Stop building MVPs. Build a prototype that answers one question.

I have never once seen the letters MVP make a team move faster.

I have seen them make a team build for six months and call it a test.

The term is Minimum Viable Product. Three words, three instructions, and two of them point in exactly the wrong direction at the moment they matter most.

Product tells you to build a product. So you build one: sign-up, billing, settings, an empty state, a password reset nobody will use for a year.

Viable tells you it has to stand up on its own. So the scope grows until it does.

Minimum is the only honest word in there, and it becomes the thing four people argue about in a planning meeting while the actual question goes unasked.

What the illustration was actually saying

You have seen the picture. Skateboard, scooter, bicycle, motorbike, car. It gets used to argue that each release should be usable rather than a disconnected chunk of the final thing, and that part is right.

But the reason the skateboard earns its place was never that it is a small car. It is that it answers a question the car cannot answer yet: will this person actually choose to travel this way at all? Each version exists to produce a decision.

Somewhere between that illustration and your sprint planning, "answers a question" quietly turned into "smaller version of the thing we already decided to build". Once that swap happens, the MVP stops being a test and becomes a delivery date with lower expectations.

Use the word prototype instead

Swap the noun and the behaviour follows. A prototype carries the right instruction inside it: this thing exists to answer a question, and afterwards you can throw it away without a funeral.

Keep the acronym if you like it. Minimum Viable Prototype. What changes is not the ceremony, it is three practical things:

• You start from the assumption you need to kill, not from a feature list somebody already agreed to.
• You size the artefact to the question, not to the roadmap. Some questions are answered by a landing page. Some need two days of one engineer's time.
• Nobody defends it in a review, because nobody has mistaken it for the product.

That third one does more work than the other two combined. Half the reason MVPs bloat is that the moment something is called a product, people start protecting it.

Pick the assumption before you pick the artefact

Write down what has to be true for this idea to work. Not the summary version. The specific claims: that this group of people has this problem often enough to act on it, that they will change what they currently do, that they will pay, that we can actually build it at a cost that leaves a margin.

Then rank them on two axes: how badly it hurts if we are wrong, and how little we actually know. The ones that score high on both go first. That is the whole prioritisation, and if you want a sharper way to score what you already believe, the Confidence Meter is a good place to start.

Once the assumption is named, the artefact usually picks itself:

• Does anyone want this at all? A fake door test. A page, a button, a count of who pressed it.
• Will they understand it? Clickable screens in front of five people. No backend.
• Will they pay? A real price, a real checkout, and an honest "not available yet" on the other side.
• Can we even build this? A technical spike. One engineer, two days, a written answer.
• Does the value hold up if a human does it by hand? Do it by hand, for ten customers, before you automate anything.

None of those is a product. All of them produce a decision, which is the only thing you were after.

There is a point where you do build the real thing

This is not an argument for prototyping forever. At some point the riskiest assumptions are dead and the honest next move is to build something small and real that people can use without you in the room.

That is the last step of problem-solution fit: one core problem, solved properly, for one narrow group. The difference is sequence, not size. Prototypes come first because they are how you earn the right to build. What most teams do is skip straight to a small product and then find out, expensively, which assumption they never checked.

Two questions that tell you which one you are doing

Before the work starts, ask: what would this have to show us for us to stop? If nobody in the room can answer, you are not running a test, you are building with extra steps.

Then ask: if the answer comes back no, what do we throw away? If the answer is a landing page and a week, good. If the answer is six months of code that four people are now emotionally attached to, you did not build an MVP. You built the product and hoped.

Getting this sequence right on a brand new product, with your actual assumptions on the wall rather than a generic template, is exactly what the 0 to 1 Product Development Workshop is for.