Product manager interview questions

A stakeholder asks for a chatbot on the settings page. First move?

The strongest answer: Name the job they are hiring the page to do, and whether a bot is the only way — I do not open Figma for a widget first

Why it works: Exactly. Opportunity before solution. Invented lifts are how you skip the job.

• Write the job before the widget.
• An ask ≠ the solution.
• Do not multiply the widget.
• No invented lift %.

A customer asks whether your product “has an API”, and the sales engineer forwards the question to you.

What is the customer actually asking, and what do you need in order to answer?

The strongest answer: They want another system to use our product without a person clicking: which operations are exposed, how they authenticate, what the limits are, and whether it is documented and supported

Why it works: Exactly — for a customer, “an API” means documented, authenticated, supported operations with limits, not the existence of endpoints.

• An API is a supported product.
• Which operations are exposed?
• How do they authenticate?
• Documented, versioned, rate limited.

You cannot name who succeeds if this ships. What is missing?

The strongest answer: A user and a moment — I stop and find one real person in that moment before I write stories

Why it works: Exactly. A person in a moment. Everyone, stock photos, and only-CEO are how you build a hallway.

• Name a person and a moment.
• Stock personas are décor.
• Everyone ≠ a user.
• Sponsor ≠ user.

What is a product metric allowed to be?

The strongest answer: A behaviour we can observe and a decision we will make — not a slide of invented lift

Why it works: Exactly. Observe, then decide. Promised 20% and industry percentiles are fiction.

• Metric = observable behaviour + a decision.
• No promised lift %.
• No always-up vanity.
• No invented industry percentile.

A stakeholder asks “when will it ship?” You have a rough slice and unknowns. Strongest answer?

The strongest answer: A range with what would move the ends — “sooner if the dependency lands, later if it does not” — not a single Tuesday I cannot defend

Why it works: Exactly. A range plus the movers. A single date you cannot defend is a promise, not a forecast.

• Give a range, not a Tuesday.
• Name what moves the ends.
• Do not pick the midpoint as the date.
• Do not invent certainty.

Say your product’s value proposition in one sentence. What has to be in it?

The strongest answer: Who it is for, the problem they have today, and what changes for them — in their words, not our feature list

Why it works: Exactly — audience, problem, change. If a customer cannot recognise themselves in the sentence, it is a tagline.

• Who, what problem, what changes.
• Name the audience precisely.
• State the problem in their words.
• Say what is different after.

A sponsor fixes the scope, the date and the budget on day one. What do you say?

The strongest answer: Something has to flex — if all three are fixed, quality or team health gives silently, so I ask which one the sponsor would move first and write that down

Why it works: Exactly — scope, time and cost are linked; naming the one that flexes up front is what keeps the plan honest.

• One constraint must flex.
• Name scope, time and cost together.
• Ask which one moves first.
• Write the agreed flex down.

A useful-sounding feature does not serve this quarter’s bet. What do you say?

The strongest answer: No, here is the bet, and here is a place to park the idea — I do not smile-yes and starve the team

Why it works: Exactly. A clear no plus a parking lot. Smile-yes is how roadmaps become luggage.

• Say no against the bet.
• Park the idea.
• Do not smile-yes.
• Do not no without a reason.

What goes in a RAID log, and how is an issue different from a risk?

The strongest answer: Risks, assumptions, issues and dependencies, each with an owner and a review date; a risk might happen, an issue already has — so it needs action now, not a probability

Why it works: Exactly — the four lists plus owners and dates; the risk-to-issue distinction is what tells you whether to plan or to act.

• Risks, assumptions, issues, dependencies.
• Owner and review date on each.
• Issue: a risk that happened.
• Review it; do not archive it.

Sales wants a checkbox a customer mentioned once. What do you check?

The strongest answer: Whether that customer’s job is the bet, and whether the checkbox is the job — I do not treat one quote as a mandate

Why it works: Exactly. One quote is a clue. Hidden checkboxes and invented chorus are theatre.

• One quote is a clue, not a mandate.
• Match the bet.
• Do not hide-ship to say yes.
• Do not invent more customers.

A team labels a release with MoSCoW. What do the four labels mean, and which one does the work?

