Recently I’ve been talking to potential customers about a product space I’ve been exploring. One thing I’ve wondered as I do this is, “At what point should we ask our first customers to pay?”
Writing on how to develop a SaaS product tends to advocate one of two approaches:
- “Sell, then build.” It’s critical that you build something people will pay for. So you should use product discovery interviews to determine what people will pay for, then get your first customer to commit to paying, then build what you’ve sold – and iterate from there.
- “Build, then give it away.” It’s critical that you build something great, and that can only be done with ample customer feedback. So you should get useful software in customer hands as early as possible, before you can even justify charging them – then charge for it once their feedback (and your iteration) has built something they’ll happily pay for.
Each of these approaches has a certain appeal: They each avoid a famous pitfall of product development.
Many consultancies have sold a complex bespoke product to one large customer, then found it doesn’t generalize to other customers. Many startups have built a polished product that embodies their founder’s vision, only to discover nobody will pay for that vision. They’re both dead ends!
So you get these two lines of advice: sell first, or build first. Mutually exclusive paths.
As I noticed this tension, I did what I do: I asked founders and other smart people how they think about it. Here’s what I’ve learned so far.
Sell, then build
Selling first is, naturally, the preferred path for salespeople. If you are a non-technical founder hoping to raise money to hire a development team, you probably need to first prove that you can sell what you’ll build.
This is the classic Lean Startup mentality: your hypothesis is that you can sell something. What better way to prove this than by selling it?
Going sales-first can also be appealing for bootstrappers. The strategy “Build a great product, then give it away” requires being able to afford giving something valuable away. Not everybody has – or wants to raise – the capital necessary to do that. If you instead start by selling what you want to build, you can get your first revenue faster.
Starting with sales is also a natural path for startups that will need to go to market with a sales-led approach anyway. If the problem you’re solving is specific to large retailers, but is worth $50 million/yr to each of them, they’re not going to serve themselves from your website – no matter how delightful it is. Best to start with sales.
On top of all this, there’s a reason VCs tend to encourage founders to go full-on enterprise sales mode: it can be a somewhat lower risk, more systematic path to success than a product-led one.
All that said, starting with sales has downsides. Enterprise sales are not, typically, driven by surprise and delight. Sure, there are many great businesses that started product-first, building a wonderful experience for their customers, that then shifted to sales-led growth as they matured. But startups that start sales-centric, often, find themselves struggling to build a great user experience.
Something is lost, it seems, when a product starts its life as a sales negotiation. You’ve proven a need, but it can be difficult to build something people love from there. Starting with sales tends to lead to building something customers think they want, rather than exploring deeper and potentially more valuable territory.
Early-stage sales-led teams have a tendency to get thrashed from customer demand to customer demand. “Ford says we need to add support for CORBA. Oh, and Eli Lilly needs us to add 3D dashboards.” Your product startup can end up maintaining a bunch of custom stuff for a small number of customers – basically, a consultancy.
All that said, it’s possible for startups to keep healthy boundaries while closing big sales, allowing them to build a single product that’s coherent and thoughtful. Really successful companies have been built this way.
At least, in certain markets.
Build, then give it away
Building first is, on the other hand, appealing to developers. We’re good at building. And we like it! Meanwhile, we have an instinctual suspicion of salespeople. And of enterprise contracts. We’d rather focus on making stuff that users love.
A popular way to defer the sales process, and first prove you’re making something people want, is to let folks use the initial versions of your product for free. Dennis Pilarinos described in a recent interview why, at his startups, he’s made his early iterations free:
If you help us along that journey, then when we launch pricing, you’re grandfathered in. The thinking is, you’ve already paid us with something more valuable than money: your time. So if you take the time to use this product and provide feedback to us, it feels disingenuous to then say, “Also give me money,” because we’re already getting that benefit.
This kind of humble exploration naturally fits with a product-led growth strategy that will eventually scale to a lot of customers. Product-first is a great approach if you’re building something for customers who are suspicious of salespeople – other developers, for example. For certain consumer-facing products, you might have no choice but to start with building a free product.
Building first, though, has its own perils.
For one: It is very, very easy to build something nobody will pay for.
One time, years ago, I had the idea to build an image browser app for iPad – like a visual version of Instapaper. We built it, polished the heck out of it until it was delightful, launched it, and achieved a 5.0-star rating on the App Store. Our customers loved it.
Unfortunately, there were only a hundred customers. We never even made enough money to recoup what we spent on the app’s icon. We built something wonderful that nobody was looking for, and nobody would pay for. It sucked.
If you sell first, though, you’re forced to talk to customers. You have to research your target market, develop and refine an approach for explaining what pain you’re solving in a way that resonates, and overcome customers’ objections.
Building first makes it possible to defer all this. You might tell yourself, “I basically know what they want, I already talked to customers, so let’s just focus on getting a solid v1 ready.” This is dangerous thinking, because it can lead to not putting critical eyes on what you’re building for way too long.
In that same interview, Dennis vividly described what it feels like to put rough, early versions of your product in front of customers for feedback:
It’s just repeatedly getting kicked in the teeth. I felt like I needed to go to the dentist every month to get dentures put in, right? Finding product market fit is hard.
If you’re a builder who takes pride in your work, and you get your teeth kicked in by early potential customers, it’s really tempting to defer talking to them further. It’s easy to tell yourself that you just need more time to make the product lovable. That you can step back from customers for a few months – or, god forbid, years. To spend your time and money on making that prototype you had, the thing that people didn’t want to pay for, really lovable before you launch it with fanfare to a crushing defeat.
Fundamentally, if you’re going to run the build-first playbook, you need to come at it with the mindset of not just building something people love, but something people will pay for. There are a bunch of frameworks for doing this, but even so it can mean iterating and adjusting for a long time until you’re building the right thing.
That gets to another challenge with the build-first approach: it can get expensive. Excellent software engineering teams cost a lot of money. Sometimes you can build a compelling product by yourself, maybe as a side project. Some great businesses start that way. But if you have your sights set on something ambitious – a hard problem, a discerning market, or a fast-moving space – it can be hard to self-fund the full cycle of “Build, give it away, collect feedback, iterate, then charge money” before running out of runway.
This brings me to a final observation I’ve had about folks who advocate giving a product away before charging for it: they usually have funding. A growing user base of free or trial customers may help you raise investment, but doesn’t help you make payroll.
Finding the path, one mistake at a time
As with most dichotomies, this one is partly false. There are many paths you can take between the extremes of being fully sales-centric vs. making your product free forever for your early users.
Slack started with a free invite-only preview, but started charging for pro features within less than a year, paired with generous credits for early customers. Mailchimp bootstrapped to profitability, and didn’t have a free plan for years. Shopify launched with free store creation, but charged 3% of sales from day one. There are a lot of approaches that can work.
Like most startup tactics, the right approach depends on what kind of company you’re trying to build. If you’re building a business that depends on big enterprise deals, you’d best start with sales. If you’re set on building a product that is so insanely great that your users drive your growth, you’d best focus on building that great product.
Either way, the end goal is the same: building something great that people want to pay for.
As long as you do that, you might have a chance.
Thanks to Lynsey Thornton, David Hariri, Martin Ertl, Dennis Pilarinos, and the other friends I’ve interrogated recently for their feedback on the ideas behind this article.