Lessons learned going from idea to $130,000,000

You don’t need to be technical to build a great company. But doing so without the right help is extremely difficult.

Here’s how Charitable Impact’s non-technical CEO and I worked together to go from napkin to MVP to $130 million (and on to $530 million). I led product development as a consultant and was the first person he brought on to validate and grow the business.

The Beginning

In 2008 I left eduFire, the first company I started. Shortly after leaving I went for coffee with my friend John, who’d also been an investor in the company.

John told me he had an idea to use the internet to improve how people gave to charity. He had deep domain expertise in finance. His co-founder (and dad) Blake had deep domain experience in charitable law. But neither of them were technical. He wanted to know if I was interested in helping them on the product and technical fronts to build an MVP and see if his idea had legs.

I agreed, and for the next 7 years we worked closely together to grow Charitable Impact. It went from idea to a platform that processed $130,000,000+ in donations before I rolled off. And as of Jan 2020 they’re up to $530 million.

For some context, Charitable Impact enabled Canadians to give to charity in a variety of ways: individually, as part of a group, through their workplace, and via an investment account.

Here are the key lessons I learned about how to build and grow a $100M+ product.

Prototype and validate

After scoping down John’s big vision into a buildable v1 (which is what we called MVPs in 2008) I built a prototype. At this point the company was just me and John - no designer - so it looked like an ugly version of Craigslist.

We walked people through our prototype, refined it several times based on what we learned, and convinced ourselves about what the “right” v1 was to invest in building.

Since the cost of change increases with each line of written code, building and validating a protoype before we wrote code was one of the smartest things we did.

At times it felt like we were going slowly because it took longer to build usable software. But in the end we got to a “good” product quicker and cheaper because of the learnings from our prototype.

Validation: not just for new products

Even when the product was more mature we’d validate feature concepts with customers. There were several occasions when we proudly showed prototypes of features to customers only to find out there was no appetite for them. This humbling experience had upside though: we saved a bunch of money on what would have been expensive builds of useless features.

Today you can validate ever quicker

Today there’s a whole host of ways to build a better looking prototype with off-the-shelf components: you can buy a theme from WrapBootstrap or ThemeForest to make your app look good, and use NoCode tools like Bubble or Airtable to build a quick and dirty prototype.

The key idea here is that you can quickly test your product solution in real-world conditions to learn where your theories were right and where they need to be tweaked. Once you’ve learned enough from your prototype you’ll probably want to undertake a custom build. But in the early stages the goal should be to learn as quickly and cheaply as possible to figure out what the right problem and solution look like.

Talk to customers often

Cliche? Yes.

Effective? You bet.

Before we created a prototype we went out into the big bad world to understand things like:

• how people gave to charity (in turns out not only solo, but also as a group, through a company, using non-cash assets, and in a variety of other ways)
• what barriers there were to giving online (findability, bad UX, poor trust signals)
• what compelled people to give (usually emotional appeals for the poor and middle class, and tax benefits for the wealthy)
• how people thought about spontaneous giving via mobile (this was in mid 2008, shortly after Apple launched the iPhone app store)

Over the subsequent seven years on the gig, I ran usability tests, did customer calls and in-person interviews to validate our understanding of customer problems and potential solutions, and relied on customer-facing teams (like support) to better understand how people thought about charity and about the product.

The best part was that pretty much every single time I spoke to a customer I learned something new about the market, problem, solution, pricing, or our product.

In my experience Product Managers tend to believe they know what their customers’ problems actually are and what a good solution looks like (and I’m just as guilty of this!) But the evidence strongly suggests this isn’t true: if it was, new features would have significant adoption because they solve customer problems so well. In the real world, this sadly isn’t true.

Talking to customers always helps bridge the gap between customer problem and a good solution.

Hire a small, phenomenal technical team

At this stage, small teams are preferable. Small means you won’t build things you don’t need - big means you need to keep everybody busy. Small means there are fewer ways for communication to go wrong so you can get alignment quicker and go faster. Small means less potential for interpersonal conflict. And small means you spend less.

You also want a high quality team. This can be difficult to assess if you’re not technical. It’s basically impossible to know what a “good” hire or agency looks like if you haven’t done the job yourself. The best approach to hiring is to have someone technical who you trust to help with the hiring.

