Anatomy of a PM Job Description

What does (and doesn't) belong in the requirements list

hello and welcome back! If you’re new here, so far we’ve written about Founders doing PM work, the first few PM hires, and a smattering of lessons that might be future jumping off points. Have a topic you’d like covered? Reply and let me know!

---

I read a hundred or so PM job posts this week¹. The vast majority of “requirements” sections describe an idealized 🦄 product manager instead of a real person or role. NGL I almost rage quit reading a lot of them.

Here’s how it tends to go:

• N Years of experience

• Industry experience (b2b, b2c, b2b2c, b2d, SaaS, Enterprise)

• Platform experience (mobile, web, desktop, robots)

• Stage experience (0→1, early stage, hyper growth, improving an existing product)

• Love the mission!!!!!

• Comfort with ambiguity and deciding what to do

• Moves really fast while getting everything right

• Organizational Project Management Skills

• Wants to talk to users, cares about the users, voice of the users, loves the users

• Data driven (Analytics, Metrics, SQL, A/B Testing)

• Engineering Skills

• Mega-super-awesome communication and collaboration skills with anyone and everyone

• If we somehow left any skill off of this list, be ready for that too!!!

This role tends to have a big impact on how the team feels, and it’s usually a one-at-a-time hire for the company or the team. Unfortunately, these job descriptions very rarely help a PM narrow down if the opportunity makes sense for them. Deciding what to include (or not) can make the difference between getting great candidates and not getting very many at all.

You want the right PM to feel like the job was written for them - not for any old PM.

Here’s how each of the typical categories play out:

Years of Experience

The primary reason to list this is that if you don’t, anyone who “wants to get into tech” will apply to the open PM job. That creates a lot of noise.

• 1+ indicates “I want someone else to have vetted that you have potential/given you the title.” Often one year in a PM role is not enough to have demonstrated impact or success.

• 2+ indicates one successful job.

• 4+ indicates two successful jobs.

• 5+ indicates a senior independent contributor. often people in this bucket will be starting to want mentorship/management opportunities. Ambitious 4+ people will probably still apply here.

• 10+ indicates you think of yourself as fully autonomous.

If you’re hiring your very first PM you definitely want this to be 4-5+ (ideally two jobs) so the person will have triangulated vs. applying one pattern to your company.

Assessment: If you only want an experienced PM, include it, and think about what signal you’re sending with the number of years. Consider making that signal explicit vs. implicit.

Industry & Platform Experience

How much this matters depends on the stage of your company and the problem you’re looking to have this hire solve. Lots of PMs enjoy shifting industry focus to continue learning, so if you include this unnecessarily you might cut out great candidates. I think it tends to end up in job descriptions more often than not because it was appropriate for one hire, and then people continued to copy-paste it into each JD after that.

A few examples:

• If you’re a growing SaaS company with a churn issue, it makes sense to hire a PM who has seen SaaS before! You could even note that they’d be focused on retention/churn.

• If you’re a consumer company with five experienced consumer PMs, hiring a sixth PM who brings a different perspective might be more useful than another b2c PM. Don’t list it. Maybe you’ll find the ideal candidate who wanted to learn about consumer.

• If you’re a marketplace, requiring the experience could narrow the potential candidate pool. That might increase signal but could also slow the process. Speed of making a solid hire might matter more than that specific experience.

Platform is similar.

• A highly specific platform (robotics, hardware/software combos) might be a big shift and would make sense to call out.

• If you’re hiring a first PM for your App and you have a lot of other PMs who work on web, yes, call out mobile.

• If you’re an app company with existing PMs who work on the app, it’s less important. Switching from web to mobile could take a new PM a little ramp up time, but the core skills aren’t wildly different. Don’t include it.

Assessment: Don’t include them unless it’s directly relevant and super important to the role.

Stage Experience

Stage experience is one of the trickiest ones because companies tend to be communicating something, often in ambiguous terms.

• 0 → 1 Often means the candidate has been a founder, been the first PM at an early stage company, or started a project from scratch within another organization (ex: UberEats for Uber). Typically this also indicates the person is comfortable with ambiguity and limited resources - one example would be running their own launch instead of having a product marketing partner to do it.

• Hyper growth often means the PM has seen some part of the Series A →IPO journey. In product specifically, the A → C part is totally different than C → E or D → IPO prep. The easiest way to figure out which one the job refers to is by checking the company’s recent funding announcements. This could also code for “things are on fire and the role will be intense” or “potential to grow your role quickly if you’re thriving.”

• Improving an existing product usually means something has been built and it’s important to refine it. This codes for “this job won’t be about brainstorming big new ideas/strategies.”

Assessment: Keep it, but try to help candidates understand what it means in your company’s case.

Comfort with Ambiguity, Move Fast, Project Management, Organized, Detail Oriented, Love the Mission, etc.

All of these come up in some form in every job description. If you’ve already covered that you want the PM to have been a PM before, then they know this is part of the story. Sometimes when founders want to include these items to show they know what product is, but it doesn’t help much. Why? They won’t tell the candidate much about your company’s job vs. any other job they might consider.

While every job lists these skills, the implementation is wildly different. If you do want to include something in this bucket, make it concrete.

• Dockwa had one of these that I really liked: "Thrives in an iterative environment that favors small continuous improvement of grand design execution ... Willing to test alternatives and comfortable with imperfect solutions." This says nothing about project management, but says a lot about an inclination to ship small changes vs. sitting around and coming up with big ideas.

• Another clear example is “You will participate in strategic discussions, but lean toward a strong focus on delivery and prioritization” - this easily lets a candidate opt-out if they care more about the direction of the product than project management of tasks. This could easily pair with a 1-2+ years of experience criteria for someone who is looking for exposure to strategy, but no responsibility for it yet.

• Sharing a set of tools can also give some context for how the team works. “Our team currently collaborates using Figma, Jira, and Github” reads very differently from “we’d like experience with Oracle and Smartsheet.”

On the Mission piece, at least 50-75% of the PMs I talk with are focused on the mission and impact of their work. They wouldn’t be on your career page if they didn’t already buy in to the company’s mission. Plus, at the end of the day you’re hiring someone to do a job. Would you not a hire a PM who could do a great job because they wouldn’t identify as “obsessed” with your mission?

Assessment: The high level skills are every description so they’re pretty much meaningless. If you’re going to include them, instead make it detailed enough for the candidate to understand what it means at your company vs. any other PM role.

Users, Business/Metrics/Data, & Tech Skills

The big three! As every PM has seen and shared the classic Mind the Product graphic at some point:

Someone in job descriptions this has often gotten translated to mean that PMs should be equally good at all three. Most PMs come in one of the flavors, and aren’t equally good at each. There are talented PMs who have never run an A/B test, and others who have never written a line of code.

Use the job description to highlight where it’s important for the role to lean in your company:

• If you have an existing team, you might want to keep the person aligned - for instance, a UX leaning product team might want another user-focused PM.

• An existing team might also want to expand out into one of the other areas to increase the number of perspectives within product team meetings. If you’re just starting to ramp up large scale analytics and A/B testing, it might be a good requirement to ask for that perspective!

• If you’re hiring a first PM you should think about where your team is strong and what will help the organization absorb the new person.

  • A devtools company might want a more technically leaning PM even if they have strong engineering talent. That background can help the role blends more seamlessly with the rest of the team (and as a bonus, understand the users).

  • If you have a strong design team already, you might not need another voice of the user.

  • If you’re struggling on analytics but don’t want to hire a dedicated analyst, hiring a PM who focuses on the numbers could be the right call.

The more specific and unique the skill, the more accurately a candidate will be able to assess if they have it or not.

Assessment: Every PM knows they sit between these disciplines. Focus in on what you really need to add to strengthen the team vs. naming them all.

Communication & Collaboration

People aren’t great at self-assessing their communication skills. I have never met a PM who would say they had “poor” communication skills - especially not when applying for a job. Putting it in the description won’t increase signal-to-noise ratio in your candidate pool. Assessing communication needs to happen during the interview process.

One thing that can help is showing how communication and collaboration actually occurs at the company.

• User Interviews describes their Project Pods in depth - “What is a product pod? Each pod is made up of a Product Manager (you), a Tech Lead, a Product Designer, an embedded Data Analyst, and 4+ engineers. The pod will be responsible for a specific outcome and own everything from the discovery of opportunities through the delivery of solutions. Watch this brief video to learn more about the Product team!”

• CockroachDB talks about using documents instead of decks - “Excellent writing skills; our strategic product meetings are based on docs rather than decks.”

• Knowing about timezones and expectations for synchronous or asynchronous communication can also help a PM self-assess if the environment would work.

Assessment: Show how you communicate and collaborate in the description so the candidate can see if it’s a fit, don’t list “good communication skills” as a requirement.

Up the Signal-to-Noise Ratio

By writing a highly specific job description that tells the PM what to expect in your company vs. what it’s like to be a PM, the right candidates are more likely to identify with it and apply.

A job description should tell the candidate what it’s like to be a PM at your company, not what it’s like to be a PM. This will create a high signal to noise ratio in candidates who join the interview process.

---

Enjoy reading about product, devrel, early stage companies, and VC? Please subscribe and let me know what you’d like to hear about next!

1. Thank you to Cassidy Fein, Dan Storms, and #jobs channel of a private Slack community for sharing helpful links!