Under Conway's Law, which was developed by software programmer Melvin Conway, "any organization that designs a system will produce a design whose structure is a copy of the organization's communications structure."

In other words, what teams deliver will reflect their organizational structure, given the extent to which the organizational structure affects the way employees communicate with each other. This means that the way you organize your product teams will have a major impact on the customer experience.

For example, if one team develops your desktop app and another team develops the mobile version of that app, and the teams don't work together. Well, you probably get two completely different user experiences.

The organizational structure becomes more critical as the company grows rapidly. As the number of product managers grows to meet the needs of the business, it is easy to create confusion about who has jurisdiction over decisions and over large areas of the product. To avoid these problems, you must adopt an organizational structure to divide responsibilities and tasks, but choosing how to organize a growing product team can be a tough decision.

There is no silver bullet for the way you organize your teams. The trick is to minimize the negative impact by placing the seams in the organization where they have the least impact on your ability to deliver customer and business results.

To this end, there are six common ways to structure your teams: each with its own advantages and disadvantages.

Organization # 1: By Product

In larger companies with multiple products on the market with limited dependencies, it is easy and smart to split the work by product. But confusion about what a "product" is can stumble teams. We define a product as something that people use to help them achieve an outcome they care about.

As an example, Uber offers a number of different products: the original ride-sharing service, Uber Eats, and JUMP scooters. For Uber, organizing by product means having a product manager (or, more likely, teams of product managers) for each of these products.


  • Very clear which team should handle specific feedback / bugs
  • Easy to bring the right product person to external product meetings, such as a sales call


  • Limited vision / strategy / roadmap to product level ( not very customer oriented)
  • Requires a lot of coordination between the teams when products are closely integrated with each other

Organization # 2: By characteristic

An organizational structure can also be built around product characteristics. This organization is a good option for companies with mature products with various meaty features.

Returning to Uber as an example, you probably know that the Uber app has a number of different functions: booking a ride, real-time driver tracking, payment options, driver ratings, travel history, and so on. Imagine assigning a product manager to each of these functions.

While this is a common way of organizing teams, it creates dependencies, as some job changes may require development work from multiple job teams, slowing the delivery of value to the customer. .


  • Very clear which team should handle specific feedback / bugs
  • Less dependencies than other options


  • Causes confusion when features require infrastructure / architecture updates
  • Limited vision / strategy / roadmap to function level (not very customizable)

Organization # 3: at technical layer

This organizational structure typically has several teams built around three common layers of software products: data, APIs, and user interface. Or imagine if Uber's product teams were organized around individual operating systems – iPhone, Android, Web – with specific teams targeting each form factor and a back-end team supporting all three.

This organization is a good choice for companies with a highly technical or complex algorithmic product, but it can become dependency-ridden. One team can develop a feature quickly, but then run into a brick wall while waiting for another team to fall behind due to a different set of competing priorities.


  • Aligns with technical team specialties such as front-end or iOS
  • Very clear which team should handle specific feedback / bugs


  • Creates a confusing user experience due to differences in functions between technical layers (eg Function on the web not available on mobile)
  • Requires a lot of cross-team roadmap coordination to manage dependencies

Organization # 4: by customer segment or persona

Rather than organizing around products, you can organize your teams based on your customer segments or personas. This is a smart move for companies that serve very different types of customers with their product suite.

Imagine if Uber had a product manager for specific customer segments such as: full-time professional drivers, occasional drivers, business travelers, partygoers and families with children.

This organization is a good way to focus teams on the needs of users, but it requires strong coordination between teams to avoid duplication, deviation from established design principles, or taking the product in different directions at the same time.


  • Highly customer-centric, encourages teams to think about customer needs / results
  • Simplifies user research, each team can tailor interviews to the type of person they want to talk to and become experts in that persona over time


  • Can pull product in multiple directions simultaneously
  • Requires a lot of coordination between teams when selling multiple products to a customer segment

Organization # 5: According to Customer Journey Stage

19659008] In this organizational structure, you have a different product manager for each major part of the buying experience such as discovery, testing, engagement, retention, and so on. This structure works well for companies with a well-defined linear customer journey and a strong emphasis on growth.

Often times, there are important business metrics that closely match the success or failure of customers who continue their journey at those times, allowing for delegation. to be accountable.

However, this structure requires a lot of design coordination to ensure a cohesive customer experience. For example, you wouldn't want new Uber users to find different words in the app than premium users, and you wouldn't want buttons or drop-down menus to work differently as users become more engaged.

Benefits [19659011] Supports product scaling well: growth teams focus on driving people to a product, other teams focus on testing and engagement
  • Clear metrics you can assign to each product manager, such as conversion rate free trial to paid or retention
  • Disadvantages

    • Requires tight management to ensure a consistent and great user experience throughout the customer journey stages
    • Complicated for a viral growth strategy where use serves as trigger, discovery and evaluation for potential customers

    Organization # 6: on performance metrics
  • 19659008] It is also possible to organize product teams based on specific product metrics. This is a good choice for companies with established product key performance indicators (KPIs) that capture customer and business results.

    For example, Uber might consider letting a product manager focus on revenue from new customer acquisition, while another product manager focused on average customer revenue per account, and a third product manager focused on net promoter score.

    The main benefit of this approach is accountability to individual product managers, but it can lead to multiple teams working on the same product components at the same time and thus no one feels ownership of those things.


    • Easy to assign goals to teams and then measure product success
    • Easy to delegate decision making and accountability to product managers

    ] Disadvantages

    • Requires a stable set of KPIs that will not change often
    • Requires coordination of the roadmap between teams as individual teams may need to touch a lot of product areas to achieve goals

    Choosing your organizational method

    Keep in mind when weighing the pros and cons of any organizational structure takes into account that you are not stuck with whatever organizational strategy you choose. It often makes sense to change the organizational structure based on the maturity of the product. You can also take a hybrid approach by combining two or more of the structures.

    The important thing is to create some kind of structure. This allows you to effectively scale your product team and clarify responsibilities as the business grows.


    Written by Ben Foster and Rajesh Nerlikar . Ben Foster and Rajesh Nerlikar co-founded Prodify, a product management consultancy that has served more than 60 software companies over the past six years. Ben Foster is a speaker at industry-leading events and numerous podcasts with over 20 years of experience in product management. He is Chief Product Officer at WHOOP and was previously Senior Product Manager at eBay, Vice President Product at Opower and Chief Product Officer at GoCanvas. Rajesh Nerlikar has over 15 years of experience in product management. Before becoming chief product advisor at Prodify, he was a technology consultant at Accenture, entrepreneur, product manager at Opower, senior product manager at HelloWallet and director of product at Morningstar. He is also currently vice president of product at Savonix, a Prodify customer. For more advice on organizing your product team, you can find Build What Matters: Leving Key Results with Vision-Led Product Management (Lioncrest Publishing; September 7, 2020) on Amazon.
    Have you read?
    & # 39; The World's Best Countries For its citizens to live.
    & # 39; the world's best countries for cultural influence.
    & # 39; the world's best countries for entrepreneurship.
    & # 39; the world's trendiest countries.