By search term

By author
  • Practice
  • Opinions

Agile Product Ownership

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, 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. 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).

Image source: Discover to Deliver: Agile Product Planning and Analysis by Gottesdiener and Gorman.

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.

1. 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.

2. Build Empathy for Your Customer.

Great agile product owners share with their teams what they 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

Image source: Discover to Deliver: Agile Product Planning and Analysis by Gottesdiener and Gorman.

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.

8. 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.

9. 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.


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.

Comments (1)

  • From: Matthias Brenner
  • Date: 12. February 2015

Thank you for this perfect definition of my dream job.
Currently working within a partly-agile project, I focus on parts of that you've described within this article, namely the customer collaboration, definition of the Product Roadmap and being the main point of contact for questions regarding functional and business oriented aspects of the project. Other responsibilities you've described lie in the hands of other roles within the project.
I totally agree in your opinion that for being (more) successful, having Product Owner that follows your definition would help our project in a lot of ways.
Fulfilling all of those requirements is surely challenging and takes a lot of real passion for the product being developed, but I consider being this type of a Product Owner a profession that is exciting (almost) each and every day.

Best regards and once again thank you for this inspiration, Matthias Brenner

Author's profile
Related Articles
RE for Testers

Why Testers should have a closer look into Requirements Engineering

Read Article
Product Owner in Scrum

State of the discussion: Requirements Engineering and Product Owner in Scrum

Read Article
Toward Better RE

The Main Thing is Keeping the Main Thing
the Main Thing

Read Article