The Path to Product Teams

Oli Gibson
Oli Gibson
Share:
  • Twitter
  • Linkedin

Through my work at ThoughtWorks, I get to see a lot of teams delivering technology products. Over the years, I’ve coached and worked with some fantastic companies, but I have seen very few true product teams.

Most companies are not yet at the stage where they can operate product teams like Amazon, Google or Netflix. People often say these companies lack a product mindset or don’t have the right ‘culture’. However, I think it is about having the organisational readiness to operate product teams that empower people to work as they need to.

All organisations could benefit from having product teams, but to operate effectively, they need to be ready for them. There are some significant changes in organisational design necessary to make product teams effective. Often people find these changes surprising and particularly challenging, but the benefits can be far-reaching.

The first step on the path to product teams is to recognise where you currently are. You can then identify the characteristics and activities you need and plot a route towards that for your organisation. To help you find your way, I have built on Amplitude’s team structures diagram and explained the characteristics of teams at the four stages of development.

The Four Stages of Team Development

1. Agile Delivery Teams

On the first step of the path are agile delivery teams. These teams exist to deliver what the business asks for, not to decide what to build.

They own the build and test stages of product development. In some cases, they can also release the code they developed. More often though they are releasing to a staging environment and there is a separate operations team that manages the product in production.

Agile delivery teams are not cross-functional. They usually are made up of just developers with a backlog ‘owner’ in the form of a project manager or business analyst. Theses teams are all about output and are managed accordingly. They often exist in companies with significant project management functions and tend to be measured based on team velocity or their ability to hit time-based deadlines.

2. Design-Build-Run Teams

The next stage of team development is the Design-Build-Run Team. These teams extend the responsibilities of the agile delivery team to include product design and managing the product in production.

At this stage, teams begin to own the usability of the product. They will typically focus on just visual, and interaction design but are ultimately responsible for ensuring that the product is easy to learn, efficient, effective and engaging.

They are now also responsible for the feasibility of the product in production. The team will have to ensure the product is reliable, maintainable and scalable.

Design-Build-Run Teams are cross-functional but don’t include product managers because they don’t need to decide what to work to do. Instead, these teams will receive requests to deliver functionality from business stakeholders.

3. Feature Teams

The next stage is feature teams. Up to this point, teams have been all about delivery, but feature teams begin to have some decision making power. They often will be able to decide on the user requirements and sometimes how to implement these features within the product.

Feature teams often look like product teams. They are usually cross-functional and have development, design and some form of product management capability. Unfortunately, they are not truly empowered to make product decisions.

In feature teams, product decisions are owned by a business stakeholder that sits outside the team and makes feature requests, generally through a roadmap. It’s therefore not possible to fully operate as a product manager from within a feature team. In fact, it can be downright dangerous. Although the stakeholder outside the team is the one responsible for the product decisions, they may still find a way to blame you and your team if their hoped-for results are not realised.

4. Product Teams

Finally, we arrive at product teams. In comparison to feature teams, they are fully empowered to identify opportunities to serve the customer and develop solutions that work.

Product teams are responsible for outcomes. It is up to them to ensure their product is delivering value to its customers and is capturing value to make continuing product development viable. The results a product team is trying to achieve may vary, but what cannot is their autonomy to decide how to achieve them.

Why transition to product teams?

The transition to product teams means the team now exists to serve the customer directly, rather than to serve an internal business stakeholder.

This is a profound change, that affects almost all the team’s ways of working, resulting in greater inspiration, motivation and morale. More importantly, it unlocks the knowledge and abilities of the people within the product team, leading to consistent innovation that generates value for your customers and your business.

It is the trust and empowerment of people within the product teams that enables companies like Amazon, Google, or Netflix to achieve disproportionate results. These companies trust the people nearest the customer problem to make the best product decisions, and you should do the same.