We don't all have the luxury of being in a small startup or a large company where we get to start brand new products straight from ideation.
In fact, most of us here at ProductManagerJobs.net, have been in Product Manager roles were 90% of the time it's managing an existing product where someone else handed off. Or sometimes there wasn't someone in that role or that role was filled by someone else.
The fact is, and if you haven't come to realization now, you'll figure out that a Product Manager role is NOT vital. In fact, product teams especially when it's new and running lean, borrows or seconds a "product owner" from some other discipline and typically someone who is the closest to the users or customers.
It's tough going, it's complicate and messy and we have all experienced not such great experience when taking on a new role. So this is the definition guide to how to start a new product manager job on a existing product run smoothly and efficiently (as much as possible).
Here are some pitfalls and also some best practices to overcome these challenges.
It'll be great if you have a manager or someone in the incoming role. This is the first group to talk to because they know what's going on and can do their work transfer to you.
The objective is to have them.
In our experience though, it's not necessarily helpful and these people don't necessarily know. They may not be able to tell you everything because they are so used to working in Agile where things are a bit more transitory.
But the first step is to identify if there is someone on this team that is like this.
Document, document and document everyone. It'll be preferable if that person's email can remain open to you so you have it archived and you can read it. Most employers would do that for some time and all the emails should be work-product so is owned by the company.
Set up a few meetings to discuss with them after they've prepared their transition email. Not everyone is so detailed oriented and chances are that if they are on their way out, they probably don't care so much, so it's on you to extract as much context as possible -- what's not on paper.
It comes as no surprise that excellent listening is a skill that every product manager should possess. There may be a lot of stuff going on when you first are thrusted into this product team, but take the time doing 1-on-1s whenever possible to get to know each individual.
Individuals make up teams and in a one-on-one setting, getting to know each of them, understand the dynamics of the team from each individual's perspective is so important.
Of course, if you have the luxury of being a fly-on-the-wall for the first Sprint with some weeks of overlap with the outgoing Product Manager, then that'll be even better to observe the team dynamics and just absorb the knowledge of the process of that team. Perhaps attending a Sprint Retrospective or Sprint Retro would be beneficial.
No two teams are alike, even if they were to share a subset of resources. The product itself is different, the timelines are different, even the introduction or reduction of one individual can make the team dynamic be unrecognizable. There is no downside to listening. What is it that people say -- you have two ears and one mouth so do it that rough portion. Besides, there are not going to a lack of opportunities where you speak and your team listens so do them a favor and listen to them first.
This may not be possible everyone, but if you work in a large enough organization you may be lucky to have an Architect to walk you through the whole stack that your product sits on. Sometimes they may have some Architecture Diagrams prepared and looking through that and understand the ins and outs will catapult you right into the product.
There's not other easy way of learning about the product however. Of course this all depends on the product itself and the team and the customers and the frequency in which you work with them, but that's it -- the more you immerse yourself in the day-to-day things you can learn more.
Try your hand at QA! Work with QA for a few days and help them test things. I find that having a mission or a goal is better than someone handing you a device and say, "click around the app". It's hard to think as deeply about why people made the decisions they made when you're aimless in using an app.
One of the key pitfalls that I see other Product or virtually anyone joining the team that's new is that there are so many questions of why decisions were made the way they were.
Personally, and this my own opinion only, I don't really care for the most part. If I know the Product Team is good, meticulous and thorough, I don't tend to go back and revisit why certain things were certain ways. People made the best decisions at the time with the information that they had or they just had to make a hard choice.
I have found though that when new members join the team filing someone's role that left, they come in with a strong opinion or mental model of how things should be a certain way without first understanding the wisdom of some of the existing decisions.
That's what I think separates experienced Product Managers from less experience product managers who are thrusted into a new product role, is having an acute awareness of your personal opinion about something and balancing that with looking forwards the future work. Sometimes the details can get you bogged down.
Building product is what we all love to do and that's why we are attracted to this career path, no matter which diverse careers we've had before. For those that are new product managers AND also new to working a product team setting, especially in a matrix organization, you need to learn the ropes.
All good to great product managers know that the product is just, for lack of a better word, a product of people making it. The people on the core solutions product team made up of developers, designers, scrum masters, but there are also ancillary stakeholders including, Business Sponsors, other technology teams in your stack, marketing, sales, Executives, customers, users, clients, production support, help-desk etc. There's many people to keep tabs on and there are many people to ensure they are informed, and that you are informed about their activities too should they impact your product.
Emails are great to an extent, conference calls works too, but nothing beats a conversation in person. Even as we have more remote jobs in history and people are doing it from their homes or cafes around the world, I still haven't found a better way to communicate and for the communication to be more binding than in person, face-to-face.
Take the opportunity whenever you can to have coffee with one of these individuals.
Not every product role is in the ideation, seed or even growth phase. Sometimes, it's well past the S-curve or it's a product that's stable, steady in usage and it's just business as usual. The thing to keep in mind is that as products mature, there may be different skill sets that's required of product managers, and may require different people to do that same job.
Do you currently work on any "mature" products? Do you have any stories to share regarding your transition to a product that you didn't launch, build the MVP? Welcome your thoughts in the comments below and we'll include this in the post!