How to answer product manager execution interview questions: prioritisation, roadmap calls and shipping decisions

What does the execution round actually test?

The execution round tests whether you can make a delivery call under a real constraint and explain the rule you used, so that someone else could predict your next call. Google's careers site describes the shape of its own interviews plainly: "Every candidate is assessed using clear rubrics," and "We ask role-related, open-ended questions to learn how you solve problems." An open-ended prompt scored against a fixed rubric rewards answers whose reasoning is visible at each step, because the interviewer can only award what they heard.

The label varies by company. Ben Erez, a former Facebook PM writing in Lenny's Newsletter, recalls that the loop he faced there included a round called Execution that has since been renamed Analytical Thinking. In his guide to analytical thinking interviews, he describes that round as assessing a candidate's ability to "establish metrics to track success, identify team goals, and evaluate tradeoffs in a structured way", and notes that although it "normally lasts 45 minutes, you'll have only about 35 minutes of actual working time."

Thirty-five minutes is the working budget. That budget does not stretch to a framework recital. Plan for one main prompt followed by twists ("the CEO wants all three", "the engineer is out sick"), and keep your first answer short enough to leave room for them.

This guide covers the trade-off half of the round: prioritisation, roadmap calls and shipping decisions. The metric half, where a number moved and you diagnose why, has its own method in how to answer the metric dropped interview question.

What are the five moves of a strong execution answer?

A strong execution answer moves through five steps in order, and each one is a sentence or two, not a section.

1. Restate the constraint. Say what is fixed and what can move: the date, the team, the scope, the quality bar. Ask one question if the prompt hides the constraint ("Is the launch date tied to anything external?").
2. Name the lens. Say which rule you will judge the options by, and why that rule fits this constraint.
3. Make the call. Pick. One option, specific enough that the team could start tomorrow.
4. Say what you cut and who you told. Name the losing option, the person it disappoints, and when and how they hear about it.
5. Name the signal that would change your mind. One observable number or event, and the date you will look for it.

Moves 4 and 5 separate candidates more than moves 1 to 3. Most candidates can pick an option. Fewer say who loses, and fewer still say what would prove them wrong, which is the part of the answer that shows you will still be managing the decision after it is made. The product decision making framework runs the same logic at full length for real decisions at work; the five moves are its spoken, five-minute version.

Which prioritisation lens fits which constraint?

A prioritisation lens is the rule that turns a list of options into a ranking. Pick the lens from the constraint, not from habit, and say the sentence that names it.

Lens	Use it when	The sentence that names it
Cost of delay	The date is fixed and options differ in how much they lose for every day they wait	"I'll rank these by what each one costs us per day it isn't done."
Impact against effort	Capacity is the binding limit and options differ in size	"We have two engineers for six weeks, so I'll compare value delivered per week of work."
Reversibility	Some options can be undone or mitigated cheaply and others cannot	"I'll protect the things we can't undo and accept risk on the things we can."

Cost of delay deserves more airtime than it gets in interviews. Black Swan Farming, whose cost of delay pages set out the method for product teams, argues that "it is often far more valuable to get something even a week earlier than it is to make it slightly cheaper to develop." The lens forces you to say why the date matters, which is usually the real constraint hiding in an execution prompt.

Reversibility has a well-known source too. In his 2016 letter to shareholders, Jeff Bezos wrote: "If you're good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure." In an interview, that sentence is your licence to make a call on partial information, as long as move 5 says how you would notice being wrong. For scored methods such as RICE, see how to prioritise features; in an interview you rarely have time to score, so name the lens and reason with it out loud.

How would you answer "Two weeks before launch, QA finds three must-fix bugs and you can only fix two"?

The full prompt, as an interviewer might give it: "Your team launches a redesigned checkout in two weeks. QA has found three bugs everyone is calling must-fix. Engineering says it can fix two of them properly before the date. What do you do?"

Restate the constraint. "So the date is fixed for now and the team can fix two bugs properly. Before I choose, is the date tied to anything outside the team?" Assume the interviewer answers: a partner promotion starts on launch day, and the partner's codes go live in their newsletter that morning. Then: "So moving the date has a real cost, and I'll treat it as fixed unless one of these bugs makes launching worse than not launching."

Ask what the three bugs are. Assume:

• Bug A: the promo code field rejects codes typed in lower case. Every partner promotion code is affected.
• Bug B: on one older app version, still used in about 4 percent of checkout sessions, the address form clears itself if the user switches apps. The order still works if they retype it.
• Bug C: the order confirmation email shows the total before discount. The card is charged the correct, discounted amount.

Name the lens. "The date is fixed, so I'll rank by cost of delay: what each bug costs per day it stays live after launch. Then I'll use reversibility to decide how to handle the one we don't fix: can we soften it without code?"

Make the call. "Fix A and B before launch; ship C and fix it in the first week. A costs the most per day: launch day is the partner promotion, so every partner customer who types the code in lower case fails at the moment we most want them to succeed. B hits fewer people, but it destroys their work and there's no workaround we control. C is confusing, but nobody loses money, and we can mitigate it without a code change."

Say what you cut and who you told. "C ships broken. Today I'd tell the support lead and agree a short reply for 'my email shows the wrong total', so tickets are closed in one touch. I'd tell the partner manager nothing changes for the promotion. And I'd tell finance, because a customer who sees the higher total may dispute the charge, and they should know it's a display error, not a billing one. The fix for C goes first in the post-launch sprint, with a date the support lead can quote."

