Scaling Product Development Teams

Optimising Learning & Value Flow

In lean product development, a small cross-functional team is responsible for a product and they have all the skills to build, deliver and support that product.

The team evolves their product incrementally by iterating through a learning loop.

In each journey around this loop, the team takes an idea, builds it into the product, measures how customers react and learn from the data they collect.

In an early stage company, the learning loop optimizes finding product/market fit and growth. In a later stage company, it optimizes return on investment (ROI) and time to return (TTR). In either case, the team looks to reduce the cycle time around the loop so they can increase the rate at which they learn.

But what if you are trying to do more than a single, small team can possibly achieve? How can most effectively engage more people in your endeavor?

For any team to be effective each person needs to communicate well with the others. For a team of n individuals, there will be n × (n −1) ÷ 2 relationships between the individuals.

As we add more people to the team, the numbers of relationships grow and the increased communication overhead reduces alignment amongst the team members. As a result, the time taken to each cycle around the learning loop increases and the rate of learning slows.

Because large teams don’t work, we need to use multiple small teams. But how do we divide the work between teams?

Dividing Work Between Teams

Avoid Component Per Team

One reason for engaging more people in your endeavor is to help you meet customers needs more quickly.

One approach is to take the customers needs, design a solution to those needs, break the solution into its component parts and have each team build a part. Once all of the parts are built, then they are assembled into the product and delivered to the customer.

For example, if the customer needs a car then we could have separate teams build the chassis, suspension, steering, engine, etc.

But there are significant problems with this approach. First, someone outside the teams needs to break the product into components before the teams can start work. And because each team’s component is of no value to customers on its own, someone outside the teams needs to integrate the components together into a product and test the product.

This leads you (back) into a waterfall process and the learning loop slows.

Avoid Role Per Team

One other approach would be to group folks into separate small teams based on their skillsets. We could have separate teams for product managers, developers, testers, operations, support, etc.

Because each team’s work is of no value to customers on its own, they will need to hand over the deliverables from their activities to another team for further processing. For example, the product managers team will hand requirements to the development team, the development team will hand builds to the test team, etc. These hand-offs between teams are wasteful because contextual information doesn’t get transferred fully.

Another major issue with this approach is that each team will locally optimize its own work rather than globally the speed of value delivered to customers. For example, the development team will continue building new features even though the test team is swamped with a backlog and still testing features built months ago. By the time the test team finds an issue with a feature, the development team will have to waste time reacquainting themselves with that feature so they can fix the bug.

Note that the DevOps movement was born from the recognition that having separate development and operations teams significantly slows value delivery. In fact, the same is true of separation between any role!

Role Per Team just leads you (back) into a waterfall process and the learning loop slows.

Try Product Per Team

In this model, each small cross-functional team is responsible for their own product. They have customers for their product and all the skills to build, deliver and support that product.

Each team is able to deliver their product independently of each other because of their product:

• Having a backward compatible public interface.
• Fully encapsulating its internal implementation details.
  Only interacting with other products through their public interfaces.
• Never depending on features in other products which are not yet released/live.

Note that unlike component per team, in product per approach, each team has a product with external customers and hence can deliver value and learn independently of other teams. So if your teams don’t have real customers external to your enterprise then you are using component per team, not product per team.

Try Functional Area Per Team

Sometimes you may have just one, big product and therefore be unable to have each team have a separate product. In this case, you can achieve many of the same benefits of product per team by giving each of your teams a coherent subset of the functionality of the one, big product. Each team can then focus on making sure customers are getting the maximum value from that subset of functionality. In this approach, it is essential to choose the functional subset in a way that minimises coupling and dependency between the teams.

Try Starting Small

If you are building a new, significant product from scratch, then I would advise you start with a single, small team. Once this team has developed the skeleton of the product, you will be in a better position to bringing more people to work on the product. As you do this, at some point, you will need to switch from a single, small team to multiple teams. Consider seeding each new team with individuals from the original core team and dividing work as recommended above.