Articulate YOUR definition of Product Management

Back in 2014, I was interviewing to become a PM at Google. It struck me that one of my interviewers spent 15 minutes articulating what it means to be a Google PM and how it differs from PMing in other tech companies such as Amazon and Microsoft. This discussion appeared to be crucial since I noticed, during my time at Google, nearly no misalignment on the core job and responsibilities of a PM. Everyone knew what was expected of them, from a role perspective. 

Unfortunately, this is not the case in multiple startups and companies, where different teams and departments have different understandings of the PM role and its responsibilities compared to those of other functions. This misalignment also occurs within the tech and product teams themselves. This leads to dysfunctional PM orgs, PMs joining the wrong company for them and gaps in responsibilities between teams. Instead of building the product and getting excited to solve real problems, PMs get stuck in never ending role and processes discussions, trying to answer questions such as:

• Should PMs spend more time with commercial or tech teams? 
• Should PMs define and own the product strategy? 
• Shouldn’t PMs just prioritize sales requests and implement them? 
• Who project manages a feature? Shouldn’t PMs write user stories? 

I wanted to write this post to share how I got used to articulating what product means for me, my org and my company. You can adopt the following framework to come up with your own definition and illustrate the scope and complexity of the role.  

Phases of a PMs’ role

Starting with the end, I would gradually draw the following on a white board, focusing on three phases. The goal is to illustrate and explain PM’s responsibilities across all aspects of the product lifecycle, from discovery and planning to implementation and launch phases.

Phase I: Discovery and planning  

As a PM, you will be 1) collecting feedback and insights 2) outlining user problems and how bad they are and deciding which ones to focus on 3) defining and prioritizing potential solutions and 4) scoping out the solutions, of course with the help of your engineering and design teams. The output of this phase would be a clear roadmap and/or OKRs, based on the outcomes your strive to achieve.

As part of articulating your definition of product management, here are some questions to clarify:

• Should PMs be part of the discovery phase? If not, who should drive it? Top down, from commercial teams? What is the role of UXR and design teams during discovery? 
• How should PMs collaborate with other teams in order to come up with a prioritized list of problems to be solved? 
• Should PM’s work be driven by the willingness to achieve an outcome or should PMs just facilitate the planning of incoming features? 

Phase II: Implementation / Delivery 

Once you know what you would like to implement to achieve a specific outcome, engineering teams spend the time planning the work, coding and testing in order to reach a “ready to launch” stage. 

As part of articulating your definition of product management, here are some questions to clarify:

• Should PMs be involved during the delivery process and rituals? Should they attend all engineering meetings? 
• What are PMs key responsibilities during this phase? (for eg, continuously clarify scope and take the right product decisions to unblock the engineering teams). Where do their responsibilities start and end compared to TLs, TPMs, etc.? 
• Should they project manage engineers and write user stories and tasks in Jira? 

Phase III: Launching 

Once ready to launch, different teams, led by PMs or PMMs, will look at the experimentation results, execute GTM plans and take the go/no-go decisions to launch and learn. 

As part of articulating your definition of product management, here are some questions to clarify:

• Can PMs delay a launch if they think the potential outcome will not be achieved? 
• Who is responsible for bringing all teams together to launch a feature, sell it, inform the customer, etc.? 
• Should PMs go back into the discovery phase to iterate on that launch? Or should they just wait for sales teams to tell them what to do?

Effort vs Lifecycle

After clearly defining the PM’s role throughout each of these three phases, I recommend you draw the effort (or time spent) you expect your PMs to provide during each of these phases. The following graphs are two real-life examples from two companies who look at PMing differently:

1. Example 1: PMs spend most of their time in the discovery and planning phase. They then noticeably reduce their involvement in the implementation phase, in order to take on more work at the discovery and planning phase. During implementation, PMs remain present to answer scoping questions, help with tradeoffs, etc. Finally, PMs become more involved during the launch phase, making sure features are launched, landed and adopted → This is closer to what Google PMs do. 
2. Example 2:  PMs are lightly involved during discovery and planning phase, mostly spending time collecting requirements from stakeholders. They then spend most of their time working with the engineers, writing tickets (eg. user stories), and then become less involved in the launch phase, where engineers just ship or marketing takes over → This is closer to what Product Owners do. 

The way that effort is distributed across the product lifecycle will vary depending on the company, the product, and the team. This is why it is crucial for you to define expectations and where/how you expect PMs to spend their efforts. 

Key takeaways

Of course, your definition of product management will also be influenced by the product, people’s skills, and previous ways of working at your company. Try your best to create the right internal setup that will deliver delightful customer experiences and will solve real problems. Being upfront about your definition of product management during interviews, will help keep internal alignment about the role, reduce churn and create a company focused on improving the product rather than stuck in role and process discussions.