Everyone Was Right

The person who decided to add one more feature is rarely a bad actor. The problem is what happens when many separately reasonable decisions pile up.

Picture the roadmap meeting from our last piece. Twenty-three features queued for next quarter. Look at any one of them and there's no real argument against it. Customers have been asking for it. A competitor already shipped it. The data backs it up. No manager can easily veto a single item. And yet, once all twenty-three ship together, a first-time user has no idea what to press first.

The gap is strange for one reason: nothing about it involved a bad call. The trap of completeness doesn't come from poor judgment. It comes from judgment that was sound at every single step. So the question has to change. If no individual decision was wrong, what is it that pushes all these sound decisions in the same direction — always toward more?

The answer isn't one cause. It's four pressures: customers, competitors, the team, and fear. Each arrives from a different place, speaking a different language. Customers arrive as requests. Competitors arrive as comparisons. The team arrives as performance metrics. Fear arrives as silence. And all four converge on exactly one direction — add. What makes the completeness trap so persistent is that when all four fire at once, none of them gets challenged in the room.

One thing worth naming here: none of these four pressures comes from bad intent. Listening to customers, watching the competition, chasing results, not wanting to disappoint users — these are, in fact, the basic virtues of a good product team. The trap doesn't appear because these virtues are missing. It appears because each virtue is being maximized in its own corner, with no one positioned to reconcile them. Every department finishes its own optimization. The sum of all those finished pieces hardens into a shape nobody actually designed.

When the customer asks nicely

The hardest pressure to resist comes straight from the customer's mouth. Ignoring "it would be great if this existed" feels like ignoring the customer altogether. So the request itself often becomes reason enough to build. This is exactly where the listening trap and the completeness trap meet.

The problem is a mismatch of scale. Customers request features one at a time. No one who asks for a single feature can picture how the product will feel once every other request has also been granted. What they wanted was the feature — not the complexity that appears when all those features share one product. So granting every request, one by one, can end in building a product that, taken as a whole, nobody actually wanted.

The smartphone market before the iPhone ran exactly this experiment. Ask consumers back then what they wanted, and the answers were predictable: longer battery life, MMS, 3G, copy and paste. Phones that checked every one of those boxes already existed. And yet consumers chose the iPhone — a phone missing several of those things — over the fully-featured alternatives. The product that granted the most requests didn't win.

There's a quieter distortion layered on top. The requests that reach an organization don't represent customers evenly. The loudest, most frequent, most articulate voices land on the roadmap first. Requests that arrive through sales carry outsized weight. The moment one client on the verge of signing says, "we'll sign if you build this," that single voice outweighs the silence of a thousand people quietly using the product. Users who don't speak up don't get counted. What accumulates on a roadmap isn't the average of what customers want — it's closer to the sum of what the loudest minority wants.

This distortion isn't a flaw in how requests get processed. It's baked into the questions being asked in the first place. Customer interviews and satisfaction surveys almost always ask, "What would you like to see?" They rarely ask, "What in this product is currently in your way?" Ask only about addition, and only answers about addition accumulate. The research design itself is already tilted.

There's also an asymmetry in how rejection lands. Turn down a request to add something, and one identifiable person is disappointed — a visible, countable loss. The number of people who quietly left because the product had already gotten too complicated is invisible. An organization that can only feel one of these two losses spends its resources avoiding the one it can feel. The invisible loss always loses the budget fight.

Because the rival got there first

The second pressure comes from next door. When a competitor's product has a feature yours doesn't, the gap reads instantly as a deficiency. This is where the competitive trap pours fuel on the completeness trap.

What makes this pressure especially corrosive is how it accumulates. Every time a competitor ships something, an answering item appears on your own roadmap. Repeat this for a few quarters and the product quietly becomes a collection of the competitor's features — nothing especially excellent, every item slightly behind or roughly equal. And somewhere in that process, the thing that made people choose this product in the first place — its original edge — gets quietly diluted. Chasing the competitor ends up erasing the self.

This pressure hits hard precisely because it arrives in the language of fear, not logic. One question from the field — "why doesn't ours have what theirs does?" — and the item jumps straight to the top of the roadmap. Whether the feature actually closes deals, or how many customers would really leave without it, often goes unexamined. The feeling of falling behind is treated as evidence enough. And the same feeling runs in the rival's organization at the same time. When two teams watch each other and move on the same fear, the two products converge. Competition is supposed to make things more different. Often, it makes them more alike.

The feature comparison chart is where this pressure shows its face most clearly. A checked box is visible. How many people actually use that feature never appears on the chart. So decisions naturally drift toward "filling the chart." Filling a chart and making a good product are not the same task — but inside the meeting room, they keep getting treated as if they were.

The other face of this pressure is how the market gets scored by press and analysts. The moment a category comparison ranks products by feature checklist, that checklist quietly becomes the internal target. An external scoring standard ends up setting internal priorities — without anyone verifying how much that standard actually correlates with real user satisfaction.

