(107) How to organize your product teams? — Part 2

While in Part 1, I thought I covered all ground on this topic by curating the best content from the Internet, I had missed out on an important source there — Marty Cagan’s Empowered.

Marty Cagan covered the topic of team scoping, which he calls topology, quite extensively in his book. There are a few things I still need clarification on, which I will when I have Marty on my podcast late October. You can subscribe to my podcast to be informed when that happens. https://www.youtube.com/productlessons

Here’s the summary on team topology from Empowered:

A product organization’s team topology answers questions such as:

• How many product teams should our organization have?
• What is the scope of responsibility of each team?
• What are the skills required for each team, and how many of each skill
• What are the dependencies between the teams?”

The topology helps answer the question of how a company should organize its product people into teams to best enable them to do great work.

If you are a product leader, establishing an effective team topology is one of your key responsibilities. It’s essential that product and engineering leadership must determine the topology together.

First and foremost, your topology choices should be guided by principles that support team empowerment.

These include three important elements:

1. Giving teams real ownership of the space of problems they will be responsible for
2. Providing autonomy in their ability to deliver the solutions to the problems they’re asked to solve
3. And alignment with various aspects of the company’s customers, business, and technology.

Another important consideration is the number and nature of the dependencies between product teams. Every topology creates its own set of dependencies between product teams, and leaders must consider the trade‐offs.

TEAM TYPES

There are two fundamental types of product teams:

1. Platform teams — They implement services so they can be leveraged by other teams. For eg, authentication and authorization. They are also responsible for maintaining a library of reusable interface components.
2. Experience teams — Responsible for how the product value is exposed to users and customers.

Platform Teams

Platform teams reduce the load required to use the underlying technology, creating cognitive capacity for experience teams to own more aspects of the customer problems.

Your end customers — and even your executives and stakeholders — may not have any direct visibility into the work performed by your platform teams, but don’t think these teams aren’t important.

In a small company, the platform may be provided by a single platform team. In many of the large, top tech companies, as many as half of the product teams are platform teams.

These experience teams are able to use platform services without having to understand how they are implemented. Instead, they can focus their energy on the customer or business problems they are working to solve.

Experience Teams

Experience teams are responsible for how the product is experienced by users in the form of apps, UIs, solutions, or journeys.

Experience teams are most empowered when they are given as much end‐to‐end responsibility as possible. Such teams have a meaningful sense of ownership, more autonomy, and it’s easier for them to see their impact on solving customer problems and achieving business results.