200 PM Job Descriptions Reviewed: 98% Hire for a Dead Job

I spent two weekends doing something mildly unhinged. I pulled 200 product manager job descriptions from companies actively hiring on LinkedIn, Otta, and Wellfound. Big tech. Growth-stage SaaS. Seed-stage startups. AI-native companies. Traditional enterprises.

I scored each one against a simple test: could this job description have been written in 2022, before the agent stack existed?

196 out of 200 could have been.

Four were written for the role I actually run today. The other 98% are hiring for a job that is being automated as the JD is being posted.

If you run product, this is on you. Your JDs are the loudest public statement you make about what you think the role is. Every candidate reads them. Every current PM reads them. Every recruiter benchmarks against them. If yours still looks like 2022, you're telling the market that your org hasn't noticed the last 18 months.

Here's what I saw, what's broken, and how to rewrite.

The short version

The four tells of a dead PM JD: translation-layer language, PRD-centric responsibilities, stakeholder-management framed as a job function, and a conspicuous absence of tools the role touches daily. The four tells of a live one: a 90-day prototype expectation, named tools (Claude Code, Cursor, an eval harness, a deployment stack), owned metrics rather than influenced ones, and an explicit disclaimer that PRDs are not the output. Most JDs miss all four. The fix is mechanical: rewrite the opening to lead with what the PM ships in the first quarter, not what they coordinate.

For the underlying role definition, see the PM Standard. For the agent fleet that automates the old PM execution layer, see Your AI Agent Fleet. For the broader hiring rebuild, see Kill the APM Program.

The four tells of a dead JD

Every one of the 196 bad JDs had at least two of these. Most had all four.

Tell 1: The translation-layer language

"Serve as the bridge between business and engineering."

"Translate customer needs into product requirements."

"Work closely with engineering to deliver on the roadmap."

All three of these phrases describe the exact work that agents now do. The translation layer is automatable. Hiring for it in 2026 is hiring for a role that your next cost-cutting quarter will target.

Tell 2: The PRD-centric responsibilities

"Write detailed PRDs."

"Create comprehensive product specs."

"Maintain the product documentation."

The PRD was a workaround for the fact that engineering was expensive and misunderstanding was expensive. Both of those premises are now weaker than they were two years ago. The replacement is a working prototype plus an eval rubric plus a README. If your JD centers on writing PRDs, you're hiring a documentarian.

Tell 3: The stakeholder-management-as-job-function framing

"Manage cross-functional stakeholders."

"Build consensus across teams."

"Drive alignment through effective communication."

Stakeholder management is a skill, not a job. When it becomes the centerpiece of the JD, it's a signal that the role is structured around internal coordination, not customer outcomes. Coordination work is exactly what a well-run agent pipeline eliminates.

Tell 4: The conspicuous absence

No mention of building. No mention of prototyping. No mention of evals, cost and latency, or agent design. No mention of shipping code. No mention of Claude Code, Cursor, or any specific tool that the role would touch daily.

The absence is louder than the presence. Roles that don't name the tools the Product Builder uses are roles designed for someone who doesn't use them.

The four tells of a live JD

Here's what the four good ones had in common.

1. A specific prototype expectation in the first 90 days. Not "contribute to product strategy" but "ship a working prototype of one customer-facing workflow, deployed to at least 10 users, in your first quarter."
2. Named tools. Claude Code, Cursor, Linear, a chosen eval harness, and a deployment stack. Named. Required. Not "familiarity with AI tools a plus."
3. Owned metrics, not influenced metrics. The PM owns a retention number or a usage number, not "helps drive" it. If the JD hedges on ownership, the role isn't real.
4. An explicit disclaimer that PRDs are not the output. Not every good JD had this, but the best ones did. They named what the output is: a prototype, an eval rubric, a deployed experience, a measured outcome.

That's it. Those four things. Most JDs are missing all four.

A before-and-after teardown

Here's one of the JDs I scored lowest, lightly redacted, and my rewrite. Both are real. One of them will still look like a product manager job. The other is what Product Builders actually do.

Before

Senior Product Manager, Growth

We are looking for an experienced Senior Product Manager to join our Growth team. You will be responsible for driving user acquisition, activation, and retention across our core product.

Responsibilities:

• Define product strategy and roadmap for growth initiatives
• Write detailed product requirements documents and user stories
• Partner with engineering, design, and data science to deliver features
• Analyze user behavior and run A/B tests
• Manage stakeholders across marketing, sales, and customer success
• Communicate product updates and priorities to leadership

Requirements:

• 5+ years of product management experience at a SaaS company
• Strong analytical skills and experience with SQL
• Excellent written and verbal communication skills
• Experience running A/B tests at scale
• Bachelor's degree required, MBA a plus

