The Product Owner as superhero

Explore Assurity 18 January 2016 Joe Kearns

If you look at a few articles about Scrum's Product Owner role online, it won't be long before you come across an image of a Product Owner as a superhero. I often thought this concept was perpetuated by Product Owners themselves (Hi Product Owners!), but, over time, I've come to understand why a Product Owner really can be seen as a superhero.

When I'm delivering training, I always draw the Product Owner with a Batman-type mask and cape. Ok, so far so good. It fits with the standard PO as a superhero model.

But then I draw a 'V' on their chest and ask attendees what the ‘V’ might stand for. It doesn't take long before someone says 'Value'. It's not that difficult to work out, but the key point remains – a PO with a superhero costume and a 'V' on their chest means – just as Batman seeks out evil wherever it may be and deliver justice – a Product Owner exists to seek out value wherever it may be and deliver it to the organisation. Simple.

And they do have a super power!

For a Product Owner to be effective, they need the authority to say ‘no’ to a project, functionality, feature or story that a stakeholder, customer or team member has suggested.

The reality I see in going into the organisations I work with is that nearly all of them have too many things they want to do (ideas, innovations, projects etc.) for the number of people they have to do them.

Given this, the superpower a Product Owner has (or needs to have if they aren't empowered), is the ability to say 'no' to an idea or project that’s raised if there's no value in it – or if there's value in doing another piece of work first.

If you're a PO and not yet comfortable with saying ‘no’, then perhaps start by using the concept of 'now vs not now' before plucking up the courage to say ‘no’.

Product Owners are not necessarily the experts

While writing this, an email from Mike Cohn arrived in my inbox called 'The Product Owner does not need to be the sole source of knowledge' reinforcing what I've been saying about the PO in my training. If you take what I've said above about the PO seeking out value wherever it may hide and delivering it to the organisation, this makes sense.

Just as Batman isn't an expert on crime, he simply arms himself with all the gadgets under the sun to get the right information, at the right time, to be able to deal with any situation – he's a facilitator perhaps – then your Product Owner doesn't need to be the source of all knowledge. They just need to know who to talk to and how to get the right information out of them at the right time.

An example

A team I was working with was asked to automate the creation of (but not the sending of) 14 'credit letters' that a department in the organisation creates manually using Word templates every month. I worked with the team's Product Owner to poke around on what they want and ask a few more questions.

I asked how long it takes to create each letter and then how many letters they send out each month. 'Three to five minutes' and '2000 letters' were the answers. Aha! I now had a way to calculate the value of this piece of work to the business. By multiplying the 2000 letters per month by three or five minutes per letter, I calculated that it was taking the credit department between 100-160 hours per month to manually create these letters.

On an estimated average salary of $50,000 per year then, automating this piece of work would save the organisation $50,000 per year. This 'automated letters’' piece of work then represented $50,000 worth of value for the organisation. Great! We now had a metric whereby we could compare the value of this work against any other being put to the team.

But wait, there's more…

I wasn't fully satisfied. I then casually asked if there are any letters they have to create more often than any others. The answer was ‘Yes. Credit letter one, we send out 70% of the time’. Aha, again!

So given that credit letter one (whatever that was) was sent out 70% of the time, I deduced that that single letter represented 70% of the $50,000 value for this piece of work – or $35,000 (70% of $50k). I then asked what was the next most frequently created letter and the answer was 'Credit letter two, we create 20% of the time'. Aha again! A letter that’s created 20% of the time represents $10k of value for this piece of work.

So, in these two letters, we've accounted for 90% of the value for this piece of work. It should be obvious then that the remaining letters represented less than 1% or $500 worth of value.

When I explained that these remaining letters were an unlikely candidate for automation any time soon, they agreed and even sheepishly added, 'Well this letter here gets sent out two to three times per year and this letter here, we've never had to send out at all!'.

So, in two questions, I'd manage to slice the project down from 14 letters to automate to two. The end result was that – in our very first sprint – we delivered the ability to automate credit letter one and realised $35k worth of value.

Credit letter two was placed in the backlog as a piece of work valued at $10k that we would get to at some point in the near future. But there was other, more valuable work to complete first. And, of course, the  Product Owner was seen as a superhero. A good result!