How to Balance Keeping The Lights On With Innovation
Creating value while keeping your product valuable
The first version of this post was released at LogRocket.
Hey everyone,
One of my biggest challenges as a product manager has been balancing maintenance with innovation. I cannot recall how often I argued with software engineers about refactoring and paying tech debt off.
Shall we have a chat about it? Let me help you understand how to balance maintenance and innovation to drive value while keeping your product valuable.
This free episode of Untrapping Product Teams will take around 7 minutes to read.
Digital products are complex. As a product manager, surprises are your only certainty. Whenever you think you’re done and can move on to 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 differ 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. In this article, you will learn what the phrase keep the lights on means and how you can implement it within your product team.
What does keeping the lights on (KTLO) mean?
Remembering to keep the lights on is fundamental for ensuring your product effectively delivers on its value proposition. KTLO relates to everything that gets between the product and the promised value. Let’s explore the typical categories:
Bugs → Unexpected behavior that distracts or blocks users from benefiting from the product, forcing them to churn or disengage
Maintenance → Like a car, doing what it takes to keep the product sustainable for the long run. That includes updating the tech stack, evolving coding, etc.
Debt → Teams often create debts unintentionally, which complicates how fast they can deliver value. That’s why it’s crucial to have a strategy to avoid debt and pay off what’s already created
Understanding KTLO with digital products
To better understand KTLO, 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:
Packed roadmaps → When you have extensive feature roadmaps, the team has no chance but to cut corners and focus on delivery. Inevitably, quality will suffer, and KTLO will increase
Trying to build perfect solutions → When you strive to build scalable solutions from the beginning, you will end up causing waste. First, you need to learn what works and then improve your solution
Full-blown releases → Delivering new features to everyone at once runs the risk of disturbing all of your customers. That’s why it’s fundamental to release gradually, limiting the reach so you can incrementally learn
How to balance keep the light on with innovation
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.
Divide and conquer
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.
Dedicated team
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.
Dedicated team member
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.
Dedicated time
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.
Strategies for minimizing KTLO
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.
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 will lead to massive KTLO work in the future.
Here are a few strategies to reduce KTLO:
Test coverage → Ensure that your product’s code base has solid test coverage, a minimum of 85 percent, ideally 90 percent or greater. This will reduce the surprises with bugs
Tech debt → Effectively dealing with tech debt is a thin line between love and hate. Software engineers will resist creating tech debt because PMs tend to deprioritize paying it off. Ensure that you first build to learn (hacking a quick solution) and then scale
Make it better → It’s good to encourage software engineers to improve the code when they visit it. Such minor improvements result in more quality and a more robust product
The impact of keeping the light on for strategic planning
Product management isn’t project 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 e-commerce 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 convinced me by saying, “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 reached our goals the following quarter without any hiccups.
Key takeaways
Whether you like it or not, you will have to deal with KTLO. 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 and plan accordingly for the more complex ones.
Try to avoid packed roadmaps as much as possible. Instead, increase code quality and test coverage and treat tech debt wisely.
Let’s rock the product world together!
Here are three ways I can help you even more:
Upgrade your subscription to Premium and get one deeply thought newsletter per month (20+ minutes reading) plus access to 300+ episodes
Join my cohort, Product Discovery Done Right
Have a lovely day,
David
All of this is true! And you constantly need to explain this to other people.
A year ago, I called the main benefit of KTLO the "reduction of future surprises" (https://www.leadinginproduct.com/p/when-to-plan-maintenance-work).