Defining Products
Introduction
Let’s consider a small organisation using Scrum. Let’s assume for now there is just one team working on a certain product this company is creating. The Developers have everything in their hand, they have all the competences necessary to “get the job done”. Of course, this makes their work very flexible and adaptive: if there is anything they need to change in their development, they can simply meet shortly, decide what to change and implement it.
For their business priorities they are relying on their Product Owner, a person that is “accountable for maximizing the value of the product resulting from the work of the Scrum Team” (Schwaber & Sutherland) or is “responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list. The Product Owner has profit and loss responsibility for the product, assuming it is a commercial product. In the case of an internal application, the Product Owner is not responsible for ROI in the sense of a commercial product (that will generate revenue), but they are still responsible for maximizing ROI in the sense of choosing – each Sprint – the highest-value items”. (The Scrum Primer)
From this perspective the Product Owner is a… Product - Owner, i.e. a person who has accountability (“owner”) over the whole Product. Given this 1:1 relationship in single-team Scrum between Product and Product Owner, it is important to understand what we mean with the word “Product”, especially at scale where a Product can be something very large, complex and consist of possibly many contributions and different deliverables. To add more complexity, in Composite Value Streams it is often the case that several different Products are being developed using various contributions and contributors in order to exploit possible synergies.