Most teams get stuck in the same argument: “We need to ship features” versus “We need to fix the mess.” If you pick one, the other gets louder. If you try to do both without structure, you end up doing neither well.
A useful roadmap makes tradeoffs explicit. It also protects the work that keeps your product stable: upgrades, refactors, test coverage, performance fixes, and operational improvements. These are rarely exciting, but they determine whether feature delivery gets easier or harder over time.
This post describes a simple, repeatable approach called a two-speed roadmap: one stream for customer-facing outcomes, and one stream for engineering health. It’s designed for small teams that need to stay responsive without accumulating hidden risk.
Why “feature vs debt” is a false choice
“Technical debt” is often treated like a moral failing or a mysterious monster. In practice, it is just the cost of change: the friction you feel when you try to add, modify, or operate your system.
The feature-versus-debt framing fails because both streams serve the same goal: delivering value reliably. Features increase value directly. Maintenance increases the rate at which you can deliver value without outages, regressions, or long lead times.
What you need is a way to compare unlike things. That’s where a two-speed roadmap helps:
- Product speed: initiatives expressed in user or business outcomes (what changes for customers).
- Engineering speed: initiatives expressed in measurable capability (how fast and safely you can ship and operate).
When you plan both explicitly, you stop “stealing time” from one to feed the other. You also create a shared language with stakeholders: maintenance is not “because engineers want it,” it’s because it reduces specific delivery and reliability risks.
Set a debt budget you can keep
A debt budget is a pre-committed slice of capacity dedicated to engineering health. The point is not precision. The point is consistency, because inconsistent maintenance is how systems drift into emergency mode.
Pick a budget rule (and keep it boring)
Choose one rule that matches your team’s maturity:
- Percentage rule: reserve 15 to 30 percent of each sprint for engineering health.
- Fixed slot rule: one “maintenance day” every week for the team.
- Alternating cadence: one sprint per month focused on reliability and cleanup, if context switching is expensive for you.
Whichever rule you choose, protect it the way you protect customer deadlines. If you only do maintenance when “you have time,” you will not have time.
Decide what counts as “debt work”
Teams argue because the category is fuzzy. Write down your definition in one paragraph. A practical definition is: work that reduces future cost-of-change or reduces operational risk without directly adding new customer-visible capability.
Examples that usually qualify:
- Upgrading dependencies to supported versions
- Adding tests around fragile workflows
- Removing dead code paths and outdated feature flags
- Improving observability (logs, metrics, alerts) for known pain points
- Reducing build times or flaky CI
Run a two-speed backlog
The two-speed roadmap is not two separate teams. It’s one team running two kinds of work with different acceptance criteria and different success metrics.
In practical terms, you maintain two top-level lists:
- Outcomes backlog (features): items described as user impact with a clear “done” state.
- Health backlog (maintenance): items described as system capability with a measurable before/after.
Then you plan each sprint (or month) by filling the feature portion and the maintenance portion according to your debt budget rule.
Two-speed sprint plan (conceptual)
- Capacity: 40 points
- Outcomes (28 points)
- Outcome A (14)
- Outcome B (14)
- Engineering health (12 points)
- Reduce CI flake rate from 8% to 2% (6)
- Replace deprecated library in billing module (6)Notice what’s missing: “refactor the billing module” as a vague task. Health work should read like a hypothesis: if we do X, we expect Y to improve. That makes maintenance visible and reviewable, not a black box.
A concrete example (and how to measure it)
Imagine a small SaaS team that runs an appointment scheduling product. Feature requests keep piling up: recurring appointments, SMS reminders, and a better admin search. Meanwhile, engineers complain that every change touches the same fragile scheduling rules, and incidents are increasing.
They adopt a 25 percent debt budget. For the next four sprints, they keep outcomes moving while running targeted health bets:
- Health bet 1: add characterization tests around the scheduling rules before touching them again.
- Health bet 2: remove an old “temporary” rules engine path still used by 12 percent of customers.
- Health bet 3: add a dedicated “schedule validation” log and alert to catch the most common data corruption case.
What do they measure? Not “we refactored stuff.” They track:
- Lead time for changes: time from starting a ticket to deploying it.
- Change failure rate: percentage of deploys that cause incidents or hotfixes.
- Support load: count of scheduling-related tickets per week.
- Confidence (optional): a simple 1 to 5 rating at sprint end, “How safe did changes feel?”
After a month, recurring appointments still shipped. But now changes to scheduling rules stop triggering surprise regressions, and support tickets trend down. The result is not just fewer fires, but faster delivery of the next set of features.
Common mistakes
Two-speed roadmaps fail in predictable ways. Avoid these traps:
- Maintenance as a grab bag: “cleanup” is not a plan. Each health item needs a success metric, even if it’s imperfect.
- Over-scoping health work: multi-month refactors are where budgets go to die. Slice it into verifiable steps that can be shipped.
- Hiding maintenance under features: bundling “and we refactor everything” inside a feature ticket makes tradeoffs invisible and planning unreliable.
- Using maintenance to avoid decisions: sometimes the real problem is product ambiguity. Maintenance work cannot substitute for choosing a direction.
- No operational feedback loop: if you do not track incidents, build health, and lead time, you cannot tell if the health stream is working.
When not to do this
A two-speed roadmap is a steady-state model. There are times when you should temporarily break the rule:
- Emergency reliability work: if the system is actively unsafe to operate, treat stabilization as the outcome. Pause discretionary feature work.
- Existential product risk: if you must validate a market direction quickly, short bursts of feature focus can be reasonable, but set an explicit end date.
- Major platform shift with hard deadlines: sometimes external constraints require concentrated migration work. In that case, frame the migration as an outcome with clear checkpoints, not as “debt.”
The key is to make the exception explicit and time-boxed, then return to the budget. “Just for a little while” is how exceptions become the new normal.
Key Takeaways
Use a two-speed roadmap: plan customer outcomes and engineering health as two first-class streams, not competing leftovers.
Set a debt budget: pick a simple capacity rule and protect it. Consistency beats intensity.
Make health work measurable: define success in terms of lead time, incident rate, CI stability, or support load.
Keep health bets small: prefer shippable improvements over grand refactors that never finish.
A checklist you can copy for your next planning cycle
- Choose your budget rule (percentage, fixed slot, or alternating cadence) and write it down.
- Define “engineering health work” in one paragraph for your team.
- Create a health backlog with items that each include: scope, owner, and a measurable before/after.
- Pick 1 to 3 health metrics (lead time, change failure rate, CI flake rate, incidents, support tickets) and track them weekly.
- Plan the sprint by allocating capacity to outcomes and health according to the budget.
- Review health work like features: did the metric move, did it reduce risk, and what did you learn?
- Adjust the budget quarterly: increase it if the system is brittle; decrease it cautiously if stability is strong and metrics are trending well.
Conclusion
A roadmap is not just a list of features. It’s a commitment about how your team will spend limited attention. A two-speed roadmap makes maintenance a deliberate investment rather than an apology.
If you keep the health stream measurable and small, you can ship features without quietly increasing the cost and risk of every future change.
FAQ
What debt budget percentage should we start with?
If you have recurring incidents, slow releases, or fragile tests, start at 20 to 30 percent. If you’re relatively stable, 10 to 20 percent can work. The best number is the one you can maintain for months without constant renegotiation.
How do I explain maintenance work to non-engineering stakeholders?
Describe it in terms of outcomes they care about: fewer outages, faster delivery, less rework, fewer support tickets. Bring one metric to each planning conversation so it stays concrete.
What if we can’t find “small” health work and everything feels huge?
That’s usually a sign that you need better boundaries. Start with safety rails: characterization tests, clearer logging around failure points, and removing dead paths. These often unlock smaller, safer refactors later.
Is refactoring always technical debt work?
Not always. If refactoring is necessary to deliver a specific feature, it can be part of the outcome stream. Use the health stream for refactors whose main purpose is reducing future cost-of-change or operational risk.