The Request Is Not the Problem

Part 4 of a series on structured problem-solving and senior-level communication.

Reading time: about 9 minutes.

---

The request arrives already solved. "We need a dashboard showing weekly pipeline by rep." It is specific, it is reasonable, and it comes from someone senior enough that asking why feels like stalling. So the work starts. Requirements get gathered, a data source gets picked, three weeks go by, the dashboard ships.

Nobody opens it after the first week. Not because it was built badly, it does exactly what was asked. The person who requested it wanted to know whether two specific reps were going to miss the quarter, and they wanted to know it before the forecast call, which was eleven days ago. A dashboard was their guess at how to find that out. It was never the thing they needed.

The work was not wasted because it was done poorly. It was wasted because the first sentence of the brief was accepted as the problem.

What This Article Answers

• Why do smart teams deliver exactly what was asked and still miss?
• What does "framing the problem" actually mean, past the platitude? (Deciding what question the work has to answer, before deciding how to answer it.)
• How do I question a request without sounding obstructive or slow?
• Is there evidence that skipping this step actually costs anything, or is it just consulting folklore?
• What do I do when the person asking genuinely does not know what they want?
• How much time is the right amount to spend here?
• When is taking the request at face value the correct call?

TL;DR

Most requests arrive as a proposed solution wearing the clothes of a problem. Someone has already done a private round of diagnosis, and what reaches you is their conclusion, not their question. Reconstructing the question before you start is the single cheapest hour in the project, and it is the one that most reliably gets skipped under time pressure.

• A request is a hypothesis about the fix, not a statement of the problem. "Build a dashboard" is an answer to a question you have not been told.
• The framing tax is real and it is paid either way. Spend it up front deliberately, or spend it later as rework, on a worse schedule.
• Two questions do most of the work: what decision does this change, and what happens if we do nothing?
• Framing is not resistance. Done right it takes one conversation and makes you look faster, not slower.
• Sometimes the request is exactly right. Framing is how you confirm that in ten minutes rather than assume it for three weeks.

Two projects on the same timeline. One pays the framing tax in the first hour, the other pays it in week four as rework. Notice which line finishes sooner.

What Reaches You Has Already Been Diagnosed

The previous part was about decomposing a problem into branches you can actually test. All of that machinery has one dependency: the question at the top of the tree. Split the wrong question perfectly and you get a clean, defensible, well-owned answer to something nobody needed.

The reason the top line is so often wrong is not carelessness. It is that by the time a request reaches you, someone has already thought about it. They noticed something, formed a private theory about what would help, and what they sent you is the last step of that reasoning with the first steps stripped off. "We need a dashboard" is the visible end of an invisible chain that started with "I do not know if we are going to hit the number and I find out too late every quarter."

You are handed a conclusion and asked to implement it. The diagnosis that produced it stays in their head, where you cannot check it.

That is the framing tax: the cost of reconstructing the question that the request was an answer to. It gets called a tax because you pay it whether or not you choose to. Pay it in the first hour and it costs an hour. Skip it and it comes due in week four, when the thing you built meets the need it was supposed to serve and does not fit, except now it is expensive, other people have opinions about it, and the schedule has no room left.

There is more behind this than intuition. Paul Nutt of Ohio State studied 350 decision-making processes at medium and large companies and found more than half failed to produce the results they were after, often because perceived time pressure led people to pay too little attention to examining the problem from all angles. The mechanism in that finding is the point: the failure was not weak analysis, it was time pressure cutting the examination of the problem short. Which is precisely the pressure you are under when a senior person hands you a specific request and a deadline.

Two Questions, One Conversation

Framing has an image problem. It sounds like the thing that adds a discovery phase to a two-week job, and there is a version of it that does exactly that. That version is why people skip it.

The useful version is much smaller. Two questions, asked in the same conversation where the request lands.

What decision does this change? Not what will it show, what will someone do differently once it exists. If a request survives this question with a real answer ("I need to know by the tenth whether to reallocate two reps"), you now have the actual specification, and it is usually much narrower than what was asked for. If it does not survive, you have found something important very early.

