The short answer
A solution shaped request is a request that arrives as a specification rather than as a problem. A client asks for a hammer. They never wanted a hammer, they wanted to hang a picture, and tape might have been enough.
This happens constantly in enterprise work. By the time a request reaches a delivery team, the original problem has usually been translated into a solution somewhere along the way: by the person who raised it, by their manager, by an account team, or by a meeting that converted a complaint into an action item. Taking the solution literally means building exactly what was asked for and solving a different problem from the one that existed.
The fix is not to ignore requests. It is to rewind the translation far enough to see the problem, which takes four questions and usually one conversation.
Key takeaways
- Requests are translated into solutions before they reach the team that will build them.
- The translation is helpful in intent and it discards the information needed to evaluate alternatives.
- Building the literal request produces a correct delivery against the wrong problem.
- Four questions recover the original problem: the outcome, the current workaround, the trigger and the definition of success.
- Rewinding a request is not a challenge to the requester, and it has to be framed so it does not read as one.
- The cheapest version of a solution is usually invisible until the problem is restated.
What is a solution shaped request?
A solution shaped request is an incoming requirement expressed as a specific implementation, where the underlying problem has been removed in the course of being reported.
The hammer example is the clean version. The enterprise version is harder to spot because the request is usually plausible, internally consistent and supported by someone senior.
Examples of the same shape:
A request for a new dashboard, where the problem is that one number is needed weekly and nobody knows where to find it.
A request to integrate two systems, where the problem is that a team re-enters forty records a day and an export would resolve it.
A request for a notification, where the problem is that an approval sits unnoticed for three days and the approver was never told they owned it.
A request for a report with eleven filters, where the problem is that four different people each need one of them and nobody asked which.
In each case the request is buildable and the cheaper solution is invisible until the problem is restated.
Why does the translation happen?
Four mechanisms, all of them well intentioned.
A solution is easier to communicate than a problem
Describing a problem requires context, and the person raising it reasonably assumes nobody wants the whole story. Naming a solution is short and it sounds actionable, so it travels better.
Intake systems ask for solutions
Request forms, ticket templates and backlog fields ask what should be built. The field that asks what is happening is usually optional and usually empty, so the format itself performs the translation.
Seniority compresses
A request passing through two levels of management acquires authority and loses detail at each step. By the time it lands it has sponsorship and no context, which is the worst combination for making a decision about it.
Requesters have learned that problems get deferred
A reported problem goes into a category for consideration. A specific request gets a date. People who have been through this learn to arrive with a solution, which is a rational response to how the intake works.
Quality and project management standards treat the determination of actual requirements as a distinct step rather than a reception activity. ISO 9001 requires an organization to determine the requirements for its products and services, including requirements not stated by the customer but necessary for the intended use, which is a formal way of saying the stated request is not the requirement. ISO 21502 places scope definition as its own practice with its own ownership.
Request to problem
What gets removed at each step of the translation
| Step | What is added | What is lost |
|---|---|---|
| The person experiences a problem | The full context | Nothing yet |
| They name a solution | Actionability | The outcome they wanted |
| Their manager endorses it | Authority | The frequency and the trigger |
| It enters an intake form | A specification | The current workaround |
| It reaches the delivery team | A date | The option to solve it differently |
By the final row the request is fundable and the information needed to evaluate a cheaper alternative is gone.
The four questions
Each one recovers a specific piece of what the translation removed. They work in a single conversation and the order matters.
1. What will be different once this exists?
Recovers the outcome. The answer separates the request from its purpose, and it is the question that most often reveals the request was a proxy. Someone asking for a dashboard who answers that they will stop asking the analyst for a number every Monday has just described a smaller problem than the one being built for.
2. What are you doing about it today?
Recovers the workaround, which is the single most informative answer in the set. Every real problem has a current handling, and that handling tells you the frequency, the cost and the shape of an adequate solution. A person spending twenty minutes a week is describing a different problem from one spending two hours a day.
3. What happened that made you ask now?
Recovers the trigger. Most requests have a specific precipitating event: a case that went wrong, a complaint, a close that slipped. The event is a concrete instance to design against, and its absence usually means the request is an improvement idea rather than a problem, which is worth knowing.
4. How will you know it worked?
Recovers the success definition, and it has to be answered before anything is built. An answer in terms of the solution, such as the dashboard being live, means the outcome is still missing. An answer in terms of the outcome, such as not needing to ask for the number, is a specification.
| Question | Recovers | What a weak answer indicates |
|---|---|---|
| What will be different? | The outcome | The request is the goal, which means the problem is unexamined |
| What are you doing today? | The workaround, cost and frequency | No current handling, so possibly not a live problem |
| What happened to make you ask now? | The trigger | An idea rather than an incident |
| How will you know it worked? | The success definition | The outcome is still unstated |
How to do this without dismissing the requester
The questions can read as resistance, which is how this practice usually fails. Five framings that prevent that.
Ask about the problem, not about the request. The difference between "why do you want a dashboard" and "what would you stop doing once this existed" is entirely in how it lands.
Say what the questions are for. One sentence: there may be a faster way to get you the outcome, and the answers help find it. Requesters are generally in favour of faster.
Accept the request as a valid candidate. Sometimes the answer is a hammer. Treating the stated request as one option rather than as a misunderstanding keeps the conversation open.
Do it once, early, and not repeatedly. A request that gets re-interrogated at every stage teaches people to stop raising things.
Report back what you built and why. A requester who asked for a dashboard and received an automated weekly email needs to hear the reasoning, or the next request will arrive with the justification pre-attached.
What changes in the intake
Three changes, in order of effect.
Make the problem field required and the solution field optional
Reverse the current default. What is happening, how often, and what you do about it now are required. What you think should be built is useful context and not the specification.
Route on outcome rather than on object
A request for a report and a request for a notification may be the same problem. Grouping by the stated solution hides that, and grouping by outcome reveals that four requests are one piece of work.
Record the workaround in the backlog item
The single field with the highest value later. It carries the frequency, the cost and the evidence that the problem is live, which is what prioritization actually needs.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform, and its relevance to this pattern is that the answer to the second question, what are you doing about it today, is exactly what a discovery cycle collects at scale.
Discovery Cycles run AI-led interviews with the people performing the work, asking what they did, where they waited, what they fixed themselves and what they would warn a new colleague about. The third of those reaches workarounds directly, which is the information that intake forms lose and the information that distinguishes a twenty-minute irritation from a structural cost.
The Insights Dashboard ranks findings by impact and effort with traceability to the inputs behind them, which allows four separately raised requests to be seen as one underlying problem with a measured frequency. The Process Library records where the work is actually performed, including the steps that never became a ticket because somebody absorbed them.
At Despegar, a cycle covered more than 170 collaborators, produced 124 hours of conversation and 45 initiatives, and ran in under 4 weeks against a baseline of roughly 12 months, in the context of a CRM migration. A system migration is where solution shaped requests concentrate, because the stated request is the migration and the underlying problems are the specific things people are working around in the current system. Forty five initiatives from one cycle is the shape of what sits underneath a single stated request. These figures describe one engagement and they are evidence rather than a guarantee.
The question worth asking about any incoming request: what is the person doing about this today, and does anyone have that written down?
Request intake template
| Field | Required | Purpose |
|---|---|---|
| What is happening | Yes | The problem |
| How often, and to how many people | Yes | Frequency and reach |
| What you do about it now | Yes | The workaround, cost and shape of an adequate fix |
| What happened that prompted this | Yes | The trigger instance to design against |
| What will be different afterward | Yes | The outcome |
| How you will know it worked | Yes | The success definition |
| What you think should be built | No | A candidate solution, treated as one option |
The last row being optional is the whole change. Most intake forms make it the first required field, which is where the translation gets locked in.
Common mistakes
Building the literal request. It delivers correctly against a problem that may not be the one that existed.
Asking why they want it. The information needed is the outcome and the workaround, and this phrasing invites a defence of the request instead.
Skipping the workaround question. It is the highest-value answer in the set and the one most often left out, because it sounds like small talk.
Re-interrogating at every stage. Rewinding once early is diligence. Doing it repeatedly teaches people to stop raising problems.
Treating the absence of a trigger as a problem with the requester. It usually means the request is an improvement idea, which is legitimate and should be prioritized differently.
Grouping the backlog by stated solution. Four requests for four different objects can be one problem, and grouping by object conceals it.
Not reporting back the reasoning. A requester who received something other than what they asked for will pre-justify the next request, which makes the translation harder to undo.
FAQ
What is a solution shaped request?
A request that arrives as a specific implementation rather than as a problem, because the problem was translated into a solution somewhere between the person who experienced it and the team that will build it. The classic form is asking for a hammer when the goal was to hang a picture.
Why do requests arrive as solutions?
Because a solution is shorter to communicate than a problem, because intake forms ask what should be built rather than what is happening, because detail is lost as a request gains seniority, and because requesters have learned that a specific request gets a date while a reported problem gets a category.
What questions recover the original problem?
Four. What will be different once this exists, which recovers the outcome. What are you doing about it today, which recovers the workaround and its cost. What happened that made you ask now, which recovers the trigger. And how will you know it worked, which recovers the success definition.
Which of those four matters most?
What are you doing about it today. Every live problem has a current handling, and that handling reveals the frequency, the cost and the shape of a solution that would be adequate. It is also the field most often missing from a backlog item.
How do you rewind a request without the requester feeling second-guessed?
Ask about the outcome rather than about the request, state in one sentence that the questions exist to find a faster route to what they want, treat the stated request as a valid candidate, do it once rather than at every stage, and report back what was built and why.
The request is evidence, not the specification
Somebody experienced a problem and did their best to make it actionable. The translation they performed was helpful in intent and it removed the information needed to find the cheaper answer.
Four questions put that information back, and the most useful one is about what the person is already doing to cope. Sometimes the answer confirms the hammer. Often it does not, and the difference is a conversation rather than a project.
See it. Fix it. Scale it.