Product Manager interview scorecard template
A structured scorecard for interviewing a Product Manager: six weighted competencies, what a 1 and a 5 actually look like, and questions that surface evidence instead of opinions. Print it, or copy it into your ATS.
The Product Manager scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Problem definition and customer evidence Whether product decisions are grounded in specific customer evidence rather than internal opinion, and whether a stated request is separated from the underlying problem. | 20% | Describes users in generic segments and cites no source beyond internal requests; when pressed for the original customer problem, restates the feature that was asked for. | Names the specific customers or data cut behind a decision, quotes what they said or did, and explains how the request differed from the problem they shipped against. |
| Prioritization and trade-off reasoning How the candidate decides what not to build, whether the criteria are explicit, and whether a cut can be defended in front of the team that wanted it. | 20% | Lists the features shipped last year but cannot explain what was cut to ship them or who decided; ranks work by the seniority of whoever asked for it. | Walks through a specific quarter, names the items dropped and the criteria applied, and describes the conversation with the person whose request lost. |
| Outcome metrics and instrumentation Whether success is defined before shipping, the release is instrumented, and the candidate knows what the numbers did afterwards rather than only what launched. | 18% | Reports launch dates and delivery volume as results; when asked what changed for users, cites installs or page views with no baseline to compare against. | States the metric chosen before launch, the baseline it moved from, and the counter-metric watched to catch damage elsewhere in the funnel. |
| Discovery and validation Whether risky assumptions get tested cheaply before engineering time is committed, and whether there is a case where the test changed the plan. | 15% | Describes discovery as writing a spec and reviewing it with stakeholders; every validated idea was built, and no example exists of a plan being abandoned. | Describes a prototype, fake door or manual pilot run before the build, states the assumption under test, and names what the result forced them to change. |
| Influence without authority Whether engineering and design follow the candidate because of reasoning and shared context rather than deadline pressure or escalation to a manager. | 15% | Explains alignment as running meetings and sending updates; when engineering disagreed, the resolution was a decision handed down by a director. | Recounts a disagreement with a tech lead, the constraint the lead raised, and how scope changed after it, with the lead still backing the release. |
| Written communication and product narrative Whether a messy problem can be compressed into a document a stakeholder reads once and acts on, without needing a follow-up meeting to decode it. | 12% | Documents are feature lists and acceptance criteria; the problem, the options considered and the reason for the choice are absent or written after the decision. | Can point to a written doc that named the problem, the options rejected and the open risks, and describes the specific decision it unblocked. |
Weights sum to 100. Agree them before the first interview, not after — adjusting weights once you have scores is how a panel rationalises a favourite.
Questions that surface evidence
Each one asks for something that already happened, in enough detail to verify. Hypotheticals reward rehearsal, not track record.
- Tell me about a feature you killed after launch. What evidence told you to kill it, who disagreed, and what did you do with the team that built it?
- Walk me through the last roadmap you owned. What was on it at the start of the year that was gone six months later, and what caused each removal?
- Describe a decision you made against the loudest stakeholder in the room. What did you have that they did not, and what happened to that relationship afterwards?
- Pick a launch where the metric you chose did not move. What was the baseline, what did the instrumentation tell you, and what shipped next?
- Tell me about something you shipped smaller than the original scope. Who decided what to cut, what got dropped, and what did users lose because of it?
Red flags
- Describes every past product as a success; no launch is remembered as underperforming, delayed or reversed.
- Speaks only in "we" and cannot separate their own decisions from the team when asked directly.
- Justifies a roadmap item by feature parity with other products, with no customer problem behind it.
- Cannot name a single metric that moved, or names one without a baseline or a timeframe.
How to use this scorecard
- Agree the weights with the panel before anyone interviews, and write them down.
- Every interviewer scores every competency independently, adding a note that quotes what the candidate actually said.
- Compare scores before discussing them. Discussing first anchors the panel on whoever speaks loudest.
Build a custom scorecard → · Boolean string to source a Product Manager →
Frequently asked questions
What should a product manager interview scorecard include?
Six to eight competencies weighted by what the role actually needs, each with observable anchors describing a weak and a strong answer. Weighting matters: a discovery-heavy role and a delivery-heavy role should not share the same distribution. Every score should tie back to something the candidate said, not to a general impression.
How do you tell a product manager from a project manager in an interview?
Ask what they decided not to build and why. A product manager answers with customer evidence and trade-offs; a project manager more often answers with schedule and dependency reasoning. Both answers can be strong, but they point to different roles.
How many interviewers should score a product manager candidate?
Three or four is usually enough, provided each one owns different competencies instead of covering the same ground. Have them score independently before the debrief, so the first opinion voiced does not anchor the rest. Scoring each competency against the same anchors, with the words the candidate used cited as evidence, turns the debrief into a comparison of records rather than impressions.
When the stakes are a real hire, use evidence
These tools are quick heuristics. Verdict reads the CV against your job description and scores six dimensions with verbatim quotes as evidence — a hiring document you can defend.