The Business Analysis of Agile Product Ownership
I’ve been giving an Agile Product Ownership talk at a few conferences lately and the response has been great. BAs and BA leaders are beginning to see their connection to product ownership functions, but they are also discovering that there is a huge gap in the industry about what product ownership means.
They want to understand the scope of the product owner role, how the role fits in various agile methodologies, and how the product owner and the BA work together. As teams learn more, it is evident that product ownership extends much further than most teams realize.
For example, most agile methodologies place the product owner focus on the backlog, but do not offer guidance on how to build, prioritize, and refine the backlog. Also, some agile methodologies recognize the need for a product vision, roadmap and release plan, but again, offer little guidance on collaborative techniques needed to build these effective tools. Yet this is a HUGE part of the role!
Related Article: Technical Product Ownership
What surprises me most when I work with teams, teach this topic, and present on it is the giant number of teams that do not have a product vision, or teams that create a product vision, but never use it. This bugs me! It ranks near the top of my “How to Work Hard, but Create Crap” list. Without a product vision that is aligned with the organization’s strategy and customer value, we are seriously compromising the money being spent. Is it really possible to have a prioritized backlog without a baseline vision and value proposition?
Product visions provide many benefits. You wouldn’t do a waterfall project without understanding the problem or opportunity or update systems in a large organization without a roadmap that aligns the technical and business strategies? Why would agile be any different?
When your team starts digging into the details of requirements and user stories, they need to see connections to the product vision. They need to understand how their work supports the purpose of the product, the goals of the organization and/or the needs of the end-user. This is true for projects, but it’s also true for enhancements and defect fixes too! Even a backlog of defects and enhancements to an existing internal system can benefit hugely from a product/solution vision.
Whether your team is building a new product or modifying and existing product, you need a product vision. If your team doesn’t have a product vision, here’s what happens:
- The team projects their own ideas and values into the solution.
- The team makes unconscious (sometimes conscious) assumptions and decisions about what the true business problem is.
- The team assumes the user group or requestor has thought through the proposed solution and its impacts, while the user group assumes the team is thinking through it all.
- Ultimately the team creates fixes, enhancements, and solutions that do not meet the needs of the customer and require rework.
You are probably reading this and thinking, “Yes Angela I agree, but my leadership team is not providing this vision information! They only want the solution done yesterday!”
Most leaders I talk to about this scenario tell me that they want their teams to question vision and value, and would rather postpone the date then spend money on something that does not align. Leaders are assuming that if teams don’t ask, then they already understand the vision and strategy. That’s why they get so disappointed when the solution does not deliver the intended value.
Here are some tips to help BAs and Product Owners advocate for the importance of the product vision:
- Highlight lessons learned. If past solutions moved forward without aligning to strategic intent and value, remind your leaders about mistakes, reworks, and defects. Connect with their pain in this, and then explain how you and the team will fix it.
- Create a draft. Create a product vision, write a problem statement, or use a tool like a vision board, product canvas, or business model canvas to confirm your understanding of the context of the product, solution or fix. Discuss how the proposed solution impacts the various areas of the organization.
- Discuss the extremes. Generate dialog or create simple models that help the team think about what an over- or under-engineered solution would look like.
- Prototype. Build a prototype of the design or in-progress solution to get feedback.
Vision discussions throughout the solution lifecycle lead to better requirements, less rework and defects, high-value solutions, and happy end users.
The shared vision/purpose promotes a high-quality decision-making process. We want to avoid making assumptions and decisions for the business owners, and put the right information in front of them to make or delay decisions. Collaborative discussions between the team and the stakeholders, eliminate the blame game. Leaders get what they need to evaluate time/value trade-offs.
How does your team keep requirements and solutions aligned with organization strategy and end user value? Please leave your comments below.