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:
This structure revolves around the 3 layers of most modern software products:
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.
Similar to the technical layer structure, there would be a team for each OS:
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.
In Chuckwagon, the teams might break down like:
This is a common way of organizing teams, but it does create dependencies as some feature changes might require changes from other feature teams.
In Chuckwagon's case, the workflow teams might look like this:
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.
You could imagine a world where Chuckwagon teams were organized to optimize the experience for different segments, such as:
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.
For Chuckwagon, you could imagine KPI-focused teams like:
As the team scales, you could offer smaller teams more portions of the outcome KPI pyramids, such as:
The Chuckwagon team may choose to divide their work by who they're building for:
This is my preferred structure because:
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:
I prefer #7 - Personas because:
I'll add two more things to consider when deciding on a team structure:
Good luck and of course please contact us if you'd like to talk about your team's structure.