Characteristic of a good product owner

Typically on most Agile projects, the success (or failure) of a project can heavily depend on how good (or bad) the product owner is and how committed they are. Good Agile teams that consistently d


Typically on most Agile projects, the success (or failure) of a project can heavily depend on how good (or bad) the product owner is and how committed they are. Good Agile teams that consistently deliver the right thing at the right time, and with quality in mind, will always have a product owner that is focused on the overall bigger picture and able to articulate this into the smaller pieces that are needed to deliver their vision/goal, i.e. the individual user stories. Anyone can take on the role of the product owner, but to be a great one is hard. Let’s take a look at some characteristics that great product owner’s have:

Relating the vision/goal to backlog items

A lot of product owners are good at making the business case for a project to go ahead, but very quickly end up with a backlog that is disjointed and seems disconnected from the original vision/goal that they started with. After a couple of sprints, it’s likely that most of the team (perhaps they too) have forgotten what the original goal was and why they’re doing the project. The phrase ‘can't see the forest for the trees’ comes to mind.

A great product owner will

  • ensure the business case is encompassed into a short vision statement,
  • makes this visible to everybody.
  • But more importantly, can always refer back to this when explaining every user story on the backlog.

One of the best ways to convey your vision/goal is with an elevator pitch. The product owner should

  • come up with their elevator pitch,
  • make it clearly visible to the team,
  • and constantly refer back to this to explain why the team is working on the prioritised backlog and the individual user stories.

Write User Stories with the team and allow them to contribute to the business value, i.e. the ‘So that…’

Often product backlogs are created by the product owner in silo and given to development teams. A lot of the time, the user stories are a set of task lists (or wish lists) the product owner wants the team to do. It can be difficult for the team to understand why they’re doing what they’re doing, especially if the vision hasn’t been stated.

A great product owner will

  • work with the team to come up with a product backlog that is
    • relevant,
    • links back to the vision,
    • but also includes the business value (i.e. the so that…).

This means the team fully understands the reasons and value of each user story and how it is intrinsically linked back to the vision.

The product owner must ensure that each user story has

  • a clear ‘why’ for each user story which explains the value/goal for the user
  • what the user is trying to accomplish rather than the feature in the system.

A great product owner will try to work with the team to solve the problem/issue for the user. This is likely to allow the team to solve the problem in a way any individual wouldn’t have thought of doing.

Respond to changing circumstances

For the duration of a project, business goals, technology changes, new regulations, or a competitor's latest release will likely mean that the business/project priorities need to be changed in order to adapt. Often product owners and senior management will try to stick to the original goal in the hope that they will be seen as correct. Often that is not the case, and the project ends up delivering something that is out of date before it’s even launched.

Product owners should

  • always be able to adapt to changing circumstances
  • and modify the current product backlog so that it’s inline with what’s current now.

The modern world moves at a rapid pace, and great product owners are able to ride the wave and change the product backlog accordingly without having to throw away lots of work.

In order to do this, the product owner and the team should only be looking a couple of sprints ahead. The top of the product backlog should contain user stories that are small enough and have the necessary details that the team feels comfortable with. It’s very hard to see past a couple of weeks, as things are likely to change, so why plan to detail product backlog items that are planned for several months into the future. Simply add Epics/Themes to the backlog which can be elaborated upon when the time is right

Backlog priority Backlog priority

Say No without being a jerk

Senior stakeholders trust product owners to make the right decisions for the product that is being built. Therefore, a product owner must be conscious of what they say yes or no to. Great product owners will say no to many requests without being a jerk. The following are some examples a product owner could use:

  • ‘Thats a good idea, but we’d need to pull something out from the current backlog to accommodate this. What would you suggest?’
  • ‘Can you help me understand why this is important for you. Maybe there’s another way to solve your problem and we might have something similar already on the backlog’
  • ‘Maybe we could include that as part of this story, which is similar?’
  • ‘I'm not sure that aligns with the current vision for the product/project’
  • ‘No, because [reason why you’re not putting the item onto the product backlog]’

It’s very hard to say no to requests, but if it doesn’t align with the vision for the product, the product owner should be saying no, but providing the reasons for it in a friendly, and courteous manner.

