MVP or prototype: what must the first version really do?

A prototype is a representation built to answer a design question. Will people understand it? Can they use it? Can we build it? A minimum viable product answers a different question. Eric Ries defined it as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” In practice, it meets real people in real conditions and tests whether they value the offer enough to change what they do.

So the first version must do one thing a prototype does not: put something real in front of people who are not role-playing. A paper sketch can be thrown away after a morning. An MVP asks real people for attention, time or money, and it has to honour whatever it promises in return, however small. “Minimum” describes the scope needed for the learning. It does not describe the level of care, safety or honesty.

The worked example below follows an invented language school testing an online conversation-practice club for adults.

A prototype asks whether it works; an MVP asks whether it matters

Ries’ 2009 guide to the minimum viable product gives the definition above, then adds caveats that are often lost. The MVP, he writes, “is not about creating minimal products”. Because the definition pairs maximum learning with minimum effort, it is “decidedly not formulaic”: what makes sense requires judgement in each context. In one of his examples, a feature took two weeks to build and nobody wanted it; a simple AdWords smoke test would have shown that sooner.

The Lean Startup methodology page states the underlying question sharply. It is not “Can this product be built?” but “Should this product be built?”, and whether a sustainable business can form around it. That is a question about value and behaviour, which only people using something in their own lives can answer.

A prototype usually works under protected conditions. GOV.UK’s description of the alpha phase asks teams to build prototypes, try different ideas and do the minimum needed to test their riskiest assumptions. It also says alpha services should not be available for the public to use, and that teams should expect to throw away the code and many of the ideas. That protection is what makes rough exploration acceptable.

Our guide to concept testing covers the prototype side: how people interpret an offer and whether they can complete a task. In Double Diamond terms, prototypes help a team develop and compare responses. An MVP comes once one response is concrete enough to hand to real people.

Why “MVP” means different things to different people

The term has travelled further than its definition. Lenarduzzi and Taibi’s systematic mapping study screened 97 articles, kept 22 and produced a classification schema for how the MVP is defined in lean start-up literature. The key factors it identifies span technical characteristics of the product as well as market and customer aspects. That such a schema was needed at all suggests the term has no single settled meaning. When a colleague says “let’s just ship an MVP”, ask which one they mean.

Some people mean a learning instrument in Ries’ sense; others mean a first release with fewer features, or a rushed version to be fixed later. Henrik Kniberg’s blog post Making sense of MVP names that last reading bluntly: for some customers, he writes, MVP has come to mean “Minimum Releasable Crap”.

His response is a practitioner metaphor, not a research finding. Instead of delivering a car one unusable part at a time, a team delivers a skateboard, then a scooter, a bicycle and a motorcycle, learning as it goes. He suggests avoiding the term and naming the aim instead: the earliest testable product, which customers can do something with; the earliest usable product, which early adopters will use willingly; and the earliest lovable product, which people will recommend and pay for. The split is useful because it makes a team say which of the three it is attempting.

Steve Blank’s 2013 Harvard Business Review article places MVPs inside a wider method. Founders treat their plans as untested hypotheses, get out of the building to test them with potential users, purchasers and partners, assemble minimum viable products quickly and use the feedback for small adjustments or larger changes of direction. When the uncertainty concerns the whole business rather than the product, a Business Model Canvas read as linked, testable assumptions helps show which one an MVP is meant to test.

Prototype, MVP or pilot: what each one can show

The labels overlap. What matters is the question a version answers and what it cannot prove. The comparison is an editorial summary, not an official typology.

Aspect	Prototype	MVP	Pilot or first release
Question answered	Is it understood, usable, feasible?	Do real people value it enough to act?	Can we deliver it reliably at limited scale?
Who uses it	Test participants, often in a session	Real users in their own circumstances	A defined group of real users
Typical form	Sketch, mock-up, clickable model, rehearsal	Manual service, single feature, borrowed tools	The intended service with real operations
What it cannot prove	Demand, repeat use, willingness to pay	Scalability, unit cost, mainstream demand	Long-term adoption across all settings

A pilot shifts the emphasis from whether to build to how to run. GOV.UK’s guidance on the beta phase starts with a private beta for a limited number of invited people. It asks teams to make sure support staff can cope with users who struggle, to show regular accessibility testing at the beta assessment and to be ready to explain how users’ data stays safe. Most MVPs are far smaller than a government service, but the logic transfers: once real people depend on something, some safeguards stop being optional.

