The laundry list trap: why much of your roadmap doesn't matter

In one telco app, more than 40% of the candidate scope accounted for less than 2% of measured feature engagement.

At a European telco, we had a laundry list of features: the kind that accumulates when you ask stakeholders what they want. Fingerprint login. Detailed call itemization. Loyalty program integration. FAQ knowledge base. Live chat. Store appointment scheduling. The list went on.

Every feature had a champion. Every feature had a business case. Every feature felt important to someone.

How Laundry Lists Happen

The list grew because every request sounded reasonable on its own. Nobody was looking at the total cost.

Feature parity was the first source of scope. The old system had 47 features, so the new one was expected to carry all 47. Never mind that 30 of them were used by a handful of customers a handful of times.

Stakeholder wish lists pile on top. The marketing team wants campaign integration. The operations team wants fault reporting. The retail team wants store locators. Everyone gets something. Nobody prioritizes.

Competitive benchmarking added more. A competitor had a feature, so it entered our list before anyone checked whether customers used it. Edge cases added more scope: "But what about the customer who needs to do Z?" That customer exists. They're also 0.03% of your base. Should they drive your roadmap?

We ended up with a long list and no agreed way to decide what mattered.

What the usage showed

We did something that sounds obvious but rarely happens: we measured engagement across every feature before deciding what to build next.

Not "will stakeholders approve this?" Not "does this fill a gap in our competitive matrix?" Actual customer behavior. What do people use? What do they ignore?

The usage did not match the roadmap.

Features that felt important (live chat, detailed billing breakdowns, fault ticket creation) barely registered. Customers had asked for these things. Stakeholders had fought for them. And when we built them... crickets.

Meanwhile, the boring stuff dominated. Checking usage. Making payments. Viewing bills. The core jobs that brought people to the app in the first place.

What Actually Matters

In this product, three jobs accounted for most of the measured engagement:

Payment and billing. This produced about 35% of the measured engagement. Customers came to check what they owed and pay it, so that journey deserved more attention than the feature list gave it.

Usage monitoring. This produced another 30%. Seeing what was used, what remained, and what the plan included was one of the app's main jobs.

Onboarding. Yes, this matters, but I list it third deliberately. Most organizations already have something here. It's table stakes, not differentiator. If you're building a digital product without onboarding, you have bigger problems than prioritization.

Everything else? Evaluate ruthlessly. That loyalty program integration might wait. The live chat might not be as urgent as the chat vendor claims. The detailed call itemization that three customers requested might not be worth the development time.

The Prioritization Mindset

I would not turn this into another scoring framework. Start with customer behavior, then add compliance, strategy, and delivery cost.

Start with behavior, not requests. What are customers actually doing? Usage data is a better starting point than a stakeholder vote, but it is not the only input. Compliance, poor discoverability, and deliberate strategic bets still need judgment.

A low-use feature still adds maintenance, testing, and another decision to the interface. That cost belongs in the roadmap discussion.

Question "must-haves." When someone says a feature must be there, ask: who needs it? How many customers? How often? What happens if we don't build it?

Some requests will not make the roadmap. That is the result of prioritization, not a failure of it. Measure after launch. Track engagement on what you build. Be willing to sunset features that don't perform. Don't let sunk cost fallacy keep dead features alive.

The Uncomfortable Conversation

The difficult part starts when a stakeholder's feature does not make the cut.

The Head of Retail really wants that store appointment feature. The data says store locator gets 0.3% engagement. That conversation is awkward.

But the alternative is worse. Build everything everyone wants, and you'll ship late, over budget, with an app so cluttered that the features people actually need get buried.

I use the data to move the discussion away from who requested the feature. The question becomes whether the observed customer value justifies the cost.

Some stakeholders won't accept it. That's a leadership problem, not a product problem. Escalate if needed. But don't compromise the roadmap to avoid difficult conversations.

When to Break the Rule

Data-driven prioritization isn't absolute. Sometimes you build low-engagement features anyway.

Compliance is the clear one. If a regulation requires a feature, engagement is irrelevant. Build it.

Discoverability is trickier. Sometimes a feature has low engagement because it's buried four clicks deep, not because it's unwanted. Before cutting a feature, check whether the UI is hiding it. A poorly placed feature and an unwanted feature look identical in the data.

Then there are strategic bets. Maybe the loyalty program has low engagement now because the experience isn't good enough. A redesign might change that. But be honest: is this a strategic bet or a stakeholder appeasement? Same with foundation features: some enable other features. Low engagement today might turn into high engagement tomorrow. Track this, don't just assume it.

Low engagement is a reason to check compliance, discoverability, strategic value, and cost before rejecting the feature.

The Result

When we cut that 40% of scope, the team had more time to build and test the core journeys. We did not measure whether customers noticed the missing features after launch, so I would not claim they did not.

The Question to Ask

Before adding anything to your roadmap, ask this: "If we don't build this, what happens?"

If the answer is "some customers will be mildly inconvenienced," maybe it can wait. If the answer is "we'll lose customers to competitors," dig deeper, because that's usually a nice-to-have dressed up as a must-have.

If customers cannot complete the core job without it, build it first.

Most features fall into the first two categories. Build the third first, then check the usage data after launch.

A product team needs to say no when the evidence is weak. Stakeholder needs matter, but they do not replace customer outcomes.