Scoping Question Log
A drill for the skill every discovery call actually tests. Two underspecified customer asks, twelve candidate questions each, and a budget of six — spend them, see what the customer really says, and get each question scored on whether the answer changes what you build. Ends with a copyable scoping doc, a coverage map across the six axes, and the thing that was really going on that you either found or missed.
“We want AI to handle our invoices.”
That constraint is the point. A real discovery call has room for about six questions that matter, and the skill being measured is which six.
Pick questions on the left. Each one costs a slot and returns what the customer actually says — which is the only thing that tells you whether the question was worth asking.
The scoring rule: 3 if the answer changes what you build, 2 if it changes the plan, 1 if it is nice to know, 0 if it is premature or has no wrong answer.
“We want AI to handle our invoices” is not a requirement — it is the beginning of one, and how you run the next twenty minutes decides whether the project is buildable or arguable. This drill puts you in that call twice, with a hard budget of six questions against twelve candidates. Some of those candidates are the ones that surface the real project; some are reasonable-sounding questions whose answers change nothing; and a couple are the ones people actually ask, which return a polite non-answer and cost a slot. You spend the budget, you see exactly what the customer says, and each question is scored on the only criterion that matters: whether the answer would change what you build.
The scoring runs on six axes — outcome, data, users, constraints, success and risk — and the coverage map is as informative as the score. A session that spends all six questions inside one axis produces a confident, detailed misunderstanding. In the first brief, four questions are enough to discover that the customer already solved document extraction and the actual work is a 0.7 per cent long tail of purchase-order mismatches resolved by one person using an undocumented £200 threshold. In the second, the retrieval problem turns out to be a corpus-governance problem, and a technically excellent system would confidently cite withdrawn clinical guidance. Neither reveal requires cleverness. Both require asking about the right axis before you start building.
What comes out is a scoping doc you can copy: what you learned, in the customer's own words, plus the axes you never touched, which are your open risks. Each learned answer is a sentence that belongs in a statement of work — as an acceptance criterion if it is measurable, as a dated assumption if it depends on the customer. That conversion is the whole point. The questions you did not ask do not disappear; they resurface in month four as a scope argument, at which stage they cost far more than a slot in a discovery call. The full method is in the discovery and scoping handbook, and the interview round that tests it is simulated in the decomposition round lab.
How it works
- Two realistic underspecified asks, twelve candidate questions each.
- A budget of six — the constraint is the exercise.
- Each question scored 0–3 on whether its answer changes the build.
- Exports a scoping doc with a coverage map and the open risks.
Frequently asked questions
What makes a good clarifying question in a discovery call?
One whose answer changes what you build. “What happens today, step by step?” routinely reveals that the stated problem is already solved and the real work is somewhere else. Questions with no wrong answer — how do you feel about AI, what is your timeline — cost you a slot and return nothing you can design against. The test to apply before asking anything is simple: if the answer came back either way, would I build something different?
What are the axes a scoping session needs to cover?
Six: outcome (what changes in the business if this works), data (what exists, who owns it, whether you can actually get it), users (who does this work today and what they do instead), constraints (where it can run, what it can touch, who must approve), success (what number moves, measured how, agreed by whom) and risk (the cost of being wrong and how often that is acceptable). An axis you never asked about is where the surprise comes from, and it is usually data or risk.
Why limit the number of questions?
Because a real discovery call has room for about six that matter, and the skill being assessed — in the job and in the FDE decomposition interview round — is which six. Removing the budget removes the exercise: with unlimited questions everyone eventually covers everything, and nothing is learned about prioritisation.
What do you do with the answers?
Turn each one into either an acceptance criterion or an assumption with a date. “Forty of the sixty exceptions resolved without a human” is a testable acceptance criterion; “customer provides warehouse access by week one” is an assumption, and it only protects you if the statement of work also says delays shift milestones day-for-day. Anything still unknown when scoping ends is a scope argument already scheduled for month four.