43 PM Interview Questions, Sorted by What They Actually Test

A feature solves a piece of a job. A product owns the whole job end to end, including the parts around the feature that make it usable on its own, onboarding, support, pricing, positioning. A calendar-invite button is a feature. A scheduling app is a product.

Interviewers ask this to check whether a candidate thinks in terms of user outcomes or in terms of shipped artifacts. The two aren't the same, even though it's easy to conflate them under deadline pressure.

Pick something you can go deep on, not something generic like "Instagram." Interviewers use this to check whether you actually form product opinions in daily life or only when asked to perform one in an interview. A candidate who's never thought critically about a product they claim to love usually gets caught within one follow-up question.

A leading indicator moves before the outcome you care about and gives you a chance to react. A lagging indicator confirms the outcome after it's already happened. Weekly active usage in the first month is a leading indicator for annual retention. Churned revenue at renewal is the lagging confirmation of a problem that was probably visible months earlier.

Lead with the trade-off before you lead with the no. "We can't do this because X" lands better than a flat refusal. And yes, it fails sometimes, a candidate who claims their framework works every time either hasn't said no to anyone senior enough yet or isn't being fully honest about the friction.

Show up with questions before opinions. Learn what's already been tried, what's technically painful about the current system, and where past PMs lost credibility with this specific team, before proposing a roadmap. Trust built by listening first tends to survive the first hard prioritization call better than trust built on early enthusiasm alone.

The most underprepared question in every PM interview. Generic answers, mission, culture, scale, don't land. What works is a specific product or customer problem the company hasn't fully solved yet, and genuine interest in working on it, which requires actually using the product and forming a real opinion before you walk in.

A PRD (product requirements document) is a written statement of the problem you're solving, who it's for, and how you'll know you solved it. The mistake most new PMs make is writing a PRD full of solution detail before anyone has agreed on the problem. A good one leads with a problem statement, names the target user or segment, and states the success metric before it ever mentions a UI or a flow.

Beyond that, a PRD should cover scope (what's explicitly out, not just what's in), the user stories or scenarios it needs to handle, known edge cases, any technical constraints or dependencies flagged by engineering, and a rough launch plan including how you'll measure the outcome afterward. Treat it as a living document, not a spec you write once and hand off. If engineering finds a case you didn't account for during build, the PRD should get updated, not just discussed in a side channel.

RICE stands for Reach, Impact, Confidence, and Effort. Reach is how many users or events the change touches in a given period, say per quarter. Impact is a multiplier for how much it moves the needle per user, usually scored on a simple scale like 3 for massive, 2 for high, 1 for medium, 0.5 for low. Confidence is a percentage reflecting how sure you are about your Reach and Impact estimates, based on data quality or how much you're guessing. Effort is person-months to build it. The score is (Reach x Impact x Confidence) / Effort, and you rank the backlog by that number.

In practice, the value isn't the exact number, it's the forcing function. If a feature request touches 200 users a month with medium impact and full confidence but takes six person-months, and another touches 5,000 users with the same impact and confidence in one person-month, RICE makes that gap visible instead of letting the loudest stakeholder win by default. The weak point is that Impact and Confidence are still subjective, so I always attach a one-line justification to each score so people can challenge the input, not just the output.

An MVP is the smallest thing you can put in front of real users to test your riskiest assumption, not a stripped-down version of the full product roadmap. The word "minimum" refers to the amount of work needed to get a valid answer to a specific question, not to feature count. If your riskiest assumption is "will people pay for this," your MVP might be a landing page and a manual concierge process behind it, with zero actual software built.

To decide what's minimum, I start by writing down the single biggest unknown that could kill the idea, then work backward to the least amount of build needed to resolve that unknown, ignoring polish, edge cases, and scale. A common failure mode is confusing "minimum viable" with "minimum lovable," building something so bare it fails on user experience grounds instead of on the actual hypothesis you meant to test, which gives you a false negative.

