Maintain: to sustain, or to keep in an existing state. - Merriam-Webster Dictionary

In the tech world, the word “maintenance” is often thought of as the opposite of innovation. It is a boring word. Maintenance: given what we have today, how do we keep it basically functioning as-is without investing in net new functionality? We generally hire for innovators in tech, so what happens to the maintainers?

When we begin to deprecate software, we move them into “maintenance mode”, simply provide support and patches only for security updates or major fixes, if available. We want to put a minimal amount of work put into this product because additional investment in new features will likely not pull in reasonable organizational impact per effort. Keep making money and not spend any more effort on it? Sounds like an investor’s dream come true.

Talk to anyone with a live “maintenance mode” product and ask them for the cost of maintaining it. 90% of the time, they will give you a much higher number than you would expect. This is why:

• Contractual Obligations - You must support existing clients in production because you said you would.
• Client Satisfaction - A bad experience with a maintenance product impacts your brand. The client doesn’t care about your profits. They paid for a service and you’re expected to provide it.
• Nothing is dead until it’s dead - As long as something is live in production, it will cost you. Your clients don’t stop changing their systems, and something will break. The more critical your product, the harder and longer it will take your clients to move off, and the more expensive maintenance will be. You might not have the option of saying no.
• Even when it’s dead, it might not be dead - Extended maintenance is a real thing. It’s hard to say no to money from clients if your organization is struggling or not disciplined enough to stay out of the Product vs Service Model trap.

The Harsh Reality

Changing focus is super normal when we’re talking about limited numbers of devs and designers to build better solutions for our customers. When we decide to not work on a live product with customers in production, we start losing context through natural attrition and lack of practice.

Perhaps it’s a fairly stable product with minimal production issues. We move all of the devs and designers over to the new initiatives. 6 months later, you have a major production failure on the legacy product. By then, perhaps 30% of the main team has turned over (Median tenure of a software developer in the US is 1-2 years).

If you choose to fix this issue:

• Your developers will need to get caught up on the product to understand the issue, and relearn the systems to do so. This is harder to do if it is on a different tech stack.
• Your Support team has also been cobbling together a product lifetime’s worth of workarounds to make the product keep working, and now these might break your new fix as well.[1]
• Your team stops working on your new stuff that will help you hit your goals.
• Major production issues like these usually have smaller follow up issues.
• Customers will jump on this as a “you’re doing something in the old product can you add this as well?”
• You probably don’t even have a product manager on this old product anymore, so helping the team say no to that customer’s request is doubly challenging.

And it goes on. It breaks every single system you have in place because our existing systems are all structured around building net new value.

Product End-of-Life

You often don’t have the choice to say no to fixing things until the product is dead. Let’s talk about why it’s still not dead.

Say your clients are the biggest banks in the world, and they use your product to make the regulators happy. Your product costs a fortune to buy and pay for subscription/support, train users on, and even more to implement internally due to the complexity that is a bank. They are content enough to use the ancient software, and update only when they absolutely have to because they got audited[2]. If you withdraw the product, you lose all of your existing support revenue on that product line, plus you anger the client, who might pull their relationship with your entire brand.

Sales doesn’t want this. Execs doesn’t want this. Your parent company / investors doesn’t care what or how you do things, as long as you hit your target, and you don’t make the big shared portfolio clients angry. Why not keep it in maintenance mode until interest peters off, or you build a migration path to something better?

B2C isn’t much different. Think about every single time Google killed your favourite product (RIP Google Reader and Inbox.) I moved off Chrome and several other Google services as a result. Think about every single time your favourite app completely re-did their user interface and you hated it, along with the rest of the internet and they lost market share. Customer facing change is expensive and a huge risk.

That said, I wonder how much old.reddit.com is costing Reddit.

Killing products is a hard conversation. You need to build a cost business case on how much it will cost to maintain this product. You need to find the inflection point at which it makes sense to formally announce and withdraw the product. You need to figure out how to deal with angry clients, and maybe provide migration solutions. This could be a partnership with a competitor if you’re trying to exit the space. You need to do this within the contracted notice periods. The bigger your clients are, the messier this gets.

Until then, we need to figure out what maintenance looks like.

Doing Maintenance

There are several ways of maintaining an old product:

1. Dedicated maintainers
2. Business as usual (BAU) with dedicated time to maintenance
3. Business as usual and shift our schedule as things break.
4. Dedicated Rotational L3 Team

It’s highly situational which one makes sense. Everything is expensive from an opportunity cost perspective.

I would like to note that in #1 and #2, we are essentially budgeting time towards this old product, which means you may actually be building new things in said product, even though it’s low priority.

At what point is a new feature a fix? If you leave a product long enough, there will be expectations for improvement from paying customers. There are no easy answers.

Dedicated Maintainers

This case makes the most sense for a product that continues to have a high volume of support requirements, and the organization is not opposed to building one or two little things if time permits. There is basically no research or design at this point.

In a world of dedicated maintenance, there are generally 3 categories of dedicate single product maintainers:

1. The people who built the thing and are therefore experts.
2. Junior or less experienced people, who aren’t working on the cool new stuff.
3. Outsourced teams.

Group 1: Experts

You spent the last 2-10 years building what was the coolest new product in your industry, and now it’s being replaced by a shinier solution on another framework. You’ve been a builder your entire career, and now you’re being asked to fix old problems that don’t really solve any net new issues for your customers. Would you stay?

