A Minimum Viable Product, or MVP, is the smallest useful version of a solution that can test an important product assumption with real users and generate meaningful learning.
Suppose a music product wants to explore: Give people more control over AI-generated playlists.
The complete vision might eventually include conversational editing, mood controls, artist weighting, genre controls, collaborative steering, voice input, and automatic learning from edits.
Building all of that would take significant time before the team learns whether users actually want to steer generated playlists.
An MVP could focus on one narrower behavior:
Generate playlist → lock songs you like → swap songs you dislike → undo changes
That may be enough to test the core assumption: after generating a playlist, do users value lightweight controls that let them steer the result?
Figr’s Spotify AI playlist steering project is a useful example of narrowing a broad idea into a smaller, testable product experience.
They are not the same thing.
A prototype is primarily used to explore or test how an idea might work.
An MVP is a minimum viable version intended to test an important assumption through real usage.
A clickable prototype might simulate a new booking experience without processing an actual booking. An MVP may need to complete the transaction because real behavior is what the team needs to learn from.
A proof of concept asks: Can we build this?
An MVP asks: Should we continue building this based on how users respond?
A technical team might create a proof of concept showing that an AI model can classify customer requests. The MVP would turn enough of that capability into a usable experience to see whether customers find it valuable.
V1 simply means the first released version.
An MVP has an explicit learning purpose. If the team cannot state which assumption the release is supposed to test, calling it an MVP does not make it one.
An MVP should not be a random small feature. It should test something important enough to influence product strategy or a meaningful product decision.
If the result would not change what the team does next, the experiment may not be testing the right assumption.
Minimum scope is not permission for minimum quality.
Then nobody knows why the MVP succeeded or failed.
If the experience no longer solves the user’s problem, it is not viable.
An MVP should have a learning objective before it launches.
Sometimes the correct result of an MVP is: do not build this.
No. The experiment only needs to test the underlying assumption reliably.
It should be credible enough that poor execution does not invalidate what you are trying to learn. The required fidelity depends on the assumption.
The team evaluates the evidence and decides whether to iterate, expand, change direction, or stop.
The right question is not: What is the smallest product we can ship?
It is: What is the smallest useful thing we can put in front of users to learn whether our most important assumption is true?
That distinction is the whole point.
Product discovery · Product strategy · Product management · User story · PRD
For the discovery side of MVP decisions, read Discovery vs Delivery Product Management.