Name the signal. "If confirmation-email tickets pass 20 a day, or we see a single chargeback citing the email, I'd pull the C fix forward as a hotfix instead of waiting for the sprint. And if B's fix slips in testing, I'd fall back to keeping the old address form for that app version rather than shipping a half-fixed one."

The answer never argued that C is unimportant. It argued that C is the cheapest one to live with for a week, and it named exactly who carries that cost.

How would you answer "Engineering says the feature will take twice as long as planned"?

The full prompt: "You committed a bulk invoice export to a large customer for the end of the quarter, six weeks away. Two weeks in, engineering re-estimates it at twelve weeks of work instead of six. What do you do?"

Restate the constraint. "The date is a promise to a customer, so I want to know what the promise is for. Is the date tied to their renewal, or to something they need to do on that date?" Assume the interviewer says: their renewal is in ten weeks, and their finance team exports invoices one at a time every month end, which takes them most of a day.

Name the lens. "Capacity is the limit, and the commitment has a real job behind it, so I'll use impact against effort on slices of the feature: which part delivers the job their finance team does at month end, for the least work."

Break the feature into slices with engineering in the room, and write the estimates down:

Slice	Value to the customer's month-end job	Estimate	In or out for the date
CSV export of up to 500 invoices, filtered by month	Replaces the manual day of exporting	3 weeks	In
PDF bundle of the same invoices	Needed only for audits, twice a year	4 weeks	Out, next quarter
Scheduled automatic export	Saves a click once a month	3 weeks	Out, next quarter
Exports above 500 invoices	The customer sends about 300 a month	2 weeks	Out until a customer needs it

Make the call. "Ship the CSV export by the original date. That's three weeks of the four we have left, so we keep a week of buffer, and it does the job behind the promise."

Say what you cut and who you told. "PDF bundles and scheduling are out of this quarter. I'd tell the account manager this week and ask to join the next customer call, so the customer hears it from us in week 3 and not as a surprise in week 6. I'd bring the slice table, because 'you get the part that saves your finance team a day, on time, and the audit bundle next quarter' is a better conversation than 'it's late'. And I'd tell my manager before the customer call, not after."

Name the signal. "Two signals. If the CSV slice isn't feature-complete at the end of week 4, I'd go back to the customer about moving the date rather than cutting further, because a smaller slice wouldn't do the month-end job. And after their first month end with the export, I'd check whether their finance team used it or still exported one by one. If they didn't use it, we cut the wrong slice, and the PDF bundle conversation changes."

The answer kept the date and changed the scope, but it also said when it would stop cutting scope and move the date instead. That second rule is what makes the call credible. How to negotiate deadlines and trade scope instead of quality covers the stakeholder conversation in more depth.

How do weak execution answers fail?

Weak execution answers almost always skip a move rather than get one wrong. Four patterns cover most of them:

1. A call with no lens. "I'd fix A and B." The interviewer cannot tell whether you would make the same call tomorrow with different bugs, so the answer scores as a guess, even when it is the right guess.
2. A lens with no call. A tour of RICE, MoSCoW and cost of delay that ends in "it depends on the team's priorities". The prompt asked what you would do.
3. Nobody loses. Every stakeholder ends up happy, usually because the answer quietly assumes overtime or a heroic engineer. Real execution calls have a losing edge, and the interviewer is waiting to hear you name it.
4. The decision is final. No signal, no review date. The answer treats the call as the end of the job, when the job is managing the call after you make it.

A fifth failure shows up under pushback: escalating instead of deciding. "I'd take it to my manager" is a fine step inside move 4. As the whole answer, it hands the decision to someone else in the room you are being hired to run.

How is an execution question different from a behavioural trade-off question?

An execution question is hypothetical and a behavioural trade-off question is historical, but both are scored on the same five moves. "Tell me about a time you had to cut scope" wants the constraint you faced, the rule you used, the call, who lost and how you told them, and what happened next, which is move 5 with a real outcome attached. The behavioural version adds one requirement: evidence that it happened, meaning dates, numbers and named roles. The behavioural interview questions guide covers how to build those stories; the product manager interview questions overview shows where execution sits among the five question types.

What is the honest limit of a five-move structure?

The strongest objection to any answer structure is that it sounds rehearsed, and interviewers who have heard hundreds of candidates notice the recital before they notice the reasoning. That objection is right about recitals. Saying "first I will restate the constraint" out loud scores nothing; actually restating it, in a way that shows you heard the detail about the partner promotion, scores a lot.

The structure also does not supply judgement. If you rank bug C above bug A because "billing emails matter", the moves are all present and the answer is still weak. The structure only makes your judgement easy to follow and easy to challenge. Practise by taking real trade-offs from your own work, running them through the five moves aloud in under five minutes, and having someone interrupt you with a twist halfway through.

Practise execution and delivery questions with feedback

Builders Camp's Product Interviewing bootcamp runs across 2 weeks. Its public curriculum covers execution and delivery questions (prioritisation, roadmap calls, stakeholder conflicts and shipping decisions) alongside product sense, analytics, strategy, and a mock interview and improvement loop.

See the Product Interviewing bootcamp