Language is powerful tool. The words we use are labels for concepts that exist in minds. They’re the mechanism for conveying our perception of reality to others. We often don’t take full control of this tool, using phrases, metaphors and vernacular that generalises our concepts to the lowest common denominator.

I’ve been thinking about this with reference to the labels we give to roles in Scrum, particularly the Product Owner.

The term “Product Owner” assumes quite a few things.

Firstly, it assumes that the primary object or concept in Scrum is the ‘product’, an application or software tool that encapsulates functionality to solve a specific need or problem. The product is usually branded, becomes a noun, and is marketed as an entity in itself. Products vie for attention, competing with each other. App Stores came into being to allow easy access to the multitude of products that now exist. The product in the form of an app is now widely accepted as the default mechanism to deliver functionality to customers.

The second assumption in the term “Product Owner” is that ownership of the product rests with the individual who bears that role. That person is responsible for product, working out the business plan and strategy, prioritising features, and signing off on the features once delivered by the team.

But, going back to the first assumption, is ‘product’ the right concept? One of the drawbacks of a product-based mindset, specifically in organisations is that a product only provides a limited set of feature that a customer or employee needs to perform when interacting with the organisation. To perform all the tasks a typical customer or employee wants to do, they have to switch between multiple products, often facing a huge variety of interfaces and usage paradigms. What makes this worse for the product users is that more often than not, organisations structure themselves around these individual products, with separate teams or business units supporting separate products. This has the side-effect that anyone dealing with large organisations knows all to well – customers are passed from team to team for even the simplest of requests, frustrating them and delaying the resolution of their requests significantly.

How do we resolve this? We elevate our thinking out of the product-domain into that of the customer journey. We step back and follow the customer through their various interactions with the organisation. We re-organise ourselves into teams that understand these end-to-end journeys and endeavour to make these journeys as friction-free as possible, perhaps even joyous. We may still end up with a number of teams focusing on a single journey, but now they work together to sculpt the best solution instead of only taking responsibility for their particular product that deals with a small part of the journey.

This however rubs up against the second assumption listed above, that the Product Owner is responsible for the product and is usually mandated to make sure that the product is earning its worth. If the overall customer journey requires a particular product to lose some features to another product to streamline the flow, or, even more severe, to be replaced completely by another system that serves the customer’s purpose better, what then?

When we move to this model, Product Owners must relinquish their tight hold on their ring-fenced products and instead work together with other Product Owners to create the ultimate journey. Organisations will need to be very specific about the measures of success ascribed to initiatives – the overall flow through the journey will be the key measure.

Perhaps then we should move away from the term “Product Owner” and instead use Customer Journey Custodian?