It must be re-org season. Last week alone, 4 of my customers each brainstormed with me on how to best split the responsibilities within their product organization.

After exploring the various options with each of them, I found 5 primary methods that I wanted to share with you.

Importance of Having Clear Boundaries Between Product Managers

Before we get to the “how to split”, let’s talk about the “why?”

As a novice product group leader, I didn’t like clear boundaries on roles. I went with my belief that in a good team (which I worked hard to build), everyone should work together towards the same goals, and when there are disagreements, the relevant team members can talk about it with each other and solve any dispute.

I wanted to see my team as one big happy family, without any barriers to interrupt the togetherness.

Well, little did I know.

My team raised a red flag and asked for clearer boundaries. They were tired of stepping on each other’s toes all the time, or just discussing who owns what on a regular basis. They wanted clear ownership and the ability to run their own domain freely.

I learned that even if not everyone likes the split responsibilities at first, it is still better than not having them at all.

With teams that really worked well together, I asked them to come up with a proposal on how to split their responsibilities. It typically led to good results with a split that everyone (including me) was happy with.

Note: having clear responsibilities doesn’t mean that you lose the flexibility to add or change them. Ad-hoc projects which don’t necessarily belong in specific domains will still be handed over to team members based on the specific needs and availability of each, and in times of load product managers can help each other and take ownership of specific parts which would naturally fall in another person’s domain.

Still, having clear boundaries is an important starting point to know which boundaries you feel more comfortable bending, and when and why to do so. And most of the time the boundaries will hold.

Of course, like anything else in an agile world, the boundaries need to be rethought of every now and then — when it stops working for you, when you go through major changes or when new responsibilities are added to your team.

Don’t be tempted to do it too often though — I recommend giving the new structure at least 6 months before you consider changing it, even in the most fast-paced companies.

Three Criteria for a Good Domain Split Between Product Managers

I found three important criteria for splitting product manager domain and responsibilities:

1. Completeness

As a product leader owning a domain, it is important that you have full ownership over something end-to-end. This “something” needs to be tight enough (without holes) and wide enough to be able to bring complete value over time (as opposed to delivering functionality). In a complete domain, you should be able to build a clear value-based vision and roadmap.

2. Independence

In the crazy world we live in, moving fast is critical to your success. Independence is achieved when a product leader has the ability to promote their mission and achieve their goals with the development team they are working with, and with minimum dependencies on other teams.

Part of this can be achieved regardless of a specific split of responsibilities, for example by working in squads and/or multi-functional teams. The more advanced your R&D organization is in that respect, the easier it is to achieve independence with any split you choose.

You should note that product dependencies are not limited to development teams. Additional dependencies include the other PMs in the team (and this is where the split of responsibilities can make a large impact), other delivery teams like data, UX, design, marketing, and also stakeholders like legal, compliance and finance.

The way you split the responsibilities in your product organization can impact (increase or decrease) the level of independence each domain has on all of these fronts.

3. Balance

The split should be balanced throughout the product team — according to the desire, load, and capabilities of each team member.

Note that balance doesn’t necessarily mean equal load, capacity or responsibility. It means that each team member owns something they can succeed in, in a way which contributes best to the overall team goals.

Since balance is very specific to each team and the people in it, I will only rank the following methods according to completeness and independence.

5 Methods for Splitting Product Responsibilities Between Team Members

1. Using Layers

This method is mimicking the classic R&D split of teams: backend, frontend, integrations, research, web, mobile, etc. and gives each team a product owner.

Completeness score: low.

Independence score: low (when looking at delivering end-to-end value).

Best suitable for: traditional companies where R&D teams are split based on professional capabilities, without any additional cross-functional R&D structure on top of it (like squads) — and when changing or adding to the structure is not easy.

If you are choosing this model, make sure you have an uber-leader who still owns the product end-to-end (could be the head of product or someone else), to make sure all the pieces are connected to delivering value and not just functionality. They would also need to lead the vision and roadmap for the entire product area since it is hard to create a product vision for the front-end piece, for example.

2. Using Functional Modules

This method splits the responsibilities by functional areas. It can look something like the following: notifications, analytics, detection (for cyber products for example), primary logic (like the route and ETA calculation in Waze), etc..

Completeness score: low to medium. The more granular the split, the lower the completeness. For example, if you own “settings and preferences,” there is not much you can do with it in terms of vision and roadmap. But if you own the entire analytics functionality in the product, you can do much more.

Independence score: medium (will be higher if R&D works in a cross-functional structure like squads or multi-functional teams).

Best suitable for: products at a relatively early stage, where heavy lifting is required to deliver even the first releases. The vision and roadmap at this point are typically the overall product ones, and you mostly need the different parts to work well together towards the already defined scope.

I believe this is a much better approach than the first one — especially since it prepares the organization for more mature stages, so if you can choose between the two — go with functional modules over layers.

3. User Personas

This method assigns a user (or a customer) persona to each product leader and lets them serve the persona’s needs end-to-end. For example, if your product is a marketplace, you can assign one product leader to serve the needs of buyers and one product leader to serve the needs of sellers. Of course, if you are a large enough product you will have multiple people on each persona and you will need to further split the responsibilities within each team.

Completeness score: high.

Independence score: medium to high (will be higher if R&D works in a cross-functional structure like squads or multi-functional teams, and if the needs of each persona are served through primarily separate and distinct areas in the product).

Best suitable for: products with multiple personas, where the needs of the various personas are independent and don’t conflict with each other.

4. Customer Journey Phases

This method splits the responsibilities by the phases in the customer journey. For example, in an e-commerce site, one product leader can own on-boarding of new users and/or driving traffic to the site, another one owns finding the right product to purchase, and another one owns the checkout process.

As in the previous method, the larger your product is the more likely it is that you will have multiple people owning each piece and need to further split the responsibilities between them.

Completeness score: medium to high (will be higher for more mature products where each phase in the journey can have its own independent goals).

Independence score: medium to high (requires R&D to work in a cross-functional structure like squads or multi-functional teams).

Best suitable for: large products, where each phase in the customer journey has enough substance to it. Will not work well with traditional R&D structure of back-end, front-end, etc..

5. Using Goals

In this method, each product leader is assigned a set of goals they own (essentially a problem definition) and can touch whichever functionality they believe is going to solve that problem. Growth product managers are a good example of that.

Completeness score: high.

Independence score: medium to high (requires R&D to work in a cross-functional structure like squads or multi-functional teams).

Best suitable for: mature products, where specific problems can be identified and tackled (and assigned goals for). It is also a good approach for ad-hoc, specific, and typically temporary problems that need a task force to solve. In the latter case, you can add it on top of any other method you selected. This method will not work well with the traditional R&D structure of back-end, front-end, etc..

Selecting the Best Method for You and Your Team

So how do you find the optimal split of responsibilities for your specific product problem?

Beyond the general guidelines above, try to split your product into actual domains based on each of the methods above. Evaluate each option based on the criteria we defined: completeness, independence, and balance.

You will immediately start to see which methods work better for you — some products, for example, have greater independence than others when splitting by personas, while other products split more naturally by the customer journey phases.

Don’t spend too much time on it initially, as at this point you are mostly trying to rule out some of the methods so that you can dive deeper into the remaining ones and find the optimal split.

You can also use the criteria in discussions with stakeholders (for example R&D leadership and senior management) — and debate which criterion is more important for you at this specific point in time.

Remember: there is no single method that is universally right. Each company, product, and team have the right split for them, and even that one is only right for the specific point in time you are considering it in.

Try it out and let me know how it works.

Happy re-org!