Product managers get very good at telling product stories in interviews.
Tell me about a difficult stakeholder. Tell me about a failed launch. Tell me how you influenced without authority. Tell me about your biggest win.
A strong candidate knows how to make ambiguity sound clean in retrospect. That creates a hiring problem. We can start mistaking the ability to narrate product management for the ability to do product management.
Eloquence is a proxy
Communication matters enormously in product. I want PMs who can write, explain, frame, persuade, and synthesize. But communication is one signal among several. The role also asks for judgment under incomplete information, ownership without perfect authority, recovery after a bad call, curiosity, follow through, tradeoff thinking, and comfort with evidence that contradicts the original plan. A candidate can be gifted at describing those behaviors without consistently demonstrating them.
That is the hiring risk. We hire the story. Then discover the job.
Interviews reward hindsight
Success stories have one enormous advantage: the candidate knows the ending. They can remove the dead ends, make the decision look more deliberate, turn a messy team effort into a coherent narrative, and explain exactly what they learned. Real product work is not like that.
The evidence is partial. The stakeholder interrupts. The metric conflicts with the anecdote. Engineering pushes back. The customer changes their mind. The obvious answer creates another problem.
That is why I want at least part of the interview to happen before the ending is known.
Put the candidate in the water
Give them a product situation. Not a trivia question. A messy situation. A large customer is threatening to leave unless a feature is added. Engineering is already committed. Customer evidence is incomplete.
What do you do? Then introduce new information. Support says the customer's requested solution may be a workaround for a broader problem. Now what? Finance says the account is strategically important, but the economics of the customization are weak.
Now what? You are not testing whether they produce your answer. You are watching how they think.
What do they ask? Which assumptions do they notice? Do they rush to solution? Can they change their mind without losing confidence? Do they identify the tradeoff? Do they know when they need more evidence? Can they still recommend something?
That is closer to the work.
Ask about ownership when the story gets ugly
One of my favorite places in an interview is the moment where the candidate's original decision was wrong. Not “what is your weakness?” A real decision.
What did you believe? What evidence changed? When did you realize it? Who did you tell? What did you do next? What damage did the team have to absorb? What would you do differently?
Listen for ownership. Do they spend the answer explaining why another function made the mistake? Do they hide behind “we”? Do they describe a lesson so polished that the failure no longer feels real?
Or can they say, “I made the call. The assumption was wrong. Here is how I knew. Here is how I corrected it.”
That signal matters to me.
Score what you actually mean
Interview teams often leave a conversation saying things like: “Strategic.” “Sharp.” “Great presence.” “Not senior enough.”
“Strong Product sense.” Those labels are not useful unless the panel agrees on what it saw. Before the interview, define the evidence you would expect from someone who is strong in the role. If you care about ownership, what would that look like in a messy decision? Do they surface assumptions, raise risk early, follow through, and change course when the evidence changes?
If you care about judgment, what would you expect to hear? Can they separate signal from noise, connect customer and business value, make the tradeoff visible, and still recommend a path when the information is incomplete? Now the panel has something more useful to compare than vibes. The candidate can still impress you. They just have to impress you in the direction of the job.
Standardize the prompt, not the thinking
If several candidates receive completely different cases and follow up questions, the interview team may be comparing interviewer behavior as much as candidate behavior. Give candidates a comparable problem. Use the same core evidence. Define what good signals look like before the first interview. Then allow the conversation to breathe.
A strong candidate may take a path you did not expect. That is useful. Structure should make the evidence comparable, not force every candidate to perform your preferred product framework. The goal is not hiring the person who thinks exactly like the panel. It is getting better evidence about how they think when the job becomes messy.
Work samples do not eliminate bias
No hiring method is magic.
A case can become a performance. A structured interview can still be poorly designed. A scorecard can contain biased criteria. A work sample can favor candidates already familiar with your industry's language.
The point is not to replace one false certainty with another.
Use multiple job relevant signals. Ask consistent questions. Give candidates enough context to show how they reason. Make the criteria explicit. Then compare evidence.
That is better than hiring the person everyone enjoyed talking to most.
Hire the behavior you will need after the interview
The interview is a strange environment. The candidate has an hour to demonstrate a career. The company has a few hours to predict how that person will behave in messy situations for years. That is hard. So get as close to the work as reasonably possible.
Do not only ask them to describe ownership. Give them a decision they can own. Do not only ask about ambiguity. Introduce ambiguity. Do not only ask whether they learn. Give them information that should change their answer.
Then watch. Product managers should be able to tell a clear story. But the story is not the job. Hire the person who can still do the work when the story has not been written yet.