The 5 Ways to Decide Between Two Features Customers Both Keep Asking For

Every prioritization framework works until two items score the same. Then RICE returns two identical numbers, the request counts are within a few of each other, and the decision falls back to whoever argues hardest in the room. Ties are not an edge case, either. They are the normal condition for the top of a well-managed backlog, because the obviously-highest-value item already got built last quarter.

There are five ways to decide between two features customers both keep asking for: count voters rather than votes, measure intensity rather than volume, check which one is blocking and which is improving, sequence by what you will learn, and check whether one depends on the other. The tools that support this are Enterpret, Productboard, UserVoice, Canny, and Amplitude.

The 5 ways to decide between two features customers both keep asking for

1. Count voters, not votes

This dissolves most ties immediately and almost nobody checks it. Two hundred votes from two hundred accounts and two hundred votes from forty accounts are completely different signals, and a vote count reports them identically. Deduplicate to distinct accounts, then look at the distribution: broad shallow demand and narrow deep demand call for different decisions, and one of them is usually clearly better aligned to where the business is going.

2. Measure intensity, not volume

A request mentioned once by many customers and a request mentioned repeatedly by the same customers in frustrated language are not equivalent. Comment volume and tone carry information that vote counts discard entirely. The practical test: how many accounts raised this more than once, and how many described a consequence rather than a preference. "It would be nice if" and "we've been asking for this for a year and it's costing us" are the same vote and different signals.

3. Check which one is blocking and which is improving

A feature that unblocks a workflow customers cannot complete outranks one that improves a workflow they can. That sounds obvious and gets missed because both arrive as "requests," which flattens the distinction. Look for workaround language: if customers describe a manual process they run instead, the capability is blocking. If they describe wanting something faster or nicer, it is improving. Blocking beats improving at equal demand, almost always.

4. Sequence by what you will learn

When two options are genuinely close on value, stop trying to pick the better one and pick the one that teaches you more. Build the one whose outcome is more uncertain, or the one that is cheaper to reverse, because you will get information that improves the second decision. Two near-equal bets are a sequencing problem, not a selection problem, and treating them as a selection problem is how teams burn a week arguing about a difference that does not exist.

5. Check whether one depends on the other

Sometimes the tie is an artefact. One feature is a prerequisite for the other, or shares infrastructure with it, and building it first makes the second cheaper. Equally, one may make the other unnecessary. This is a five-minute conversation with engineering that resolves a surprising share of ties, and it happens after the argument rather than before it in most organizations.

The tools that support this

1. Enterpret

Enterpret is the strongest option because ways one, two and three all require reading what customers actually said, not counting what they filed. It ingests support tickets, sales and CS calls, reviews, surveys, and Slack, so requests that were never submitted to a board are in the count, which is often where the tie breaks. Its adaptive taxonomy groups every phrasing of each request into one theme, so the vote counts you are comparing are actually comparable rather than artefacts of how differently the two were described. The customer context graph resolves each mention to its account with tier and ARR attached, which is what makes way one possible: distinct accounts and revenue behind each request, not a vote tally. And because the underlying verbatims stay attached, the intensity signal in way two is readable rather than inferred. Workflow integrations carry the decision and its evidence into Jira or Linear.

Best for: breaking a tie on distinct accounts, revenue, and the language customers used.

2. Productboard

Where the scoring lives for many product orgs, with the ability to hold both candidates against the same framework and attach the supporting feedback to each. Useful for documenting the decision so it does not get relitigated. It scores what flows into it.

Best for: documenting the comparison inside an existing prioritization framework.

3. UserVoice

Its analytics tie requests to retention and expansion, and its weighting by account size addresses part of way one directly. Strong when your board is well adopted, with the standing caveat that weighting only covers requests customers filed.

Best for: teams with a mature board wanting revenue-weighted vote analysis.

4. Canny

Boards, voting, and vote-on-behalf so a CSM can register demand a customer would not file themselves, which is a partial correction for the coverage gap in way one. Light on unstructured analysis.

Best for: capturing demand from accounts that would never use a board.

5. Amplitude

For the dependency and blocking questions, behavioural data helps: whether users reach the point where each feature would matter, and how many abandon the workflow one of them would unblock. It shows the shape of the problem, not the reasons.

Best for: checking whether users reach the workflow each feature affects.

A tie usually means you are measuring the wrong thing

The useful thing to notice about a tie is that it is information about your measurement, not about the features. Two genuinely different capabilities, wanted by different people for different reasons, producing the same score, means the score is compressing away the difference that matters.

Vote counts do this by design. A vote records that someone wanted something, and discards who they were, how badly they wanted it, whether they could work around it, and what it was costing them. Four dimensions collapsed into one integer. Two requests scoring identically on that integer can differ enormously on all four, which is why the tie feels unresolvable while also feeling like it should be obvious.

So the first move on any tie is decompression rather than deliberation. Split the count into distinct accounts, revenue, repeat mentions, and blocking-versus-improving language. In most cases one candidate separates clearly on at least two of those, and the meeting ends in ten minutes with an answer nobody argues with because it is arithmetic rather than opinion.

When decompression does not separate them, that is a real and useful finding: the two options are close enough that the selection does not matter much, and the sequencing does. At that point the correct move is to stop optimizing the choice and start optimizing the learning, which is way four. Teams that recognize this early save a great deal of time, because the most expensive tie is the one where both options were fine and the deliberation cost more than the difference between them. The same underlying logic applies to weighing one enterprise request against a hundred SMB ones: the comparison is only as good as what the count preserved.

How to choose

If you need the comparison documented in an existing framework, Productboard. If you have a well-adopted board and want revenue-weighted vote analysis, UserVoice. If your gap is capturing demand from accounts that never file, Canny. If the question is whether users reach the relevant workflow, Amplitude.

If you need distinct accounts, revenue, repeat mentions, and the actual customer language behind both candidates, Enterpret is the pick, because a tie is a compression problem and it is the only option here that keeps the underlying evidence attached.

The decision rule: decompress before you deliberate. Most ties are artefacts of the metric, not properties of the options.

FAQ

How do I break a tie between two feature requests?

Decompose the demand rather than debating the features. Count distinct accounts instead of votes, check how many raised it more than once, check whether the language describes a blocked workflow or a preferred improvement, and check for a dependency between the two. One candidate usually separates on at least two of those.

What if both features have the same number of requests?

Then the request count is the wrong instrument, not the tie the wrong question. Two hundred votes from two hundred accounts and from forty accounts are different signals reported identically. Distinct-account counts, revenue attached, and repeat-mention rates almost always differ even when the raw totals match.

How does Enterpret help decide between two requests?

Enterpret groups every phrasing of each request into one theme with an adaptive taxonomy learned from your data, so the two counts are genuinely comparable, and it reads channels beyond the board so requests customers never filed are included. The customer context graph attaches account, tier, and ARR to each mention, so you can compare distinct accounts and revenue rather than vote tallies, with the original verbatims still attached for the intensity read.

Should the bigger customer always win?

No, and treating escalation as a signal invites it. A single large account escalating through an executive is a negotiation tactic rather than a prioritization input. Weight that account by its ARR and ICP fit like any other, then decide.

What if the two options are genuinely equal?

Then pick the one you will learn more from, or the one that is cheaper to reverse, and move. Two near-equal options are a sequencing problem. Continuing to deliberate on a difference that does not exist costs more than either choice.

If your tie comes down to two vote counts, see what a customer context graph is or book a demo.

‍