Reading user intent
Move from what users say to what they are actually trying to get done.
Users describe their problem in the shape of the solution they already imagined. Your job is to unbend it.
Your three largest customers have all asked, in the same quarter, for a way to export their dashboard to PDF. It's a clear, specific, repeated request. Engineering says it's two weeks of work.
What's the right first move?
Users report solutions, not jobs
"I want a faster horse" is the canonical version, but it happens every day in quieter forms. A customer says "add a bulk-edit button." A support ticket says "the search should sort by date." Each is a real person naming the fix that occurred to them from inside their current workflow — constrained by what your product already looks like.
Reading intent is the discipline of treating the ask as evidence, not instruction. The request tells you a job exists and roughly where it hurts. It does not tell you the best way to serve that job — and taking it literally is how backlogs fill with features that ship and don't move anything.
The stated request vs the job underneath
"Let me export to PDF"
A button that produces a PDF of the dashboard.
Get this in front of an executive who will never log in to your tool.
A shareable read-only link or a scheduled email digest — no export, no stale file.
"Add a dark mode"
A dark color theme.
Often: 'this is uncomfortable to use for hours at night.'
Sometimes dark mode — but sometimes it's contrast, density, or reducing glare, which dark mode alone won't fix.
"Make onboarding shorter"
Fewer setup steps.
Reach the first moment of value before giving up.
Reorder so value comes first; the step count may not even change.
From ask to intent
- 01
Take the ask literally — once
Write down exactly what they requested. You'll come back to check your solution still serves it.
- 02
Ask what happens next
"What do you do once you have that?" The answer is where the real job lives.
- 03
Find the outcome, not the mechanism
Strip the request down to the state the user is trying to reach. That's the job.
- 04
Generate solutions the user didn't
Now that you own the job, propose builds they couldn't see from inside the current product.
- 05
Check back against the literal ask
Your better solution should still satisfy the original request — or you've quietly changed the problem.
Pick the most-requested feature in your current backlog. Do you actually know what users do in the five minutes after they'd use it — or only that they asked for it?
Honor the job, not the ask. The request tells you a real need exists and where it hurts; reading intent frees you to serve that need better than the user knew how to request.