Splitting scarce engineering capacity across competing projects: a prioritization story
Company: Amazon
Role: Product Manager
Category: Behavioral & Leadership
Difficulty: medium
Interview Round: Other
Describe a time when several projects were competing for the same limited engineering capacity. How did you decide which work got the engineers, and what happened as a result?
```hint Show the rule, not just the call
Choose a case where each side had a fair claim to the engineers, and be ready to explain the criteria and evidence that settled it, and what you did about the work that lost.
```
### Clarifying Questions
- Should the story be about splitting engineers between projects you owned, or about competing with other teams' requests for a shared engineering group?
- Does the interviewer want one specific allocation decision, or how you ran prioritization as a recurring process, such as each planning cycle?
- Is a story acceptable where the allocation later proved wrong, if I can explain what I changed afterwards?
### What a Strong Answer Covers
- A situation with real scarcity: the competing projects, who wanted each, and the engineering capacity actually available
- An explicit prioritization method grounded in customer impact, business value, effort, risk and dependencies, with the data used
- How the candidate aligned engineering leads and stakeholders, including disagreement and the owners of the projects that lost
- What was delivered and measured, and what happened to the deprioritized work
- Reflection on what the candidate would do differently and how the approach was reused
### Follow-up Questions
- A senior stakeholder whose project you deprioritized escalates to your manager. What do you do?
- How were the engineering estimates produced, and what did you do when one turned out to be wrong?
- Knowing how things turned out, would you make the same allocation again?
Overview: A behavioral product manager question from an Amazon interview about a time when several projects competed for the same limited engineering capacity. It tests how you set prioritization criteria, ground the trade-off in data, align engineers and stakeholders, and own the consequences for the work you deprioritized.