"What should I build first" is the most answerable-looking question in the whole process, which is why every tool answers it on the spot. Ask a chatbot and you get a feature list in twenty seconds. The list will be reasonable. It will also be a plan for building the wrong thing efficiently, if nobody has established that anyone wants the thing.
So this analysis checks a precondition before it will produce a scope, and in most of the states you can be in, it refuses.
The gate, walked all the way through
The check is not a judgement call. It reads the most recent verdict the idea already carries and maps it, and because that map covers every value the verdict can take plus the case where there is no verdict at all, the set of states is finite and countable.
The idea's latest verdict | Reads as | You get |
|---|---|---|
| BUILD | verified | A scope |
| VALIDATE | promising | A scope |
| PILOT_FIRST | promising | A scope |
| HOLD | unvalidated | A refusal |
| KILL | unvalidated | A refusal |
| UNKNOWN | unvalidated | A refusal |
| no prior run | unvalidated | A refusal |
Every state the gate can be in, generated by running the real mapping function over the whole verdict enum plus the no-run case. The last row is where every new idea starts.
4 of 7 states get a refusal. That is not a tuning choice — it is where the map's fall-through lands, and the fall-through was pointed at refusal deliberately. Anything the gate does not positively recognise as validated is treated as unvalidated, so a new verdict nobody has taught it about fails closed rather than quietly unlocking a build plan.
Note which states are in there. Not just the killed idea — the idea nobody has evaluated at all, which is the state every idea is in on the day you have it, and the held one, where the evidence was inconclusive. Inconclusive is not a soft yes.
What the refusal actually does
It does not produce a smaller scope, a "lean" version, or a scope with a warning on top. The instruction is to leave the scope empty and write a paragraph explaining that we do not build a plan for an unvalidated idea, pointing at async validation instead.
That is the whole difference between this and a prompt that writes PRDs. A tool that hedges — scope plus a caveat — has produced the scope, and you will build from it, because the scope is the concrete artefact and the caveat is a sentence.
The refusal branch is thin on purpose: it requires a reason and nothing else. We checked by building one with every other field empty and confirming the invariant lets it through. A single paragraph is a complete, legitimate output here, and knowing that in advance is better than receiving one and assuming something broke.
What a scope has to contain when you do get one
When the gate opens, the output is not free-form. These are the parts the invariant refuses to let through empty:
mvp_goalenforcedmust_have_featuresenforcednon_goalsenforceduser_flowenforcedticketsenforcedstop_lossenforcedDerived, not transcribed: each field was blanked in turn and fed to the invariant that guards real output. These are the ones it rejected.
Two of those are the ones nobody asks a chatbot for, and they are the two that matter most.
A condition for quitting. A scope with no stated point at which you abandon it is not a plan, it is a wish with tickets. The useful property of that condition is that it has to be written before you are emotionally invested, which is exactly now.
An explicit not-building list. The features you are cutting are the ones you will otherwise re-add in week three, one reasonable decision at a time. Naming them converts a hundred future arguments with yourself into one decision you already made.
And the honest edge of that second guarantee, since we are publishing the derivation: the contract asks for more than one non-goal, and the invariant only refuses an empty list. A scope with exactly one non-goal passes. The intent is stricter than the enforcement, and a page claiming an enforcement guarantee should say precisely where it stops.
The parts that are asked for and not policed:
data_modelThe few entities and their key fields.acceptance_criteriaPer-feature checkable criteria.Requested by the contract; a missing one will not stop the output.
A complete first-version scope
The valid sample used for the checks above is deliberately small. Its goal is A bookkeeper closes one client's month end without a spreadsheet. It allows one must-have — Close checklist, whose job is “Know what is left to reconcile.” — and explicitly leaves out No payroll. and No multi-currency. The build window is 2 weeks. The condition for quitting is written before the tickets: If the core flow is not usable by the end of week two, go back to validation.
That is what “first” means here: one user outcome, one feature with a named job, explicit exclusions and a written point at which building stops. The example is the same object the invariant accepts, not a separate idealised scope invented for the article.
Two rules the parser enforces before anything else
Every must-have feature has to name the job it serves. Not a category, not a theme — the job. This one is stricter than an invariant: a feature with an empty job does not parse at all, which we confirmed by handing the parser exactly that and watching it refuse. The reason it earns that strictness is that "name the job" is the question a feature list cannot survive. Features that exist because competitors have them have nothing to write there.
The build window is bounded. Probing the parser with a ladder of week counts, the values it accepts run from 1 to 4. There is no option for a scope that takes a quarter, because a first version you cannot finish inside 4 weeks is not a first version — it is the product, and you have gone back to building on faith.
What it deliberately will not do
It does not re-decide your idea. The projection is neutral: the decision column comes back UNKNOWN, the score is a placeholder 50, the confidence MEDIUM. A scope is not a verdict, and a tool that let a scoping pass raise an idea's score would be laundering enthusiasm into evidence.
It also will not suggest a call, an interview or a demo anywhere in the plan — the same async constraint the rest of the product runs under.
Doing it yourself
- Answer the precondition first. Write down the evidence that someone wants this. If the honest answer is "it seems obviously useful", you are in the refused set and no feature list will fix it.
- Write down when to quit before the features. One sentence: what has to be true by the end of week two, and what you do if it is not.
- List what you are not building. Aim for more of these than features. It will feel wrong and it is the correct ratio for a first version.
- Make every feature name its job. If you cannot, cut it. That single rule removes most of a typical first scope.
- Cap it at 4 weeks. Not as ambition — as a constraint that forces the cut you keep avoiding.
The short version
- The question has a precondition, and 4 of 7 possible states fail it — including the state every idea starts in and the inconclusive one.
- The refusal is empty on purpose. A scope with a caveat attached is a scope, and you will build from it.
- 6 fields are mandatory in a real scope, derived by blanking each and watching the invariant reject it. A condition for quitting and a not-building list are two of them.
- The intent is stricter than the enforcement on non-goals, and we say so rather than implying the guarantee is total.
- Every feature must name its job or the output does not parse, and the whole thing has to fit in 4 weeks.