I’m sure I’m not the only one who’s ever pondered this. As more and more shops move towards SCRUM as their development methodology, the role of the product owner becomes increasingly important in defining.
Well, what the heck is the product owner supposed to do in the first place? There are a lot of formal definitions, but the main objectives of their role are as follows (taken from agilejournal.com):
• Setting objectives for the Sprint (or iteration)
• Prioritizing and maintaining the backlog
• Participating in the Sprint planning meeting
• Elaborating stories on a just-in-time basis with the team
• Accepting stories into the baseline
• Accepting the Sprint
• Driving release planning
By definition, a product owner’s involvement in the SCRUM process is daily. They need to be constantly involved with the dev team as far as clarifying user stories at the sprint planning level and even the daily stand-up level, among other things.
A traditional product manager has other duties outside of the SCRUM realm that becomes hindered when following the product owner definition. The product manager is ultimately the poster child of the product they’re managing. They have a responsibility to achieve success in the market of their product in addition to insuring success in the delivery of that product. In other words, a lot of their work involves meeting with customers and analyzing current market trends. It’s difficult to be fully focused on these duties when you have to attend daily stand-ups and be available to the developers at all times.
Ideally, I think an agile product team could gain value in having both a product manager as well as a product owner. The product manager can continue to focus on being the face of the product from a design and marketing standpoint. The product owner can be someone who is more technically-inclined and is able to fully engage with the SCRUM team. The product development is still handled mostly by the product manager, but the product owner takes on the role of prioritizing the user stories and being a conduit between the business stakeholders and the dev team.
Obviously this situation won’t work for all companies. Some product teams are small enough to have one person handle both roles without becoming overwhelmed. Other teams simply don’t have the budget for both. However, I think it would be interesting to see how a dual role situation would pan out.