Pattern: one product, one team
Foundation Pattern: One product equals 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
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?
