The first answer is almost never the real one

A stakeholder once asked me for a faster horse. I am being slightly unfair to him, because he did not use those words. What he said was that the monthly reporting pack needed to come out in half the time, and that the fix was to add three more people to the reporting team. That was the request. Three more people. He had even worked out the cost and pre-approved it. All I had to do was write it up.

I almost did. The request was clear, the sponsor was senior, and writing it down would have made my week look productive. Instead I asked one slow question. Not what he wanted, but what the reporting pack was actually for. Who read it, and what decision did they make after reading it?

It turned out almost nobody read it. Two of the fourteen tables drove every real decision, and those two were late every month because they sat at the end of a queue behind twelve tables that no longer mattered. The honest fix was not three more people. It was deleting most of the pack and reordering the rest. We solved the real problem with a morning of work and zero new hires. The faster horse would have cost a fortune and still arrived after dark.

People speak in solutions, not problems

This is the first thing to make peace with. When you ask someone what they need, their brain does not hand you a clean problem statement. It hands you the nearest solution it can reach for, because that is how human beings are wired to be helpful. They are trying to save you the trouble of thinking. They translate a messy, half-formed need into the closest familiar thing, and they give you that instead.

So you hear "I need a dashboard" when the real need is "I cannot tell if we are about to miss the quarter until it is too late." You hear "add a status field" when the real need is "three teams keep redoing each other's work because nobody knows what is finished." The request is a costume the problem is wearing. Your job is to look underneath without insulting the person who handed it to you. None of this means stakeholders are foolish. They are often the smartest people in the building about their own work. The trouble is that the solution feels so obvious to them that the problem behind it has gone invisible, the way you stop hearing a clock you have lived with for years. They are not hiding the problem from you. They have stopped seeing it themselves.

The cost of writing it down too fast

A requirement captured at face value is more dangerous than no requirement at all, because it looks finished. It goes into the document. It gets estimated, scheduled and built. By the time anyone realises it solved the wrong problem, money has been spent and the stakeholder has moved on to wanting the next thing. The faster horse gets built beautifully, on time, on budget, and it does not help.

This is the quiet failure mode of our profession. Not the dramatic project that collapses, but the steady stream of features that work exactly as specified and change nothing. They satisfy the request and miss the need. And the saddest part is that everyone did their job. The BA captured what was said. The team built what was captured. The only thing nobody did was ask whether the request and the need were the same thing.

The one shift: hold the request, chase the need

Here is the move that changes everything, and it is more attitude than technique. When you receive a request, do not treat it as the answer. Treat it as the first clue. Say it back, write it down so the person feels heard, and then quietly refuse to act on it until you understand the need sitting behind it. The practical version is almost embarrassingly simple. When someone hands you a solution, ask what it would let them do that they cannot do today. Ask what happens right now without it. Ask what good would look like if the solution did not exist and they had to solve the problem some other way. Each of these questions walks the person backwards from their solution to the problem underneath, and it does it without making them feel second-guessed.

Two questions to carry into every conversation

"If this were already built, what would you do differently tomorrow morning?" This forces the conversation onto outcomes and away from features. The answer is the need.
"What are you doing today to get around the fact that you do not have this?" The workaround people have invented usually tells you more about the real requirement than any wish list.

Notice that neither question challenges the person. You are not telling them they are wrong. You are taking their solution seriously enough to understand why they reached for it, and that respect is exactly what earns you permission to dig.

Why this matters whether or not you are a BA

This week is built for business analysts, but the skill underneath is not ours alone. A manager who takes a brief at face value ships the wrong project. A doctor who treats the symptom the patient names misses the illness. A designer who builds the screen the client describes instead of the job the client is trying to do produces something pretty and pointless. Anyone who takes instructions from another human being is doing elicitation, whether they call it that or not.

That is why a junior reading this can take away a clean technique today, the two questions above, and use them in their next meeting. And it is why a senior reading the same lines will recognise something they learned the hard way over a decade of building faster horses before they knew better. The technique is easy to state and hard to hold under pressure, when a senior stakeholder is waiting, and the easy thing is to just write it down.

What this week covers

Tomorrow I get specific about the questions themselves, because not all questions are equal and the order you ask them in matters as much as the words.
On Wednesday I move to the hardest part of the craft, surfacing what stakeholders genuinely cannot put into words, the knowledge they have but cannot reach.
On Thursday I move from the one-to-one conversation to the room, and how to run a workshop that produces answers instead of noise.
On Friday I hand you the whole thing as a single reference you can keep beside you.

For now, sit with the discomfort of the first idea. The next time someone hands you a fully formed solution, resist the small relief of writing it down. That relief is the trap. It feels like progress, and it is often the exact moment a project quietly points itself at the wrong target. Ask what the solution would let them do instead. Ask what they do today to cope without it. Then wait. The silence after that question is where the real requirement lives, and the willingness to sit in it, when everyone in the room expects you to move on, is the first real mark of a business analyst who has stopped collecting requests and started finding needs.

Go out and be successful.

Oluwatosin Ogunkoya | Flotog BA Insights | www.flotogbainsights.com

Tomorrow: Not All Questions Are Equal

The question types, the funnel, and why the order you ask in decides what you learn.