The pull inside the team

The third pressure comes from inside the organization. Building something new gets recorded as a visible achievement. Removing or simplifying something that already exists rarely looks like an achievement at all. As long as performance gets measured in features shipped or updates released, this tilt isn't an accident — it's baked into the structure.

Subtracting carries no visible reward. All anyone sees is risk. Users of that feature are expected to complain, so the objections start inside the meeting room before the decision is even made. Both the incentive structure and the decision-making structure point the same way: toward addition. Not because teams are lazy — because the organization only applauds addition.

Personal motives layer on top. The person who built a feature gets to claim it — a credit, a line on a résumé. What does the person who removes a feature get to claim? More often than not, they're remembered as the one who admitted a failure. Sunk time and resources make it worse: proposing to kill something that took months to build sounds like declaring those months wasted. In the face of that sunk-cost feeling, "let's just leave it for now" is always the path of least resistance.

The deeper issue is that no seat on the org chart is explicitly responsible for the coherence of the whole product. Each team owns the polish of its own feature. Nobody owns how those features behave together on one screen, in one user journey — how the sum feels to someone opening the product for the first time. Every team can do its job faithfully and the whole can still grow heavier, precisely because that seat — the one looking at the whole — sits empty.

Why is subtracting scarier than adding?

The fourth pressure is fear itself. Whatever the feature, some group of customers cherishes it. However low the usage number, that minority's backlash is easy to picture and immediate. To avoid it, teams default to leaving the feature exactly as it is.

Make that choice once, twice, twenty times, and the result is singular: nothing ever gets removed. The product only ever grows in one direction. Addition is always permitted. Subtraction is put on trial every single time. Sustained long enough, this asymmetry costs an organization the muscle for subtracting altogether. When the moment truly calls for it later, there's no practice to draw on.

A second asymmetry hides inside this fear. When a feature disappears, the people who complain are visible — names, accounts, angry emails, bad reviews, all leave a trace. The people who quietly appreciate that the product got simpler, or the potential users who would have left because of that very complexity, leave no trace at all. Between the vocal minority and the silent majority, an organization always sides with the side it can hear. Accountability compounds the asymmetry: remove something and something goes wrong, and the person who made the call is easy to name. Leave something in and the product slowly gets heavier — and no one is ever named as the person who decided that. Doing nothing is always the safe choice.

Institutional memory keeps this fear alive long after the fact. A team that once removed a feature and faced a loud backlash carries that memory into every future removal conversation. "Remember what happened last time we cut that." One sentence, and it freezes every subsequent attempt before it starts. What fraction of the total user base that backlash actually represented, or how much the product genuinely improved afterward, rarely gets re-examined. One bad memory does the deciding for every judgment that follows.

When customers want it, competitors have it, the team wants to build it, and removing it triggers complaints — all at once — the decision not to add a feature is already an uphill fight.

What the four pressures share is that none of them gets challenged in the room. No one argues for ignoring customer requests. Few argue for ignoring the competition, giving up on performance targets, or accepting a vocal minority's anger. So the completeness trap doesn't arrive as an accumulation of bad calls. It arrives as the result of individually correct decisions lined up in the same direction. Nobody did anything wrong, and the product still gets a little heavier every quarter.

More precisely, these four pressures reinforce each other. A pile of customer requests gets cited as a competitive gap. That gap gets translated into a team's performance target. The feature built to hit that target becomes, for someone, indispensable. If only one pressure existed, the organization would have room to filter it out. When all four operate at once, citing each other, the point at which anything could be filtered simply disappears. That's why the completeness trap is a structural problem, not an individual mistake.

Which is why it's hard to blame the organizations that fall into it. This isn't a trap built by lazy teams — it's built by diligent ones. Responding faithfully to every request, watching the competition closely, chasing results diligently, caring about users diligently: that diligence is exactly what produces the trap. "Try harder" is not a prescription that works here, because trying harder is the cause. What's needed isn't more effort — it's a different standard for judging where that effort should go.

Noticing the structure is itself a first step. Knowing the pressures exist doesn't make them disappear. Customers will keep asking. Competitors will keep shipping something first. Teams will keep wanting to build. Backlash will keep feeling frightening. But knowing that these four aren't independent signals arriving from different directions — that they're a structure engineered to converge on the same conclusion — changes at least one thing. A meeting that used to ask only "why is this needed" starts asking a second question: "why does this feel needed." Need and the feeling of need are not the same thing. What manufactures the latter is, more often than not, one of those four pressures — not logic.

Next time a new feature comes up in a roadmap meeting, there's a question worth asking before asking whether it's justified. Which of the four pressures did this come from? And do we know that, or are we simply being carried along without noticing? Only once that question can be answered does the next one — what should we take out — start to mean anything.

Every added feature had a reason. That's exactly the problem.