Product Owner

Map of the Fredrick Half-Marathon

A product roadmap is a powerful tool.  Roadmaps help link products and services to the strategy, objectives and key results.  Roadmaps are directional, answer the question of where we are going and why.  Roadmaps are powerful – unless they are messed up!  There are four common mistakes that will reduce the value of a roadmap. (more…)

A Roadmap Provides Direction

Product roadmaps are a tool used to visually present an approach to translating a business strategy into the real world. The visualization of the impact of a strategy on a product allows all relevant constituencies to grasp how a product and its enablers are intended to evolve.  

In order to create and use product roadmaps, there are several key concepts and components that need to be agreed upon.   (more…)


The product owner (PO) role is incredibly important in any Agile effort. The product owner leads, manages and prioritizes the backlog and networks with stakeholders, customers, and developers of all stripes.  All sorts of problems can beset the role. However, most of those problems are either self-inflicted or a result of poor organizational design.  A laundry list of problems based on observation and responses from other product owners include:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The next set of difficulties are: (more…)

Ill-defined Roles Block The Elevator!

As I considered the intricacies and difficulties of the Product Owner role, I was concerned that my perceptions might not be as inclusive as possible. In order to expand my understanding of the role and to test my experiences, I asked over fifty product owners why they thought the role was hard.  The majority responded and I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  Part of the difficulty is a reflection of information asymmetries, other difficulties arise because of how we use words or who is assigned to be product owners.  The next two of most common reasons the product owner role is difficult are: (more…)


Organizational culture is a reflection of the beliefs, ideologies, policies, and practices of an organization. Culture is important because it guides what and how work gets done. Team culture, in Agile, in addition to being influenced by the organization’s culture is heavily influenced by the product owner’s interpretation of the organization’s culture.


The product owner role is anything but boring.

The product owner role is anything but boring.

The role of the product owner is incredibly important. The decision-making role of a product owner helps grease the skids for the team so that they deliver value efficiently and effectively. That said, there is more to the role than making decisions. In the survey of practioners (Agile Roles: What does a product owner do?) the next four items were:

      1. Attends Scrum meetings
      2. Prioritizes the user stories (and backlog)
      3. Grooms backlog
      4. Defines product vision and features

The product owner is a core member of the team. Participating in the Scrum meetings ensures that the voice of the customer is woven into all levels of planning and is not just a hurdle to be surmounted in a demo. When I was taught Scrum, the participation of the product owner was optional at the daily stand-up, in the retrospective and in more technical parts of sprint planning. Experience has taught me that optional typically translates to not present, and not present translates into defects and rework. Note, on the original list #15 was buy the pizza. I think the Scrum meetings are a good place to occasionally spring for pizza or DONUTS.

The backlog is “owned” by the product owner. The product owner prioritizes the backlog based on interaction with the whole team and other stakeholders. There are many techniques for prioritizing the backlog, ranging from business value, technical complexity, and the squeaky wheel (usually not a good method). Regardless of the method the final prioritization is delivered by the product owner.

As projects progress the backlog evolves. That evolution reflects new stories, new knowledge about the business problem, changes in the implementation approach and the need to break stories into smaller components. The process for making sure stories are well-formed, granular enough to complete and have acceptance criteria is story grooming. Grooming is often a small team affair, however typically the product owner is part of the grooming team. Techniques like the Three Amigos are useful for structuring the grooming approach.

Product owner interprets the sponsor’s (the person with the checkbook and political capital to authorize the project) vision by providing the team with the product vision. The product vision represents the purpose or motivation for the project. Until the project is delivered a vision is the picture that anyone involved with the project should be able to describe. Delivering the vision and vision for the features is a leadership role that helps teams decide on how to deliver a function. Knowing where the project needs to end up provides the team with knowledge that supports making technical decisions.

The product owner is leader, do’er, a visionary and a team member. As the voice of the customer the product owner describes the value proposition for the project from the business’ point of view. As part of the team the product owner interprets and synthesizes information from other team members and outside stakeholders. This is reflected in decision and priorities that shape the project and the value it delivers.



One on the product owner's roles is to buy the pizza (or the sushi!)

One of the product owner’s roles is to buy the pizza (or the sushi!)

