execution · standard
When is an MVP ready to ship?
When is an MVP ready to ship?
This is an execution question, not a product sense question. The interviewer is testing judgment under constraint: can you make a principled call about what ships and what doesn’t, and can you defend what you’re leaving out?
Structure a strong answer
strong
"Before I answer, I'd clarify what 'ship' means here: to five design partners under NDA, or to production? The bar is different. For any ship, I use three gates. One: can a real user complete the core job without hand-holding from me or my team? Two: will this ship actually teach us the specific thing we don't yet know, whether that's the demand assumption, the retention assumption, or whatever the riskiest bet is? Three: can we absorb being wrong, technically, reputationally, and legally? When all three are yes, we're ready to ship.
What I also do before shipping: I name the cut list out loud. 'We are not shipping X, Y, or Z because those features don't stress-test our core assumption and the cost of building them isn't justified by what they'd teach us.' Naming the cuts is more important than the checklist, because it proves the MVP is deliberate, not just unfinished.
And I pre-commit to one number before we ship: the metric and the threshold at which I'd kill it. If I can't name both in the planning doc, we're not ready regardless of the build state.
In 2026 the framing has shifted. AI tools mean a functional prototype can be standing in days, so the question has moved from 'can we build it' to 'what's the smallest ship that proves someone will pay for this and come back.' For AI products I'd add a fourth gate: an eval threshold. What error rate or hallucination rate triggers an automatic rollback before users hit it? Shipping an AI feature with no automated regression tests is the 2026 equivalent of shipping with no analytics: you've made learning impossible."
weak
"An MVP is ready when it solves the core problem for the target user and doesn't have any critical bugs. You want to ship the minimum set of features that delivers value, get feedback, and then iterate. I'd make sure the user can complete the main flow and that we have some analytics in place." This fails because it's a definition, not a decision. It doesn't name what's being cut or why. It offers no threshold, no pre-commit metric, and no signal of what failure looks like. It could apply to any product in any situation.
What interviewers are actually penalizing
Listing readiness criteria without naming what was cut is a junior signal. Senior candidates proactively surface the cut list before being asked. The implication is important: an MVP isn’t a reduced feature set, it’s a deliberate bet. You have to show you know the difference.
The three tells interviewers notice most:
- No pre-commit metric (“we’ll evaluate after we see the data” is not a plan)
- No cut list (“here’s what we’re building” with no “and here’s what we’re not building and why”)
- No failure definition (if you can’t say what would cause you to kill it, you don’t understand what you’re testing)
The 2026 shift
Dropbox’s original MVP was a demo video, not a product. It tested demand with zero engineering. That’s still the ur-example of hypothesis-first thinking, and it holds. What has changed is that the technical bar for “can we build something real” has collapsed. A functional prototype that required a full team in 2022 now takes a solo PM with AI coding tools a fraction of that time. The scarce resource is no longer engineering hours: it’s high-quality signal from real users in real contexts.
That means the question “when is it ready” has become almost entirely a question about learning efficiency, not build completeness. Minimum does not mean broken or ugly. It means ruthlessly scoped to the one job that tests viability, done extremely well, with everything else omitted.
For regulated products (healthcare, fintech), add a fourth gate before any of the above: legal and compliance sign-off and a rollback plan. For AI products, that fourth gate is an eval harness. These aren’t optional for those contexts.
The PM judgment
The interviewer wants to know whether you treat MVP as a build decision or a learning decision. The three-gate framework forces you to articulate the hypothesis, the signal, and the cost of being wrong before a single line of code ships. That’s what clears the bar.
For more on the 2026 feasibility shift and what it means for PM judgment, see feasibility is free and proving viability.