Christina Anderson is an avid Agile Enthusiast & AgileDad Guest Blogger
One of the most challenging parts about being a Product Owner is working with stakeholders. Why? Because in a perfect world stakeholders would always have a strong technological background and understand the complexities and challenges that come with developing software. Unfortunately, the reality is that most stakeholders live in the business world, and therefore, know very little about the Software Development Lifecycle and what happens once a feature goes “over the wall”. A perfect example of this is when a stakeholder hears the word “automation” and then in turn celebrates— “automatically” thinking that they are now going to get their requested feature done twice as fast. Another example is when a stakeholder requests something seemingly simple, like a label change, only to have the Product Owner tell them that adding that feature will set the release back another two weeks. The stakeholder is shocked and asks, “Why would it take that long? It should be a piece of cake.” What the stakeholder does not understand is that they’re actually asking to change the logical name of the label which requires updating databases, processes, workflows, and even plug-ins—definitely not a quick fix! Stakeholders are also notorious for asking questions such as “can this be done?” Well, in the current world of technology, there isn’t very much that can’t be done. The question lies in whether the stakeholder wants to spend the time and money in order to do it. That is when the Product Owner can step in and avoid what could be a frustrating experience. A good Product Owner will use the following concepts when dealing with stakeholders to help establish a good, solid foundation and a healthy working relationship:
Defines the vision and mission statement of the product with their stakeholders.
Is transparent with their stakeholders and updates them regularly on goals and progress.
Engages with their stakeholders and uses their knowledge and skills to help gather information and helpful insights.
Defining the Vision and Mission Statement:
One of the most important things a Product Owner can do is work with his or her stakeholders and define what the vision and mission statement is of their product. Typically, this is done during an annual Vision and Strategy meeting. It is here that stakeholders from all the departments align and agree upon the same vision and mission statement. These can then be used by the Product Owner as he or she tries to prioritize, delay, or remove requests that come from their stakeholders who probably have different backgrounds, purposes, and agendas. That is why it is so crucial for all the stakeholders to meet, so that even though they all have what they feel is the most important part of the product, they can discuss and make decisions that will be best for the product overall. This is when the Product Owner needs to set boundaries and expectations that even though all requests are “important” to the stakeholders, they may not all be the most “urgent” that need to be addressed. Even if stakeholders may not like it, in the end, it is the Product Owner who is the ultimate decision maker, and when all the stakeholders agree upon a unified vision and mission statement, it helps the Product Owner as they have to accept or reject ideas that do not align. In essence, it empowers the Product Owner to be able to say “No” to a stakeholder – especially when he or she can fall back to the statement that all the stakeholders agreed upon in the first place.
Creating Transparency and Trust:
Transparency is a key component for a Product Owner because it develops trust between themselves and their stakeholders. Transparency begins with accurate reporting and communication. This is typically done in the form of burn-up charts, roadmaps, and Sprint Reviews. These types of communication help alleviate the common problem of unrealistic expectations and deadlines. Too often, stakeholders think as soon as they tell the Product Owner what they want to see in the product, that it is going to magically appear in the next Review and Demo meeting. That is why it is such a complicated balance for the Product Owner to communicate the outcome of a product with their stakeholders because it may not always be what they want to hear. If the Product Owner continues to collaborate with his or her stakeholders throughout the life of the product, that transparency will show the stakeholders that the Product Owner will always be upfront and honest. The Review and Demo meeting is not the right time for a stakeholder to find out that their request did not make it into the sprint. Surprises rarely ever end well which is why transparency is key between the Product Owner and the stakeholders because the worst thing that a Product Owner can do is listen to an idea from a stakeholder, and then never follow-up with that stakeholder again. It not only destroys trust, it also makes it that much harder to work with that stakeholder in the future, and gleaning information and insight from their stakeholders is imperative for a Product Owner.
Engaging and Conceptualizing:
A Product Owner’s ability to engage with his or her stakeholders goes hand in hand with being transparent. Stakeholders may want to engage with the development team more than a Product Owner would like them to. Stakeholders should never be in a meeting where the development team is making their estimates, for example, because the last thing a Product Owner would want is a stakeholder to question the validity of each and every estimation given by the development team, or to try to sway the development team to lower their estimates to get the product out sooner. That doesn’t mean, however, that a Product Owner cannot engage with his or her stakeholders in their own meeting and give them the opportunity to discuss priorities and come up with their own consensus using a method such as “Fist to Five”. It is important for stakeholders to see that their idea is just one of hundreds of ideas that the Product Owner must shift through during the ideation stage of the SDLC. Stakeholders need to understand that the Product Owner cannot, and should not, include every idea that is given to them in the backlog. For one, it would create an infinite backlog with no hope of ever getting the product delivered. For another, including every idea, not understanding the technical implications, could mean that idea directly contradicts or undoes another idea, or could break the system altogether. That is why constant engagement is crucial between a Product Owner and their stakeholders. It could easily be argued that a Product Owner can never over-engage with his or her stakeholders.
To say that the Product Owner has one of the most challenging and difficult roles in the Agile Process would be an understatement. That is why using the concepts explained above, creating a vision and mission statement, creating transparency, and engaging with stakeholders, can help promote a positive and healthy relationship between a Product Owner and their stakeholders. Even though being a Product Owner may be the toughest job on the team, it can also be the most rewarding because when a Product Owner does their job well, the end result is not only a quality and viable end product, but happy and content stakeholders who can’t wait to get started on the next product with their “Rockstar” Product Owner.