4 exercises — responding to "everything is P1", handling conflicting priorities, escalating priority conflicts between stakeholders, and making the case for a priority change.
0 / 4 completed
1 / 4
Your PM says: "Everything on the backlog is P1. Can you just do all of it?" How do you respond?
Option C responds to the "everything is P1" problem by:
1. Acknowledging the legitimacy of each item: "every item matters" — not dismissive 2. Making the capacity constraint concrete: "3–4 items per sprint" and "12 items = ~6 sprints" — translates backlog volume into time so the PM sees the trade-off 3. Proposing a collaborative prioritisation process: "rank by business impact + dev effort" — structured, fast, and brings both parties' expertise 4. Creating a positive outcome: "commit to the top tier with confidence" — the PM gets certainty on the most important items
Why A fails: "We'll try" without a plan leads to all 12 items starting and none finishing
Why B fails: "Can't do everything" is a refusal without a path forward
Why D fails: "I need you to prioritise for me" puts the problem back on the PM without any value added from the engineer
2 / 4
A PM asks you to drop your current security fix and start a new UX feature immediately. How do you handle this conflicting priority?
Option C handles a conflicting priority request professionally:
1. Flags the consequence of switching, not just the inconvenience: "active SQL injection vulnerability unpatched for 24–48 hours" — connects the task switch to a real, specific risk 2. Returns the decision to the PM with full information: "Is the UX feature launch-blocking in a way that outweighs that risk?" — the PM is now making an informed decision, not an uninformed one 3. States the consequence if they say yes: "I'll switch and note the ticket as openly vulnerable" — no passive aggression; just transparency 4. Offers a compromise if they say no: "finish by end of day, start tomorrow" — reasonable, concrete, likely acceptable
Why A fails: Switching without flagging leaves a security vulnerability unpatched with no stakeholder awareness Why B fails: Refusal without reasoning Why D fails: Escalation when a simple conversation would resolve it — looks like avoidance
3 / 4
Two senior stakeholders disagree on the priority of two projects and are both asking your team to start immediately. How do you respond?
Option C escalates a prioritisation conflict professionally:
1. Names the structural problem: "both projects have been flagged as highest priority" — makes the conflict explicit without blaming either stakeholder 2. Quantifies the cost of multitasking: "both take approximately 3× longer" — not a guess; reflects the real cost of context-switching at team level 3. Refuses to make the decision unilaterally: "rather than my team deciding" — correctly identifies that priority decisions belong with the stakeholders who own the business context 4. Offers to support the decision process: "one-page brief with impact and timeline" — adds value instead of just escalating the problem
Why A fails: Passive — waits for them to resolve it when they may not even know the conflict exists
Why B fails: "Work on both" looks productive but actually slows both projects
Why D fails: Seniority is not a legitimate prioritisation criterion; it causes the more senior person's preferences to always win regardless of business value
4 / 4
You think the current sprint's top-priority feature is wrong — there's a critical infrastructure item that will block three future sprints if not addressed now. How do you raise this?
Option B is a strong priority challenge because it:
1. Names the specific ticket: "INF-112" — concrete, not vague 2. Names the downstream blockers specifically: Sprint 15 auth refactor, Sprint 16 notifications, Sprint 17 mobile API — not "it will cause problems later" but specific future tickets 3. Quantifies the cost of deferral: "6–9 days of avoidable blocked time" — business-language framing of a technical risk 4. Quantifies the cost of the fix: "3 days of work" — so the audience can compare 3 days now vs. 6–9 days later 5. Scopes the ask correctly: "one-time priority bump — not a permanent change" — shows you understand the concern about precedent-setting 6. Asks appropriately: "Could we discuss this in sprint planning?" — the right venue
Why C fails: Bare assertion without reasoning
Why D fails: Doing work without agreement is a classic scope/trust violation — even if the technical call is correct