Every feature must earn its place

Most product roadmaps are lists of things to build. Few are lists of things that deserve to exist.

I've shipped more than 40 mobile apps. The ones that failed rarely failed because we didn't build enough. They failed because we built too much of the wrong thing, and not enough of the right one.

The earning test

Before any feature ships, I ask four questions:

1. What behavior does this create? Not what it does, what the user does differently because it exists.
2. What does it cost? Not just engineering time. Attention, complexity, maintenance, support burden, cognitive load.
3. What would we remove if we had to? If you can't answer this, you don't understand your product's priorities.
4. Would anyone notice if it disappeared? Be honest. Most features wouldn't.

If a feature can't pass all four, it doesn't ship. Or it ships later, after something more fundamental earns its place first.

Feature debt is worse than tech debt

Engineers talk about technical debt constantly. Product teams rarely talk about feature debt: the accumulated weight of things that seemed like good ideas in a sprint planning meeting but never created a habit, never reduced friction, never made anyone's life meaningfully easier.

Feature debt shows up as:

• Settings screens nobody opens
• Onboarding flows that explain features nobody uses
• Navigation tabs added for stakeholder balance, not user need
• "Phase 2" items that became permanent clutter

Each one seems small. Together they signal something to users: this product doesn't know what it is. And when a product doesn't know what it is, people stop trusting it.

The stakeholder feature

In government and enterprise work, features often exist because someone with budget authority asked for them. Not because a user needed them. Not because data supported them. Because they were politically necessary.

I understand the reality. I've navigated it across public-sector apps and regulated environments. But I also know that every stakeholder feature you accept without a behavior case is a tax on every user who didn't ask for it.

The best product leaders I've worked with don't say no to stakeholders. They translate requests into behavior outcomes and make the tradeoff visible: "We can add this, but it means delaying the fix that's causing 40% of users to abandon checkout. Which matters more?"

Subtraction as strategy

My favorite product work isn't adding, it's removing. Finding the three things a product should do and stripping everything that competes with them.

When I helped rebuild app ratings from 3 stars to 4+ on products I'd inherited, the wins rarely came from new features. They came from removing friction, fixing the first-run experience, and making the core loop obvious.

That's not glamorous work. It doesn't make good keynote slides. But it's the work that changes whether people come back.

What I'm still learning

I don't always get this right. Sometimes I ship things that don't earn their place because speed mattered more than discipline. Sometimes a feature I defended turns out to be noise.

The filter isn't about perfection. It's about intention. Every feature should be able to explain why it exists in one sentence that starts with a verb a user would recognize, not a capability a vendor would list.

Great products are designed around behavior, not requirements documents.

Hold every feature to that standard. Most won't make it. That's the point.