Scopes a v1 from a framed problem and discovery evidence — what v1 does, what it explicitly doesn't, a cut list where every cut has a reason, a cost and a revisit trigger, and an adoption plan for getting busy users off their current channel. Invites and handles the PM's pushback.
Use when deciding what goes in an MVP, writing a cut list, or when someone asks "what's the smallest thing we can ship that solves this".
This is the step where the PM argues with the model. The first scope any model proposes includes too much: it adds the dashboard, the AI assistant and the integrations because they appeared somewhere in the evidence. A useful v1 is defined as much by what it refuses to do, and every refusal needs a reason someone can disagree with.
Inputs
out/04-problem.md and the chosen framing from out/decisions.md (required)
context/brief.md constraints: team, time, budget, data and integrations that exist or don't. If constraints are missing, ask once: "What can the team build in the next 4–6 weeks, and what data or integrations do we definitely not have?"
Every Parked ideas line from earlier outputs
Process
1. Build the candidate list
Collect every possible feature from:
Each severity-2 and severity-3 pain (one or more candidates per pain).
Each collision's "what v1 must choose".
Workflow-map gaps (unowned steps, relays).
Parked ideas.
The obvious features stakeholders will expect, even if the evidence is weak: the brief's original solution, a dashboard, an AI chat assistant, integrations, notifications, analytics. They go on the list so they get cut on the record rather than coming back later.
For each candidate: one line, which persona it serves, evidence IDs (or "no evidence: stakeholder expectation").
2. Apply the scoping rules
A candidate is in v1 only if it passes all of these:
Serves the framed problem, not just a pain nearby.
Has evidence: at least one severity-2+ pain or a top collision behind it.
Replaces a workaround someone described, or removes a relay step. If nobody would stop doing anything, it's not v1.
Lives where users already are. If the extracts contain "no new logins" or a failed previous attempt at a separate tool, v1's entry point must be inside the existing channel (a link in the message they already get, a reply that works by email). A separate destination needs a reason that beats that evidence.
Doesn't depend on data or integrations the team doesn't have.
Fits the constraint (team × time).
Where a top collision forces a choice, make it, and write which side v1 favors and why.
3. Write v1
One sentence: who does what, where, and what changes for them.
In scope: 3 to 6 capabilities, each with persona served, evidence IDs, and the workaround or relay it removes.
v1 does not: explicit list, in plain sentences. "v1 does not show performance data." "v1 does not replace the account manager's message."
4. Write the cut list
Every candidate not in v1 goes here. The cut list should be at least as long as the in-scope list; if it isn't, you haven't considered enough.
| Feature | Why it was considered [IDs] | Why it's cut (which rule) | What we lose by cutting it | Revisit when |
"What we lose" must be honest. If the honest answer is "a client who wanted it will be disappointed", write that. "Revisit when" is a trigger, not a date: "when we have read access to client ad accounts", "when 3+ clients ask unprompted".
5. Adoption plan
Current channel: where each persona does this today.
Why they'd switch, in one sentence per persona, tied to a workaround they'd drop.
Entry point: exactly how they arrive at v1 the first time (e.g. a WhatsApp message they already get carries the link or the buttons).
When they don't use it: what happens to the work if a user ignores v1 entirely. v1 must degrade to today's process, not break it. Who does what in that case.
Adoption signal: the one behavior that tells you it's working within the first two weeks.
6. Assumptions
List every assumption v1 depends on, one line each, typed as desirability (will they want it), usability (can they do it), feasibility (can we build it), viability (does it make sense for the business). Step 6 ranks these.
7. Argue with me
End with the three scope calls you're least sure about, each with the strongest argument for the opposite choice. This invites the pushback the PM should be giving.
Handling pushback
When the PM disagrees ("cut the dashboard, we have no data", "you're missing the sous-chef who receives on her days off"):
Make the change.
Re-run the scoping rules on anything affected. A cut can pull something else in, or push it out.
Show a short diff: moved in, moved out, changed. Then the revised table.
Log the pushback and the change in out/decisions.md.
Don't defend the original scope beyond one sentence. If you think the PM is wrong, say so once with evidence, then do what they decided.
Output: out/05-scope.md
# v1 scope
## v1 in one sentence
## In scope
| Capability | Serves | Evidence [IDs] | Removes workaround / relay |
## v1 does not
## Cut list
| Feature | Considered because [IDs] | Cut because | What we lose | Revisit when |
## Collisions decided
| Collision | v1 favors | Why |
## Adoption plan
## Assumptions
| # | Assumption | Type |
## Argue with me
Stop here: show the results and ask how to continue
This step always ends with a stop, including when it runs inside a full pipeline or the user said "run everything". Never start the next step, and never apply a decision, until the user answers.
Show the results in the chat, not only the file path: v1 in one sentence, the in-scope table, the full cut list table and the "Argue with me" items. Then say where the full file is.
Ask the decisions below. Give your recommended answer for each, clearly marked as a recommendation.
Ask how to continue, offering: Continue to step 6, prototype-brief · redo this step with changes · edit the output together · stop here.
Then wait for the user.
Decisions for you
"Push back on at least one cut or one inclusion. Which?" (If the PM accepts the first scope as-is, say plainly that a first scope is almost never right and ask which item they'd defend least.)
"Is the 'when they don't use it' fallback acceptable for the account team?"