Where a task comes from: interviews and the questions that uncover the real need
The customer asks for an Excel export. A month later it turns out the file is opened to work out a single number — a number that could have been shown on screen. The request was fulfilled; the need was missed.
A task almost never arrives as a task. It arrives as a ready-made solution: “we need an Excel export”, “add a comment field”, “send a notification”. The person asking has already thought it through for everyone and brought the result. The thinking itself — which problem lies behind it — stayed in their head.
Write the request down as stated, and development will build exactly that. A month later it turns out the export is opened to calculate one number by hand, and that number could have been shown on screen in a day instead of a week.
Request, need and problem
It helps to tell three layers apart. The request is what was said. The need is what the person wants to end up with. The problem is what gets in their way today. Customers almost always speak at the level of the request, and that is not a mistake: they know their work, not how the system is built. The analyst’s job is to go two layers down and come back with a solution that closes the problem rather than reproducing the request.
That does not mean rejecting the request. Often it is the best solution. But that can only be known once the problem has been named.
Questions that take you a layer down
| How the request is phrased | Question | What usually turns up |
|---|---|---|
| “We need an Excel export” | What do you do with the file afterwards? | They total one column or reconcile against another system |
| “Add a comment field” | What goes in the comment, and who reads it later? | It holds a status the system does not have |
| “Send a notification” | What should the person do when they get it? | Nothing — it exists so people stop calling support |
| “We need a sales report” | Which decision is made from this report? | There is one decision, and three numbers are enough for it |
| “Make it like the old system” | What worked well in the old system, and what did people put up with? | Half of the old behaviour is a workaround for its limits |
The common move in every row is to ask what happens after the request is fulfilled. The answer to that question is the need.
The last case, not the general rule
“How do you usually process a return?” gets you the ideal process — the one it is supposed to be. “Tell me about the last return you processed” gets you the real one: with exceptions, workarounds, and the call to a colleague without which nothing would have worked.
A concrete case is almost always richer than a generalisation. It contains details the person does not consider important and so would never mention: “then I looked up the contract number in my email” — which means the contract number is not in the system, and it is needed.
Seeing beats hearing. If you can sit next to someone while they do the work, it is worth three interviews. People describe their work as they understand it and do it as is convenient; the difference between those two versions is the material for the spec.
How to run the conversation
Before. Read everything that already exists: previous tasks, support tickets, correspondence. Write down your own hypotheses about the problem — not to confirm them, but to notice when an answer contradicts them.
During. Ask open questions — “how”, “what happens when”, “tell me about the last time”. Do not propose solutions: the moment the analyst says “what if we did it this way?”, the other person switches to judging someone else’s idea and stops talking about their own work. Hold the pause after an answer: the most important thing is often said in the second sentence, after a short silence.
After. The same day, write it up briefly — problem, need, exceptions found, open questions — and send it to the person asking them to correct it. Written in your words and confirmed by the other side, it is an elicited requirement. Written and not sent, it is the analyst’s version.
What gets in the way of hearing
- Leading questions. “You do need filtering by date, right?” — almost everyone says yes. The answer means nothing.
- A wish list. Ask “what else would be nice” and you get a long list in which the necessary cannot be told from the pleasant. Better to ask “what can this not launch without”.
- “All users want it.” Behind this phrase there is usually one user, or the speaker. It helps to ask who exactly said so.
- A single interviewee. The person who enters the data and the person accountable for it want different things. How to find the second one is covered in the piece on scope boundaries.
The sign the need was never found: after release the feature is used differently from what was intended — and people are still happy, because they found a workaround.
A five-minute check
Take the task you are writing now and answer one question: what will the person do differently once it is done? If the answer is “they will be able to press the new button”, you have written down a request, not a need.
What next
A problem found does not yet tell you when it is solved. For that you need a goal written so that after release there is something to compare against — and a number to compare by.