Get the Right Product Owner First

Building software is more than just writing code. One of the things we want to ensure in each project at u2i is that the way we work prevents redundancy. Getting the process right depends on many factors, and unlike common belief, some of them lay outside of the development team.

One of these “external factors” is the Product Owner role, which is very often underestimated. Engineering teams tend to focus on ensuring proper test coverage and building efficient technical solutions, failing to notice that being disconnected from the business side can have an even larger impact on the product they build.

Quick Recap

As you probably know, the Scrum framework defines three roles;

A development team responsible for building things. In perfect world, these guys can design, build and test the technical side of the product they’re building.

A Scrum Master – a person who’s in charge of making sure things are done “the scrum way”.

And finally, there’s a Product Owner.

Product Owner

If you have a strong technical background, there’s a high chance you’ve never really cared about this role. The most common perception is that’s a person working on the business side of the product, who knows what needs to be built and is able to verify that the work done by development team makes sense.

A Product Owner comes to developers, bringing their ideas on how the product should work. The latter are presented as user stories and stored in the backlog.

Once features based on user stories are delivered by the development team, the product owner verifies that it’s what was meant to be built.

Simple, isn’t it?

Typical Implementation

If you look at various tech companies, a lot of them use this definition of Product Owner when implementing Scrum.

And, since they’re tech companies, they tend to put a huge effort into getting their tech teams to understand agile, Scrum and everything that’s related to them.

When it comes to the Product Owner role, the person doing that is quite often picked randomly (or sometimes even non-existent).

Doesn’t our Project Manager know what needs to be done? That guy does, let’s make him our PO!

“- Hey, starting tomorrow we’re going Agile, and you’re the PO. – Alright, whatever.”

6 months later, despite doing their best, the team is still working in the same old way, except now they’re doing sprints and having daily stand-ups. It doesn’t really matter that they’re doing their best, something still isn’t working and no one has an idea of how to fix it.

The Product Owner Competences

As simple as it sounds, the PO’s work is more than just “knowing what needs to be done”.

When working on our process, we noticed there are four areas of competence that are essential for a good Product Owner.

If they lack some skills, you’ll notice that even though the Development Team and Scrum Master do their best, you’ll never be able to achieve the perfect state of unconscious competence.

Let’s have a look at them:

Business Knowledge

Since our development team doesn’t always know everything about the business domain of the product (it takes a lot to learn it), and in order to implement complex logic, they’ll need someone capable of explaining ambiguities. That responsibility naturally rests on the Product Owner.

It’s also useful if that person knows the why-s: “Why are we building that?”, “Why do users use our product?” etc.

Defining Requirements

You probably know the spec documents – the often 50 page-long documents which define what needs to be built. The problem with them is that lots of text and diagrams are not the most convenient way of expressing requirements. Unless it’s perfectly well-designed, it’s difficult to focus or figure out business priorities.

Your perfect Product Owner will be able to solve this problem by extracting the essence of product and present them as business perspective user stories.

Your team benefits from that in two ways:

  • It’s more clear why a certain feature needs to be build; that gives developers a better understanding of the product they’re working on.
  • More importantly, the Product Owner will be able to verify if what was built makes sense for the end user.

Decision Making

The Product Owner holds the interest of all people interested in using the product you’ve built. If you’re working with an external Product Owner, i.e. you’re doing consulting, the Product Owner may even be your “proxy” to the users.

Because they’re talking to a lot of people, they’ll need to be able to build their own product vision on top of inquiries they get and execute it. Keeping their priorities in mind, they need to be able to be assertive enough to say NO to their supervisors and take full responsibility for what’s built.

Managing the Product

Don’t mistake it for managing people – the development team should be able to manage themselves.

As the center point in product, the PO needs to be able to handle any chaos in communication. That’s especially important in case of events like releases – everybody needs to be on the same page and it needs to be clear what it is we’re releasing, when it’s done etc.

Let’s Get to Work

Without getting the Product Owner role right, even the biggest enthusiasm in your team won’t help much.

As in general with Lean/Agile methodologies, it’s crucial to start observing what happens in your team and find the sources of inefficiency. It may turn out that your development team and Scrum master are in fact in alignment and the problem lies somewhere else.

Be aware that the Product Owner position requires more skills than anticipated. If you let other companies build things for you, make sure you provide them a good person to fill this role. If you build software for other companies, make sure they know what being a Product Owner is all about. And, if necessary train them and provide support if they’re struggling with some of these skills.

And keep on iterating.