Backlogs do not kill companies because they get too long. They kill companies because they lose meaning. When every item is marked urgent, nothing is. When features get added without a business hypothesis attached, the team stays busy while the business stalls. Six forces are accelerating this problem right now: the pressure to ship everything fast, the competitive arms race, the rush to add AI features without a clear strategy, undisciplined experimentation that never removes failed work, compliance requirements that jump the queue, and leadership ideas that bypass prioritization entirely. The result is a backlog that functions less like a planning tool and more like a debt instrument, one that compounds interest over time and eventually comes due. The fix is not more engineers, a new framework, or a better offshore arrangement. It is treating the backlog as a financial instrument that requires the same discipline as any balance sheet item.
When the Bill Comes Due
Peter Chen stared at 1,407 items on his Jira board.
Peter had three meetings on his calendar that morning. The CEO wanted to know why an AI feature promised to the board six months ago still was not live. Sales had lost a $500,000 deal to a competitor that had a Plaid integration, a feature that had been sitting in the backlog for 14 months. And engineering leadership wanted to discuss an eight-year-old authentication system held together with workarounds that made every new feature take three times longer than it should.
Before the first meeting started, Peter already knew the truth. This was not a velocity problem. It was a prioritization problem wearing a velocity problem's clothes.
The Backlog as a Debt Instrument
The oldest item in Peter's backlog was four years old. A feature requested by a customer who had since churned was still marked Critical. An integration estimated at three weeks had been re-estimated twice and now sat beneath 400 higher-priority items, with no one sure whether the original requesters still wanted it.
Software backlogs do not behave like wish lists. They behave like debt instruments. Every piece of deferred technical work makes everything built on top of it harder to change, slower to ship, and more expensive to maintain. The longer the deferral, the higher the interest rate. A refactor that would have taken two weeks last year takes two months today because six new features were built on top of the problematic code in the meantime.
Research from Sonar, a code quality platform, analyzed over 200 projects and estimated that for a codebase of one million lines, technical debt costs approximately $306,000 per year in remediation work alone. Most mid-market B2B software companies maintain codebases of three to ten million lines. The math compounds fast.
Fred Brooks identified the core trap 50 years ago managing the IBM OS/360 project. Adding engineers to a late project made it later. Communication overhead grows exponentially with team size. A three-person team has three communication channels. A six-person team has fifteen. Adding people to a backlog problem does not clear the backlog. It adds coordination cost on top of an already strained system.
Six Forces Making This Worse
The forces driving backlog growth today are more aggressive than they were a decade ago.
Idea generation outpacing evaluation
Product organizations now generate ideas faster than any team can evaluate them. Product managers return from conferences with feature concepts. Sales closes deals with custom requirements attached. Every internal channel becomes a request queue. What changed is not just the volume. It is that most backlog items no longer arrive with a business hypothesis. They are not framed as experiments designed to move a specific metric. They arrive as tasks, tickets, and requests, disconnected from any outcome the business can measure.
Competitive queue thrashing
The competitive environment makes this worse. Every Monday morning, someone discovers a competitor shipped something that has been planned internally for months. The response is to reprioritize. Again. Don Reinertsen, who has studied product development economics for over 40 years, calls this queue thrashing. Every reprioritization disrupts work in progress, creates context-switching costs, and generates rework. And most organizations make these decisions without ever calculating what it actually costs to delay any given piece of work.
AI pressure without strategy
The pressure to ship AI-powered features has added a new layer to this. Board members read forecasts about generative AI adoption and ask about the company's AI strategy. Product managers add "AI-powered" to every spec. Competitors announce AI features and internal teams respond by adding more AI experiments to the backlog. The architectural work to support those features, the security and compliance requirements, the data pipeline infrastructure, all of it goes into the backlog as well. The problem is not AI. It is the pressure to ship AI features without a clear framework for which ones actually create durable value.
Compliance jumping the queue
Compliance adds its own cascade. GDPR, CCPA, SOC 2, PCI-DSS, state privacy laws, and now frameworks like the EU AI Act each generate dozens of backlog items. Because compliance work carries legal risk, it jumps the queue. Revenue-generating features get pushed further out. And because compliance requirements determine which engineers can touch which systems, the team cannot simply reassign capacity to clear high-priority items.
Undisciplined experimentation
Experiments get added to the backlog but failed work is rarely removed. Hypotheses that should have produced a clear yes or no decision instead linger as half-shipped features, unfinished pilots, and "we should revisit this" tickets that no one ever revisits.
Guesses labeled as priorities
Finally, there is the dynamic that Marty Cagan, founder of Silicon Valley Product Group, has described directly: teams spend their time working through a backlog without truly understanding why the items are there or how any individual piece of work moves the business forward. When leadership generates ideas faster than the team can evaluate them, the backlog fills with guesses labeled as priorities.
The Cost Nobody Calculates
One of Peter's product managers calculated the Cost of Delay on a single deferred integration. Based on a conservative estimate from Sales, delaying that feature cost approximately $50,000 per month in lost deals. The feature had been in the backlog for 14 months.
Reinertsen's research on this phenomenon found that when teams finally calculate their Cost of Delay, the number is almost always larger than anyone expected, the calculation takes less time than anyone feared, and the team reaches consensus faster than on almost any other prioritization question. The reason those calculations rarely happen is simple: no one has asked for them. Decisions get made based on estimated ROI with time treated as a constant. Time is not a constant. It is the variable that determines whether you capture a market window or miss it.
Stripe's 2018 Developer Coefficient study found that the average developer spends 33 percent of their work week dealing with technical debt and maintenance work. That is more than 13 hours per week not building new features. The Consortium for Information and Software Quality estimated the cost of poor software quality in the United States at $2.41 trillion annually, with $1.52 trillion of that attributable to accumulated technical debt.
When the Bill Actually Comes Due
There are three moments when a backlog problem crosses from operational to strategic.
What Has to Change
Peter's 1,407-item backlog was not a crisis because of its length. It was a crisis because most of those items had lost their connection to a business outcome. With 65 percent of items marked urgent, the word urgent had become meaningless. The backlog was no longer a portfolio of strategic bets. It was a record of organizational anxiety.
A healthy backlog is not a comprehensive list of everything anyone has ever requested. It is a prioritized set of work governed by strategy, constrained by realistic capacity, and pruned continuously based on evidence. Most backlogs have abandoned that discipline entirely.
The three most common responses to a backlog crisis all fail for the same underlying reason. Hiring more engineers adds communication overhead without fixing the prioritization system. Handing work to an external team without delivery ownership creates a coordination problem on top of a capacity problem. Adopting a new framework changes the ceremony without addressing what gets built, in what order, and why.
Sonatafy's Managed Delivery POD model
Small, autonomous teams with clear ownership, disciplined prioritization, and US-based principal engineering leadership that connects architectural decisions to business outcomes. Not a staffing solution. A delivery system built to address the root cause, not the symptom.
The Backlog Illusion goes deeper on exactly how this works, how PODs are structured, how senior technical oversight prevents the compounding shortcuts that create tomorrow's debt, and why delivery accountability is what separates teams that ship from teams that stay busy.
Read the Book
The Backlog Illusion goes much deeper into the operating framework Steve and Chris developed.