In this model, product responsibilities are split between three or more roles: a product manager and a product owner in the business and one or more business analysts who report up through IT. This model seems to have some inefficiencies in it, however it is quite common, especially in internal product settings.
Typically the product manager is a business leader in the area that the product supports. The product owner is a staff member in that same organization and usually provides subject matter expertise and connection to other staff. The day to day work of backlog maintenance ( identifying stories and clarifying stories) falls to the business analysts.
Product manager is responsible for:
- Setting Roadmap
- Global Prioritization
Product owner is responsible for
- Local Prioritization
- Subject matter expertise
Business analyst is responsible for
- Story Writing
- Story Clarification
Centralized IT Teams as Service Providers
A financial services company I worked with had a central IT organization as well as an IT function in each of the business units. The centralized IT organization adopted agile and was positioned as an option for the business units, who could either have IT work done with their own units, or “hire” a team from the centralized IT area to do their work.
If a business unit engaged a team from the centralized IT unit , a member of the business unit would colocate with the team to take on product owner responsibilities. This product owner prioritized the backlog and provided subject matter expertise. While these product owners sat with the centralized team, they also maintained aspects of their day job, but were available to answer questions from the team.
Each team also had one or more business analysts who created and fleshed out backlog items. There were a couple of reasons for this setup. First, the product owner may not have had much background in working with requirements and they may not have had time to fully flesh out backlog items for the team. Second, most business units produced rather sizable requirements documents prior to sourcing the work to either their internal IT team or the central IT unit.
The business analysts on the teams converted those specifications into product backlog items. This is a classic example of what many people refer to as Water Scrum Fall – where detailed, in depth analysis is done up front, the development and testing are done iteratively and the product may be released all at once. In most projects I saw at this organization, the product owner who sat with the team was responsible for low level prioritization, but there was still a business leader in the business that made the broader prioritization decisions. Each engagement didn’t necessarily have it’s own roadmap, rather each project was launched as a roadmap item.
IT Project Team
Another financial services organization I worked with applied this model in a little different manner. The project was one of the first applications of agile that the organization had attempted. The people who worked in IT were organized into skill based silos (developers separate form testers, separate from analysts, etc.). For this particular project, people were pulled from the different silos and combined into a team, but in a departure from other projects that this organization had run, the team members were (generally) focused entirely on this project.
The leader of the business unit the project supported filled the product management role – making the global prioritization decisions. She also identified a members of her staff to play the product owner role and provide more day to day subject matter expertise and occasional local decisions. The person filling the product owner role changed from time to time depending on the part of the process the team was working on. The product owner generally did not colocate with the team and also maintained their normal responsibilities.
One interesting twist with this team was that these product owners eventually ended up running the demos. This was done in part to make sure the product owners were familiar with the changes being made, and also because the demos were used to get the rest of the staff familiar with the impending changes. The thought was if the product owner did the demo, the rest of the staff would react more positively to the change (if she is able to do it, it must be ok) rather than if it had been demoed by a developer.
The team also included business analysts who were responsible for maintaining the backlog – both creating and further clarifying backlog items. They were on the team because the product owner did not have the time to perform these activities and because they did not have a wealth of analysis skills that they could call on to effectively flesh out the backlog.
When to Use It
This model is a less effective version of product ownership model 2 and product ownership model 3, but it can be useful if a product owner is available in the business but does not have experience in working with delivery teams, does not have experience working with requirements or does not have the availability to effectively maintain the backlog to the extent that the delivery team finds most useful.
This model can also be useful where the internal product itself, or the environment in which it exists, is quite complicated – meaning there are a lot systems, organizations or people that are involved in order to reach the desired outcome. In this case the product manager and product owner focus on prioritization and subject matter expertise, while the business analysts spend a considerable amount of time uncovering interactions and other parts of the organization that may be impacted.
This model is most often seen in internal product settings in large organizations that are new to using agile, long standing teams, and having stakeholders work directly with the delivery team. This model may be needed as teams move from reliance on extensive documentation to more effective ways of building and maintaining shared understanding.
Pros of the Model
- Supplements product managers and product owners if they do not have experience describing backlog items in a form useful for the delivery team
- Provides a means to get subject matter expertise available to the delivery team even when the business unit does not have someone they can dedicate full time to the effort.
Cons of the Model
- Increased opportunity for communication errors due to the number of intermediaries involved. Communication in this model inherently goes Product Manager -> Product Owner -> business analyst -> team causing the opportunity for errors and delay.
- Increased opportunity for decisions made by the wrong product person
- Decisions made by one of the product people can be overridden by another product person after work has started on a particular item