What makes a good Product Owner?

With Agile becoming increasingly popular in Australia, many people are getting on board the Agile ship and are taking on roles that they feel are suited to their skills and mentality. A lot of them do a great job. The magic of Agile happens when self motivated, skilled professionals come together and do their part with minimum supervision to create magic.

I have encountered many team members who were not trained in the Agile ways of working but they took to it like a fish to water…. They loved the way it worked and how it fostered a healthy work environment (if done with the right mindset) and I noticed it gave them immense satisfaction. I however, realised that this is possible only when people do their part without any reservations and egos. Agile is not for you if want to take credit for the team’s performance. This is the one major mindset shift that one has to make for Agile to work for your organisation and for you.

Every role within the agile team has a unique part to play, for this to work the way I just described. In this article, I want to focus on the role of a product owner and how that contributes in a way that Agile is beneficial and productive.

We have seen a lot of articles on how an ideal Agile team works from the perspective of the core team (for e.g. Scrum Master, Business Analysts, Developers, Testers, etc). I would like to shed some light on the characteristics of what an ideal Agile team is from a level above the scrum master. This is not saying there is a hierarchy involved but in this I am talking about the roles that have broader visibility than a Scrum Master does. I have worked on numerous “Agile” projects and some are great, yet some are really bad. I also noticed that a major reason for the bad agile projects is the lack of a quality Product Owner.

Let’s have a quick look at the definition of a Product Owner. Scrumguides.org describes this role as follows:

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.”

Keeping this definition in mind, I want to look at some characteristics of a good Product Owner in this article and how they can use those to foster a great agile environment.

Stable vision

The Product Owner is the visionary in the team, and they inspire the team to achieve that vision. But if that vision is not stable, that means you are not clear yourself and you don’t know what you want. If you keep changing your mind about that vision, there is a lot of work and rework required by your team and that will lead to frustration and demotivation.

I once worked with a PO who said, “I am changing my mind because I can…… ”. In an Agile team, there is no place for such arrogance because it goes against the spirit of Agile.

1. Consult your team before you change your mind.
2. Find out what the impact of the change is.
3. Assess the impact and then reassess if the change is required.

Product Owners can sometimes fall into the trap of hiding behind the demands of the business or the executive management putting the blame on them for changing the direction. It is the Product Owner’s role to challenge the business on that. You are not a messenger that passes on that decision to the team. You are there to come back to your team, discuss and understand the impact and then take that information back to the business and convince them that this may not be productive and that they should stick to the original plan. Sometimes change is inevitable. In that case you get the team to understand the situation and earn their confidence that this has to be done differently. The team stays motivated when they understand that they are not subject to changes because of someone’s whims and fancies but this is happening due to conditions out of anyone’s control. It is also the Product Owner’s job to make the team realise (and get their buy-in) that when the required change occurs, it helps to make the outcome of the project a success.

Discuss, don’t dictate

There are no “Executive decisions” in Agile…. Unless the team is unable to decide, and they lean on you as the PO to make a decision so they can move on with it. Every decision made is after a discussion with the team. As a PO you function as a leader, which means you involve your team and get their buy in on the vision. When the team is invested in your vision, then you don’t need to micro manage the team. Which takes me to my next point.

Don’t micro manage but still be in the detail

The Product Owner is the owner of the vision. It’s impossible to know if the team is moving in the right direction unless you know what exactly is going on. It’s a fine line between knowing the detail for the sake of giving guidance and for micro managing. 

Your Scrum Master is your best ally and the Team is your strength

I have worked on an Agile project where the Product Owner showed scant respect for the Scrum Master. Scrum Masters are the ones that marshal the team to execute your vision. They are the ones that update you on the progress accurately so that you are in the know and enable you to take the right decision when required.

The team on the other hand is responsible for executing your vision. The team gives a shape to your vision by helping you visualise and give a form to your vision by developing the solution to that vision. When the team is motivated, the product owner’s job is easy because the team (through the Scrum Master) will provide details of challenges and options to move forward which will then enable the Product Owner to make a choice in order to continue on the path towards your vision.

You are accountable for the “collective” vision

As I mentioned before, if you get the team’s buy-in on your vision by discussing with them, they are more invested in realising your vision. A good leader will discuss with the team and then take accountability for the delivery. Leave the responsibility to the team. The Scrum Master will ensure that anyway. Discuss and decide the “why” and leave the “how” to the team.

Conclusion

There could be so many more features of a good product owner but the above are coming from my experience working with some good and some bad ones. The PO has got to remember that the spirit of Agile lies in collaboration and communication and not in autocracy. You visualise as a team, develop as a team, succeed as a team and fail as a team. There is no room for individual achievements. Your individual contribution is what brings about collective success. It starts with the team and ends with the team. Everyone is equally responsible for the outcome. 

Other articles by this author

What professionals can learn from toddlers

Requirements vs Solutions

Agile – Why is it really so difficult for some organisations?

What do we Business Analysts really do?

Launching your career for fresh graduates – is it really as hard as it looks?

How to handle ever changing requirements?

What can leaders learn from Parenting?

What makes a good consultant?

Danger signs during recruitment….. For Candidates

How Agile can make you a better human being?

Business Analysis and Customer Experience – 2 sides of the same coin

About the Author

Click here to visit Arvind's Linkedin Profile