The strongest answer: Must, Should, Could and Won’t-this-time. Must means the release is not worth shipping without it, and the label that does the work is Won’t, because it is a decision written down

Why it works: Exactly — if Must is not “the release fails without this”, the method is a ranked list with nicer words.

• Must: the release fails without it.
• Should: painful, not fatal.
• Could: the first thing dropped.
• Won’t: agreed, written, this release.

What is a PRD for?

The strongest answer: The decision, the non-goals, and what done looks like — not a novel that restates Slack

Why it works: Exactly. Decisions and non-goals. Novels, titles, and invented lifts are not a record.

• Decision, non-goals, done.
• Not a Slack reprint.
• Not a 40-page costume.
• No invented lift in the PRD.

How do you keep a team from marrying the first solution?

The strongest answer: Write the opportunity, then at least two ways, and a reason you picked — I do not start the sprint in love

Why it works: Exactly. Two ways and a pick. First-love, ten-and-none, and loudest-voice skip the opportunity.

• Opportunity, then ≥2 ways, then a pick.
• Do not sprint in first love.
• Do not collect ten and choose none.
• Loud ≠ chosen.

A customer asks for “read-only users”. In refinement the engineers start talking about authentication and authorization as two separate things.

What is the difference, and which one is this ask?

The strongest answer: Authentication is proving who you are — login, SSO, a second factor. Authorization is what that identity may do. Read-only users is authorization: a role, plus the rule for every action

Why it works: Exactly — and the work is the rules: every screen, export, API call and notification has to know what a read-only user may do.

• Authentication: who you are.
• Authorization: what you may do.
• Read-only is a role.
• Decide the rule per action.

You ship a setup wizard. What do you refuse to call the success metric?

The strongest answer: Page views on the wizard — I want completed setup that leads to the job, not tourism

Why it works: Exactly. Completed job, not tourism. Pre-written lifts and percentiles are fiction.

• Measure completed job, not views.
• Tourism ≠ success.
• No pre-written lift.
• No industry percentile.

You have a few months of finished slices and a new, lumpier ask. How do you forecast?

The strongest answer: I show a range from what we have actually finished and I widen it for the new lumpiness — I do not quote a single week as if the past were a law

Why it works: Exactly. Observed finishes, as a range, widened for new uncertainty. No fake precision.

• Start from observed finishes.
• Keep a range; widen for new work.
• Do not multiply tickets into a date.
• Do not wait for a perfect breakdown.

After a search redesign, average time in the app is up and sessions per user are up. Someone proposes putting it in the company update.

What do you check first?

The strongest answer: Whether people are finding things faster or slower — for search, more time and more sessions can mean failure. I look at successful searches, repeat searches, and what happens next

Why it works: Exactly — engagement is only good when it is time spent getting the job done. For a search box, more time is a warning.

• Engagement is a proxy, not value.
• Ask what the job is.
• For search, faster beats longer.
• Check outcomes, not minutes.

What does a good spec do for engineering?

The strongest answer: Removes the decisions they should not have to guess — states, empty, permissions — I do not send a moodboard and vanish

Why it works: Exactly. The decisions. Pixel prisons, vibes, and invented percentiles do not unblock.

• Spec the decisions: states, empty, permissions.
• Do not vanish behind a moodboard.
• Do not pixel-prison.
• No invented performance percentile.

A peer wants to rank the backlog with RICE and ship the top number. Pushback?

The strongest answer: RICE is a conversation starter — the scores are guesses I will not treat as a law, and I will not invent reach

Why it works: Exactly. A prompt, not a court. Fake reach and vibe-only are two other courts.

• RICE starts a talk; it is not law.
• Scores are guesses.
• Do not invent reach.
• Do not hide in vibe-only either.

An exec wants three things this month. You can do one well. What do you bring?

The strongest answer: One yes, two explicit nos or later, and what we will not watch — I do not take all three as “thin”

Why it works: Exactly. You choose in the room. Thin-all and hope-engineering are how you own nothing.

• One yes; two explicit later/no.
• Do not thin-all.
• Do not add a fourth.
• Do not outsource the no to engineering.

A designer shares a lo-fi wireframe and asks for your feedback. Your instinct is to say the button should be on the right and the list should be a table.

How do you give the feedback?

