The most dangerous roadmap is the one built from customer feature requests. Customers are experts in their problem and amateurs at your solution — and confusing the two builds a worse product.
There's a kind of product meeting that feels virtuous and ends in ruin. The team pulls up the feature-request board, sorts by vote count, and starts building from the top. Every item came straight from a real customer. Every one is documented, requested, defensible. Nobody can be accused of ignoring the people who pay. And quarter by quarter, the product gets bigger, busier, and harder to explain — until one day a prospect opens it for the first time and can't tell what it's for.
The roadmap built from literal feature requests is the most dangerous one there is, precisely because it looks the most responsible.
The trap is that a request sounds like an answer. A customer says "add a bulk-export button" and it arrives pre-packaged: the problem, the solution, the spec, all in one sentence. The team treats it as a unit of work to schedule. But a feature request is not a fact about what to build. It's a customer's guess at the solution to a problem they've described to you in code.
Experts in the problem, amateurs at the solution
Customers know their world better than you ever will. They live the workflow, feel the friction, and can tell you with total authority where it hurts and what it costs them when it does. On the problem, they are the experts and you are the tourist. Discount that and you'll build confident answers to questions nobody asked.
But the request itself — the specific feature, the proposed button, the suggested fix — comes from someone who sees a sliver of your product, doesn't know what's technically cheap or expensive, can't see the other forty customers with adjacent needs, and has no view of where you're trying to take the thing. On the solution, the expertise flips. You're the one who can see the whole board. The customer is guessing, and they're guessing inside the constraints of what they already know exists.
Take the request literally and you outsource design to someone who can only see one corner of the product. Take the problem behind it seriously and you can solve it better than they knew how to ask for.
The most corrosive version of this is the loudest-account distortion. The customers who file the most requests, escalate the hardest, and sit in the largest accounts get a disproportionate share of the roadmap — not because their underlying needs are most representative, but because their volume is highest. Build to the loudest and your product slowly becomes the shape of your three angriest customers, which is rarely the shape of your market.
Visual 1 — Past the ask to the job behind it
What they asked for | The job behind it | The better build |
|---|---|---|
"Add a faster horse" | Get from here to there with less time and effort | A different mode of transport entirely — not a quicker version of the old one |
"Let me export everything to a spreadsheet" | Trust the numbers and answer a question without leaving the tool | In-product reporting and an audit trail, so the export is no longer needed |
"Add a field for every edge case we have" | Stop the product breaking on our non-standard process | A flexible model that absorbs many edge cases, not fifty bespoke fields |
How to read it: the left column is the customer's solution; the middle is the need they were actually expressing; the right is what you build when you take the need more seriously than the proposed fix.
Listening past the ask
The skill isn't ignoring customers. It's listening one level deeper than the words. Behind "add a bulk-export button" is usually a job: I need to trust these numbers and answer a question my boss is asking, and right now the only way I can imagine doing that is to drag it all into a spreadsheet I control. The export is the customer's workaround, described back to you as a feature. The job is the thing worth building for.
When you solve the job rather than the literal ask, two good things happen. You usually find a solution the customer couldn't have specified, because they were reasoning from what already existed and you can reason from what's possible. And one well-designed answer to the underlying job tends to dissolve a dozen surface requests at once, because those requests were all workarounds for the same unmet need wearing different clothes.
Visual 2 — The request, the job, the better build
Conceptual model. The request sits at the surface. The job lives beneath it. The strongest build ignores the surface ask and serves the job directly — often in a form the customer never thought to request.
When to build the request anyway
This isn't a license to overrule customers on instinct. Sometimes the request is the right build. When the asked-for feature is also the cleanest solution to the underlying job, when many different customers converge on the same workaround, when the cost of building it is trivial and the cost of being wrong is low — ship it, and don't get clever. The discipline is knowing which case you're in, not reflexively reinterpreting every request as a deeper truth. Treating every literal ask as a riddle is its own failure mode, and customers notice when you never just do the obvious thing.
The judgment call is whether the request and the job point the same direction. When they do, build the request. When the request is a narrow workaround for a job you could solve more completely, build the job. The mistake to avoid is automatic in either direction — neither blind compliance nor reflexive reinterpretation.
What this means for leaders
Distinguish customer-driven from customer-led. A customer-driven company builds what customers ask for; a customer-led one is guided by customers toward outcomes it then figures out how to deliver. The first sounds humble and produces incoherence. The second is the actual job. Audit which one your roadmap process really is.
Make "no" a sign of obsession, not indifference. The most customer-obsessed companies say no to literal requests constantly, because they take the underlying need more seriously than the customer's proposed fix. Saying yes to every ask isn't respect for the customer; it's abdication of the work you're paid to do. Frame the well-reasoned no as the customer-centric act it is, and your best people will stop fearing it.
Instrument the job, not the request count. Stop ranking the roadmap by vote tally, which only measures volume and rewards your loudest accounts. Cluster requests into the jobs underneath them, then build for the jobs that matter most across the market you actually want. The request board is a rich source of signal and a terrible roadmap. Mine it for the problem. Never mistake it for the spec.
A LookatBusiness original.
