According to 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 communication structure.”
In other words, what teams deliver will be a reflection of their organizational structure, given how much org structure influences how employees communicate with each other. This means how you organize your product teams will have a great impact on the customer experience.
For example, if one team develops your desktop app and a different team develops the mobile version of that app, and the teams don’t collaborate well, then you’re likely to wind up with two very different user experiences.
The organizational structure becomes increasingly critical with rapid company growth. As the number of product managers grows to match the needs of the company, it’s easy to create confusion about who has jurisdiction over decisions and major portions of the product. In order to avoid these issues, you need to adopt an organizational structure to divide responsibilities and tasks, but choosing how to organize a growing product team can be a tricky decision.
There is no silver bullet solution to how you organize your teams. The trick is to minimize the negative consequences by placing the seams in the organization where they will have the least impact on your ability to deliver customer outcomes and business results.
To that end, there are six common ways of structuring your teams, each with its own pros and cons.
Organization #1: By Product
At larger companies with multiple products on the market with limited dependencies, it’s easy and smart to break the work down by product. However, confusion about what constitutes a “product” can trip teams up. We define a product as something people use to help them achieve an outcome that they find important.
As an example, Uber offers a number of distinct products: the original ride-sharing service, Uber Eats, and JUMP scooters. For Uber, organizing by product would mean having a product manager (or, more likely, teams of product managers) for each of these products.
Pros
- 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
Cons
- Constrains vision/strategy/roadmap to product level (not very customer-centric)
- Requires a lot of cross-team coordination when products are tightly integrated with each other
Organization #2: By Feature
An organizational structure can also be built around product features. This organization is a good option for companies with mature products with several meaty features.
Returning to Uber as an example, you are probably aware that the Uber app has a number of different features: booking a ride, real-time driver tracking, payment options, driver reviews, trip history, and so on. Imagine assigning a product manager to each of these features.
Although this is a common way of organizing teams, it creates dependencies as some feature changes might require development work from multiple feature teams, which slows down the delivery of value to the customer.
Pros
- Very clear which team should handle specific feedback/bugs
- Fewer dependencies than other options
Cons
- Causes confusion when features require infrastructure/architectural updates
- Constrains vision/strategy/roadmap to feature level (not very customer-centric)
Organization #3: By Technical Layer
This organizational structure typically has distinct 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 focusing on 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 hell. One team might quickly develop a feature but then hit a brick wall as they wait for another team lagging behind due to a different set of competing priorities.
Pros
- Aligns with engineering team specialties, such as front-end or iOS
- Very clear which team should handle specific feedback/bugs
Cons
- Creates a confusing user experience due to feature discrepancies across technical layers (ex. feature on 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 according to your customer segments or personas. This is a smart move for companies who serve very different customer types 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, partiers, and families with children.
This organization is a good way to focus teams on the needs of users, but it requires heavy coordination across teams to avoid duplicating efforts, deviating from established design principles, or taking the product in different directions at the same time.
Pros
- Very customer-centric, encourages teams to think about customer needs/outcomes
- Simplifies user research, each team can target interviews by the type of person they want to talk to and can become experts in that persona over time
Cons
- Can pull the product in multiple directions at once
- Requires a lot of cross-team coordination when multiple products are sold to a customer segment
Organization #5: By Customer Journey Stage
In this organizational structure, you have a different product manager for each major part of the buying experience, such as discovery, trial, engagement, retention, and so on. This structure works well for companies with a well-defined linear customer journey and a heavy emphasis on growth.
Often, there are important business metrics that closely mirror the success or failure of customers continuing their journey at those junctures, allowing for delegation of accountability.
However, this structure requires a lot of design coordination to ensure a cohesive customer experience. For example, you wouldn’t want first-time users of Uber to encounter different verbiage within the app from premium users, and you wouldn’t want buttons or dropdown menus to work differently as users become progressively more engaged.
Pros
- Supports scaling products well—growth teams focus on driving people to product, other teams focus on trial and engagement
- Clear metrics you can assign to each product manager, such as conversion from free trial to paid or retention
Cons
- Requires tight governance to ensure a consistent and great user experience across customer journey stages
- Complicated for a viral growth strategy where usage serves as a trigger, discovery and evaluation for prospects
Organization #6: By Performance Metric
It’s also possible to organize product teams based on specific product metrics. This is a good choice for companies with well-established product key performance indicators (KPIs) that capture customer and business outcomes
For example, Uber might consider having a product manager focused on revenue from new customer acquisition, another product manager focused on customer average revenue per account, and a third product manager focused on net promoter score.
The main benefit of this approach is pushing accountability to individual product managers, but it can result in multiple teams wanting (or needing) to work on the same product components at the same time and thus no one feeling ownership for those things.
Pros
- Easy to assign goals to teams and then measure product success
- Easy to delegate decision making and accountability amongst product managers
Cons
- Requires stable set of KPIs that won’t change often
- Requires cross-team roadmap coordination as individual teams may need to touch a lot of product areas to hit goals
Choosing Your Organization Method
As you weigh the pros and cons of each organizational structure, note that you aren’t locked in to whatever organization strategy you choose. It often makes sense to change the organizational structure based on the maturity of the product. You can also adopt a hybrid approach, combining two or more of the structures.
The most important thing is to create some kind of structure. This will allow you to effectively scale your product team and make responsibilities clear as the company grows.
******
Written by Ben Foster and Rajesh Nerlikar. Ben Foster and Rajesh Nerlikar co-founded Prodify, a product management advisory firm that’s served more than 60 software companies in the past 6 years. Featured as a speaker at top industry events and on numerous podcasts, Ben Foster has more than 20 years of product management experience. He is chief product officer at WHOOP and was formerly a senior product manager at eBay, vice president of product at Opower, and chief product officer at GoCanvas. Rajesh Nerlikar has more than 15 years of product management experience. Prior to becoming chief product advisor at Prodify, he was a technology consultant at Accenture, an entrepreneur, a product manager at Opower, a senior product manager at HelloWallet, and a director of product at Morningstar. He is also currently serving as vice president of product at Savonix, a Prodify client. For more advice on organizing your product team, you can find Build What Matters: Delivering Key Outcomes with Vision-Led Product Management (Lioncrest Publishing; September 7, 2020) on Amazon.
Have you read?
World’s Best Countries For Its Citizens To Live.
World’s Best Countries For Cultural Influence.
World’s Best Countries For Entrepreneurship.
World’s Trendiest Countries.
Add CEOWORLD magazine to your Google News feed.
Follow CEOWORLD magazine headlines on: Google News, LinkedIn, Twitter, and Facebook.
This report/news/ranking/statistics has been prepared only for general guidance on matters of interest and does not constitute professional advice. You should not act upon the information contained in this publication without obtaining specific professional advice. No representation or warranty (express or implied) is given as to the accuracy or completeness of the information contained in this publication, and, to the extent permitted by law, CEOWORLD magazine does not accept or assume any liability, responsibility or duty of care for any consequences of you or anyone else acting, or refraining to act, in reliance on the information contained in this publication or for any decision based on it.
Copyright 2024 The CEOWORLD magazine. All rights reserved. This material (and any extract from it) must not be copied, redistributed or placed on any website, without CEOWORLD magazine' prior written consent. For media queries, please contact: info@ceoworld.biz
SUBSCRIBE NEWSLETTER
