Why Do We Need a Product Owner?

Product Owner accountability was added to Scrum to respond to the traditional product management approach, which was problematic but typical in many organisations. Such organisations relied on a hierarchical command structure to solve problems and make decisions. Despite Agility being around for decades now, many organisations still do this! This traditional approach caused many issues, such as late, low-value, low-quality projects and product deliveries.

Here is how product-related issues and decisions were made in a pre-Agile organisation. First, the team building the product is told what to do and how to do it by management external to the team. The belief is that those in management roles and further up the hierarchy will make the best decisions, leading to the best product.

When a problem is encountered, or a decision is needed, it is escalated up the management chain to the appropriate level in the hierarchy. The more experienced and trusted people make the decision. This is typically a committee of managers from different departments across an organisation for significant issues or decisions. This committee is expected to review the information presented to them and send a decision back to the team.

This sounds sensible in theory. However, in practice, this typically leads to delays in decision-making and undesirable outcomes. The Scrum Team must wait for the committee to meet and decide what to do. The committee often lacks the complete information to choose, so they defer the decision and request more information from the team. This pattern repeats, but the time it takes is rarely reflected in the team’s plan. The deadline they are working towards becomes increasingly unlikely to be met.

Things then get worse. The product team parks the issue and moves on to working on something else, which is often lower value. Any decisions the team make on behalf of the committee may be reversed at any time by the committee. The team will be blamed for any wrong choices or waste that this creates. The pattern repeats. An issue is raised. No clear decision is made. The team is starved of decisions, leaving the valuable work and moving on to lower-value work to keep busy. The issues and unmade decisions pile up and compound.

The problem is further compounded as the more senior the committee, the less often they will meet. So, the more influential the issue and decision, the more significant the delay. It is difficult for a committee to reach a consensus with multi-dimensional issues that crosscut the interests of different departments. Each committee manager also has unique motivations, interests and loyalties. Committee members do not want to be responsible for making incorrect, hard-to-reverse decisions based on incomplete information. So, the committee defers the decisions, requesting additional information. However, the information is always incomplete and subject to change in complex environments. We are caught in a vicious circle!

The result of all of this is:

• Big decisions get delayed.
• Work gets delayed. Deadlines are missed. Promises are broken.
• Customers are unhappy.
• Management is unhappy.
• The committee is unhappy.
• Management and the committee blame the Scrum Team.
• The Scrum Team is frustrated, demotivated and unhappy. This is reflected in the future work of the team.

This is the Decision/Issues/Information/Committee Circle Of Doom or the DIICC of Doom. Don’t get caught in a DIICC of Doom!

The Product Owner is Scrum’s simple answer to the DIICC of Doom. Scrum requires one person to occupy the Product Owner accountability. They may (and should) consult others, but ultimately, this person is accountable for maximising the value of the product resulting from the work of the Scrum Team.

In complex environments with limited information, it is often better to make a decision later proved wrong and reversed rather than make no decision at all while waiting for perfect information that may never arrive.

Product Owners build trust with those around them by facilitating the decision-making process with a broad group of stakeholders despite incomplete information.

Product Owners are accountable for effectively managing a Product Backlog that makes decisions transparent. They work with the rest of the Scrum Team to deliver Done Increments of value each Sprint.

Developers support the Product Owner by building products to minimise the cost of changing direction when new information emerges and decisions need to change.

So, the Product Owner’s accountability is critical and should be filled by someone with the requisite experience, knowledge, support and empowerment. This will allow for better decision-making based on learning and understanding. Where no such person exists, the organisation needs to empower and support someone to grow into the accountability and accept and manage the increased risk this will bring.

Ultimately, the Product Owner becomes the “mini CEO” for the product and helps the Scrum Team maximise their work’s value.