Product Team Structure - How Product Managers, Product Owners, and Business Analysts Collaborate
The creation of the product owner in Scrum has caused some angst and confusion in product circles regarding how a product team structure looks like.
Should there be a product manager and product owner? Should there be only one?
If both, who leads whom?
Throw in a third type of product person - business analyst - and the discussion can get quite muddy.
It doesn’t help matters that the terms product manager, product owner, and business analyst can refer to roles or titles (or both).
In order to provide a bit of clarity, here’s an explanation of the difference between roles and titles, a description of the three common product titles, and how people filling those titles often collaborate. Learn the ins and outs of product team structure and more.
Roles vs Titles
A role is a function that you play in an organization or with respect to a product. Roles describe what you do and are often used as shorthand for a set of responsibilities you fulfill.
A title is how you present yourself outside the organization. It is, ironically, what you reply when someone asks you what you do for a living (ie “I’m a product manager”).
The title can often be used as shorthand for the set of skills you have and it is likely to be what gets listed on a job description.
You will also see variations of job titles as a way to denote seniority and hierarchy, such as this common hierarchy for product managers.
To avoid confusion, this post refers to roles in terms of the function they perform (product management, product ownership, or business analysis) and titles using the terms that you’ll most likely see on a job ad or business card (product manager, product owner, or business analyst)
Product roles explained - Product team structure
You can’t assume that if your title is product manager that all you’ll do is product management as described above.
It’s not unusual to see:
a product manager doing product management and product ownership
a business analyst doing product ownership and business analysis
someone who does not have a product manager, product owner, or business analyst title asked to fill a product ownership role.
In addition, different organizations use titles in a variety of ways, so this post focuses on roles.
Product management
The product management role focuses on understanding an organization’s customers, understanding their needs, and determining whether it’s worth it for their organization to satisfy those needs.
This role requires a balance between the needs of your customers and the needs of your organization.
Some product management techniques help you build and maintain a direct, meaningful connection with your organization’s customers.
Other product management techniques help you to assess those needs against your organization’s strategy and business plan.
Still, other techniques help you make decisions about what problems to solve and what products to build and update.
Product management also deals with the business aspects of selling the product and making it available to your organization’s customers.
In an external product context, product management is often the function that incorporates everything product people do. Product ownership, then, is a subset of product management and business analysis doesn’t necessarily exist as a separate function.
Product ownership
The product ownership role focuses on supporting the team delivering the solution and making sure that team has the information necessary to deliver the right solution effectively. This function primarily deals with the product team.
Product ownership was originally created to describe the activities that the product person does in the Scrum framework. Because Scrum was created to guide the work of a software development team, the product ownership role tends to focus on what a software development team expects their product person to do.
As a result, product ownership focuses almost entirely on the relationship with the team developing a solution.
The related techniques provide clear direction regarding the right things to build and include things such as creating backlog items, refining the backlog, and providing information about backlog items.
What often gets left unsaid is how product owners go about making those decisions, or how much they should look externally to understand the market.
Business analysis
The business analysis role focuses on understanding the business processes, date, and business rules necessary to satisfy your customers’ needs.
This role primarily deals with subject matter experts—and to some extent users. In some respects, you could interpret business analysis as product management applied to internal products.
In practice, however, there are some key differences. Most business analysis functions are in a position to support decision-making but not necessarily make the decisions. One advantage of moving to a product perspective is better positioning business analysis functions to influence and even make key decisions.
The main activity that differentiates business analysis from product management and product ownership is the focus on the needs of businesses and stakeholders.
How product people work together
Understanding the difference between roles and titles is informative. In order for that knowledge to be truly useful, you need to understand how people filling those roles work together in specific contexts.
A good way to focus on contexts is to split them between an external product setting and internal product setting.
In an external product setting, you work directly on a product for sale to customers.
In an internal product setting, you work on a product that enables your organization to provide products and services to customers.
External product roles
When you look at the roles involved in external product settings there are two roles that you are most likely going to fill.
You fill the product management role when you work to understand customers and are outward-focused.
You fill the product ownership role when you build shared understanding with your product team and are inward-focused.
Business analysis is rarely a separate role in external product setting and is absorbed into the other two. Business analysis is much more prevalent in an internal product setting and is explored in more depth in the next section.
Models for organizing product people for external products
Now that you have two primary product people roles, the question becomes how do you organize the people that fill those roles.
Todd Little put together a diagram that explored product roles in his organization The following diagram, modified from Todd’s original, shows that there are three primary models to apply specific titles to these roles.
The models differ in the number of product people that sit between customers and the product team and what organization those product people report through.
There seems to be general agreement that the ideal model is to have a single product person working to understand customers and building a shared understanding with the product team.
This is the Only Child model shown above. The reasoning goes that the best person to build a shared understanding with the product team is the one who is working to understand their customers.
Most startups use the Only Child model where the founder is filling the product management role.
As the product gets more complex and the organization grows, you may see someone brought in to be a full-time product person so that the founder can concentrate on other things.
As the product continues to grow in complexity, you’ll reach a point where one person, even if acting only as a product person, can not effectively put forth the effort to understand their customers and build a shared understanding with the product team. This usually coincides with the need to add more product teams to the mix.
Some organizations keep the number of product people to one per product team in which case you have multiple instances of the only child model.
In other cases, organizations split up the product responsibilities so that you have one or more people focusing on understanding the customers and other people who focus on building shared understanding with the product team(s).
These are the Identical Twin and Fraternal Twin models. The difference between these two models is the organization in which the product person reports. This difference is important because it can impact how product people interact with each other.
Internal Product Roles
Internal product settings have the same roles as external product settings, with the addition of business analysis.
You fill the product management role when you work to understand customers and are outward-focused.
You fill the product ownership role when you build a shared understanding of the problem to solve with your product team and are inward-focused.
You fill the business analysis role when you work to build understanding of the data, rules, and processes that your team needs to work with.
Models for organizing product people for internal products
The main differences between the external product setting and internal product setting are who fills the product management role and the addition of the business analysis role. As a result, the models of interaction look like this.
In an internal product context, there may not be an explicit product management function. The connection with customers and decision-making activities usually occurs in various business units. In this situation, product management happens in a sponsorship model.
When you act in a sponsorship mode, you still make decisions about the problem to solve and constraints on a solution (i.e. time and budget). You still make those decisions based on your understanding of the impact on your business and its customers.
The difference is that you aren’t responsible for a specific product that is sold to your customers. You aren’t responsible for marketing and selling a product. You are more than likely responsible for a process that enables delivering a product or service for your organization’s customers.
And, being a product person is not your full-time job. That point is key when looking at the different models for organizing product people in an internal setting.
The addition of the business analysis role changes the Fraternal Twin model such that the product person interacting directly with the product team is a business analyst rather than a product owner.
The addition of a business analyst also adds the possibility of a fourth model, the triplets model.
You may use the Triplets Model when the person in the business unit who was identified as the main product person has neither the responsibility to make all the decisions (usually around what funds are available to work on the product) nor time available to work directly with the team.
This model is characterized by someone acting in sponsorship mode who makes key decisions about funding work on a product, and what particular problems to solve. Though to be honest that second decision usually ends up being about what solution to deliver.
A product team identifies someone to do business analysis for one or both of two reasons.
When the person filling the product ownership role cannot devote their full attention to working with the product team.
When the product person filling the product ownership role does not have the skills to build the necessary understanding of data, rules, and processes with the product team.
It’s helpful to know what model you want to use, but you also need to consider who is going to fill the roles in whichever model you pick. In fact the two are fairly intertwined.
What product model do you use?
If you’d like more information about the various models for organizing product people, see the roles product people play.
The intent of these models is to show there is no one way to organize your product people. The context that you’re working in has a huge influence on how you organize your product. The main consideration for picking the proper model is whether you’re working in an external product setting or an internal product setting.
Of course once you pick the model you’re going to use, you’ll need to figure out how to make that model work.
If you select one of the models that includes more than one product person, you’ll need to figure out how to keep everyone on the same page and help them collaborate. This is where airfocus comes in. It can help all the product people working on a product create clear roadmaps and collaborate on product strategy.
For more information of product management team structures, and the role of product manager, we wrote an extensive guide to the product manager's job. Check it out.
Kent McDonald
Read also
Experience the new way of doing product management
Experience the new way of doing product management