What to Build When Every Customer Wants Something Different

Every product team hits the same wall: the request list has grown past what any roadmap can hold, no two customers agree on what matters, and each ask is somebody's dealbreaker. This is a translation problem, not a ranking problem. You are not trying to order 200 requests by score — you are converting many literal asks into a small number of underlying jobs, then deciding whose jobs you serve. Tools like BuildBetter make the clustering visible so you can see which requests collapse into the same job, but the method below works today with nothing more than a spreadsheet and clear thinking. The goal is never to satisfy every request. It's to build the smallest thing that serves the job most of your target customers share.

What This Problem Actually Is

The problem is that you have too many requests and no shared logic for turning them into decisions. Your backlog is full, the requests contradict each other, and every account frames its own ask as non-negotiable. That state feels like a prioritization failure. It usually isn't.

The distinction that unlocks everything: a surface request is the specific feature a customer names. The underlying job is the outcome they are hiring your product to accomplish. Clayton Christensen put it plainly — people don't want a quarter-inch drill, they want a quarter-inch hole. The request names the tool. The job names the result. When you cluster on drills, disagreement looks like chaos. When you cluster on holes, most of the noise resolves.

Des Traynor of Intercom framed the operator's version: "Every feature request contains a problem and a proposed solution. Your job is to extract the problem and reject or replace the solution." That extraction is the real work.

So name the decision honestly. You are doing three things at once: translating literal asks into jobs, clustering those jobs, and deciding which cluster belongs to the customers you actually build for. The output is not a ranked list. It's a small set of jobs and one clear ideal customer profile (ICP). Everything downstream — what to build, what to defer, what to decline — follows from those.

Why This Breaks Teams (The Concrete Failure Modes)

Teams break in predictable ways when they treat conflicting requests as a queue to work through rather than a set of signals to interpret. Four failure modes account for most of the damage.

The averaging trap

Building the union of all requests produces a bloated, incoherent product nobody fully loves. Each feature serves a minority; the whole serves no one completely. The data on this is brutal — Standish Group research is frequently cited for the finding that around 64% of software features are rarely or never used, and Pendo's analysis lands near 70%. You are not building value when you average. You are building maintenance cost.

The loudest-voice trap

Shipping for whoever emailed most recently, or whoever has the biggest logo, mistakes volume for representativeness. Ten tickets from one account is one customer's opinion, not ten independent votes. A request queue sorted by recency or noise systematically over-weights vocal accounts and under-weights the quiet majority who represent your real market.

The literalism trap

Building exactly what was asked instead of what was needed gives you the faster horse. Customers describe solutions in the vocabulary of what they already know, so the literal ask always understates the real job. Marty Cagan calls a roadmap built straight from a request queue a "feature factory" — high output, low outcome.

The false-consensus trap

Assuming disagreement means the market is confused. It usually means you are serving two distinct segments at once and hearing both. That's not confusion. That's a segmentation question wearing a feature-request costume.

The end state of all four is paralysis: 200 open requests, a full backlog, and no shared basis for saying no — so nothing coherent ever ships. CB Insights consistently finds "no market need" among the top reasons startups fail, cited in roughly 35% of cases. Building the wrong thing is a survival-level mistake, not a matter of tidiness.

The Method: Finding the Job Beneath Conflicting Requests

This method needs a spreadsheet and no budget. You can run it this afternoon. It has five steps, and it works whether you have 20 requests or 200.

Step 1: Collect every request verbatim

One row per request. Capture the exact words the customer used, the account name, and their segment. Do not paraphrase yet — the literal language matters because it's the raw material you'll translate. Resist the urge to clean it up.

Step 2: Translate each request into a job

For every row, ask: what were they actually trying to do? Write the answer in outcome language, not feature language. "Export to CSV" becomes "get our data into our own reporting stack." "Add a dark mode" might become "use the product for long sessions without eye strain." Tony Ulwick's outcome-driven innovation approach is useful here — express the job as a stable, solution-agnostic outcome so that competing asks can map to the same target.

