The key to product success is to discover and deliver the right product for the right customers—and to do it at the right time. That doesn’t change when you move to an agile way of working. In fact, appropriately applying the agile mindset amplifies the imperative of eliciting and specifying the right requirements. The goal is to deliver the highest value product needs (requirements) in as short a time as possible.
In an agile or lean project, discovering these requirements is the work of agile product ownership. Product ownership intersects with the disciplines of product management, project management, and business analysis/requirements engineering. Agile and lean teams use different titles for the person in charge of this work, including product owner, product champion, associate product manager, or technical product manager.
Whatever the title, agile product ownership is no small task. Product owners are the champions of the product—and have ultimate accountability for the health and well being of that product. They “own” the jointly derived product vision, must deeply and emphatically understand customer needs, keep a finger on the pulse of changing stakeholder values, and continuously make decisions on what to build (or not), and when. This is true whether the product is sold commercially or is used to operate the business.
This is a tall order. Product owners cannot do this work alone, especially if they also have strategic, customer-facing product management responsibilities. Instead, in many organizations, business analysts, requirements engineers, or testers (or some combination of them) work closely with the product owner, sometimes even taking on tactical or technical product ownership responsibilities (the day-to-day interaction with the delivery team).
Product owners—and the business analysts, requirements engineers, and testers who work with them—who handle the challenge successfully all seem to understand 9 essential practices, which are explained below.
- Put the Ends before the Means.
Agile focuses on value, and delivering the highest value features as soon as possible. To do that effectively, all involved — from the c-suite to the delivery team — need to have their eyes fixed on value. One of the many responsibilities of agile product ownership, and perhaps the most important, is to share, over and over, the vision, goals, and objectives for the product. The best product owners ensure a compelling, clear and cohesive product vision emerges from collaborating cross-functional disciplines.
- Build Empathy for Your Customer.
Great agile product owners share with their delivery teams what they (and their product organization) are learning from competitive intelligence, product and market research, and customer visits. When possible, they invite engineers, testers, user experience experts, and any other members of the delivery team to participate in contextual inquiry by observing actual product users interacting with the product. They may also invite the team to read customer service and complaint emails or sit in as operations or customer service personnel addresses customers’ needs. The idea is to have the team fully experience walking in the customers’ shoes.
- Stand Up.
The best product owners, or those explicitly designated as the tactical “product owners,” attend daily team standups. They don’t consider standups as status meetings, but as daily planning sessions that require facilitative leadership.
- Cozy Up.
Successful product owners make themselves available every day to answer questions about work in progress. They know they are responsible for clarifying acceptance criteria and reviewing prototypes, completed stories, or other evidence of acceptance before the demo. These product owners never wait until the demo to see what the team has accomplished — otherwise they lose opportunities for real-time refinement and suffer potentially embarrassing demo-day surprises.
Great product owners always, always, always attend the team’s demos. Better yet, they facilitate the demo so that customers or proxy customers “test” the completed work. The best take it one step further and invite the world to the demo. In other words, they persuade colleagues from other product areas, technology, operations, support, and so on to attend. They also encourage their delivery teams to invite their colleagues. A standing-room only demo not only showcases the team’s work (and that of the product owner as well) but also demonstrates accountability and invites powerful feedback.
- Fess Up.
Successful product owners are part of their teams, and that includes being part of team retrospectives. They are always ready to give and receive open, honest feedback. They are integral to their teams’ — and their own — learning about the process and product. They are present and they expect retrospectives to be well facilitated, engaging, transparent, and to conclude with one or two specific actions or experiments for improvement or learning.
Some people might argue that retrospectives are only for the delivery team. I disagree. Agile product owners are part of the team — and have a right and an obligation to be there. And remember: retrospectives need to be facilitated by a skilled, neutral facilitator, who can be an agile project facilitator, a coach, or a ScrumMaster from another team.
- Decide How to Decide.
Great product owners never relegate decisions about what features to build and when to the delivery team. They accept that this is their responsibility. They proactively encourage and expect the delivery team to share and express their opinions (hopefully backed by data). Ultimately, however, they know that the decision about what to pull from the product backlog (the living, prioritized list of product requirements) lies with the product owner.
Some product owners choose to explicitly and transparently delegate tactical decision-making to a business analyst, requirements engineer, tester, technical leader, or ScrumMaster (whomever has the right skills and product expertise) when, like many typical product owners, they are overloaded with strategic product management responsibilities. In this case, the delegate is now a tactical product owner. Typically, this is done for near-term product planning: deciding which backlog items to pull into each iteration. At the same time, the best product owners understand that once that responsibility is delegated, they cannot overrule or second-guess the delegate’s decisions; otherwise, the delivery team will quickly lose faith.
- Develop Telescoping Vision
Agile projects don’t attempt to understand or predict all product requirements up front. However, agile product owners still need to sketch out the long view of the product to establish a common focus and marshal organizational resources (people, money, space, governance). From that vantage point, product owners define what to build in each release, and then in each iteration. For large products, they collaborate and rely on product management to do this work.
These three levels — product (and portfolio), release, and iteration — correspond to three views (the Big-View, the Pre-View, and the Now-View) of the product.
The Big-View includes the overall understanding of what the product will be and the sequence of delivery. The Pre-View outlines what product functionality to deliver in a given release, and obtains agreement on the backlog items to deliver in the first few iterations in the release. This is articulated in the release plan. The Now-View (iteration or sprint plan) defines the items the team will deliver in an iteration, or if using Kanban, the work-in-progress.
Successful product owners are able to keep the Big-View in mind, even as they progress through the Pre-View and the Now-View.
- Move in Measurable Inches.
At the Now-View, great product owners think about small, cohesive, high-value product slices. They know they need to create the product inch by inch. They realize that delivery teams need clear, measurable conditions of satisfaction so that they can create the user acceptance tests necessary to ensure that what they deliver is what the customer needs.
- Use Roadmaps as a Guide, but Don’t Pave Them.
At the Big-View, agile product owners use a product management planning and analysis tool called the product roadmap. It is an evolving plan of product releases, with brief descriptions of their themes, features, primary customers (market segment or personas), and anticipated outcomes.
“Evolving” and “over time” are two key points that successful product owners keep in mind. As the product is developed, the roadmap must be revised to include new technologies, emerging opportunities, response to market conditions and customer feedback, team cycle time (or velocity), and new learning. If product owners were to create one roadmap at the beginning of a product’s lifecycle, freeze it, and never stray from the original path, they would miss the chance to continually discover and deliver a product that truly delights their customers.
Agile Product Ownership
Successfully delivering high value products depends on knowledgeable, engaged product owners. At its core, the work of agile product ownership entails one clear and essential mission: steer a team toward a vision, in small steps, with regular stops along the way to check in, learn, adjust, and move forward.
Don’t miss my training in Stockholm in September!
Agile Requirements Analysis and Planning for Product Success, 21-23 September 2015
IMAGE SOURCE: Discover to Deliver: Agile Product Planning and Analysis by Gottesdiener and Gorman.
References
Gottesdiener, Ellen and Mary Gorman. “It’s the Goal Not the Role: The Value of Business Analysis in Scrum. Available at: http://www.agileconnection.com/article/its-goal-not-role-value-business-analysis-scrum.
Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. 2012. EBG Consulting.
Gottesdiener, Ellen. “5 Ways to Recognize a Great Product Manager”. Success with Requirements blog, available at http://ebgconsulting.com/blog/5-ways-to-recognize-a-great-product-manager/
Gottesdiener, Ellen. “Decide How to Decide” Available at: https://www.ebgconsulting.com/Pubs/Articles/DecideHowToDecide-Gottesdiener.pdf
Additional Resources
Cagan, Marty. Inspired: How To Create Products Customers Love. 2008. SVPG Press.
Cohn, Greg. Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams. 2010. Super Star Press.
Larman, Craig and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. 2010. Addison-Wesley.
Pichler, Roman. Agile Product Management with Scrum: Creating Products That Customers Love. 2010. Addison-Wesley.
IMHO one of the most important duties of a product owner is to help the team create a common understanding and to work out the requirements together. It causes often bottlenecks, if the product owner takes the task to define all requirements on his own. In contrast, the product owner should be responsible for the final decision (about questions that cannot be derived logically), but the team should specify collaboratively.
The product owner should bring the entire team (with external stakeholders) together so that they can work out requirements together. Through discussing concrete examples, they acquire a common understanding so that each involved role can work together in parallel. Developers can implement the functionality, testers can create detailed test cases to establish a high coverage, requirements specialists can Illustrating requirements using examples and refining specifications so that the discusses topics are captured. The specifications help the team not to forget details they were talking about.
To work collaboratively as a team within the requirements process, flexible tools can be used that are make it easy to involve non-technical stakeholders. One of such tools is Concordion:
http://concordion.org