Problem Statements vs Solution Requests

A solution request tells you what to build; a problem statement tells you why. "Add a report showing exposure by entity" is a solution. "Treasury rebuilds exposure by hand every month-end and it's error-prone" is the problem behind it. Converting the solutions people ask for back into the problems they're actually solving is the single highest-leverage move in project intake — because a solution built without understanding its problem is how teams confidently deliver the wrong thing.

The difference

People almost never bring you a problem. They bring you a solution — the first answer that occurred to them — phrased as a request. That's natural, but it's a trap: the requested solution is one answer to a problem you haven't seen yet, and it's often not the best one. The problem statement is the thing underneath: what's broken, for whom, and why it matters.

Why requests arrive as solutions

Because it's how people think. Someone hits a pain, jumps to a fix, and asks for the fix. By the time it reaches you, the problem has been silently compressed into a solution — and if you build the solution, you've inherited their compression, including whatever they got wrong on the way. The request feels actionable, which is exactly why it's dangerous.

How to convert a solution into a problem

Work backwards from the request with a few questions, ideally with the requester:

• What's the problem this solves? ("Why do you need the report?")
• Who has this problem, and how often? (One analyst monthly, or the whole team daily?)
• What breaks if we don't do it? (The cost of inaction — often the real justification.)
• What are you doing today instead? (The current workaround reveals the true need.)
• Keep asking "why" until you reach something that isn't a solution.

An example

Take the real-sounding request: "Can we add a report that shows treasury exposure by entity? Finance keeps asking."

• As a solution: you build an exposure-by-entity report. Six weeks later it's the wrong report.
• As a problem: you ask why. It turns out finance doesn't need a report — they need the month-end exposure number to stop being wrong, because today it's rebuilt by hand and errors slip through. The best answer might be fixing the source data, or an automated feed — not a report at all.

Same request, completely different — and much better — outcome. (This is the shift from a raw ask to a decision-ready initiative.)

When the solution really is the request

Occasionally the requester has done the analysis and the solution is genuinely the right, well-understood answer — a specific compliance requirement, a known integration. Fine: confirm the problem quickly and move on. The point isn't to interrogate every request to death; it's to not build a solution whose problem no one has checked.

What usually goes wrong

• Building the solution as stated. Delivering exactly what was asked for, and discovering it didn't solve the problem.
• Skipping the requester. Guessing the problem yourself instead of asking, so you invent a different wrong problem.
• Interrogation theatre. Turning "what's the problem?" into a bureaucratic gate that annoys people, instead of a two-minute conversation.
• Naming a solution in the "problem." Writing "we need a dashboard" and calling it a problem statement. If it names a build, it's still a solution.

Convert the solution back to the problem, and three good things happen: you often find a simpler answer, you can tell whether it's worth doing at all, and you can define a measurable outcome for it. Skip it, and you build precisely what was asked — and precisely the wrong thing.

This is the core of what Delivery Sheet does: it makes the problem, not the requested solution, the first field you fill in.

Part of the Finance Systems Delivery guide. See also the project intake process and turning a Slack request into an initiative. The newsletter sends one finance-systems pattern every two weeks.