A user story is written from the user's point of view, in the "as a [user], I want [goal], so that [benefit]" shape, and it's deliberately loose on implementation. It exists to start a conversation between the PM and the engineering team about intent, not to dictate a solution. A requirement, by contrast, is a precise, testable statement of what the system must do, closer to "the system shall lock the account after five failed login attempts within ten minutes."

In day to day PM work, the story is the headline and the acceptance criteria underneath it do the job requirements used to do: they're the specific, checkable conditions that define done. I write the story to preserve room for engineering to choose the best technical approach, then lock down the acceptance criteria tightly enough that QA and engineering agree on what "correct" looks like before a single line of code is written.

A product manager owns the what and the why: which problem to solve, for which users, and how you'll know it worked. That means owning prioritization, tradeoffs between competing goals, and the metric the team is ultimately accountable to. A project manager owns the how and when: sequencing the work, tracking dependencies across teams, flagging risk to the timeline, and keeping status visible to stakeholders.

A concrete way to see the split: if a launch date slips because a third-party API integration is delayed, the project manager surfaces that risk two weeks out and renegotiates the plan with the teams involved. The product manager decides whether the launch date is worth protecting at all, or whether it's smarter to cut scope, delay, or ship a version without that dependency. In smaller companies one person often does both jobs, which is fine, but conflating the two responsibilities in a larger org tends to produce PMs who spend all their time in status meetings and none of it thinking about the problem.

Jobs to be done is the idea that people don't buy products, they hire them to make progress on a specific job in their life or work, and that job existed before your product and will exist after it. The classic example is the milkshake study: customers weren't buying milkshakes because they craved milkshakes, they were hiring them for a long, boring commute, something filling, one handed, and slow to finish. Once you frame it that way, the competition isn't other milkshakes, it's bagels, bananas, and boredom itself.

Applied to a feature request, say a user asks for a "bulk export to Excel" button, the surface ask is a feature. The underlying job might be "get this data into a format my finance team already trusts so I can close the loop without a meeting." If that's the real job, the fix might be a scheduled report emailed to finance directly, which serves the job better than the literal button the user described and avoids building a feature that only gets used once per user before they forget it exists.

A KPI is a metric you watch continuously to gauge the health of something, activation rate, weekly active users, churn, support ticket volume. It doesn't have a deadline attached, it's just a number you monitor over time, and a healthy KPI can just mean "stay flat, don't regress." An OKR is a goal-setting structure with an Objective, a qualitative statement of direction you want to push toward, and Key Results, specific measurable outcomes tied to a time box, usually a quarter.

The two connect because a Key Result frequently uses an existing KPI as its measurement, but adds a target and a deadline the KPI alone doesn't have. "Activation rate" is a KPI you track every week regardless of what quarter it is. "Increase activation rate from 38% to 48% by end of Q3" is a Key Result built on top of that same KPI. Teams get into trouble when they treat every KPI as if it needs its own OKR, which produces a scoreboard with twenty objectives and no actual focus.

Churn rate is usually customers lost during a period divided by customers you had at the start of that period, expressed monthly or annually. Retention is the inverse framing, either simply 1 minus churn, or more usefully, cohort based: what percentage of users who signed up in a given month are still active on day 30, day 90, and so on. The cohort version is more informative because it isolates a group by start date instead of blending old, loyal customers with brand new ones in a single blended number.

The two can diverge in practice. A company can have a rising blended churn rate while retention curves for its newest cohorts are actually improving, if an older cohort that was always going to churn eventually is dragging the aggregate number down. There's also a split between logo churn, the count of customers who leave, and revenue churn, the dollars lost. A SaaS company can post positive logo churn every month and still grow net revenue if expansion revenue from existing accounts, upsells and seat growth, outweighs what departing customers took with them, which is why net revenue retention over 100% is treated as a strong signal even when some customers are still leaving.

