Technical debt is the future cost and constraint created by past technical choices, including deliberate shortcuts and changing requirements. Manage it jointly by documenting product effects, likelihood, consequence, and remediation options. Fund work according to risk and strategic capability rather than treating all debt as invisible engineering preference or an emergency rewrite.
Who this is for: Product managers and engineering leaders balancing near-term customer work with system health and delivery capability.
- Translate debt into customer, delivery, reliability, security, cost, and strategic capability effects.
- Maintain an evidence-backed register with risk, trend, dependencies, options, and accountable owners.
- Choose incremental reduction, containment, replacement, or acceptance based on product priorities and total risk.
Build a shared definition
Teams use technical debt to describe many things: expedient design, obsolete dependencies, missing tests, fragile data models, manual operations, or architecture that no longer fits product direction. Name the concrete condition and how it arose. Avoid using debt as a moral judgment about earlier teams that made reasonable choices under different constraints.
Connect the condition to observable effects. Examples include longer lead time, repeated incidents, blocked accessibility work, inability to price correctly, elevated cloud cost, or difficulty supporting a strategic segment. Product language helps compare debt with other investments, while technical detail remains necessary for engineers to assess options.
Assess risk and evidence
For each debt item, record affected capabilities, likelihood, consequence, trend, detectability, workaround, and dependencies. Use incident records, cycle time, defect patterns, operational hours, performance, security findings, and change failure evidence. Separate a current impact from a forecast and state confidence in each.
Consider concentration and compounding. One brittle service may place many roadmap outcomes at risk, while several small annoyances may be cheaper to tolerate. Ask what happens if volume doubles, a vendor ends support, a key engineer leaves, or regulation changes. Specialist security and compliance findings may establish nonnegotiable action.
Compare response options
Options include accepting the condition, adding monitoring, isolating a component, improving tests, refactoring incrementally, migrating data, replacing a service, or redesigning a workflow. Estimate effort ranges, risk reduction, opportunity enabled, customer disruption, and ongoing maintenance. A complete rewrite should compete with narrower alternatives, not appear as the automatic definition of quality.
Tie reduction to upcoming product work where practical. If a new permissions model touches the fragile authorization layer, invest before stacking more behavior on it. Reserve capacity for continuous maintenance and create explicit initiatives for larger risks. Emergency-only funding rewards hidden deterioration until the most expensive moment.
Govern debt over time
Review the register with product and engineering leaders on a predictable cadence. Rank items by product risk and strategic leverage, assign owners, and record accepted risks with expiration dates. Communicate which customer or roadmap commitments change when debt work is funded or deferred. This makes the tradeoff real rather than framing maintenance as free spare-time work.
Measure outcomes such as incident reduction, lead time, change failure, support burden, or enabled capability after remediation. Closing a refactor ticket does not prove risk fell. Update architecture and operating documentation, remove temporary paths, and retire stale register entries only when verification supports the intended effect.
Prioritize a fragile permissions service
Permission changes take weeks, produce recurring access incidents, and block planned enterprise administration work.
- Document incident frequency, affected accounts, engineering delay, support effort, and enterprise capabilities blocked.
- Assess likelihood and consequence as role count and account size increase, including privacy review.
- Compare monitoring, targeted test coverage, interface isolation, incremental model migration, and full replacement.
- Choose staged isolation and migration before the enterprise initiative, with rollback and customer communication plans.
- Verify fewer incidents and shorter permission-change lead time before closing the debt record.
Technical debt decision record
Use this record to compare debt with other product investments without erasing engineering evidence.
- Condition: affected system, origin, concrete limitation, owner, and linked technical assessment.
- Product effect: customer harm, incident, delay, blocked opportunity, cost, manual burden, and evidence.
- Risk: likelihood, consequence, trend, concentration, detection, workaround, and uncertainty.
- Options: accept, contain, improve, migrate, or replace with effort, reduction, disruption, and dependencies.
- Decision: priority, capacity, accepted tradeoff, review date, success measures, and closure evidence.
Common mistakes
- Treating every disliked implementation as urgent debt without showing product effect or future constraint.
- Demanding a rewrite before comparing incremental risk-reduction options and migration hazards.
- Deferring maintenance indefinitely while keeping roadmap commitments that depend on the fragile system.
Try one
Engineering reports that checkout tax logic is difficult to change, but incidents are rare. What should product ask before prioritizing remediation?
A strong answer asks which future capabilities are blocked, how change lead time and defect risk are trending, what jurisdictions or volumes increase consequence, what monitoring exists, and which response options reduce risk. Rare incidents do not settle the decision. The team should compare evidence, strategic dependencies, security or compliance duties, effort, and the cost of accepted risk with a review date.
Sources
- Atlassian product roadmaps guideOfficial guidance on communicating product direction, priorities, and progress.
- Atlassian product requirements guideOfficial guidance on collaborative, concise, and testable product requirements.