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.