There is a common misconception that the Product Owner is just a Business Analyst with a new suit and a better title. While the two share many skills in common, the roles are really quite different. According to the Agile Atlas: “The Product Owner is the single individual who is responsible for drawing out the most valuable possible product by the desired date.”
Great Product Owners have:
- A clear understanding of the business needs.
- A clear vision of where the product needs to go.
- Enough budgetary authority that they can make decisions about product features without having them changed later.
- They must be able to get answers to the team’s questions rapidly (think minutes and occasionally hours).
The right Business Analyst has these attributes and will make a great Product Owner. In contrast many BA’s are great detail people, but struggle with the vision side. In addition many businesses aren’t willing to give a BA the budgetary authority required of the PO.
Other warning signs of the wrong PO:
- Rarely available to answer the team’s questions
- Doesn’t talk to end-users directly instead just talks to their managers or admins
- In a large organization there are often many levels of people between the PO and the actual users of the Product
So before just deciding that your Business Analyst will become the Product Owner, sit down and examine who has the right mix of skills, authority and access to play the role well.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
The Product Owner should provide the strategic direction of the product – the Business Analyst should provide the tactical direction of the solutioin:
https://rthewitt.com/2013/02/14/product-owners-vs-business-analysts/
While I agree that the “Product Owner” (as the role is called) is not just an uber Business Analyst, to expect this person to be available whenever the dev team needs AND have a clear understanding of the business + budgetary authority, etc. is not always realistic, especially in a larger org. To be well versed in the business and customers, you need to spend time ON the business and with customers. That can easily be a full-time job. But I’ve seen many agile teams that expect the product owner to be available almost the entire time or be “on call” at all times. And budgets don’t always trickle down to execution team. While I support agile as an SDLC process, it seems to me agile teams needed someone to represent all business/customer interests, so rolled it up into one uber role called the product owner. I wonder if the flipped model is possible: that the dev folks spend more time in the market with customers and understanding the business. Spend 1 hour with a customer and it’s eye opening.
Shardul – I agree the role is hard to play well. I give PO’s two rules of thumb:
– Split your time 50% Customer, 50% Team
– Most of the time you should be able to answer a question in ~2-3hrs.
From there I ask them to do what make sense.
I agree that the team should spend time with the customer (easier if you’re in IT shop vs ISV). I also agree that the role is hard to play well.
So I think we’re mostly in agreement here.