The product owner role, one of the three identified in Scrum, is deceptively simple. The product owner is the voice of the customer; a conduit to bring business knowledge into the team. The perceived (the word perceived is important) simplicity of the role leads to a wide range of interpretations. Deconstructing the voice of the customer a bit further yields tasks and activities that include defining what needs to be delivered, dynamically providing answers and feedback to the team and prioritizing the backlog. I recently asked a number of product owners, Scrum masters and process improvement personnel for a list of the four activities that product owner was responsible for. The list (ranked by the number of responses, but without censorship) is shown below:

      1. Makes decisions
      2. Attends Scrum meetings
      3. Prioritizes the user stories (and backlog)
      4. Grooms backlog
      5. Defines product vision and features
      6. Accepts or rejects work
      7. Plans for releases
      8. Involves stakeholders (included customers, users, executives, SMEs)
      9. Sells the project
      10. Trains the business
      11. Buys pizza
      12. Provides the project budget
      13. Tests features
      14. Shares the feature list with business
      15. Generates team consensus

The #1 activity of the product owner is to make decisions. Decisions are a critical input for all project teams. Projects are a reflection of a nearly continuous stream of decisions. Decisions that if not made by the right person could take a project off course. While not all decisions made by a team rise to the level of needing input from product owner, or even more importantly rise to the level of needing immediate input from a product owner, when needed the product owner needs to be available and ready to make the tough calls that are needed.

In the first major technology project I was involved with my company decided to shift from one computer platform to another. It was a big deal. In our first attempt the IT department attempted to manage the process without interacting with the business (I was the business). That first attempt at a conversion was . . . exciting. I learned a number of new poignant phrases in several Eastern European languages. The second time around, a business lead was appointed to act as the voice of the business and to coordinate business involvement. The business lead spent at least ½ the day with the project team and 1/2 in the business. Leads from all departments and project teams involved in the project met daily to review progress and issues (sort of Scrum of Scrums back in 1979). The ability to meet, talk and make decisions was critical for delivering the functionality needed by the business.

Making decisions isn’t the only task that product owners are called on to perform, but it is one of a very few that almost everyone can agree upon. Although buying pizza would have been higher up my list!

What would you add to the list? Which do you disagree with?

Listen to the Software Process and Measurement Cast

Subscribe to the Software Process and Measurement Cast on ITunes

The Software Process and Measurement Cast our essay on product owners.  The role of the product owner is one of the hardest to implement when embracing Agile. However how the role of the product owner is implemented is often a clear determinant of success with Agile.  The ideas in our essay can help you get it right.

We will also have a new column from the Software Sensei, Kim Pries. In this installment Kim discusses the fact that are numerous ways go get something done when writing code.  Some are the right way and some are wrong way. For example, are you willing to sacrifice clarity for cool or fast?

We also continue with Jo Ann Sweeney’s column Explaining Communication. In this installment Jo Ann addresses why knowing who your audiences and stakeholders are will help make your communication more efficient and effective! Visit Jo Ann’s website at and let her know what you think of her new column.


In the next Software Process and Measurement Cast we will feature our Interview with Steve Tendon.  Steve has been a regular on the podcast in the past but took a break to   hone his ideas on hyper-productive knowledge work.  We discussed his new book Tame The Flow: Hyper-Productive Knowledge-Work Management published J Ross and how teams can raise their game to deliver results that not only raise the bar but jump over it


Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

3-15 2013 log reigndeer

We use proxies in many situations. My neighbors recently provided a humorous example of a proxy. They decided to build a diorama of log reindeer after they could not induce the local deer to hang out in their front yard and pose. Perhaps because I let the dog out to bark at the real deer. The log deer erected were a proxy for real deer and, in this case, not only will the proxy suffice but they might be better for neighborhood peace.

Naming a proxy for a product owner in an agile project will be far less satisfactory than a herd of log reindeer. A product owner acts as the Voice of the Customer channeling information about how the product will be used to the project team. This information is critical for the team to maximize the value of what they are building. Product owners also provide the team with priorities and decisions based on their knowledge of the business environment. The further the person acting as the product owner is from the financial responsibility (profit and loss) for the product or the day-to-day operations that use the product the lower the fidelity of the information he or she can provide. Poor information or slower decisions will yield lower value to the organization regardless of what is being built. While a proxy product owner might not be a log reindeer, the further they are from the business the more apt you will be to get termites rather than the answers your agile project team needs.