Consider Scrum as a theatre play. We see the actors on stage: the ScrumMaster facilitating meetings, removing obstacles and so. The development team committing, reporting and generally getting on with creating the product. When on the stage the Product Owner role is well defined: populating the Sprint, managing the product backlog, prioritising and such. But Scrum has little to say about what the Product Owner does when they are offstage.

Product Owners spend most of their time offstage. It is here that they learn what is needed, they learn the stories behind the items in the backlogs and offstage is were they perform their evaluations and trade-offs so when they walk on stage they are prepared to manage the backlogs.

Scrum is right to stay silent on how the Product Owner does their work. If Scrum detailed this activity it would be a bigger, more prescriptive process; it would be more complicated to adopt and more time consuming to learn.

(Similarly Scrum is silent on how Developers do their work: it does not mandate Test Driven Development, Refactoring or any of the other common technical practices. However, most of developers have seen the XP play which puts all development activity centre stage.)

To understand the Product Owner role we need to look at their offstage work.

 

The Product Manager and the BA

 

The Product Owner role is seldom filled by an actual customer. The Product Owner rarely puts their own money on the line to pay for the end product. Instead they fill a proxy-customer role. Their job is to understand what is needed from the software and translate that into work that needs doing.

Typically offstage Product Owners are Product Managers or Business Analysts (BAs). Although these are very different roles both work as Product Owner when on the Scrum stage. Whether the organization employs Product Managers or BAs depends on the type of end customer and product the company sells.

In independent software vendor (ISV) the software is the product. Here the Product Owner role is taken by a Product Manager. They talk to customers about their needs, watch the competition, determine product strategy and final decide what is needed in the product. Ultimately the Product Manager wants to know what will help the software sell.

Inside corporate IT departments – and companies who provide IT services to corporates – the Product Owner is played by a Business Analyst. While Product Managers look outside the company to determine need the BA looks inside the company.

When the company does not sell technology in its own right then IT is used to support the activities and products of the company. So BAs look inside the company to discover what is needed to improve operations, save money, open new markets and change operations.

At one extreme the BA role is to capture and document requirements; at the other extreme the role is an internal consultant tasked with understanding a company and finding ways to improve through technology.

Understanding these difference is key to successfully filling the Product Owner role. The single label obscures these differences. Whether the role is called BA, Product Manager or Product Owner the end result is the same: they determine what software needs to do. In order to do this both roles demand analysis skills, however what they analyse and how they do the analysis can be quite different.

Yet the difference between these roles is narrowing as more businesses embrace the web the two roles need to learn from one another. Once upon a time a BA only looked at internal customers and a Product Manager external ones.

Today, more and more corporate IT departments are tasked with deploying customer facing applications. BAs need to acquire some of the skills and tools of the Product Manager. Similarly, as more software companies offer software as a service applications Product Managers need to understand the insides of corporations.

The Subject Matter Expert

The key skills for both Product Manager and Business Analyst is analysis. The best Product Managers can use this skill in different domains: they may work on office automation software this year and CAD design tools next. Similarly good BAs can move form an insurance company to a car rental companies. A fresh mind can result in fresh analysis and new insights.

However, sometimes analysis skills and fresh thinking is not what is required. Sometimes companies want their software needs to be considered by an expert in the field. In these cases the Product Owner role is best filled by a Subject Matter Expert (SME) – also called a Domain Expert.

Such experts rely on their own knowledge to know what needs doing rather than analysis. Just to confuse matters SMEs frequently have the title Product Manager or Business Analyst.

Development teams should not rely on SMEs alone to fill the Product Owner role. There needs to be some analysis and future gazing to avoid creating software which is just a shopping list of features.

 

Some other holders

 

Almost as soon as I explain the three roles hiding behind the Product Owner title people ask: “Can an architect fill the role?” Or, “can a salesman fill the role?” As a general rule the answer is No.

Although some organizations use the title Architect to refer to Product Managers in most organizations the role is concerned with software design. It is difficult to ask one individual to empathize with the customers’ needs for the software and the software’s own needs.

