MVPs fail in two ways and you can usually spot which one from the backlog alone: too many features (because everything “feels needed”), and no testable hypothesis underneath them (so even shipping the whole thing wouldn’t tell you what you learned). These prompts force a written “we believe X will do Y when given Z” before scoping, a brutal cut to 30% of the backlog, a Wizard-of-Oz or smoke-test alternative when it’s cheaper than building, and a 6-week time-box with explicit kill / pivot / double-down criteria. Pair with the jobs-to-be-done prompts to lock the underlying job before you cut.
Best for
- Indie maker MVPs
- Internal MVPs at companies
- Pre-funded startup MVPs
- Validating a new feature in an existing product
- PoC for B2B contracts
1. Hypothesis-first MVP scoping
I want to build an MVP for {idea}. Before scoping, write the testable hypothesis: "We believe {persona} will {behavior} when given {value}. We will know this is true when {metric}." Then scope only what tests this hypothesis.2. Brutal-cut MVP backlog
Below: my current MVP backlog of {N} features. For each, mark "core hypothesis test" / "support" / "cut". Justify cuts. The final MVP should have ≤30% of the original list.
{paste}3. Time-boxed MVP plan
For MVP {paste}, build a time-boxed plan: weeks 1-2 (build), 3 (launch), 4-5 (learn), 6 (kill / pivot / continue decision). Output: deliverables per week, the metric checked at week 6, the kill criterion.4. Manual / Wizard-of-Oz scoping
For idea {paste}, design a Wizard-of-Oz MVP that fakes the hardest tech with human labor. Output: what looks automated, what is manual, the costs, the limits of validation it provides.5. No-code MVP scope
For idea {paste}, scope a no-code MVP using {tools — Bubble / Webflow / Airtable / Zapier}. Output: each feature → the no-code component, what is fragile, where it will break at scale.6. MVP smoke-test landing page
Instead of building an MVP, design a smoke-test: a landing page with a fake-buy button. Output: page sections, the metric (sign-ups / clicks-to-buy / waitlist), the threshold that justifies building.7. Single-user MVP
For idea {paste}, scope a "single-user MVP": works for exactly 1 named user. Output: who that user is, what we hand-craft for them, what we learn, when we expand to 5 users.8. Build-only-the-spike
My MVP has 1 risky technical assumption: {paste}. Scope a tech-spike-only MVP that tests just that assumption. Strip everything else. Output the spike scope and the go/no-go threshold.9. MVP cost / time estimator
Below is my MVP scope. Estimate: build time (solo dev), build cost (with contractors), the single biggest unknown that could 2x the estimate, and the cheapest way to de-risk that unknown first.
{paste}10. MVP kill criteria
For MVP {paste}, define the kill criteria: which metric, which threshold, which timeframe. Output: the explicit "kill it" condition, the "pivot here" condition, the "double down" condition.11. MVP → product roadmap bridge
My MVP just validated. Below: what we learned. Design the 90-day post-MVP roadmap: what features deepen the validated value, what we deprioritize, what we say no to. Be explicit about scope discipline.
{paste}12. MVP post-mortem
My MVP failed validation. Below: what I shipped + the data. Help me extract: was the hypothesis wrong, was the execution wrong, was the audience wrong, was the metric wrong. Output a pivot vs kill recommendation.
{paste}Common mistakes
- No testable hypothesis behind the MVP — shipping it teaches you nothing falsifiable
- Building everything that “feels needed” instead of cutting to the assumption that matters
- No kill criteria, so a flat MVP gets quietly extended for another quarter
- Treating MVP as v1 of the product instead of a single experiment
- Skipping cheaper alternatives (smoke-test landing page, Wizard-of-Oz, single-user) and going straight to build
- Using vanity metrics (signups, page views) instead of the behavior the hypothesis predicts