Making the move into product management is exciting. It’s a rewarding job that allows you to work across multiple teams as you build creative solutions to customer problems. However, starting out can be very overwhelming. Some companies have formalized onboarding processes to help new product managers learn the ropes. But the way that a product org works can vary widely from one company to another, and even product teams in the same organization can have very different approaches.
Because there is no cheat sheet that can teach you everything you need to know, here are the questions I wish I had asked when I first started out. I believe this will help you establish a basic understanding of your product, how your team works, their expectations for you (as their new PM), and where to jump in first.
What is your product?
It’s important to remember that there are two angles to the “what does your product do?” discussion. You need to know what your product helps a user accomplish in its current form. But you also have to consider what your customers NEED your product to help them accomplish. Often, they are not the same. And the difference is where the opportunity to improve and innovate lies.
Part of unpacking what your product is involves taking a hard look at the numbers. You’ll need to review usage trends for your product. If you can, go back a few years. Pay attention to how the user base has changed over time. What are milestones along the way? Was there a new feature that drove usage? A marketing change that brought on a new customer persona? This type of historical context is critical to moving forward.
You’ll also want to schedule a debrief with sales. Ask about your pipeline, renewal rate, and churn rate. Understand what sales thinks are the primary decision drivers for each area of your product. Then ask product leadership what success looks like for your product. You can’t be successful if you don’t know what you are measured by.
What’s on your roadmap?
When I took over my first product as a PM, I looked at the existing roadmap and balked. I didn’t agree with what had been prioritized. I immediately started thinking about all the things we could build instead. Thankfully, the previous PM was my boss (and also a very patient person). He let me go through the process of talking to customers, reviewing data, and meeting with stakeholders in sales and customer success, before ultimately arriving at a very similar conclusion about what we should build next. That’s not to say that you shouldn’t question the inherited roadmap. However, you should do so only after you’ve done the appropriate research. This means talking to colleagues and customers who can provide first-hand knowledge of the market and what your users actually need.
Some questions you might address include:
- What items are committed on the roadmap?
- Why are they on the roadmap? What problems do they solve?
- What did the team recently release?
- Is it performing as expected?
- How did the previous PM prioritize features for the roadmap?
What is the process for a release?
Let me start by saying this: There will never be enough communication for everyone to be happy when it comes to a product release. I just don’t believe it’s possible. I do believe, however, that you can establish processes that satisfy your most important internal collaborators and set those teammates up for success.
How do you do that? You communicate with other departments regularly and with purpose. Make sure you have recurring meetings set up with internal stakeholders to discuss upcoming releases. In my experience, the best way to accomplish this is to have one or two people from support, customer success, sales, and sales engineering in a group meeting to review the impact a new product or feature might have.
You’ll also want to quickly establish what you are responsible for when it comes to documentation for a new release. I’ve been on teams where I was writing help documents and on teams where we had a docs org and all I had to do was a product walkthrough with the person actually writing up support materials.
Other questions to ask might be:
- Are there set meetings when product shares the roadmap with other teams and discusses upcoming releases?
- Is product responsible for helping generate support documentation ahead of a release?
- Is product responsible for helping educate customer success reps ahead of a release?
- Is product responsible for helping educate sales reps ahead of a release?
How does your engineering lead/manager like to work and what do they expect of you?
I can’t overstate how important it is to learn the habits and preferences of your engineering manager/engineering lead. Ask what they liked and disliked about their previous PM, and get them talking about what they expect from you on a daily, weekly, and monthly basis. Similarly, they should be invested in learning how you work best and what you need to do your job well. Will your work styles always match? Probably not. That doesn’t mean you can’t have a great relationship with open lines of communication.
How does your engineering team like to work and what do they expect of you?
I have worked on teams where I had a close relationship with individual engineers and on teams where I instead relied more heavily on the engineering lead to manage those relationships. In either scenario, you and the product will benefit from taking the time to understand their work and communication preferences and how they expect to interact with the PM.
One question I didn’t think to ask but have since learned can have a big impact on productivity and team morale is how and when should you ask more general questions as you get up to speed. When you are a new PM, you are going to have a lot of questions about how things work and why. Sending a Slack message to an engineer every time a question pops into your head can be distracting and frustrating for them. It can also lead to confusion about prioritization. Should they stop what they are doing and answer your question, or should they stay heads down on the current sprint? Work with your team to identify a process so that there is time for both heads-down coding and time for exploration, questions, and what-ifs.
What are the details/processes surrounding sprints, bugs, and backlogs?
You may not think that such basic questions like how long are your sprints? What is the current process for bugs? And what was the past PM responsible for in a sprint planning meeting? are important to talk through before getting started. However, not explicitly having conversations like this can lead to a lot of pain and many hours of lost work.
The best thing you can do as a new PM is to establish open lines of communication and be respectful about the processes and product decisions that have come before you. You’ll get your chance to make an impact, but making the effort to develop a historical understanding of your team and your product will go a long way toward building trust with your new team.
