TL;DR
Paste your one-sentence idea, your single most-cited user pain (verbatim), your honest timebox, and your first-50-users plan into the prompt below. Force the model to return a short IN list (5-7), a long OUT list (15-20, each with a reason), at least 3 Wizard-of-Oz fakes, a measurable definition of done, and a cut order. The whole doc fits on one page. Claude Opus 4.7 or Sonnet 4.6, GPT-5.5, and Gemini 3.1 Pro all handle this well; use the cheaper workhorse tier unless you are pasting a long interview transcript. The single biggest mistake the model makes is a symmetric IN/OUT list — fix it by demanding the OUT list be 3x longer than IN.
The task
You have a product idea and a 30-feature list in your head — some in a Notion doc, some scribbled in a notebook, two of them mentioned by your co-founder on Slack last Tuesday. You want to ship in 6 weeks. You know from the last project that without a written scope you’ll add “just one more thing” three times, slip 4 weeks, and end up with an MVP that does six things badly. You need a 1-page scope doc: IN list (max 5-7), OUT list with reasons, what you’ll fake manually for the first 50 users, a measurable definition of done, and a cut order for when you fall behind.
Where AI helps — and where it does not
AI is good at applying MVP scoping principles (one core job, no settings, minimal polish), proposing a defensible cut list, and writing the OUT list with reasons so future-you doesn’t relitigate. It’s also good at proposing Wizard-of-Oz alternatives — manual versions of features that can wait. The Wizard-of-Oz MVP, named after the man behind the curtain, fakes the backend by hand while the front looks finished; Zappos validated online shoe sales this way, buying shoes from local stores as orders came in.
What AI cannot do: know which feature your specific audience needs first. Feed it the single most-cited user-pain quote from your interviews, not your guess at what’s important. Without that, AI defaults to a generic “first MVP” template that may build features your real users don’t care about.
The named failure mode: the symmetric IN/OUT list. AI gives you 7 IN features and 7 OUT features. Then you negotiate the OUT items back in over the next 6 weeks. The right shape is short IN (3-5), long OUT (15-20), with reasons that survive future-you’s attempts to relitigate. The cure is to force a reason per OUT item and a cut order on the IN list.
Which AI model to use (as of June 2026)
Scoping a one-page doc is a reasoning task with a short output, so any current flagship is fine. Pick based on what you’re pasting in and what you already pay for:
| Model | Plan / price (as of June 2026) | Context | Best for this job |
|---|---|---|---|
| Claude Sonnet 4.6 | Free (limited) or Pro $20/mo | 1M tokens | Default workhorse; crisp, opinionated cut lists |
| Claude Opus 4.7 | Max $100/mo (5x) | 1M tokens | When you paste long transcripts and want the sharpest reasoning |
| GPT-5.5 | Plus $20/mo (Thinking mode) | ~320 pages in-app on Plus | Solid all-rounder; pick “Thinking” for the scope prompt |
| Gemini 3.1 Pro | Google AI Pro $19.99/mo | 1M tokens | Cheapest 1M context if you dump many interview notes |
Practical rule: for a single idea plus one quoted pain, the $20 workhorse tier (Sonnet 4.6, GPT-5.5 Plus, or Gemini 3.1 Pro) is enough. Only reach for Opus 4.7 or a 1M-context paste when you’re feeding a full interview transcript and want the model to find the real pain itself rather than trusting your summary. Note that GPT-5.5’s in-app context on Plus is roughly 320 pages; the full 1M-token window needs the $200 Pro tier or the API.
What to feed the AI
- Product idea in one sentence — the value, not the technology
- The single most-cited user pain from your interviews (quoted verbatim, not paraphrased)
- The honest timebox — weeks until ship, with your actual capacity (not aspirational)
- The first 50 users — who are they, where do they come from, how do you reach them?
- What you’ve already built or can reuse (existing API, design system, accounts)
- 2-3 features your co-founder, advisor, or instinct keeps pushing for — so AI can argue them in or out
- The “what does success look like at week 6” metric (signups, weekly active, retention, conversion)
- Your honest skill gaps — what would slow you down most if you tried to build it
Copy-ready prompt
Scope a 1-page MVP doc.
Product idea (one sentence, value not technology): [paste]
Top user pain quoted from interview: [paste verbatim]
Honest timebox: [weeks until ship, real capacity not aspirational]
First 50 users — who they are and how I reach them: [paste]
What I can reuse (existing): [existing API, design system, accounts]
Features I'm tempted to add but unsure about: [2-3 candidates]
Success metric at ship + 4 weeks: [one measurable signal]
My skill gaps: [what would slow me down most]
Return:
1) MVP definition — the single user job this MVP does. One sentence. If two jobs sneak in, pick the higher-leverage one.
2) IN list — features required for that single job. 5-7 max. Each with a 1-line reason WHY it's necessary for the single job.
3) OUT list — features people will ask for but you won't build in this MVP. 15-20 items. Each with a 1-line reason WHY it's deferred (not "later" — an actual reason: "matters at retention, not activation").
4) Wizard-of-Oz candidates — features that can be faked manually for the first 50 users. Each with the manual process.
5) Definition of done — measurable, not "looks good." Quantify the success metric and the user behavior that proves it.
6) Cut order — if I fall behind, IN list items get cut in this order. Each ranked with the risk-of-cut justification.
Rules:
- IN list is short (max 7). OUT list is long (15+).
- Every OUT item has a reason that future-me cannot easily relitigate.
- At least 3 Wizard-of-Oz candidates.
- Cut order is mandatory — you will fall behind.Shorter variant — single-sentence scope test
Stress-test this MVP scope in one paragraph.
MVP definition: [paste]
IN list: [paste]
For each IN item, tell me: is it necessary for the MVP definition or is it scope creep? Cut anything that isn't strictly necessary. Output: trimmed IN list with 1-line justification per item.Sample output
A useful MVP definition: “Help solo founders decide in 60 seconds whether to switch from Stripe + their current billing tool to ours, and complete a test webhook within 5 minutes of signup.” That beats “Help founders manage billing.” The first is one job and is testable; the second is a product.
A useful OUT line: “User dashboard — OUT. Reason: the MVP job is ‘decide whether to switch’, not ‘manage subscriptions over time.’ Dashboards matter at retention, not activation. Wizard-of-Oz alternative: for the first 50 users, email them a manually-built screenshot weekly. Defer the real dashboard until we have 200 paying users.”
A useful IN line: “Webhook test sandbox — IN. Reason: the user can’t decide whether to switch without seeing the webhook fire successfully with their own event payload. Without this, the MVP doesn’t deliver the single job.”
A useful cut order: “Cut order if I fall behind: (1) cut the OAuth provider beyond Stripe — a manual API-key paste is enough for the first 50; (2) cut the inline docs panel — link to an external docs page instead; (3) cut the variant pricing display — pick the lowest tier and hide the rest until v2. Each cut named with what we’d lose.”
A useful Wizard-of-Oz: “Customer onboarding emails — fake it. For the first 50 signups, I personally send a welcome email within 2 hours and book a 15-min call. This is faster to build, surfaces the questions to actually answer, and the friction it creates filters out non-serious signups.”
How to refine
- Force IN to 5 or fewer: “Cut the IN list to 5 items. Name the 2 most likely to be cut if I slip 1 week. If you cannot get to 5, pick the 5 that most directly serve the MVP definition and demote the rest to OUT.”
- Lengthen OUT, deepen reasons: “Add 5 more items to OUT. Each must have a reason that survives my future attempt to relitigate. ‘Later’ is not a reason; ‘matters at retention, not activation’ is.”
- Find Wizard-of-Oz candidates: “What are the 3 most expensive IN items to build? For each, propose a manual fake that works for the first 50 users.”
- Pressure-test the definition of done: “Replace ‘looks good’ or ‘feels right’ with a measurable user behavior. ‘X% of signups complete the webhook test within 5 minutes’ beats ‘onboarding feels smooth.’”
- Stress-test the cut order: “If I had to cut 2 IN items today instead of week 5, which 2 would you cut and what would the MVP still prove?”
Scoring the cut: a quick RICE pass
When the model hands back an IN list you still can’t choose between, run a RICE pass — Reach x Impact x Confidence / Effort, the Intercom-built scoring model. Ask the model to score each IN item 1-5 on Reach, Impact, and Confidence, divide by an Effort estimate in person-days, and rank. Because Effort is the denominator, expensive features fall fast, which usually exposes a cheaper Wizard-of-Oz version of the same value. A common rule of thumb: must-have items should eat no more than ~60% of your effort budget, leaving slack for the inevitable slip.
Common mistakes
- MVP that “does everything badly” loses to the MVP that does one thing well at attracting first users
- No definition of done — scope creeps as ship date approaches because nobody can say what “done” is
- Skipping the cut order — when you fall behind (you will), you have no plan, so you cut at random
- OUT list with no reasons — six weeks in, someone proposes a deferred item and the OUT decision can’t defend itself
- Letting AI pick the user pain — feed it the verbatim quote, not your interpretation
- Building the OUT list to placate stakeholders (“don’t worry, that’s in v2”) — v2 is the OUT list with a different label
- Adding features the team is excited about but the user pain doesn’t require — excitement is not signal
- Defining “the user” as everyone — an MVP for everyone ships for no one; pick one persona for the scope doc
FAQ
- What if my audience is “everyone”? Pick one. An MVP for everyone ships for no one. The scope doc names one specific persona (their job, their context, their substitute solution today). You can broaden later — but only after the first persona’s MVP works.
- How polished should the MVP be? Polished enough that the user understands the value in 30 seconds without a tutorial. Beyond that is over-investment until you have a retention signal. The single-job MVP can be ugly; it cannot be confusing.
- What if I have multiple user pains tied for top? Pick one for this MVP. Multi-pain MVPs become multi-job products and the scope unravels. Ship the single-pain MVP, get signal, then pick the second pain for v2.
- My co-founder keeps pushing for one more feature. How do I use the doc? Add the feature to OUT with the reason. If the co-founder disagrees with the reason, that’s the conversation — at the reason level, not the feature level. The doc converts feature debates into reason debates, which are faster.
- Which model should I run the prompt in? Any $20-tier flagship as of June 2026 — Claude Sonnet 4.6, GPT-5.5 (Thinking), or Gemini 3.1 Pro. Reach for Claude Opus 4.7 or a 1M-token context only when you paste a full interview transcript and want the model to find the pain itself.
- Should I share the OUT list publicly? Yes if it builds credibility (“we’re not building X yet — here’s why”). Skip it if competitors would weaponize it. Founders often over-protect; the OUT list is rarely the secret.
Related
- AI feature prioritization
- AI user persona
- MVP Scope Prompts for Cutting Down to What Validates
- AI Roadmap Planning
- Customer Discovery Questions AI
- Landing Page Section Ideas AI
Tags: #AI writing #Product #Workflow #MVP