Pattern: one product, one team

From the author

This is the first in what may become quite a few pattern blogs. These are short summaries of a useful patterns in modern software product development. The idea is that they start off a bit ‘rough around the edges’ but are refined over time as I discover more and respond to feedback. The patterns will build on and compliment each other

Some of these patterns I have quite a lot of confidence in, others are still emerging in my thinking.

Pattern Summary

The most effective way of developing software is to define logical products and assign a dedicated self-managing team who own the product, from discovery to design and build through to, and including, operation.

Definitions

For the ‘big picture’ definition of a product see Marty Cagan’s definition Product = Customer x Business x Technology”. In the context of this pattern a product is a bounded piece of functionality that meets a business need and offers value to a user group. So a SaaS company that offers a few enterprise level products may break this product up into a smaller set of products. You could call this a ‘feature’ except the word ‘product’ denotes a fuller experience which includes the product packaging, metrics, user feedback loops and so on

A team in this context is a small, cross functional, independent and aligned group of people who are a full time. Of course a team can leverage consultants and other teams, however the team should possess the basic skills, permissions and connections to bring their product to market, and to operate the product. Teams should be small enough to be manoeverable, the classic rule of thumb here is the ‘two pizza’ Amazon rule: internal teams should be small enough that two pizzas would feed the entire team.

Variations

One team — multiple products

In this arrangement a single team develops and manages multiple products. This has the downside of splitting focus but the advantage of offering new challenges to the team.

This pattern can be effective if the team has a high maturity level

One product — multiple teams

Sometimes known as a ‘stream’ or ‘tribe’ approach this pattern sees a single product split across two or more teams. The chief issue with this pattern becomes how to logically split the work between these teams. If the teams specialize in a particular business sub-area then this risks being a confused version of the ‘one product = one team’ approach. If the team split is along technology lines — e.g. a front-end team and a back-end team then the cross-functionality of the teams is compromised. If the teams are inter-changeable, i.e. they don’t specialize then in practice this could be considered one large team — a ‘team’ being simply a way of preventing meetings from getting overly large.

This may be an anti-pattern possibly?

Reference

Pattern: Product Vision and Strategy

Of Patterns and Frameworks (Chris Lennon)

See also

Team topologies

Spotify engineering culture

Marty Cagan — Missionaries vs. Mercenaries

Feedback wanted

Do you have experiences with the variations — one team = multiple products or one product = multiple teams? What have you found that worked? What didn’t work?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chris Lennon

Chris Lennon

Agile coach. Ways of Working researcher. I live in beautiful New Zealand and work for Spark. I am also the founder of a start up — voyzu.com. Views are my own.