S4 Ep. 3: Weighing the options: How do product leaders allocate resources to products in Maintain or Sustain?

Are you a product leader seeing growth plateau for some of your most adopted products? 

Are you struggling to reallocate resources away from legacy products and onto new growth opportunities?

Are you being asked to do more with less?

If so, you're not alone.

In the 3rd episode of our Resource Allocation mini-series, we answer the question: How do product leaders allocate resources to products in Maintain or Sustain?

Hope Gurion: Welcome to the Fearless Product Leadership podcast. This is the show for new product leaders seeking to increase their confidence and competence. In every episode, I ask experienced and thoughtful product leaders to share their strategies and tactics that have helped them tackle a tough responsibility of the product leader role. I love helping emerging product leaders shorten their learning curves to expedite their professional success with great products, teams, and stakeholder relationships. I’m your host and CEO of Fearless Product, Hope Gurion.  

Hope Gurion: Next, we're tackling products in maintenance mode. These products are still contributing value, but there's not the same urgency, push for innovation, or race to outdo competitors. The products are working, they pay the bills, and customers or employees are using them regularly, they keep the systems up and running. We want them to keep doing just that.

• How do you determine the right amount and types of people to allocate to a product in Maintain or Sustain mode?

• What is a product outcome or typical measure of success for a product in Maintain?

• Who is best suited to work on a product in Maintain?

In this episode, we hear from multi-time Chief Product and Technology Officer, Troy Anderson and the wise technology leadership advisor, Adrian Howard of Quietstars to answer those questions.

First, Troy Anderson offers his perspective on resource allocation in Maintain.

Hope Gurion: Let's say it's a product that you want to maintain, but it's not in the center of the bullseye. But we want to maintain that with maybe we can have a small team on it or maybe it's an engineer and an associate pm or I don't know what might be probably we aren't going to need a designer in that situation. Or maybe it's a couple engineers. How do you think about the team size/structure for a maintain product?

Troy Anderson: I think the one thing in thinking through this is there's always an assumption that if you don't have people allocated like they were, the things going to fall down. Oddly, modern software is more resilient than most people give it credit for. And so you really can reduce a team a lot. And that software will still stand up, usually. I’ve found there’s a bias towards the inertia of team size.

But I've found that it's always been the case that it's better to be more aggressive than less. 

Hope Gurion: Do you have a rule of thumb about what their measure of success should be?

Troy Anderson: I mean, if it's maintained only then it's really, is it still alive tomorrow?

Okay, all right. The rule of thumb, the rule of thumb is, you know, we're not looking to grow it. We're not looking to do it. You know, is it still doing what it is? It's still sending faxes? Yes. Okay. Don't worry if they're slow. Don't worry if they're, you know, not high fidelity. Don't worry about all the things that we were otherwise normally worried about. It's still sending a fax and still getting the message across qualities. decline, don't worry. 

Hope Gurion: Yeah. I use the term “performant and bug free” but I don't really mean bug free. I mean free of the most intolerable bugs. That's the sort of rule of thumb. 

Hope Gurion: Next Adrian Howard and I discuss our different perspectives on the mindsets for individuals working on products in “maintenance” mode.

Hope Gurion:  It can be difficult for a team who has been in Invest and creating a lot of new value and seeing big impact transition to a more sort of like considered approach to whether it does make sense to increment within their product as opposed to sort of making it performant and responsive. Do you feel like the same team that got it to a place where it had gotten to a point of maturity should be the team that sort of sees it through that more slower pace of innovation or do you feel like it should be a new team? Because I do think it is a big, mindset shift and a different set of outcomes that may be more or less appealing to people who really enjoy that fast pace stage of an like an Invest stage of a product life cycle. So what are your thoughts on that mindset or characteristics of a team that's well suited to maintenance mode?