Quantitative research tells you what is happening and at what scale: funnel analytics, A/B test results, survey data with numeric answers, usage counts. It's good at telling you where in a flow users are dropping off, or whether variant B actually beat variant A, but it can't tell you why on its own. Qualitative research, user interviews, moderated usability tests, session recordings, open-ended survey responses, tells you why, at the cost of much smaller sample sizes that don't generalize cleanly to your whole user base.

In practice I use them in sequence rather than picking one. If funnel data shows 40% of new signups abandon at the payment step, that's a quant finding that tells me where the problem lives but not what it is. Running five to eight usability sessions with people at that exact step usually surfaces the actual cause, maybe they don't trust a form field, or a hidden fee shows up that wasn't visible earlier in the flow. Skipping straight to quant-only decisions tends to produce fixes that move a metric without addressing the real friction, and skipping straight to qual-only decisions risks over-indexing on a handful of vocal users who aren't representative.

A customer journey map lays out the stages a user moves through, from first hearing about the product through onboarding, regular use, renewal or churn, along with what they're doing, thinking, and feeling at each stage, and where the friction points and handoffs between teams sit. The common mistake is building it entirely from internal assumptions or a single stakeholder's mental model, then treating it as finished. It ends up describing how the team believes the journey works rather than how it actually works for real users.

The map only earns its keep when it's built from actual evidence, support tickets, session recordings, interview notes, tied to each stage, and when it's revisited after a launch instead of archived in a slide deck. I've seen teams map a beautiful five-stage journey, ship a fix for stage three, and never check whether that stage was even where users were actually getting stuck, because the map was never validated against real usage data in the first place.

Name the user segment first, not the feature. Which type of user, what are they actually struggling with right now, and why does the product fall short for that specific person today. At Amazon this question often shows up dressed as "working backwards," start from the customer outcome you want, not the roadmap item you already had in mind.

A weak answer opens with three feature ideas. A strong answer opens with one frustrated user, described specifically enough that the interviewer could picture them, and only reaches a solution in the second half of the response.

Be specific about what's broken and for whom. "It's confusing" isn't a critique, it's a shrug. A vague critique ("the checkout flow is clunky") signals you haven't actually used the product with any attention. A specific one ("returning users still see the new-account onboarding every time they switch devices") signals the opposite.

Test the underlying problem, not the specific solution you already have in your head. A landing page measuring signup interest, a handful of user interviews, even a manual concierge version of the feature can tell you whether the need is real before engineering touches anything.

The trap to avoid: skipping validation because "I'm confident in the idea," then asking stakeholders whether they'd use it, which mostly produces polite agreement rather than real signal.

Separate a feature that's declining because it's broken from one that's declining because the need genuinely went away. The first is worth investigating and possibly fixing. The second is a sunk-cost trap if you keep pouring engineering time into it out of habit.

Strong answers name a specific signal they'd check, usage among new users versus existing users, retention among the people who still use it, before committing to either path.

Name something specific and defend the alternative with reasoning, rather than hindsight alone. Interviewers are less interested in whether you can spot a bad call after the fact and more interested in whether your alternative would have actually been knowable at the time, or whether you're just pattern-matching on the outcome.

Show you know the difference between output metrics, features shipped, sessions, and outcome metrics, retention, revenue per user, task completion. Connect each metric to a user behavior or a business goal, rather than to a dashboard number sitting on its own. No single metric tells the whole story, which is why you need a small, complementary set rather than one hero number.

Pick something tied to real user value, not to internal convenience. "Number of features shipped" fails this test instantly. "Percentage of users completing their core task within a session" passes it. Be ready to defend why this one number would still miss something important, since a good interviewer will ask exactly that.

A North Star metric is the single measure that best captures the value a product delivers to users, chosen so that improving it reliably correlates with business outcomes too. It's not a vanity number and it's not a revenue number by itself, it sits in between, close enough to the user's real experience that a team can act on it week to week.

There's no single universal framework here, and that's part of the point. Interviewers want a coherent mental model, impact against effort, strategic fit, user pain, applied in context rather than RICE scores recited abstractly. Good answers acknowledge that prioritization means saying no to genuinely good ideas, and that this creates real friction with the people who proposed them.

