← back to the blog

Putting the "Product" in Product Team

Posted on November 20th, 2014 in agile, management, architecture by Simon

As an architect it is not feasible to solely concern yourself with the design of the system, you have to also apply the same principles to the delivery teams who produce it. When you apply Agile and SOA principles to these teams, you are aiming to create Product Teams.

What's a Product?

Loosely Products are capabilities, or groups of capabilities, that the organisation wishes to have. When defining a product, SOA principles are helpful in identifying how your systems should be organised. Products share many of the attributes sought in services.

Products are Autonomous

Products don't rely on long chains of dependencies to facilitate the work they are responsible for. Business logic is self contained within the product.

Products Change Independently

Products are releasible on their own without needing to be staged with other physically separate systems.

Products have Identifiable Discrete Business Accountability

You can identify a single responsible person who is accountable for the product's function within the business. In a number of cases, if the product was not automated this person would run the team of people that did the job instead.

If multiple people are sharing accountability for the requirements you have grouped into your "product" then you don't have autonomy or clear business accountability.

Why Product Teams Anyway?


The main driver for moving to Product Teams within an Agile environment is efficiency. Product Teams are generally accepted to be a very efficient approach to delivering change due to three attributes that they exhibit:

  1. Stability
  2. Domain Knowledge
  3. Limiting Hand-offs

As explored in my last post, Teams are stable and therefore have time to bond which increases their efficiency. Secondarily they are able to build up significant domain knowledge in the problem space they are working within. This domain knowledge reduces the amount of specification that is required for new or changed features and also allows the team to identify further opportunities for the product. Finally as the product itself is autonomous the team has reduced or removed the need to rely on other groups to provide output which will allow new features to function. Hand-offs are inefficient as they generally require a knowledge transfer to facilitate the work, a reprioritisation for one of the groups involved and often a co-ordination of multiple releases.


Product Teams are great mechanisms for encouraging ownership both within the business and within the change team itself. An accountable team cares about the product they are responsible for and is more likely to take decisions that are in the best interest of the team and not the individual. Further to this, the team members become accountable not only to the product but to each other as they are responsible for success or failure, not someone higher up.

Using a Service Catalogue to Identify Products

If you are fortunate to have a service catalogue to refer to already, you will likely find some variation on the below:

Business Capability Home Loans
Capability Description Mortgage products for retail clients.
Business Owner Head of Lending
Other Key Stakeholders

Lending Operations Manager

Service Level Objectives

24/7 Uptime for Home Loan Applications
100 Home Loan Applications per Hour

Business Processes

Home Loan Application
Home Loan Dispersal

Supported Products 

Basic Variable Rate Loan
Basic Fixed Rate Loan
Premium Variable Rate Loan
Premium Fixed Rate Loan

Supporting Products

Account Management
Payment ExecutionArrears Management
Collateral Management

Product Description

Specifies Home Loan Product features, applies fees, interest, statement schedules, amortisation schedules to an Account.

If you are not fortunate enough to have something like the above, then you're really going to want to be doing some prep work. Without having an understanding of the business you're supporting your teams will be lacking in direction.

Service catalogues at their core try to quantify the business capabilities that you are supporting, which is fundamental to being successful with Agile.

Once you have defined the service you are trying to offer you need to decide whether it is the right size to be maintained by a single team.

Up next, putting it all together.