Adrian Howard: I think it's, for me, it's a people thing. Not necessarily a mindset thing. Well, sorry, that's badly phrased. Let me find a better way of saying it. For me, mindset has multiple different dimensions and different people value different things across these different dimensions. And so what you want is a team who values and is good at and enjoys the things that are gonna make the product successful at this stage. Now, sometimes that is very much like the... wardly pioneer town planner type stuff that there are people who enjoy lots of early experimentation and there are people who enjoy organizing stuff and though you know the people who all enjoy you know organizing and building for stability are going to the people who are generally going to be happier in kind of you know sustain maintenance long-term work. Equally though, I've worked with developers. Some developers really value solving hard, gnarly technical problems. And some developers really value that feedback a little bit about seeing people use their thing. And sometimes both of those groups, for different reasons, can be happy in both early stage and late stage work. that I worked with a guy who just spent, after I worked, spent three years on a big software, and all he did was go tidy up developers, like the libraries that developers had written, as like, I'm gonna write a faster whatever, because that's gonna save time, and then swapping them out for the standard library, because the standard library basically always did that better. So all he did for three years was do this thing across the code base, which was incredibly dull work. For me, it's not the kind of work I enjoy. He loved it. And an absolute ideal person for both. But the interesting thing with that work is it crossed both old existing projects that were up and running. and a whole bunch of new products that were using the libraries that these developers had written a bunch of time ago. So he was kind of, you know, he was working across multiple across the whole code base and that was affecting different products at different stages and he was helping all of them. So what was he? Was he a, is he a town planner, is he a pioneer, is he something else? I know there's people who like to find problems and people who like undefined problems. There are people who like organizing big things that thousands and millions of people use and there are people who like shoving a prototype in front of somebody and then tweaking it and sharing it to somebody else. And all of those things can be valuable at different stages. You're certainly gonna see more of some type than others at different stages, but it's understanding what your team needs at that particular point, and then finding the people who both enjoy and are good at that work. And that is, I think, much more of a... It's people and leaders knowing their teams and building... building the infrastructure in an organization that understands those values. So you can look to somebody, you know, who is going to enjoy tidying up this gnarly code base that needs to be transitioned over to the new platform. And that is a, that's not a kind of... I develop a type that say who in our team enjoys that work. And that means you have to have managers and leaders who value understanding their people and the things those people enjoy across multiple different dimensions.

Hope Gurion: Products in the "Maintain" stage of life typically don't need a full team of product manager, designer, and engineering lead.

You may be able to reduce the team to a partially dedicated engineer with a good "it's still working" monitoring system. You'll also need a clear metric to tell you if the product is still working to an acceptable level, and a system for monitoring that metric and alerting an "on-call" person or team if the product appears to stop working.

Products in Maintain may need to move temporarily out of Maintain and back into "Invest" if they begin to deteriorate to an unacceptable level. Three common reasons maintained products move back into Invest are:

• Technology advances: Even if your product stays still, your users are likely to continue to upgrade to new operating systems, web browser versions, or hardware. This can create UX or technical incompatibilities that need to be addressed with incremental investment.

• Security vulnerabilities: All software products are constantly at risk of security vulnerabilities, and even products in maintenance mode need to be patched regularly to stay secure.

• Compliance: Products in maintenance mode may also need to be updated to comply with new regulations or industry standards.

As a leader, you'll need to plan for these inevitable disruptions and decide how you want to allocate a team to address them. You may be able to use partially allocated engineers, designers, or product managers. Or, you may find that a product needs to come out of maintenance and back into Invest mode if enough deteriorations occur.

In the next episode of the Resource Allocation series, we’re going to discuss how to best allocate people and time to products in your portfolio that are in the Explore and Invest stages.

If you’re a product leader seeking to fearlessly lead your product teams through resource allocation decisions, I’d love to be of help. Please reach out on LinkedIn or send me an email to hope@fearless-product.com. I’ll respond with an FAQ about my coaching programs and a link to sign up for a free mini coaching session about a challenge you’re facing.

Fearless Product: confidence through evidence.

- - -

Feedback is a gift! Share what was most useful to you by leaving a review. Contact me on Linkedin or at https://www.fearless-product.com/contact.