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. 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. Let’s explore the typical categories:
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.
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 KTLO:
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 were able to reach our goals the following quarter without any hiccups.
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; 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.
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.
Sanjay Modi discusses his role in leading a website security product portfolio through drastically changing customer needs.
The acronym SDK stands for software development kit. It contains platform-specific tools to run and develop software.
If you think about some of the businesses that market familiarity as a selling point, you actually don’t get negative vibes from them at all.