The term “Product Owner” is used in the Scrum Guide (pdf version) 35 times and the term “Product Backlog” is used 59 times. But what is a “product”? Unfortunately, that is a big question and that is left open to interpretation. The definition of “product”
Let’s move away from Scrum for a bit and move to the world of shoes. Yes. Shoes. Your shoes have at least 15 parts to it (did you know?). So, what is the product? Shoes? or the 15 different Parts? Sure, you are not going shopping to buy the “individual parts” (unless you are making the shoe). So what is the “product”?
Lemma 1: View your product from the eyes of your paying customer/user
In the eyes of those making these parts, the shoe manufactures (e.g. Nike, Reebok, etc) is the customer. And the “products” become the shoe parts. In the eyes of the shoe manufacturers , the paying customer is the shopper and hence the product is “shoe”.
Now even if we all agree on buying shoes (just say men’s shoes), here are a few variables to play with : size, width, color, material, pattern, and style. Let’s consider only three variables, size, width and color. There are about 38 sizes for adults (1 through 20 with increments of 0.5), 18 widths (4A to 9E), and 31 colors. So if you consider each of these unique combinations, you got 212014 “types” of shoes just considering only the three variables (and if you consider the other variables, the combination will exceed a million).
And if you treat these individual shoes as “products” it is an overkill. Sure, the product that the customer is buying is a shoe, but will Zappos see it the same way as the customer sees it? Probably not. Zappos probably sees all “shoes” as “one product”. Which brings us to the first lemma in defining a product
Lemma 2: Your product definition need not be isomorphic.
That is, the way your customer sees the “product” need not be the way the organization sees the “product”. This lemma can also be extended to “technology”. Hypothetical example – Microsoft PowerPoint comes in five flavors – PowerPoint for Windows, PowerPoint for Mac, PowerPoint for Android, PowerPoint for iPhone/iPad, Office 365 PowerPoint . The user may even buy different versions separately, but Microsoft may not manage them as five separate products, they may just manage them as ONE product. If these five versions of PowerPoint were managed as separate “products” (and hence multiple product owners, and product backlogs), this leads to a lot of dependencies, hand-offs, and co-ordination between the product owners. This is an unnecessary overhead for the organization. Managing it as “ONE” product (hence one PO and one Product Backlog) eliminates these headaches for the Product Owner (and now the Dev. Team has to be a lot more cross functional( Windows client development skills, web development, iPhone development skills, Android development skills, etc) relative to their scenario). And by using an appropriate Definition of Done (example – should work in Android, should work in web, etc) the inter-operability of features between different technology platforms be ensured (Example – you create a PowerPoint in Windows, your friend can open it in an Android phone or their Mac book Pro).
Lemma 3: Make your product definition as broad as possible, but no broader.
“Make your product definition as broad as possible…”: An example here helps. I was contacted by an executive of an auto insurance firm. The organization was “doing scrum” but the executive team was not getting the promised benefit. Upon investigation, I found that their “product definition” was fragmented. “New Policy enrollment” was considered as a separate “product”, “underwriting” was considered as a separate “product”, “policy management” was considered a separate “product” and “claims processing” was considered a separate product. Hence there were four different “product owners” managing four different “product backlogs”. But all these capabilities were within the organization. Let’s imaging that “claims processing” is completing their first Product Backlog Item (PBI)
- But this PBI may have a dependency on 35th PBI on “new policy enrollment”, hence it creates inventory
- Assuming that the 35th PBI in “new policy enrollment” is completed, someone now has to do the integration testing. “Claims Processing” Dev Team(s) is not going to test it, as they completed it many sprints ago as per their Definition of “Done”. “New Policy enrollment” Dev Team(s) are not going to do the integration test because “Claims processing” is not in their “product backlog”. So, now, we need a “Testing team”
- The integration testing may lead to defects which then would mean that there would be rework
- There are many other problems including hand-offs, and waiting in the process due to the fragmented definition of “product”.
- Each “product” was managed using an annual budgeting process, which lead to a whole bunch of other dysfunctions
My cure to these problems was to look at things from a customer perspective and make the product definition “broader”. Hence “auto insurance” became the “product”. And we had ONE product backlog. When all the older Product Backlog Items (from the four different “products”) were ordered in the new Product it became immediately evident that what was #1 PBI in “claims processing” was actually the 50th item in the new Product Backlog. The “Claims Processing” Product Owner was locally optimizing their product backlog at the expense of sub-optimizing for the whole organization. No wonder the executives were not seeing the benefits of Scrum
Making your product definition broader avoids local optimizations
“…but no broader”: Very broadly speaking, the workflow of auto-insurance is similar to that of life-insurance, P&C insurance, home insurance, renters insurance, etc. (yes, there are different rules and regulations governing these, and the underlying data set and algorithms used might be different, and these probably can be abstracted during the implementation using good design patterns). But there might be different elements at play including political boundaries, incentives and bonus, technologies, organizational boundaries, target customer persona, etc. And with these variables at play, making the product definition way too broad may immediately kill the Scrum adoption. It is possible to expand the definition of the “product” over the course of time, but that is a longer game.
Going back to our PowerPoint example, considering all flavors of PowerPoint as product may be helpful, but defining the “product” to “Microsoft Office” may have its own political, and organizational challenges. In organizations using COTS products (e.g. Salesforce, SAP, etc)for their development, it is impossible to extend the definition of the product to include the development of these COTS products (as they are developed and maintained by a different organization). In the same vein, Amazon videos and Amazon AWS might be considered different products as they serve different personas and solve different set of customer problems.
Conclusions: In general, broader definitions of product
- focus on solving actual customer problems
- avoids local optimizations in organization
- eliminates management of dependencies between different micro- “products”
- and hence enables organization to “be more agile”
Helping Teams and Organizations be Agile 