Do's and Don'ts in Product Team?Topology

Last week, I shared my journey of structuring a growing product team at eBay -how I initially resisted making bold organizational decisions, thinking that a strong team culture would be enough to navigate overlapping responsibilities. I learned the hard way that without clear ownership, even the best teams waste time debating who should handle what instead of driving real impact.

Moreover, it limited me as a product leader since I couldn’t delegate at the strategic level and needed to manage the details with each product manager in my team.

It didn’t work, and I needed to define the team’s responsibilities clearly.

That’s when I first encountered how complex it is since all of the product managers in my team were essentially working on the same product: eBay’s structured data platform. Therefore, any split of responsibilities is, by definition, artificial.

However, some splits work better than others.

In the previous article, I outlined the key principles that guide a strong team topology: substance, independence, and balance. I mentioned that structuring your team isn’t about finding a perfect, one-size-fits-all solution but about making trade-offs that fit your strategy -at least for now.

I explained why product team responsibilities should stem from strategic pillars rather than being dictated by engineering constraints, but that’s often easier said than done.

That’s what this article is about. Now that we’ve covered why a well-defined team topology is essential and the core principles behind a good split, let’s talk about the practical side: what works, what doesn’t, and the mistakes you want to avoid when organizing your product team.

Examples of Splitting Product Responsibilities According to Strategic Pillars

You can mix and match any of the methods below as long as the end-to-end story makes sense. You should also note that when your product (and your product team accordingly) is large enough, this is the initial split, and each domain then needs to go through the same process again to split responsibilities between the various team members according to the specific domain strategy.

Remember that these are just examples. Your strategic pillars might look different, but that’s perfectly fine?—?you can still use them to define your team’s responsibilities in the same way.

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.

Use this split for products with multiple personas, where the needs of the various personas are independent and don’t conflict with each other.

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 the onboarding 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, all end-to-end.

This split is suitable for large and mature products, where each phase in the customer journey has enough substance to it.

Goals

In this method, each product leader is assigned a set of goals they own and can touch whichever functionality is needed to reach it. Growth product managers are a good example of that.

This split is most relevant for mature products, where specific problems can be identified and tackled with explicit goals. 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.

Methods to?Avoid

I often see team topologies that are defined based on engineering constraints. This is not the right way to go.

The worst example is splitting product responsibilities by engineering layers (i.e., backend, frontend, integrations, research, web, mobile, etc.). A slightly better one, but still not the one you want to go with, is splitting by functional modules or areas (i.e., notifications, analytics, detection (for cybersecurity products, for example), primary logic (like the route and ETA calculation in Waze), etc.).

These types of splits score low both on substance (how can one build a good roadmap and vision for notifications or the front end of the product?) and on independence, although not necessarily the way you think.

Theoretically, these teams are independent: I own the entire frontend capacity of the company and can run with it as much as I want. However, when you look at delivering end-to-end value, this is no longer the case.

Real value requires cross-functional collaboration, and you cannot achieve it if your product people own technical functionality.

The Decision?Process

Since there is no perfect solution, you want to try out several options and see which is best. Of course, I mean trying it out on paper and not changing your topology in practice every other day.

Start with your strategic pillars. Understand what they are and try to split your product into actual domains based on the pillars. You can use each of the examples above and add your own. Evaluate each option based on the criteria we defined: substance, 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 mainly trying to rule out some of the methods so that you can dive deeper into the remaining ones and find the optimal split.

Include your stakeholders (at least engineering and senior management) and debate the trade-offs. An important discussion is about the criteria itself and which is most important for you as a company at this specific time.

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

Try it out, and let me know how it works.

Happy re-org!

Our free e-book “ Speed-Up the Journey to Product-Market Fit”?—?an executive’s guide to strategic product management is waiting for you at www.infinify.com/ebook

Originally published at https://infinify.com on February 27, 2025.