INTRODUCTION

I have engaged with several Product Owners; most of whom are our clients, but some are colleagues at Endava who fill the role of the Product Owner for our clients. The latter set-up requires a lot of trust and I have illustrated some of the enablers that create and support a relationship of trust on both sides in a previous blog post.

This post is not about the pros and cons of different team set-ups. It is about growing people into Product Owners. Product Owners come from various backgrounds (see [1]). For the purposes of this post, I am focusing on Product Owners that have a background in agile business analysis. If you trust the relevant sources [2,3], the Product Owner is so multi-skilled that they appear to be "Superman". There is no guide to becoming Superman. Therefore, I frequently have discussions with my junior colleagues about how to develop the skills required of a Product Owner. Surely, there are some soft and hard skills you must learn, like stakeholder management or creating a convincing product vision. But most of the time, product ownership is about making decisions to move the product forward. While working with many successful product owners, I have observed an approach that effectively supports decision-making. You can practice this approach ‘in the small’ long before being in the role of a Product Owner, e.g. when acting in the capacity of an agile BA, working as part of an agile delivery team.

The aim of my present post is to define this approach and illustrate its application in a fictitious example from one of our key domains: Payments.

THE STORY

Imagine you are a business analyst working with a highly competent Product Owner to develop a portal for merchants to manage their credit card payments. The initial goal of creating the portal is to save costs. This remit was given by the COO and the CPO (1) of the company to the Product Owner. The Product Owner has worked out that self-service over a web channel will be a large contributor to reducing merchant servicing costs, helping to reduce the overall customer servicing costs of the organisation.

That's the context, so here is the approach:
Step 1: Go breadth-first and explore options to achieve your objective and decide on one!
Step 2: Go deep with the chosen option to create value!
Step 3: Observe and revisit your decision!

You might argue that this has already been done by the CPO and PO. The objective was to reduce the costs, the decision was to focus on self-service and now we just build it. That's simply wrong. The principle of conscious and responsible decision-making applies at any level. Or, as they say: "One man's floor is another man’s ceiling". In this sense, the steps in our approach are applicable on all levels of the delivery chain, from the vision to the running software that can be used by your customers or provide insights about your customers. The same approach is relevant across the organisation from the CEO to a person in the team designing the tools for the delivery pipeline.

Let's continue our story to make it more tangible: Now you, the BA, dig deeper into the recent tickets from the client’s service desk dealing with all service requests from their customers. You find out that there are about 50 different self-service cases that are candidates for implementation, so do you:

◻ Provide a detailed analysis of all the 50 options, so they can be implemented (good old times).
◻ Go to the PO and ask her what to do (not my problem).

Tick your answer! If you are presented with the options formulated so simplistically, no-one would tick either of the boxes. Still, I regularly observe tendencies to do one or the other or sometimes both of these things (you can actually tick both boxes and follow them one after the other).

So what should be done instead? If you apply our approach: you (1) go breadthwise and enumerate all 50 options and come up with some classification criteria. You can use or derive some of the criteria from the objective to reduce the overall costs: "What are the most frequent cases?" "Which are the ones taking up most of the service desk team’s time?" "Which ones can we perform as self-service over the web channel, because of the required authorisations?". (2) Having assessed all of the cases based on these criteria, you decide that the self-service case to start with is the adjustment of the shipping address for a payment terminal that needs to be delivered.

