The discovery question bank

A discovery session is not a requirements meeting. Requirements are what the customer already decided to ask for; discovery is the attempt to find out whether that ask corresponds to anything. Thirty-one questions is more than one session can hold, so the bank is ordered: the first set decides whether there is a session worth having at all.

How to run it

Ninety minutes, two people from the customer side at minimum — one who does the work, one who can approve spending — and one rule: no laptops, no slides, and no solution vocabulary. If a question gets answered with "we'd want a dashboard", write it down and come back to it in the last ten minutes; the dashboard is usually a request for visibility into something nobody can currently define.

Write the answers as sentences with numbers in them. "Invoices arrive by email, about 400 a day, and 12% of them need a human to read the attachment" is usable. "Invoices are a big pain point" is not.

Set one — process (8 questions)

1. Walk me through one case from the moment it enters your team to the moment it is finished.
2. How many of those a day, on a normal day and on the worst day last month?
3. Where does it wait longest? Who or what is it waiting for?
4. Which step do people complain about, and which step actually takes the time?
5. What is done differently by your two best people versus the rest?
6. When it goes wrong, how does anyone find out?
7. What happens to the output after your team finishes it?
8. If you hired one more person tomorrow, which step would they take over?

A bad answer to 4 is the most common failure in the whole session: complaint and time sink are different steps, and building at the complaint is how projects ship something nobody uses.

Set two — data (8 questions)

9. Where does the information live now — system, spreadsheet, inbox, someone's head?
10. Who can export it, and have they done it before?
11. What is the identifier that lets two records be the same record?
12. How often is it wrong, and how do you find that out today?
13. Which fields does a human always check, even when the system is confident?
14. Is any of it personal data, contractually restricted, or from a system you do not own?
15. What happens when it is late or missing — does the process stop or proceed on guesses?
16. Who do I ask when a column's meaning is disputed?

Question 12 decides most feasibility calls. A customer who says "it's mostly right" has no error measure and the first two weeks of the deployment will be spent building one.

Set three — the decision (8 questions)

17. What decision does this output change, and who makes that decision?
18. What does that person do today when the output does not exist?
19. What would make them stop trusting it?
20. What is the cost of a wrong answer — money, time, or a phone call?
21. Which answer would be unacceptable even if it were usually right?
22. Is there a number this has to beat, and where does that number come from?
23. Who signs off that it worked, and what do they need to see?
24. What would you do with the time saved?

17 and 24 are the two that most often end a project early and cheaply. If the output changes no decision, or the saved time has no plan, there is no deployment here — there is a demo with a budget.

Set four — change and exit (7 questions)

25. Who has to change how they work for this to matter, and have they been asked?
26. What did the last system like this do to them?
27. Who could veto this quietly?
28. What is the busiest week of your year, and should we avoid it?
29. Who will run this when the vendor is not here?
30. What would make you turn it off?
31. When this ends, what should stay behind?

25 and 27 are the pair that predicts month two. A deployment approved by IT and not adopted by the business owner is the single most common way a technically correct project dies, and it is visible in discovery if you ask rather than assume.

Scoring the session

Do not score answers as good or bad; score how many of the four sets produced something checkable.

Outcome	Reading
Sets 1 and 2 answered with numbers	There is a project. Proceed to a metric table.
Set 1 clear, set 2 vague	The problem is real and the data is not ready. Sell a data-readiness sprint, not a deployment.
Set 3 empty	Nobody owns a decision. Any build is theatre.
Set 4 hostile	The blocker is organisational. An FDE cannot fix it from inside the code.

That table is also the honest way to decline work without insulting anyone: you are not saying no, you are reporting which set came back empty.

What to leave with

One page, in the customer's words, containing: the step in the process, the number per day, the current time or error rate, the data source and who owns it, the decision the output changes, the person who signed off, and the two things the customer is most afraid of getting wrong.

If you cannot fill that page, the next meeting is another discovery session, not a scoping meeting. Turning the page into a measurable acceptance test is the job of the metric definition table; turning it into something you may quote for is scoping and pricing.