This is how I felt when I was asked to maintain business as usual and enforce compliance after years of leading major organizational change. (Clip from Rick and Morty)

Group 2: Juniors

You joined this company to work with really cool devs, and you find yourself in the group that gets all the blame when customers are unhappy. You don’t get to build your skillset on solving new problems, just what the regular devs broke in the old days. How would you feel? How long would you stay?

Group 3: Outsourced

You know you’ll never be a part of the main group. There is high turnover, so you constantly have to train new people on the context. In my experience, this is really, really expensive as the trainers tend to be the super knowledgeable people. As soon as these devs get enough experience, they’ll leave and go somewhere to get real building experience.

Don’t get me wrong. There are people who are incredible maintainers and love doing this work. We don’t build organizations that support the culture of maintenance, and therefore it isn’t work that ends up being valued. I wonder if this is also why Support is chronically undervalued and underfunded.

BAU with Dedicated Time

This version allows most dev time to be focused on the net new, but the team has a dedicated bucket of time (often a sprint at a set cadence) to do maintenance fixes.

This works best in a team who has a bit more ability to manage context switching between sprints and has plenty of support on the engineering operational side. It has a moderate volume of support requests for the old product, and they are generally lower priority issues. It is less pleasant for the teams who are really into the problems they are solving with the new product, and the sentiment towards the old product continues to sour.

This model distributes the responsibilities across the team, and allows everyone to recognize the cost of maintenance, and therefore makes it easiest to make the case to withdraw the product when the time comes. The context switching makes for unhappy developers though, so it is generally an unpopular model.

BAU with Maintenance as Needed

This works best with a product with minimal maintenance requirements. You blaze forward with the new things, and when things break, you slot it in your schedule. The main challenge with this is that you never know when things break, and it throws a wrench in your delivery timelines and team focus. You also begin to lose the skills needed to support the maintenance product.

This is the least expensive method in the beginning, but rapidly becomes expensive as natural attrition and transfers start hitting your SMEs across the organization. You MUST have an end of life plan with this strategy.[3]

Rotational L3/Maintenance Team

This is a group of developers that are rotated in and out on a set cadence (often 3-12 months), usually voluntarily. This team takes care of all maintenance requests across the portfolio including the maintenance product, and provides a feedback loop back to their original team and the support team in terms of issues that they’re seeing.

It’s a great cross-platform developer training space, but takes a lot more operational overhead and organizational maturity to be effective. The rotational feature also allows developers to know that it’s not permanent, and work with developers with different skillsets. This team is also a great forum to cross-train and prime potential development leaders and managers, as well as SRE oriented people.

I am evidently biased towards this model. It requires leadership. It tends to be the toughest one to sell to an organization as a whole. This requires pulling developers full time to focus on the current client experience instead of the net new features. (What a terrible thing. /s) It requires calling out the costs of maintenance across the board, and therefore drawing attention to quality, which leads to hard questions.

What if we change the face of maintenance by calling it “training our developers better”? Suddenly, maintenance mode doesn’t sound too bad in the short term.

Time to Go

Maintenance Mode is not “cheap revenue”.

No matter what route you choose, the longer you put something in maintenance, the more it will cost you. There will come a time when the costs outweigh the value it brings in.

Final pieces of advice:

• Withdrawals take longer than you think, especially in the B2B space, so plan for it in advance.
• Remove the burden from your limited pool of people doing the work so you can collectively focus on more important activities.
• Consider:
  • Who are your maintainers? How are they feeling?
  • What does your ROI over time curve look like?
  • When is the withdrawal final?

If you systemically address things that are not the current investment focus, they won’t turn into zombies and wreck havoc on your day-to-day flow. You must withdraw old products before it’s too late.

Footnotes

(Footnote links broke in the migration.)

[1] Support is often a thankless job. I have seen so many support teams work absolute magic with products. If you ever need to know about a weird customer use case or set up, check with your support team.

[2] In the days before better CRMs, it’s impressive what happened when you announce software withdrawals. Clients came out of the woodwork to request extended support for $$$, which was literally us agreeing to answer the phone and read the documentation back to them with response time SLAs. Zero expectations of software maintenance. I have so many questions.

[3] When I left a previous company, I was one of the very few people who knew anything about a product that was still in production. Most of the leaders kept forgetting about its existence, but they did not want to formally withdraw it because of the possible backlash. We had 0 devs remaining who built the initial product. I sometimes wonder what happened to it.

Thanks for reading!

This post was inspired by:

• This Topic of the Week on difficult product decisions.
• This 2016 Aeon article: Hail the Maintainers
• My years of experience as “the EOL PM”, and people asking me to maintain a major change process I spent years setting up. I’m a change pusher and have no interest in pure maintenance. Stop expecting your builders to do maintenance.

I like to do long, accessible deep dives into an idea. These articles take quite a long time to put together. I hope I made you think. If you made it this far, thank you for your time investment.

Self-Promotion

Do you happen to need someone who understands product management, change, and organizational complexity? I am currently looking for my next role, and am always up for a chat. Book some time with me here.

Are you a product professional in Toronto? Join us at productto.org. We do in-person small group deep dive 90 minute discussions once a month. This is where I grew up in my product practice.