Your first 30 days as a product manager – ramping up on a team

Whether you’re transitioning roles within an existing team or switching teams, here are a few crucial things to do in your first 30 days as a product manager.

As a child, I heard a song by Guatemalan singer Ricardo Arjona which said, “aquí no es bueno el que ayuda, sino el que no [molesta], acuérdese.” This translates to “here the good are not those who help, but those who don’t [bother], remember that.”

Having completed my first three months as a PM at Google, this is good advice to keep in mind at the beginning of a new job. Instead of having a grandiose plan to make a big difference and impact, start by learning as much as you can without disturbing others.

Communicate what others should expect in your learning phase

As a new PM to an existing product, your focus must be on learning. Even when there is an improvement that seems evident to you, a product idea or process tweak, abstain from contributing too hastily. Consider that:

  • You lack context. Your new colleagues have been working on the product area for months, maybe years. They have tried many ideas that failed, talked to many customers, and learned a lot in the process. Try to gain that context quickly.
  • You have zero reputation. You can only go far if your team cares about what you have to say. You can quickly tarnish your reputation if you babble ideas or decisions before thoughtfully thinking through problems and considering all aspects of a problem.

So, focus on learning. How do you get started? Instead of trying to revolutionize the team’s dynamic, I suggest that you pick a small project or initiative and use that to prove yourself.

Pick up a few small initiatives

Dive in and pick up a small, non-critical project to work on while your team continues executing on their priorities. It doesn’t matter how uninspiring the project might be; what matters is that it is an initiative with the various phases that a typical project will go through – writing a PRD, going through design iterations, executing, and shipping a project.

Your goal is not to amaze anyone, but rather to maximize learning by getting through a full cycle of contribution. By doing this, you will learn many of the quirks of working with your new team and figure out tactical ways to be more productive.

  • What level of detail works well for your team in your PRDs?
  • Who should you consult in the process of designing a solution?
  • How do you communicate cross-team dependencies or impact on other teams?
  • How do you break down your requirements into tactical work items that your team can execute? Where do you file work tickets or bugs?
  • Will you have help from other teams (design, eng, user research, etc.)? If so, how much?
  • Do you need to get approvals or reviews by other teams? Which ones?
  • How often should you get your manager’s input while working through an initiative?

Try to maximize the number of times you go through this cycle in your first few months by picking many small initiatives and owning them end to end. It will help you fill the gaps in your know-how of working with your team, and will be of great help when you pick up more significant projects.

As you go through the initiatives, ask why things are the way they are but don’t try to change processes yet. What you’re looking for is opportunities to learn what’s useful and to tune your habits to make a more significant contribution within your team’s established processes.

Tweak your habits to match your team’s workflow.

Most processes need to be just good enough to allow the team to work effectively. Constantly tweaking processes to improve them is often more distracting than it is worth. So, focus on matching your team’s process and work within them for the first few months, before you try to bring new workflows or tools for the team to use.

I had a new manager once tell me in their first week at the job, “we must get rid of these spreadsheets” referring to the team’s use of spreadsheets to manage the feature backlog. A month later, he realized it was a simple and effective way to manage the backlog and backtracked on the statement.

Get to know your team

You will need a lot of help over the coming months and years from the people you are meeting now. Meet them as people. Try to learn about their personalities, what they are interested in, what they like, and what they dislike about their job. Knowing your teammates’ likes and dislikes will help you when planning work for your team, something PMs do regularly throughout the year.

I like to acknowledge upfront my ignorance when I meed new team members, but offer to help as possible. “I don’t know anything right now, but if there’s something that you think I can be helpful on, just let me know.” It’s a simple statement recognizing that you are unlikely to be helpful but still showing your willingness to step up and assist.

You are not here to issue commands or speak of visions for the team to execute. You’re here to collaborate with your team to come up with a direction that will make the product excellent. You should be very involved and willing to help your team’s life less complicated. Make it clear to them that you’re here to do that.

Ask your coworkers for braindumps

A previous manager and I called our knowledge transfer sessions braindumps; these were sessions where she would share a lot of information and context. I’d soak all this information up and ask clarifying questions. Many of these sessions would start with a particular topic or area, but as we dug into an issue, we’d make a note of other issues that came up, and we needed to discuss further. These sessions covered a lot of ground, such as:

  • How does the product work?
  • How does the product initiative fit within the overall product and company strategy?
  • What are the known issues with a given feature?
  • Why hasn’t a critical issue been fixed?
  • What are known feature requests or solutions that the team hasn’t implemented, and why?
  • Why do these two parts of the product feel so disjointed?
  • What did the team try to do and succeeded? How did they start down that path?
  • Who are the players involved in making your product area a success?

Keep these sessions flexible. They are best in person, but often we’d do these asynchronously by using a Google Doc. My manager would type up a bunch of thoughts about an area or topic I needed context around. We’d then discuss.

During these braindump discussions, you will have many ideas, thoughts, and potential solutions. Don’t jump into looking for answers. Remain focused on surfacing issues and tidbits of knowledge. What you’re after is building a foundation of knowledge around the team and product. You must take the time to organize all this new information in a way that’s useful to you. As you do, ask why until you’ve hit on a point that is easily understandable and actionable.

Your coworkers will gravitate towards topics that have been important in the past 6-12 months since they are top of mind. This will make your learning process more focused than trying to read every document sent your way.

Observe your users

Get first-hand exposure to your users. You can learn a lot from talking to your coworkers. But, ultimately, your goal is to build a product for your users. Deeply empathize with those users. Observe them. Talk to them. Find ways to watch them in action. Listen in on support or sales calls. Read support tickets. The more you can identify with your users and understand their real goals and needs, the better of a product that you’ll be able to build.

What to do in your first 30 days as a product manager

Your first few months as a PM can be quite unsettling. You are brand new, want to contribute, may have a lot of relevant experience to bring to the table, yet have little to no knowledge or context about your new team and product area. There are significant gaps in your understanding that will prevent you from making a significant contribution.

Focus on learning by picking up many small initiatives, assimilating your team’s processes and tools, asking your co-workers for braindumps, digging deep into the why behind what you learn, and observing your users. After a few weeks of consistently doing this, you’ll be ready to take on more significant initiatives and will be much more effective at helping your team.

Last Updated on August 22, 2020 by Omar Eduardo

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.