How to hire a PM now

Executive summary

• One question, not three. How many PMs, what good looks like and how to interview are one problem: the signals hiring relied on stopped carrying information.
• Up, and smaller. Open PM roles are about 75% above the 2023 low, yet PM headcount at US tech companies sits about 28% below its 2022 peak. Openings shifted from generalist to specialist. AI-focused PMs earn a large premium; the title now covers two jobs.
• Two per twenty. An AI-native team of 20 engineers needs two product people plus a designer who prototypes. Enterprise, regulated and multi-product settings need more. If those two aren’t doing discovery weekly, hire a third.
• Product sense, defined. Prediction, compression and error speed. All three are testable, and they’re built from verified predictions — launches nobody measured don’t count.
• A new loop. Bring something you built and say what’s wrong with it; score a real open decision; write a rubric for an AI feature; diagnose a launch that missed.

The old loop tested whether someone could produce the artifacts of the job, and a model can now produce them. Test the judgment you can watch them use on material they couldn’t have prepared.

Three questions get asked separately, and they’re really one.

How many PMs should we have? What does a good one look like now? How do we tell in an interview?

The question underneath is how you identify product talent when the signals you relied on stopped carrying information. Answering the three separately is why hiring managers keep getting all three wrong. A ratio without a definition of the role is a headcount guess. A definition without an interview is a values statement. An interview without a ratio produces excellent candidates for a seat that shouldn’t exist.

So: the market first, because it’s the part with data. Then the number. Then what to test for. Then the interview.

A caveat on sources. The public numbers contradict each other, and I’ll show you the contradiction rather than pick the flattering side.

Part one: what the market actually says

The contradiction

Two true statements that seem to disagree.

Hiring is up. Lenny Rachitsky’s state-of-the-job-market report in early 2026 put open PM roles at over 7,300 globally — around 75% above the early-2023 low, and the highest since 2022. Userpilot’s 2026 trends report cites postings up 14% year over year as of May 2026. It also notes that companies still describe hiring as unusually difficult.

The market is smaller than it was. Mind the Product’s analysis of the same period notes a 145% net rise in PM roles since 2019, with PM headcount at US tech companies down about 28% from its 2022 peak. Meanwhile 2026’s first six months saw more than 150,000 tech layoffs across 500-plus organizations, with 55% of companies citing AI automation as the reason.

Open PM roles vs early-2023 low+75%

PM postings, year over year+14%

PM headcount vs 2022 peak−28%

−50%0+50%

Sources: Lenny’s Newsletter (openings); Userpilot (postings); Mind the Product (PM headcount at US tech companies).

The numbers

Measure	Change	Baseline
Open PM roles	+75%	early-2023 low
PM postings	+14%	a year earlier
PM headcount	−28%	2022 peak

Both are true. Hiring is recovering from a crash into a market structurally smaller than the 2021–22 bubble. For a hiring manager, that means you will get a lot of applicants and still struggle to fill the role. It feels like a contradiction; it isn’t.

What’s actually changed is composition

The headline numbers hide the real story: the openings are not the same openings.

The cleanest public example is Atlassian: roughly 1,600 jobs cut, about a tenth of the company, with the savings pointed at AI and enterprise sales. The cut made the headlines; the story is which skills the money now buys.

The same pattern shows up in seniority. Junior PMs face the sharpest competition: fewer entry-level openings, more applicants, a higher bar. It shows up in specialization too. Expect fewer “General PM” searches at large companies and more specific ones — AI PM, API PM, consumer PM — with generalists facing slower career growth.

The pay gap is the loudest signal

The compensation data is the part I’d put in front of a skeptical executive.

Pawel Huryn, who tracks PM compensation, used Glassdoor data from late 2024 to put the US figure at roughly $245,000 for AI-focused PMs against $124,000 for traditional PMs.

AI-focused PM$245k

Traditional PM$124k

Source: Pawel Huryn, from Glassdoor data, October 2024.

The numbers

Role	Pay (US)
AI-focused PM	$245,000
Traditional PM	$124,000

