There's a specific moment in a product's life that I've come to recognise. Nobody rings a bell or sends a memo. But it's the moment where a product becomes about everything people have asked for and the original point of it recedes into the background.
I've watched this happen across a portfolio of over fifty large-scale digital products. I've sat in the post-mortems afterwards. And the consistent lesson is that feature creep starts as a decision-making problem. It happens when organisations lose the ability to say no, or never build that ability in the first place.
How it starts
The usual story is that someone is close to the customer. That's a good thing. A salesperson hears a request. A support agent sees a pattern. A key account says, "if only the product could also do X." And because the organisation values responsiveness, because it's genuinely trying to be customer-oriented, someone says yes.
Then it happens again. And again. And each individual yes seems reasonable, because each individual request has a real customer behind it. The backlog fills up with legitimate-sounding items, each with a name and a business case attached.
But nobody is asking the harder question: does this fit what this product is actually for?
This is where customer orientation and strategic coherence part ways. Doing everything customers ask for is a reaction pattern dressed up as strategy.
Uncritical customer orientation is strategic drift with good intentions.
What makes it hard to see
One reason this pattern is so persistent is that it feels virtuous. Nobody gets fired for being responsive. Nobody gets called out in a review for saying yes to a customer. The incentive structure in most organisations rewards addition over subtraction. Every new feature has a visible advocate in the room. Restraint has none, and the person who benefits from a coherent experience (the end user) isn't in the room either.
The other thing that makes it hard to see is that the product doesn't collapse overnight. It degrades gradually. The interface gets busier. The onboarding gets longer. The messaging gets vaguer because the product no longer has a single clear promise. It has twelve. And at some point, somebody in leadership looks at retention or NPS or market feedback and says: "why aren't people excited about this anymore?"
They were excited. They just couldn't find the thing they came for under everything that was piled on top.
The "our audience is everyone" trap
Underneath most feature creep is a deeper problem: the product doesn't have a clear definition of who it's for.
When I work with product teams, one of the first things I try to establish is the boundary of the audience. Who is this not for? What expectations are we explicitly choosing not to serve? That sounds negative, but it's actually the most protective thing you can do for a product. Without a boundary, messaging and design choices lose coherence. Everything seems plausible because there's no filter to test it against.
I've seen projects drift for months, sometimes years, because the audience definition was generous enough to accommodate almost any feature request. "Our audience is broad" becomes the justification for every addition. And slowly, the product becomes a negotiated compromise between internal stakeholders rather than a coherent promise to a real person with a real need.
"Our audience is everyone" means you haven't made a strategic choice yet.
Feature lists masquerading as strategy
A related pattern I've seen many times: the product's "strategy" is actually a feature list. There's a roadmap, there are milestones, there's a backlog, but no articulation of what this product promises to be in a way that could survive a conversation with someone outside the building.
This matters because features don't create coherence. The user doesn't see the backlog or the roadmap. They see a product that either makes sense or doesn't. One that either delivers on a recognisable promise or feels like a collection of capabilities looking for a purpose.
The alternative is what I'd call experience pillars: three to five statements that express the product's promise in plain language, grounded in real user needs, and specific enough to guide design choices. Specific enough to tell you what to build and what not to build.
When pillars like this exist and are genuinely shared across product, design, marketing, and leadership, they become a filter. A new feature request arrives and the question becomes: does this strengthen one of our pillars, or does it dilute them? Most organisations never have that conversation because the pillars were never established in the first place.
What overconfidence does to the filter
There's another force that breaks the filter, and it's subtler: success.
When a product has done well, when a previous version was a hit or the company has a strong track record, something happens to the organisation's ability to be critical of its own choices. The sensors that would normally catch drift get deactivated. Assumptions that should be questioned get carried forward as facts. And the feature list grows because the team believes it can pull off more than it actually can.
I've been in post-mortem rooms where this was the core finding. Confidence from a previous success had inflated the ambition of the next project beyond what the evidence supported. The product lost its core gradually, because everyone felt safe enough to stop checking whether it was still holding together.
This is why I've come to think of insights and research governance as an immune system for the organisation. Its job is to keep people honest about what they actually know versus what they're assuming. When that immune system gets weakened (by success, by time pressure, by political dynamics) drift becomes almost inevitable.
The product lost its core because everyone felt safe enough to stop checking.
What helps
I'm not going to pretend there's a framework that solves this. But after twenty years of working inside product organisations, I've seen a handful of mechanisms that consistently separate the products that hold their shape from the ones that don't.
Define who it's not for. Define the expectations you're choosing not to serve. Write them down. Share them. When a feature request arrives that serves a non-target need, you have a reason to say no that feels grounded rather than arbitrary.
Build a needs hierarchy. Separate table-stakes (must work, or people leave) from differentiators (why they choose you) from nice-to-haves (pleasant, but not load-bearing). Then prioritise accordingly. A needs hierarchy survives stakeholder pressure in a way that a flat backlog never will, because it makes the reasoning visible.
Make experience pillars the filter. Three to five plain-language statements about what this product promises to be. Working filters that show up in prioritisation meetings, greenlight conversations, and production planning. If a proposed feature doesn't strengthen a pillar, it needs a very good reason to exist.
Put decision gates on inbound requests. Separate the strategic backlog from the day-to-day request stream. Some customer requests are strategic. Some are operational. Some are neither. The act of sorting them, in public, with shared criteria, is itself a corrective against drift.
Name the tradeoff. The most useful output of a strategy conversation is "what we're going to be average at on purpose." If we want to win on X, we accept being adequate on Y. Most teams find this uncomfortable. But being great at something requires accepting that you'll be ordinary at something else.
The hardest part
None of the above is technically difficult. The tools exist. The models exist. The hard part is organisational: creating the conditions where people can say "no, that doesn't fit" without it being read as negative, disloyal, or obstructive.
That's a culture question, and it's where I've spent most of my career. Designing the context in which evidence actually changes decisions. Building shared language. Running the rooms where difficult tradeoffs get made. Making it safe to be the person who says, "I know this sounds good, but it breaks the promise."
Products lose their core in a thousand small moments where the easier thing was to say yes. Getting those moments right is a system design problem. And systems, like products, need maintenance.
A product loses its core in a thousand small moments where the easier thing was to say yes.