hiring pms
You cannot teach someone to care about the user. You can teach them frameworks. Hire for the caring, train for the frameworks.
Most companies hire PMs badly. They run generic behavioral interviews, ask “design a product for blind people” to every candidate, and then wonder why their new PM spends three months asking what they should be doing.
The problem is not a shortage of PM candidates. India produces thousands of MBA graduates a year who want product roles. The problem is that most hiring processes test the wrong things — presentation skills, framework vocabulary, and confidence in a room. None of these predict whether someone will ship a good product.
I have hired PMs at early-stage startups and reviewed hundreds of PM applications through Pragmatic Leaders. Here is the process that actually works.
Why most PM hiring fails
The core difficulty: PM is the only role where you cannot see the output in a portfolio. A designer shows you their work. An engineer shows you their code. A PM shows you… a resume that says “launched feature X which increased metric Y by Z%.” You have no way to verify whether they drove that outcome or watched it happen.
This means your interview process has to be designed to surface thinking — not recall, not polish, not framework recitation.
A hiring debrief. The panel has just interviewed three candidates for a PM role.
Engineering Lead: “Candidate A was impressive. Named every framework — RICE, ICE, Kano. Very articulate.”
Design Lead: “Sure, but when I pushed on why she prioritized that way, she just restated the framework. No original reasoning.”
Hiring Manager: “Candidate B was rougher in presentation but nailed the follow-up questions. She caught an edge case in the product critique that none of us had noticed.”
Engineering Lead: “But she didn't even mention RICE...”
Hiring Manager: “We're hiring a PM, not a textbook. Frameworks are trainable. The instinct to spot what's broken is not.”
The most polished candidate is rarely the best PM. You need a process that distinguishes rehearsed answers from genuine product instinct.
Three patterns I see repeatedly in bad PM hiring:
1. Over-indexing on pedigree. An IIT/IIM tag or a FAANG stint tells you someone can clear a selection bar. It tells you nothing about whether they can define a problem, make a trade-off under uncertainty, or push back on a stakeholder. I have seen excellent PMs from tier-2 colleges and terrible PMs from brand-name companies.
2. Asking the same case questions everyone practices. “How would you improve Instagram?” has been answered ten thousand times on YouTube. If your case question appears in the first page of Google results, you are testing preparation, not thinking. The candidate who rehearsed the best mock answer wins — and that is not the signal you want.
3. Skipping the take-home and going straight to interviews. Interviews reward verbal fluency. Take-homes reward structured thinking. In India especially, where English fluency varies and does not correlate with PM ability, a written case study levels the playing field.
The four-stage process
Here is the structure I use. It filters roughly 80% of candidates before you spend any interview time.
Stage 1: Resume screen (5 minutes per candidate)
You are not reading resumes. You are scanning for three signals:
- Impact language vs. activity language. “Increased activation by 18% through onboarding redesign” is impact. “Managed the onboarding redesign project” is activity. Impact language means the candidate thinks about outcomes. Activity language means they think about tasks.
- Specificity. Vague bullets (“improved user experience”) are a red flag. Specific bullets (“reduced checkout drop-off from 34% to 21% by removing the mandatory registration step”) are a green flag. If everything on the resume is vague, the candidate either did not measure their work or did not drive it.
- Trajectory, not titles. A PM who went from analyst to associate PM to PM at growing startups has a more interesting trajectory than someone who spent four years as “Product Manager” at a large company where the title is handed out freely.
80-90% of applications for any PM role are irrelevant — people applying to every opening without reading the job description. A non-PM can do this initial filter if you give them clear keywords to look for.
Stage 2: The survey and case study (async, 3-5 days)
This is the most important stage — and the one most companies skip.
Send shortlisted candidates a brief survey:
- Have them study your product
- Ask them to pick one area they would change and briefly explain why
- Include an open section for questions
The survey itself is a filter. 20-30% of candidates drop off here — they were applying to every opening and will not invest time in yours. Good. Those candidates would have quit in month three anyway.
Based on their survey response, send a personalized case study. The case should:
- Be based on the product area they chose (so they are invested in it)
- Ask them to build an argument, not just an analysis
- Test storytelling: “Convince the CEO and CTO to commit resources to your plan”
- Explicitly state that approach matters more than data — they should assume they have access to any data they need
- Set a clear deadline (3-5 days is enough)
The scoring rubric should be objective and pre-defined. I score on five dimensions:
| Dimension | What you’re evaluating | Red flag |
|---|---|---|
| Problem definition | Did they frame a clear problem or jump to features? | Solution-first thinking, no user evidence |
| Prioritization logic | Is there a principled reason for their choices? | ”Users want this” with no segmentation |
| Trade-off awareness | Do they acknowledge what they are NOT doing? | Everything is high priority |
| Communication clarity | Can you follow the argument without the candidate explaining it? | Needs a verbal walkthrough to make sense |
| Business sense | Do they connect user value to business value? | Pure user empathy with no revenue model |
One practice I strongly recommend: ask candidates to not put their names on their submissions. After scoring, share all anonymized submissions with all candidates, ranked by score. This transparency builds enormous goodwill — even rejected candidates leave with respect for your process.
Stage 3: The product critique interview (45 minutes)
Only candidates who score above your threshold on the case study get an interview. By now you have confirmed they can think and write. The interview tests something different: how they think live, under pressure, with follow-up questions they did not anticipate.
Do not ask generic case questions. Instead:
Give them a real product to critique — yours or a well-known one. Hand them a phone with the product open. Give them five minutes to explore. Then ask:
- What is this product’s core value proposition?
- What is the biggest problem you noticed?
- How would you fix it? What would you measure?
- What is the riskiest assumption in your fix?
The power of this format is the follow-up chain. “Why?” asked three times in a row separates candidates who have a mental model from candidates who have a memorized answer.
Stage 4: The culture and collaboration interview (30 minutes)
This is the soft-touch round. You have already confirmed skills and thinking. Now you are answering one question: can I work with this person every day?
No scorecard. No structured questions. Have a conversation about:
- A time they disagreed with their manager and how it played out
- How they handle situations where engineering says “this will take 3x longer than you estimated”
- What they do in their first two weeks at a new company
- A product they admire and why (the depth of their answer tells you about their curiosity)
Listen for self-awareness, not perfection. A candidate who says “I pushed too hard on that one and lost the team’s trust” is more mature than one who has a polished story about every situation.
The five signals that actually matter
After hundreds of PM evaluations, these are the signals that predict on-the-job performance:
1. Problem articulation. Can they describe a user problem crisply, without jargon, in two sentences? If they cannot articulate the problem, they cannot align a team around solving it.
2. Trade-off reasoning. When they prioritize, do they explain what they are giving up and why? PMs who only talk about what they are building — never what they are not building — will over-commit every quarter.
3. Intellectual honesty. When you poke a hole in their argument, do they defend, deflect, or update? The best PMs update. The worst PMs are the ones who cannot say “I had not thought about that.”
4. User empathy rooted in observation. Not “I care about users” (everyone says that). Specific observations: “I noticed the checkout flow asks for a phone number before showing the price — that is friction for price-sensitive users.” Specific beats general, always.
5. Analytical instinct. Not whether they know SQL. Whether, when presented with a problem, their first instinct is to ask “how would we measure that?” If a PM does not think in metrics naturally, they will ship features and hope for the best.
Design a scoring rubric for your next PM hire. For each of the five signals above:
- Write one interview question that specifically tests for it
- Define what a strong answer looks like (specific, concrete example)
- Define what a weak answer looks like (vague, rehearsed, or defensive)
- Assign a weight — which signals matter most for YOUR team’s current gaps?
If your team struggles with execution, weight trade-off reasoning and analytical instinct higher. If your team struggles with vision, weight problem articulation and user empathy higher. A generic rubric is almost as bad as no rubric.
Red flags most hiring managers miss
The consultant PM. Speaks in frameworks, produces beautiful slides, and sounds impressive in meetings. But ask them what they shipped and what happened after launch, and the story gets thin. Consultants optimize for the recommendation. PMs optimize for the outcome. These are different skills.
The “data-driven” PM who has never made a judgment call. Data informs decisions. It does not make them. A PM who cannot act without data will be paralyzed in an early-stage company where the data does not exist yet. Ask: “Tell me about a time you made a product decision with incomplete information.” If they cannot answer, they need more data than your company can provide.
The PM who has never said no. Ask about a feature they killed or a project they recommended canceling. If every story is about launching something, they are either hiding the failures or have never had to make a hard call. Neither is good.
The “visionary” with no shipping history. Grand ideas are cheap. Shipped products are expensive. If the candidate talks mostly about what they want to build and rarely about what they have built, they may be better suited for a strategy role than a PM role.
Perfect interview performance. Counterintuitive, but the candidate who has a polished answer for every question has probably rehearsed extensively. This is fine — preparation is a signal. But if you never get an “I don’t know” or a pause to think, you are seeing the prepared version, not the working version. Push into areas they did not prepare for. That is where the real PM shows up.
Hiring for the India market specifically
A few things that apply particularly to hiring PMs in India:
Do not use English fluency as a proxy for intelligence. A PM from a Hindi-medium engineering college who thinks clearly about users may outperform a PM with perfect English who thinks in frameworks. Your case study (written, async, in their own time) controls for this better than a verbal interview.
Beware the MBA-to-PM pipeline. India’s MBA programs produce many graduates who want PM roles because the title sounds prestigious. Filter hard for genuine product curiosity — ask what products they use daily, what they would change, what they have built (even side projects). A candidate who has built a small tool to solve their own problem is more interesting than one who can recite the Pragmatic Institute framework.
Account for the startup-vs-corporate divide. A PM at a large Indian IT services company (TCS, Infosys, Wipro) has likely operated more as a project manager. This does not disqualify them — but your case study and interview need to test for product thinking specifically, not project management skills. The transition is real and many make it well, but do not assume the title matches the role.
Value domain expertise. In India’s market, understanding local payment systems (UPI, wallets, cash-on-delivery), regional language preferences, price sensitivity patterns, and distribution challenges is genuine product expertise. A PM who understands why a feature works differently in tier-2 cities is more valuable than one who can quote Silicon Valley playbooks.
Test yourself
You are hiring a PM for your B2B SaaS product. After the case study round, you have two finalists. Candidate A scored highest on the case study — clear problem definition, sharp prioritization, excellent written communication. But in the live interview, they were stiff, gave rehearsed answers, and got defensive when challenged. Candidate B scored lower on the case study — decent but not exceptional. In the interview, they were candid, asked unexpected questions about your product, admitted gaps in their knowledge, and updated their thinking when you pushed back.
Your engineering lead prefers Candidate A ('more structured thinker'). Your design lead prefers Candidate B ('easier to collaborate with'). You need to make the call.
your path
You are the VP of Product at Freshworks, interviewing two final-round candidates for a Senior PM role on the CRM team. Candidate A has 5 years of CRM product experience at Zoho, gave a polished case study, and handled every question with confidence — but pushed back when you challenged one of his metrics estimates, explaining why he was right without considering your input. Candidate B has 3 years of experience, weaker domain knowledge, stumbled on the technical questions, but paused when challenged, asked a clarifying question, and genuinely revised her answer.
The call: Who do you hire?
You are the VP of Product at Freshworks, interviewing two final-round candidates for a Senior PM role on the CRM team. Candidate A has 5 years of CRM product experience at Zoho, gave a polished case study, and handled every question with confidence — but pushed back when you challenged one of his metrics estimates, explaining why he was right without considering your input. Candidate B has 3 years of experience, weaker domain knowledge, stumbled on the technical questions, but paused when challenged, asked a clarifying question, and genuinely revised her answer.
The call: Who do you hire?
Where to go next
- Building the team around your PMs: Building a PM Team
- Understanding what makes a strong PM: PM Competency Model
- The career progression your hires will expect: Career Ladder
- Preparing candidates for the interview formats you run: Interview Types