Here are seven things we did that helped us build a great team at Charitable Impact.

Hire known quantities, if possible

Initially our team was John and me. Our first hire was a fantastic dev and all-around super guy named Dan. We were lucky to find Dan. He, John, and I gelled quickly.

After that we brought on Arif (a friend of mine), Chris (a friend of Dan’s), and we rounded out the team with Clayton (a young and hungry designer). Bringing on friends meant the team trusted each other faster and quicker than if we had brought together five people who didn’t know each other at all.

The Hiring Manager does outreach

Building a list of candidates to reach out to is time consuming and painful. But it was time well spent: it’s how I found Dan and Clayton.

Hiring managers are more credible than recruiters or HR when reaching out: you can talk the candidates’ language, you can be discerning about who to reach out to, and you can talk authentically about the challenges and opportunities of the job.

Since a company only has one chance to make a first impression, having a hiring manager reach out is sometimes the difference between a reply and your email getting binned.

Reach people via email, not LinkedIn

I wanted my cold emails to land in their inbox, which (in 2008) everybody checked.

I put a lot of work into finding people who had portfolios. In 2008 this meant they’d done a bunch of work and cared about their online presence - website building tools like Squarespace were far less dominant than today.

Finding an email address was easy because a portfolio site likely meant people wanted to be contacted for new opportunities.

Emailing candidates directly with a personalized email from a human instead of hitting them up on LinkedIn pretty much guaranteed my email would at least get a look.

Be normal

My outreach email wasn’t full of acronyms and didn’t promise the world. It was personalized (commenting on their work), apologized for interrupting them if they weren’t interested, and was clearly from a normal-sounding person similar to them who was trying to find someone great to work on an interesting project.

It was written like you’d write your mom, if you were trying to hire her as a software developer or designer.

Have a story that attracts like-minded people

Charitable Impact had a story that repelled some and attracted others, simply based on their perspectives about charity. We leaned on this as a quick filter to ensure we only talked to people who were aligned with the company’s mission.

Have an opinion on the teammates you want

We were quite deliberate about this. We wanted a team comprised of people who were generally:

• Conscientious. They sweated the details.
• High integrity. If you can’t trust who you work with, they’re not worth working with.
• Reliable. When they said they’d get something done, you’d believe them because they had a history of following through on what they said they’d do.
• Self-managing. If there was an issue, they’d raise it.
• An expert. They were very talented at what they did.
• T-shaped. They had deep expertise in their area of expertise, but could pick up slack in related areas if necessary (for example, I’d write code, our designer Clayton would do product work, etc). This meant people wouldn’t necessarily need to wait for someone in an adjacent discipline to get things done - sometimes they could do it themselves. Which also meant communication overhead was lower.
• Communicative. Information got shared and wasn’t used as currency.
• Kind. The kind of people you liked to hang out with after hours.

Looking back we created a very psychologically safe team (what Google has discovered is one of the main criteria for team success).

Here’s an example of how effectively someone with the above qualities can function on a small team.

One of my favorite sayings about software is “a good developer is her own best product manager”. This means a dev has a nose for sniffing out and making good tradeoffs to get the right product to market cheaper and faster.

Dan is this kind of dev. He single-handedly built a double-entry bookkeeping system to run Charitable Impact’s accounting. This was especially important because charity is highly regulated and tracking cash inflows and outflows needs to be perfect - getting it wrong could be existential. Dan was the dev and de-facto product manager on it - I was barely involved. He cared about the project, took ownership, was able to operate across different domains (product, accounting, software dev) and he nailed it.

It’s incredibly rewarding to be able to work with teammates you can trust to do great work.

Keep recruiting until you’re satisfied

Let me say up front: we were incredibly lucky with the five-person product dev team we ended up with. But we had worked with several other (literally) world famous developers and designers to get there. Some did great work, and some (surprisingly) not so much. But when it became clear there wasn’t great alignment between what they wanted and what the team needed, we parted ways.

In short, we didn’t stop looking until we were satisfied with the team composition.

Produce steadily (but sprint sometimes)