What happens if we do nothing? This one prices the work. Sometimes the honest answer is that someone stays mildly annoyed, which is worth knowing before you commit three weeks. Sometimes the answer is that a renewal gets missed, in which case the deadline you were given is the wrong deadline and you have just saved everyone from finding out later. It is the same instinct as sizing work by how expensive it is if it turns out wrong rather than by how big it looks.

In the dashboard case those two questions take four minutes and produce a different piece of work: not a dashboard by month-end, but a specific answer about two reps, by the eleventh, delivered in an email. Same underlying need. A fraction of the work, and it arrives in time to be used.

The framing here is a tone question, not a permission question. "Before I scope this, help me understand what you will do with it" is not a challenge to the request. It reads as competence, because it is the thing an experienced person does. What reads as obstructive is the other version: "are you sure you need a dashboard?" One of those asks about their objective and the other argues with their judgment.

A request unwound backwards into the question it came from, and then forwards into a much smaller piece of work.

Where This Goes Wrong

Framing has two failure modes and they pull in opposite directions.

The first is framing as an excuse not to start. Everyone has met the version of this: the stakeholder interviews, the alignment workshop, the problem statement that gets rewritten four times while nothing gets built. The framing tax is supposed to be an hour, sometimes a day on a large engagement. When it becomes a phase with a name and a deliverable, it has stopped being framing and become a way of avoiding commitment. The test is whether the framing work is changing what gets built. If two more days of framing would not change the plan, the framing is done, whether or not it feels finished.

The second failure is reframing something that was already framed correctly. Sometimes the request is right. The person asking has actually done the diagnosis, they are competent, and what they want is exactly what they asked for. Interrogating them at that point wastes their time and costs you credibility for the next request, when it will matter more. The two questions above resolve this in minutes rather than requiring a judgment call in advance: a well-framed request answers both of them immediately and crisply. The speed of the answer is the signal. Someone who has done the diagnosis tells you what decision it changes without pausing.

There is a third situation, and it is the most common one on messy work: the person asking genuinely does not know what they need. They know something is wrong. The request is their best available guess and they are not attached to it. Here the two questions will not produce a clean answer because there is not one yet, and pressing harder just makes someone feel tested. What works instead is offering a frame and letting them correct it. "It sounds like the real issue is that forecast surprises land too late to act on. Is that it, or is it more that you do not trust the numbers?" People who cannot generate a problem statement can almost always recognise one, and correcting a wrong frame is much easier than producing a right one from nothing.

Three requests, three responses. Only one of them warrants a real reframing conversation.

The Version of This You Can Do Tomorrow

Take the next request that arrives already specified, and before you scope it, write one sentence in this shape:

You are asking for X because you need to decide Y by Z.

Fill in all three. X is what they asked for and you already have it. Y and Z are the ones that matter, and you will usually find you are guessing at one of them. That guess is the thing to check, and checking it is a single message: "Just so I build the right thing, is this mainly about the reallocation call before the forecast meeting?"

Two things happen. Often the person corrects you, and the correction is worth more than a week of requirements-gathering, because it comes from the diagnosis you could not see. Occasionally they confirm it exactly, and you proceed with something you no longer have to worry about.

Either outcome cost one message. That is the entire framing tax on a small piece of work, and it is the highest-return message you will send that week.

The Point

Nobody sends you a problem. They send you their solution to a problem, and the solution is the part they were least careful about, because it was the last thing they thought of and the first thing they typed.

The seniority signal is not solving the request faster. It is noticing, inside the first conversation, that the request is a guess, and spending four minutes turning it back into the question it came from.

Delivering exactly what was asked for is not the same as being useful. Most failed work was executed correctly against the wrong sentence.

Coming Up in This Series

Once the question is right, there is still the matter of how to answer it without spending six weeks gathering data first. The instinct on a hard problem is to collect everything and let the answer emerge, which is how analysis expands to fill whatever time it is given. The alternative is uncomfortable and much faster: commit to a best guess on day one, before you feel entitled to one, and spend the time trying to kill it. Next: hypothesis-driven problem solving, and why an answer you can disprove beats data you have not organised.

---

This is part of a series on structured problem-solving and senior-level communication.