8 Ways to Organize Your Product Development Squads

In 1967, computer programmer Melvin Conway introduced an idea that came to be know as Conway's Law.  It stated:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

In the product development world, this means that teams are more likely to ship a product that reflects the way their teams are structured.  Given how much the team structure can affect the customer experience, we work with a lot of teams on how to structure their product development teams.  Here are 8 of the most common structures we see:

1. By Technical Layer

This structure revolves around the 3 layers of most modern software products:

1. Data
2. APIs
3. User Interface (UI or "front end")

Using our imaginary Chuckwagon home-cooking product as an example, the data team would be focused on capturing and organizing recipes, household profiles, meal plans and grocery lists.  The APIs team would work with partners like Instacart and Shipt to share relevant data to make grocery delivery possible, and the UI / front end team would be responsible for building a UX on mobile / web platforms.

While this may be a great way for engineers to organize themselves by specialty, you can see how it can quickly distance the "back end" teams from the customer experience that provides the context they need to make technical decisions.

2. By Operating System

Similar to the technical layer structure, there would be a team for each OS:

1. iPhone
2. Android
3. Web / Tablets

Using Chuckwagon as an example again, you could imagine a team dedicated to each mobile platform (perhaps the apps are slightly different in functionality) and one for the web, which might include creating tools for internal operations teams or partner dashboards for Instacart / Shipt.

Again, this structure works well from an engineering standpoint given most engineers specialize in one of these (although that's changing).  This structure may work well if your user base sticks to a single OS.  If that's not the case, you'll have to be thoughtful about creating a seamless experience for users who jump between a laptop and their phone.

3. By Features

In Chuckwagon, the teams might break down like:

• Meal Plans - the features to get / tweak a weekly meal plan of recipes
• Household Profile - the features to specify who's in my household and any dietary restrictions
• Groceries - the features to convert a weekly meal plan into a grocery list, with the option to get groceries delivered
• Chefs - the consumer-facing features to book and rate a chef, and the chef-facing features to plot their route and grocery list for the day

This is a common way of organizing teams, but it does create dependencies as some feature changes might require changes from other feature teams.

4. By Customer Workflow

In Chuckwagon's case, the workflow teams might look like this:

• Plan Meals - the process of deciding what to cook over some time period
• Get Groceries - the process of getting all the ingredients to make your planned meals
• Cook - the process of prepping and making the planned meals
• Clean Up - the process of cleaning up the table / kitchen after a meal

This structure requires strong design coordination to ensure a consistent customer experience.  For example, you wouldn't want the Meal Plan team using different words within the app from the Grocery team, and you wouldn't want the buttons or a dropdown to work differently between teams.

5. By Customer Segments

You could imagine a world where Chuckwagon teams were organized to optimize the experience for different segments, such as:

• Single people
• Couples
• Families with kids

This is a great way to get the teams focused on the needs of their users.  However, it still does require coordination across teams to avoid duplicating efforts or deviating from common design principles / artifacts.

6. By Product KPIs

For Chuckwagon, you could imagine KPI-focused teams like:

• ARR Growth - converting free users to paid plans, extending lifetime value, etc.
• Time Spent - reducing the time required by users to plan meals, get groceries, cook and clean up

As the team scales, you could offer smaller teams more portions of the outcome KPI pyramids, such as:

7. By Personas

The Chuckwagon team may choose to divide their work by who they're building for:

• Consumers
• Chefs
• Grocery delivery partners (Instacart, Shipt)
• Internal operational / support teams

This is my preferred structure because:

1. It forces teams to recognize how many different stakeholders they're serving
2. It gives teams the ability to learn about their users at a deep level since they're focused on them
3. It creates a simple way to prioritize work ("we need to stop building for internal teams for a bit to focus on our new grocery delivery partners - hopefully you all understand why")

8. By Product

Of course, at larger companies with multiple products in market, it's simple to break the work down by product.  However, one way I see teams get tripped up here is what the definition of a product is.  We define a product as follows:

A product is something people use to help them achieve an outcome that's important to their lives.

The definition of product probably merits its own blog post (on my list).  But at Chuckwagon, this structure might look like this:

• Consumer product - key outcome is reducing the time it takes to get home-cooked meals on the table
• Grocery partner product - key outcome is increasing grocery delivery revenue
• Chef product - key outcome is increasing take-home pay as a chef

My Vote?

I prefer #7 - Personas because:

• It shines a spotlight on how many people you're building product for.
• It gives the team the ability to focus on building a product to optimize the outcome each persona seeks.  For example, the outcome an enterprise buyer seeks is likely very different from what the enterprise user seeks.  The reality is you probably have two very different customer experiences for those two personas.
• It gives the team the ability to focus on who they are building their product for over a long period of time.  No more switching context.
• For smaller teams who can't dedicate an entire team to every persona, it makes the prioritization decisions immediately visible.  "We're in a good spot with the enterprise user experience, so our roadmap is focused on building a reporting dashboard for the enterprise buyer so they can see the value of what they bought."

Closing Thoughts

I'll add two more things to consider when deciding on a team structure:

1. Use the MECE Principle.  You want to ensure the team structure is Mutually Exclusive and Collectively Exhaustive - that is, it should be clear which team any product work should go to, and there shouldn't be any overlap / ambiguity about which team should take the work.
2. Consider a Core / Platform team. Many companies today have a core / platform team, which manages common functionality across a product or product suite such as authentication or email messages.  This is to help accelerate product development (ex. why should every team have to figure out how to send emails to users?) and ensure technical consistency (ex. avoid having to maintain 3 different integrations with email delivery vendors).  This team might also be responsible for product hygiene initiatives like uptime, performance and security.  One note about using a core / platform team - you might need a unique product manager for this team as they might need to be more technical than the user-facing product managers who are building on top of the core platform.

Good luck and of course please contact us if you'd like to talk about your team's structure.