Image courtesy of William Gill
A hurdle for companies who are transitioning to Agile is how to staff the product owner role. Should they look externally or is it OK to look within as they already have roles that are similar to the Product Owner (PO) position. Common questions I’ll see pop up when they are considering who would make good candidates for the new Scrum role include:
- Do Product Managers make good Product Owners?
- How about Business Analysts, do they make good Product Owners?
- Which should we look to – Product Managers or Business Analysts?
The answers are “yes, yes, and it depends”.
I’ve seen excellent POs who have come from Product Management, Business Analysis, as well as a variety of other roles such as Quality Assurance, Technical Support, Research, and others. It just happens that Product Managers and Business Analysts happen to have a head start when it comes to some of the essential responsibilities of a product owner, so we often see organizations looking to them first when considering candidates.
What Makes A Good Product Owner
The product owner is a person (not a committee) who is responsible for the ~what~ that is going to be built.The product owner holds the vision for the product, and understands why features are valued by customers. He or she owns the product backlog, and collaborates with the development team and stakeholders throughout the creative process.
Hard skills include domain knowledge of the industry and the ability to manage stakeholder expectations. They need to be able to compromise without being a “yes” person.
Product owners should be trusted by their team and one way to do that is to spend time with them. Great product owners are available to their teams, normally getting answers back to them in minutes rather than days. They balance empathy for the team but also integrity to the product. Teams should not expect PO sign-off if the Definition of Done is not met.
Product Owners From Product Managers
Product Managers have traditionally considered a wide range of product-related activities and data in performing their role. A well-known framework developed for Product Managers has been developed by Pragmatic Marketing which calls out product owner-ish skills such as use scenarios, user personas, market problems, and product roadmap. That said, you can also see there are a number of things a product manager could be doing that isn’t directly related to the Scrum description of a product owner; such as pricing, win/loss analysis, lead generation, and so on.
Having the TIME to be a good product owner – available for the development team – is a real challenge for the typical already-overworked product manager. Product managers always seem to be 110% tasked out before someone comes along and tells them, “Hey, there’s this thing called Scrum and guess what – you’re a product owner now!” It would not be fair for the Product Manager, now PO, to transition immediately into the role without Scrum training, though we have seen this happen. To make this really work the whole Product Management group should have PO training so expectations are clear and everyone has respect for the role.
Product Owners From Business Analysts
Business Analysts have skills and experience in areas such as facilitation, requirements analysis, risk evaluation, focus, and helping team members with domain knowledge. The Business Analyst Body of Knowledge (BABOK) from the International Institute of Business Analysts (IIBA)** does a good job of describing how Business Analysts can contribute in Agile environments. Their expertise in analyzing systems, structures, policies, and operations can be valuable both in aiding the team in their creation of just enough documentation, and in clarifying and elaborating product backlog items. Being able to quickly spin up a visual model such as a Process Flow or Ecosystem Map can really help a team get their minds around concepts and energize their emergent design.
I’ve worked with several companies where the Product Managers are in a different location (or even on a different continent) from the development teams. Challenges that come from distributed teams present themselves quickly during an Agile adoption. A solution I’ve seen work very well is to have a Business Analyst local to the development team who works closely with the product owner – they divvy up responsibilities according to their skills and interests. The product owner is the lone owner of the product backlog, but the Business Analyst can be of great aid in clarifying acceptance criteria, understanding risk, working with the development team in getting to effort estimation, and so on. The product owner can focus on things such as vision, value, and stakeholder interaction and feedback. The business analyst can act as a proxy for the product owner as needed, with the caveat that the PO is quickly updated and agrees to the proxy’s decisions. This sort of “product ownership” collaboration can help smooth some of the difficulties global organizations can face.
Product Owners From Tech
Another option is to staff the product owners through the technology department. This is a good option as tech understands the PO role and can allocate bandwidth. However, working with tech is only half of the equation. What about the customer? The technology team is somewhat removed from the business market making it difficult to create and stick to a balanced vision for the product.
You can have a dedicated product owner or have a person playing dual roles. Someone who is a PM and PO is a good solution because you have the vision and the market. The negative is that you have one person that may need to be in two places at once. The best solution is one that works for your organization.
**(need to be an IIBA member for free copies – see http://www.iiba.org/babok-guide.aspx and http://www.iiba.org/BABOK-Guide/Agile-Extension-to-the-BABOK-Guide-IIBA.aspx).