How do you manage requirements with multiple stakeholders with conflicting priorities?
Prioritizing requirements always implies resolving requirements with conflicting priorities. At a minimum, you are constrained by available time and resources—forcing you to make both sequencing and selection decisions. You will choose to prioritize some goals first, some that will be addressed later and some that won’t be addressed at all.
From a product management perspective, you're always –hopefully explicitly—making choices about what not to do. That's actually the tough part, articulating a strategy that helps your product stay focused on a particular market, set of problems, set of customers and contexts for use. There is always a temptation to go chase the "shiny object." Good product managers avoid that temptation.
Requirements management doesn't particularly change when you have multiple stakeholders – unless you are the owner, developer, buyer and user, you always have multiple stakeholders. What can change, however, is how you manage the stakeholders.
When you have internal stakeholders with conflicting priorities, reaching a rational agreement about the relative importance of those priorities is your goal. When those stakeholders cannot rationally agree, even including escalation to someone who "owns" the goals of all of the stakeholders, you're in an unhealthy organization— or at least an organization that is unable or unwilling to fix itself.
My personal suggestion, if we were talking over lunch, would be to ask if that's where you want (or have) to work. Assuming you aren't in a toxic environment, what you need to facilitate is a shared understanding of how the different priorities are in conflict, and reach agreement with the involved stakeholders about the resolution.
What can be more difficult is in resolving conflicts between external stakeholders. These can come from balancing the needs of intermediaries in B2B2C domains (selling to businesses who use your products to serve their customers), working with partners to create indirect sales channels (selling to distributors who then sell to end-customers) or even coordinating complex multi-party relationships (e.g. cell phone manufacturers, operating system providers and cellular service providers).
In those situations, you still have to take the same approach, but acknowledge that you may very well have conflicts in objectives that cannot be resolved. In those cases, you have to make tough choices, and choose to neglect some goals (and implicitly the stakeholders that own them) in deference to other goals.
More tactically, you should explore opportunities to kill two birds with one stone—finding a single capability or feature that addresses goals that appear to be, but actually are not, in conflict. Sometimes, the conflict is "manufactured" by picking a solution approach to one goal that is in conflict with another— not that the goals are implicitly in conflict. When you find those situations, you are dodging a bullet. This is one of the reasons that managing a backlog (and roadmap) in terms of goals (requirements) is so important. If you manage in terms of features, or even just capabilities, you reduce your ability to find these synergies.
This was first published in July 2012