A Product Team is a group responsible for the delivery of a software Product. In a high-performing Product Delivery Organisation it’s usually a multi-disciplinary team, iteratively developing the Product in response to new learning about customer requirements or changes in the Organisation’s business environment. There may be only one, or many Product Teams in a Product Delivery Organisation.
The accountable decision-maker for a Product Team is the Product Lead. Since Product Leads are often not software engineers themselves, being the accountable decision-maker requires clear and open dialogue between the engineering members of the Product Team and the Product Lead so that they make the best, informed decisions at the time.
The above diagram shows how the Product Lead is accountable for all responsibilities of their Product Team and that there will be one or more Product Teams within a Product Delivery Organisation.
One of the goals of this framework is to clearly, fairly and scalably assign accountability for maximum effectiveness. There are four things needed to fairly assign accountability:
- Understanding: the accountable person has to fully understand what they’re being held accountable for
- Information: they have to have the information available to them to ensure what they’re accountable for is being done to an acceptable standard
- Empowerment: they must have enough time in their working day to carry out the tasks required to ensure what they’re accountable for is being done
- Control: they must have decision-making power with the people responsible for doing what the accountable person is being held accountable for
As the voice of the customer and voice of the business, the Product Lead steers development of the Product and has decision-making power for the Product Team to set work priorities. Considering also the natural increase in Product Leads with the number of Product Teams, this makes the Product Lead the only fair and scalable role to be assigned accountability for a Product being delivered securely.
Another goal of this framework is for the desired outcomes to be emergent from simple, repeatable processes that can self-correct and adapt quickly to changes in the business environment of the Organisation. To achieve this, it requires Product Teams to manage one continuous improvement cycle.
Quality Improvement Cycle
The goal of a Product Team is to deliver a Product of suitable quality for the Organisation and its customers, which must be achieved in a way that meets the Organisation’s Compliance Obligations. The security of a Product is just one aspect of its quality. This framework utilises the ISO/IEC 25010:2011 System and Software Quality Model to ensure Product quality is well-defined.
A Product Team will likely not deliver a Product of suitable quality in all aspects immediately or maintain quality levels without ongoing effort. With the iterative nature of software Product development, a continuous cycle of quality improvement is required to achieve the Product Team’s goal.
The above cycle diagram shows how a Product Team delivers and maintains a Product of sufficient quality with a continuous quality improvement loop. Product Working Practices and Product Security Work prioritisation drive change in the Product, which is measured by Product Quality Metrics and Product Delivery Metrics, which inform and support improvements to Product Working Practices and Work Tracking System prioritisation.
In this quality management loop, Product Working Practices and Product Security Work prioritisation drive change in the Product, which is measured by Product Quality Metrics and Product Delivery Metrics, which inform and support improvements to Product Working Practices and Product Security Work prioritisation. It’s essentially the established ‘Plan, Do, Check, Act’ process for continuous improvement of processes and products, within this framework.
Use the navigation links on the left to explore the individual policy objectives for a Product Team, grouped by the artefacts the Product Team maintains.