The gap has narrowed since that snapshot: Glassdoor’s 2026 US averages put AI product managers near $198,000 against about $151,000 for product managers overall. Still, a market paying more for a skill doesn’t usually open a gap that size on the same title. A market pricing two different jobs does. When the same title pays a third more depending on a qualifier, the title has stopped describing a job.

The honest counterweight

Before this turns into an argument that everything should be an AI PM: a 2025 MIT NANDA study found that 95% of enterprise AI pilot projects fail to produce measurable ROI, while 64% of product teams have already integrated AI into their products.

Product teams that have integrated AI 64%

Enterprise AI pilots with no measurable ROI 95%

Sources: Pragmatic Institute (teams); MIT NANDA (pilots). The MIT figure is widely argued over; hold it loosely.

The numbers

Measure	Share
Product teams with AI in the product	64%
Enterprise AI pilots without measurable ROI	95%

Read those together. Most companies are doing AI product work. Most of it isn’t working. So the premium buys a capability that is scarce and often ineffective. The difference between the 5% and the 95% is largely a product problem, not a model problem. Someone has to decide what the thing is for, what good output means, and how you’d know if it worked.

That’s the job you’re hiring for. Everything below follows from it.

Part two: how many

The old ratio and why it existed

The old rule of thumb, never a law, was one PM per six to ten engineers, and it wasn’t arbitrary. It was a coordination-load calculation. A PM could hold the context of about that many people’s work, write the specs they needed, run the meetings that aligned them, and pass status upward. Past ten, the coordinator became the bottleneck. Under six, they had spare capacity, and someone would notice.

Every input to that calculation was friction: specs as the only way to communicate an idea, synthesis as a week-long task, engineering too scarce to experiment with. Remove those and the calculation doesn’t adjust — it stops applying.

The number

At an AI-native startup with 20 engineers, I’d argue for two product people, plus a designer who prototypes.

That’s 1:10, which looks like the conservative end of the old range and isn’t, because the job is different. Those two aren’t coordinating twenty people. They own bets, define quality for non-deterministic features, and decide fast enough that twenty engineers who can now build quickly don’t spend a quarter building the wrong thing.

The proof point people cite is Linear, which has run at meaningful scale with almost no PMs: two, by one count, and none beyond a head of product, by an earlier one. It’s one data point, and I wouldn’t build a policy on it alone. But it points the same way as everything in Part one.

What breaks if you get it wrong in each direction

The second failure costs more and shows less, which is why “just let engineers own product” works at ten people and stops working at thirty.

Where the number is wrong

Honest exceptions, because nobody should trust a ratio that claims to be universal:

• Enterprise and regulated. Procurement cycles, compliance review and customer advisory boards are human coordination you can’t remove. Closer to 1:6.
• Multi-product portfolios. The constraint is surfaces, not engineers. Five products with four engineers each still needs more than two product people.
• Heavy platform or infrastructure work. Engineers are closer to the user; the ratio stretches further.
• Hardware, or anything with a physical supply chain. None of this analysis applies.

The stronger counterargument

The best case against a lean ratio, stated fairly: fewer PMs means less discovery, and less discovery means the team builds faster in a direction nobody checked. Cheap building makes wrong direction more expensive in total, not less, because you produce more of it.

I think this is right, and it argues for a different kind of product person, not more of them. Discovery got cheaper as fast as building did — an hour of synthesis instead of a week, a prototype in front of a user the same afternoon. Two people who work that way do more discovery than five who commission a study. But if your two product people aren’t doing discovery weekly, the counterargument wins. Hire a third.

Part three: what “good” means now

The problem with “product sense”

Every hiring manager wants product sense. Nobody defines it. When building was the constraint, that was survivable: you could hire on execution and let sense develop. Now that building is cheap, product sense is the job. Hire on an undefined quality and you get a team that interviews well and ships confusion.

So here’s a definition with three testable parts. It’s not the only one possible, but it’s specific enough to argue with.

Component 1: prediction

Can they say what users will do with something before users see it — and are they right?

This is the measurable core. Product sense isn’t aesthetic taste; it’s skill at forecasting human behavior in a specific domain. Someone with it says “they’ll ignore the second button” and is right more often than chance.