Size matters! Small is good (for user stories)

A product owner must be able to

  • take the high-level vision and start to deliver value early on
  • in collaboration with the team, turn the vision into a prioritised list of user stories that are small enough to deliver value to the users immediately.

Having user stories that are large, vague, and take a long time to deliver are of no value to anybody.

Splitting out user stories into small manageable chunks of work also allows you to prioritise and focus on the high-value items that should be worked on first.

Becoming good at breaking down user stories into smaller chunks has the following benefits

  • Helps prioritise the high and low-value user stories, allowing the team to always work on delivering high-value user stories, and not waste time on low-value items
  • Focuses the team on building what’s right for the product and the overarching vision
  • Reduces risk by allowing you to concentrate on completing the hard to do things first. Generally, items that are of high value tend to be hard to do. By focusing on this first, you reduce risk on the project
  • Early feedback - by completing small chunks of work, users will be able to feedback to the team and allow them to adapt and change the backlog accordingly

Available, Engaged & Committed

In an ideal world, the product owner should be available to the team at all times. However, most product owners will have other work to do too, so it may not be possible to be 100% available. They should try to spend as much time as possible with the team, preferably face to face, to work in a collaborative manner. If they aren’t available to respond to questions, or participate in team discussions, it’s likely that the project will struggle, due to the lack of leadership. If they aren’t available to provide feedback and sign off for completed user stories, the team is likely to lose momentum on the project. If they can’t be made available for considerable amounts of time to support the team, consideration should be given to a proxy product owner who has the authority to make decisions.

The product owner should also be actively engaged and committed to the project's success. The more time they spend with the team and is working with them in a collaborative manner, the better the chances of success on the project. An engaged product owner is a natural leader, as they find themselves leading a team through their decisions and makes it apparent to the team that they are committed to the final product. Great product owners build up a very good rapport with the team, and builds relationships with them to allow the team to focus on delivering the right things at the right time.

Great product owners are able to inspire and motivate teams just by being available to the team and working side by side with them to keep the project aligned to the original vision/goal. One of the best things they can do is to sit with the team as much as possible, so that they are available to the team and allow relationships within the team to be built.

Empathy and humility

Product owners have been given permission by senior management to make the necessary decisions to build the right product. With this comes the product power to lead teams and drive their vision forward. Great product owners lead through empathy and humility, working side by side with the team to make the correct decisions. They show their empathy and humility through their past success, continually making the right decisions, and correcting poor decisions to lead the team forward.

Be Prepared

As any good boy scout will tell you, you should always be prepared. It comes as no surprise that great project owners are always prepared. They alway come prepared to the ceremonial agile meetings, they are prepared and ready to make the necessary decisions.

A team will have greater confidence in their product owner, if they’re prepared for everything. If a product owner isn’t prepared, it will quickly become apparent, and the teams trust will be lost very quickly. It’s essential (and important) that the product owner is always prepared to lead the team, turns up to meetings with the right material, and takes pride in their work.

In God we Trust

No, I’m not trying to convert anybody to become religious, or even pledge their allegiance to the USA (‘In God we trust’ appears on a $20 bill). What is fascinating about religious people is their trust in their faith and trust in God (or gods for that matter). Some may even say it’s blind trust.

So what has trust got to do with being a good product owner? Well, quite a lot actually. Having a product owner that trusts the team to make the right decisions, and vice versa having a team that trusts them is great for team harmony and more importantly being productive. Having a product owner that trusts the team means they can convey their vision, and know that the team will do their best to achieve that goal. From the team's perspective, having trust in the product owner means they’re doing the right thing and taking the necessary actions to deliver their vision for the product.

Having a team and a product owner that trust each other doesn't’ just happen overnight. As the saying goes, trust has to be earned. Good product owners will establish a culture of openness and honesty within the team and encourage everybody to always be open and honest with each other, knowing that decisions and actions are being made for the betterment of the vision everybody is working hard to achieve. Trust also leads to respect. Having both trust and respect within the team and with the product owner helps immensely to deliver the right thing, at the right time, and with quality in mind.   

Similar posts

Are you looking to build a digital capability?