Who finds it easy to say "no" to stakeholder requests? Anyone? I don't see many hands up. We are hardwired to want to help others, and that instinct generally serves the human race well. But, when it comes to stakeholder requests that don't align with the Product Owner's strategy, saying "no" might be the best thing for the product. As the saying goes, sometimes, you must be cruel to be kind.
When to pull out the “no” response
The Product Owner (PO) is responsible for the content and ordering of the Product Backlog items (PBIs). This includes deciding which stakeholder requests to include in the Product Backlog and which to leave out. The PO must consider the impact of each request on the overall goal and vision for the product, as well as the available resources and time constraints.
There are many reasons why a product owner might refuse a stakeholder request, including the following:
- Doesn’t align with the product roadmap or goals: The product owner has a clear vision for the product and doesn’t want to deviate from it.
- Not feasible: It may not be possible to implement the request due to technical or resource constraints or other limitations.
- Not valuable: The PO doesn’t see the value in implementing the request and decides it is not worth the time and effort.
- Too risky: The PO hesitates to take on a request because it carries many risks, such as requiring significant changes to the product with a high likelihood of failure.
- Not a priority: The PO has priorities that take precedence over the request.
The PO should work with stakeholders to understand their needs and priorities and explain the reasoning behind not including specific requests in the Product Backlog. This can help build trust and ensure stakeholders understand the PO’s perspective.
Stakeholders need to understand that the PO has the final say on what goes into the Product Backlog and that the team might be unable to accommodate every request.
Here is why stakeholders should respect the PO’s decision to deny some requests.:
- The product owner is responsible for maximizing the value of the product. They must make difficult decisions about what features and functionality to include or exclude in the product toward that end.
- The PO represents the interests of the stakeholders and the end users of the product. They have a deep understanding of the needs and priorities of these groups, and they use this knowledge to make decisions about what to include in the product.
- The PO is accountable for the success of the product. They are the ones held responsible if the product does not meet the needs of the stakeholders or the end users.
- The PO has the authority to make these decisions. They are ultimately responsible for the product's direction and the Scrum Team's priorities.
Conclusion
Saying “no” to a stakeholder request is never easy because, as humans, we instinctively want to be helpful and accommodating. But agreeing to requests that don’t serve the Product Goal will ultimately displease stakeholders and their end users. Saying “no” while explaining the reasons for denying the request can provide stakeholders with the context that can make the response understandable.
To learn more about the Product Owner accountability in Scrum, signup for Rebel Scrum’s upcoming Professional Scrum Product Owner course. For advanced Product Owners, register for the Advanced Professional Scrum Product Owner course.
To learn more about how to apply Scrum in your unique situation, join us for a day of learning, discussion and activities at this year’s Scrum Day USA, scheduled for September 14, 2023, in Madison, Wisconsin, USA.
