How to hire a Product Manager

PM hiring is full of "visionaries" who cannot deliver and "executors" who cannot think. You want both in the same person. Resumes list feature launches but leave out the decisions behind them. Look at how a candidate thinks through trade-offs, owns their failures, and handles competing demands from stakeholders. A weak PM falls back on "let me check with engineering."

Four traits set strong PMs apart from project managers with a better title. Product sense: can they tell what makes a product good without being told? Trade-off reasoning: when resources are tight, how do they decide what to cut? Stakeholder management: can they say no to a VP and keep the relationship? Accountability: do they own the results as well as the work shipped?

Also look for comfort with unclear goals, since many product teams have small user research budgets. Look for data skills: can they pull their own numbers, or do they file a ticket with the analytics team? And look for clear communication across teams: can they explain things to engineering, sales, and customer success in terms each one understands?

A strong PM interview has three parts. First, a decision walkthrough. Ask the candidate about a product decision they made. Listen for how they framed the problem, what data they used, what other options they weighed, and what happened. Second, a prioritization exercise. Give them a list of competing requests. Sales wants X, engineering wants Y, and customers are asking for Z. Ask them to rank them. Score the quality of their reasoning, whatever answer they pick. Third, a failure story. Ask about a feature or launch that did not work. The best PMs take ownership, explain what they learned, and describe what they changed.

Hiring for industry knowledge over product thinking. A PM who knows fintech but cannot prioritize is less useful than one who can prioritize but needs to learn fintech. Product thinking is harder to teach than industry knowledge.

Mistaking confidence for skill. PMs talk for a living. The most polished presenter in the room may not be the best thinker. Ask follow-up questions that go past their prepared story.

Not testing how they work with others. A PM who cannot work with engineering will write a roadmap nobody builds. Ask how they handle disagreements with their engineering lead. Vague answers like "we align on goals" are a warning. You want specific answers, like "we ran a spike to test the assumption."

Skipping the data question. Every PM says they use data. Ask them to walk through an analysis they did themselves. If they always relied on an analyst, their data skills may be weaker than they claim.