Are we nearly there yet? The role of the product owner

Here are a few expressions you may have heard:

"Too many cooks spoil the broth."

"If something is managed by many, many things will be missed."

That last one was coined by Sir Alec Issigonis, who, in the mid-1950s, was trusted with creating three vehicles for the British Motor Corporation. The first should be large and sporty, the next medium-sized for a typical family, and the final model a small runabout for nipping down the shops.

Unfortunately for Sir Alec (and just as he was making progress on the first two), along came the Suez Crisis. It's hard to believe, but fuel became incredibly scarce and expensive, so he was asked to focus purely on the smaller car. Not only did it need to be inexpensive to build and maintain, but it must also be safe and economical to run.

The car we all recognise today as the Mini faced many complications before it went into full production. Fortunately, Sir Alec had a clear vision of the project's end goal and a great understanding of automotive design. These insights helped him overcome the hurdles he faced with innovative ideas that formed the basis of vehicle design for decades. He was, after all, the expert in his field.

So we have an expert. What next? Someone has to put their product vision into practice, and however adept Sir Alec was, he couldn't do everything himself.

As with many large goals, they suddenly don't seem so big when broken down into small incremental chunks. In fact, if you break down that large goal into smaller goals – each with its own set of tasks – you start to see a clear picture of how everything should come together. What's more, the work can be divided and assigned to the right people to carry out.

Of course, things don't always pan out as you intended, and you may need to adapt, reprioritise and even abandon tasks to reach your goal.

Take the Mini's suspension – there simply wasn't enough time to make it as Sir Alec envisioned. So, he went back to the drawing board (quite literally) and came up with an alternative that was just as ingenious as initially intended but far quicker and cheaper to make. That's what an expert does!

In Scrum terminology, we'd almost certainly call Sir Alec the product owner of the Mini project, but what exactly does that mean?

At Zengenti, we use the Scrum framework, "Scrum helps people and teams deliver value incrementally in a collaborative manner", says Scrum.org. A typical scrum team comprises developers, a scrum master and yes if you can still remember the title of this blog, a product owner! For us, they are the client representative in the team and critical to the success of each project.

Here's an excerpt from The Scrum Guide's definition of a product owner:

As with the Mini, it's compact, but there's more going on underneath the bonnet.

It sounds like a lot of responsibility being the product owner – aren't you paying us to do all of this?!

Whilst we are the experts at delivering highly-functional and great-looking web applications, we can't be experts in every field for which these products are designed. We would make a great attempt at it, based on our wide-ranging experience, but ultimately we can't deliver an outstanding product without you and your application-specific expertise.

We need several things from you to stand the best chance of creating the product you want.

Like Sir Alec, the product owner needs to be an expert in their field and have a clear vision of the project goal. If they don't know what they want, how can anyone else?

They must express that goal clearly when collaborating with the development team to break it down into well-defined tasks, each with their own mini-goal called a 'Definition of Done', or DoD. This definition is the measuring stick you use to determine whether a task is complete.

Every task the team undertakes is tested against their DoD to ensure completion, so it's essential to get these right.

What happens to all these tasks? Well, the product owner is also responsible for maintaining something called the product backlog. The backlog is the definitive list of tasks that, when complete, go towards an incremental release of the product. In other words, this is everything that is needed to make the product. If it's not in the product backlog, then it isn't going to be built.

Scrum Teams often categorise tasks into their sub-goals called epics. Torturing the car analogies a little more – it was either that or The Lord of the Rings – these would be along the lines of "Gearbox" or "Brakes", and each would contain tasks related to their parent epic.

Critical to maintaining the product backlog is prioritising those tasks. Time is money, and both are limited on a project. Making sure the developers complete the most important work in the correct order is crucial to an efficient development process and a project's success. The nearer a task is to the top of the backlog, the more critical it is to the project's success.

When creating, maintaining, and prioritising the product backlog, it's good to have an idea of the Minimum Viable Product or MVP. The MVP is a no-frills approach that focuses on producing a working, shippable product that the team can improve in response to user feedback. It's intended to avoid the scenario where a team spends large amounts of time and money trying to deliver a perfect product, only for it to fall down the first time a real person uses it.

After all, a flash paint job with go-faster stripes may look great, but if it's delivered at the expense of developing the suspension, it will be a bumpy ride.

Availability is essential. A typical project requires the product owner to be available for a 15-minute daily stand-up meeting. This meeting is where the team discuss what they did yesterday, what they plan to do today, and any problems they're having that could affect the work.

There's more! Aside from the stand-ups, the product owner must attend three further meetings each sprint – review, retrospective and planning. As the names suggest, everyone gets together to show their work, discuss how the sprint went and then plan the next one.

They do this by confirming and then discarding any completed tasks and selecting new ones from the prioritised backlog the product owner has so helpfully made.

If the product owner doesn't attend, the project will start to break down quickly.

Remember the camel analogy? Well, that's perhaps the most important thing to take away from this article.

The product owner doesn't have to be the CEO of the company. They may not be anyone high up in the organisation at all. What they must be is the single voice of the client. They are the filter through which all client decisions must come, with all customer and stakeholder needs represented.

That doesn't mean the product owner must make all those decisions themselves. It's absolutely fine – positively encouraged even – for the product owner to go and discuss anything product-related internally, as long as they come back with a singular direction.

Scrum is an Agile process, and, as the name suggests, the scrum team needs to be nimble and move quickly.

To do so, it must have a clear direction. Having several client representatives – each with their own vision of the product – makes it almost impossible to move forward in any meaningful way.

Imagine driving from Lands End to John O'Groats relying only on directions given to you by several passengers, each one telling you to go a different way at every turn. If you did make it there, you'd have driven far further than necessary and paid a lot more in fuel than intended.

• Each project needs one product owner
• They don't have to be the CEO, but they do need to be the expert
• The project needs to be led by the product owner in the form of a well-planned product backlog

Sources:

https://en.wikipedia.org/wiki/Alec_Issigonis

https://www.scrum.org/resources/what-is-scrum

https://scrumguides.org/scrum-guide.html#product-owner