← back to the blog

Putting the "Team" in Product Team

Posted on November 5th, 2014 in agile, management by Simon

The title Product Team is applied liberally in organisations adopting Agile as though the two concepts are intrinsically linked, i.e. because we do Agile we are therefore a Product Team. Even though the two are complementary they don't cause one another. So let's explore the Team part of Product Teams in its own right.

Defining a Team

Working Groups vs Teams

Amongst the companies I've worked at there have been differences in the way people are brought together to deliver change within development. I struggled to classify the differences I had experienced until reading the excellent thesis paper "Integrated Product Team Effectiveness in the Department of Defense" by Gregg B. Monk.

In the paper the author identifies two main types of collaborations, Working Groups and Teams, which I found a pretty close fit to my own observations. I've broken down the differences between the two classifications below and added elements that I have identified as well.

Working Groups

Working groups are formed to achieve a specific goal, such as a project, and are disbanded once the goal has been achieved. Due to this the group is reliant on the individual talents of those within it to achieve the desired outcome. The short term nature of the grouping generally ensures that most members have a shallow understanding of the problem domain throughout the engagement. This in turn leads to a heirarchical assigning of tasks by the most senior person in the group who has the context or relationships to steer the delivery.

In addition to achieving individual deliveries, this type of collective is usually promoted within heirarchical organisations with an established management structure and short term planning through discrete pieces of work. Working Group information usually must travel up before it can reach another team through team leaders or management chains. Throughput is often constrained by these layers as well to keep control of the changes.

Working Groups are also generally organised around areas of influence who have budget to promote their initiatives. Alongside this, many areas without influence are denied investment and fall into disrepair.

With a Working Group, the sum of the parts are greater than the sum of the whole due to the overheads of coordinating the group and of unfamiliar faces becoming acquainted.


Teams are formed on the premise that performance is less about individual talent and more about assembling complementary pieces who will over time outperform individuals.

Teams require time to bond and after this time form an interdependence between team members, because of this it is important to take into account more than just technical skill-sets when forming the team. Effective team builders are able to identify individuals who will complement each other even if all team members are not "superstars".

If the team bonds effectively it will likely follow Bruce Tuckman's Forming, Storming, Norming & Performing model proposed in his paper "Developmental sequence in small groups". Whilst Forming, individuals in the team are likely to test limits and ways of working with each other to find what is acceptable and productive. Storming will herald interpersonal conflict as some team members struggle to accept their role within the team and display emotional responses. As this phase subsides, conflicts become less frequent and impactful, and team members accept each others contributions during the Norming phase. Once detrimental conflict has been removed from team behaviour, the team starts Performing and pulling for each other to achieve their common goal.

Once the above sequence has played out the Team reaches a point where the sum of the whole is greater than the sum of the individual parts. The team itself becomes less succeptible to outside influences that negatively impact its goal, which can become a double edged sword in environments where some teams need to sacrifice for the whole.

Working Groups are usually not given the time to reach this level as initiatives begin and end in a relatively short timeframe, measured in weeks or months. Products on the other hand are long running entities and exist for much longer timeframes, generally years, and so the Team supporting the Product exists for the requisite time to start Performing.

It is an organisational decision which of the above collaboration techniques to utilise with their development function. Some organisational attributes I've noticed correlating to each technique include:

  • Working Groups
    • High levels of Project involvement
    • Short term planning
    • Have experienced high levels of recent growth in either scope or complexity
    • Lack of an architecture
  • Teams
    • Minimal Project involvement
    • Defined vision and roadmap
    • Stable environment
    • Defined architecture and responsibilities

In the longer term it is generally accepted that Teams are a more efficient option than Working Groups, however require higher levels of maturity to be in place both within the organisation and the IT architecture.

Next... Putting the "Product" in Product Team. Until then, enjoy Bonfire Night!