The word “sprint” in the context of software development is a joke. Nobody spends their life sprinting, and devs shouldn’t either.

We prefered steady and productive output. But on occasion we’d have to run like heck.

One example was late in the stages of our first significant partnership with Bell Canada. Bell was running their annual national campaign to raise Mental Health Awareness.

Canada has two official languages (English and French). And Bell required the community we were building to be available in French, which it wasn’t. And launch was 6 weeks away. And we had just absorbed a three person team, and were in the transition phase of sorting out roles and responsibilites.

I don’t like heroically-built software. I’d rather have a predictable plan and execute. But sometimes you get tossed a curveball and need to sprint.

So we worked our tails off for those 6 weeks to localize the site into French. It was a royal pain - especially since it spanned the Christmas holidays. We got particularly lucky that of the teammates we absorbed named Chris largely drove the project to completion (he’s now a PM at Zapier).

Ultimately we were able to localize because we built a tight process, we had a conscientious and experienced team, and we had gas in the tank to sprint when needed.

But if you’re sprinting all the time you’re headed for burnout.

Establish (and change) dev process when necessary

I like a team to have guard rails up to make it easy to do the actitivies necessary to ship good software. It reduces variability, increases quality, and generally makes life easier.

Our process was always some variation of:

1. Gather customer feedback
2. Design mocks or wireframes
3. Validate feature
4. Refine mocks
5. Build high-fidelity designs
6. Write requirements doc
7. Split into small implementable chunks
8. Build
9. Dev and Product Manager do acceptance testing
10. Ship
11. Measure success
12. Gather customer feedback and feed into process

We revisited it when shipping software started to feel painful. Over the course of seven years we tweaked the process and changed our tooling when it made sense. What we used at two people changed as we grew to eight and had more stakeholders.

Don’t overhire or overwork

Of the the initial five person team, three of us worked half-time and two were full time.

We kept the team small. When building a fairly straightforward web app, a small team lets you do the right things faster. More people means more communication overhead, more people to keep busy building things that you’re not sure customers want, more potential for interpersonal conflict, and a higher burn rate.

A full-time Product Manager should be able to keep 10-15 full-time developers working away. So it wasn’t a problem to keep the dev team humming, talk to customers, make sure product strategy was aligned with the business vision, and tweak our shipping process, and ship product on a half-time basis.

Two of the devs were also consultants and both also worked half time. Having less time to work is a forcing function to ensure you’re working on the important things. It worked incredibly well at Charitable Impact.

Build camraderie but also get stuff done

The first company I started in 2007 was entirely remote (our team was in Santa Monica, NY, Raleigh-Durham, SF, and Indianapolis). I’d seen the future and it was remote, as had the rest of the Charitable Impact product dev team. John was game, with the caveat that we come in one day a week. We settled on working remotely except for Tuesdays, when we all commuted into the office.

The face to face time enhanced the relationships we were continuously building in Campfire (RIP) and later Slack, but was generally worse for productivity.

I think it was the best of both worlds, to be honest. Creating psychological safety in a team takes trust. Trust can absolutely be built online, but I believe is more easily built in person. We all had that weekly face to face checkpoint. But it was in addition to four glorious days of focused deep work in one’s preferred working environment.

Choose your technology carefully

Here are some business reasons that impact how to choose your core technology.

Is your dev team comfortable with it?

The first business reason for choosing your technology “stack” (the series of technologies that make your app work) should be: is your development team comfortable with it? If so, they’re obviously going to be more productive than if they have to learn it.

If they don’t know it but want to learn it, and they’re senior, they’ll likely become somewhat productive in a few weeks. At eduFire both me and our CTO (I ran Product but also wrote code) learned Ruby on Rails, but we hired a consultant to accelerate our learning. It was expensive, but it was money well spent. That’s because in 2007 there weren’t many frameworks that enabled blazing fast development like Rails does. We could have used something we were both familiar with, but we still wouldn’t have built our app as quickly as we did with Rails because it enables rapid development.

Can you ship quickly and maintain features inexpensively?

The second should be: how expensive is it to ship and maintain new features?

