The Stability Triangle
Why Technical Debt and Feature Requests Are the Same Kind of Bet.
The argument nobody finishes
Every planning session eventually arrives at the same moment. Engineering raises technical debt. Business raises new features. Someone says "we need to deliver value." And without anyone meaning to, technical debt quietly loses.
The reasoning feels intuitive: features serve customers, drive revenue, and justify investment. Technical debt is an internal concern. An engineering preference. Something to handle later, when things slow down.
But here's what I've come to believe after years sitting across both sides of that table: we are measuring one of these with a ruler and the other with a feeling.
Both are bets. Neither is a certainty.
When business requests a feature, there is an implied assumption of value. But how often do we rigorously validate that assumption before it enters the backlog? How many features get built, shipped, and quietly forgotten because the expected uplift never materialised?
The honest answer is: more than we admit.
Technical debt gets dismissed because we can't easily point to the revenue it generates. But feature requests survive scrutiny not because they are proven to add value, but because they feel aligned with business goals. That is not the same thing.
Both are really just probabilities. A feature might improve conversion. A debt resolution might prevent a system failure that would cost three times what the feature earned. Neither outcome is guaranteed. Both carry risk. Both carry potential.
The difference is that one gets a business case and the other gets an apology.
The project triangle has a sibling we've been ignoring
Most people in technology are familiar with the project triangle: scope, time, cost. The constraint that says you cannot optimise all three simultaneously. Pick two, and accept the trade-off on the third.
I think we need an equivalent mental model for product stability. Call it the Stability Triangle.
The three corners are:
Features — the new capabilities business requests to drive growth, serve customers, or respond to market signals.
Technical Debt — the accumulated shortcuts, outdated dependencies, architectural compromises, and deferred improvements that slow every future change and increase the risk of every deployment.
Stability — the system's capacity to perform reliably, scale predictably, and evolve without breaking.
Just like the project triangle, you cannot fully optimise all three at once. Push hard on features and defer debt indefinitely, and stability erodes. Resolve debt aggressively without communication, and the business loses confidence in delivery. Prioritise stability above everything else, and the product stagnates.
The triangle does not tell you what to choose. It tells you that every choice has a consequence, and that consequence is shared.
Where it breaks down: the conversation that never happens
The real problem is not that organisations choose features over technical debt. Sometimes that is the right call. The problem is that the choice is made without genuine partnership.
Business stakeholders are often handed a product that feels slower every quarter, more fragile with every release, harder to change when the market shifts. They do not always know why. Nobody told them. The relationship between deferred debt and degraded velocity is invisible until it is catastrophic.
On the other side, engineering teams carry the weight of systems they know are fragile, and feel the frustration of watching new features pile onto foundations that were never solid. They raise concerns that get filed away. They estimate cautiously and get asked to estimate again.
Neither side is wrong. Both are working with incomplete information and insufficient trust.
This is not a technical problem. It is a communication problem dressed as a technical problem.
What partnership actually looks like
Balancing the stability triangle requires stakeholders who are genuine partners in building a product, not just consumers of a delivery roadmap.
That means a few things in practice.
Visibility into the true cost of debt. Not just in engineering hours, but in what it prevents. What features can't be built cleanly because the data model is wrong? What releases carry more risk than they should because the test coverage is thin? When debt has a business cost, it earns a business conversation.
Shared ownership of the backlog. Technical debt items belong in the same prioritisation conversation as feature requests. They should be sized, reasoned about, and ranked alongside everything else. Not as a concession to engineering, but as a recognition that they carry real consequence.
Honest probability assessments on both sides. Feature requests should be held to the same standard of evidence that we apply to technical investment. What is the expected outcome? How will we measure it? What is our confidence level? Treating features as certain and debt as speculative is a bias, not a strategy.
Regular stability conversations. Not post-mortems after incidents. Regular, structured reviews of where the system is healthy and where it is not. Shared language between technical and business leaders around what stability means and what it costs to maintain.
The role of the person in the middle
I sit at an unusual intersection. As a Solutions Architect, I think about the long-term structural health of what we build. As a Delivery Lead, I am accountable for what ships and when. As a Technical Product Manager, I am in the room when prioritisation decisions get made.
That position gives me a particular vantage point. I see the technical debt that engineering is managing. I see the features business is requesting. And I see the gap between them: the conversations that are not happening, the trade-offs that are not being named, the assumptions that are not being tested.
The stability triangle is not a framework I hand to one team and walk away. It is a shared lens. A way of making the trade-off visible so that everyone in the room is choosing deliberately, not deferring blindly.
This is not about saying no to features
To be clear: features matter. Responding to customers matters. Building things that grow the business matters. None of that changes.
What changes is how we talk about the choices we make. If a team decides to prioritise a feature over a debt item, that should be a conscious, informed decision with understood consequences. Not a default. Not an unexamined assumption that engineering concerns are less legitimate than business ones.
The stability triangle asks a simple question: are all three corners visible to everyone making the call?
If the answer is yes, then whatever is decided is a real decision. And real decisions can be revisited, adjusted, and learned from.
Closing thought
We spend a great deal of energy trying to prove that technical debt has business value. I think we are framing it wrong.
The better question is not whether technical debt resolution adds value. The better question is whether we are being equally rigorous about whether everything else we build does.
When we hold both to the same standard, the conversation changes. Features and debt stop being opposites. They become two variables in the same system, managed together by teams that trust each other enough to be honest about the uncertainty on both sides.
That is what a partnership in product building actually looks like.
If this resonates, I'd be interested in how your team navigates the stability triangle. What's worked? What hasn't?