Tech debt & estimation
TL;DR
Technical debt is the accumulated cost of past shortcuts — code and architecture that made sense (or didn't) at the time and now slow every future change. It's not "bad engineering." Some debt is a deliberate, smart trade to ship faster, as long as you pay it down. Estimates are the other half of this literacy. They're probabilistic ranges, not promises, and knowing why something is "small" or "large" is what lets you sequence work and negotiate scope. The PM's job isn't to write the code or the estimate. It's to make the debt and the trade-offs visible and to prioritize them honestly.
🎯 For the AI PM
Why it matters — AI features accrue a distinctive debt: prompt spaghetti, no evals, untracked model versions, a data pipeline held together with tape. This debt stays invisible until quality silently regresses and nobody can tell why.
What it changes in your decisions — Budget for the unglamorous foundations — evals, observability, data quality — as first-class roadmap items, because in AI they are the product's reliability.
Ask yourself — "What's the shortcut we're taking to ship this, and when do we pay it back — or is it debt we can never afford?"
Risk if ignored — A feature that ships fast, then can't be improved because every change fights the mess underneath it.
Prioritizing: effort vs. impact
Most technical work — features and debt paydown — sorts onto one map. Making it explicit is half the battle:
Debt paydown belongs on the same map as features
Quick wins go first. Big bets get planned deliberately. Time sinks get questioned hard.
Quick wins (low effort, high impact) go first. Big bets (high effort, high impact) get planned deliberately. Time sinks (high effort, low impact) get questioned hard. Debt paydown items belong on this map alongside features — that's how you avoid the trap where debt never wins against the next shiny thing.
Understanding technical debt
- Deliberate debt — A conscious "we'll do it the quick way now and fix it later" to hit a deadline. Legitimate — if the "later" is real and scheduled.
- Accidental debt — Mess that accrues from changing requirements and rushed decisions.
- The interest — Debt charges interest. Every feature built on shaky foundations takes longer and breaks more. Left unpaid, teams reach the point where simple changes take weeks.
The PM's role is to keep debt visible and prioritized. Translate "the code is a mess" into "this is why the last three features slipped, and here's what paying it down buys us."
Reading an estimate
An estimate is a probability distribution, not a date. When an engineer says "about two weeks," hear "probably two, could be one, could be four." Useful instincts:
- Ask what makes it big or small. The why — "we've done this before" vs. "we've never touched that system" — tells you more than the number does.
- Uncertainty is data. A wide range ("2–6 weeks") tells you there's unknown risk. The fix is often a spike — a short timeboxed investigation — to shrink the range, not to demand a tighter guess.
- Beware the 90% done trap. The last 10% — edge cases, error handling, polish — routinely takes as long as the first 90%. "Almost done" is the most dangerous status.
- Complexity compounds. Two features that each touch the same system aren't additive. Integration is where estimates blow up.
You're not there to squeeze the number down. You're there to understand it, so you can sequence work, cut scope intelligently, and set expectations you can keep.
A worked pass: reading a "3 weeks for a form"
Here's an estimate that sounds absurd until you decompose it. You ask for two extra fields on the signup form; engineering says three weeks. The wrong response is "it's a form." The right response is "walk me through it." The walk reveals: the fields need a schema migration on a 40-million-row table (which, on this database version, locks the table unless done in stages), a backfill for existing users, changes to three services that validate signup payloads, handling for old app versions that will keep submitting the old shape for months, and updates to the data-export pipeline a partner depends on. The form is two days. The system the form touches is three weeks.
Now the negotiation is honest and specific instead of adversarial. Do old app versions really need support, or can the fields be optional until the next forced upgrade? Does the partner export need the fields at launch, or in Q3? Can the backfill run lazily on next login instead of up front? Each question trades scope against time knowingly, and each is only askable because you asked what the three weeks was made of. That's what "reading an estimate" means: not challenging the number, decomposing it.
Failure modes
- Invisible debt — Debt never makes the roadmap, so it compounds until the team grinds to a halt.
- Treating estimates as promises — A team commits externally to the optimistic end of a range.
- Debt always loses — Features always beat paydown, because the cost of debt was never made concrete.
- No AI foundations — Model features ship with no evals or observability, and then no one can diagnose quality regressions.
Practitioner checklist
- Is the debt we're taking on deliberate and scheduled for paydown — or silent?
- Are debt-paydown items on the same priority map as features?
- Do I understand why an estimate is what it is, not just the number?
- Have I treated wide estimates as a signal to investigate, not to squeeze?
- For AI work, are evals and observability funded as first-class, not "later"?