Your main costs in the early days will likely be developer costs. So the less time you spend writing and maintaining code, the less you’ll spend on developers. Choosing a simple tech stack generally optimizes for this.

The smartest approach I’ve seen - assuming you’re building a typical web app - is to keep it as simple as possible: use a self-contained framework that lets you do all you need (like Ruby on Rails or Django). Do not use technologies that can work together but take more work (like Rails and React).

In general keeping things self-contained means your dev team can spend less time (and thus money) wrestling with tools and more time delivering customer value. You can always add fancier technology later when you have the business need and money to pay the cost that comes with using technologies that weren’t designed to work together out of the box.

At Charitable Impact we chose a framework calls Ruby on Rails that Dan and I – the first two technical people on the project – had lots of experience with. Arif was also familiar with it, and Chris got up to speed super quickly (it shouldn’t take a ton of time for an experienced developer to get up to speed with a new language or framework). Rails is one of the handful of ideal frameworks for quickly building and maintaining a new web app.

Can you hire more developers later?

The third business consideration that impacts your technology choice should be: will we be able to hire people who know it or want to learn it? In general the answer to this question is “probably yes”. But it depends on your region, whether you hire remotely, and how much you’re willing and able to pay.

Can it provide the required UX?

The fourth criteria should be: will it provide the required customer experience? You’ll notice I caveated the decision about using a self-contained framework like Rails or Django with “assuming you’re building a typical web app”.

If you’re building something that must feel like a desktop app (like Trello), you’ll need something fancier than Rails or Django. But most apps aren’t like Trello. In that case, fancy technology costs more than it benefits at the beginning.

Is it well-supported?

Finally, a well-supported (and ideally open source) framework means your team will be able to use the work of others in your app. For example, we needed to generate PDF tax receipts at Charitable Impact. Because we used a widely-adopted framework (Rails), there were plugins we used to generate PDFs that saved our dev team hundreds of hours (or more).

Using a well-supported framework has all kinds of time-saving advantages when building a new app.

Use your unfair advantages

Charitable Impact was #blessed with a handful of advantages:

1. Its founders had deep domain experience and a broad network in charity (at the time, one was in the process of helping a major Asian government think through its charitable tax policy.)

2. Vancouver had a nascent tech community, and Charitable Impact was one of the visible players. It leveraged this when hiring and building brand partnerships with companies like Bell Canada, Hootsuite, and lululemon.

3. We were lucky enough to pull together a cross-functional software development team who framed many of our decisions in terms of “how will this impact the business” rather than “is this cool tech”. This helped us use software to grow the business rather than to build interesting tech for its own sake.

Here are two examples of our unfair advantages in action:

Our first brand partnership was with Bell Canada

It’s not many startups that do their first partnership powering a community for a company with a $41 billion market cap.

But high-level connections in the charitable world yielded high-level connections in the private world (this is a great hack btw - it’s easier to meet powerful/rich people through the charity world). Through those connections, Charitable Impact powered part of the community giving piece of Bell Canada’s mental health awareness campaign.

In future conversations with potential partners we were able to talk about our partnership with Bell, which gave us instant credibility.

Without relying on a broad and deep network in the charitable world that few people have, this partnership never would have happened.

We increased traffic by 24%+ with some mild engineering effort

I’d been reading a lot of Patrick McKenzie’s writing about using engineering leverage in marketing. It occurred to me that we could take each charity’s publicly-available tax return information and create a landing page for them.

So we did. And this engineering-as-marketing approach quickly added tens of thousands of landing pages and almost 25% more traffic.

Because we thought about decisions in terms of their impact on the business, we quickly identified this as an opportunity and the team quickly bought in to try it.

Summing up

You can build a real tech business with a small team of the right senior people, even if you’re not technical. But having the right help is critical.

That random catch-up coffee with John turned into seven years of lessons about growing from idea to mature product. There’s no doubt we got lucky (anybody who succeeds without acknowledging that is lying to themselves, or to you!) But some things that work never go out of style: hiring good people, choosing tech wisely, talking to customers, prototyping and validating, and using your unfair advantages.

Doing those things right most of the time helped Charitable Impact achieve part of its vision: over half a billion dollars raised for charity, and lasting change in the Charitable sector.