In 2021, a team of researchers at the University of Virginia published a study in Nature that should concern every product manager. When participants were asked to improve a structure, 59% added new components rather than removing one, even when removing a single piece was the simpler, more effective fix. Gabrielle Adams, Benjamin Converse, Andrew Hales, and Leidy Klotz called this “subtraction neglect”: a cognitive bias toward accumulation that operates below conscious awareness.
Product teams exhibit the same bias. They accumulate features, processes, meetings, integrations, and architectural choices over months and years. What they rarely do is go back and ask whether the decisions that created those layers still hold.
Every Decision Belongs to a Specific Moment
Product decisions are not permanent truths. They are conclusions drawn from a set of conditions: the competitive landscape at the time, the data available, the team’s capacity, the customer segment being served, the constraints of the quarter.
A pricing model chosen in 2023 reflected 2023 unit economics. A feature bundling decision from Q3 last year reflected Q3’s competitive pressure. An API architecture choice from 18 months ago reflected the integrations that mattered then.
Conditions change. The decisions do not update themselves.
Jeff Bezos framed this well in his 2016 letter to Amazon shareholders when he distinguished between Type 1 decisions (irreversible, requiring careful deliberation) and Type 2 decisions (reversible, worth making quickly with roughly 70% of the information you wish you had). What Bezos did not emphasize is that the boundary between Type 1 and Type 2 shifts over time. A decision that was easily reversible at launch can become deeply embedded in user workflows, partner contracts, and team structure within a year. By the time someone asks “should we revisit this?”, the cost of reversal has often grown far beyond what anyone anticipated.
Three Conditions That Cause Decay
Not every old decision is a bad one. Many hold up indefinitely. The skill is recognizing what causes decay.
The market moved. A competitor launched a feature that changed user expectations. Regulatory requirements shifted. A technology that was experimental when you chose your approach is now production-grade and cheaper. The strategic context in which the original decision made sense no longer exists. Teams that run a regular competitive position check catch this earlier than teams that do not.
The team changed. When the person who made a decision leaves, so does the reasoning behind it. The Bureau of Labor Statistics documented 5.1 million total job separations in November 2025 alone, including 3.2 million voluntary quits. At that churn rate, the person who chose your current analytics architecture, defined your onboarding flow, or set the pricing tier thresholds may have left six months ago. The decision remains; the rationale is gone.
The assumption expired. Every product decision rests on assumptions about user behavior, market size, cost structure, or technology capability. Those assumptions do not announce when they stop being true. A company targeting SMBs in 2023 may have shifted toward enterprise by 2025, but the product choices (self-serve onboarding, usage-based pricing, lightweight admin controls) still reflect the original segment. Assumption mapping helps at the start of a project, but assumptions also need scheduled rechecks after a decision ships.
The “Would We Start This Today?” Test
The most effective filter for identifying stale decisions is a question borrowed from sunk-cost discipline: “If we had not already invested in this, would we make the same choice today?”
This question strips away the emotional weight of prior investment. It reframes the decision as forward-looking. And it surfaces a surprising number of features, processes, and architectural commitments that exist only because nobody paused to ask whether they should still exist.
During a fractional COO engagement, I watched this pattern play out with a batch reporting process that consumed four hours of compute every night. It had been designed when the database was small and nightly batch jobs were the only practical option. By the time the team had access to real-time query tooling, the batch job had become load-bearing: dashboards depended on it, executives expected the output by 7am, and the operations team had built monitoring workflows around it. The original constraint (no real-time capability) had been gone for two years. Nobody questioned the process because it still produced correct output. But “working” and “still the right approach” are not the same thing.
Decision Logs as Expiration Labels
The operational mechanism that makes decision review possible is documentation. Specifically, a decision log: a lightweight record of what was decided, why, what assumptions it rested on, and when it should be revisited.
The format does not need to be heavy. A table with five columns works: Date, Decision, Reasoning, Key Assumptions, and Review By. The “Review By” column is the critical addition. It forces the team to set an expiration check at the moment of decision, when the context is freshest.
Not every decision needs a review date. Choosing a button color does not warrant one. But pricing models, platform architecture choices, market positioning decisions, major feature commitments, and partnership agreements all benefit from a standing check-in. Quarterly works for most strategic decisions. Annual works for architectural ones. The right cadence depends on how fast the relevant market moves.
The secondary benefit of a decision log is onboarding. When a new product manager joins the team and asks “why do we do it this way?”, the answer should never be “I don’t know, it was before my time.” That answer is the sound of institutional knowledge evaporating.
The Accumulation Default
Klotz’s research on subtraction neglect points to something deeper than laziness or inattention. Humans default to addition because addition feels productive. Removing a feature, killing a process, reversing an old commitment: these feel like losses, even when they create more value than they destroy.
Product managers are particularly susceptible because the incentive structures around the role reward building. Shipped features appear on resumes. Removed features do not. Performance reviews rarely credit the PM who deprecated the integration that was costing 15 engineering hours per week in maintenance. Teams that explicitly track their strategic no list at least have a mechanism for documenting what they chose not to build. A decision log with review dates extends the same discipline to what has already been built.
Building a culture where revisiting past decisions is treated as productive work, not second-guessing, requires deliberate effort. It starts with the decision log. It continues with a quarterly review cadence. And it matures when the team normalizes the phrase: “that was the right call then; it’s not the right call now.”
Start With Five
If your team does not currently revisit past product decisions, start small. Identify the five oldest active decisions on your roadmap or in your product’s architecture. For each one, answer three questions:
- What assumption was this decision based on?
- Is that assumption still true?
- If we were making this decision today with current information, would we make the same choice?
Any “no” to questions 2 or 3 is a candidate for reversal, modification, or at minimum, a deeper review. You will likely find that at least one of the five has quietly expired.
Product management is not just about making good decisions. It is about knowing when good decisions stop being good.