Requests usually arrive looking like this: “could you just add an export button to the listing?” It is short and clear, and it feels like something you can write straight into a ticket. But that sentence has already been translated once. The person turned their own inconvenience into a solution before they spoke, and what reached you is the solution, not the inconvenience.
The request is already a translation
This is not a bad thing. It means they have thought about the problem, which is co-operative. But every translation loses something. The solution they imagined is bounded by the methods they happen to know, so an easier route never makes it into the sentence. If what they actually wanted was “five numbers for the monthly report”, you can build a perfect export and they will still be opening a spreadsheet every month to pick out five figures.
The planner’s first job, then, is not to build but to reverse: step back one square from the request to the need that produced it.
Three questions that recover the purpose
Three questions are usually enough, and all three ask about the situation rather than the feature.
“What are you trying to do with it?” — the simplest question and the most frequently skipped. If the answer is “I have to produce a monthly report”, the thing to build may be a summary view rather than a download.
“How are you doing it today?” — the current workaround contains the requirement in full. The manual routine people have already invented is the most accurate specification you will ever get, and it tells you which step actually hurts.
“What happens if this does not exist?” — the prioritisation question. “It is a bit annoying” and “we miss the deadline” are not the same request wearing different words.
Asking should not sound like refusing
A run of questions can read as “he is looking for a way out of this”. So state the intent before the questions: “I want to get this right, so let me check a couple of things” changes the temperature of the conversation entirely.
And do not argue with the feature. Not “I am not sure you need that”, but “let us check together that this solves it”. Recovering the purpose is not a procedure for rejecting requests — it is a procedure for getting a better outcome from the same budget.
The purpose belongs on line one of the spec
Write down what you found. A purpose agreed verbally evaporates within a fortnight, leaving only the original request sentence behind. Open the specification with “this exists in order to …” and every later judgement — what to cut, how far to handle edge cases, what to build first — has a stated reference point.
More on the documents that sit between planning and development is in the development workflow archive, and if you would like to see a request travel all the way into delivered work, our process page publishes the order we work in.
Next part
With the purpose recovered, it is time to write it down. The next part covers what to write before any list of screens: who is doing what, and to achieve what.