Why do customers say one thing and do another?
Because a stated request is already a solution — the customer has silently diagnosed their own problem and skipped to a fix. Saying it costs nothing; changing behavior costs effort. So words track aspiration while actions track constraint. Ask what they did last week, not what they want next quarter.
The gap is a translation problem, not a lying problem
Nobody is lying to you. A feature request is a customer doing part of your job as a favour: they hit friction, guessed at the cause, and handed you a fix. The guess was made from inside their workflow, with no view of your data model, your roadmap, or the other forty accounts hitting the same wall differently. Then it got compressed into one sentence in a call or a support reply.
The say/do gap is visible at company scale too. Okta and Zylo put the average company at 101 SaaS apps and roughly $21M a year spent on licenses nobody uses. Every one of those tools was requested by someone who was certain, at the time, that they needed it.
None of which makes the request worthless. A stated request is strong evidence about where the pain sits, who felt it, and how they narrate it — the exact words are worth keeping verbatim. It is only weak evidence about the fix.
What common requests usually mean
Treat the middle column as a hypothesis to test, not a diagnosis. The right-hand column is the cheap check that either kills it or promotes it.
| What they said | What it usually means | What to check before you build |
|---|---|---|
| ”We need bulk edit” | A routine task takes too many steps, and volume made it painful | How often that flow runs per account, and how many items per run |
| ”Can you add a Slack integration?” | The work lives in one tool and the decision in another; nobody sees updates | Whether the people asking ever open the notifications you already send |
| ”Your reporting isn’t flexible enough” | One recurring question can’t be answered — usually for someone above them | Which export they pull by hand each month, and what they paste it into |
| ”We need SSO” | IT or procurement blocked the rollout | Whether a real deal is gated on it, and who is doing the gating |
| ”The UI is confusing” | One specific step failed and generalized into a verdict | The session path at the moment they gave up, and the ticket filed that week |
| ”We’d use it more if it were faster” | A single slow screen sits inside a daily loop | Which route is slow for that account, and how often they hit it |
Triangulate before you build
The request is one signal. Three others exist that the customer does not author, and they are the ones that tell you what customers actually need.
What they did. Usage is the least flattering and most honest record you have. If a team asks for a better dashboard but nobody in the account has opened the current one in six weeks, the dashboard is not the problem — discovery is. Usage cannot tell you what they wanted to do and couldn’t; absence of a behavior is not proof of absence of intent.
What they wrote. Support tickets, chat threads, and meeting notes carry the unpolished version of the same pain, usually with a timestamp and a workaround attached. Support data skews toward the people who complain, so it over-weights the loud and under-weights the quietly churning.
What it’s worth. Attach revenue to the request. Not to rank accounts by size, but because a request from three accounts worth $200k behind one shared workflow is a different object than the same sentence from three trials that never activated.
Where two of the three agree, you have a problem worth solving. Where only the request exists, you have an anecdote — which is fine, as long as you call it that in the roadmap conversation.
The interviews still matter; the question set is what changes. Ask about the last occurrence rather than the next one: walk me through the last time this came up, what did you do instead, how long did it take and who else was in it. That is how you surface the workaround, and workarounds are expensive in ways people rarely volunteer. Gallup’s research on context-switching, as compiled by TheTab, puts the cost at roughly $450B a year, with the average employee losing 40% of productive time to it. The tab-hopping ritual nobody thinks to mention is often the most costly thing in their week. Our guide on running customer interviews without the awkwardness covers the mechanics; surveys versus interviews covers when to use which.
When you should just build what they asked for
The honest counter-case, because “dig deeper” is not free advice.
When the build is smaller than the investigation. A two-hour change does not warrant a two-week discovery cycle. If it is cheap, reversible, and low-blast-radius, ship it and watch.
When the customer is the expert in that domain. A compliance officer asking for an immutable audit export, a data engineer asking for a webhook with a retry policy, a designer asking for a specific export format — these people are describing a fix inside their expertise, not guessing about yours. Their stated request is frequently the literal need, and asking “but what’s the underlying problem?” is condescending.
When it is a hard blocker. SSO, a DPA, data residency, a procurement checkbox. No amount of problem-discovery moves a contractual gate. Establish that the gate is real, then build the thing.
When the same sentence arrives from unrelated accounts. Convergence across teams with different workflows and no contact with each other is evidence in itself. Independent sources landing on the same fix is unusual, and worth respecting.
And there is a cost to over-doing this. A team that interrogates every request eventually becomes a team customers stop telling things to. Being asked “what’s the real problem here?” four times in a row reads as being handled. Spend your discovery budget on the expensive, irreversible, or ambiguous calls, and take the cheap ones at face value.
The step everyone skips: check afterwards
Most writing on this subject stops at the interview, as though better questions were the whole discipline. They are half of it. The loop only closes when you go back and check whether the thing you shipped moved the behavior you used as justification.
Write the prediction down before the build starts: if we are right, the weekly count of this action per active account goes from X to Y within thirty days, and support volume on this topic drops. Then look. If the number does not move, you solved a stated request rather than a real need — and, more usefully, you now know which of your signals misled you and can weight it lower next time. That failure is only visible if the prediction was recorded somewhere durable before shipping.
This is why we keep the verdict attached to the work itself. In AIOProductOS, feedback across reviews, requests, surveys, and support lands on the same customer record as revenue and the work item, features rank by request count and revenue at stake, and every shipped feature carries a verdict — adoption, MRR adopted, retention lift — on its task card. See Insights for the feedback side and Outcomes for the verdict side. If nothing moved after launch, why is nobody using my feature is the next thing to read.
Where to start this week
Take the three loudest requests on your roadmap right now. For each one, write the sentence the customer actually used, then find the usage number, the support thread, and the revenue behind it. You will likely find that one of the three collapses, one changes shape, and one gets stronger. That is a good week’s work.
If your feedback is scattered across a spreadsheet, an inbox, and three Slack channels, the triangulation is the hard part rather than the thinking. Start with our roundup of the best customer feedback tools to get the signal into one place, then read how to turn customer feedback into product changes to keep it moving.