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.
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