The task
You have a product idea and a 30-feature list in your head (some of them 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 excellent 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. 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.
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 leverage (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 leverage (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" — 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 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 — manual API-key paste is enough for first 50; (2) cut the inline docs panel — link to 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 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?”
Common mistakes
- MVP that “does everything badly” — beats 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 — MVP for everyone ships for no one; pick one persona for the scope doc
FAQ
- What if my audience is “everyone”?: Pick one. 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 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.
- Should I share the OUT list publicly?: Yes if it builds credibility (“we’re not building X yet — here’s why”). Skip 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