The Maintenance vs. New Feature Product Manager

There is a topic I have found rather conflicting over the last several years and I wanted to explore through this article.

For a single product:

• Should we separate a team to work on product maintenance and another team to work on new features?
• Or should we have a single development team and let them decide how to balance both types of work?

In products that mature beyond their “launch” phase, the reason to consider this options is simple enough: you have tons of ideas for new features but little gets made because of a constant stream of “maintenance work” (like bugs) or current service optimizations.

Note: just to give my posture on this subject, I do not like having separate teams. I consider that a product team should be in charge of a service end to end, considering the maintenance, optimization, and new features work. They should be in charge of finding the right balance among those tasks. Imposing that balance as a stakeholder outside the team (like forcing the split in two teams as mentioned) goes in detriment of team autonomy, and in the other hand it ends up being a HiPPO decision instead of something that the team with proper deep level insights of the service can determine.

That being said, and if we decide to split teams anyway, I have found that the topic is mostly discussed from the splitting developers perspective. But what about Product Managers? Do we have one Product Manager overseeing both maintenance and new features? Or should we have 2 product managers fully dedicated to each team?

New features

When working on new features you would probably wear a Research & Discovery hat most of the time. Activities like market research, user interviews, prototyping, and experimentation will consume most of the Product Manager’s time.

This requires a tremendous amount of effort. Just considering a task like conducting user interviews: creating a screener, calling users to schedule meetings, creating and running the script, debriefing the interview, creating insights… it truly is a full-time job!

Maintenance & Optimization

In the case of the Product Manager, I wouldn’t say there is “maintenance work” since they are not the ones fixing bugs or refactoring code.

But there is a task that for mature products is enormously valuable and usually drives most growth in this phase: optimization.

Optimizing a product also requires a huge effort. Deep dive into all sort of metrics, preparing and analyzing A/B test experiments, researching user feedback through customer service or satisfaction surveys, finding automation opportunities in manual processes… it truly is another full-time job!

A grey line

When working with modern lean product development methods for creating new products and features, you release iteratively the new service with small changes each time.

So, which is the limit where a feature stops being under discovery phase and starts its optimization phase?

Let’s say you want to launch a photo sharing app. Your first iterations definitely are discovery examples: you launch a landing page test to measure conversion, you create a prototype to test with users, you create a working app to use among your friends as a beta test… but soon you have your first app in the store.

Does the discovery phase end there? Probably not. You will not be hitting your retention and growth targets. You will learn a ton of things, identify features that are not really needed and others that you don’t have and are a must to be successful.

But that big list of learnings and new things to implement can both be discovery or optimization. Let’s say you did Facebook login, and now you find out you also need Google login. Is that discovery or optimization?

Conclusion

There clearly is a lot of work on both ends. You can easily spend 8hs per day in Discovery, and another 8hs per day in optimization.

But I would still argue that the above-mentioned grey-line between discovery and optimization supports the need for “end to end” Product Managers (and product teams).

Some other reasons why the one-team approach will help:

• The same people who participated in the creation of the product and deeply understands user needs is in charge of optimizing the product to better satisfy those needs
• When you have separate teams, the features team may “cut corners” and develop a subquality product considering that the maintenance will be done by others. If they will support it, they will hold their standards high.
• If you have a single team they can shift the amount of optimization vs new features work depending on the current product state, metrics and user needs.
• Rotation between new features and optimization may keep the team more motivated

(I ran out of time but I feel I can keep thinking more benefits forever :D)

Nevertheless, the Product Manager will need the challenging skill to determine how much time and effort to put in each phase depending on the lifetime phase of the product.

Thanks for reading! I would love to hear feedback (or claps!) and your stories on this “team splitting” topic.

If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join hundreds of readers!