By Sheyinka Harry
As the liaison between the business/customer and the team, the Product Owner is innately responsible for creating the Product Vision and Mission, as well as the resulting Product Backlog. When creating these artifacts, Product Owners spend a great portion of their time in meetings with:
- The stakeholders to capture their needs;
- The Team to ensure the Product Backlog items are clear and understood; and
- The actual customers to validate the correct thing is being developed.
Because of these meetings, many would consider this role to be the most demanding on the Agile Team, and they may very well be correct. There is a great deal riding on the ability of the Product Owner to clearly articulate the needs of the customers, including the ability to provide guidance to the Delivery Team. Asking questions is therefore definitely par for the course, given the degree of elicitation required in these interactions. There are commonplace questions that need to be asked, such as:
- Is my backlog clear?
- What should we work on next?
Then there are the not-so-commonplace – but equally important – questions that often get overlooked. These questions go a long way in ensuring that the right thing is both being built and being built right. Discussed below are some powerful questions Product Owners should be asking in their interactions with their stakeholders, customers, and teams.
To the Stakeholders:
1. What opportunity is this product creating?
Taking a look at the opportunity being created is a great step toward defining the Product Vision Statement. While we may already know the target audience we wish to serve and the product we want to put on the market for them, we may not know which of their needs we are solving. This creates a potential problem, i.e., resources are wasted creating products or services that are not needed. Instead, time could have been spent solving actual pain points and the needs of customers to increase satisfaction and, ultimately, business revenue. How do we do this? We want to zone in on what the actual customer’s needs are, and curate features or functions within the proposed product or service that can solve this existing issue or exploit an opportunity. Yes, we want to be first to market and be quick with innovative solutions, but we need to ensure they are serving a purpose.
2. Where does this new need fall in the grand scheme of things?
We have all had experiences with stakeholders bringing new requests to the team for implementation. Whether these requests are communicated during the Sprint review/ Demo session, or they come in as ad hoc requests during the Sprint, the question still remains, “Where does this new request fall?”. Even when saying “Yes” to a request, it does not mean you can start working on it right away; all requests need to have an associated priority.
When in mid-Sprint, getting a new request reduces the previously allocated and committed time and effort of team members. Therefore, there needs to be a conversation to review the current commitments of the team, and a decision made around what trade offs will be made based on the priority of this new addition. The most common trade off is removing an item of equal or possibly greater effort from the Sprint Backlog.
If this request is made during the Sprint Review, a conversation can be initiated either immediately or in a follow up to discuss where this falls in relation to the planned work for the next Sprint. Is this request of greater importance than the predetermined next steps? Can it wait until a few Sprints down the road?
Knowing the “why” for a piece of work is also beneficial when deciding when or even IF it is implemented. Zeroing in on whether this request is coming from the results of market research, new trends in data, or something that a stakeholder or team member thought about overnight helps with acceptance and prioritization.
To the Team:
1. If our stakeholders were in the room with us, what would they say about this sprint?
This could be a great mid-Sprint or Retrospective check-in for your teams. Whatever the occurrence, asking this question prompts the team to wear a different hat and do an assessment of how well they’re working as a team to meet the Sprint Goal, as well as the quality of what they’re producing. In a Retrospective, this can lead to a discussion around action items for future Sprints to mitigate any unfavorable views that the team perceives may come from stakeholders.
2. How can I help you deliver more value?
Even though the Product Owner doesn’t build the features, the team depends on your ability to maximize the value of the product and the work of the Development Team. There is no better way to help the team deliver more value than asking what they need from you to do so. Doing this will ensure you are providing them with exactly what they need, instead of what you think they need.
3. Does my prioritization help you stay focused?
Product owners have the tricky task of creating synergy in the team through the organization of the Backlog. Having priorities that cause major task switching can create strain on the team. Asking if the current prioritization method helps the team stay focused opens the door for the team to talk about any conflicting priorities you may not know about.
4. Are you clear on why the Backlog is prioritized this way?
The Curse of Knowledge is a bias that most Product Owners unknowingly possess. With this bias, they assume that others have the background information to understand their actions and often neglect to inform the team why they’ve made certain priority choices. On the occasions where they express the why, the reasoning doesn’t always make sense to team members. Having the team clear on the reason for the prioritization goes a long way in getting their buy-in to do the work.
5. Do you have any competing priorities that may keep you away from this work?
Although the Scrum Guide emphasizes the need for a dedicated team, the reality is that it is not always possible. It is therefore crucial to the success of the Sprint and the overall project that any competing priorities be communicated promptly. Having this discussion early with the team can help Product Owners to scope future Sprints and adjust the Product roadmap. With this information, it becomes easier for POs to set expectations with stakeholders and customers, as they can preempt any delays based on the availability of team members.
6. What risks do we face in delivering this product?
The importance of identifying risks early cannot be emphasized enough. Issues that derail projects often live as risks at the beginning of the project. Think back to a time you faced a disaster, then heard someone loudly say, “I knew that was going to happen!” Wouldn’t it have been better to have spoken about it at the beginning? Noting any risks allows Product Owners to have discussions with stakeholders on how to handle them. During these sessions, the identified risks can be:
- Resolved: The issue has been addressed and no longer exists.
- Owned: A member of the group has agreed to either resolve the issue outside of the meeting or oversee its resolution.
- Accepted: The risk cannot be resolved, so it has been discussed, and the team understands and accepts it for what it is.
- Mitigated: The team is moving to formulate a plan to eradicate the risk.
To Customers:
1. Does this product solve your problem?
As Sam Walton, founder of the popular retailers Walmart and Sam’s Club, said, “There is only one boss; the customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else.” With this thought in mind, it is of utmost importance for any customer needs to actually be addressed. The main prerogative should be doing the work needed to get their pain points addressed, and doing this check validates if the product is moving in the right direction.
As you can see, there’s more to be considered when doing the work of a Product Owner. Yes, the North Star we all work toward is correctly communicating the needs of the customer and stakeholders to the team, and providing necessary guidance to get the work done. Getting to that end goal, however, requires deep questioning of all parties involved to ensure that the right thing is being done right. Having these questions in your repertoire works to ensure that all aspects of the process are being considered, and that as that liaison you are empowering your teams to create solutions that actually solve your customers’ problems.
Check out part 1 of the Agile Questions series for Six Powerful Questions Every Agile Team Member Should Ask.