Ranking Rival Feature Requests When the Team Cannot Build Them All

Several features are competing for your team's limited time. How do you decide which ones get built first? ```hint Show the method, then prove it Name the inputs you weigh and how you compare them, but expect to be pushed on a real case: two features that both look urgent, and a stakeholder who disagrees with your call. ``` ### Clarifying Questions - Do you want my general method, or a specific time I had to choose between competing features? - Are the features competing for one team's capacity, or spread across teams with dependencies between them? - Is this for the next sprint, the quarterly roadmap, or a longer horizon? ### What a Strong Answer Covers - Anchoring the choice to a stated product goal or metric before any features are compared. - A consistent way of comparing features with explicit inputs, and an honest view of what that method misses. - How deadlines, dependencies, technical debt and strategic bets that compare poorly are handled. - How stakeholders shape the inputs, how the decision and the cuts are communicated, and how disagreement is resolved. - A concrete example of a hard call, what was not built, and the measured result. ### Follow-up Questions - Your top-ranked item is a small usability fix, but your VP wants a large strategic bet that ranks low. What do you do? - Sales says a major customer will leave without a feature only that customer needs. How does that enter your process? - A feature you ranked low turns out, months later, to have been the one that mattered. What do you change in how you prioritize?