Treat Deliberate Exclusions as Product Decisions

I have seen plenty of product strategies that describe what a product will do and say almost nothing about what it will refuse to do. That omission looks harmless until a large prospect asks for an exception, a competitor launches another feature or a new technical capability becomes easy to add.

Then the backlog starts making the strategy by default.

Several current developments point in the opposite direction. A basic e-reader can still be attractive precisely because it lacks the distractions and extras of a more capable device. Some parents are looking for phones that deliberately offer less. A compact speech model can be interesting because of where it can run, not because it wins every benchmark. At the same time, signs of slower growth in company AI spending suggest that access to more capability does not automatically produce more willingness to pay.

The pattern is straightforward: absence can be part of the value proposition.

Product teams rarely manage it that way. We call a limited product an MVP, which implies that its missing features are waiting to be added. We describe a simpler plan as entry-level, which positions it as an incomplete version of the real product. We keep rejected requests in the backlog, where they remain available for resurrection without anyone having to revisit the original reasoning.

I think deliberate exclusions deserve the same attention as roadmap commitments. If a product is designed for focused reading, reduced functionality is not technical debt. If a phone is designed to give children more independence without unrestricted access, its limits are not gaps. If a model is designed to run locally with modest resources, a smaller footprint may matter more than broad capability.

This also applies to ordinary business software. Imagine a reporting product for regional managers. One customer asks for raw query access, another wants a visual report builder and a third wants automated recommendations. Each request is defensible in isolation. Together, they turn a clear operational product into a database tool, a business-intelligence suite and an advisory system.

The usual prioritisation process is not enough here. Scoring each request separately hides the cumulative change in the product’s identity. A feature can have a positive business case and still make the overall product worse.

I would therefore expect a product strategy to include a small set of explicit exclusions. Not vague statements such as “keep it simple,” but concrete boundaries: we will not support unrestricted customisation; we will not become the system of record; we will not automate the final approval; we will not serve users outside this operating context.

Those boundaries should not be permanent dogma. They should state what evidence would justify reconsideration. A sustained pattern in lost deals may be evidence. Repeated failure by active customers to complete the core job may be evidence. One executive request, a competitor announcement or the availability of a new model is not enough by itself.

This approach also improves metrics. Product organisations often complain that dashboards become noisy, but feature sprawl causes measurement sprawl. Every new workflow creates more events, more segments and more possible explanations for movement in retention or conversion. A narrower product gives a team a better chance of understanding why customer behaviour changed.

It can improve learning from churn as well. When departing customers consistently need something the product intentionally excludes, the conclusion is not automatically to build it. The better conclusion may be that positioning, qualification or packaging is attracting the wrong customer. Sometimes churn confirms a boundary instead of disproving it.

Building faster makes this discipline more important, not less. When an addition takes months, its cost forces a serious conversation. When it takes days, the conversation is easy to skip. The result is a product assembled from individually reasonable decisions that no longer adds up to a coherent whole.

I want teams to be proud not only of what they shipped, but also of what they kept out. A product’s shape is defined by both. If exclusions remain implicit, they will eventually be negotiated away one request at a time.