The Feature They Asked For Is Rarely the Problem They Have

A customer emails you: "Can you add an export-to-PDF button?"

It's specific. It's polite. It even tells you where it should go. So you build it,
ship it, and feel the small satisfaction of a request closed. Three weeks later the
same customer churns — and in the exit survey they write that the product "just took
too long to get anything out of."

The PDF button was never the problem. It was a guess at a solution, offered by
someone who was trying to be helpful. Your job in requirements elicitation is to get
underneath that guess to the problem it was standing in for.

Why customers hand you solutions, not problems

People don't experience their lives as a list of requirements. They experience
friction, and they instinctively translate friction into the nearest solution they
can imagine. That translation is lossy. By the time a need reaches you as a feature
request, it has been through at least two compressions:

1. Problem → felt friction. The customer noticed something was slow, confusing, or missing.
2. Felt friction → proposed fix. They reached for a fix shaped by whatever tools they already know.

You receive step 2. Elicitation is the work of running that translation backwards —
recovering the problem from the proposed fix. The famous (probably apocryphal) line
captures it: if you'd asked people what they wanted, they'd have said a faster
horse. The horse is the solution. The job is "get me there sooner."

Stated wants vs. real needs

It helps to hold three layers in your head during any discovery conversation:

• The request — what they literally asked for ("PDF export").
• The need — the outcome they're chasing ("send a clean summary to my boss").
• The job — the recurring situation that keeps creating the need ("every Friday I have to prove to leadership that my team shipped value this week").

The request is the least durable of the three. Ship the PDF button and you've served
one narrow expression of the need. Understand the job and you might realize the
customer would be far better served by an auto-generated weekly digest — something
they never would have thought to ask for.

The interview techniques that actually surface needs

Good elicitation is mostly discipline about how you ask. A few practices do most of
the work.

Ask about the last time, not the general case

"How do you usually handle reporting?" invites a tidy, idealized answer. People
describe the process they wish they followed. Instead: "Walk me through the last
time you had to send a report. What did you actually do?" Specific, recent memory is
harder to sanitize, and it's where the real friction lives.

Chase the story, not the feature

When someone names a feature, resist the urge to scope it. Get curious about the
situation instead:

"Interesting — tell me about a moment recently when you really wished you had that."

Now they're narrating an event, and events contain context: who else was involved,
what was at stake, what they tried first, why it hurt.

Use "why" carefully (and count to five)

The five whys are useful for digging past the surface, but stacked "why"
questions can feel like an interrogation. Vary the phrasing — "what made that
matter?", "what happened next?", "what would've changed if it worked?" — and you'll
descend the same ladder without putting the person on the defensive.

Watch what they do, not just what they say

Whenever you can, observe the actual workflow. People are unreliable narrators of
their own behavior — not because they lie, but because habit is invisible from the
inside. Ten minutes watching someone wrestle a spreadsheet teaches you more than an
hour of them describing it.

Jobs to be done: a frame that keeps you honest

The Jobs-to-be-Done lens formalizes all of this into one question: what job is
the customer hiring this product to do? The value of the frame is that a job is
stable while solutions come and go. "Help me look competent to my boss on Friday" is
a job that will outlive PDF exports, digests, dashboards, and whatever comes next.

A lightweight JTBD story template:

When [situation], I want to [motivation], so I can [expected
outcome].

Fill it in for our example:

When it's Friday and leadership is asking what my team accomplished, I want
to quickly assemble proof of the week's progress, so I can show impact
without spending an hour I don't have.

Nowhere in that sentence is there a PDF button — and yet it tells you far more about
what to build.

The traps to avoid

• Leading questions. "Wouldn't it be great if...?" gets you a yes and teaches you nothing. Ask open questions and then be quiet.
• Averaging across users. Requirements aren't a democracy. Ten people asking for ten slightly different fixes to the same job point at one solution, not ten.
• Confusing enthusiasm with need. People are generous with "that'd be cool." Needs show up as things they've already built a painful workaround for. Follow the workarounds — they're evidence of a job important enough to hack around.
• Stopping at the first plausible problem. The first answer is usually the request lightly reworded. The real need is often one or two layers down.

What to do Monday

You don't need a research team to start. Pick your three most recent feature
requests and, for each, book fifteen minutes with the person who asked. Don't discuss
the feature. Ask them to walk you through the last time they hit the problem it was
meant to solve. Write down the job, not the fix.

You'll usually find one of three things: the request was a fine solution to a real
job (great — build it with confidence), the request was a weak solution to a real job
(now you can build a better one), or there was no durable job underneath at all
(now you've saved yourself the build).

The feature they asked for is rarely the problem they have. Your advantage isn't
building faster — it's being the person in the room who bothers to find out.