Five early product tests and what each one hides

Practitioners use a handful of recurring forms, under names that vary between books and blogs.

A concierge test delivers the service by hand to real customers who know a person is doing the work. It shows whether people take up the offer, what they actually need and whether they come back. It hides the cost of doing the same thing at scale, and it can flatter the idea: people may be responding to an attentive human rather than to the service.

A Wizard of Oz test presents what looks like an automated product while people do the work behind the scenes. It shows how people behave with an interface they believe works. It cannot show whether the automation can be built, and it raises an honesty question, because people may share information differently when they think only a machine will read it.

A single-feature product offers one function done properly. It shows whether the core job earns repeated use. It cannot show whether the wider offer you imagine around it is needed.

A smoke test, often a landing page or an advertisement, describes an offer and measures who responds. Ries’ AdWords example is this kind. It shows whether a message attracts a particular audience. Clicks and sign-ups are not use, payment or retention, and results depend heavily on wording and placement.

A piecemeal test assembles the service from existing tools: a form, a spreadsheet, a video platform, a payment link. It shows whether the whole workflow can deliver something useful before anything custom is built. It hides the effort of stitching tools together by hand, and it can scatter personal data across services nobody reviewed.

The forms combine: the club in our example is a concierge test that is also partly piecemeal.

Test demand without deceiving people

A “fake door” test shows an option for something that does not exist yet, such as a button to join a service, and records who clicks. It can be a fair way to gauge interest. It becomes a problem when it costs people money, time or trust.

Never take money for something you will not deliver. For a stronger signal than a click, ask people to register interest, or deliver the service properly to the first people who pay. Tell people what is happening as soon as they act: that the service is not available yet, what you will do with their details and whether you will contact them.

Say what is manual. A concierge test is transparent by design. A Wizard of Oz test hides the people, so ask whether participants would object if they knew who was reading their messages. If they would, tell them or choose another test.

Protect data from the first day. Collect only what the test needs, decide who can see it and delete it at the end unless people agree otherwise. Keep services that people rely on for health, money, safety or legal status out of casual experiments; those need specialist review before any live test. This is ethical guidance, not legal advice; check payment and data rules with someone qualified.

A concierge MVP for an online conversation club

Consider a fictional language school with a loyal group of adult evening students and a director, Hannah, who keeps hearing the same request: more speaking practice between lessons. The idea is an online conversation club. Adult learners would be matched in groups of three with a tutor for 30-minute video sessions at times that fit around work.

The idea began as a testable concept stating who it was for, what would change for them and how it would work. The school then prototyped it. Two tutors, Tomasz and Leila, ran sample sessions with colleagues playing learners, and the administrator, Priya, showed a paper booking form to a few students. People understood the offer, the format worked on screen and the form was clear.

None of that answered the question that mattered most. Would busy adults turn up, week after week, to a short session at a booked time? Hannah had been offered a booking platform with automatic matching. Buying it first would mean spending money on the part of the problem that was easiest to imagine.

So the school chose a concierge MVP. Priya would match learners by hand in a spreadsheet, using level, availability and one line about each person’s goals. Sessions would run on the video tool the school already used. Reminders would go out by email the day before. Learners would pay a modest fee for a six-week block and be told plainly that a person was doing the matching during the trial.

Write the test plan before anyone joins

Before the first learner signs up, write a one-page plan. The table pairs six questions with the fictional school’s answers; it is an original planning aid, not a standard.

Plan element	Question to answer	Fictional school’s answer
Riskiest assumption	Which belief would sink the idea if wrong?	Adults will attend short booked sessions regularly
Evidence	What behaviour will count?	Attendance, rebooking, notice given for absences
Decision rule	What result means continue, adjust or stop?	Continue if two-thirds of places are used and half rebook; stop if attendance falls below half by week four; otherwise adjust
Time box	How long, and at what cost?	Six weeks, eighteen learners, staff hours counted
Minimum responsible quality	What cannot be cut?	A tutor at every session, captions available, a help contact, data deleted afterwards
Afterwards	What happens to users?	Told the outcome in week six; refund for any session the school cancels

