The PM job spec that's costing you the right candidates

Most PM job descriptions are written in about forty-five minutes by someone copying a previous JD and updating the salary band. The result is a document that describes a role nobody fully defined, for a candidate nobody fully imagined, at a company that hasn't quite decided what it needs.

This isn't laziness. It's a structural problem. Hiring managers are busy. HR wants something posted quickly. The last PM had a job title, so the new role gets the same one. The spec goes live. The wrong candidates apply. The right ones don't.

Here's what goes wrong, and how to fix it.

The three most common mistakes

First: the spec describes outputs, not the problem to be solved. 'Define and execute the product roadmap.' 'Work cross-functionally to deliver features.' These are descriptions of PM activity, not of the actual challenge the hire needs to meet. A candidate reading this has no idea whether you need someone to build a product from zero, rescue a struggling one, or scale something that's already working.

Second: the requirements list is a wish list, not a filter. Eight to ten years of experience. B2B and B2C. Enterprise and startup. Deep technical background. Strong design sensibility. Excellent at stakeholder management. These requirements are not complementary; they describe different people. The candidate who meets all of them doesn't exist, and posting a spec that implies they do will either attract overqualified candidates who won't stay, or people who've learned to game the application process.

Third: the culture section is meaningless. 'Fast-paced environment.' 'Collaborative team.' 'High ownership.' Every company says this. None of it tells a candidate whether they'll be managed well, whether engineering respects product, or whether the company has a coherent strategy. The candidates who care about fit, which is to say, the ones you want, can't use this information.

What a better brief looks like

Before writing a word of a job spec, answer these questions in plain language:

What problem is this PM hired to solve? Not their responsibilities, the actual business or product problem that currently doesn't have the right person on it.

What does success look like in ninety days? In a year? What would make you confident, twelve months in, that this was the right hire?

What kind of engineering team will they work with? Senior and autonomous, or junior and needing direction? Do they respect product, or is that a dynamic the new PM will have to earn?

What's the hardest part of this role? Where have previous people struggled? What's the context a good candidate would want to know before accepting?

The answers to these questions are your brief. They may not all go into the public job spec, some are too candid, but they should inform every word of it.

Before and after

Before: 'We're looking for an experienced Product Manager to join our growing team. You'll own the roadmap, work closely with engineering and design, and drive the product strategy for our core platform. The ideal candidate has 5+ years of PM experience, a track record of shipping products at scale, and excellent communication skills.'

After: 'We're looking for a PM to take ownership of our core workflow product, which serves around 800 business customers and has grown faster than the team's ability to maintain it. The immediate challenge is triage: the backlog is large, engineering capacity is limited, and we need someone who can make hard calls about what gets cut without losing the confidence of the team. You'll report directly to the CPO. You'll have one direct report. The role is suited to someone who's been through a scaling challenge before and knows what it feels like to make a prioritisation decision with incomplete information.'

The second version is shorter, more specific, and will attract fewer candidates, which is the point. Every application you don't have to discard is time saved.

What we do differently

When we take on a search, we don't start with the job spec. We start with a conversation about the problem. We ask the hiring manager what they're actually trying to solve, what's failed before and why, and what the first ninety days need to produce.

The brief we build from that conversation is what we use to source against. It's also what we share with candidates before any interview, so that the people who show up are showing up because the role genuinely fits, not because it had the right keywords.

This process takes longer to set up. It produces a much shorter shortlist. And it results in hires that stick.