The What Debt
When the Bottleneck Moves from How to What
There’s a specific kind of discomfort I’ve learned to recognize during sprint reviews. Someone demos a feature that’s been in production for eight months. The demo goes fine. Then comes the silence where nobody in the room is entirely sure why we built it.
The feature works. It just doesn’t quite matter. Or maybe it does, but nobody can remember to whom, and under what circumstances, and whether anyone is actually using it. The story that created it is closed. The epic it belonged to is still open, technically, because there were three more stories that never got picked up. The feature lives in the product, quiet and persistent, like furniture you stopped noticing.
We’ve spent years developing a sophisticated vocabulary for the technical equivalent of this problem. Technical debt has entire frameworks dedicated to its management, measurement, and repayment. We know how to talk about it with business stakeholders. We can quantify it, at least approximately. We’ve built the muscle.
I don’t think we’ve built the equivalent muscle for what I’m starting to call What Debt.
The Problem With Features That Don’t Switch Off
Technical debt accumulates in the codebase. What Debt accumulates in the product, and in the backlog, and in the organizational memory of the team.
The defining characteristic of What Debt is that it doesn’t turn itself off. Code can rot silently; a deprecated API endpoint can be sunset with a migration plan and a sunset date. A half-finished feature in your product lives differently. It occupies real estate in the UI. It shows up in onboarding documentation. It generates support tickets. New engineers join the team and ask about it. Someone, somewhere, built a workaround that depends on its current behavior. It’s not dead, but it’s not delivering value either.
And then there’s the backlog. The open epic with three unclosed stories, sitting at the bottom of the board, never urgent enough to be prioritized, never clearly dead enough to be archived. Every time someone opens the backlog to estimate velocity, it’s there. It’s not work. It’s weight.
The asymmetry is worth pausing on: we built mechanisms to prevent technical debt from accumulating invisibly, but we rarely have the equivalent for product decisions. We have linters, CI checks, architecture review boards, code review culture. What’s the equivalent for a feature that made sense under a Goal that is no longer valid?
Learning to Repay It
A few months ago I went back and reviewed everything we’d added to our backlog over the previous quarter. It was one of those sessions I’d been postponing, mostly because I half-knew what I’d find. And I did: a significant portion of the items had quietly dropped in priority, several had been made irrelevant by decisions taken in the meantime, and a smaller but real subset were actually ready to be worked, just buried under the noise of everything else.
What struck me wasn’t the disorder, which was manageable. It was how different these three categories required me to respond, and how little practice I had at telling them apart quickly.
Some things needed to be switched off. Not archived, switched off. Features in the product that had accumulated their own weight: documentation references, support queries, the occasional user who’d built a workflow around them. The honest question I learned to ask is blunt: what would we lose if this disappeared tomorrow? If the answer is genuinely “nothing material,” that’s your signal. The hardest part was internalizing that switching something off isn’t a failure to be explained; it’s a decision to be documented.
Some things needed to be closed, not deferred. The ghost epics are particularly insidious because they survive planning cycles through a kind of passive inertia: nobody champions them, but nobody kills them either. Archiving one with a clear written rationale, “we validated the hypothesis, it didn’t hold, here’s why,” turned out to be surprisingly cathartic. It also made the backlog legible again in a way that opened up new conversations about what we actually wanted to do.
And some things deserved a proper restart. Not every half-finished thread is a mistake. Some were sound ideas with poor timing, or incomplete execution, or a context that had genuinely shifted. For these, I found the right move wasn’t to pick them back up where they were left, but to treat them as fresh discovery input: return to the problem, talk to users again. The difference between a ghost epic and a legitimate future bet, I’ve come to think, is mostly documentation and intent.
The Cognitive Load Nobody Is Measuring
There’s a second dimension to What Debt that goes beyond individual features or backlog items. It has to do with the pace of product decision-making itself.
The increasing velocity of delivery, driven in large part by the same AI tools transforming how software gets written, is creating a structural imbalance I find hard to ignore. The how of software development is accelerating. The what is not keeping pace.
Product management at its core is a human process: synthesizing user signals, navigating organizational constraints, making judgment calls about value and timing. These things don’t get faster because your CI pipeline gets faster. The cognitive load required to make good product decisions is, if anything, increasing, because the space of possible things to build is expanding faster than teams can evaluate them, and the cost of starting has dropped dramatically while the cost of abandoning remains sticky.
What I observe in teams navigating this is a specific kind of overload in discovery. When delivery is slow, the product bottleneck is naturally paced by engineering capacity; the system has a built-in regulator. When delivery accelerates, that regulator disappears, and the product function is suddenly expected to generate decisions faster than its processes were designed to support. What Debt is, in part, the artifact of this mismatch: features started before the why was clear enough, shipped before the for whom was validated, left running because nobody had the bandwidth to evaluate them deliberately.
The Bottleneck Has Moved
For most of the history of software development, the primary constraint was the how. Writing good code was hard. Shipping reliably was hard. Infrastructure was expensive and slow. These constraints had a regulating effect on product decisions, not because they made decisions better, but because they imposed a natural cadence. You couldn’t easily outrun your own backlog.
AI is dissolving that constraint. Code generation, automated testing, accelerated prototyping: the how is getting radically cheaper. The ability to move from idea to working prototype in hours rather than weeks changes the economics of experimentation fundamentally.
But it also means the limiting factor is increasingly the what.
“Fail fast” was always a useful heuristic, but it assumed the cost of building was the primary friction. In a world where you can ship a functional prototype in an afternoon, the updated version of “fail fast” requires an equally capable decide fast: a product function that can generate, evaluate, and invalidate hypotheses at the same velocity as the engineering function can implement them. Most teams I see are not there yet. The product discovery muscle is underdeveloped relative to the delivery muscle, and so What Debt keeps accumulating: features built quickly, validated slowly, never properly closed.
The irony is real. AI gives you speed. But speed without direction doesn’t reduce waste; it accelerates it.
In conclusion
What Debt won’t show up in your DORA metrics. It won’t trigger a SonarQube alert. It will sit in your product and your backlog and the back of every PM’s mind during roadmap planning, quietly compounding.
The teams that figure out how to manage it, how to decommission without shame, archive without loss, and run discovery fast enough to keep pace with delivery, won’t just have cleaner products. They’ll have a fundamentally different relationship with their own roadmap.
The iteration has always been the point. The question now is whether you’re iterating on the right things.