The answer needs more than "I write a PRD and lock the scope." It requires proactive stakeholder alignment before development starts, and the judgment to tell legitimate scope growth (you learned something new mid-build) apart from scope added because someone didn't want to hear no earlier.

Name the criteria before naming a winner, revenue impact, strategic timing, risk of the other team's roadmap slipping if they don't get resourced now. A decision made purely on whoever asked loudest or first tends to erode trust with whichever team loses out, especially if they can't see the reasoning.

Weigh how core the capability is to the product's differentiation against how fast a bought or partnered solution gets you to market. Building something a vendor already does well, with no meaningful differentiation from doing it yourself, usually wastes engineering time the company doesn't have back.

Quantify who's actually affected before you announce anything. "Some users" is a guess dressed up as an answer. Then build a transition path, an alternative workflow, a migration tool, advance notice, rather than a cutoff date with no bridge. The strongest answers name a specific group they expected to be angry and describe what they actually did about it, not just that they "communicated clearly."

A sunset with zero pushback usually means either the feature genuinely had no remaining users, or the team got lucky. Neither is the same as having handled it well.

Check whether the underlying issue is a product gap or a process gap wearing a product costume. A confusing refund flow might need a UI fix. A flood of refund requests might actually need a policy change nobody's willing to propose because it's uncomfortable, not another button.

This question surfaces how you handle friction without formal authority. Good answers show you listened, understood the technical concern, adapted where the engineer was right, and held your ground with evidence where they weren't. Answers that make the engineer look like an obstacle read as a red flag almost every time.

A values question as much as a skills question. The honest answer is that the tension is real and doesn't always resolve cleanly. Dark patterns can lift short-term revenue while eroding trust over a longer horizon. Good PMs can name where they personally draw that line, and they've thought about what they'd do if leadership pushed them past it.

Structure it: what data you had, what you didn't, how you made the call anyway, and what happened after. The most compelling versions of this answer involve a decision that turned out wrong, but where the process behind it was sound. Interviewers aren't fishing for a success story here. They're checking for judgment.

Name the actual failure mode, not a vague "it didn't hit our numbers." Was the problem the target audience, the messaging, a technical bug, a mistimed launch window. "Specifically" is doing a lot of work in this question, and interviewers notice when an answer stays generic on purpose to avoid admitting a real mistake.

Bring the actual evidence you used, a data point, a user quote, a comparable case from elsewhere in the company. Persistence alone rarely moves someone who outranks you. The strongest version of this story includes a moment where the stakeholder had a real, valid concern you hadn't considered yet, and how that changed your pitch.

Own the specific signal that proved you wrong, a metric, a user complaint pattern, direct feedback from an engineer who'd flagged the risk earlier. Candidates who can't name a single wrong call across their career either haven't shipped much or aren't being straight with the interviewer, and both read poorly.

Get specific about the actual disagreement. "I mediated" describes an activity, not a decision. Was it a scope question, a technical feasibility question, a genuine difference in what "done" means. A PM who can name the real crux of the disagreement, and which side had the stronger argument, comes across better than one who just describes facilitating a meeting.

Name the actual pressure that forced the compromise, a deadline, a leadership mandate, a dependency you didn't control, and be honest about whether it was the right call in hindsight. "We shipped a rough version to hit a demo date, then paid down the debt in the next sprint" is a credible answer. A version with no real compromise in it usually isn't believable.

This one tests whether you can argue against something existing, which is harder than pitching something new. Name the actual cost of keeping the feature, engineering maintenance, a confusing surface area, cannibalized usage of something better, beyond a shrugging "nobody uses it."

Candidates who hedge ("well, it depends") without eventually committing to an answer tend to lose points here. Interviewers want a real opinion, even one they might disagree with.

Statistical significance answers "is this real." It doesn't answer "is this worth the engineering cost, the added complexity, or the opportunity cost of not building something else this quarter." A significant but tiny lift on a low-traffic surface might not justify a permanent maintenance burden.

