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…)

Advertisements

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…)

Control!

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…)

13655612593_1229e2c6f4_h

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.
(more…)

 

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?

Next Page »