← All Blog Articles

Keeping The Lights On in Product Roadmaps

Stop pretending that 100% of your P&E team is doing feature development

·Mark Holt
Keeping The Lights On in Product Roadmaps

Here’s a roadmap planning mistake I see constantly: product leaders presenting ambitious feature roadmaps that assume their engineering teams will spend 100% of their time building new capabilities. It’s a fantasy. And it sets everyone up for failure.

Every software organisation has “keeping the lights on” (KTLO) work. This isn’t optional overhead you can wish away through better planning. It’s the essential maintenance, support, and operational work that a) keeps your existing products running while you build new ones and b) keeps your engineering team effective.

The amount varies. A greenfield startup might spend 10-15% on KTLO. A mature enterprise with legacy systems and regulatory obligations? Easily 40-50%. But zero? Never. And pretending otherwise creates roadmaps that are, quite simply, lies.

I work a lot with Private Equity owned SaaS businesses. There are some good examples further down the article but, as a guide, I would expect a growth business that has achived Product Market Fit and has been around for 5-10 years to be spending approximately 30% of their resource on KTLO activities. Q1 might be less and Q2 might be more, but across the full year companies that aren’t spending this are probably building up a backlog that will bit them in the end.

1. What Exactly Is KTLO Work?

KTLO—sometimes called “business as usual” (BAU) or maintenance work—refers to the minimum activities required to maintain your customers’ current level of service. As SVPG explains , these are items like “essential business reporting, business compliance changes, and fixing critical issues that may arise.”

The key distinction? KTLO preserves the status quo. It doesn’t build anything new or improve internal productivity. It simply keeps your existing promises to customers.

John Cutler, in his excellent piece TBM 234: Maintenance, KTLO, and BAU , argues we’ve got the mental model wrong. We think of software like car maintenance—oil changes and tyre rotations that preserve current state. But software is more like gardening: it requires “seeding, weeding, pruning, watering, cultivation, and adaptation.” The work is ongoing and never truly complete.

Why KTLO Carries Stigma (And Why It Shouldn’t)

There’s an uncomfortable truth in most organisations: KTLO work is seen as less prestigious than feature development. Engineers want to build new things. Product managers want to ship features. Nobody puts “maintained existing security protocols” on their CV.

Yet as Cutler points out, KTLO is often “the highest leverage/value work a team might tackle.” A security patch that prevents a breach. A compliance update that avoids regulatory fines. A bug fix that stops customers churning. This work directly protects revenue and reputation.

The stigma creates perverse incentives. Teams underreport KTLO time. Leaders ignore it in planning. And roadmaps become fiction.

2. The Real Cost of Ignoring KTLO in Your Roadmap

When you plan as if KTLO doesn’t exist, several predictable failures occur:

Chronic Roadmap Slippage

Features consistently miss deadlines because teams are pulled away for “urgent” maintenance work that was never planned for. Stakeholders lose trust in roadmap commitments. Engineers burn out from constant context-switching between planned work and firefighting.

Technical Debt Accumulation

SVPG warns about what happens with project-based teams that don’t own their code long-term: “ballooning technical debt” and “orphaned projects.” When maintenance isn’t planned, it doesn’t happen. And deferred maintenance compounds.

The KTLO Death Spiral

Here’s the vicious cycle I’ve seen repeatedly: KTLO is ignored in planning → technical debt accumulates → systems become fragile → more incidents occur → more time spent firefighting → less time for planned work → roadmap slips → pressure to “catch up” → KTLO ignored further.

SVPG’s Team Objectives - Action article describes the end state: “this ongoing work can reach the point that it consumes the team.” When that happens, leadership faces a stark choice: accept no progress on objectives, invest heavily in reducing the overhead, or grow the team.

3. 15 Types of KTLO Work You Must Plan For

Looking at articles from SVPG , LogRocket , BMC , and Axify , here’s a list of KTLO activities:

1. Bug Fixes and Defect Resolution

Customer-reported issues that block workflows or degrade experience. These arrive unpredictably and demand response.

2. Security Patches and Vulnerability Remediation

Staying ahead of known vulnerabilities in your codebase and dependencies. This includes CVE responses, penetration test remediation, and security audit findings.

3. Regulatory Compliance Updates

GDPR, PCI-DSS, SOC 2, HIPAA, accessibility standards—the list grows yearly. Compliance isn’t a one-time achievement; it’s ongoing maintenance.

4. Dependency Updates

Third-party libraries, frameworks, and platforms deprecate constantly. Node versions, database engines, cloud provider APIs - all require regular attention. I regularly see businesses with platforms stuck on Java 7, facing a big bill for upgrading and carrying huge security risks. For the love of god, please allocate the time to stay current. It costs basically nothing if you’re chipping away.

