Should we give product manager candidates a take-home case?

A short, live case usually gives the same evidence with less unpaid work. If you use a take-home, keep it to two hours, use a fictional or anonymized problem, tell candidates what you will assess, and discuss it with them rather than grading slides.

How technical should a product manager be?

As technical as the product needs. A product manager for a developer platform should read an API reference comfortably. One for a consumer app needs to understand what makes a change hard or easy, not to write code. Decide which before the loop and say so in the job description.

Who should be on a product manager interview panel?

The hiring manager, an engineer and a designer the product manager would work with, and one stakeholder such as sales or support. Give each person one or two competencies so the panel gathers distinct evidence instead of four versions of the same chat.

How do we interview someone moving into product from another function?

Use the same competencies and anchors, and accept evidence from their current job: a support lead who changed a process based on ticket data is showing discovery and metrics. Weigh the work samples more heavily, since the product titles are missing.

Free interview kit

Product Manager interview kit: questions and rubric

For hiring teams interviewing a mid-level product manager who owns a product area and works with one engineering team and a designer. It covers a short screen, five competencies with behavioral, situational and work-sample questions, anchored ratings, the questions never to ask, and a rule for deciding.

5 competencies · 11 questions · anchored 1-to-5 scale · Updated 10 October 2026 · Written by the Itya team

Share this kitLinkedIn X WhatsApp Email

How to use this kit

Agree the competencies with the hiring manager before the job is posted.
Give each interviewer one or two competencies, so nothing is asked twice.
Ask every candidate the same core questions; follow up freely.
Rate each competency against the anchors straight after the interview, alone.
Debrief on quotes, not adjectives, then decide with the rule at the end.

First-round screen

Fifteen to twenty minutes, by phone, video or a disclosed AI screen. The aim is to confirm the basics before the panel spends its time.

What draws you to this role and this product area? Which problems do you want to work on next?
Tell me about a product or feature you owned: the problem, your part in it, and what happened after launch.
What kinds of products have you managed (business or consumer, platform or customer-facing), and how closely have you worked with engineering and design?
The job description sets out the location, working pattern and start date. Do those work for you, what is your notice period, and what compensation range are you expecting?

Competency 1

Customer and problem discovery

A product manager's first job is to find problems worth solving. Evidence about customers is what separates a roadmap from a wish list.

Tell me about a time customer research changed what you built.
Follow up with
- How did you find and talk to the customers?
- What did you hear that surprised you?
- What did you stop doing as a result?
Strong answer
Describes a specific method (interviews, usage data, support tickets), the insight, and a concrete change in direction. Separates what customers said from what they did.
Weak answer
The research confirmed what they had already planned, or 'customers asked for it' is the whole reason. Cannot describe a single customer conversation.
Work sample: churn in our small-business segment has risen this quarter. Here are the anonymized numbers. How would you find out why within two weeks?
Follow up with
- What data would you pull first?
- Who would you talk to?
- What would make you drop your first hypothesis?
Strong answer
Forms hypotheses, combines quantitative and qualitative sources, plans to speak with customers who left and customers who stayed, and says what evidence would disprove each idea.
Weak answer
Jumps to a solution (a discount, a new feature) without diagnosis, or plans open-ended research with no deadline and no decision at the end.

Rating	What it looks like
5 · Strong	Runs focused discovery that combines data and conversation, states hypotheses that could be proven wrong, and changes direction when the evidence says so.
3 · Mixed	Uses customer evidence regularly, but research mostly validates existing plans rather than testing them.
1 · Weak	Builds from requests or opinion. Cannot describe a customer conversation or a decision that evidence changed.

Competency 2

Prioritization and trade-offs

There is always more to build than the team can build. A product manager must say no with reasons the team and stakeholders can follow.

