Taking Over an Existing Product: Product Management Lessons Learned
Congratulations! You’re a Product Manager or Product Owner or both, and you have a new opportunity to add an existing product to your arsenal. One catalyst for this scenario is when a colleague leaves, or changes positions. Someone has to take over her products or features. Until they hire a replacement, it’s your responsibility.
Another impetus is when you permanently inherit some of their products or features due to an organizational or strategic change in hierarchy. Another trigger is a new job- where you are taking over a product from somebody else. Maternity/paternity leave is another reason this could occur. Or, you have switched positions, so you move on from your other responsibilities. Whatever the reason for the situation you find yourself in, what’s the best way forward?
A whiteboard and a quiet room: brainstorming
Before you get cluttered with all the information you’re about to imbibe, let yourself dream. Do a brainstorm with yourself. Write up questions, assumptions, directions for a vision. Get it all out there on a whiteboard or on paper. Make a mess with your thoughts, allow yourself to free associate. Not sure where to start? Borrow from Tony Buzan’s mind map. Jot down assumptions on the side. Make a list of questions.
When you’re done, take a picture of the whiteboard, or store that paper for later. After Discovery, you will re-visit and see what has shifted. Hopefully, you will have answers to some of your questions. You can reject some of your ideas. You will have a clearer direction.
Handover from the current product manager
Ask the questions
You have the responsibility to ask the questions, to get the knowledge. Do not expect to be spoon-fed. Remember, it’s your product now, and the product manager who is handing it over may want to move on as fast as possible. Alas, her next challenge awaits her too and she is eager to embark on discovery of her own.
Capture their vision
If the outgoing product manager has a roadmap and vision, great. If they don’t bring it up, you can ignite the flame one last time. Product managers who are leaving or changing positions may have already been broken down by their product, in the sense that they developed minor myopia. At first, they had more passion, a bolder vision.
The weight of life — developers, customers, markets, organizational politics— whatever, has taken the edge off of their initial spark. But you can learn a lot from re-igniting it. Give them a magic wand for a moment, and ask them to dream, to share the ideal situation. You may connect to it or not, but at least it will take you — and the conversation with them — to a far more expansive mental space.
Get the back story
Why is this feature the way it is? Are there previous decisions that we are captive to upholding? Why was decision X made, and decision Y? Often there are ‘skeletons’ in the form of outdated constraints, or setbacks that we can now overcome.
Get written resources
Ask for documents sent now. Let there be awkward silence for a moment when you ask what documents, emails, correspondence, PRDs, epics, whatever, you should look at. Often there are always some documents, even if they are old and obsolete. Though not interesting to current product managers, they can still give you a sense of where the product was at some point, and how it was thought about then.
Key Performance Indicators (KPIs)
What are the product KPIs? If there are none, why not? What was the product manager considering? How did they measure product success?
Join active conversations
Get linked into active email chains, or tickets. If there are active open current items, have the product manager you’re taking over for add you to the conversations, so others know you’re involved. I find this valuable even if you don’t know what you’re doing yet. Your colleagues will understand that you need a grace period before you can offer value, and you will learn about the product while you are ‘listening in’ on the conversations.
Ask who else to talk to
Every product has a community around it. Find the members of the community around the product you’re taking over. Engage with them. Of course your ownership will influence who is part of the community.
Don’t be judgmental or critical
Whatever you do, don’t be a hater. The product manager whose product you are taking over had struggles you don’t yet understand. Remember, it was once their baby. They poured hours of sweat and tears into it. So even if you see the product differently from its previous product manager — and it is natural that you will- be gentle about it.
You don’t want to march in and aggressively overthrow everything about the product. Even if you do want to change everything about it, you can accomplish that in a sensitive yet firm way.
Internal Discovery
Your organization has a lot of knowledge about the current product. You need to get up to speed, fast. How?
Documents: PRDs, MRDs, HLDs, LLDs, SLAs, YAMLs, Release Notes, Press Releases, Articles
Find the documents that have been written about the products you’re inheriting. The acronyms above may or may not be relevant to the ones used in your organization.
Software project management tickets
Your project management software (like JIRA) has tickets about the product. Beyond what you may have been informed about in the handover from your product manager, search keywords related to your product. You will find support tickets, bugs. You may find some backlog items. Some items that are related. Dependencies. This is an invaluable source of information. The comments, too.
‘Listening tour’: Interview relevant non-stakeholders
Multiple people in various roles and positions have more experience with this product than you do. Developers. Designers. Technical Writers. QA. They are not direct customers or users, but they have been working on the product, toiling for it. So have a lot of insight. Ask them about it.
Not sure how to frame your activity? Tell everyone you’re embarking on a listening tour. Ask stakeholders to share their views, too. Worst case — you do not agree. Best- you have new insights and ideas.
Participate in customer calls
Even if you don’t know anything about the product yet, be there on calls. This is how you learn. Savor those angry complaint calls; you’ll learn a ton about pain points.
Data
Does the product have usage data? Is there a tool? Get the login credentials, and play with the data. More than play — master it, if you want to make data-driven product decisions. If there’s a Product Analyst, talk to her and get her feedback.
Set expectations with stakeholders
You have an opportunity to re-ignite relationships with stakeholders related to the product. Set up conversations to hear their opinions about the product’s current status, and invite them to share their views on challenges, and even how they see the product moving forward.
Ask what is the best way to work with them, and what they expect from you. Tell them how you like to work. Ask the best way to communicate with them — calls, meetings, emails, or do they prefer not to be bothered unless something critical comes up? Instead of learning this the hard and laborious way, put it on the table and work it out together.
Understand the market
If the market context is new to you, delve in deep. Read industry reports. Follow the competition. Attend conferences. Subscribe to newsletters. All this is ‘bread and butter’ of product managers, and should be obvious. But what’s not trivial is carving out time to allow yourself to learn.
Once it’s yours, take full ownership
True E2E product management means taking responsibility. In conversations with other stakeholders — developers, sales, customers, customer delivery, technical writers- you need to own even that which you inherited. If you want to cry and complain and moan about all the crummy aspects of the product you inherited that were not your fault, you can rant in your private journal or talk to yourself alone in a dark room. But from the moment the product is yours — it’s yours, even its past.
With all its glorious successes, and all its scars and weaknesses. Do not succumb to the temptation to let slip, in passing, some justification of the product— yea, that was before I took ownership. That would be petty. Taking over a product can be daunting, and a steep learning curve. But after the initial shock, you will be up and running faster than you believed possible.
About this series
This article which is part of a series on product management based on my experiences.
About the author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and agile B2B2C companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.
