MVP Readiness Checklist: 12 Questions to Answer Before You Write Code

Most MVPs don't fail at build. They fail at a question nobody asked in week zero.

The pattern repeats. A team writes code for six weeks, ships, and then discovers it does not know what it was supposed to learn. The code works. Nobody can say what the result means.

This checklist exists to close that gap.

What "ready" means, and what it does not

MVP readiness means you know which assumption this build tests, how you will measure the result, and under what conditions you will stop.

Readiness is not a complete design, a complete team, or sufficient funding. Teams with all three have shipped useless MVPs. Readiness is a knowledge condition, not a resource condition.

Twelve questions, in four groups of three. Each either has a specific answer or it does not. "Roughly" counts as no.

Problem clarity — three questions

1. How is this problem solved today? If the answer is "it isn't", you have not looked hard enough. People always have a clumsy workaround, and that workaround is your real competitor — not the similar product.
2. Who currently spends money or time on this? Name them. If you cannot name anyone, you have a hypothesis, not a problem.
3. If this product is never built, what happens to them? If the answer is "not much", the problem is real but not urgent — and lack of urgency is what kills MVPs.

User access — three questions

4. Can you talk to ten people in the target audience this week? Not ten acquaintances. Ten who actually have the problem.
5. Who is the first real user, and why do they say yes? One specific person, one specific motivation.
6. When the product is ready, how does it reach them? If the answer is "we'll do marketing", you have no distribution path.

Question four stops more projects than any other, and it is the best question on the list. If reaching ten prospects takes a week, reaching a thousand takes a year, and your growth model does not exist yet.

Scope discipline — three questions

7. What is the smallest thing that tests the core assumption? If the answer runs longer than one sentence, it is not small yet.
8. What are you deliberately not building? Write the list. That list is the contract that protects you in week four.
9. Which part can a human do by hand? Data entry, matching, approval — most of these can be manual in version one without damaging what you learn.

Metrics and the stop rule — three questions

10. What number shows this worked? One number, not a dashboard.
11. What number shows it did not? Write this before you ship.
12. How much time and money are you willing to spend to see that number? Set the ceiling now.

Question eleven is the most common blank. Teams define success and skip failure, so no result ever leads to a stop — an optimistic reading is always available.

Scoring: what a weak answer costs later

A working rule: if two of three questions in a group have no clear answer, close that group before any code is written.

How to run this as a 90-minute session

A checklist that becomes a document does not get read. What works is a short session with one hard rule.

Three people maximum: whoever builds the product, whoever talks to customers, and one outsider with no stake in the project continuing. The third is the important one. A team assessing itself always finds vague answers acceptable.

The hard rule: five minutes per question. If five minutes does not produce one clear sentence, the answer is recorded as "we don't have it" and the discussion ends. Working toward an answer inside the session is precisely where teams substitute assumption for fact.

The output is one page: twelve questions, twelve answers or dashes, and a research task for each dash. More than four dashes and it is not time to write code.

Why twelve questions and not forty

Longer lists exist, and most of them are useless, because a forty-question checklist becomes ceremony. The team ticks boxes to get past it.

These twelve were chosen because each covers a distinct failure mode and none overlaps another. If you add a question, you should be able to name the uncovered failure it closes. If you cannot, leave it out.

A worked example: the team without question eleven

Two founders built a scheduling tool for small clinics. Seven weeks of work, a clean product, three pilot clinics on free accounts.

Two months in: all three still used it, none would pay. The team read this as a signal to add features and built for three more months.

Features were not the problem. They had defined success as "continued usage", which is a reasonable metric for a free product and says nothing about willingness to pay. Had question eleven been asked — what number shows this did not work? — the answer would probably have been "no clinic agrees to pay after eight weeks". That one rule would have saved five months.

The trade-off this checklist imposes

Answering twelve questions takes between three days and two weeks, and it feels bad, because it does not feel like work. Writing code feels like progress. Answering question eleven does not.

Against that: the most you lose is two weeks. The most an assumption-free MVP loses is a quarter.

What if I don't know some of the answers?

Not knowing is fine. Not knowing and starting anyway is the problem. Turn each blank into a one-day research task.

Does this apply to an internal product?

Yes, and the second group matters more, not less. Internal products are assumed to have guaranteed users, while internal adoption is just as fragile.

How often should this be revisited?

On every material change of assumption. Week-zero answers stop being valid once you have watched thirty real users.

Closing

An MVP is not a small product. It is an experiment that happens to be shaped like one. If you cannot say what it tests, you are just building software.

If you want these twelve questions run against your own idea with an outside read, that is exactly what an MVP readiness check does.