Three People, Three Different Answers to "What Should We Build Next"
Here's the scenario. One customer wants deeper reporting. Another wants a faster onboarding flow. A third wants you to fix an integration that keeps silently failing. All three are paying you. All three are right, from where they're sitting. And you have one roadmap slot open this sprint.
When customers want genuinely different things, the fix isn't finding the "correct" request. It's separating disagreement about priority (which is normal and expected) from disagreement about direction (which means your product doesn't have a clear enough job yet). Most founders treat every conflicting request as the same kind of problem. It isn't.
This is different from reconciling conflicting data sources, where calls, tickets, and analytics disagree about the same event. That's a signal-reconciliation problem. This is three separate humans asking for three separate things, all valid, and you can only build one this sprint.
Why This Feels Harder Than It Is
At low customer counts, every request sounds like a mandate. You talked to the person. You know their name, their business, their deadline. Weighing "Priya wants X" against "Marcus wants Y" feels like picking a favorite customer, not making a product decision.
That's the trap. The request isn't the signal. The reason behind the request is the signal, and three different requests can point at the exact same underlying job, the same insight behind Harvard Business School's "jobs to be done" theory. Priya wants deeper reporting because she can't prove ROI to her own boss. Marcus wants faster onboarding because his team keeps abandoning setup before they see value. Different asks, different urgency, but neither one is really asking for a feature. They're asking for a job to be done, and the words they used to describe it are just packaging.
The Two Questions That Actually Separate These Requests
Before ranking anything, run each request through two questions:
- Is this a priority disagreement or a direction disagreement? A priority disagreement means everyone agrees roughly where the product is going, they just want different things sooner. A direction disagreement means the requests are pulling toward incompatible products: a reporting-heavy analytics tool and a zero-friction onboarding wizard aren't the same product wearing different hats.
- What's the underlying job, stripped of the feature language? "I want deeper reporting" and "I want a way to prove this was worth the spend" are not the same request, even when the same customer says both. The first locks you into a feature. The second leaves the solution open.
If most of your conflicting requests turn out to be priority disagreements pointing at the same underlying job, you have one product with a sequencing problem. If they're genuinely pulling in different directions, that's a market-fit conversation, not a backlog conversation, and no prioritization framework fixes that.
A Working Method: Weight by Reach, Recur, and Reversibility
Once you've separated priority from direction, don't rank by whoever asked loudest or most recently. Weight each request across three dimensions:
| Dimension | Question to ask | Low weight looks like | High weight looks like |
|---|---|---|---|
| Reach | How many other customers have the same underlying job, even if they used different words to ask for it? | One customer, one phrasing, no pattern elsewhere | Three unrelated customers, same job, different vocabulary |
| Recurrence | Has this come up once, or does it keep resurfacing across calls, tickets, and churn-risk conversations? | A single mention in one call | Raised independently in the last three customer conversations |
| Reversibility | If you build the wrong thing here, how expensive is it to walk back? | A config toggle or copy change | A data model or integration commitment you're stuck with for a year |
A request that's high-reach and high-recurrence but low-reversibility earns real scrutiny before it earns a sprint. A request that's low-reach but instantly reversible is cheap enough to just try. This is the same instinct behind ICE and RICE scoring, but built for the specific moment when you have three named customers in front of you instead of an anonymous backlog: reach, recurrence, and reversibility answer "does this actually matter" before you touch a scoring formula at all.
What Founders Get Wrong Here
The most common mistake isn't picking the wrong feature. It's building a small piece of every request to avoid disappointing anyone. That produces three half-features instead of one whole one, and none of your three customers actually gets what they needed. They get 30% of it, which functionally reads as nothing.
The second mistake is treating the highest-paying or most recently-signed customer's request as an automatic tiebreaker. Revenue matters, but a single customer's request isn't a market signal until something else corroborates it. If reach and recurrence are both low, you're not prioritizing a real pattern, you're doing that one account's professional services for free.
Information Gain: Reading Conflicting Requests as a Signal About the Product, Not Just the Backlog
Here's the part a generic prioritization framework won't tell you. The shape of your conflicting requests is itself information about where your product actually stands.
If your conflicts cluster tightly (different words, same underlying job), that's a sign your product has a clear identity and customers are just describing the same gap from different angles. That's a sequencing problem, and any of the standard frameworks (RICE, ICE, MoSCoW, or the Kano model) will resolve it fine once you've translated the requests into the same underlying job.
If your conflicts are genuinely orthogonal (one customer wants a reporting layer, another wants a lighter-weight tool, a third wants deeper integrations), that's not a backlog problem at all. That's your ICP not being narrow enough yet. Founders usually reach for a prioritization framework at exactly the moment they actually need to narrow who they're building for. Running the reach/recurrence/reversibility weighting above on your last quarter of requests will tell you which situation you're actually in, because tightly-clustered high-reach requests look completely different on that grid than scattered, mutually exclusive ones do. That grid is diagnostic before it's decisive.
The One-Sentence Version
Conflicting customer requests are not a tiebreaker problem. They're a translation problem: the job to be done is usually more consistent across customers than the words they use to describe it, and the fastest way to a defensible decision is finding that shared job before you rank anything.
Where This Fits Into a Weekly Decision Process
This isn't a one-time exercise. Conflicting requests show up every week that you talk to customers, and the reach/recurrence/reversibility grid works best as a standing five-minute check rather than a special process you reach for only when things feel stuck. Founders running a structured weekly product decision process already have a slot for this: conflicting requests just become one more input that gets weighed against everything else on the table that week, not an emergency that derails it.
If you're deciding what to build next without a dedicated product team, the same underlying discipline applies whether you're triaging three conflicting requests or a full backlog: separate what's actually being asked from why it's being asked, then weight the pattern, not the volume of any one voice. Explore how P8's decide layer turns scattered customer requests into a single, weighted view without adding another tool to check.
