# The Laundry List Trap: Why Half Your Roadmap Doesn't Matter

**Author:** Ivan Misic  
**Published:** 2026-02-12  
**URL:** https://ivanmisic.net/blog/product/laundry-list-trap-prioritization

> We analyzed engagement across an entire app feature set. Over 40% of the scope generated less than 2% of engagement. This is how to avoid building features nobody uses.

> Less than 2%. That's how much engagement over 40% of our planned feature scope generated. Not 20%. Not 10%. Less than 2%.

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.

And collectively, they accounted for barely over 1% of actual customer engagement.

## How Laundry Lists Happen

Nobody sets out to build features customers won't use. But laundry lists form naturally through reasonable-sounding processes.

**"Feature parity" thinking.** The old system had these 47 features. The new system needs all 47. Never mind that 30 of them were used by a handful of customers a handful of times.

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

Then there's competitive benchmarking. Competitor X has feature Y, so we need feature Y too - even if their customers don't use it either. And edge case accommodation: "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?

The result is a list of everything anyone could possibly want, with no clear signal about what actually matters.

## The Data Doesn't Lie

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 findings were uncomfortable.

| Feature Category | Expected Value | Actual Engagement |
|-----------------|----------------|-------------------|
| Payment & billing | High | ~35% of all engagement |
| Usage monitoring | High | ~30% of all engagement |
| Onboarding flows | Medium | ~20% of all engagement |
| Loyalty integration | High (stakeholder view) | <3% |
| Live chat | Medium | <2% |
| Store features | Medium | <1% |
| Detailed itemization | Low | <1% |

Features that felt essential - 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.

## The Balance Metaphor

Think of your roadmap as a scale. On one side: business value (revenue, cost reduction, strategic positioning). On the other side: customer value (problems solved, time saved, friction removed).

Every feature tips the scale one way or the other. Some features serve both. Many serve one at the expense of the other.

The trap is building features that serve neither - features that exist because someone asked for them, not because they create value.

> When you add a feature that generates minimal engagement, you're not just wasting the build cost. You're adding maintenance burden, complexity, and distraction. You're making the app harder to understand. You're slowing down future development.

Every button you add to a screen makes the "Pay Bill" button slightly harder to find. And you're tipping the scale toward bloat without moving the needle on value.

## What Actually Matters

Based on this analysis and others like it, the engagement lives in three places:

**Payment and billing.** This is why customers open the app. Can they see what they owe? Can they pay easily? Is the experience smooth? If you get this wrong, nothing else matters. Modern customers expect one-tap payment with saved cards. Anything more friction than that feels broken.

**Usage clarity.** Customers want to understand what they're paying for. How much data did I use? Am I close to my limit? What's included in my plan? Make this clear and accessible, and you've solved one of the biggest anxiety points.

**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](/blog/digital-transformation/stop-trying-to-digitalize-everything). 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

This isn't a rigid framework. It's a mindset shift.

**Start with behavior, not requests.** What are customers actually doing? Usage data beats stakeholder opinions every time.

**Question "must-haves."** When someone says a feature is essential, ask: essential for whom? How many customers? How often? What happens if we don't build it?

Accept that some things won't get built. A prioritized roadmap means saying no. If everything is priority one, nothing is. And 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 hard part is telling stakeholders their feature isn't making the cut. I've had this exact conversation more times than I can count.

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.

The data gives you cover. "We analyzed engagement patterns, and here's what we found." It's not personal. It's not political. It's evidence.

Some stakeholders won't accept it. That's a [leadership problem](/blog/digital-transformation/renaming-it-to-product-didnt-fix-anything), 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.

**Regulatory requirements.** If compliance requires a feature, engagement is irrelevant. Build it.

**Discoverability problems.** 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 unlock high engagement tomorrow. Track this, don't just assume it.

You're not rejecting everything that lacks proven engagement. You're making conscious choices rather than defaulting to "build everything."

## The Result

When we cut that 40% of scope, nothing bad happened.

Development accelerated because the team focused on fewer things. Quality improved because attention wasn't scattered. The features that shipped were better because they got more investment.

And customers? They didn't notice the missing features. They noticed that the app did what they needed, quickly and well.

And that's the goal. Not a feature list that impresses on paper. An experience that works in practice.

## 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.

But if the answer is "customers literally cannot accomplish their core goal" - now you're talking.

Most features fall into the first two categories. Build for the third. The data will thank you.

---

*The best product teams I've seen share one trait: they're comfortable saying no. They care about stakeholder needs, sure. But they care more about customer outcomes.*