Editor’s note: This article was reviewed and updated on 8 October 2024 to provide a clear definition of KTLO, more information about its benefits and drawbacks, specific examples of KTLO activities, and more.
KTLO means “keep the lights on” in a modern business context and refers to the activities that keep a company’s core services and operations running smoothly. For example, KTLO in product management refers to the ongoing efforts that are essential for maintaining and supporting a digital product’s functionality and performance.
Digital products are complex. As a product manager, surprises are your only certainty. Whenever you think you’re done and can move onto the next fancy feature, an annoying bug pops up, and suddenly you have to find a solution.
An essential part of being a PM is understanding that digital products are different from physical ones. Digital products require constant evolution to remain relevant, while physical products require production right from the beginning because repairing them later is troublesome.
A constant challenge for digital product managers is balancing keeping the product working and innovating. While KTLO helps prevent technical debt from building up, it can take time and effort away from pursuing new opportunities that deliver value to your customers and your business.
In this article, you will learn what the phrase keep the lights on means and how you can implement it within your product team.
Keep the lights on refers to everything that comes between your product and your customers receiving its promised value. Typical KTLO categories could include:
Examples of KTLO activities that fall under these categories could include:
In other contexts, like IT, business ops, and project management, the phrase “keep the lights on” has slightly different meanings. For example, KTLO in project management might describe maintaining a project’s infrastructure and supporting ongoing systems and processes.
Fixing bugs is important in IT maintenance as well, while keeping the lights on in a business context could refer to maintaining staffing levels or continuing operations, even if it’s not making much progress.
KTLO is necessary and important — in some ways, it’s inevitable. However, keep in mind that focusing too much on KTLO could be time-consuming and expensive, detracting from progress on other, more valuable activities.
To better understand KTLO, let’s take a look at the following image from Henrik Kniberg and reflect on the core difference:
The first part applies to a physical product, which may take years to market. The second part is better for digital products because you reduce the time to deliver value. Yet, you will need to do some KTLO work continuously.
In physical products, you’re done when the product is available in the market, while with digital products, the work starts once customers can consume the product. That’s the moment you realize what doesn’t work. You will probably discover bugs, uncover usability glitches, and whatever plan you have will go water down.
Let me be clear: you cannot avoid KTLO. It’s a part of every business, so you need to take proactive measures against it. Try to avoid the following:
Given that KTLO is inevitable, how do you balance it with your team? Over the years, I’ve seen multiple ways, but the key is to remain focused. Alongside that, here are four strategies you can employ.
The most common strategy is to segment sprints into innovation (50 percent), tech debt (20 percent), bug fixing (20 percent), and buffer time (10 percent). Logically, it works; practically, it seldom does.
Context switching has a high cost, which backfires, reduces productivity, and hinders collaboration. Divide and conquer is the easiest approach, but not the best.
A support or separate team takes care of incidents. They are fully responsible for KTLO work. This alternative can work but requires knowledge transfer from the innovative (feature) team to the support (KTLO) team.
I discourage this format for two reasons. First, the KTLO team only deals with tedious work, making it hard to motivate them. Second, it can get in the way of accountability, as one team delivers and the other maintains.
Every day, week, or cycle, a dedicated team member focuses on KTLO. This format is a sustainable balance because the team shares the burden, and everyone suffers equally.
I favor this approach as it increases accountability and quality. Every team is different. I recommend exploring rotations per day, week, or whole sprint and then deciding what fits you best.
Some KTLO work does require more time. For example, migrating an outdated technology or refactoring an unmaintainable code. For such situations, I recommend focus time.
You can use whole sprints or even quarters for that when necessary. KTLO will ensure your product grows sustainably. Ignoring it will make your life harder.
Dealing with KTLO is inevitable, but you can reduce the burden. Some practices simplify your life so you can focus more on innovation than firefighting, especially if you’re facing pressure to reduce budgets, save time, or make progress elsewhere.
Whenever you hear a software engineer complaining that the code is smelling, you should have a conversation and evaluate what’s happening. Ignoring that will enable you to create more short-term features, but lead to massive KTLO work in the future.
Here are a few strategies to reduce work related to keeping the lights on:
It may also help to keep a KTLO budget separate from other organizational budgets to better help with resource allocation and planning.
Product management isn’t project management, although KTLO is a vital part of both. But in product management, you’re not done when the feature is live; it’s just the beginning.
For strategic planning, ensure teams know what to achieve instead of what to deliver. When product managers create prescriptive feature roadmaps, teams cannot do what they are told. Sadly, accountability evaporates, and ultimately, more KTLO comes to exist.
Great product managers share the context and objectives with the team. Then, you can decide what makes sense to do. Let me give you a brief example.
In one ecommerce site where I worked, we had to scale it up. Our goal was to broaden our product offering and attract more customers. I shared with my team that we should grow tenfold in two years. Shocked, the software engineers told me we had to review our architecture immediately because it wasn’t ready for that.
Initially, I became resistant because I feared we’d invest too much time in it without creating the new features. Yet, one software engineer’s words stuck with me: “You either invest in it now to work in the future, or you ignore it now to break in the future.” That got me thinking and I became convinced.
As I shared the growth plan and objectives, the software engineers realized we needed to change our integrations and infrastructure. It took two quarters for that. Yet, we were able to reach our goals the following quarter without any hiccups.
Whether you like it or not, you will have to deal with keeping the lights on. What matters is how you deal with it.
Strive to provide focus to team members. For day-to-day activities, let team members take full accountability; for the more complex ones, plan accordingly. Try to avoid packed roadmaps as much as possible. Instead, increase code quality, test coverage, and treat tech debt wisely.
Following these tips will help you achieve a balanced approach to KTLO, allowing you to maintain quality in your digital product while still innovating.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Over the last years, tech people became resistant to Agile frameworks because their expectations of empowerment didn’t materialize.
Andrew Cheng, VP of Product Management at WellSky, shares examples when he’s made short-term trade-offs for long-term career opportunities.
Chris Holland talks about how his teams develop a model for project teams to render their own evaluations or conduct their own user research.
What’s Agile really about? In this blog, I explore the history and implementation of the Agile Manifesto and uncover how its values drive product innovation and collaboration.
Learn more →
