MVP
Ask me before you build an MVP.
MVP scopes tend to grow. Every feature feels urgent, every "also useful" gets added on, and what started as a test becomes a product. The result: months of work, a late launch and a product too large to course-correct. A short check brings the scope back to the actual core question.
Check this before you commit
What I check first.
- 01
Which one question does this MVP test, do customers recognise the problem, or will they pay for it?
- 02
What is the smallest workflow in which a customer receives value?
- 03
Which features do not contribute to that one question?
- 04
What explicitly goes on a "later" list?
- 05
How do you tell "they used it" apart from "they came back"?
Common patterns
What I see happen most often.
- MVPs end up two to three times larger than needed.
- Features get added to avoid making choices.
- Settings, roles and dashboards are built in v1 for customers who do not yet exist.
- Credible gets confused with complete.
What the conversation produces
What you leave with.
- 01
A trimmed MVP scope, marked against the core question.
- 02
An explicit "not in v1" list.
- 03
A workable plan for the next cycle.
Further reading
Articles on this challenge.
- 6 min read
Why Your MVP Is Probably Three Times Too Big
Founders confuse a first sellable version with a complete product vision. Why features feel safe, and how to get back to one workflow.
- 8 min read
What Should Be in Your MVP and What Should Wait
A decision framework for keeping the first release complete, credible and much smaller.
- 7 min read
Build Less: The Startup Skill Nobody Wants to Learn
Adding features feels productive. Removing them requires a clearer understanding of value.
Ready to talk?
Do you really need to build all of this?
Most MVPs are much larger than they need to be. The faster you learn, the faster you discover what matters.