Framing the Problem Before the Solution

A stakeholder once opened a discovery session with a fully formed request. We need a new dashboard; can we scope that? Six weeks in, on the original framing, we would have shipped a polished dashboard that almost nobody actually used, because the real issue had nothing to do with visibility. It was that three different teams were each updating the same number in three different spreadsheets, and none of them trusted the numbers the other two were reporting. A dashboard would have made that disagreement easier to see. It would not have fixed it. The actual fix was a single source of truth for that number, feeding every team from the same place, which turned out to be a smaller, faster, and completely different project from the one originally requested.

Why Stakeholders Arrive With Solutions

This is not a criticism of the stakeholder, and treating it as one is the fastest way to make this conversation go badly. People bring solutions, not problems, because a solution is what they can picture clearly, and a problem, especially one they are living inside every day, often feels too vague or too personal to state plainly out loud. Saying I don't trust the numbers my colleagues send me is a harder thing to say in a meeting than we need a dashboard. The solution is the safe, concrete version of a much less comfortable underlying complaint, and most people reach for the safe version without fully realising that is what they are doing.

The job in discovery is not to reject the stated solution outright, which reads as dismissive and shuts a stakeholder down fast. It is to treat the requested solution as a clue rather than a conclusion, a signal pointing toward a real problem that is still worth surfacing directly, and asking the questions that lead there.

The Walk-Back, in Practice

Here is roughly how that conversation went once the dashboard request came in, generalised enough to be reusable rather than tied to the specific project it came from.

WALKING BACK FROM A SOLUTION TO THE REAL PROBLEM

Stakeholder:

We need a new dashboard; can we scope that?

You:

Happy to look at that. Before we get into what it should show, what's the actual moment that made you think of a dashboard? What happens right now that a dashboard would fix?

Stakeholder:

Honestly, every week we sit in a meeting arguing about whose numbers are right. My team says one thing, finance says another.

You:

So the pain isn't really that the number is hard to see; it's that you don't trust it once you do see it.

Stakeholder:

Exactly. A dashboard wouldn't fix that, would it? It would just show us disagreeing faster.

You:

That's roughly where I landed too. What if we scoped this as fixing where that number actually comes from, one source everyone pulls from, instead of a dashboard for now? A dashboard becomes a much smaller add-on once the number underneath it is something everyone already trusts.

Notice the shape of that exchange. It never tells the stakeholder their request was wrong. It asks what specific moment prompted the request, and lets the stakeholder arrive at the real problem themselves, largely in their own words. A problem a stakeholder names themselves is one they will defend later, in front of their own leadership, in a way a problem you named for them rarely gets defended with the same conviction.

A Question Worth Keeping in Your Back Pocket

One question does most of the work in these conversations, and it is worth having ready before any discovery session that opens with a stated solution: what would happen if we did nothing at all, and left things exactly as they are today? If the honest answer is genuinely not much, the request is probably a nice-to-have, closer to the Could category from last week's series on requirements prioritisation than an actual discovery priority. If the honest answer involves real, specific pain, that pain is the actual problem, and it is very often smaller, cheaper, and more specific than the solution that was originally proposed to fix it.

This discipline is not about being difficult or slowing a project down for its own sake. It is about spending the cheapest hour of the entire project, a conversation in week one, to avoid the most expensive one, discovering six weeks or six months in that the wrong problem was solved extremely well.

It is also worth naming the moment this technique should stop. Not every solution a stakeholder brings is hiding a different problem underneath it. Sometimes the dashboard really is the answer, and the walk-back conversation simply confirms that quickly and moves on. The discipline is not to distrust every stated solution as a matter of habit, which becomes its own kind of unhelpful friction over time. It is to ask the one grounding question, what would happen if we did nothing, before accepting the solution at face value, and to trust the answer that comes back, whichever direction it points.

The other place this matters is in how the reframed problem gets carried forward once it has been found. Write it down in the stakeholder's own words wherever possible, not a polished restatement in your own language. A problem statement that still sounds like the person who said it tends to survive contact with that same person's memory weeks later far better than a version that has been smoothed over into generic project language they no longer fully recognise as their own.

It is also worth watching for the moment a stakeholder resists the walk-back entirely, insisting the original solution is what they need regardless of what the grounding question reveals. That resistance is information too. Sometimes it means the solution genuinely is right and the questioning has simply run its course. Sometimes it means the real problem is one the stakeholder is not yet ready to say out loud in the room, which no amount of gentle questioning will force open before they are ready. Either way, pushing further than a stakeholder is willing to go rarely produces a better outcome than noting the resistance, proceeding with what they have asked for, and staying alert for the real problem to surface again later, in a moment they choose rather than one you engineered.

Go out and be successful.

Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com

TOMORROW

Naming the Unknowns - How to size and time-box a genuine unknown instead of guessing or letting it stall the whole project.