As a new Product Manager, you’ll be inundated with training videos and you’ll be anxious to jump right into a project to release a feature that members of your platform will use.  But let’s pause…and take a deep breath. Take your finger off the feature trigger.  Before you can begin building, you must understand the Three P’s of Principled Product Role Preparation (say that three times fast). No, seriously. Do it and then continue reading the article……… Done? Cool.

What are the Three P’s, you ask?  They are:

1. People – Who will I be working with?
2. Process – How does sh*t get done?
3. Projects – What will I be working on?

I know you’ll have a ton of other questions like “Where are the free snacks?” and “Can I really wear shorts to work?”  Yes those questions are important too, but not as important as the ones I just listed.

Getting answers to the Three P’s will help you onboard successfully so your transition into the PM role is as smooth as possible:

Who will you be working with?

In the article “The Product Squad” I detail a few of the various experts who will be part of your product development team.  This list will not be standard at all companies you work for and the scope of each expert may expand or shrink based on the company as well. Regardless, these are the people/roles you should expect to interact with.  Take time to meet with your manager to confirm all of the people that PMs interface with to get the most accurate list.  Also note that depending on the complexity or moment in which you jumped on the project, you may interface with more or less of the people on that list you obtain.

Side note: I advise literally trying to set up a meeting with as many people on your team as humanly possible.  This may seem impossible given the sheer amount of designers or engineers on your team, but try to!  When you eventually work with them, you will have already established a rapport which will make working with each other so much easier.  I tried this.  I think I got to around 15 engineers and then realized it wasn’t sustainable because unfortunately, I actually had to work and not just meet people **shrug**.

Knowing who you will be working with is key to uncovering the answer to the next question…

How does sh*t get done?

At this point you know who you will be working with.  Now you should ask, how you will be working with them (in other words “how does sh*t get done around these parts?”).  What I mean is, what are all of the processes involved in the development of a product.  Within each area of expertise, there will be processes that each expert has to go through before their work can be finalized.

For example, your engineering team may have:

1. A working team review of technical/architectural changes needed. By “working team”, I mean the team of engineers who will directly be writing code to create your feature.
2. A review of the working team’s expected changes by another engineering team as a “fail safe” to double check that there will be no major negative global impact stemming from code changes.
3. During the actual development of the feature, there should be a review of each change to ensure the implementation was completed as expected with no deviations to the original plan.  This review also ensures there will be no adverse changes to the current architecture.  

Your design team may have a similar structure:

1. A working team review of the design to ensure the feature will be understood by your members and ensures all product requirements are met.
2. A design review committee to ensure design implementation does not deviate from the company standard.  Your team may get creative with the design to make your product requirements fit within the current design framework.  This review committee may point out if an aspect of your design does not meet UX design standards.

Now the fun stuff…

What will you be working on?

Once you’ve established who you will be working with and how you will be working with them, you can actually get to work!  As a new PM, there’s a good chance your first project will already have a problem statement and the solution may be semi-defined. Despite this, still internally pretend that you don’t know why the problem exists.  This will require you to ask questions to deep dive into why the problem and solution exist so you empathize more with your target user. The more empathy you have for your user, the more you’ll understand their needs and desires.  Who knows…you may come up with a better solution then what was thought of already!