The strongest answer: Against the problem, not the pixels: name the case that worries me and why — someone with two hundred of these has to find one — and leave the layout to the designer

Why it works: Right — describe the job, the case and the constraint. Prescribing a control hides the reason, so the designer cannot solve for it.

• Feed back on the problem.
• Name the case that worries you.
• Give the constraint, not the control.
• Lo-fi is the cheap moment.

Sales wants a single launch date for a conference. You have a range. Strongest comms?

The strongest answer: I give the range, I name the conference as a constraint, and I say which end we would have to protect — I do not convert the early end into a promise

Why it works: Exactly. Constraint plus range plus what we would protect. The early end is not a gift.

• Keep the range.
• Name the conference as a constraint.
• Say what you would protect.
• Do not donate the early end.

Two directors disagree on the outcome. What do you not do?

The strongest answer: Start the sprint anyway and hope the work settles it — I put the disagreement on one page and make them pick

Why it works: Exactly. One page, one pick. Two PRDs, night Slack, and both-outcomes are how you spend a quarter.

• Surface the fight; make them pick.
• Do not sprint into a disagreement.
• Do not night-Slack a side.
• Do not ship both outcomes.

What is the difference between mitigating a risk and having a contingency for it?

The strongest answer: Mitigation acts before the event to cut its probability or impact; a contingency is the pre-agreed plan and reserve you trigger if it happens anyway — a serious risk usually needs both

Why it works: Right — one reduces the chance or the damage, the other prepares the response; naming both per risk is what a register is for.

• Reduce before, respond after.
• Mitigation: lower probability or impact.
• Contingency: pre-agreed plan and reserve.
• Serious risks get both.

What is strategy, if the roadmap is bets?

The strongest answer: The problems we will not work and the user we will disappoint on purpose — a Gantt is not that choice

Why it works: Exactly. Who we disappoint. Pretty Gantts and everything-sequenced are avoidance.

• Strategy = whom we disappoint.
• Roadmaps are bets under that.
• Gantt ≠ strategy.
• Everything-sequenced is not a choice.

Five “top priority” initiatives share one team. Forecasts keep slipping. Strongest move?

The strongest answer: I make the WIP visible at the initiative level and I ask leadership which two we stop starting — I do not ask the team to go faster

Why it works: Exactly. Portfolio WIP is the constraint. Stop starting. Speed is not the lever.

• Show initiative-level WIP.
• Stop starting; pick what waits.
• Do not split into five theatre teams.
• Do not hide slip in phase 2.

You are writing the PRD for a feature that lets users upload documents and share them with people outside the company.

What goes in it besides the flows?

The strongest answer: Who may see and share what, what we store and for how long, whether links expire, what the audit log records, what happens to the files when an account is deleted, and who reviews it

Why it works: Right — permissions, retention, expiry, audit and deletion are product decisions with user-visible consequences, and they are cheapest before the build.

• Decide the rules in the PRD.
• Who may see and share?
• How long do we keep it?
• Log it, expire it, delete it.

How do you talk about several bets without fake expected-value math?

The strongest answer: What each is for, what would kill it, and how much attention it gets — I do not invent an EV spreadsheet

Why it works: Exactly. Purpose, kill, attention. Invented NPV and little-all are how you starve the real bet.

• Purpose, kill rule, attention.
• No invented EV/NPV.
• Do not rank by slide beauty.
• Do not sprinkle all bets equally.

How do you forecast a lump of work without inventing a velocity?

The strongest answer: From the distribution of what this team has actually finished, as a range, and I say when the work is unlike that history — I do not invent a points-per-sprint law

Why it works: Exactly. Observed finishes. A range. A caveat when the work is unlike the past. No invented law.

• Use this team’s finished history.
• Keep a range.
• Say when the work is unlike the past.
• Do not invent a velocity law.

You will try three copy variants and two metrics. How do you stay honest?

The strongest answer: Write the primary and the confirmation window before the hunt — extras are labelled exploration

Why it works: Exactly. Pre-specify. Hunting and launch-post buffet are how every test “works.”

• Primary + window first.
• Label extras as exploration.
• Do not pick the metric after peeking.
• Do not publish every hunted win.