Tell me about a time you deprioritized something a senior stakeholder wanted.
Follow up with
- How did you decide?
- How did you tell them?
- What happened next?
Strong answer
Gives a clear rationale tied to goals and evidence (impact, effort, risk), communicated it directly with alternatives, and kept the stakeholder's trust.
Weak answer
Dropped it because the team was busy, avoided the conversation, or reversed under pressure without new evidence.
You have capacity for one of three things next quarter: a feature your largest customer wants, a reliability fix for a problem many small customers hit, or a new onboarding flow to improve activation. Which do you pick, and how do you decide?
Follow up with
- What information would change your answer?
- How would you explain the decision to the people who lose out?
Strong answer
Estimates or asks for the impact of each against company goals, weighs risk and reversibility, makes a call, and says what would change it. Plans how to tell the people who lose out.
Weak answer
Refuses to choose, picks by gut with no reasoning, or applies a scoring framework mechanically without questioning its inputs.

Rating	What it looks like
5 · Strong	Ties priorities to goals and evidence, makes and owns hard calls, states what would change them, and keeps the trust of the people who lost out.
3 · Mixed	Uses a sensible method and can defend most choices, but struggles to say no to senior stakeholders.
1 · Weak	Cannot explain why the roadmap is in its order. Prioritizes by whoever asks loudest.

Competency 3

Execution with engineering and design

Ideas matter once they ship. Product managers who write clear problem statements and decide quickly keep their team moving.

Walk me through how you took a feature from idea to launch, focusing on how you worked with engineering and design.
Follow up with
- What did your brief contain?
- Tell me about a decision you made mid-build. How did you make it?
- What did you cut to ship?
Strong answer
Describes a clear problem statement and success measure, engineers and designers shaping the solution, timely mid-build decisions, and deliberate scope cuts.
Weak answer
Handed over a detailed spec and was absent until launch, or dictated the implementation. Cannot name a scope trade-off.
What would you do if, two weeks before launch, engineering found that a key part would take another month?
Follow up with
- Who do you talk to first?
- What options would you bring?
Strong answer
Works out the cause with engineering, lays out options (cut scope, launch in phases, move the date), decides with stakeholders, and communicates the change clearly.
Weak answer
Pushes the engineers to work harder to hit the date, or moves the date without telling anyone why.

Rating	What it looks like
5 · Strong	Writes clear problem-first briefs, makes timely decisions, cuts scope deliberately, and keeps engineering and design shaping the solution.
3 · Mixed	Ships reliably with the team, but mid-build decisions are sometimes slow or escalated when they need not be.
1 · Weak	Hands off requirements and disappears, or micromanages implementation. Cannot describe a scope trade-off.

Competency 4

Metrics and outcomes

A launch is not the goal; a change in customer behavior is. Product managers should define success before shipping and check it after.

Tell me about a feature that did not achieve its goal. How did you know, and what did you do?
Follow up with
- What measure did you set before launch?
- What did you learn about the original assumption?
Strong answer
Had a success measure before launch, read the results honestly, diagnosed why, and iterated or rolled back. Shares the lesson without defensiveness.
Weak answer
Defined success after launch, explains away bad numbers, or claims never to have had a feature fail.
Work sample: activation dropped after a redesign of the sign-up flow. Here is the funnel by step. What do you look at first?
Follow up with
- What could be a data problem rather than a product problem?
- What experiment would you run?
Strong answer
Checks the data first (tracking changes, definitions), segments the funnel by step and by cohort, forms hypotheses tied to the change, and proposes a test with a clear success threshold.
Weak answer
Reverts the redesign at once without diagnosis, or proposes several changes at the same time that could never be told apart.

Rating	What it looks like
5 · Strong	Defines success before building, checks the data, segments the results, and acts on the answer even when it shows the feature failed.
3 · Mixed	Sets measures and reads them, but stays at the top line and does not check data quality or segments.
1 · Weak	Treats the launch as the success. Cannot name a measure they own or read a basic funnel.

Competency 5

Communication and influence

Product managers rarely have authority over the people who build. They lead through clear writing, good questions and earned trust.

