Vact MVP Planning: How to Define and Deliver a Minimum Viable Product
The Minimum Viable Product (MVP) is the smallest version of a product that delivers enough value to attract early users and validate the core product hypothesis. Coined by Eric Ries in The Lean Startup, the MVP concept is frequently misunderstood. It is not a half-built product. It is not the first version with all features but poor quality. It is the smallest set of features that proves (or disproves) the assumption that users want what you are building.
MVP Planning: How to Define and Deliver a Minimum Viable Product
What an MVP Is and Is Not
An MVP is: A complete, usable product that solves the core problem for a specific user segment. It may lack advanced features, but the features it includes work well.
An MVP is not: A buggy prototype, a demo without real functionality, or a product that does everything poorly. Users will not adopt a product that does not work, regardless of how minimal the feature set is.
The skateboard analogy is instructive: an MVP for transportation is a skateboard, not a car chassis without wheels. The skateboard is complete, functional, and solves the core problem (getting from A to B) even though it lacks the comfort and features of a car.
Defining the MVP
Step 1: Identify the Core Hypothesis
What assumption are you testing? “Small teams need a simpler alternative to Jira for sprint management” is a hypothesis. The MVP tests this by delivering the simplest sprint management experience that validates or invalidates the assumption.
Step 2: Define the Target User
Who is the MVP for? Not everyone. Not the general market. A specific user segment with a specific problem. “Freelance developers managing personal projects” is a segment. “Everyone who needs project management” is not.
Step 3: Map the Core User Journey
Using user story mapping, identify the minimum journey the user needs to complete to receive value. For a task management MVP, the journey might be: create a project, add tasks, move tasks between columns, and mark tasks complete.
Step 4: Cut Ruthlessly
For each feature in the journey, ask: “If we remove this, does the product still solve the core problem?” If yes, remove it. The MVP should make the team uncomfortable with how little it includes. If you are not embarrassed by v1, you launched too late.
MVP Feature Prioritization
| Feature | Core Problem | MVP? | Post-MVP? |
|---|---|---|---|
| Task creation and status | Yes | Yes | |
| Kanban board view | Yes | Yes | |
| User authentication | Yes (multi-user) | Yes | |
| Advanced reporting | No | Sprint 3-4 | |
| Custom workflows | No | Sprint 5-6 | |
| Third-party integrations | No | Sprint 7+ | |
| Mobile app | No | Phase 2 |
Delivery Approach
Time-Box the MVP
Set a fixed deadline for MVP delivery — typically 4-8 weeks. If scope and timeline conflict, cut scope. The purpose of the MVP is to learn, and you learn faster by shipping sooner.
Ship to Real Users
An MVP that sits in staging forever teaches nothing. Ship it to real users, even if the user base is small. Ten real users providing genuine feedback is more valuable than a hundred internal testers validating known scenarios.
Measure What Matters
Define success criteria before launch:
- Engagement: Do users return after the first session?
- Activation: Do users complete the core workflow?
- Retention: Do users continue using the product after one week? Two weeks?
- Feedback quality: Are users requesting additions (positive signal) or reporting broken basics (negative signal)?
After the MVP
Iterate Based on Data
The MVP produces data that informs the next iteration. Use agile metrics and user feedback to decide what to build next. The product backlog after MVP launch should be informed by real user behavior, not pre-launch assumptions.
The Build-Measure-Learn Loop
- Build the smallest increment that tests the next hypothesis
- Measure user behavior and feedback
- Learn what worked and what did not
- Repeat
Each cycle should be fast — one to two sprints. The goal is to maximize learning per unit of time invested.
Pivot or Persevere
If the MVP data invalidates the core hypothesis (users do not engage, the problem is not significant enough, the solution does not resonate), decide whether to pivot (change direction) or persevere (iterate on the current approach). This decision should be made with data, not hope.
Common MVP Mistakes
Too much functionality. The most common mistake. Teams include “just one more feature” until the MVP is no longer minimal. Use MoSCoW prioritization to enforce discipline.
Too little quality. An MVP must work. Users will forgive missing features but not broken ones.
No success criteria. Launching without knowing what success looks like means you cannot evaluate the results. Define criteria before building.
Not shipping. Teams that perfect the MVP endlessly miss the point. The value is in user feedback, which requires shipping.
Wrong audience. Launching to a general audience instead of the specific user segment the MVP was designed for produces misleading feedback. Target the right users for the most useful data.