An MVP is not simply an incomplete product
A minimum viable product is the smallest version that can test a relevant hypothesis with real users. Minimum refers to scope; viable means the experience must be reliable enough to produce valid learning.
It should answer a specific question: do people have this problem, will they adopt the solution, will they pay for it, or can the process operate this way?
Define hypotheses before features
Describe the target user, problem, proposed value and expected behavior. Then decide what evidence would support or reject the hypothesis: completed tasks, repeated use, time to value, continuity requests or willingness to pay.
Include only what enables value and learning
Build one complete primary journey, provide the security and data handling the context requires, and include measurement from the first version. Postpone advanced customization and rare scenarios.
If removing a feature does not prevent value or learning, it probably does not belong in the MVP.
Use the least expensive valid test
A prototype can test comprehension and usability. A partly manual pilot can test demand. Functional software is needed when performance, integration, recurrence or real operating conditions are part of the hypothesis.
Define decision criteria before launch
Measure activation, completion of the primary journey, repetition, time to value and abandonment. Decide in advance which results would lead the team to continue, adjust or stop. After the test, document the learning before adding more scope.
Frequently asked questions
How many features should an MVP have?
There is no universal number. It needs the features required to complete the primary journey and test the hypothesis.
Can an MVP include manual processes?
Yes, when they are controlled and do not invalidate the learning being sought.
Need to apply this to your operation?
We can help you turn this approach into a clear scope and practical path.
Explore software project planning →