Step 3: Cluster by job, not by feature

Group rows that share an underlying outcome even when the literal asks look nothing alike. This is where opposite-seeming requests collapse. Then count two things per cluster: how many distinct customers sit in it, and how concentrated those customers are in one segment. Distinct customers — not request count.

Step 4: Apply the decision rule

Each cluster gets one of three calls. Use this table:

Step 5: Write the no's down

Every decline gets a one-line reason. A documented no is a strategy artifact, not a rejection. It stops the same request from resurfacing every quarter and re-litigating a decision you already made. Your ICP is the boundary here — it defines whose jobs you optimize for and, by extension, whose requests you can legitimately turn down.

Worked Example: Five Requests, Two Jobs, One No

Here's the method on real-looking data. Six requests come in across two segments — three SMB accounts, two enterprise, one outlier.

• Request 1 (Northwind, SMB): "Add a Slack alert when a deal stage changes."
• Request 2 (Batch Co, SMB): "Send me a daily email digest."
• Request 3 (Delco, SMB): "Webhook into our internal ops tool."
• Request 4 (Meridian, Enterprise): "Custom SSO / SAML."
• Request 5 (Atlas Group, Enterprise): "Role-based permissions for 40 seats."
• Request 6 (Solo Ventures, SMB): "White-label the whole UI."

Translating to jobs

Requests 1, 2, and 3 look like three different features — a Slack alert, an email, a webhook. In outcome language they are identical: "know when something changes without logging in." Three distinct customers, spread across the SMB base, aligned with core. That's a GENERALISE. You build one notifications feature with a few delivery channels, and all three literal asks are served by a single build.

Requests 4 and 5 cluster into a second job: "deploy this safely across a large, governed organization." Two distinct customers, both enterprise. This is coherent — it's not noise, it's a real and consistent need — but it comes entirely from a segment heavier than the ICP you build for today. That's a SEGMENT SIGNAL. You defer it and write the note: "If enterprise requests for governance features hit 5 distinct accounts, this reopens as an ICP decision, not a feature ticket."

Request 6 is a single non-target account asking for something that contradicts your product's core (you are a product, not a white-label engine). That's a SAY NO. One-line reason: "White-labeling conflicts with our brand-forward product strategy; single non-target account."

The shipped decision

Six requests, three outcomes. Build one notifications feature. Defer one segment bet with a defined trigger. Decline one, on the record. Notice what did not happen — you didn't build three separate notification mechanisms, you didn't ship SSO because the enterprise logo was loud, and you didn't leave the white-label request floating in the backlog to resurface next quarter.

Common Mistakes

Five mistakes undo the method even when teams follow the steps.

• Clustering by feature keyword instead of by job. "Notifications" and "digest email" look like different rows in a spreadsheet. They are the same job. If you cluster on the words customers used, you will miss the collapse and keep three tickets where one belongs.
• Counting requests instead of customers. Ten tickets from one account is one data point. Sort by request volume and you will build for your noisiest customer, not your typical one.
• Treating a segment signal as noise. Declining a coherent enterprise cluster piecemeal, quarter after quarter, avoids the actual question. A consistent cluster from one segment is asking you to decide who you serve. Make the ICP call deliberately instead of dodging it five times.
• Never writing down the no's. Undocumented declines resurface. Every quarter the same request re-litigates a decision you already made, burning the same meeting time twice.
• Confusing a capture problem with an analysis problem. If you cannot remember who asked for what, no method saves you. And to be clear: no tool, including BuildBetter, fixes bad judgement. Tooling only makes the clustering visible so your judgement has something accurate to work with.

When Manual Stops Working (And What Tooling Actually Does)

The spreadsheet method holds up to roughly 150–200 pieces of feedback a month across a handful of channels. Past that, the clustering starts living in one person's memory and quietly goes stale.

The real breaking point isn't raw volume — it's fragmentation. The average B2B product team collects feedback across five or more channels: sales calls, support tickets, in-app prompts, Slack or community threads, surveys, and CSM notes. When feedback is scattered across all of them, no single person can hold the full picture, and the job-clustering degrades because half the evidence is invisible to whoever runs the spreadsheet.

