Product Owners – value and challenges

A key step in product management is to identify the Value Streams in the business.  Then we understand the stages involved in the Value Stream. Then we understand how value is created in the process of a product or feature moving from an idea to delivery to the customer.

Focus on value

We want to ensure that each team delivers the most value for the business.  To do this we must ensure flow in the Value Stream.  We must ensure that the team are always working to optimise the whole value stream end to end, avoiding local optimisation. The team needs to prioritise and work on what is most important at any time. 

No one individual can make all of this happen – it has to be a collaboration.  This collaboration needs to be continuous and ongoing. This has always been central to Agile development.

Business people and developers must work together daily throughout the project.

Principles behind the Agile Manifesto

The developers spend much of their time focussed on the implementation and need someone more focussed on an “outward” view. Someone ensuring the work aligns with the priorities of the value stream, generating customer value

A close link between the business representative and the rest of the team is vital.  This is generally a key part of the “Product” function in the organization.  It is key to ensure that the energy from development is going into maximising the value for the business and avoiding waste.

There is nothing so useless as doing efficiently that which should not be done at all.

Peter F. Drucker

What does the product representative do?

Language matters and ensuring there is a common language around the business is important. We have a piece of language to be resolved here.  As we have seen is a common theme in Agile development, naming is not standard.  What do we call this business contact for the team? 

Scrum uses the term “Product Owner” for this person who works with the team to maximise alignment with business value.  In a classical project, the term “Product Manager” would be more common. Whatever naming you use, you will need to ensure that it is understood around the organization. 

In order to manage a value stream, a Product team needs to perform a range of key activities for the organization.  These include:

  • Research and understand the market. 
  • Propose a strategy to match the business objectives. 
  • Create and communicate a compelling vision. 
  • Manage roadmaps which encapsulate the strategy.
  • Specify individual features for the teams to deliver
  • Work with the teams day to day in optimising value from work

Product Owner vs Product Manager

With such an extensive remit, it is perhaps little surprise that there is confusion over roles.  In some models, there is a tendency to split up these functions into separate roles.  This has especially been popularised by the Scaled Agile Framework (SAFe).  In SAFe, there are two distinct roles:

  • “Product Management” does research, strategy, vision and roadmaps. 
  • “Product Owners” work on features and manage the team backlog

Effectively the Product Owner in SAFe is a junior and very administrative role with limited influence.

By contrast, in Scrum there is a single Product Owner.  Remember that Scrum is a simple model – in Scrum there is a single Product.  The Product Owner is the overall authority on all aspects of the Product and has full accountability for the decisions made.

The Product Owner is accountable for maximizing the value of the product

Scrum Guide 2020

Product Owner challenges

There is a problem here. The Scrum Product Owner has a very wide skillset.  Domain knowledge, technical understanding, product roadmapping skills and team working are hard to find in the same person.  It is a rare and talented Product skilled person who can do all of these and do them well.  Agile promotes the value of “working together daily”. We also need to consider the opportunity cost. Does that give enough time for those same business people to do their other work away from the team?

There is, as so often with Agile development, no “right answer” and opinions differ. 

There is a temptation to follow the SAFe approach and have a “Team Level Product Owner” who focusses only on the team.  They can be on hand to answer questions from the team about the product.  They can help with backlog refinement.  They can run acceptance tests and comment on design decisions.  Meanwhile we separate out the more strategic functions and call those people “Strategic Product Managers”.

I would treat this approach with caution.  The Agile principle of working together is only effective if the business person is empowered.  They are not just working with the team as an administrator.  The point of having them in the room is that they can advise the team.  As emergent knowledge appears from the work, they can make decisions about what is best for the customer.  And these decisions are definitive because they have the accountability.  If they cannot do that, they are not delivering what the team needs.

Imagine we build a process where the features are owned by a separate product management team.  Do we still have a self-managing development team with autonomy?  The point of a cross-functional team is to have the skills and authority to minimise external dependencies.  Without a true Product Owner, the team is not truly cross-functional.  Instead it needs to refer to an external product management team for decisions.  The benefits of embedding a Product Owner are reduced or lost.

How should we structure the roles?

This leaves us with a dilemma.  We know that the business person in the team (the Product Owner) must be accountable.  Only by giving them this authority do we give the team autonomy.  But they must also have enough time to spend with the team.  Which clashes with the end to end accountability for the product.  You will need to decide your solution for this.

My own preference is to split product functions slightly differently from SAFe.  I prefer “Strategic” product managers who are mostly market and customer focussed.  This of course depends on the skills of the Product team – in a small team I find myself initially building around the people I have.  The “Strategic” product managers would cover these key areas:

  • Researching the market
  • Propose strategy
  • Create vision

The “Implementation” product managers have a wider remit than in SAFe.  They own the roadmap and the features, as well as working directly with the teams.  This focus means that when the team need a decision about how to get the most value from an implementation, that decision is immediately available. These product managers would cover:

  • Manage roadmaps
  • Specify features
  • Work with teams

Good practices

As an Agile leader, you need to ensure that your team has access to business knowledge and awareness. As part of “Management as a Service” you can view this as one of the “Services” that the team require.

This generally will need an individual working with the team but with a Product and customer focus. Exposing developers to customers is also good, but building a Product function which specifically focusses on product and roadmap is important.

You should ensure that the Product individual is working with the team regularly to explain the vision and to make judgement calls as the team learns and experiments.

To do that you need to make sure they can make those judgement calls, so think about whether it’s necessary to split up the strategic/tactical product role. And if it is, how you can do that and still give the team the support they need.

Leave a Reply

Your email address will not be published. Required fields are marked *

Discover more from Agile Plays

Subscribe now to keep reading and get access to the full archive.

Continue reading