# Problem Statements vs Solution Requests

Source: https://gravam.com/blog/problem-statements-vs-solution-requests
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-09
Summary: A solution request tells you what to build; a problem statement tells you why. Converting solutions back to problems is the highest-leverage move in intake.

**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.

|  | Solution request | Problem statement |
| --- | --- | --- |
| **Answers** | What to build | What's wrong and why |
| **Example** | "Add an exposure-by-entity report" | "Treasury rebuilds exposure by hand at month-end; it's slow and error-prone" |
| **Fixes** | One pre-chosen answer | The underlying need |
| **Lets you** | Build what was asked | Choose the best answer, or decline |

## 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.

> The tell that you've reached the problem: you can no longer answer "why?" with another feature. "Add a report" → why? → "to see exposure" → why? → "because we hold too much cash as a buffer and miss investment yield." _That_ is the problem — and it might be solved by something other than a report.

## 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](https://gravam.com/blog/03-finance-team-friction). 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](https://gravam.com/blog/06-slack-request-to-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](https://gravam.com/blog/how-to-define-a-measurable-outcome) for it. Skip it, and you build precisely what was asked — and precisely the wrong thing. (To capture the converted request as a decision-ready page, the [intake one-pager generator](https://gravam.com/tools/project-intake-one-pager) does it live in the browser.)

This is the core of what [Delivery Sheet](https://gravam.com/products/delivery-sheet) does: it makes the problem, not the requested solution, the first field you fill in.

***

_See also the [project intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams) and [turning a Slack request into an initiative](https://gravam.com/blog/06-slack-request-to-initiative)._

## Questions this article answers

**Q: What is the difference between a problem statement and a solution request?**

A solution request tells you what someone wants built — 'add a report showing exposure by entity.' A problem statement tells you what's actually wrong and why it matters — 'treasury rebuilds exposure by hand every month-end and it's error-prone.' The solution is one possible answer; the problem is the thing that actually needs solving, and it usually has better answers than the first one someone thought of.

**Q: Why should you turn a solution request into a problem statement?**

Because building the requested solution without understanding the problem is how teams deliver the wrong thing. When you know the real problem, you often find a simpler or better solution than the one requested, you can tell whether it's even worth doing, and you can measure success. Converting solutions back to problems is the single highest-leverage step in intake.

**Q: How do you write a good problem statement?**

State what's wrong today, who it affects, and why it matters — concretely, with the cost or pain, and without naming a solution. 'Finance can't see group cash intraday, so they hold excess buffers and miss investment opportunities' is a problem statement. 'Build a cash dashboard' is a solution. Keep asking 'why' and 'what breaks if we don't' until you reach the underlying need.