Arbitrating Competing Roadmap Requests From Sales and Engineering Teams

A product manager is asked how they decide between the needs of the Sales organization and the needs of Engineering when both are competing for the same limited roadmap capacity. Describe the process you would follow to make that call and how you would bring both groups along with the outcome. ```hint Make the asks comparable A deal-driven feature and a stability or infrastructure request look like apples and oranges. Think about what each one costs the business if it waits another release. ``` ### Clarifying Questions - What do the competing needs look like: a feature Sales wants in order to win or keep particular accounts versus bug, reliability or technical-debt work Engineering wants, or each team's requirements for a new product being planned? - What is the company optimizing for in this period: new revenue, retention of existing customers, or platform stability? - Has anything already been promised, such as a contractual delivery date for a customer or a committed incident fix? - Would you like my general decision process, a real example of applying it, or both? ### What a Strong Answer Covers - Understanding each request before ranking it: who is affected, how valuable or severe it is, how urgent, and how strong the evidence is (a signed deal versus a hopeful pipeline; incident data versus intuition). - A single prioritization lens tied to company goals, such as revenue at stake, customer impact, risk, effort and cost of delay, applied the same way to both teams. - Treating engineering work as having customer and revenue consequences of its own rather than as overhead. - Options beyond a binary choice: reducing scope, sequencing, workarounds, or reserved capacity. - A transparent decision with clear reasoning shared with both leads, and a trigger for revisiting it. ### Follow-up Questions - After you put the Sales feature behind a stability fix, the head of Sales escalates to your manager. What do you do next? - A large deal depends on a feature that Engineering says can only be built quickly by taking on significant technical debt. How do you decide? - How would you keep this same argument from coming back every planning cycle?