In Scrum, the Product Owner’s purpose is to maximize the value of the Scrum Team’s work (the product). Delivering value to the customer (beneficial customer outcomes) is the ultimate measure of success for the Scrum Team, including the Product Owner. (Pssst … you can learn more about measuring customer outcomes by signing up for Rebel Scrum’s Evidence-Based Management course.)
We can only measure customer value after we have released the product. Until then, the value we envision is merely a hypothesis. How does the Product Owner seek to maximize value if that’s the case?
There are many methods at our disposal. As Product Owners, we can use our experienced judgement to think about what might be of most value. We can consult with Developers on the Scrum Team for ideas. We can conduct customer interviews or surveys. Each method has strengths and weaknesses.
Additionally, we can gather stakeholder input.
What is a stakeholder?
Stakeholders are people who have some kind of interest in the product the Scrum Team is delivering. They can be internal developers, leaders or customers. They might include providers or government regulators. They can also be customers, influencers, users, buyers, business partners or suppliers.
The benefit of stakeholder engagement
Stakeholders can provide early input and insights that can go a long way to help us, as the Product Owner, improve the product’s value. We can engage stakeholders to:
Gain a deeper understanding of customer needs and preferences.
Build product support and buy-in.
Obtain unique insights and perspectives to inform decisions.
Prioritize the most highly valued features and requirements.
Align the product vision with stakeholder expectations.
Facilitate collaboration and communication.
Ensure the product meets the needs of all relevant parties.
The perils of ignoring stakeholder engagement
Ignoring stakeholder input can have several negative impacts, including:
Decreased stakeholder buy-in: When stakeholders feel no one cares about their input, they may become less invested in the project or decision, ultimately leading to reduced buy-in and support.
Reduced trust: Ignoring stakeholder input can erode trust with stakeholders as they may feel disrespected that we have undervalued their opinions and concerns.
Missed opportunities: Stakeholders often have valuable insights, perspectives, or information that decision-makers are unaware of, and ignoring their input could result in missed opportunities or blind spots that could negatively impact the project.
Increased conflict: When stakeholders feel that their concerns and opinions are not being heard or addressed, it can lead to tension and disagreements that can be difficult to resolve.
Negative publicity: Feeling disgruntled about being ignored, stakeholders might voice their discontent publicly, which can lead to negative publicity for the project or organization.
Ignoring stakeholder input is like leaving money on the table. Stakeholder buy-in, collaboration and trust are critical to the product’s success.
Use judgment
Star Wars Episode VI – Return of the Jedi.
While it is wise to consider stakeholder input, the Product Owner is ultimately accountable for the product’s success and the Product Backlog’s content and order. As the Product Owner, we must avoid abdicating our responsibility by using our judgment to decide what input to accept and reject. (See our recent article Why “no” is part of a Scrum Product Owner’s love language for more on this.) Some customers may be unable to pinpoint what they need, and others may not be close enough to the product to know how the people we’re building it for will actually use it. (See our recent article Spain, Trains, and Incremental Delivery for a painful example of a misunderstanding of real-world customer needs.)
As Product Owners, we must consider stakeholder input in the context of each stakeholder’s interest level and influence or power over the product’s success. Consider the following graph, which juxtaposes the stakeholder’s level of power or influence with their interest in the product.
We might manage stakeholders with high influence and power over the product’s success differently than stakeholders with low interest and power.
For example, we might weigh feedback from high-interest-high power customers or governing bodies more heavily than casual feedback from a member of the general public or layperson. The Product Owner must consider all of this information—from the stakeholders’ power and interest to the quality of their feedback—when considering what input to use while crafting the product strategy or updating the Product Backlog. At the same time, we must use our judgment and understand that good ideas can come from anywhere, and bad ideas can come from everywhere; just because it comes from an important customer’s stakeholder doesn’t mean it’s a stellar idea.
How to engage with stakeholders
How we engage with stakeholders will vary depending upon the environment, but following is a general process to follow:
Identify stakeholders: Include individuals or groups directly affected by the product or who have a vested interest in the outcome. Ask the Developers or leaders involved in supporting the product to help identify whom to include. Keep the list for future reference. Assess each stakeholder’s level of interest and influence in the product.
Determine their needs and interests: Once we have identified the stakeholders, it is essential to understand their needs and interests. We can do this through surveys, focus groups, interviews, or regular stakeholder group meetings.
Communicate clearly and regularly: Staying in touch with stakeholders is essential. This can include providing updates, seeking feedback, and addressing concerns. We may even choose to share a high-level product roadmap, but do so with caution as the roadmap contains our plans, and we don’t want that falling into the hands of a competitor.
Use multiple engagement methods: Stakeholders may have different preferences for how they want to engage. There are numerous engagement methods, such as online surveys, town hall meetings, workshops, and one-on-one meetings for key stakeholders. If that sounds like a lot of work, remember that we can delegate this work and add it to the Product Backlog. Like everything else, we need to determine how much value this work adds to our product, ordering our Product Backlog accordingly.
Follow up and close the loop: If we receive feedback from stakeholders, we need to inform them how valuable their input is by telling them when we have changed the direction of the product as a result.
Conclusion
When using the Scrum framework, delivering value to the customer (providing beneficial customer outcomes) is the ultimate measure of success. As the Product Owner, our job is to maximize the value we deliver to the customer every Sprint. It’s impossible to do that without engaging the product’s stakeholders. Not only can stakeholders help us determine if we’ve delivered what we set out to, but they can also provide valuable information to guide our next steps. Getting input early and often will help us build a better product.