MySmartCoPilot
Ask Passes Your pass 7 days left 1 day left Last day

Your country

Tools that support it use your country for local currency, number formats, units and paper size. Your choice is saved only in this browser.

Product Manager Interviews Module 5

Execution, prioritisation and technical rounds interview questions

Interview questions on execution, prioritisation and technical rounds: warm-ups, then what each harder question tests and how a good answer starts.

24 questions: 4 warm-ups and 20 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

  1. Fresher to mid

    What makes a key result different from a task?

    Answered in the lesson Execution questions and goal setting

  2. Fresher to mid

    What is a feature flag, and how does it make a launch safer?

    Answered in the lesson Deadlines, scope cuts and launch readiness

  3. Fresher to mid

    What is an API? Explain it to someone who has never written code.

    Answered in the lesson Technical questions for product managers

  4. Fresher to mid

    What is technical debt, and how would you explain it to a business stakeholder?

    Answered in the lesson Technical trade-offs for product managers

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

  1. Fresher to senior

    Write one objective and three key results for a team that owns new-user onboarding in a payments app. Explain each choice.

    What it tests
    Turning a team's purpose into an ambitious objective, choosing outcome key results with starts and targets, and protecting them from being gamed.
    First step
    Name the outcome onboarding exists for before any metric: new users who make a first payment that works and come back to pay again, not users who finish a form. Write the objective in words, then choose key results that move only if new users behave differently, each with a start value, a target and the quarter's end.
    Follow-ups

    From the lesson Execution questions and goal setting

    Opening the model answers with your pass…

    Model answers open with any MySmartCoPilot pass.

    • Pro pass · 1 week₹79$2.99
    • 30 days₹179$5.99
    • 1 year₹1,699$45

    One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

    Choose a passI have a licence key

    It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  2. Mid to staff

    Your team scored 0.3 on its main objective this quarter. How do you explain it to leadership, and what changes next quarter?

    What it tests
    Separating ambition, execution, wrong bets and measurement as causes of a low grade, explaining what was learned without excuses, and changing the plan rather than hiding the target.
    First step
    Before explaining anything, read each key result's grade and its weekly line on its own, because 0.3 is an average. For each, ask whether the target was realistic for the time, whether the planned work was done, and whether the work that was done moved the number. The explanation and next quarter's changes follow from which it was.
    Follow-ups

    From the lesson Execution questions and goal setting

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  3. Fresher to senior

    Sales, support and the chief executive each sent an urgent request. You can do two this quarter. How do you decide, and how do you tell the others?

    What it tests
    Turning urgent requests into comparable problems, deciding with a stated method tied to the goal, and saying no to senior people while keeping their trust.
    First step
    Rank the problems, not the people who sent them. Restate each request as the problem it solves and the goal it serves, collect the evidence behind each, such as revenue at risk, users affected or a date, then score all three the same way and say what each choice would give up.
    Follow-ups

    From the lesson Prioritisation frameworks compared

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  4. Senior to staff

    Teams in your company inflate RICE impact scores to win roadmap space. What do you change?

    What it tests
    Treating scoring as an incentive system, making each factor checkable against evidence and outcomes, and keeping a method that many teams can trust.
    First step
    Treat it as an incentive problem, not a character problem: when a score decides who gets roadmap space, teams push the factor nobody checks. Find which factor is inflated and by how much, using last quarter's launches, then make that factor checkable before changing anything else.
    Follow-ups

    From the lesson Prioritisation frameworks compared

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  5. Mid to senior

    Users praise your new features, yet ratings fall. Using Kano's categories, what might be happening, and what do you check?

    What it tests
    Applying Kano's categories to evidence, separating attractive features from must-be qualities, and choosing the data that would tell the explanations apart.
    First step
    Say the Kano reading first: praise for new features sounds like attractive qualities landing, while falling ratings point to a must-be quality that got worse, such as speed, crashes or a basic flow that moved. Then read the low ratings' comments, crash and speed data and task completion by release before deciding.
    Follow-ups

    From the lesson Prioritisation frameworks compared

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  6. Fresher to senior

    Two weeks before a committed launch, engineering says it will be three weeks late. What do you do in the next 48 hours?

    What it tests
    Getting facts before pulling levers, choosing among scope, date, people and quality under a commitment, and telling the people who depend on the date early and honestly.
    First step
    Spend the first hours on facts, not levers: what exactly is late, how sure the new estimate is, and what kind of commitment the date is, announced to customers or an internal target. Then list what could be cut from the work that is left, by MoSCoW priority, and how many days each cut would save.
    Follow-ups

    From the lesson Deadlines, scope cuts and launch readiness

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  7. Mid to senior

    On launch day, one guardrail is just outside its threshold in the 10 percent rollout. Do you continue? Explain the decision.

    What it tests
    Reading a guardrail's interval against its limit, separating noise from harm, and deciding to hold, continue or roll back by a rule rather than by a feeling.
    First step
    Ask what "just outside" means in numbers: the guardrail's interval, not its single value, against the limit written before the launch. If the whole interval is past the limit, the trigger fires; if it straddles the limit, the data cannot say yet, and the answer is to hold the stage, not to widen it.
    Follow-ups

    From the lesson Deadlines, scope cuts and launch readiness

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  8. Mid to staff

    The day before launch, the legal team raises a consent issue in your sign-up flow. How do you handle the launch and the team?

    What it tests
    Treating a legal risk as a criterion that must be met, separating what must change from what can follow, and keeping the team's morale and the launch's credibility.
    First step
    Get the issue in writing and in detail before deciding anything: which step of sign-up, which consent is missing or unclear, which law or rule it touches, and whether people who already signed up are affected. A consent problem is a criterion that must be met, so the question is how fast the flow can be fixed, not whether to launch with it.
    Follow-ups

    From the lesson Deadlines, scope cuts and launch readiness

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  9. Mid to staff

    Your tech lead wants to rewrite a fragile service before your launch, which would delay it by six weeks. How do you decide together?

    What it tests
    Weighing technical risk against a launch with evidence, finding options between all and nothing, and deciding together with the person who owns the technical call.
    First step
    Take the risk seriously and make it concrete: what "fragile" means in incidents, failed releases or hours lost a month, and what the launch's extra load would do to it. Then look for options between a full rewrite and nothing: the parts the launch touches, protections such as limits and alarms, or a rewrite after the launch.
    Follow-ups

    From the lesson Working with engineering, design and data

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  10. Fresher to senior

    The designer believes a new layout is better; the analyst says the test shows no change. How do you resolve it?

    What it tests
    Separating what the test measured from what the design aims at, reading a flat result honestly, and turning a disagreement into the next test.
    First step
    Before reading the test again, ask both what success means: which metric the test measured, whether the layout aims at something that metric misses, such as fewer support contacts or an easier first use, and whether the test had enough users to detect the change that would matter.
    Follow-ups

    From the lesson Working with engineering, design and data

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  11. Mid to senior

    A senior stakeholder keeps asking engineers directly for features, bypassing your roadmap. What do you do?

    What it tests
    Protecting the team's focus without fighting a senior person, understanding the need behind the bypass, and fixing the process rather than the person.
    First step
    Ask what the stakeholder needs and why the roadmap is not giving it to them, before talking about process: the requests themselves, how urgent they are, and whether the stakeholder has ever seen how priorities are set. Going around a roadmap usually means the official route is too slow or too hard to see into.
    Follow-ups

    From the lesson Working with engineering, design and data

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  12. Fresher to senior

    Users say your app is slow, but only on cheaper Android phones. How would you work with engineering to learn why?

    What it tests
    Turning a vague complaint into measurements split by device, separating the phone's own work from the network and the server, and agreeing with engineering which numbers would show the cause.
    First step
    Make "slow" measurable before guessing a cause: which screens, which actions, how slow and on which devices. Then ask engineering to split the app's own timings, such as its start-up time and the time each slow screen takes to appear, by device tier, beside the server's response times for the same requests.
    Follow-ups

    From the lesson Technical questions for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  13. Mid to senior

    A partner's API allows 100 requests a minute per key. Your launch needs about 5,000 a minute at peak. What are your options?

    What it tests
    Sizing the gap, knowing the levers that reduce, combine and spread requests, using the business lever, and designing what users see when a request is refused.
    First step
    Size the gap first: 5,000 against 100 a minute is 50 times the allowance, so no single fix closes it. Then ask what the 5,000 requests are: how many repeat a recent question, how many could be combined into one call, how many can wait a few minutes, and whether the partner offers a higher limit.
    Follow-ups

    From the lesson Technical questions for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  14. Fresher to mid

    Explain caching to your marketing lead, and why it might show some users an old price.

    What it tests
    Explaining a technical mechanism in the listener's terms, naming the trade-off between fast pages and fresh prices, and ending with the decision the listener owns.
    First step
    Start from what the marketing lead sees, not from servers: a price change that some customers see at once and others a few minutes later. Then give a picture of a cache as a quick copy kept close to the customer, the reason it exists, and the decision only marketing can make.
    Follow-ups

    From the lesson Technical questions for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  15. Mid to staff

    Design live order tracking for a delivery app at a product manager's depth: requirements, main parts and the trade-offs you would raise.

    What it tests
    Turning a live feature into requirements with numbers, sketching the path of a rider's position to the customer, estimating its load, and raising the trade-offs of freshness, battery, privacy and lost signal.
    First step
    Start with what the customer needs to see and how fresh it must be: where the rider is, how long until arrival, and what has changed. Then write the numbers that size the design: orders in progress at the busiest hour, how often a rider's phone sends its position, and how often the customer's screen updates.
    Follow-ups

    From the lesson System design for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  16. Mid to senior

    Your app must send 10 million notifications within an hour for a sale. What would you ask engineering, and which product rules would you set?

    What it tests
    Turning a deadline into a sending rate, finding the limit that matters most, the people who open the app, and setting rules for consent, frequency, timing and stopping.
    First step
    Turn the goal into a rate: 10 million in an hour is about 2,800 a second if spread evenly. Then ask whether every step of the sending path can hold that rate, and what happens to the app's servers when a share of the recipients open it within minutes, which is usually the harder limit.
    Follow-ups

    From the lesson System design for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  17. Fresher to senior

    Prices in your app can be up to 5 minutes old because of caching. When is that acceptable, and when is it not?

    What it tests
    Judging staleness by the cost of being wrong on each screen, separating browsing from paying, and naming the moments and the protections that decide it.
    First step
    Ask what an old price costs on each screen, because the answer differs by screen. On a product list, a price 5 minutes old misleads a few people briefly; at checkout, the price charged must be the current one. Split the question by screen, then look for the moments when prices change quickly.
    Follow-ups

    From the lesson System design for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  18. Mid to staff

    Your engineers ask for a quarter to pay down technical debt. Leadership wants features. How do you make the case either way?

    What it tests
    Turning a request for time into evidence of interest, finding options between all and nothing, and making a case that leadership can weigh against features.
    First step
    Do not argue for or against the whole quarter yet. Ask engineering for the debt item by item, and for each its interest in numbers leadership already follows: extra days on every change, failed releases, incidents and bugs users see. Then rank the items by how quickly paying each down would pay for itself.
    Follow-ups

    From the lesson Technical trade-offs for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  19. Mid to senior

    Should your shopping app build its own search or buy a hosted search service? Structure the decision.

    What it tests
    Separating what in search sets the app apart from what is the same everywhere, comparing options on cost over years, control, data and lock-in, and keeping a way out.
    First step
    First ask whether search is part of why customers choose the app; for a shopping app it usually is. Then split search into the engine that finds matching products, which is much the same everywhere, and the ranking that orders them by the app's own data, and compare the options for each separately.
    Follow-ups

    From the lesson Technical trade-offs for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  20. Mid to staff

    A small model costs a tenth as much but makes twice as many errors on your summaries. How do you choose, and what do you measure after launch?

    What it tests
    Pricing errors as well as requests, judging errors by what people do with a summary, and planning how quality is measured once the feature is live.
    First step
    Turn "twice as many errors" into numbers with a cost: how many summaries a month, what share each model gets wrong, and what one wrong summary costs, such as an agent's minutes to re-read the case. Then compare the totals, not the prices, because the model's price is usually the smaller number.
    Follow-ups

    From the lesson Technical trade-offs for product managers

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

All Product Manager Interviews interview questions · The Product Manager Interviews track