Despite the fact that a lot has been said and written about the different roles in Scrum, still the Product Owner (PO) role confuses people and organizations. Questions like PO is like a Project Manager (PM) or PO substitutes Business Analyst (BA) still occur.
In order to clarify this, let’s look at the definition first, then we’ll make some bordering lines between commonly mixed roles and at the end, we’ll look at some problems that may occur with this role and the ways to overcome them.
The Scrum.org defines PO as responsible person for maximizing the value of the product resulting from the work of the Development Team.
In a similar fashion, Scrum Alliance says that PO is expected to do the best possible job of satisfying all stakeholders, maintain the Product Backlog, and ensure that everyone knows the priorities.
When we look at these concise definitions we see that PO has to understand the value of his product, that he manages different stakeholders and sets priorities for the team.
Sounds rather simple and straightforward and one might argue that PM has similar role. So, where’s the difference.
There’s one essential difference between PO to other typical project roles. While PM, Business Analyst (BA), Technical Project Manager (TPM) are focused to deliver particular project with defined scope, PO takes care of the product throughout his entire life-cycle.
Imagine you are building a house where you’ll live with your family. One one side you can engage professional PM who will coordinate activities on your project, or you can coordinate activities yourself (assuming that you have minimal understanding of the process). In both cases your house will be built, what comes after the project is launched is important.
Let’s assume that while your house has been built you first child has been born. You realise that it would be very convenient to have a door connecting your sleeping room with children’s room. However, as the scope of the project has been locked before you got a child and that PM has committed to this scope, there’s no way for you to change your requests. Ok, you will go via corridor connecting your and baby’s room, it’s a nuisance, but you learn to live with it.
Once you move in and start living in your house, you might find out that you need another room for seasonal things like jackets, skis, skateboards and what not. If you want a PM to handle this you would have to start new project, engage PM who will deliver it… the time passes and you live in a chaos till project is finished. As a PO in your house you could prioritize building new room and start enjoying new setup as soon as possible.
When we dig deeper into PO and PM roles we see significant differences. Typically PM has narrow view, he doesn’t care of the overall product. He has been given a task and he will deliver it. The impact this task makes on the product overall is not his concern.
Second important thing is that PM doesn’t have vision of the product. PO on the other hand, as the owner, has to be aware of where the product will develop in years to come. Each decision he makes should lead to this goal.
The third difference that I would discuss here is contact with customers. While PM takes requirements for granted, PO has to understand customer needs and incorporate their feedback in product backlog.
Occasionally, PO role is mixed with BA role. While BA should translate business requirements to “technical language” and identify systems that are impacted by those requirements, PO should explain to the team in very customer friendly way (through user stories) what users expect from the system. Here we have clash of two paradigms. In scrum, expectation from the team is to get involved and offer solution of user needs. In traditional project management expectation is that developers code in-line with detailed requirements set upon them.
The table below summarize most important differences between PO and typical project roles.
| Product Owner | Project roles | |
| Product Owner vs Project Manager | Product vision defines a high-level scope. Firm scope is defined on a sprint level | Delivers clearly defined scope |
| Change in high-level scope is daily business and is not reported to anyone as product vision remains unchanged | Each change in scope is reported and asked approval for | |
| Focused on product throughout its lifetime | Focused on project (time limited) | |
| Direct communication to dev team | No direct communication to dev team | |
| Direct communication to customers | No direct communication to customers | |
| Product Owner vs Business Analyst | Interested in end result on the product level, not on system level | Identifies impacted systems |
| Writes user stories and acceptance criteria | Translates business needs to business requirements | |
| Discuss customer needs and how they will be satisfied | Discuss final solution with dev team | |
| Check if acceptance criteria are met and if the product work in the desired fashion | Organizes system integration and user acceptance tests | |
| Product Owner vs Technical Project Manager | Coordination between teams is done by the teams | Coordinate different dev teams |
| Team inter-dependencies are settled on sprint planning | Check if inter-dependencies between teams are settled | |
| Protect team from impact coming from stakeholders | Removes obstacles that team confronts |
Once the differences between these roles are clarified, let’s see what type of person we expect PO to be.
Should PO be a person with technical background?
Not necessarily. Although he should have enough technical knowledge to understand what team is talking about PO doesn’t have to be a developer. Even more, if PO has development background it might impose problem in communication if during user story estimates he starts challenging the team, or offers his estimates instead.
PO should have product management experience. Creating product vision, understanding what steps lead towards its fulfillment are some of the vital roles of PO. Experience in this field definitely contributes to creating a success story around the product and the team.
Experience in marketing can be an asset. Here, experience in creating communication roadmap for the product, utilization of different communication channels definitely helps. Speaking of this field, understanding of growth phases and treatment of users in each of them is, also, beneficial for the product.
PO should have experience in creating strategy of the product. Understanding process of strategy creation, structure (its elements) of the strategy and aligning product strategy with overall company’s marketing strategy go hand in hand with creation of product vision.
PO should have strong customer focus. Not only as a matter of speech, but he should essentially focused on getting, understanding and implementing customer feedback as a daily routine.
One of the key soft skills that a PO should have is negotiation skills and stakeholder management. This is necessary in all phases of the product lifetime, from the idea itself, through first MVP, to its maturity. As the matter of fact, this is one of PO’s key activities and refers to internal and external stakeholders alike.
Understanding business goals, as well as customer needs and their relations is something that a good PO cannot omit. Setting priorities is in the essence of his job, and understanding both business objectives and user needs is precondition for success in this field.
When we look at these requirements one might ask if all this is necessary. I would argue that if you want to have a PO performing his role in full capacity, yes, all this is necessary. If you want to have a proxy toward development teams, as suggested by SAFe framework, then you could omit most of these qualities, but then you have just that – a proxy, not a PO.
Next blog post will be dedicated to the role of Product Owner and their real-life challenges. 🙂
