A product management role varies from place to place, but here are three reasons why we’re seeing so many differences.

As with all jobs, core responsibilities may vary at the team level, company level, or even industry level. Product management is no different, but many can agree that field will always include the following responsibilities:

• Defining the strategy and general direction of a product/feature, and how that aligns with organizational direction, leadership, business impact, and goals for success.
• Analyze data and customer/user feedback to improve product current functions and capabilities.
• Evangelize the product/feature across various platforms both internally and externally.
• Collaborate with engineering, design, and other teams to strategize and execute projects that achieve product/business goals or KPIs.

But a noticeable shift in how we perceive product management is now happening — new variations of the role are emerging to a wider degree of acceptance. Here are 3 reasons why we’re seeing so much variance.

1. Some roles are more metrics-driven than others

This may seem obvious at first; all jobs leverage metrics to varying degrees. Some are cut-throat when it comes to using metrics whenever possible, while others care more about qualitative improvements for their products.

For many software products, usually both qualitative and quantitative metrics are used. Many teams use the latter more than the former, and some do vice-versa. How that team decides which is more important is rooted in their product culture, and that’s where the PM sits.

Using metrics more or not all depends on the business priority. If you’re a PM in the B2B space, then you may prioritize the business partnership (helping your client maximize revenue) more than the user experience. Business metrics would thus be used as a KPI more than product quality. Conversely, some B2C products care more about user experiences, and they won’t necessarily use quantitative metrics as much.

This ultimately affects the PM role a lot — way more than people realize. How much you value quantitative metrics will decide which frameworks you use, how you prioritize features, how you perform discovery work, and how you determine success. For example, as a PM at Microsoft Bing, we’re incredibly metrics-driven, so feature ideas that don’t have quantitative ROIs available are usually on the back-burner. This improves our business and product performance, but what about usability and quality? What about the whole end-to-end user experience? One example of an amazing product that I look up to is Figma, an amazing designing and and prototyping platform that almost everyone loves. Their CPO, Yuhki Yamashita — explicitly expresses his distaste for being 100% metric-driven, because this may hinder product creativity, and ultimately affect the user experience.

2. Technical PMs can be wrapped up in execution

Most PMs have a technical background, but the reason why they switched to PM isn’t only to dodge the coding life; it’s to round themselves out with more business experience when building products. However, they could easily find themselves back in technical execution rather than spend time designing the next product strategy.

When product execution begins, PMs find themselves interested in how the technology works, especially for those who have prior knowledge or experience. They’ll have their say during daily scrums and even pick their engineering managers’ brains about it. But that’s not all — keeping track of this project progress will then sweep over much of their time, turning them into project managers rather than product managers.

Some teams, especially if the product is a software service or an API, are deeply technical to begin with. Their PM could be more of a “Technical Program Manager” rather than a product manager. Other teams are hard-headed on deadlines, so a PM has to chase around their team to ensure work items are “on-track to being done.” Soon, you’ll hear “can we get this done by the end of Q1?” and “why will this take 4 months to finish?”

Not all PMs need to ask these questions. Some focus on product strategy and discovery, and others on the execution: choosing how it gets built and tracking deadlines. Thus, this is another source of variance in the role.

3. Some roles have a KR culture, while others don’t

If you’ve ever been a PM, there’s a chance you’ve dealt with the universal “OKR” system. The OKR system, standing for “Objectives” and “Key Results,” is a roadmap framework that helps teams construct a long-term vision for a product, and then break down the key steps that need to be achieved to finish said product.

First is the “O” — the objective of the team. This usually captures what the theme, end direction, or goal needs to be for the product. For example:

“Achieve universal love from our active users across all 3 OS for our product, without losing YoY revenue growth.”

Then, the “KR” is the child that captures a “key result” that directly relates to the parent objective. It needs to be achieved via actual development or business work on the product. For example:

“Ensure the new stories feature is used by >20% of all daily active users across at least 5 markets,” or “Develop a new API for customers without access to the dashboard with 95% request/call rates without failure.”

You can have more child KRs that fall under those parent KRs which focus more on the engineering work; you get the idea. This also relates back to my first point regarding metrics — most key results involve some sort of quantitative metric, and PMs are usually the ones who plan out what the objectives and key results are for their team. This affects how the PM role plays out: product teams can be more “key results” focused rather than worry about creativity and freedom. If there was something that needed to be built for the sake of user experience, it could be deprioritized cause it wasn’t part of the planned key result for the team. A product culture that utilizes the OKR system could become more obsessed with just achieving the work items captured in their OKRs rather than building things outside of that — which affects how ideas are prioritized, how work is executed, and how a PM allocates their time in everything.

Hope that gives more clarity on the various nuances found in the product management job. Please comment for any feedback!

About Me

My name is Kasey, AKA J.X. Fu (pen name). I’m passionate about (you guessed it) writing.

Follow me on Medium for more writing, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!