Strong answers weigh the effect size against implementation cost and against what else the team could have shipped instead, rather than treating "statistically significant" as an automatic green light.

Some changes, a rebrand, a trust and safety fix, a compliance requirement, don't map cleanly to a single number. Propose a proxy: a qualitative research signal, a support ticket volume change, a longer-horizon retention effect you'd check months later rather than this week.

The honest answer admits that not everything worth building shows up in a dashboard by Friday, and that's fine as long as you're explicit about what you're trading for.

Google-style interviewers ask this to test whether you understand competitive dynamics and the company's specific vulnerabilities, not general market chatter. What gets penalized is vagueness. "Competition from other companies" fails. "AI-native search eroding query volume for traditional results" is a real answer, even if it's debatable and even if the interviewer pushes back on it.

A strategy question, not a market-sizing exercise. Start with the strategic rationale and what the company gives up to pursue it, engineering attention, focus, credibility if it fails publicly. Candidates who jump into TAM math before establishing whether the company should care tend to read as busy rather than sharp.

Resist the instinct to give all three equal time, which usually means none of them ship well. Rank by a stated criteria, not by seniority of whoever's asking for each one, and be explicit about which priority gets deprioritized this quarter and why, plus when you'd revisit that call.

Name what you actually gave up, not a trade-off where both sides magically worked out. Speed against quality, one customer segment against another, short-term revenue against long-term trust. The interesting part of this question is the cost, not the win, so an answer with no real cost attached usually isn't the hardest trade-off you've made.

Start by asking where in the funnel abandonment actually concentrates, shipping cost surprise at checkout, a forced account creation step, a payment method that's missing. A metric-improvement question dressed as a design question is really a diagnostic question first.

Once you've named a likely drop point, propose one specific change tied to that hypothesis and say how you'd validate it worked. "Make checkout simpler" without naming a mechanism rarely lands well.

Before touching the flow, ask what "drop-off" means at each step, is it one screen losing most people, or an even bleed across the whole sequence. Those are different problems with different fixes. An even bleed usually means the whole flow is too long. A single-screen cliff usually means one specific thing is broken.

Rank segments by a real signal, revenue concentration, growth rate, strategic fit with where the company is heading, and say the ranking out loud instead of picking whichever segment feels most familiar. Then name which segments you're explicitly not building for yet, since that's the part candidates tend to dodge.

Define the success metric before the test runs, not after you see the results. Choose the right unit of randomization, user, session, or account, since that choice changes what the test can actually tell you. Think about minimum detectable effect before launch, not as an afterthought when the numbers come back ambiguous.

Candidates who can explain why statistical significance matters, but also when a business genuinely can't wait for it, tend to stand out here more than candidates who recite the textbook process without the trade-off.

Start with the strategic question, does the company have a real reason to care about this market, before you touch a TAM calculation. Candidates who jump straight into top-down market sizing math before establishing whether the company should care at all tend to confuse effort with insight.

The biggest mistake is sketching a solution before the group is actually defined. Spend the first third of your time on who this group is, their context, their constraints, what they're doing today instead of the product that doesn't exist yet. Only then propose something, and propose one direction, not five.

Interviewers are watching whether you prioritize or whether you try to solve everything at once. A candidate who tries to serve every possible need of the named group usually ends up serving none of them well.

Name the actual constraint first, spotty connectivity, shared devices, feature phones still in wide use, and design around it rather than shrinking the existing app and calling it done. An SMS-based flow or an offline-first sync model might matter more here than any visual redesign.

This is the single most predictable analytical question in a PM loop, and most candidates still get it wrong under time pressure. Segment before you hypothesize. Is the drop consistent across platform, geography, cohort, and device type, or concentrated in one slice? If it's concentrated, that's your lead. Generate hypotheses only after you've narrowed the space.

Jumping straight to "maybe it was Tuesday's release" sounds confident and is often wrong. It also signals that you don't have a systematic method, which is the actual thing being tested here, not whether you happen to guess the right cause.