5. On-Call and Incident Response

Someone must be available when systems fail. The cognitive load and time commitment of on-call rotations is real work.

6. Customer Escalations

When standard support fails, issues escalate to engineering. These interruptions are unpredictable but inevitable.

7. Infrastructure Maintenance

Server patching, certificate renewals, capacity adjustments, backup verification. The unsexy work that prevents outages.

8. Technical Debt Payments

The interest comes due eventually. Refactoring brittle code, improving test coverage, upgrading outdated patterns.

9. Documentation and Knowledge Transfer

Keeping internal docs current as systems evolve. Onboarding new team members to existing systems.

10. Performance Optimisation

Addressing latency issues, memory leaks, and scaling bottlenecks as usage patterns change.

11. Data Management and Archival

Database maintenance, data cleanup, archival policies, storage optimisation.

12. Integration Maintenance

Third-party APIs change. Partner systems evolve. Integration points require ongoing attention.

13. Monitoring and Alerting Tuning

Adjusting thresholds, reducing alert fatigue, improving observability as systems change.

14. Essential Business Reporting

Finance needs data. Leadership needs dashboards. Compliance needs audit trails. This work happens continuously.

15. Cross-Team Support

Other teams need help with your systems. These internal “customers” have legitimate needs that consume capacity.

4. How Much Capacity Should You Allocate to KTLO?

The honest answer: it depends. But several benchmarks provide guidance.

50-80% of IT Budgets (Are You Kidding Me)

BMC cites Ventana Research recommending KTLO account for “50-80% of the overall budget.” A Vanson Bourne survey found 77% of IT leaders viewed excessive KTLO spending as a major obstacle to innovation.

Personally I find that number terrifying! If that’s where you’re playing, I’d love to have a chat to find out what’s driving that and how you’re escaping from that trap.

Agile Teams Commonly Allocate 25-30% (YES!)

For product development teams specifically, 25-30% is a common baseline. This translates to roughly one day per week per engineer on maintenance activities.

The 20% “Healthy” Threshold (Meh)

Chase Seibert, in his piece on Killing Features to Reduce KTLO , proposes 20% as a healthy rate, aligning with the principle that “80% of the roadmap should be product led and 20% should be engineering led.”

His warning signs: at 30% KTLO, teams experience stress. At 40%, it correlates with attrition.

LaunchDarkly’s 50% Example

Notably, Axify reports that LaunchDarkly dedicates 50% of engineering time to KTLO work—though this includes everything that isn’t new feature development, such as bug fixes and support escalations.

5. Factors That Increase Your KTLO Burden

Your specific allocation depends on several factors:

Product Maturity: Greenfield products have less maintenance. Mature products with years of accumulated features and technical debt require more.

Legacy Technology: Older tech stacks with outdated dependencies demand constant attention. Modern platforms with good abstractions require less.

Regulatory Environment: Healthcare, finance, and government-adjacent products face heavier compliance burdens.

Customer Base Size: More customers mean more support escalations, edge cases, and scale-related issues.

System Criticality: Mission-critical systems require higher availability and more robust monitoring, increasing operational overhead.

Team Experience: Teams unfamiliar with the codebase need more time to address issues effectively.

6. RoadmapOne Perspective: KTLO Is Not Optional

It is beyond critical that CPOs consistently acknowledge KTLO as a fact of life for product teams. SVPG guidance offers several important principles:

Don’t Pretend KTLO Requires Discovery

SVPG’s Roadmap Alternative FAQ makes clear that KTLO items don’t need the same rigour as strategic initiatives: “unless there’s real risk with any of these items, we typically just put these directly onto the product backlog. We don’t worry about the outcome, and we don’t worry about validation. We just knock these out.”

This is liberating. Not everything needs a hypothesis. Sometimes you just need to update the database driver.

Monitor KTLO Carefully

Team Objectives - Management warns that if KTLO work “spikes, the team won’t be able to make much progress on their team objectives.” Leaders must track this ongoing cost.

The implication is clear: KTLO isn’t fixed. It fluctuates. And those fluctuations must inform roadmap planning.

Consider Dedicated Rapid Response Teams

SVPG’s Rapid Response Team article describes a structural solution: small teams (2-4 developers) dedicated to handling “critical fixes for sustaining products,” “minor enhancements” that would disrupt main teams, and “time-sensitive critical issues.”

This approach functions as “a relief valve for the organisation,” enabling responsiveness without constantly derailing focused product work. The original teams make faster progress, and customer responsiveness improves dramatically.

Distinguish Investment from Sustaining Products

