The Requirements Interrogation
Take a one-line feature request and interrogate it until it is buildable. Practises the questioning that prevents building the wrong thing correctly.
Why this one
"Add a search feature" hides a dozen decisions: search what, matched how, ranked by what, for whom, and what happens when nothing matches. Building before those are answered means building the wrong thing well.
Steps
Start with a genuinely vague request
"Add notifications", "make it faster", "we need reporting". Use a real one from your own work if you have it — invented examples are conveniently easier to pin down.
Get the questions, not the solution
Ranking by cost of getting it wrong is what makes the list actionable rather than exhaustive.
PromptA stakeholder asked for: "[the vague request]". Do not propose a solution. List the questions that must be answered before this can be built, ranked by how expensive it would be to get that answer wrong after building. For each, give the two or three plausible answers and say how each changes what gets built.
Answer them yourself and notice the guesses
Work through the list. Mark every answer you had to invent. Those marks are your project risk, stated concretely, and they are usually more numerous than expected.
Write the one-paragraph spec
Rewrite the request as a paragraph a developer could build from without asking anything. If you cannot, you have found the questions that still need a real human answer.
You should end up with
A ranked question list and a buildable one-paragraph spec.
Done when
- The questions are ranked by cost of error, not by order of occurrence
- Guessed answers are explicitly marked
- The spec could be built from without follow-up questions
If you want to go further
- Ask the actual stakeholder your top three questions and compare their answers to your guesses