Requirements Gathering: How to Find the Problem Behind the Request

The short answer

Someone asks for a hammer. What they wanted was to hang a picture.

By the time a request reaches the team that will build something, it has usually passed through several translations. The person with the problem described it to their manager. The manager summarized it for a stakeholder meeting. Someone wrote it in a ticket. A prioritization process compressed it further.

Each translation is reasonable and each one loses the same thing: the situation that generated the request. What arrives is a proposed solution, stated with confidence, detached from the problem that would let anyone evaluate whether it is the right one.

The consequence is specific. Teams build exactly what was asked for, deliver it correctly, and the underlying problem persists. Everyone did their job and the outcome did not change.

Recovering the original problem is a skill, and it is mostly a matter of asking backward rather than forward.

Key takeaways

• Requests arrive as solutions because each translation strips context and adds specificity.
• Building what was asked for is not the same as solving the problem that generated the request.
• The recovery technique is asking what happens today and what happens if nothing changes.
• The person who filed the request is often not the person with the problem.
• Requests that arrive with unusual urgency usually have a specific triggering event worth finding.
• A request that cannot be traced to an operational consequence is a preference, and should be treated as one.

Why requests arrive pre-translated

Each handoff compresses

A person who reconciles two systems every Tuesday knows the shape of their problem in detail: which fields disagree, how often, what they do about it, what breaks downstream when they get it wrong.

By the time that reaches a roadmap it reads as a request for an integration. The integration might be right. It might also be that one field should be removed, that the downstream consumer no longer needs the data, or that the disagreement originates in a third system nobody mentioned.

The detail that would let anyone tell was lost at the first handoff, and nobody noticed because the request that survived was coherent.

Stating a solution feels more useful than stating a problem

There is a social dynamic underneath this. Arriving with a proposed solution reads as prepared. Arriving with a description of a difficulty reads as a complaint.

People adapt to that. Over time, requesters learn to translate their problems into feature requests before they raise them, because that is the form that gets taken seriously.

Specificity is mistaken for a well-defined need

A request that names a specific artifact sounds well defined. "We need a dashboard showing X by region" is easier to act on than "we cannot tell where the delays are coming from."

The first is a specification. The second is a problem. Only the second lets a team evaluate whether a dashboard is the right response, and only the second survives if the answer turns out to be that the delays are a routing issue that no dashboard would fix.

The recovery questions

The technique is to walk backward from the request toward the situation that produced it. Five moves, in roughly this order.

1. What happens today?

Ask the requester to describe the current process in the specific case that prompted the request. Not the general process, the last instance.

This is the highest-yield question in requirements gathering and the most frequently skipped. A concrete recent case contains the exception, the workaround, and the actual sequence, none of which appear in an abstract description.

2. What happens if nothing changes?

This establishes consequence, which is what separates a real requirement from a preference.

Useful follow-ups: how often does this happen, what does it cost when it does, who else is affected, and what do you do now to compensate.

If nobody can name a consequence, the request may still be worth doing, but it should be ranked as a preference rather than a need.

3. What triggered this now?

Requests rarely appear at random. Something happened: an incident, a volume increase, a reorganization, a customer complaint, a new reporting requirement.

The trigger frequently contains more information than the request. A request for a report that arrives the week after an executive asked an unanswerable question in a review is really a request for the answer to that question.

4. Who else touches this?

The person filing the request is often the person most inconvenienced, which is not the same as the person with the problem.

Upstream teams may be introducing the issue. Downstream teams may have built their own compensation for it. The requester generally cannot see either.

5. What would you do if this were not possible?

This surfaces the underlying need by removing the proposed solution.

If the answer is a workaround they would accept, the request is a convenience improvement. If the answer is that the work would stop, the request is load-bearing and the specific solution proposed may be negotiable.

Request to problem

What each layer contains

Most requirements processes operate at the top two rows. The disposition decision requires the bottom two.

Recognizing a pre-translated request

Four signals, none conclusive alone.

The request names a specific artifact. A dashboard, a report, a field, an integration. Artifacts are solutions. The problem is one level down.

The justification is generic. "For better visibility" or "to improve efficiency" usually means the specific consequence was lost in translation rather than that none exists.

The requester cannot describe a recent instance. If they can only describe the general case, they may be relaying someone else's problem.

The urgency does not match the stated impact. Unusually urgent requests with mild stated consequences almost always have a triggering event that was not included.

When the request is right

Worth stating, because a method that always concludes the requester was wrong is not a method.

Frequently the request is correct. The person understood their problem, chose an appropriate solution, and stated it clearly. In those cases the recovery questions take ten minutes and confirm the scope, which is a good use of ten minutes.

The purpose is not to challenge every request. It is to make sure the team knows what problem it is solving, so that when the build encounters a tradeoff, someone can decide it against the actual need rather than against the specification.

That situation arrives in most projects. A team that knows only the specification resolves tradeoffs by preserving the specification.

Doing this at scale

