When I joined eBay as Head of Product, I managed a small team of two people who were there before me. They had well-defined responsibilities and worked on completely different products.

The reasoning behind creating the Head of Product role was to start bringing larger parts of the core eBay platform to the Israeli R&D center. And it worked: When I left after almost five years, I managed over ten product managers working together on eBay’s structured data core platform.

Of course, splitting the responsibilities between many product managers working on the same platform was much more challenging than defining those for two product managers working on distinct, stand-alone tools.

At first, I wanted to avoid making bold decisions. I naively thought clear boundaries weren’t that important because we were all in it together and worked well with each other. 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.

The day-to-day wasn’t as easy as I thought it would be, and even if the team worked well together, they spent a lot of time discussing the overlapping tasks.

But as the team grew, the lack of clear boundaries created another problem that was much more painful for me: my talented and experienced product managers couldn’t take full ownership and lead their domain strategically since they were constantly assigned specific tasks that were part of the bigger domain.

Instead of splitting the responsibility, I needed to split the work and manage everything accordingly.

In this structure, the team couldn’t shine, and my ability to lead was limited because I needed to manage their work and focus on coordination rather than impact.

It was time to change.

However, there was a reason I initially avoided these clear boundaries. It was simply too hard to find the right split of responsibilities. There was no perfect solution. Even when something seemed logical from a professional perspective, if you added specific people’s considerations like skill and aspirations to it, this puzzle seemed unsolvable.

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

The right organizational structure and team responsibilities are some of the most common questions my clients ask me. Having helped dozens of companies already, I’ve found several patterns that work well, and I’ll share them with you here.

The right team topology

I’ll start by saying that there is no perfect solution. The decision on team topology always involves trade-offs. So, instead of seeking the best topology, you need to choose the right one for you, at least for now.

Like anything else in our dynamic world, team topologies change over time to adjust to new priorities and constantly improve how things get done.

So on the one hand you want to choose something and go with it. Avoiding change just because it’s not easy and there’s no perfect answer isn’t going to help you. But on the other hand, you don’t want to change things too frequently. Minor adjustments and improvements are always great. For major changes, though,  I recommend giving the new topology at least 6 months of stability. Improve as you go and use the time to learn what you are really missing because a new topology wouldn’t be perfect either.

Criteria for a good split of responsibilities

When we work to find the topology that is right for us, for now, we will explore many options. How can you decide which one is better than the other? There are many things to look at, but I found the following three most meaningful. 

They are also helpful when you come to make your trade-offs because you want to know what you are giving up on (and what you gain in return) instead of choosing blindly or based on a gut feeling.

1. Substance

As a product leader owning a domain, it is important that you have full ownership over something end-to-end. And this something is larger than the sum of the features you will develop. There needs to be a bigger picture that ties everything you do together, as this is the only way to lead and not just execute. Your are of responsibility 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 domain that has enough substance, 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.

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 and contributes best to the overall team goals.

Topology as an outcome of strategy

The whole point of a good topology is to allow you to implement your strategy well. Therefore, it shouldn’t surprise you when I say that a good topology stems directly from your strategy.

Unfortunately, since many companies don’t have a well-defined strategy, this statement often leads to a dead-end.

If that’s the case, I highly recommend at least telling your roadmap story strategically (using the GOSPA framework, for example). The most important part of the roadmap regarding team topology is the strategic pillars by which you choose to describe your world.

These pillars should be distinct and exhaustive of the goals that you want to achieve. 

When they are well defined, it is easy to assign each product manager such a pillar. If you have a larger team, a hierarchy is needed both in your strategic story and in your organizational structure.

As a rule of thumb, you should have 3-5 strategic pillars, which are generally the fronts at which you are attacking. If you have a similar number of product managers, it fits well. If you have a larger number, you can assign 3-5 leads to lead the pillars and then apply the same practice to each team separately.

Note that this split might seem unrealistic at first since when you come to implement it, you might realize there are too many dependencies in the code itself or within the engineering team.

In other words, this is great for substance, ownership, and vision, but it might not be good enough in terms of independence due to your specific circumstances.

Don’t throw the baby with the bathwater.

Squads can go a long way in helping you bridge the gap between engineering maturity and strategic product thinking. 

Other barriers, such as skill or capacity in the product team, could take longer to resolve, which might call for a lighter split of responsibility until the team is ready. But don’t be tempted to give up on splitting by strategic pillars. Define it as the end goal and gradually build your way there.

Remember that until you do, your ability to lead is limited since your team can’t take full strategic ownership, and instead of managing your pillars, you need to manage tasks and projects. Build the team topology that serves both you and your team.

Next week, I will share specific examples and guide you through decision-making until you find the right solution.