In this three-part blog series, we’ll look at some organizational roles that typically take on the Product Owner role and the pros and cons of each.
Part 1 – Business Analyst to Product Owner
What role in a traditional organization corresponds to the Product Owner role?
This is a question I hear a lot in my Scrum certification classes. Unfortunately, the answer is not simple. There is no direct mapping of the Product Owner role to a traditional organizational title. Think about it – if there were a direct mapping, then why bother creating this new role at all?
Instead, my clients often need to think about who in their company would be the best person to transition into the Product Owner role. For example, many of my clients choose to move their business analysts into this new role.
For those unfamiliar, a business analyst’s job is to work with stakeholders to elicit requirements and then document them in a business requirements document or product requirements document. They work as a go-between for the stakeholders and development team, clarifying requirements and getting answers to questions from both sides. Good business analysts have a fairly good understanding of both the business requirements and technical issues, allowing them to serve as “interpreters” between the technical team and end users.
Many of my clients point out, “Hmmm – that sounds a lot like what you are describing in the Product Owner role. Can’t we just take all our business analysts and make them product owners?”
You would be amazed how often that doesn’t work out. Here’s why:
The two key responsibilities of the Product Owner are to articulate the product vision and to manage the return on investment, or ROI, of the project. If added requirements don’t make sense from a cost/benefit perspective, the Product Owner must go back to the stakeholders and tell them “no”. This can be a very foreign experience for a business analyst. Most do not have experience telling the customer “no” and, worse, they don’t feel they have the authority to do so. Some deal with this stress by saying “yes” to all stakeholder demands and then pressuring the development team to “find a way” to deliver.
Do some business analysts make good product owners? Yes, absolutely. But this transition only works when the individual is comfortable being in that “decider” role, and is willing to take the heat that inevitably arises when stakeholders are unhappy because they didn’t get everything on their list. It is also crucial that your business-analyst-turned-product-owner is given the authority to say “no” to stakeholders. Leadership needs to give consistent and visible support to the Product Owner and make it clear that what he/she says, goes.
If you are considering transitioning your business analysts to the Product Owner role, I advise you to do so on a case-by-case basis. Only put people in the role who have the abilities, confidence and support to succeed.
In Part 2 of this blog series, we’ll look at another popular role transition: product manager to product owner.