And it’s domain-bound. Excellent product sense about developer tools transfers poorly to consumer health. Anyone who claims general product sense is describing confidence, not skill.

How you test it: show them your product, or a competitor’s, and ask what they predict about specific behavior. Then tell them what happens. Watch the quality of the reasoning and, more important, what they do when they’re wrong.

Component 2: compression

Given ten plausible things, can they say which one matters most — and why the other nine don’t?

Generating options is now free. A model will give you twenty features in a minute. The scarce act is elimination, and you can’t eliminate without a theory of what drives the outcome.

The tell is whether their reasoning routes through a mechanism. “This one, because the drop-off is at activation and this addresses activation” is compression. “This one, because it’s high impact and low effort” is a scoring rubric wearing a costume.

How you test it: give them a real backlog of ten items with real context. Ask for the one. Then ask them to defend killing number two.

Component 3: error speed

How fast do they find out they’re wrong?

The most underrated part, and the most predictive. When building was expensive, being wrong was catastrophic, so the valuable trait was being right up front. When building is cheap, being wrong is routine. The valuable trait is the cycle time between committing and finding out.

It shows up as habits: stating what would falsify the bet before building, putting rough things in front of users early, checking the metric after launch rather than at the next planning cycle.

How you test it: ask for a time they were wrong about a product decision. Then ask two follow-ups: how long did it take to find out, and what would have made it faster? Most candidates have rehearsed the first. Almost nobody has rehearsed the second, and their answer is the signal.

How it’s actually built

Product sense comes from verified predictions accumulated over time. You predict, you ship, you check, you update.

So a PM who has run thirty launches and never checked a success metric afterward has thirty launches of experience and nearly zero product sense. The feedback loop that builds it never closed. This is more common than anyone admits. It was partly true of me.

It also gives you a clean interview question: what did you predict, and what actually happened? Someone who can answer that for several launches has been building the thing you want. Someone who can only describe what they shipped has not.

Part four: the interview

Why the old loop stopped working

The standard PM loop was product design, a case study, estimation, and “tell me about a launch.” Each stood in for something you couldn’t observe directly.

Every one of those proxies is now degraded, for the same reason: a model can generate what they produce. With a few hours and a model, a candidate can prepare a polished case study, a crisp product-design answer and a well-structured launch story. The output no longer tells someone who thinks well from someone who prompted well.

Worse, the loop already favored performance over judgment, and generated preparation amplifies that bias.

The fix isn’t to ban AI from the process. You can’t enforce it, and it tests the wrong thing, since they’ll use AI on the job. The fix is to test on artifacts the candidate has to defend live, and on judgment about things they can’t have prepared for.

The four parts

Four hours total, across two sessions.

Part 1: Bring something you built, and tell us what’s wrong with it (45 min)

They bring a real thing: a product they shipped, a tool they made, a prototype. It needn’t be impressive or even successful. They walk you through it, then spend most of the time on what’s wrong with it and what they’d change.

What it tests: all three components at once, plus whether they can build or show at all.

What to watch: do they criticize it substantively or perform humility? Do they know why the flawed decisions were made at the time? Can they distinguish “this was wrong” from “this was right given what we knew”?

The kill signal: they can’t name a real flaw, or every flaw was somebody else’s fault.

Part 2: Score a real ambiguous decision (60 min)

Give them a real open decision from your company, with real context — usage data, support themes, a competitor move, constraints. Ask them to make the call and to say what evidence would change their mind.

What it tests: compression, and whether they can make a bet rather than a recommendation.

What to watch: do they ask for the data they’d need, or work from vibes? Does the falsification list name observable things, or platitudes? Do they commit?

The kill signal: “it depends” without ever resolving it. Real ambiguity still needs a decision; that’s the job.

Part 3: Write a rubric for an AI feature (45 min)

Show them a model-powered feature — yours, or one from a well-known product. Ask them to define what a good output looks like, precisely enough that someone else could apply it, and to say which failures would block a release.