Tooling changes one thing: it makes the clustering visible and continuously updated rather than remembered. This is still judgement work at any scale. Tools surface the clusters; they do not make the build/no/narrow-ICP decision for you.

Tools worth knowing

1. BuildBetter — the strongest fit when your feedback is fragmented across internal and external channels. It unifies internal voice (call recordings, Slack threads) with external sources (support tickets, surveys, product feedback) through 100+ integrations including Zoom, Jira, Salesforce, Zendesk, HubSpot, and Intercom. Every piece of feedback is analyzed individually with severity and business impact — not matched by keyword — and it produces deliverables like PRDs and follow-up notes, so the job-clustering stays current instead of decaying in someone's head. Its Clusters & Insights turn thousands of signals into visible themes.
2. Productboard — stronger when your bottleneck is roadmap communication and scoring rather than capture. If you can already see your feedback and mainly need to prioritize and broadcast decisions, that's its lane.
3. Enterpret — built for very high-volume support and CX orgs that need a deep NLP theme engine and auto-taxonomy over massive ticket streams.

Honest caveats: Productboard leads if your problem is communicating a roadmap, not synthesizing scattered input. Enterpret leads for sheer support volume. Dovetail is more mature if your workflow centers on a user-research repository. Pick for your actual bottleneck — capture, synthesis, prioritization, or research.

Frequently Asked Questions

How do I decide what to build when customers want opposite things?

Stop treating it as a ranking problem. Translate each request into the underlying job the customer is trying to accomplish, cluster requests by job rather than by feature keyword, then apply three outcomes: GENERALISE where one build serves the shared job of multiple asks, SAY NO where the job contradicts your product's core, and treat a coherent cluster from a non-target segment as a SEGMENT SIGNAL — an ICP decision, not a feature decision. Opposite-looking requests frequently collapse into the same job once you write them in outcome language.

How do I tell a real requirement from a nice-to-have?

Count distinct customers per job — not requests — and check whether the job blocks the customer's core outcome. A job that many of your target customers cannot complete without it is a requirement; a preference expressed by a few non-target accounts is not. Ticket volume is a poor signal because it is dominated by whoever emails most.

What is a 'segment signal'?

A segment signal is a cluster of coherent, internally consistent requests that all originate from the same customer type outside your current ICP — for example, several enterprise accounts asking for SSO and role-based permissions. It is telling you to make a deliberate choice about who you serve, not to bolt on a feature. The correct response is to set a threshold at which it reopens as an explicit ICP decision, not to keep declining it piecemeal.

Should I build the average of what everyone asks for?

No. Averaging conflicting requests produces an incoherent product that nobody fully loves and that costs disproportionately to maintain. Identify the shared underlying job beneath the differing asks and build the smallest thing that serves that job for most of your target customers.

How do I say no without losing the customer?

Document the no with a one-line reason tied to your product's focus, close the loop directly with the customer, and tell them what you are building instead. Practitioner consensus agrees customers accept a clear, reasoned no far better than silence — the churn risk lives in being ignored, not in being declined. Where relevant, point them to how the job might be met through an integration, a workaround, or a roadmap item that serves the same outcome.

At what point do I need a feedback tool?

When feedback exceeds roughly 150–200 items a month across multiple channels and no one can hold the clustering in their head. Tooling makes the clusters visible and keeps them current; it does not make the decision for you. The trigger is usually fragmentation — feedback scattered across calls, tickets, Slack, and surveys — more than raw count.

Make Churn Optional

Conflicting requests are not a sign your market is confused. They're a sign your feedback is telling you something you can't see clearly yet. BuildBetter unifies every call, ticket, Slack thread, and survey, clusters them by the job beneath the ask, and closes the loop with the customer once you ship — so the same request never re-litigates itself and no dealbreaker gets lost in the noise.

Make churn optional. Book a demo.