Sancho PM· Practice · 5 min read
The Knight's Wounds
When Product Debt Catches Up With You
Don Quixote never fully healed from one adventure before charging into the next. Product debt works the same way—invisible until it isn't.
The Accumulating Bruises
Don Quixote gets hurt a lot.
He’s knocked off his horse by windmills. Beaten by muleteers. Stoned by shepherds. Battered by galley slaves he tried to free. Each time, he patches himself up—a bandage here, a homemade poultice there—and charges into the next adventure.
He never fully heals. The bruises compound. The ribs cracked in Chapter 8 are still aching in Chapter 30. By the end, his body is a catalogue of accumulated damage.
Sancho watches it happen. “Master, perhaps we should rest before the next quest?”
“A knight doesn’t rest. A knight rides on.”
The knight rides on. The knight breaks down.
The Product Debt
Products accumulate damage the same way.
Someone hardcoded a value 18 months ago. “We’ll fix it later.” That value is now buried under three layers of features, and fixing it requires a refactor nobody has time for. The original engineer doesn’t even remember why it was hardcoded.
Someone skipped writing tests to hit a release date. Then the next release, and the next. Now you have 40,000 lines of untested code and every deploy is a prayer. The team doesn’t talk about it. They just hold their breath on Thursdays.
Someone started migrating to a new API but only got halfway. Now you maintain two systems that do the same thing, each with its own bugs and quirks. New engineers ask “why do we have both?” and nobody has a good answer.
A feature shipped two years ago. The PM who built it left. The engineer who built it left. It still runs. It still has users. It has bugs nobody knows how to fix.
And then there’s the invisible debt: the design system that was never built, so every team rolls their own components. It’s not broken code—it’s missing infrastructure. You can’t point to a bug. You can only feel it in how long everything takes.
None of these feel urgent individually. Together, they slow everything to a crawl.
What Actually Works
Make Debt Visible
Quixote’s problem wasn’t just the injuries—it was pretending they weren’t there. Sancho could see the damage. Quixote chose not to.
Most teams know their debt exists but keep it in a graveyard backlog that nobody reads. That’s the equivalent of Quixote insisting he feels fine while limping. Instead, track debt in a visible document that leadership actually sees—not a Jira epic with 200 tickets, but a short, honest summary: “Here’s what we owe. Here’s what it costs us per sprint. Here’s what will break next.” When leadership can see the compound interest on their shortcuts, the conversation about allocation changes.
Pay a Little Each Sprint
Sancho couldn’t convince Quixote to spend a week healing. But he could convince him to rest for one night. The product equivalent is dedicating a fixed percentage of each sprint—15-20% is common—to debt reduction. It’s not glamorous. It doesn’t show up in the roadmap demo. But it keeps the knight healthy enough to fight, and it prevents the slow erosion where every feature takes 30% longer than it should because the foundations are crumbling.
The trap is treating debt sprints as optional—the first thing cut when a deadline looms. If you only heal when nothing else is happening, you never heal. Make the allocation non-negotiable, the same way you wouldn’t skip paying rent because you had a busy week.
Stop Wounding Carelessly
Every “quick fix” and “we’ll address it later” is a new wound. Some are unavoidable—shipping fast means accepting some shortcuts. But there’s a difference between deliberate debt (documented, scheduled for payback, understood by the team) and accidental debt (nobody noticed until it was too late).
Before approving a shortcut, ask the team: “When exactly will we pay this back?” If nobody can answer with a sprint number, you’re taking a wound you’ll never heal. Write it down. Put a date on it. Treat it like a loan, because that’s what it is.
Signs Your Product Is Wounded
You might not feel the damage until you look for it:
- Everything takes longer than it should—simple features need weeks because of workarounds
- Fear of touching old code—“don’t change that, nobody knows how it works”
- Increasing incident frequency—things break more often, in unexpected places
- Declining velocity with a stable team—same people, slower output, no clear reason
- Onboarding takes forever—new engineers spend weeks just understanding why things are the way they are
That last one is particularly telling. When your codebase requires oral history to navigate, the wounds have become structural.
The Wound Check
Run this diagnostic with your tech lead. Be honest.
- Can you name your three biggest pieces of tech debt right now?
- Do you know how much time per sprint goes to workarounds instead of new work?
- Has your team deliberately paid down debt in the last month?
- Could a new engineer onboard without someone explaining “yeah, ignore that part”?
- Is there a visible document tracking what you owe and what it costs?
If you checked fewer than three, your product is carrying wounds you haven’t examined. Sancho would tell you to stop riding and look.
Rest Before It’s Too Late
Near the end of the novel, Quixote finally rests. It’s too late by then—the accumulated damage is too much.
Don’t be that product. The debt is real, even when it’s invisible on the roadmap. Pay it down before it pays you a visit.
A healthy product ships faster than a wounded one. Always.
Make the wounds visible
Your next retro is a good place to start. The Retro Template gives your team a structured way to surface the debt that’s slowing them down—and decide what to heal first.