Should You Build This Feature? A B2B Product Prioritisation Framework

Most product teams don't suffer from a shortage of ideas. They suffer from too many apparently reasonable reasons to build them.

A large customer asks for something. Sales says a missing capability cost a deal. A competitor launches a feature. Leadership sees an opportunity. Usage data reveals a problem.

Before debating scope, effort or where something sits on the roadmap, establish whether the problem deserves solving at all.

The three questions before "how do we build it?"

Start with three questions.

1. Who is this for? Not "our customers". Which customers? How many? What characteristics do they share?
2. What changes for them? What problem disappears, becomes easier or produces a better outcome?
3. What changes for the business? Does it improve acquisition, conversion, retention, expansion, margin, differentiation or another strategic objective?

If those answers aren't clear, estimating development effort is premature.

Signals a feature will genuinely move the needle

Strong feature opportunities usually have evidence behind them. The same problem appears across several relevant customers. Behavioural data supports what customers are telling you. The problem prevents users achieving an important outcome. It repeatedly contributes to churn or lost opportunities. Solving it strengthens something the product is already supposed to be good at.

The evidence doesn't need to be perfect. But there should be more than enthusiasm.

That's particularly important in B2B because a single customer can have disproportionate influence over the roadmap.

Signals it's a distraction

Some of the most dangerous roadmap requests sound commercially urgent: "We lost a major deal because we don't have this." "Our biggest customer says they need it." "Our competitor just launched it." "The CEO wants it."

Every one of those statements deserves investigation. None automatically means you should build the feature.

A lost deal may have had several causes. A major customer may have an unusual operating model. A competitor may be serving a different market. Leadership may be working from an untested assumption.

Treat each as evidence to investigate, not an instruction to build.

The "shadow of the loudest customer" problem

Large customers create gravity. They have commercial importance, access to senior people and the ability to make requests feel urgent. Over time, a product can begin orbiting around a handful of those customers.

That's when roadmap decisions become dangerous. You build something highly specific. Another large customer needs a variation. Sales begins selling the custom capability. Support complexity increases. The product slowly becomes harder to maintain and less coherent for everyone else.

This doesn't mean ignoring strategic customers. It means separating customer importance from problem prevalence.

Ask whether the request reveals a broader problem within the market you want to serve. If it does, solve that broader problem well. If it doesn't, make an explicit commercial decision about whether the exception is worth the cost.

Prioritisation frameworks that survive real trade-offs

RICE, ICE and value-versus-effort matrices can all be useful. None of them replaces judgement.

RICE can make assumptions visible by forcing a team to discuss Reach, Impact, Confidence and Effort. But if Reach is guessed, Impact is optimistic and Confidence is arbitrary, multiplying those numbers together doesn't turn them into evidence.

The value of a prioritisation framework isn't the score. It's the conversation the inputs force you to have.

A good product decision combines evidence, strategic fit, customer impact, business impact, confidence and effort. The framework helps structure that decision. It shouldn't make it for you.