How to answer PM prioritisation interview questions with a real example

First check which kind of question you are answering

A request to describe a time you prioritised competing work calls for an experience-based story. A hypothetical request to prioritise features for an unfamiliar product calls for a case discussion. This page helps with the first. Do not substitute a rehearsed story for a case that asks you to reason through new information.

For your real example, identify the period, the affected users and the capacity or dependency that made the choice necessary. Atlassian's interview handbook emphasises outcomes and decision judgement. The aim here is to give the interviewer enough context to assess your choice without spending the whole answer on the history of the product.

Reconstruct the options before naming a framework

Write down the options that were genuinely available at the time. Include a smaller intervention or a temporary workaround if you considered one. Describe the evidence available then, rather than using hindsight to make the winning option seem obvious. Someone who disagreed should be able to recognise their position as fair.

A prioritisation framework can help organise the comparison, but a score is not a substitute for explaining an assumption. If an estimate was uncertain, say which estimate and why it mattered. If you did not use a scoring model, do not retrofit one for the interview. The story should describe your decision process, not the process you wish you had followed.

• Who needed each option, and for what purpose?
• What capacity, deadline or dependency constrained the work?
• Which evidence was available, and which assumption was uncertain?
• What would be deferred under each option?
• Who could commit the team to the chosen sequence?

Fictional answer example: reliability before a new dashboard

Fictional worked example. The following situation and answer are invented for practice. They are not a Supecoder customer result. A PM's team can address one of two requests in its next release: resolve unreliable exports used by operations, or build a dashboard requested for customer presentations. A manual report is possible, but needs an owner.

'Operations was repeatedly checking exports by hand, while the customer team wanted a dashboard for upcoming presentations. I was responsible for recommending the next release scope. I gathered examples of the export problem and asked engineering to describe the dependency between the export and the dashboard. I compared repairing the export first, building the dashboard first and using a manual report for the presentations.'

'I recommended the export repair with an owned manual report as the interim customer-team option. The dashboard moved to a later review point. The sponsor approved the sequence; engineering owned the technical change. I recorded the deferred request, its owner and what would trigger a review. After release, operations confirmed the repaired workflow worked in its normal process. I can support that observed result, but we did not establish a reliable baseline for time saved. Next time I would confirm that baseline before implementation.'

This answer identifies an alternative, a capacity choice and a bounded outcome. It does not claim that a scoring framework made the decision objective, or that one PM independently made every commitment. The same structure can explain a different choice if your real constraints pointed elsewhere.

Make the opportunity cost explicit

Prioritisation has a consequence for the work that waits. Explain that consequence in practical terms: a customer request remained manual, a discovery activity moved, or a planned feature needed a new date. Then describe how you communicated the choice and the conditions under which it could change.

This is where your answer can become more precise than 'everyone aligned'. Who accepted the consequence? Who remained unconvinced? Who had final authority? If the team committed despite unresolved disagreement, state that accurately. Consensus and a decision are different facts, and neither should be invented to smooth the story.

Prepare for the challenge to your recommendation

Practise the question 'why not the other option?' without dismissing the person who wanted it. A useful answer might acknowledge that the dashboard had value, then explain why a reliability dependency made it a poor next step. If that was only an assumption, say how you tested it or what you would test now.

Also prepare for a changed constraint. What if the deadline moved, capacity increased or the assumed problem disappeared? Your answer should show which part of your reasoning would change. This is a practice exercise, not a prediction of exactly what a particular employer will ask.

• What evidence would have reversed your choice?
• Why was the deferred work still worth doing?
• What did you personally recommend, and who approved it?
• What happened after the decision?
• Which outcome can you support without an invented metric?

Turn your own decision into a usable card

Use the free story template or browser builder to write your context, responsibility, options, choice and outcome. Keep the raw notes before editing them into a short spoken answer. If you cannot explain the alternative, return to the decision rather than adding more confident wording.

The free sample provides a blank editable card and a worked example. The full PM Interview Evidence Kit provides a repeatable evidence bank and six cards for different preparation themes. Choose the full toolkit when you want to organise several stories; one page of careful notes can still be enough to start practising this decision.

Sources and scope

Employer-specific guidance is linked below. This worksheet and its practice examples are original Supecoder editorial material, with no employer affiliation or endorsement.

• Atlassian: product interview handbook
• Atlassian: prioritising ideas and their trade-offs