Sometimes an Architect can fill the role. I recently helped a team who implemented exchange connectivity for a financial trading house. The team’s work was mainly concerned with the technical protocols, connectivity and availability of different exchanges. The work was driven by the technical changes and demands of the exchange. In such a case it made sense for the Product Owner to be someone who had a deep understanding of connectivity and APIs.

Sales people often see themselves as the perfect Product Owner. After all they are the ones who talk to the customers, they are the ones who bring in the work. However sales people make bad Product Owners for exactly these reasons.

Sales staff are selected for their ability to get sales made. They focus on a single customer and remove any blocks that stop a sale from happening. For a salesman the most important thing is the next sale – and the commission that goes with it. By definition they lack the broader view and analytical approach that Product Managers and Business Analysis bring.

Heavy workload

Doing the Product Owner role justice requires a lot of time. Product Owners need to be meeting with customers and users, they need time to think and analyse, they need to work with development teams both at the start of iterations and during the iteration.

Agile, and Scrum specifically, adds to the workload of the Product Manager or BA because some tasks move from the traditional Project Manager role to the Product Owner.

In addition Product Owners also need to work more closely with Testers. Whether the Product Owner is writing acceptance tests themselves or simply briefing Testers it all takes time.

As if that were not enough the workload is further increased when Agile itself is successful. Teams which become more productive through Agile methods need to be fed with more requirements.

When the workload is too high it is all too easy to take short cuts: speak to fewer customers or spend less time on analysis. In the short term the effects are hardly noticeable but over time it means development strays from the highest value work.

I recommend a ratio of one product owner to every three to seven developers. When a product is new, fast moving, when users are coming up with lots of ideas for change then one Product Owner to three developers is appropriate. More developers and the Product Owner will spend too long working with developers and not enough time talking to customers and undertaking analysis.

When a product is stable, has an established niche or function and when the development team know the product one Product Owner may serve up to seven developers. In such cases the requests are normally more measured, much work has gone before and developers don’t need so much guidance.

Of course, sometimes companies want to go faster than this. They have a new product and they want 10 or 20 developers cutting code! The solution is to divide the Product Owner role.

If the product can sensibly divided into two parts then there should be two Product Owners. As long as the Product Owners work closely together and present a unified roadmap then each may look after one part.

When the product cannot be so divided, or when there are several divisions then the solution is to divide the Product Owner role into strategic and tactical roles.

A single Strategic Product Owner (SPO) focuses on the overall goals and spends more time with customers or users. Several Tactical Product Owners (TPOs) work more closely with the development teams and testers. Naturally there needs to be close communication between all the Product Owners and agreement on roadmaps and goals.

The SPO/TPO divide can also help when there is an obvious Product Owner but they do not have the time – or will – to spend with developers. In such cases this person becomes the SPO and one or more TPOs are responsible for translating the vision to developer goals.

Legitimacy and authority

The Product Owner role changes depending on the type of organization, product and team. One size does not fit all.

The key requirement for a Product Owner is that they have legitimacy in the organization to ask questions and the authority to make decisions. What development teams need is a single voice who can say “This iteration we are doing X” and for that decision to stick.

Problems arise when the Product Owner lacks legitimacy or authority and after the start of the iteration starts someone else tries to impose their will.

The other problem faced by Product Owners is overwork. When done well the Product Owner reduces the amount of work going to the development teams and increases productivity. When the role is overloaded short cuts are taken, work is not well understood and priorities are not properly assessed.

The product owner performs their job behind the scenes talking to customers and learning what needs to be done to keep pointing the delivery team towards the audience and their needs. Knowing what the customer wants and showing the team the priorities for delivering it to them is a make-or-break role and with a good PO doing their job, the delivery team can shine and deliver massive performance.

---

About the Author

Allan Kelly helps companies improve their performance by adopting Agile development. He works as a coach, trainer and consultant to companies large and small and is based in London.

He is the author of “Changing Software Development: Learning to become Agile” (2008), holds BSc and MBA degrees and works for Software Strategy (http://www.softwarestrategy.co.uk). He is currently working on a book of Business Strategy Patterns. More about Allan at http://www.allankelly.net