Deciding What Not to Build

A product discipline for handling feature requests

Of course everyone says they build based on customer needs. Of course.

But much of what gets built starts from feature requests that go unchallenged.

A request arrives. It sounds reasonable. It sounds specific. Sometimes it even sounds urgent. And because it sounds like work, it quickly turns into a ticket, then a roadmap item, then something that feels increasingly hard to question.

That’s usually where the discipline ends.

Feature requests are already proposed solutions. They reflect how the requester currently understands their situation, using the tools and language they already have. That doesn’t make them wrong. But it does mean they’re incomplete by definition.

Product work begins when you resist the urge to accept the solution and instead slow the conversation down.

The most important question is not “how fast can we build this?”
It’s “what problem are we actually trying to solve?”

When that question isn’t asked, products drift.

They accumulate features that address local, short-term frictions while slowly losing coherence. Over time, the product becomes more flexible on paper and harder to understand in practice. More capable, but less clear about what it is actually for.

This is not a customer failure. It’s a product one.

Challenging a feature request doesn’t mean pushing back aggressively or dismissing stakeholders input. It means doing the harder, quieter work of understanding what would be different if the issue were truly solved. What would stop happening? What workarounds would disappear? What decisions would become easier?

If the strongest justification for a feature is “someone asked for it” or “others already have it,” judgment has already been outsourced.

The same discipline applies internally.

Every item added to a roadmap is a choice about what the product is becoming. Roadmaps are not neutral planning tools. They encode priorities, trade-offs, and beliefs about what matters. Once something is on the roadmap, it competes for attention, design effort, engineering time, and long-term complexity.

This is why saying yes too easily is risky.

A roadmap should be subordinate to a clear product mission. When the mission is explicit, many requests disqualify themselves. When it’s vague, almost everything sounds relevant.

This is how products quietly turn into universal tools. Configurable. Customizable. Able to do many things. Exceptional at none.

One of the most important product skills is knowing when to say no. As Steve Jobs once said, “deciding what not to do is as important as deciding what to do.” Because focus is fragile. Every yes carries a cost, and most of that cost shows up later: in maintenance, in cognitive load, in a product that becomes harder to explain and harder to evolve.

Some of the best product decisions are invisible. They’re the features that never shipped because they didn’t fit. The requests that were understood, acknowledged, and deliberately not implemented.

This isn’t about ignoring customers. It’s about respecting them enough to solve the right problem, not just the first solution they propose.

Good products are not built by accepting every reasonable request. They’re built by maintaining a clear sense of purpose and exercising judgment under pressure.

The real question is rarely “can we build this?”
It’s “should this exist in this product at all?”

Answering that consistently is not instinct.
It’s discipline.