What it tests: the one truly new skill, and the most discriminating part of the loop. Most candidates have never done this. The ones who have stand out at once. (The long version of what you’re asking them to do is here.)

What to watch: are the criteria observable? Do they think about fabrication and omission, or only about fluency? Do they distinguish severity — a wrong fact versus a clumsy sentence?

The kill signal: criteria that only a model could satisfy trivially (“is it well-written”), or no notion that outputs vary at all.

Part 4: A launch that missed (45 min)

Describe a real launch of yours that underperformed, with the numbers. Ask: what would you have measured, when would you have known, and what would you have done at each decision point?

What it tests: error speed, and whether they think in verified outcomes.

What to watch: do they propose a metric before proposing a fix? Do they ask when the metric would have moved? Do they distinguish “the bet was wrong” from “the execution was wrong”?

The kill signal: jumping straight to solutions without asking what success was supposed to look like.

What this costs you

More than the old loop, and I’ll be straight about it.

You have to prepare real material: an open decision, a real launch with real numbers, a feature to critique. That’s a few hours of work per role, and it means showing candidates some internal reality. Most companies won’t do this, which is why it’s a hiring advantage if you do.

It also costs the candidate more time, so respect that: pay for it if you can, or hold it to four hours and don’t add a fifth round.

What it screens out that you might not want

The honest failure modes of my own format:

The short version

The market: hiring is up and the market is smaller. Openings shifted from generalist to specialist and from junior to senior. AI-focused PMs earn a premium large enough (double in 2024, about a third more now) that the title covers two different jobs.

The number: two product people per twenty engineers at an AI-native company, with real exceptions for enterprise, multi-product, and regulated environments. If those two aren’t doing discovery weekly, hire a third.

The definition: product sense is prediction, compression, and error speed. All three are testable. It’s built from verified predictions, which means launches nobody measured don’t count as experience.

The interview: bring something you built and criticize it; score a real ambiguous decision; write a rubric for an AI feature; diagnose a launch that missed.

The through-line: the old signals tested whether someone could produce the artifacts of the job. A model can now produce them. So test for what it can’t: judgment you can watch them use on material they couldn’t have prepared.

— Chris

Market data checked September 2026; the latest figures are from March–June 2026, the pay chart from October 2024.

Sources

Where the evidence comes from. Each row opens the document itself; the tag says which part of the argument it supports, and ↩︎ goes back to the sentence that uses it.

1. State of the product job market in early 2026Lenny Rachitsky, Lenny's NewsletterThe marketNewsletterMar 2026↗︎7,300 open PM roles; 75% above 2023 low
2. 6 Product Management Trends in 2026: The PM Role Is SplittingUserpilotThe marketArticle2026↗︎PM postings up 14% YoY
3. What the data tells us about tech and PM lay offsMind the ProductThe marketArticleJun 2026↗︎145% rise since 2019; 28% below peak
4. Atlassian cuts 1600 jobs to fund AI and enterprise expansionComputerworldComposition shiftNewsMar 2026↗︎The ~1,600 roles cut
5. The AI Product Manager in the US makes $245K, compared to $124K for a PM (Glassdoor)Pawel Huryn (X post)The pay gapArticleOct 2024↗︎$245k vs $124k (Glassdoor), Oct 2024
6. MIT report finds most AI business investments failMIT NANDA, as reported by Virtualization ReviewAI counterweightNewsJul 2025300+ initiatives, 52 interviews, 153 surveys↗︎95% of AI pilots no measurable ROI
7. The 2025 State of Product Management & Marketing ReportPragmatic InstituteAI counterweightReport2025↗︎64% of product teams integrated AI
8. How a $1.25B Unicorn Builds Products with Only 2 Product ManagersAakash Gupta (Medium)The numberArticleJul 2025↗︎Linear runs with two PMs
9. How Linear builds productLenny Rachitsky (Lenny’s Newsletter)The numberNewsletter2023↗︎No PMs, just a head of product
10. AI Product Manager: Average Salary & Pay Trends 2026GlassdoorThe pay gapDocs2026US average AI PM salary ~$197,600; Product Manager ~$151,500↗︎Current AI PM vs PM pay gap