A permissions change is spread across twenty-two stories. In refinement nobody can say what an admin experiences end to end, and QA keeps finding gaps between the stories.

What do you write?

The strongest answer: A use case for the flow: the actor, the precondition, the main path step by step, and the alternate and failure paths — and keep the stories as the slices we deliver against it

Why it works: Right — stories slice delivery, a use case describes the whole interaction including what happens when it goes wrong. This needs both.

• Stories slice; use cases connect.
• Name the actor and precondition.
• Write the main path in steps.
• Write the alternates and failures.

Legal risk and launch pressure disagree. What conversation do you run with the sponsor?

The strongest answer: I name both risks, I ask which they are willing to hold, and I write the choice — I do not silently pick launch and hope legal sleeps

Why it works: Exactly. Appetite is a choice in the open. Silent launch is how you get both a miss and a finding.

• Name both risks.
• Ask what they will hold.
• Write the choice.
• Do not silently ship past legal.

A stakeholder map with twenty names. What was missing?

The strongest answer: Who can actually stop the bet, and what they fear — a directory is not a map

Why it works: Exactly. Stoppers and fears. Name-counts, fan clubs, and night lobbies are politics without a map.

• Name who can stop it, and their fear.
• A directory ≠ a map.
• Do not map only fans.
• Do not night-lobby instead.

Discovery and delivery keep colliding on the same people in the same week. How do you design the cadence?

The strongest answer: I make the collision visible and I reserve capacity for both tracks — a thin discovery WIP and a delivery WIP — I do not hope people “find time”

Why it works: Exactly. Dual-track needs reserved capacity and visible WIP on both. Hope is not a cadence.

• Reserve capacity for both tracks.
• Show discovery WIP and delivery WIP.
• Do not put discovery on nights.
• Do not hide the collision in one list.

An exec wants to insert a pet. How do you say no without a career stunt?

The strongest answer: Show the bet, the cut, and a reopen path in the room — I do not say yes and starve it, and I do not grandstand

Why it works: Exactly. In the room, with a cut. Whisper-ignore, subtweet, and fake legal are how you lose the room later.

• Bet, cut, reopen — in the room.
• Do not yes-and-starve.
• Do not whisper-ignore.
• Do not invent a legal no.

A six-week build is scoped. One slide lists four assumptions: people want this, they will trust us with the data, we can charge a premium, and we can build it in six weeks.

Which do you test first, and how do you decide?

The strongest answer: The one that would kill the bet and that we know least about — often not the build risk, since engineering has done similar work. I buy the cheapest evidence on that one before the six weeks start

Why it works: Right — rank by damage if wrong against how little you know, then buy the cheapest evidence that could change the plan.

• Test what would kill the bet.
• Rank by damage times ignorance.
• Buy the cheapest evidence.
• Test before the build, not after.

What do you standardise across eight product teams?

The strongest answer: How a bet is written, reviewed, and killed — I do not standardise every ritual tool

Why it works: Exactly. Bet language and kill. Fonts, central approvers, and novels are queues and shelves.

• Standardise write / review / kill of bets.
• Let tools differ.
• Do not approve every story.
• Do not write a shelf playbook.

One large customer signs a three-year contract and pays the first year up front. The monthly revenue chart jumps, and an exec wants to present it as the new run rate.

How do you report it?

The strongest answer: Separate what was booked, what was billed and what recurs: normalise the contract to a monthly figure, show it as one named account, and say plainly that the run rate did not move that far

Why it works: Right — bookings, billings and recurring revenue answer three different questions, and concentration in one account is the part leadership needs to see.

• Bookings, billings and recurring differ.
• Normalise prepayments to months.
• Show account concentration.
• Fix the chart, not the footnote.

The portfolio starts every good idea. Teams are “busy” and nothing lands. What do you install?

The strongest answer: A visible limit on initiatives in progress, a replenishment that stops starting, and a kill/wait list — I do not ask squads for more velocity

Why it works: Exactly. Portfolio WIP is strategy. Stop starting. Velocity is not the lever.

• Limit initiatives in progress.
• Replenish by stopping starts.
• Keep a kill or wait list.
• Do not invent a velocity pool.

The company still sells the roadmap as a contract. Your staff move?

