By PaviqLabs · · 2 min read
A minimum viable product (MVP) is the smallest version of a product that lets you learn whether it solves a real problem for real users. The most common mistake is not building too little; it's building too much before learning anything.
Start with the question you need answered
Every MVP should test a specific assumption, for example: "Will small accounting firms upload client documents to a portal instead of emailing them?" Write that question down. Any feature that doesn't help answer it is a candidate to postpone.
Map one core journey end to end
Identify the single path a user takes to get value, from first arriving to completing the key task. Build that journey properly, including the unglamorous parts such as sign-up, error messages and notifications. A complete narrow journey teaches you more than a broad set of half-finished features.
Sort features into three groups
- Must have: without it, users cannot complete the core journey.
- Should have later: valuable, but users can succeed without it in the first release.
- Assumptions to test first: ideas you could validate with a conversation, a prototype or a manual process before writing code.
Warning signs that the scope is growing too large
- The feature list is longer than the list of questions you want the MVP to answer.
- Several features exist mainly to handle situations you haven't seen yet.
- You are building admin tools, settings or integrations before anyone has used the core journey.
- Launch keeps moving because each review adds "one more" requirement.
- Nobody can describe in one sentence what a successful first release looks like.
If several of these apply, pause and revisit the original question. It is usually possible to remove or defer a significant part of the scope without weakening what you learn, and the time saved can be spent improving the core journey instead.
Do things manually where you can
Many processes can be handled by a person behind the scenes in the early days: approving accounts, generating reports or matching requests. Automating them is worthwhile once you know they matter and how often they happen.
Don't cut the foundations
"Minimum" refers to features, not quality. Security, data protection, reliable hosting, basic analytics and a way to collect feedback should be part of the first release. Shortcuts here tend to become expensive problems precisely when the product starts to succeed.
Define success before you launch
Decide in advance what you will measure and what result would make you continue, change direction or stop. Without that, it's easy to interpret any outcome as encouraging and keep building without learning.