A founder asked me to help hire their first PM. They'd been interviewing for two months. Every candidate looked good on paper and sounded smart in the interview. But something felt off. They couldn't articulate what.
I reviewed their process. The job description was a wish list of 47 requirements. The interview was a conversation. There was no rubric. No product exercise. No structured debrief. The team was essentially asking "do I like this person?" and calling it a hiring process.
This is how most companies hire PMs. It is also why most companies are disappointed with the PMs they hire.
The job description problem
Most PM job descriptions describe a unicorn, not a job. Five years of experience in the exact industry. Technical background preferred. MBA a plus. Strong stakeholder management. Data-driven decision-making. Customer empathy. Strategic vision. Attention to detail.
When every trait is listed, none is prioritized. The candidate who checks the most boxes is not necessarily the one who will succeed in your specific environment.
When I write a JD, I describe the actual job: the problems this person will face, the team they'll work with, the ambiguity level, the decision authority. I'm specific about what the first 90 days look like. A PM joining a team of 3 engineers at a pre-PMF startup faces fundamentally different challenges than a PM joining a 50-person product org at a Series D company. The JD should reflect that.
The result: fewer applicants, but the ones who apply actually want the job you're offering.
What I test for
After coaching 150+ PMs across 30+ organizations, I've seen what separates the PMs who succeed from the ones who struggle. It comes down to five things.
Product judgment. Can they make a good prioritization decision with incomplete information? Not a perfect decision. A defensible one. I test this with a product exercise (never longer than 90 minutes) where the candidate has to scope a feature, make tradeoffs, and explain their reasoning. The reasoning matters more than the answer.
Structured thinking under ambiguity. When the problem isn't well-defined, does the candidate freeze, flail, or start structuring? I watch for how they break down a vague question. PMs who succeed in messy environments don't need perfect inputs. They build structure from what's available.
Communication clarity. Can they explain a complex product decision to someone who isn't a PM? I pay attention to how they talk about their previous work. If they can only describe what they did using PM jargon, they'll struggle to align cross-functional teams.
Learning from failure. I ask about a product decision that didn't work out. Not to judge the failure, but to hear how they talk about it. PMs who've actually learned from failure describe what they missed and what they'd do differently. PMs who haven't tend to externalize the blame.
Self-awareness about scope. Do they know the difference between the work they owned and the work their team did? PMs who claim credit for everything are either inflating or operating at the wrong altitude. The best candidates are specific about their contribution and generous about their team's.
The red flags
Some patterns are hard to spot in conversation but show up consistently in structured evaluation:
Fluency without depth. The candidate talks confidently about every topic but can't go deep on any of them. They know the vocabulary but not the practice. This is the most common false positive in PM hiring.
Solution-first thinking. When given a problem, they jump to the solution before understanding the context. In a product exercise, they start wireframing before they've asked a single clarifying question.
Resume-interview mismatch. The resume says "led cross-functional team of 15." The interview reveals they were one PM on a team with 14 other people. This isn't always dishonest. But when the PM can't distinguish between influence and authority, it predicts friction in your org.
The debrief that actually works
Most interview debriefs default to the loudest voice in the room. Someone says "I really liked them" and the group anchors on that. Or someone says "something felt off" and nobody can articulate what.
I design debriefs to prevent this. Every interviewer fills out a scorecard independently before the meeting. The scorecard maps to specific competencies, not vibes. The debrief starts with each person sharing their scores before any discussion. This surfaces disagreements productively instead of suppressing them.
The best hire is not the candidate everyone likes. It's the candidate whose strengths match the gaps in your team and whose weaknesses are ones you can support.
After the hire
The job description, interview process, and structured debrief are the visible parts of hiring help. The less visible part is what happens after the offer is signed.
I design a 30-60-90 day plan for the new hire's first quarter. What they should learn in the first month. What they should own by the second. What they should have shipped or improved by the third. This plan gives the new PM a clear path and gives the hiring manager a framework for early feedback.
The best outcome is when your new hire walks into a team that's already running well, with clear expectations and a plan they can execute from day one. That's the handoff I build toward.
Related services
Want to work together?
I help teams ship better products. Let's talk about your situation.
Get in touch