A More Accurate PM Job Description

There’s been a lot of talk recently about the increase in competition for product management jobs in the tech industry. Whether it’s MBA students vying for PM jobs in the Valley, young undergrads looking for a spot in the top APM programs, founder-turned-PMs, or internal transfers, many smart, high-performing individuals are finding themselves in the product role.  

What’s not to like about the job? On paper, it presents an excitingly challenging intersection of disciplines that test both your business and engineering skills. On any given day, you might collaborate with marketing, sales, customer success, engineering, business operations, legal, and others. And through it all, you’ll be flexing a wide range of PM muscles. These might include user empathy, design thinking, domain expertise, stakeholder management, and execution discipline. Each day is different and fast-paced as you ship products and march toward your “North Star.” 

But is this PM job description truly accurate?

Expectation versus reality

As someone actively interviewing new candidates trying to break into product management, I’m seeing signs that people are familiar with this paper description of the role. Candidates come in well-prepared to talk about popular product frameworks, such as those from Cracking the PM Interview or Decode and Conquer. They know about KPIs and success metrics, Fermi problems, the 4Ps of the marketing mix, and user-driven design. These candidates signal strongly for the product side of the job, which is great. These frameworks are absolutely critical to understanding what it takes to be a competent PM. Coming into an interview without this baseline knowledge would be a mistake.

But there’s another side of product management that can’t be so easily taught with decision frameworks and books. 

That’d be the people side, which I’d argue is inherently more challenging to learn and yet even more critical to being a fully effective PM. And this is something we ought to be calling more awareness to when discussing the PM role. 

The power of people skills

At the beginning of my career, I dove in headfirst into my product at Microsoft. I was intent on becoming the expert in my space. I pored through the existing feature backlog, spoke to all my core stakeholders, and learned the ins and outs of the product. The problem ahead of me was a purely objective one, I thought. Rather naively, I believed that all I needed to do as a PM was focus on the user. I’d identify what was needed (the harder part), and then relentlessly execute on shipping to get there (the more straightforward part). Generally, that was the case. What I didn’t realize, however, was how grinding and mentally taxing the latter half of the journey would be. 

In practice, product management calls not just for conceptual thinking, but also for working effectively with people. Within the space, most people refer to it as leading with influence rather than direct authority. To be a truly successful PM, you have to think deeply about what motivates your extended set of teammates and stakeholders to behave the way they do.

You must empathize not only with your users but also your team’s engineers, designers, people managers, marketers, executives and so on. You must constantly champion the user’s needs but also translate/align/refactor them for internal stakeholders. If you see that your team is losing velocity, low on morale, or not agreeing on a solution, you have to dig deeper to understand the “why” behind that obstacle. Depending on where you are in the product lifecycle, these challenges may end up being the hardest part of the PM job. 

Getting comfortable being uncomfortable

You may also find that navigating through this gray zone is inherently uncomfortable. It’s difficult to identify the best way out of a particular spot. For example, let’s say you have a situation where working with the UX team led you to identify a particular feature that you believe will solve a major user need. However, the tech lead you work with vehemently opposes developing this feature because the cost would be too high. When you start digging into the why, you realize the tech lead mentioned the expensive level of effort. But in fact, he did not agree with the priority of the feature. 

You identified a gap in your company’s understanding of your users’ needs. Now you have to bridge the gap between UX and engineering. As a matter of personal style, the tech lead may prefer not to stay too close to the UX work in general. But it is your responsibility to move the ball forward at all costs. Only after digging into the tech lead’s real concerns are you able to do so.

This is just one potential scenario. However, structured decision frameworks may not give you a straightforward solution to many of the day-to-day issues you’ll face. Instead, you will be required to evaluate the intersection of people and product needs within your space and decide on the best path forward. 

Over time, I’ve seen that the absolute best PMs I’ve come across tend to be very strong in this “soft skills” side of product management. High EQ and strong product intuition make a powerful combination for a PM.  They expertly navigate the internal organization, generating support and buy-in for their projects. They effectively delegate and empower the teams they work with. Their teams all share a sense of purpose and rally together to move forward. These PMs aren’t heroes but have an uncanny ability to make heroes out of others around them. 

A more accurate PM job description

None of the decision frameworks you read about in PM interview books explicitly prepare you for the psychological side of the job. So how can you better prepare yourself for this? I don’t have all the answers here, as I consider it very much a WIP. But I do think we can collectively do better as a product community by setting more explicit expectations for what the PM role entails. It’s our job to not only focus on the glamorous elements but also to make the soft, messy side of product management a part of the conversation. This means expanding the description beyond “stakeholder management.” If I were to write a more detailed list of what to expect, it might look a little like this: 

• Identify your core set of stakeholders across multiple business functions, and decide on how to influence them without direct authority 
• Be prepared to “soft lead” the team by bringing a sense of purpose and mission to your everyday work
• Demonstrate expertise in multi-faceted negotiations that require complex tradeoffs 
• Exhibit extremely strong verbal and written communication skills; able to think on your feet when necessary
• Possess high emotional intelligence and self-awareness; able to identify potential roadblocks or team issues, and work with people managers as needed to move the ball forward
• Demonstrate grit: ability to persist and overcome challenges with a sense of conviction, even if missing tangible signs of traction
• Be self-motivated: set priorities and measure progress even without a clear directive

If you’ve been a product manager for a while, you might have your own list of job requirements. Let me know in the comments if I’ve missed anything.