Tell me about a time you changed the mind of someone who disagreed with you about product direction.
Follow up with
- What evidence did you use?
- What did you concede?
Strong answer
Understood the other person's concern, brought evidence rather than assertion, conceded some points, and reached a shared decision.
Weak answer
Persuaded by escalating or by citing authority, or cannot describe the other person's view.
What would you do if an engineer on your team publicly questioned the value of the feature you were asking them to build?
Follow up with
- What would you say in the moment?
- What would you do afterwards?
Strong answer
Treats it as useful signal, explains the problem and the evidence behind the feature, invites the engineer into discovery, and changes course if the challenge holds.
Weak answer
Gets defensive, pulls rank ('leadership wants it'), or ignores the challenge.
Work sample: in one page, write the problem statement for the churn work you scoped earlier, for an audience of engineers and the sales lead.
Follow up with
- What did you leave out?
- What do you want each reader to do after reading it?
Strong answer
States the problem, who has it, the evidence, what success looks like and what is out of scope, in plain words both audiences can follow.
Weak answer
Describes a solution instead of the problem, uses internal jargon, or leaves success undefined.

Rating	What it looks like
5 · Strong	Explains the why behind each decision, writes problem statements anyone can act on, persuades with evidence, and changes their mind when a challenge holds.
3 · Mixed	Communicates clearly and persuades with evidence most of the time, but is less effective when challenged in public or by senior people.
1 · Weak	Relies on authority or escalation. Writing and explanations are hard to follow.

Never ask

Don't ask a candidate's age, or their graduation year to work it out. Why: age says nothing about product skill, and age-based decisions are unlawful in many places.
Don't ask about marital status, children, pregnancy or plans to start a family. Why: none of it is job-related, and the question is still put mostly to women, which makes it discriminatory as well as irrelevant.
Don't ask about religion, caste, community or the origin of a surname, directly or by proxy ('What does your father do?'). Why: in India these questions signal caste and religion, which have no bearing on the job.
Don't ask 'Where are you from originally?' or 'What is your native place?'. Why: it invites judgments about region and community. If location matters, ask whether the candidate can work from the job's location.
Don't ask about health conditions, disabilities or past medical leave. Why: the only relevant question is whether the candidate can perform the essential functions of the job, with or without reasonable accommodation.
Don't ask for salary history where the law restricts it, as many US states and cities do. Why: it carries past pay gaps into the new offer. Ask for the expected compensation range instead.
Don't use a business-school or college name as a stand-in for product skill. Why: it measures access more than ability. The work sample and the discovery questions show the skill directly.

Making the decision

The must-haves are customer and problem discovery, prioritization, and metrics and outcomes. Any 1 on a must-have is a no, and so is any competency rated 1 by two interviewers. A hire needs an average of 3.5 or higher. The hiring manager decides after the debrief and records the work-sample evidence and the quotes behind each rating.

Questions people ask

Should we give product manager candidates a take-home case?: A short, live case usually gives the same evidence with less unpaid work. If you use a take-home, keep it to two hours, use a fictional or anonymized problem, tell candidates what you will assess, and discuss it with them rather than grading slides.
How technical should a product manager be?: As technical as the product needs. A product manager for a developer platform should read an API reference comfortably. One for a consumer app needs to understand what makes a change hard or easy, not to write code. Decide which before the loop and say so in the job description.
Who should be on a product manager interview panel?: The hiring manager, an engineer and a designer the product manager would work with, and one stakeholder such as sales or support. Give each person one or two competencies so the panel gathers distinct evidence instead of four versions of the same chat.
How do we interview someone moving into product from another function?: Use the same competencies and anchors, and accept evidence from their current job: a support lead who changed a process based on ticket data is showing discovery and metrics. Weigh the work samples more heavily, since the product titles are missing.

A kit is step one.

Itya holds every interviewer to the same rubric, records the interview, and drafts the scorecard with the quotes behind each rating. The AI drafts; your team decides. Free plan, unlimited teammates.

Run this kit in Itya All interview kits