MVP Thinking
The smallest version that proves the core idea — for the store, products, cart, order, payment — and nothing that does not change whether the idea is proven. Not the product with features removed; the product with the proof left in.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
What is the smallest version of this that would tell me whether the core idea works, and how do I stop it growing into the whole product?
The founder's feature list has recommendations, coupons, wishlists, multi-warehouse stock and a search box on it, and every item has a sentence starting with "we obviously need". I know I cannot build all of it first. I do not know how to say which part is first without it sounding like I am cutting their product.
Take the full feature list and estimate it, then trim from the bottom until it fits the deadline. It feels responsible — nothing is dropped, only postponed — and it produces a plan with dates on it, which is what everyone in the room wanted to see.
Trimming from the bottom keeps whatever was written down first, and the list was written in the order features came to mind, not in the order they prove anything. "Recommendations" survives because it was on line three; "what happens when payment fails" was never on the list at all.
- Trimming from the bottom keeps whatever was written down first, and the list was written in the order features came to mind, not in the order they prove anything. "Recommendations" survives because it was on line three; "what happens when payment fails" was never on the list at all.
- The plan has dates and no verdict. Nothing in it says what would be learned at the end: whether customers will pay at all, whether the checkout works, whether the founder's idea was the shop or the recommendations. A schedule is motion; a proof is progress.
- Every feature stays coupled to every other. Search needs the catalog, coupons need checkout, recommendations need order history — so nothing is finished until everything is, and the first real customer arrives at the end, when there is no time left to react to what they do.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Write down the core idea as a claim that could be false: "people will pay for these products through this site". An MVP is the smallest thing that tests that claim; every feature is judged by whether the claim can be tested without it. This is what makes "just ship an MVP" falsifiable — an MVP that cannot fail the test is not one.
- Find the single end-to-end path the claim needs. For the store it is browse → add to cart → checkout → order created → paid. The path is V1. Anything not on it is a candidate for later, however loudly it was requested.
- For each thing on the path, ask whether it can be *simplified* without changing what the path proves. One warehouse, one currency, filter-by-name instead of search, a fixed shipping fee — each of these keeps the proof intact. Then ask what on the path *cannot* be simplified away, because it is what the claim is about: money moving correctly, and an order that exists afterwards (What Cannot Be Simplified).
- Keep the riskiest part on the path, not off it. If the founder's idea is really "our recommendations will sell more", then recommendations are the core and a plain shop proves nothing. The MVP is the smallest test of *this* idea, and the first job is to know which idea that is (What Am I Actually Trying to Achieve?).
The path, decomposed into what must work
The reflex decomposes the product by feature list. The move decomposes it by the path that tests the claim, and every leaf carries the observation that would show it works — which is also what makes the leaf small enough to build. Nothing here is a heading; a leaf you cannot test is a feature you have not thought about yet.
Notice what is absent. Search, coupons, recommendations and stock across warehouses are not children of any node, because none of them changes whether a customer can buy a product. Payment is a child, and it is the deepest one, because the claim is about money.
- ├See products— nothing can be bought that cannot be seen
- └List and filter by nametestable Products in the database appear on the page; typing part of a name narrows the list; an empty result says so.
- └Product page with price and stocktestable The page shows the current price and whether the product can be bought; a sold-out product cannot be added.
- ├Collect a purchase— the customer must be able to say what they want
- └Cart with quantitiestestable Add, change quantity, remove; the total equals the sum of line prices at the current catalog price.
- └Address and fixed shipping feetestable A checkout with a missing address is rejected with a reason; the fee is added once.
- ├Turn it into an order and take money— this is the claim
- └Create the order from the carttestable Exactly one order exists per completed checkout, with the items and prices the customer saw.
- └Take payment in test modetestable A successful test payment marks the order paid; a declined one leaves it unpaid and tells the customer; a repeated click does not charge twice.
- └Confirmation the customer can find againtestable After paying, the customer sees the order and can return to it later; an email is optional in V1 if the page exists.
Every leaf could be built and checked this week, and together they are the whole path. A stakeholder can argue with the tree — "search must be in" — and the argument is about what the claim needs, which is the right argument.
"We need X in V1", climbed down
Most features on the founder's list arrive as needs. The why ladder turns a need into the requirement underneath it, and then asks whether V1 has to meet that requirement to test the claim. Often the answer is a smaller thing; sometimes it is "yes, this is the claim", which is equally useful to know.
“We need product recommendations in V1.”
- ↓Why do we need recommendations? So customers discover more products and buy more per visit.
- ↓Why does V1 need to raise basket size? Because the business case assumes an average basket bigger than one item.
- ↓Why must that be proven before anyone has bought anything? It does not; it must be proven before we scale marketing spend, which comes after we know people buy at all.
the claim was right when The claim being tested is "our recommendations are what will make people buy here" — a shopping-discovery product rather than a shop. Then recommendations are the path, and a plain catalog proves nothing about the idea.
One order for building it, and the other
The tree does not say what to build first. A defensible order walks the path in the direction a customer walks it, so that there is always a working store up to some step — but the alternative is just as defensible when the risk sits at the end of the path.
- 1Product list and product page from a real database
because The walking skeleton: every layer connected with the least content, and the first thing a customer sees.
- 2Cart and checkout up to "order created", without payment
because The path is complete except for money, and can be exercised end to end by someone other than you.
- 3Payment in test mode, including declined and repeated
because The claim is about money; the three outcomes that matter are tested before anything decorative exists.
- 4Confirmation page, then a real payment with a real card, once
because The MVP is not done until one real order has happened through it.
How to do it
Most important first.
- Write the claim in one sentence and get the person who asked for the product to agree it is the claim. If they say "no, the point is X", you have just saved the build (Problem Framing).
- Draw the shortest path that tests the claim, as actions a user takes. Everything on the path is V1; write everything else in a "not V1" list with the reason it is not (What Is Not V1).
- For each V1 step, name the simplification and the assumption it rests on — "one warehouse, so stock is a single number" — so that when the assumption breaks, the design change is already located (Making Assumptions Explicit).
- Name what must be correct even in V1. Money, identity, and data that cannot be recreated are not simplified; they are done properly or done by someone else (MVP vs Bad Prototype).
- Decide what you will observe when the MVP is in front of a user, before building it. "Did anyone complete a payment?" is an observation; "did they like it?" is not (Experiment Design).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The claim: "customers will buy these products online from us". Path: list products → product page → add to cart → checkout with address → pay → order confirmation. V1 is exactly those six screens and the data behind them. Simplified: one warehouse, one currency, fixed shipping, filter by name. Not simplified: the payment either happens or it does not, and an order exists exactly when it did.
- Not V1, with reasons: recommendations (the claim is not about them), coupons (a pricing experiment that needs a baseline first), multi-warehouse (an assumption written down, not a feature), microservices and a message queue (there is no load to justify them and nothing to prove with them), search (filter by name tests the same customer action), personalisation (needs history that does not exist yet).
- The same move on the chat app: claim, "people will message each other here instead of elsewhere". Path: sign in → open a conversation → send a message → the other person sees it. Realtime delivery is on the path, because a chat that needs a refresh does not test the claim; read receipts, typing indicators and file attachments are not.
How you know it worked
What now exists that did not before, and what question you can now ask.
- You can say, in one sentence, what would make the MVP a failure — and it is about the idea, not the code.
- The "not V1" list is longer than the V1 list, and every item on it has a reason someone else could disagree with.
- The riskiest part of the idea is inside V1. If it is not, you have built a demo of the easy parts.
- The first real user can complete the path, and what they did next is something you can observe.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What is the claim this product makes, in one sentence that could turn out to be false?
- ?What is the shortest path a user takes that tests that claim end to end?
- ?For each step on the path, what can I simplify without changing what the path proves — and what cannot be simplified because it is the proof?
- ?Is the riskiest part of the idea inside the smallest version, or have I cut it out because it was hard?
- ?What will I observe when a real user reaches the end of the path?
What can go wrong
- The MVP omits the risky part because it was hard. A store that lets customers browse and add to cart but "will add payment next sprint" has proven that people can browse, which nobody doubted. The proof was the hard part.
- The path is minimal but the build is not: V1 ships with the queue, the microservices and the admin dashboard "since we will need them". The scope was cut and the architecture was not, and the architecture took the time.
- Minimal becomes permanent. The one-warehouse assumption was never written down, so when the second warehouse arrives it is discovered by a customer with a missing parcel rather than by a developer reading a list.
- The MVP is used to justify skipping correctness: a checkout that double-charges "because it is only an MVP" is not testing the idea, it is testing customers' patience.
- A real MVP is smaller than the stakeholders wanted and the conversation about what is not in it happens now, in front of them, instead of later, quietly.
- Simplifications are debt with a known creditor: one warehouse becomes two, one currency becomes several, and each was cheap to assume and will cost something to unassume.
- Keeping the risky part in makes V1 slower to reach than a demo of the easy parts would be. That is the cost of it meaning something.
- "MVP means small." It means *minimum for the proof*. If the idea can only be tested with realtime delivery, then realtime is in the MVP, and the MVP is not small.
- "MVP means rough." A rough MVP that loses orders proves the wrong thing. Simplify scope, not correctness; the difference is the next two lessons.
- "Once we know the MVP works, we scale it up." Usually you learn something that changes the path, and the next version is a different smallest thing, not a bigger one (Growing From the MVP).
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe claim-and-path move applies to any product or internal tool; for a library the claim is "callers can do X with this API" and the path is one call from a real caller.
- CONTESTEDThe strongest case against MVP purism: an MVP that leaves out the risky part proves nothing, and a great deal of "MVP" practice is exactly that — a demo of the easy parts, shipped to feel fast, teaching only that browsing works. Practitioners who reject the term argue that a product whose whole value is in the hard part (a marketplace, a recommendation engine, a realtime system) has no honest small version, and that "ship the MVP" then becomes permission to avoid the question. The lesson's answer is that the risky part must be inside V1 — but that concedes the critics' point that many MVPs are not MVPs.
- STAGE-SPECIFICOn a greenfield product the MVP is the first thing built. Inside an existing system, the same move applies to a feature: the smallest change that tests whether the feature is wanted, which is often a link that counts clicks before the feature exists at all.
- ILLUSTRATIVEThe store, its founder and the feature list are invented to show the shape of the move; any quantities are for the argument, not measurements.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "Don't delegate understanding" at /manifesto applies to scope as much as to code: an MVP whose scope was decided by a template is a feature list somebody else wrote.