When not to build your MVP yet

It's an odd thing for a studio to publish, but the most useful conversation we have with founders is often the one where we talk them out of building. Not out of the idea — out of building it this month.

Software is the most expensive way to test an assumption. It's worth reaching for once the cheap tests are exhausted, and there are four situations where they clearly aren't.

1. You've talked to fewer than twenty people

Not twenty friends, and not twenty people who said the idea sounded good. Twenty people who have the problem, described it in their own words, and told you what they currently do instead.

That last part is the one that matters. Every problem worth solving already has a workaround — a spreadsheet, an assistant, a WhatsApp group, an afternoon each week. If you can't describe the workaround precisely, you don't yet know what you're replacing, and a product that's merely better than nothing loses to a spreadsheet that's already there.

2. You could do it manually first

If the product would serve ten customers in its first month, ask what it would take to serve those ten by hand. Often it's a form, a shared inbox, and a few hours a week.

This feels like cheating. It isn't — it's the highest-yield thing you can do, because doing the work manually teaches you the edge cases that no amount of planning surfaces. Almost every scoping call we've had where the founder had run a manual version first produced a smaller, sharper build than the one they originally asked for.

The manual version isn't a rehearsal for the product. It's the research that determines what the product should be.

3. The thing you're testing isn't the software

Sometimes the real uncertainty is whether anyone will pay, or whether you can reach the buyer at all, or whether a regulator will permit it. Software answers none of those, and building it converts an open question into twelve weeks and a bill.

A useful test: write down the single assumption that, if false, kills the business. If a working product isn't the cheapest way to test that assumption, build the cheaper test first.

4. You're building to raise, not to learn

This one is uncomfortable, because it often works — a demo does help a raise. But a product built to impress investors and a product built to serve users are different products, and the first is remarkably hard to convert into the second.

If the honest goal is a fundraise, say so out loud. The right build is smaller, more visual, and explicitly disposable. What goes badly is pretending it's version one of the real thing, then discovering in month six that the foundation was designed for a slide.

When it is time

The signals are unglamorous and fairly reliable:

• —The manual version is working and is now the bottleneck — you're turning people away or drowning in admin.
• —You can name the one workflow that matters, and it's one, not nine.
• —Someone has paid, or has credibly committed to pay, for the manual version.
• —You know which parts you'd throw away in a year, and you're comfortable with that.

That last point is the difference between an MVP and a first product. An MVP you expect to learn from and partly discard. If you can't name what you'd discard, the scope is probably still too big.

What we do with this

When someone comes to us in one of the four situations above, we say so. Occasionally that ends the conversation, which is fine — it's a cheaper ending than the alternative. More often it changes the scope, and the build that follows is smaller, faster, and considerably more likely to survive contact with users.

If you're not sure which side of the line you're on, describe where you actually are. We'll tell you straight, and there's no cost to finding out.