Tells present: 1, 2, 3, and 4. Perfect score for a dead JD.

After

Growth Product Builder

You will own one growth-stage funnel end-to-end. Not partner with it. Not collaborate on it. Own it.

What you will do in your first 90 days:

• Ship a working prototype of a new activation flow, built in Claude Code or Cursor, deployed to at least 20% of new signups
• Build evals for every AI-driven step in that flow and publish the scorecard internally
• Move the 14-day activation rate by 3 percentage points or return with a clear reason why the bet did not work

What you will do on an ongoing basis:

• Prototype two to four experiments per month without waiting on engineering capacity
• Own the unit economics of any AI-driven step in the funnel, including tokens, latency, and gross margin per user
• Publish a weekly ship log that your team, your leadership, and finance all read

What you will not do:

• Write long PRDs. A prototype plus a one-page README is the spec.
• Manage stakeholders as a primary job function. If you need five meetings to align, the prototype is probably wrong.
• Wait for engineering to build what you describe. If it cannot be prototyped in hours, it does not get prioritized this week.

Requirements:

• You have shipped code in the last 30 days. Not managed it. Written and deployed it.
• You run Claude Code or Cursor as your daily driver and have an opinion about both.
• You have built at least one production eval harness, even if small.
• You can explain the cost and latency tradeoffs between three different model choices for a given task.
• You have strong taste. We will test this with a working trial project, not a whiteboard interview.

This JD will filter out a specific kind of senior PM, and that's the point. It is not a friendlier JD. It is a truthful JD.

The argument against rewriting

When I share this rewrite with CPOs, three objections come back.

"We need a JD that attracts a broad funnel." You already have a broad funnel. What you don't have is a funnel of Product Builders. The rewrite filters out everyone who couldn't do the job, which is the point of a JD. Broad funnels feel safe and create two quarters of bad hires.

"Most of our current PMs couldn't pass this JD." Correct. That's useful information. You now know what the upskilling program needs to address, and you know who the first Product Builders on your team are. The JD is a mirror before it's a filter.

"Our hiring committee will push back on the tone." The tone is the hiring committee's problem to get comfortable with, not the candidate's. A candidate who would be offended by the directness is a candidate who hasn't made the transition. That is useful to surface before the interview, not during it.

A minimal rewrite you can ship this week

If rewriting every open JD from scratch is too much, here's the minimum-viable change.

For every open product role, do three things:

1. Add a 90-day ship expectation to the top of the responsibilities section. Name the artifact. Name the deployment target. Name the measurable outcome.
2. Name your stack. Under requirements, list the tools the candidate will touch daily. Required, not preferred. If you don't want to commit, pick a shortlist of three.
3. Remove or rewrite any line that describes translation, stakeholder management as primary function, or PRD-centric responsibility. Replace each with a verb that starts with "ship," "build," "measure," or "own."

That's a 30-minute edit per JD. By the end of the week, every open role on your careers page signals to the market that you know what this job has become.

What this unlocks

Three things happen within a quarter of the JD being genuinely rewritten.

1. Your best current PMs apply for the internal transition. The JD gives them language for a role they've been inching toward and didn't know how to name.
2. Your interview loop gets shorter and higher-signal. Trial projects replace whiteboard sessions. You spend less time filtering out mismatches because the JD did that work upfront.
3. Your recruiter stops apologizing for the role. Recruiters can't sell a JD they don't understand. A clear, opinionated JD is the easiest thing a recruiter will sell all year.

Where to start

Pull three of your current open JDs. Paste each into Claude with the prompt below. Ship the rewrites by Friday.

You are helping rewrite a product manager job description for a Product Builder role. The Product Builder ships working prototypes in hours using Claude Code or Cursor, owns evals and unit economics, and treats PRDs as obsolete artifacts. Rewrite the attached JD in that voice. Preserve the company name, team name, and reporting line. Remove any language about translation between business and engineering, PRD-centric responsibilities, or stakeholder management as a primary job function. Add a specific 90-day ship expectation with a named artifact, a deployment target, and a measurable outcome. Name the tools the role will touch daily. Keep the rewrite honest and direct. No filler adjectives.

You'll know you got it right when the rewrite reads half as long and twice as clear.

---

I've put a full Product Builder Ladder with four fork-ready JDs (L4 through Principal) on the toolkit at falkster.com/toolkit. Copy, edit, ship.

Further reading

• Lenny Rachitsky's body of work on PM hiring and interviewing
• SVPG on the difference between a Product Manager and a Product Leader
• Teresa Torres on the skills a modern discovery PM needs
• Andreessen Horowitz on the rise of the AI Engineer / Builder archetype