MVP vs Prototype vs Increment
The three words get used as though they were synonyms for early, and they describe three different pieces of work with three different success conditions. The confusion is not academic. A team that builds one and is judged against another spends months defending work that did exactly what it was supposed to do.
Section 5 of the PMBOK® Guide Eighth Edition includes the delivery techniques these belong to, and the practical way to keep them apart is to ask what each one is built to establish.
Three different questions
A prototype asks whether something can work, or whether people understand it. It is built to answer a question and then be discarded, which is what licenses it to cut every corner that is not relevant to the question: no error handling, no security, no performance, no support. Its success condition is that the team learns something specific, and a prototype that proves an approach will not work has succeeded.
A minimum viable product asks whether the value is real. It goes to actual users doing actual work, which means it has to function, be supported and be measured, and it is deliberately narrow: the smallest thing that can test whether the benefit appears. What makes it minimum is the scope of the hypothesis, and what makes it viable is that somebody can genuinely use it without being harmed by the experience.
An increment asks nothing. It is a working slice of the eventual product, built to production standard, that adds capability and stays. Its success condition is that value is delivered now and kept, and it carries every obligation of the finished thing, because it is part of the finished thing.
What mislabelling costs
The prototype that goes live. Somebody sees a working demonstration, the pressure to realise the benefit is real, and a thing built to answer a question becomes the thing the business depends on. What follows is predictable: the shortcuts that were correct for a prototype become defects in production, and the team that built it honestly gets the blame for the decision to ship it. The protection is a stated intention before anybody builds: this is being built to answer this question and will be thrown away, and here is what a production version would cost.
The minimum viable product with no measurement. Where an MVP is released without a hypothesis and without anything to measure it against, it is a small first version with a fashionable label, and the organisation gets the disadvantages of a narrow release without the learning that justified it. The test is whether anybody can say, before it goes out, what result would cause the project to stop.
A client portal that was never meant to survive
A professional services firm was designing a new way for clients to submit and track cases. The team built a prototype counter and workflow to test whether clients would complete the submission unaided: foam board and tape for the physical parts, a real card reader taped on to make the payment step feel genuine, and a workflow behind it that handled exactly the happy path.
It tested well. Nine of twelve clients completed the submission without help, which was the question and the answer, and the prototype had done its job the moment that number existed.
What happened next is the common part. A partner saw the demonstration, a large client asked when they could use it, and within six weeks the prototype workflow was handling live submissions for two offices. It had no reconciliation, no error handling for a failed payment, and no way to correct a submission once made. The first failed payment took four people two days to resolve manually, and by the end of the quarter there were sixty-one of them.
The recovery cost about three times what building it properly would have cost at the start, mostly because the data created by the prototype had to be migrated into the real system and much of it could not be reconciled. What the firm changed afterwards was a single sentence in its own governance: anything built to answer a question is labelled at the outset with the date it will be switched off, and switching it on for a client requires a decision by somebody who has seen the cost of making it real.
Deciding which you need
If the uncertainty is about feasibility, build a prototype. Can this integration work, will the material hold, can people follow this flow. Build the smallest thing that answers it, and agree what will be done with it afterwards before starting.
If the uncertainty is about desirability or value, build a minimum viable product. Will people use it, does the benefit appear, is it worth doing at scale. Accept the cost of making it real enough to use, state the hypothesis, and decide in advance what result would stop the work.
If there is no material uncertainty, build an increment. Where the organisation knows the thing is wanted and knows it can be built, discovery language adds ceremony and delays value, and the honest answer is to deliver a working slice to production standard and keep going.
For a PMP® candidate, the reading that helps is that these are separated by their success conditions, so a scenario where a pilot is being pressed into service is describing a decision about production readiness rather than a delivery question. A response that hardens the prototype after the fact accepts a cost nobody has priced. Situations where the experiment succeeded and the organisation wants to keep it are among the more interesting ones a structured PMP exam preparation course poses.
Check the label against the intention. For whatever early thing your project is currently building, write down what question it answers, who will use it, and what happens to it in six months. If those three answers disagree with each other, the label is doing work that a conversation should be doing.
Interested in going further?
The moment a successful prototype meets a keen stakeholder is one of the more consequential and least prepared-for conversations in delivery. Omega's PMP® Exam Preparation works through discovery and delivery decisions where the pressure runs one way.
Prototyping, incremental delivery and the techniques around them appear in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A180: Facilitation Techniques for Difficult Project Conversations
A191: Product Backlog vs Sprint Backlog
A192: Sprint Review vs Retrospective
A187: Retrospectives That Lead to Change
A178: SWOT Analysis in Project Management
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