Portfolio Grooming introduces the concept of “sustaining” products—cash cows that receive bug fixes and compliance updates but no new features. These products don’t need dedicated product managers or engineers; they need minimal maintenance investment.

The insight here is that not every product in your portfolio deserves active development. Some should be explicitly in “keep the lights on” mode, freeing capacity for products that merit real investment.

7. Practical Strategies for Managing KTLO

Make the Invisible Visible

You can’t manage what you don’t measure. Start tracking KTLO time explicitly. Survey your teams about what percentage they’re spending on maintenance versus new development. The numbers will likely surprise leadership.

RoadmapOne helps teams to ensure that KTLO is included in the Roadmap. Using a methodology like Gartner’s RGT can help stakeholders to understand the impact of major KTLO items and

RoadmapOne showing Gartner RGT Roadmap allocation

We can see here that 30% of our roadmap in Q1 is allocated to KTLO activities. That feels fairly healthy.

Uplevel’s research found that teams with transparent time allocation data have more strategic conversations and report higher developer satisfaction.

Protect Dedicated Time

Several approaches work:

Rotating KTLO Duty: One team member per sprint handles all incoming maintenance work, shielding others from context-switching. This person rotates each sprint.

Dedicated Sprints: Periodically schedule full sprints for maintenance work. Some teams do this quarterly; others use firebreak sprints —focused periods where all squads align on platform health objectives, pausing feature work to address critical technical issues that can’t wait.

Percentage Allocation: Reserve a fixed percentage (say, 20%) of each sprint for maintenance, making it a first-class citizen in planning.

Dedicated Teams: There is a pervasive, unhelpful, and frankly wrong assumption that most engineers won’t want to work on KTLO activities. In 20-years of experience I can tell you that is nonsense! There are a group of engineers who absolutely love this kind of work. Making things easy for the wider team and constantly shipping architecture changes, patches that reduce complexity and protecting our customer data is actually great fun. Depending on the phase of your lifecycle, don’t be afraid to use this approach.

Reduce KTLO Through Simplification

Seibert argues the highest-ROI approach is “killing features”—removing complex, low-value functionality rather than just fixing bugs. Every feature you remove is a feature you no longer maintain.

Ask yourself: which features have low usage but high maintenance costs? Retiring them frees permanent capacity.

Automate What You Can

Manual KTLO processes are prime candidates for automation. CI/CD pipelines, automated testing, infrastructure-as-code, and self-healing systems all reduce the operational burden.

Invest in Platform Engineering

Axify notes that Site Reliability Engineering (SRE) and Platform Engineering strategies reduce cognitive load by providing standardised tools and automating operations. Instead of every team solving the same operational problems, platform teams solve them once.

8. The Product Leader’s Responsibility: Honest Roadmaps

If you’re a product leader, your roadmap reflects your promises to the organisation. When you promise more than your team can deliver because you’ve ignored KTLO, you’re not being ambitious—you’re being dishonest.

An honest roadmap accounts for reality:

  1. Calculate your actual capacity: Engineers rarely get 40 productive hours per week. Meetings, Slack, and context-switching consume 15-25% before any KTLO.

  2. Reserve explicit KTLO allocation: Based on your product’s maturity and context, allocate 20-40% for maintenance work.

  3. Plan features with remaining capacity: Only after accounting for overhead and KTLO should you commit to new features.

  4. Communicate transparently: Help stakeholders understand why 10 engineers don’t equal 10 engineers worth of new features.

9. Visualising KTLO in Capacity-Based Planning

This is where tools matter. Spreadsheets and slide decks can’t show you the relationship between team capacity, KTLO commitments, and planned feature work.

You need to see:

  • How much capacity each squad actually has per sprint
  • How much is already committed to KTLO and ongoing work
  • What’s left for new objectives

This is exactly what RoadmapOne provides. The grid interface shows squads in rows and sprints in columns, making capacity allocation visible at a glance. You can see immediately when a squad is overcommitted or when KTLO work is consuming more than planned.

10. Conclusion: KTLO Is The Price of Admission

Every company that has shipped software has KTLO work. The amount varies—early-stage startups face less; mature enterprises face more. Companies in regulated industries face even more. But no one gets zero.

The question isn’t whether you’ll do KTLO work. It’s whether you’ll plan for it honestly or pretend it doesn’t exist and wonder why your roadmaps never land.

Product leaders who acknowledge KTLO in their planning build trust with engineering teams, set realistic expectations with stakeholders, and actually deliver what they promise. Those who don’t create a fantasy world where commitments slip, engineers burn out, and technical debt compounds until it becomes a crisis.

As SVPG reminds us, team objectives aren’t the only work product teams do. There’s always “keep the lights on” work—and it’s not going away. Plan accordingly.

References: