Meet the team: a primer on product teams

Let's say you're running a software organisation for the first time. You've got plenty of questions: who does the work? How does work get done? Where does the work come from? And how do you keep your teams aligned? Let's answer these questions.

This post will answer the first question: who does the work?

So what is a product team, anyway?

Who does the work?#

In a software product organisation, the fundamental unit of "doing work" is the team. Teams, not individuals, create business value. Teams identify customer needs, ideate solutions, and deliver code.

A product team should consist of a minimum of three and up to six engineers. It should include a team lead (often an engineering manager but sometimes a product manager) and experts from other disciplines, including both a product designer and product manager.

The teams I'm talking about here are product teams. They identify opportunities and deliver solutions that directly benefit their customer. Product teams should make up most of your software engineering organisation.

There's two other types of teams you might come across: enabling teams, and platform teams.

• Enabling teams provide expert support to others in the organisation.
• Platform teams build shared systems that are used by other product teams.

You can learn more about other team topologies here.

Now you may have more questions: why do you need product design and product management within a team? Why limit the number of engineers within a team? And why have a team at all — what's wrong with letting people do what they'd like? Let's answer them in turn.

Why do you need a product designer and product manager within your team?#

Why do you need these cross-disciplinary experts in your team? Why not have a team of solely engineers and have your product manager (assuming you have one) work across multiple teams?

Here's why: when a product manager and design operate outside of a team, you end up with a dynamic of work being handed to the team. Feature requirements are "thrown over the wall". The team is empowered only to deliver features, not to understand their customers and actively find ways to improve their lives.

You want a team of missionaries, not mercenaries. Your team builds better products when they believe in, and are active participants in shaping, what they're working on.

Team members also learn a lot from working with cross-disciplinary peers. For example, a product manager working with engineers gets to grow her understanding of what's possible with technology. An engineer can learn about designing accessible user interfaces from his team's designer.

For more thoughts, read Marty Cagan's article on empowered product teams. See also Teresa Torres's article on the Product Trio.

Why constrain team size?#

We've already established the benefits of a cross-functional team. But what about the number of engineers? Let's consider the "engineering" part of the team.

Let's start with the lower limit. A team is an abstraction of its members. But with three or fewer engineers, it's quite a leaky abstraction. The team resembles the individuals within it far too well: for example, it's noticeably affected by holidays and sick leave. When one of your two-person team takes a holiday, you lose 50% of your engineering capacity. It's also difficult to build slack into your work with a small team.

On the flip side, you should also cap the upper limit of team members. Small teams are generally preferable to large teams mostly due to communication overhead. For a team of three, there are only three relationships to manage. With four members, this number grows to six, and a five person team comprises ten different relationships.

How many relationships can you keep track of? How well can you really know the nine either people in your ten person team? As a result of the exploding number of relationships and communication lines, large teams often fracture into multiple sub-teams. In that case, you get the worst of both worlds: lack of alignment and a lack of sharing expertise.

Why have a team at all?#

I said before that "teams, not individuals, create business value". But it's never "the team" that writes code — an engineer does. "The team" doesn't design a user interface — a product designer does.

How do we resolve this paradox? By realising the purpose of constructing a team is not goal attainment, but goal alignment.

You get far better results aligning people towards a shared vision than by having them work towards separate aims. In this sense, it's not terribly important what the goal even is. What's important is that there's a goal to align around at all. Goals in sport are arbitrary, yet they create powerful teams.

People also teach and grow within teams. Members of a team who work together regularly also coach each other. They can share knowledge and help each other learn. This is a virtuous cycle of the team creating and sharing knowledge.

And what happens once you get the right people in the room?#

Bringing the right people together is only the first step in creating a high performing team.

Having the right people is very important, but it's only the beginning. You'll need to help them transition through the phases of team development: from forming, storming, norming, then to performing. That's a topic worthy of its own discussion another time.