An MVP is neither a mockup nor an arbitrarily incomplete product. It is the smallest working version able to test an important hypothesis with real users.
Write the hypothesis before the feature list
The starting point fits in one sentence: for which user, which problem and which measurable change should the product create?
Without that hypothesis, the feature list grows without providing a method for decisions.
Build the central journey
The MVP should cover the complete path that delivers its primary value. Secondary capabilities can remain manual or move to a later release.
- One priority audience
- One clearly stated problem
- One complete primary journey
- Minimum administration
- One learning metric
Prepare learning before launch
Interviews, product events and support feedback should be planned before the first users arrive.
Initial success is measured by problem resolution and repeated use, not by the number of shipped features.
What a useful MVP brief contains
- A written product hypothesis
- Identified priority users
- Features ranked by necessity
- Listed technical and business risks
- Measurable success criteria
- V2 decisions separated from V1 scope
The best MVP protects the budget while producing evidence. It should help decide what to strengthen, correct or stop.