Once the decision is made on this level, you work with the team to (2) go deep with the chosen option to quickly realise some value. And as you progress with implementing this option, some more options arise on the next level (the other man's floor): "Do you verify the new payment terminal address, or not?" "Which roles are allowed to change the delivery address?" Various different team members will be able or feel empowered to make these decisions.

FIGURE 1 - Option Universe

So, the first self-service case "Change Terminal Delivery Address" gets built and delivered. The customers are using it heavily. Is the story over? Not in all cases. We are talking about products not projects. It is not about the feature that you released, it's the ongoing relationship with your customer that this feature establishes. (3) Observe and revisit how your customer uses your features. Terminals slowly get replaced by mobile devices that are already owned by most of the merchants. There is no longer any need to ship terminals. You want to remove the function and clean up the technical (and in this case the feature) debt that you created and keep your product maintainable.

AGILE ANALYSIS APPLIED

Let's reflect a little on our invented story. True agile analysis is an enabler that supports the approach we describe above. Daniel Kahneman created the acronym WYSIATI – "What You See Is All There Is" [4] to describe the cognitive pitfall when our brains create a seemingly coherent story based on information of unknown quantity and quality. The positive effect of step (1) is it enables us to make decisions in the VUCA (3) of our everyday world. But on the other hand, it creates a framing effect towards the information that we see, which can lead to overconfidence and a danger of making the wrong decisions quickly. There are two ways to avoid this: (a) we need to make sure we are getting all the information by stepping back and taking time to ask the not so obvious questions, such as "Which support cases can we perform as self-service over the web channel?". Alternatively, (b) we need to ensure that if we make the wrong decision (quickly, saving some analysis time), the situation can be recognised, and the impact of the mistake, corrected quickly. But remember, you need to make (or at least recommend) a decision. Your contribution decreases if you passively elicit requirements and ask others to make decisions.

During the execution of step (2), agile analysis helps us to handle edge cases and errors by thinking through how we enable a machine – who cannot deal with VUCA – to realise what your customers need. You cannot avoid these cases and need to think them through, because if you don't, you’ll find that ten days of development saves you one hour of analysis! But keep your eyes open, because in some cases you can follow the steps again on this level, creating more options based on creativity or experience. For example, you can embed Google Maps to select a delivery address rather than requiring it to be typed in manually. Some of these decisions will not be separately releasable, but they will help us to release (the rest) faster.

Step (3) adds a new dimension to agile analysis: time. Classical business analysis was done in the change – operate cycles, where time is frozen for the change cycle. In a product delivery model, as shown in the example above, where terminals cease to be shipped because terminals cease to exist, we need to learn (to progress) and then unlearn (to adjust). For me personally, this is one of the toughest lessons learned: we know that today the world is no longer black and white, but shades of grey, but we now also have to remember that the dark grey of today maybe the light grey of tomorrow. This evokes the concept of "strong opinions weakly held" [5]: Have a strong opinion in order to make progress, but hold the opinion weakly in order to improve or correct or even revert the initial solution. Continuous delivery must start with the requirements; it provides the platform to make mistakes fast and correct them, or to adapt to a changing world.

CONCLUSION

I recommend you read the context of my little example as: "We need to improve the self-service capability to reduce our operational expenses for customer care. Here are some further constraints …. Go and figure out how!" For the individual like you and I, working as we have described in this context, this means taking ownership and accepting responsibility for delivery of the product. Most of us know what to do, but we often need the discipline to do the more difficult thing that we are afraid to do, than doing the easy thing that we would like to do.

The Product Owner provides the overall context for her product with a set of constraints and objectives through the "Product Vision". But, by using decision making skills of a Product Owner yourself, you can refine their vision into further constraints and sub-goals and make (or at least propose) further decisions to move the product forward. Over time you will gain trust and experience and your area of influence will grow. We should give up on the idea that more senior people make smarter decisions than the people who work for them, especially in their own specialist subject matter. Giving up this legacy thinking will lead to empowerment of people like you in the right place, where the knowledge is, versus senior management, who will not be contributing to good products by making these decisions "in the small".

So please give this thinking a try and practice some product ownership in the small. It will help you to become a great Product Owner in the future.

END NOTES

(1) Chief Product Owner
(2) For example, if we need a physical signature for legal reasons, it might be better to defer this case
(3) Volatility – Uncertainty – Complexity – Ambiguity, online here

REFERENCES

[1] "Where do Product Owners come from?", Scott Ambler, 9th July 2018 – published here
[2] "Agile Product Management with Scrum", Roman Pichler, Addison Wesley, 2010
[3] "The Professional Product Owner", Ralph Jocham, Addison-Wesley, 2018
[4] "Thinking Fast and Slow", Daniel Kahneman, Penguin Books, 2011 (pg. 85-88)
[5] "Strong Opinions weakly held", Paul Saffo, online here