Product managers are often viewed as strategic leaders of their products. They’re expected to take the reigns of their product and steer both their product and product team in the right direction. As such, they have a great deal of power over product strategy and are authorized to make product roadmap decisions as they see fit. But, as they say, “with great power comes great responsibility,” and that’s true whether you’ve managed your product from the very beginning or you’ve stepped in to take over a product starting where someone else left off.
As the strategic leader of an inherited product, you cannot be held responsible for the product’s past, but you are responsible for the product now and into the future, regardless of what kind of baggage it comes with. As soon as you step in to take over a product, you’ve accepted it as it is. As such, investors and executives will not be thrilled if you start throwing around the I-word: inherited. Don’t waste your time pointing fingers at someone who is no longer in charge—you’re the leader now, so start acting like it. Here are some tips for product managers taking on inherited products and some advice on how to tackle specific issues you may inherit.
Tips for Product Managers who inherit products
Anticipate problems
Rarely will you inherit a perfect product, so don’t expect to do so. Anticipate the possible problems your product may have before your first day on the job, but also expect the unexpected. Don’t panic if and when you uncover something surprising. The past is the past and now it’s only the future that matters. In anticipation of potential challenges, plan to reserve a chunk of time to take an objective look at potential problems at the very beginning.
You are not a firefighter
It’s easy to see every problem as a burning flame that needs to be extinguished immediately, but your job is not to play firefighter. You cannot expect to tackle everything at the same time. Once you’ve spent some time assessing where shortcomings exist, you’ll need to step back and assess everything as a whole before attempting to tackle it all at once. In many cases, what seems like a major issue is merely a small annoyance, all other things considered.
Tweet This:
“It’s easy to see every problem as a burning flame that needs to be extinguished immediately, but your job is not to play firefighter.”
DON’T point fingers
Complaining and playing the blame game doesn’t solve problems. In fact, it can have serious implications on your credibility as a product leader. You bought the ticket when you signed on for the job, now take the ride. A true leader doesn’t make excuses—they make changes. So stop talking about what you’ve inherited and instead start talking about your plan to fix it.
DO come up with a plan & share it
If you truly want to be a product leader, digest these tips, use them together, and take initiative to face the problems head on. Rather than waiting for executives and investors to bring up issues, be proactive in identifying them and drafting up a plan to take care of them. Share the challenges you’ve identified and your plan for addressing them with the executive team and investors before they have the chance to come up in future meetings. Get their buy-in and feedback on your plan and how it may interfere with any existing plans. If done right, you can also give executives and investors a chance to point out other existing problems that may not have been on your radar before. Otherwise, your investors will say no to your ideas.
Common challenges with inherited products (and how to handle them)
Inherited technical debt
If you are majorly in debt, you need to pay off your debts before taking on any new ones, otherwise you may find yourself later declaring bankruptcy. A small amount of technical debt is inevitable in every product. What counts here is knowing where it is, how it affects the core product, and what needs to be fixed. You must have an understanding of where inefficiencies and technical debt lives within your product before green-lighting any further development. No new major features, functionalities, or integrations until you fully understand how new development will contribute to existing technical debt.
To understand technical debt, talk to support and engineering. Support should be able to share data with you regarding bug reports and performance problems. They have great insight into where your product’s technical debt most affects your customers. Engineering can also help you pinpoint problems, as long as you are careful about your approach. You need engineering to trust you and see that you are not going to blame them for problems of the past. No matter how large the problem, do NOT point fingers or get upset. Instead, work with engineering to manufacture a plan for tackling the problem together. After all, you want the engineering team to see you as someone they can easily approach to discuss future implications of new developments, right?
Inherited product roadmap
Would you drive your car off a cliff if the outdated map you were using said that was the way to go? Hopefully not. You are now in charge of the product roadmap, which means you’ll be held accountable for any poor navigation decisions, even if you weren’t the one who made them.
Start by getting a thorough understanding of the existing product roadmap. Which initiatives are planned? Why are they planned? Which objectives are each of the initiatives tied to? And finally, what’s in the backlog and why? Familiarize yourself as best you can before determining whether adjustments need to be made. Ask yourself if the current roadmap is guiding your product in the most effective way possible toward both current objectives and your organization’s product vision. If you find reason to doubt, make changes.
If the state of the product roadmap is truly dire and many changes need to be made, prepare to play politician a bit, especially if key stakeholders and other internal teams have already bought into the existing plans. You’ll need to get them excited about the new plans, and to do so you need to show them why your new plan is more effective than the previous one. The last thing you want is to seem like you’re just making changes for the sake of making changes. For best results, bring as much data as you can into the conversation about why you’ve decided to make changes.
Inherited team members
Sometimes inheriting a product means inheriting personnel as well. Most of the time things are fine after a brief “adjustment” period. But occasionally things get a bit…messy. When you take over a product AND a product team, be prepared for another level of complexity.
Occasionally, you’ll find that the status quo is not the way to go. Perhaps your team resources are not being allocated properly. Or perhaps you’re not leveraging your team’s skills and experience in the most effective way. Or maybe roles and responsibilities are simply not properly defined. Either way, tread lightly. Whether you’re changing team structure or redefining the scope of certain roles, you need to get your team on board and excited about the changes. A good way to do this is to focus on getting to know your team and focusing on how the changes align with their strengths and support their advancement in the field.
Unfortunately, in some cases you’ll need to let people go. Whether it’s because their role has become redundant, their work is repeatedly not up to par with expectations, or simply due to unwillingness to adapt, sometimes cutting ties is the only remaining option you have. At the end of the day, you need all the parts of your product machine to be working together effectively. Make adjustments as you see fit, but if things are working as they are, don’t feel pressured to change things.
Inherited processes & procedures
“We’ve always done it that way” is not an excuse for inefficient, outdated, or otherwise ineffective processes. Oftentimes your product is only as good as the procedures used to develop it, and as such you want to be using the most effective methods possible.
When you first step in, invest some time in finding out how things were done in the past. Talk to your team, key stakeholders, and other internal teams. Be empathetic and listen more than you speak as you let them tell you what they see as strengths and weaknesses of the status quo. And if you can get your hands on them, notes from previous product launch retrospectives can be incredibly useful.
Come armed with your own ideas about how things can be improved, but be flexible and work alongside your team to figure out small areas you can experiment with changing. Be prepared to fail. Your first attempts at improving or updating outdated procedures may not always yield perfect results. As long as you learn, don’t chalk a failure up as a total loss. Finally, do not attempt to change everything all at once; focus on the biggest problems first and go from there.
Lack of documentation
How will you move forward if you don’t know what happened before? Taking over a product with patchy or simply non-existent documentation can be quite frustrating for both you as the product manager and the engineering team. Sadly, if the importance of thorough documentation is not emphasized or seen by the engineering team from the very beginning, it’s a task that can get swept under the rug.
In some severe cases, filling gaps in documentation can end up being a massive project that requires a significant amount of valuable engineering resources. Proceed with caution—work with engineering and support to determine which areas are suffering most due to lack of documentation and tackle those first before patching up the remaining holes.
It is important for you are a product manager to do everything in your power to ensure the problem does not get worse. Make it known that from here on out: nothing gets shipped without having the necessary documentation in a centralized, easy-to-access place. You may need to work with engineering and support to establish a system for writing and storing documentation.
How Steve Jobs conquered a slew of inherited issues
When Steve Jobs returned to Apple in 1997, the company’s outlook was not great; sales were plummeting and Apple was not acquiring enough market share to be a viable competitor of Microsoft. There were several reasons for Apple’s not-so-shiny outlook a the time, but Jobs was able to identify and solve the biggest issue to right the ship and save the company from disaster.
How exactly did he knock the company out of its downward spiral and put it back on track to become one of the most innovative, successful tech companies of all time? He didn’t waste time complaining about the mess he had “inherited.” Instead, he quickly observed that the company’s projects were not in total alignment with the company’s vision. Jobs’s first task was to help restore order and focus in the organization. When he stepped back in he discovered that Apple was producing far too many versions of the same product, and there was no simple way to differentiate products to make buyer decisions easier. As such, he took it upon himself to narrow the sprawling scope of Apple’s line of products. He reduced Apple’s product offerings to a line of just 4 products, and as a result was able to restore the company’s focus on innovation.
And it is with an example like this in mind that product managers should remember—inheriting a product can come with challenges, but it also comes with significant opportunity. After all, Apple’s market cap today is $913 billion.