Choose the riskiest assumption deliberately. Assumption mapping compares how much each belief matters with how much evidence supports it, so a team does not simply test whatever is easiest to build. For the school, the video technology was a known quantity. Attendance was not.

Write the decision rule while nobody knows the result. It can be rough; its job is to stop every outcome from looking encouraging afterwards. Tie it to behaviour, not opinion. A learner saying the club sounds useful is weaker evidence than the same learner rebooking with her own money.

Count staff time as well as cash, including preparation and admin. Funding the next question rather than the whole idea is a practical way to agree such a bounded commitment with whoever holds the budget.

Then look for harm before launch. In a short premortem, Hannah asked the team to imagine that the trial had gone badly for learners. They named a tutor falling ill with no cover, a learner uncomfortable with a stranger, and personal details lingering in a shared spreadsheet. Each became a safeguard: a standby tutor, a way to change group without giving a reason, and a spreadsheet with restricted access and a deletion date.

Attendance, no-shows and two surprises

The numbers here belong to the invented example; they are not research results. Eighteen learners joined six groups. Attendance was high in the first fortnight, which may partly reflect novelty. From week three, no-shows clustered in two groups. Both met on Monday evenings, and Priya had reshuffled both to balance levels.

Priya and Leila phoned learners who had missed sessions. They asked about the last missed session rather than about the club in general, as our guide to customer interviews that go beyond polite agreement recommends. Two themes came back. Monday evenings collided with overtime and childcare. And several learners had liked their first partners and felt less committed once they were moved.

The first surprise was preparation time. The cost estimate assumed a tutor simply turned up. Tomasz and Leila each spent around twenty minutes preparing every 30-minute session: choosing a topic, adapting it to mixed levels and noting phrases to revisit. A service that looked cheap per session was not.

The second surprise was that learners wanted the same partners. The imagined matching engine would have mixed people up for variety. Learners valued continuity: familiar faces, running jokes, a reason not to let the group down. Stable groups seemed to miss fewer sessions, but with six groups the team could not separate that from the time slot.

Because Priya did the matching, she saw every request, swap and excuse; an automated system launched in week one would have hidden most of it. A journey map that includes the backstage work of matching, reminders and tutor preparation would now show where the real effort sits.

Persevere, adjust or stop

In week six, the team compared the results with the rule they had written. Attendance met the threshold, carried by the stable groups. Rebooking narrowly passed: ten of the eighteen learners signed up for a second block. By the rule, the club had earned another round. But the cost estimate, which had left out preparation, no longer held.

The decision was to adjust, not to scale. In Blank’s terms, this is an iteration rather than a pivot: the offer and the learners stay the same. The school would run a second block with fixed groups, avoid Monday evenings and give tutors a shared bank of topic cards. It would not buy the matching platform. The evidence suggested that matching was not the hard part; keeping groups stable and preparing sessions efficiently were.

Stopping would also have been legitimate, and the team said so before the trial began. If attendance had fallen below half, the right move was to thank the learners, refund where promised and delete the data, not to redesign the club until it looked like a success. Our guide to evaluating ideas without killing them too early treats a clear stop as one legitimate outcome alongside investigating, revising or deferring.

The learners lived with the consequences, so they heard first. Hannah wrote to all eighteen in week six, explained what would change, offered the second block and confirmed that the details of anyone leaving would be deleted. An MVP that simply vanishes teaches its early users not to try the next thing.

Limitations: what an MVP cannot tell you

An MVP gives evidence about particular people in particular conditions over a particular time. The school’s learners were existing students who already trusted it. Early users can differ from later ones in ways that matter, a point developed in our guide to how innovations spread. Six weeks can show whether people turn up; it cannot show whether a habit lasts a year.

The evidence for the MVP idea itself is limited. Ries’ guide and the Lean Startup page describe what the method recommends; they are not independent proof that it improves outcomes. Blank’s article is an argument by one of the method’s architects. The mapping study classifies definitions rather than testing whether MVPs work, and Kniberg’s skateboard is a teaching metaphor. Treat all of them as useful discipline, not guarantees.

Finally, some products have no small, safe version that real people can use. Medical devices, safety-critical systems and services with legal consequences may need prototypes, simulations and formally supervised pilots instead. “Minimum” still means the least you need to learn, but the floor for responsible quality sits much higher.