The method above works well for one request. It does not scale to a portfolio, and most enterprise teams face a portfolio.

Three constraints appear. The people with the underlying problems are distributed across functions and locations. The requests that reach the roadmap are a filtered sample, since many problems never get filed at all. And the pattern layer, where several teams turn out to share one cause, is invisible when requests are handled individually.

That last one matters most. Five separate requests for five different reports may all originate in one data ownership problem. Handled individually, the team builds five reports. Handled as a pattern, the team fixes the cause.

Seeing the pattern requires collecting the underlying situations across teams at the same time, in a comparable form. That is a different exercise from working through a backlog.

Where Horizon fits

Horizon is an AI-powered continuous discovery platform. It addresses the pattern layer, which is the one individual requirements work cannot reach.

Discovery Cycles run AI-led interviews across the roles involved in a process, adapting to each role and following up on what the person actually says. The follow-up behavior is what recovers the situation rather than the request, since the conversation can ask what happened last time and what breaks downstream without a human interviewer having to be present. The Insights Dashboard then groups what comes back by process, system and cause, so a difficulty appearing in one team and again in three others becomes one finding rather than four tickets.

Despegar, the leading travel technology company in Latin America with operations in more than 20 countries and over 3,900 employees, used it in exactly this situation. Its commercial operations were manual and poorly integrated, information was dispersed across tools and systems, teams duplicated tasks, managed inconsistent data, and made decisions with delays. The organization was preparing a CRM migration and needed to align Product, Commercial, Finance and HR around it.

Horizon gathered input from more than 170 collaborators across Media Sales and HR, analyzing over 124 hours of conversations. It produced insights on campaign activation, reporting, billing and collections, and a dashboard of 45 initiatives prioritized by impact and effort, with recommendations to guide the migration and define roles and standards across the four functions. The comparison against the manual approach was 12 months against under four weeks, with average satisfaction of 9.1 out of 10.

As one participant described it, interviewing 200 people in two weeks would have been impossible manually, and the type of findings obtained would not have come from a form.

That last point is the requirements-gathering observation. A form collects stated requests. A conversation that follows up reaches the situation underneath them.

That is one engagement under specific conditions rather than a projection for any organization.

Requirements checklist

Before committing build effort to any request:

1. Can you describe a specific recent instance of the problem?
2. Do you know what happens if nothing changes, with a frequency and a cost?
3. Do you know what triggered the request now?
4. Have you spoken to anyone upstream or downstream of the requester?
5. Do you know what the requester would do if the proposed solution were unavailable?
6. Do you know whether other teams have the same underlying problem?
7. Have you separated the problem statement from the proposed solution in writing?
8. Would the requester recognize your problem statement as their problem?
9. If a tradeoff appears mid-build, do you know which way to resolve it?

Question 9 is the practical test of whether the rest of the work was done.

Common mistakes

Treating the ticket as the requirement. The ticket is the end of a translation chain, not the beginning of one.

Asking the requester what they want. They already answered that. Ask what happens today.

Skipping the trigger question. It is the shortest path to the real consequence and it takes one sentence.

Speaking only to the requester. The person most inconvenienced is often not the person whose process is causing it.

Handling requests individually when they share a cause. Five reports get built and the data ownership problem stays.

Confirming rather than recovering. Asking questions designed to validate the proposed solution produces validation.

FAQ

What is requirements gathering?

The process of establishing what a system or change needs to do and why. Done well it recovers the underlying problem, the consequence of not solving it, and the constraints, rather than recording a proposed solution as a specification.

Why do teams build the wrong thing even when requirements are clear?

Because clearly stated requirements are often clearly stated solutions. A request that names a specific artifact can be unambiguous and still be the wrong response to the problem that generated it. The ambiguity that matters is not in the wording, it is in whether anyone knows the situation underneath.

What is the best question to ask in requirements gathering?

"Walk me through the last time this happened." A specific recent instance contains the exception, the workaround and the actual sequence, all of which disappear from a general description of the process.

How do you tell a real requirement from a preference?

Ask what happens if nothing changes, and require a frequency and a consequence. Requirements have both. Preferences have neither, which does not make them worthless, only lower priority.

Should you always challenge the requested solution?

No. Frequently the requester understood their problem and chose well. The recovery questions take a few minutes in those cases and confirm the scope. The purpose is ensuring the team knows what problem it is solving, which is what lets it resolve tradeoffs correctly during the build.

How do you gather requirements across many teams at once?

Individual interviews do not scale to a portfolio, and handling requests one at a time hides the cases where several share a cause. Collecting the underlying situations across teams simultaneously, in a comparable form, is what makes the pattern layer visible.

Ask what happened, not what they want

A request is the last link in a chain that started with someone having a difficult morning. Every link in that chain made the request more specific and less informative.

Walking back up the chain takes a handful of questions and it is the difference between building what was asked for and solving what was wrong.

See it. Fix it. Own it.

See Horizon in action.