The strongest answer: Change the artefact customers see to problems and review points — and stop sales from tattooing rows

Why it works: Exactly. Change the artefact. 6pt and invented percentiles are how you keep the lie.

• Show problems and review points.
• Stop tattooing rows for deals.
• 6pt is not a fix.
• No invented delivery percentile.

Dates keep slipping and people have learned to give a single number they do not believe. What culture do you set?

The strongest answer: That a defendable range is the professional answer, that narrowing has a check, and that a costume date is a defect — I do not reward the bravest Tuesday

Why it works: Exactly. Ranges are the culture. Rewarding bravery is how you buy fiction.

• Reward defendable ranges.
• Narrowing needs a check.
• Treat costume dates as defects.
• Do not reward the bravest Tuesday.

An exec wants the next all-hands to say the product has found product-market fit. You have three months of data and one very happy design partner.

What would you have to see before you say it, and what do you say in the meantime?

The strongest answer: Cohorts that settle instead of decaying, people coming back and paying without us pushing, and demand we did not source — until then I report the signals and say it is not proven

Why it works: Right — retention that flattens, unpushed demand and willingness to pay are the honest signals, and “not yet” is a legitimate answer at an all-hands.

• Fit is retention, not a spike.
• Read cohorts, not one month.
• Look for demand you did not source.
• Say “not yet” out loud.

PMs are rewarded only for shipping. What breaks?

The strongest answer: They will ship the first idea — I reward a killed bet and a well-asked question, not only a launch

Why it works: Exactly. Incentives write the science. Ship-only, mandatory launches, and leaderboards are how you get junk.

• Reward questions and honest kills.
• Not only launches.
• Do not require a launch every sprint.
• Do not run a launch leaderboard.

Feedback arrives through support tickets, sales calls, app-store reviews, a public board, research interviews and a channel where execs forward customer emails. Eight PMs each read some of it.

What do you install?

The strongest answer: One intake with shared tags so themes can be counted, a review where a theme becomes a decision with an owner, weighting that keeps segment visible, and a loop back to whoever raised it

Why it works: Right — intake, themes, a forum where a theme becomes a decision, and closing the loop. Collection on its own just builds a bigger inbox.

• Intake, themes, decision, loop.
• Tag so themes can be counted.
• Keep the segment visible.
• Tell people what happened.

Twelve product teams are told to “do dual-track.” Discovery becomes a central research team with a six-week queue. What is the caution?

The strongest answer: Dual-track dies when learning is a distant queue — I keep discovery close to the squad with a thin WIP, I do not centralise it into a bottleneck and call it mature

Why it works: Exactly. At scale the caution is distance. A six-week queue is not dual-track.

• Keep learning close to the squad.
• Thin discovery WIP, not a distant queue.
• Do not centralise and call it mature.
• Do not count workshops as dual-track.

Three teams report three “the” activation numbers. What do you lock?

The strongest answer: The definition, the window, and who may change them — I do not lock the chart colour

Why it works: Exactly. Definition and change control. Themes, query-bottlenecks, and novels are not a lock.

• Lock definition, window, changer.
• Let chart taste differ.
• Do not approve every query.
• Do not write a metrics novel.

A sponsor says: “ship it now, we will fix the quality after launch.” The team says the release is not stable.

How do you frame the decision?

The strongest answer: I make the trade explicit: which quality attributes we cut, what that costs after launch in incidents, support and rework, who carries the risk — and the sponsor’s decision goes on record

Why it works: Exactly — quality is the constraint that gives silently; a senior makes it visible, priced and owned rather than deciding it alone.

• Price the quality trade.
• Name the attributes being cut.
• Name the post-launch cost.
• Get the risk owner on record.

Across eight teams, dozens of experiments ran last quarter. This quarter’s roadmap is almost identical to the one written before any of them reported.

What is broken, and what do you install?

The strongest answer: The decision step. Every test gets an owner, a decision written on the day it reports — ship, iterate or stop — and a place those decisions live so the next plan starts from them

Why it works: Right — experiments that report into a vacuum are theatre. Result, decision, owner, date, and a plan that is allowed to change.

• A test ends in a decision.
• Name the owner before it starts.
• Write ship, iterate or stop.
• Let the plan change.