Product Manager Interviews Module 5 – Execution, prioritisation and technical rounds
Execution questions and goal setting
Answer execution questions in a product interview: write an objective with outcome key results, grade them from 0.0 to 1.0, then plan the work.
What you will learn
- Explain what execution questions test and how they differ from product sense questions
- Write an objective with key results that measure outcomes, not activities
- Evaluate key results from 0.0 to 1.0 and say what each grade means for the goal
- Convert an objective into a first plan with bets, owners, risks and a weekly check
Before you start
What you’ll learn · Before you start
What you will learn
- Explain what execution questions test and how they differ from product sense questions
- Write an objective with key results that measure outcomes, not activities
- Evaluate key results from 0.0 to 1.0 and say what each grade means for the goal
- Convert an objective into a first plan with bets, owners, risks and a weekly check
Before you start
On this page
A team can finish all twelve features on its quarter’s list and still miss its goal, because finished features are output and the goal was an outcome. Execution questions test that part of a product manager’s job: setting goals that measure the outcome, choosing the work most likely to move it, and keeping the plan honest as problems arrive.
Below, you tell execution questions from product sense questions and write an objective with three key results for an invented grocery app’s search team. Then you grade those key results from 0.0 to 1.0 with a program you can change, and turn the objective into a first plan with owners, risks and a weekly check.
Execution questions ask how you would get a chosen goal done
Take two questions about the same invented grocery app. “Design a way for families to plan their weekly shop” is a product sense: The skill a product design round tests: choosing a group of users and the problem that matters most to them, then proposing a solution that fits and a way to tell whether it worked. More in “How product manager interviews work” question: you choose the users, the problem and the solution. “Your team owns search. Set its goals for next quarter, and say what you would do first” is an execution question: the product and its direction already exist, and the interviewer listens for how you would get results from them.
Employers that describe the role in public put this part of the job in their own words. Amazon’s product manager page counts “results-driven” among the traits it looks for and says that product managers drive ideas “from conception to execution”. Atlassian’s handbook for product candidates names delivering outcomes as one of its four expectations, with “Smartly prioritizes to achieve outcomes – says ‘no’ when needed” among its signs. Google’s interview tips say that many questions take the form “How would you approach this situation…?”, which is the shape of an execution question.
Not affiliated
Based on public information about Amazon, Atlassian and Google. MySmartCoPilot is not affiliated with Amazon, Atlassian and Google, and Amazon, Atlassian and Google’s real interview process may differ from what this lesson describes.
Execution questions come in five families, and a strong answer to each shows something different:
| Family | A question of this kind | A strong answer shows |
|---|---|---|
| Goals | “Set your team’s goals for next quarter.” | Outcomes with numbers, and how progress is checked |
| Priorities | “Rank eight ideas for one quarter.” | A stated method, and what it leaves out |
| Deadlines and launches | “The release is at risk. What changes?” | The levers, the launch criteria and a decision |
| Problems as they come | “A key metric fell overnight.” | Checks in a sensible order |
| Working with others | “Design and engineering disagree.” | Shared goals, evidence and who decides |
This lesson teaches the first family. The next three lessons of the module teach priorities, deadlines and launches and working with others; problems as they come are the subject of diagnosing a metric drop.
Answering with a list of features
Wrong: “For search, I would add voice search, filters and a barcode scanner.” That answers a product sense question nobody asked, and it gives the interviewer nothing to measure. Right: start from the goal and the number that would show it, then choose the work most likely to move that number.
Checkpoint
Check: What execution questions test
An objective names the goal; key results say how you will know
The search team’s first draft of goals is a list of things to build: launch filters, add spelling correction, rebuild the search index. The team could finish all three while customers noticed nothing. An OKR (objectives and key results): A way to set goals: an objective says in words where a team wants to go in a period such as a quarter, and around three key results say with numbers how the team will know it got there., an objective with its key results, turns such a list into a goal.
Google’s re:Work guide to OKRs gives the rules in a few lines. Objectives “are ambitious and may feel somewhat uncomfortable”. A key result: A number that shows whether an objective is being reached, with a start value, a target and a deadline, such as searches that end in an order rising from 18 % to 22 % by the quarter's end. It measures an outcome, not an activity. is measurable and “easy to grade with a number”, and key results “should describe outcomes, not activities”. The guide suggests three to five objectives with around three key results each, because more spreads a team’s effort thin. Rewrite each item of the draft as the change it is meant to cause:
| Draft activity | Key result |
|---|---|
| Launch filters for brand, price and diet | Raise the share of searches that end in an order from 18 % to 22 % |
| Add spelling correction | Cut the share of searches with no results from 9 % to 4 % |
| Rebuild the search index | Cut the median time from a first search to a filled basket from 41 to 30 seconds |
Above them sits the objective: make search the fastest way to fill a basket. Each key result has a start value, a target and a deadline, the end of the quarter, and each can move only if customers behave differently. That is the outcome (and output): An outcome is what changed because of a piece of work, for whom and by how much, such as more new users finishing sign-up. An output is what was produced, such as a feature shipped. More in “What product manager interviewers assess” test: ask whether the team could finish the work while the number stays where it was. If it could, you have written an activity.
Key idea
An objective says where the team is going; each key result is a number with a start, a target and a deadline, and it moves only when customers’ behaviour moves.
Checkpoint
Check: Objectives and outcome key results
A grade from 0.0 to 1.0 says how far each key result got
At the end of the quarter each key result gets a grade. In the re:Work guide’s words, OKRs are “usually graded on a scale of 0.0 to 1.0, 1.0 meaning the objective was fully achieved”: each key result is graded, and the objective’s grade is a rough average of them. The program grades the search team’s three key results by the share of the way each one covered from its start to its target, one common way to grade:
# Grades the key results of one objective from 0.0 to 1.0 and averages them, the way Google's re:Work guide to OKRs
# describes grading. The grocery app, its teams and every number are invented. A key result's grade here is the share
# of the way from its start value to its target that the team covered, kept between 0.0 and 1.0: one common way to
# grade, which a team agrees before its quarter starts.
def grade(start, target, ended):
covered = (ended - start) / (target - start) # works when lower is better, too
return min(max(covered, 0.0), 1.0)
OBJECTIVE = "Make search the fastest way to fill a basket"
KEY_RESULTS = [ # (key result, start, target, value at the end of the quarter)
("Searches that end in an order (%)", 18.0, 22.0, 20.8),
("Searches with no results (%)", 9.0, 4.0, 6.5),
("Median seconds from search to basket", 41.0, 30.0, 30.0),
]
print(f"Objective: {OBJECTIVE}")
grades = []
for name, start, target, ended in KEY_RESULTS:
g = grade(start, target, ended)
grades.append(g)
print(f" {name}: {start} to {target}, ended at {ended}, grade {g:.2f}")
print(f"Objective grade, the average of the three: {sum(grades) / len(grades):.2f}")
HISTORY = { # each team's objective grade in its last three quarters, oldest first
"Search team": [0.66, 0.58, 0.73],
"Delivery-slot team": [1.0, 1.0, 1.0],
}
print("\nGrades of the last three quarters:")
for team, past in HISTORY.items():
mean = sum(past) / len(past)
if all(g == 1.0 for g in past):
note = "every target reached every time, so the targets were safe"
else:
note = "ambitious targets, mostly reached"
print(f" {team}: {' '.join(f'{g:.2f}' for g in past)}, average {mean:.2f}: {note}")Output
Objective: Make search the fastest way to fill a basket Searches that end in an order (%): 18.0 to 22.0, ended at 20.8, grade 0.70 Searches with no results (%): 9.0 to 4.0, ended at 6.5, grade 0.50 Median seconds from search to basket: 41.0 to 30.0, ended at 30.0, grade 1.00 Objective grade, the average of the three: 0.73 Grades of the last three quarters: Search team: 0.66 0.58 0.73, average 0.66: ambitious targets, mostly reached Delivery-slot team: 1.00 1.00 1.00, average 1.00: every target reached every time, so the targets were safe
Recorded with Python 3.14.8 on macOS 26 arm64. To run it yourself: mise exec python@3.14.8 -- python3 okr_score.py
Runs on this device, in your browser. The first run downloads Python (about 13.5 MB), which is kept for the next runs.
Your run, in this browser
Searches ending in an order rose from 18 % to 20.8 %, 2.8 of the 4 points the target asked for, so the grade is 0.70. Searches with no results fell from 9 % to 6.5 %, half of the way to 4 %: 0.50. The median time reached its target: 1.00. The objective’s grade is their average, 0.73. Press Edit, change the first key result’s end value to 22.0 and run it again: the objective then scores 0.83.
The guide calls the 60–70 % range “the sweet spot”, and says that someone who fully reaches their objectives every time is not setting them ambitiously enough. The program’s second part reads two teams’ last three quarters that way. Over several quarters, the pattern of grades says what to change:
| Grades over several quarters | What they say | For next quarter |
|---|---|---|
| Around 0.6 to 0.7 | Ambitious targets, mostly reached | Keep the same level of ambition |
| 1.0 every time | Targets the team was sure to reach | Set one the team is not sure it can reach |
| One key result near 0.0 | Its number did not move | Ask whether the work was done, and whether it was the right work |
Grades describe goals, not people. The guide says that OKRs “are not synonymous with performance evaluation”; if the grades decided pay or ratings, every team’s safest choice would be targets it was sure to reach.
Grading the work instead of the number
Wrong: “We launched the filters, so that key result scores 1.0.” The launch was the work, not the result. Right: grade the number. Searches ending in an order went from 18 % to 20.8 % against a target of 22 %, so the key result scores 0.70, however much was built.
Checkpoint
Check: Grading key results from 0.0 to 1.0
A goal becomes a plan with bets, owners, risks and a weekly check
The activities of the first draft were not wrong; they were in the wrong place. In the plan they come back as bets, each tied to the key result it should move, with one owner, a date, the risk that could stop it and a number to check every week. Step through the search team’s plan:
The drawing shows the whole scene; its 7 steps are listed below.
Every step as text
- The objective. The search team of an invented grocery app writes one objective for the quarter: make search the fastest way to fill a basket. It says where to go, in words a customer would understand, and it carries no number yet.
- Three key results. Three numbers say whether the objective is being reached: searches that end in an order, from 18 % to 22 %; searches with no results, from 9 % to 4 %; and the median time from a first search to a filled basket, from 41 to 30 seconds.
- A bet for each number. The activities of the first draft come back as bets: filters for brand, price and diet for the first number, spelling correction for the second, a faster search index for the third. Each bet is a guess about what will move its number.
- One owner for each bet. Every bet gets one owner and a date for its first version. When a date slips, the team knows at once who to ask, and nobody waits for a meeting to learn who decides.
- What could stop a bet. Each bet names what could stop it. The filters need diet tags that a third of the products lack, so the catalogue team becomes a dependency of the plan, with its own date: tags filled by week 4.
- The weekly check. Every week the team puts each number beside a straight line from its start to its target. Week 6 of a 13-week quarter is about halfway, so a number that has not moved by then is off track.
- Change the bet, keep the target. By week 6, spelling correction has cut searches with no results only from 9 % to 8 %. The team keeps the target and changes the bet: it adds a list of common other names for products, such as courgette for zucchini.
Written as a table, the first plan fits on one screen:
| Key result | First bet | Owner | Risk, and its early sign |
|---|---|---|---|
| Orders from searches: 18 → 22 % | Filters for brand, price and diet | Search lead | Diet tags missing on a third of products; not all filled by week 4 |
| No-result searches: 9 → 4 % | Spelling correction | Search engineer | Misspellings are not the main cause; the number still flat in week 6 |
| Search to basket: 41 → 30 s | A faster search index | Platform engineer | The new index slips; not live by week 5 |
The weekly check puts each number beside a straight line from its start to its target. A number that has not moved by week 6 of a 13-week quarter is off track (MySmartCoPilot’s rule of thumb). Then the team changes the bet, not the target: a target moved in the middle of the quarter teaches everyone that targets bend. An execution answer in an interview ends the same way, with what you would check each week and what you would do when a number does not move.
Key idea
Tie every piece of work to the key result it should move, give it one owner and a risk to watch, and check every number weekly: when one stalls, change the bet and keep the target.
Checkpoint
Check: Turning an objective into a plan
Practise: grade an objective
Write the function that turns key-result grades into the objective’s grade, with optional weights, and run the sample tests:
Exercise · Easy · Python
Grade an objective from its key results
An objective's grade is the average of its key results' grades, each between 0.0 and 1.0. Some teams agree before the quarter that one key result counts more than the others, and give each a weight. Write score_objective(grades, weights=None) in objective.py:
gradesis a list of the key results' grades, each from 0.0 to 1.0, both ends included;weights, when given, is a list of one weight per key result; without it, every key result counts the same;- it returns the weighted average, rounded to two decimal places;
- it raises
ValueErrorwhen there are no grades, when a grade is below 0.0 or above 1.0, when the number of weights differs from the number of grades, or when the weights add up to 0 or less.
score_objective([0.7, 0.5, 1.0]) # 0.73: the lesson's search team
score_objective([0.7, 0.5, 1.0], [1, 1, 2]) # 0.8: the third key result counts twiceThe sample tests also check grades of exactly 0.0 and 1.0, a single key result and every kind of bad input.
Starter code · objective.py
def score_objective(grades, weights=None):
"""Return the objective's grade: the weighted average of its key results' grades, rounded to 2 places.
grades: one grade per key result, each from 0.0 to 1.0
weights: one weight per key result, or None to count every key result the same
Raises ValueError for no grades, a grade outside 0.0 to 1.0, a wrong number of weights, or weights adding up to 0
or less.
"""
# Your code here.
return 0.0The sample tests · test_objective.py
from objective import score_objective
def test_equal_weights():
"""the search team: 0.70, 0.50 and 1.00 average to 0.73"""
assert score_objective([0.7, 0.5, 1.0]) == 0.73
def test_a_weight_counts_more():
"""the third key result counts twice: (0.7 + 0.5 + 2 x 1.0) / 4"""
assert score_objective([0.7, 0.5, 1.0], [1, 1, 2]) == 0.8
def test_both_ends_are_grades():
"""0.0 and 1.0 are grades too, not errors"""
assert score_objective([0.0, 1.0]) == 0.5
def test_one_key_result():
"""an objective with one key result is graded by it"""
assert score_objective([0.45]) == 0.45
def test_grade_above_one():
"""1.2 is not a grade: a team that beat its target still scores 1.0"""
try:
score_objective([0.6, 1.2])
except ValueError:
pass
else:
assert False, "expected a ValueError for a grade above 1.0"
def test_grade_below_zero():
"""a number that went the wrong way grades 0.0, never less"""
try:
score_objective([-0.1, 0.8])
except ValueError:
pass
else:
assert False, "expected a ValueError for a grade below 0.0"
def test_no_grades():
"""an objective without key results cannot be graded"""
try:
score_objective([])
except ValueError:
pass
else:
assert False, "expected a ValueError for an empty list"
def test_wrong_number_of_weights():
"""one weight for each key result"""
try:
score_objective([0.6, 0.8], [1])
except ValueError:
pass
else:
assert False, "expected a ValueError for one weight and two grades"
def test_weights_that_add_up_to_zero():
"""weights of 0 leave nothing to divide by"""
try:
score_objective([0.6, 0.8], [0, 0])
except ValueError:
pass
else:
assert False, "expected a ValueError for weights adding up to 0"A hint
Check the input before any arithmetic: an empty list, each grade against 0.0 and 1.0, then the weights. Without weights, use a weight of 1 for every grade. The average is the sum of each grade times its weight, divided by the sum of the weights; round only the result.
Results of the sample tests
| Test | Result | Details |
|---|
What your code printed
The sample tests run on this device, in your browser (Pyodide): nothing is sent to mysmartcopilot.com. The first run downloads Python (about 13.5 MB), which is kept for the next runs. A check in your browser is feedback for you, not proof that the code is right for every input.
Then take the self-check. It begins with whichever idea your answers so far show as weakest, and it asks one question at a time:
Practice that adapts to you
Practise this lesson
12 questions about 4 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.
Interview questions
These three questions start from a goal. The warm-up is answered in full below. For the two after it, say your objective, your key results and your first plan out loud before you open the first step and the follow-ups:
Model answers open with any pass: ₹79 for 1 week ($2.99), one payment that never renews.
-
Fresher to mid · Warm-up
What makes a key result different from a task?
A task is something the team does; a key result is a change the team wants to see, measured by a number. "Launch new search filters" is a task: the team can finish it and customers may notice nothing. "Raise the share of searches that end in an order from 18 % to 22 % by the end of the quarter" is a key result: it has a start value, a target and a deadline, and it moves only if customers behave differently. Google's re:Work guide puts it as key results describing outcomes, not activities, and being easy to grade with a number. The tasks still matter: they become the plan, each tied to the key result it should move, so that a task that is finished but moves nothing shows up as a wrong bet rather than as success.
-
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.
-
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?
Flashcards · 7 cards
Recall it, then check
Say the answer to yourself before you look: recalling it is what makes it stick.
-
How does an execution question differ from a product sense question?
A product sense question asks you to choose the users, the problem and the solution. An execution question takes the product and its direction as given and asks how you would get results from them.
-
What are the five families of execution questions?
Goals, priorities, deadlines and launches, problems as they come (a key metric falling overnight, for instance) and working with others (design and engineering disagreeing, for instance).
-
What is an OKR?
An objective, which says where the team is going and may feel uncomfortably ambitious, with around three key results, each a number with a start, a target and a deadline. Key results describe outcomes, not activities.
-
How do you tell a key result from an activity?
Ask whether the team could finish the work while the number stays where it was. 'Launch filters' is an activity; 'raise searches that end in an order from 18 % to 22 %' is a key result, because it moves only when customers behave differently.
-
How is a key result graded, and how is its objective graded?
From 0.0 to 1.0, here by the share of the distance covered from start to target: 18 % to 20.8 % against a target of 22 % scores 0.70. The objective's grade is roughly the average of its key results, 0.73 for 0.70, 0.50 and 1.00.
-
What does it mean if a team scores 1.0 on its OKRs every quarter?
Its targets were safe. Grades of around 0.6 to 0.7 suggest ambitious targets mostly reached. Grades describe goals, not people: if they set pay, every team would choose targets it was sure to hit.
-
How does an objective become a first plan?
Each piece of work becomes a bet tied to the key result it should move, with one owner, a date, a risk with its early sign, and a number checked each week against a straight line from start to target. A number still flat in week 6 of 13 is off track: change the bet and keep the target.
Key takeaways
- Execution questions take the product and its direction as given and ask how you would get results: goals, priorities, deadlines, problems as they come and work with other people.
- An objective says where the team is going; each key result is a number with a start, a target and a deadline that moves only when customers’ behaviour moves.
- Key results are graded from 0.0 to 1.0 and averaged: the search team’s 0.70, 0.50 and 1.00 make 0.73, close to the 60–70 % that the re:Work guide calls the sweet spot.
- A team that reaches 1.0 every quarter is setting safe targets, and grades describe goals, not people.
- A plan ties each bet to a key result, with one owner, a risk and a weekly check; when a number stalls, change the bet and keep the target.
Terms in this lesson
- key result
- A number that shows whether an objective is being reached, with a start value, a target and a deadline, such as searches that end in an order rising from 18 % to 22 % by the quarter's end. It measures an outcome, not an activity.
- OKR (objectives and key results)
- A way to set goals: an objective says in words where a team wants to go in a period such as a quarter, and around three key results say with numbers how the team will know it got there.
References
- Set goals with OKRs (re:Work guide) (Google re:Work)
- Atlassian product interview handbook (Atlassian)
- Product Manager Interview Prep (Amazon Jobs)
- Interviewing at Google: best practices, advice and tips (Google Careers)
Report a problem with this lesson
Kept only in this browser. Your Learn progress