Do Senior Users Make Good Product Owners?

Few people would disagree that the Product Owner is a critical role in agile teams. That means that organisations often want to ensure that the product owner is as effective as possible – and that often means asking experienced, often senior, staff to take on the role.

In organisations transitioning from traditional project management approaches, the most experienced people have often held similar roles in project structures, such as Senior User.
This can be a good move, but only when they realise that the expectations and mindset of a Senior User and a Product Owner are fundamentally different. Failure to realise this can be disastrous, resulting in poor delivery, longer lead times and poorer quality products.
The role of the Senior User is to validate that requirements are necessary for the solution’s success and to accept them as such. Once accepted, they are committed to and subject to change control. At best, they may have some MoSCoW prioritisation to allow a little flexibility. Then, once delivered, the Senior User accepts the solution if it meets the requirements.

The role of the Product Owner is to ensure that the work the team (or teams) will do in the forthcoming iteration will be valuable to the business. This means their accountability is constant, not concentrated around the start and end of the project. Their focus is on the requirements they want in the next iteration and on ensuring that the work the team is completing in this iteration is able to deliver the business value required. This is true whether the ‘iteration’ is a sprint, a planning increment or the WIP on a Kanban board.

For a Product Owner, all other ‘requirements’, such as the rest of the Product Backlog, are just options. Choices. They may be required in future iterations, but they may not. There could be a change that makes them obsolete or incorrect. This is one reason why the word ‘requirement’ is a poor choice in agile teams. You don’t know a ‘requirement’ will actually be ’required’ until it is prioritised into an iteration. Until then, it is merely one of many options available.

Fundamentally, then, a Senior User treats the list of requirements as commitments; a Product Owner treats the list of backlog items as options.

This is a huge shift in mindset and not an easy one to make, especially if you don’t realise there is a difference. Unfortunately, this distinction isn’t well communicated, and many Product Owners embark on their new agile roles without realising that they have to perform them in a fundamentally different way.
This is also a problem for external stakeholders, especially those used to classic project management or systems engineering approaches. For them, the presence of a requirement on a list feels exactly the same as it used to in waterfall delivery – an agreement and a commitment to deliver it.

One way this manifests itself is in a reluctance from Product Owners or business stakeholders to begin using early increments of their product. Why should they? After all, they know that there are lots of required stories or features not implemented yet. And they know that the team has committed to delivering them because they are on the backlog, and the team is funded for more iterations.

People in this mindset see an iteration as a step towards a finished product, and they genuinely believe that the version of the product described in the requirements is definitely the right one. So, why waste time with a partial solution when waiting a few more weeks will let them have the finished product?

However, when a Product Owner views the backlog as a set of guesses, ideas and options for possible value the business can get from the solution, this attitude changes. When the work the team is doing describes things of tangible business value(even small bits), it becomes far more obvious that the increment should be used for real as soon as possible. The results of this use can then feed back into the backlog, either as new ideas or options or to affect the priority or detail of other backlog items.

Helping Product Owners realise this and helping them develop and enhance this mindset is essential. Not only does it lead to better, more value-centric backlogs and shorter lead times, but it also equips them with the ability to justify and explain this approach to other stakeholders and help them also change their mindsets.