What should a product team build before product/market fit?
Short answer: As little as possible. Before P/MF, build only the shortest path from your ICP's problem to one Aha! Moment, and nothing that doesn't serve it. Your MVP's job is to prove market assumptions (this customer exists, and wants this promise), not to be a small version of your vision. Often the right MVP isn't software at all.
The most common and costly mistake I see is starting with the product.
Product is the third step. Before it come the ICP (who it's for) and the value proposition (why they should care). If those two aren't validated, your team is building a very good answer to a question nobody asked.
So the first thing a product team should build before P/MF is a clear answer to three questions:
- Who am I building this for?
- Why should they care?
- What's the absolute minimum I need before putting it in front of them?
Everything else waits.
Build backwards from the Aha! Moment
Users don't want more features. They want the minimum required to get what they came for.
That moment, when the user gets it, is your Aha! Moment. Slack's is a teammate replying instantly. Dropbox's is your file appearing on a second device. It's a moment, not a feature.
Work backwards from it:
- Name the Aha! Moment in your ICP's words.
- Map the shortest route from sign-up to that moment.
- List the steps, then the features each step needs.
- Cut everything else. For every feature ask: does it serve the Aha? Could a manual hack replace it for v1?
- Write an out-of-scope list and share it with the team. What you won't build is as important as what you will.
Nobody cares about the elevator. They care about getting from floor 1 to floor 32. Build the ride, not the lobby.
Your MVP may not be software
Viable means it delivers value. Not your vision. Value.
An MVP proves market assumptions: that the ICP exists and wants your promise. A prototype is different. It tests product assumptions, usually just UI, and creates no real value. Prototypes generate feedback. MVPs generate proof.
Some MVPs that worked:
| MVP type | How it works | Example |
|---|---|---|
| Concierge | You deliver the outcome by hand | Founderpath ran on a hand-run spreadsheet |
| Wizard of Oz | It looks automated; you do it behind the scenes | Zappos bought the shoes after the order came in |
| Audience-first | Build the audience before the product | Product Hunt started as a mailing list |
| Content | A newsletter, course or tool that delivers a real transformation | "I didn't know how to do this. Now I do." |
If a spreadsheet and your own time can deliver the Aha! Moment, start there. You'll learn faster than any sprint.
What to skip before P/MF
- Scale. Performance, multi-tenancy, edge cases for customers you don't have yet.
- Polish. An embarrassing MVP with real market friction beats a polished one nobody tries. The best user experience is no experience: the outcome, with as little in the way as possible.
- Features requested by one loud customer. Test them with a hypothetical paywall: "This would be a premium feature." If the enthusiasm survives a price tag, look closer. Then ask who else would benefit. If they only name themselves, it's noise.
- A roadmap of features. Prioritise problems, not features. Features are candidate solutions to problems you've ranked.
What about technical debt?
Some debt is fine. You'll likely rebuild once you know what the market wants, and that's the point.
What isn't fine is using "it's just an MVP" to excuse something that doesn't deliver the value. Cheap is allowed. Broken isn't. If users can't reach the Aha! Moment, you've learned nothing about the market, only about your bugs.
"We need more features before we launch"
I hear this weekly. My answer is a set of questions:
- Why do you think these are the missing features?
- What market feedback says so?
- If you ship without them, what happens? Do people say they're missing, ask for something else, or say nothing?
Route the decision back to evidence, not conviction. Then ship and find out.
Common mistakes
- Building for the founder's vision instead of the ICP's problem. Your vision for a product serving everyone can wait for round D.
- Treating the MVP as phase one of the final product. It's an experiment. Plan to throw parts of it away.
- Measuring output, not movement. Shipped features aren't progress. Users reaching the Aha! Moment, coming back, and paying are.
- Skipping the out-of-scope list. Without it, scope creeps in through every "small" request.
What to do next
- Write your Aha! Moment in one sentence, in your customer's words.
- Map the shortest path to it.
- Pick the cheapest MVP type that can deliver it, and write the out-of-scope list.
- Put it in front of ten people from your ICP this month.
Not sure your ICP and value proposition are solid enough to build on? Start with how to tell a P/MF problem from a go-to-market problem.
Building before you're sure what to build? Tell me what you're working on, and I'll tell you what I'd cut.