What does a product owner do?
Matt George
Contract ways of working at enterprise, stream & team | Currently an Agile Coach at Visa
"In coming to write this post, I had to really think - what does a product owner actually do? This isn't because they are a jack of all trades (although many are), it's because this is one of the most abused roles within an agile team.
Get it right and a team has a person who can help lead them to be great, that will help grow people, products, services and more."
My first exposure to the wider world of agile ways of working came as a product owner (PO). I had a dev team who wanted to try something new, and asked if we could try some regular morning alignments, and then add in a couple of other sessions to review what they'd built over a few weeks and to examine how we'd operated together as a team. I gave it a go and have never looked back.
As an aside, before we get into the role of a product owner - which can operate across a variety of methodologies - there's a really important point to how my team sold me on the approach. They didn't try and blindside me with facts about scrum. They didn't tell me it was better or faster. They went with the approach of 'here's something that we think will help you'. For me, this has been instrumental in how I try and improve ways of working - by finding out how it can make your colleagues' lives easier.
Okay, product owner role. First off, what does a great product owner do? This is relatively straight forward to answer, although as with most things related to roles and people, the base will most likely get added to in various organisations. But if a PO does these things well, they'll be headed towards being great.
First off, the PO is the voice of the customer. This is really important, especially in larger organisations or less customer-centric ones, as they may often be the only person shouting 'hey, what about the people we're building this for?'. Note: customer can also mean internal stakeholders, not just end users. This is also really important, as a good PO will balance the requirements of the business with that of the user. Sometimes there will be conflict here - it's up to the product owner to find the best way forward. Oftentimes this will be the end user, however, if you just rely on users to tell you (or even better, show you) what they want, you may miss out on innovation. It's massively overused, but there is an awful lot of truth in Henry Ford's perhaps apocryphal quotation around a faster horse.
Anyways, your PO should understand what the product should be made up of by distilling the requirements of both customer and business, along with making their own stamp on the product through a combination of:
As part of this, stakeholder management is a key role. Not defined by the Scrum guide (or supported in any other documentation for other frameworks that I could find), this is nonetheless a vital area. Partly because it helps with the above, but also because a good PO will need to push back a lot in order to help the team deliver sustainably, and to give them space to discover new things (rather than just be in an endless cycle of build and release). The best product managers are diplomats, able to juggle multiple requirements, whilst protecting their team from overwork, and turning down vanity project requests without alienating others.
领英推荐
On top of this, the product owner should be managing the product backlog, constantly refining it to make sure the highest value work is prioritised, looking to the future in terms of what gets developed, and ensuring that the team (and other interested parties) are clear on direction.
This direction takes many forms, but for me the best way of assessing this is asking if the team has a shared understanding of what makes up the backlog, both in terms of what's coming up right now and next, and therefore has more detail, and what the likely direction of travel past this point is. Whilst the product owner owns the backlog, he or she should not be developing it in isolation. Having said this, having that single accountable person in the role is vital in maintaining clarity and capability.
These are the big ticket items, but there are a lot of smaller components that make up the role. The best product owners I have worked with are generalists, able to step in and help the team when things get tough. This might be because they have a background in marketing, so can help with creating comms to customers, or have the ability to analyse data, taking some of the weight off the analysts in the team. The best teams are highly skilled generalists and your PO should be no exception.
An interesting point to note here is that product owners are often expected to learn on the job, both in terms of what it means to be a product owner, but also the area they are now responsible for - for example, you may be a strong PO, but know nothing about data. These facets of the role will need supporting - in the first case, a team and scrum master can help the product owner to understand what the role entails (and also what it doesn't...). In the second case, wider business support will help, along with an understanding from the PO that they don't have to know everything, and that it's okay to ask questions (in fact, this is highly desired), and that a key component of their role is knowing where to turn to for specialist information, as well as how to delegate.
They should also be an advocate and cheerleader for the team. What does this look like? It means that your PO protects the team from the rest of the business, making sure they're involved and communicated to and with, but not overwhelmed by some of the minutiae that would get in the way of the team. They should understand the pulse of the team, when to step in and offer guidance, and when to get out of the way. They should also be ruthless in making sure that the team have enough information and context to be effective, and work along side the scrum master to understand how to develop the team, both in terms of capability and driving towards being more effective and unified.
A few things they should absolutely not be: dictatorial in what gets done - the team should be able to take the vision of the product owner, and work out (with supporting information) what best way to answer that vision. Too often, I've seen product owners think they are responsible for telling the team what to work on and how to do it. We'll look at why this is a bad idea in a future post.
Product owners should also not be yes people - this goes back to the point I made at the beginning of the post around it being one of the most abused roles in agile teams. This - more than any other role you may find in any modern ways of working team - is a business role, that represents the requirements of the business. The tension comes because as a great product owner, you're also representing the needs of your team, and that of the end user.
Being a product owner is a specialist role - that's not to say it can't be done by people who have worked in other disciplines (as a side note, I've seen some of the best product owners I've ever worked with come from a mixture of other backgrounds, including comms, analysis and content) - but it does require discipline and the ability to work effectively within the bounds of the tension created above. In lots of cases, people are thrust into this role, without proper support or understanding of what the role entails. In the worst cases, this role doesn't exist, and instead you get design by committee, or a floating responsibility for parts of the role, but no appreciation of the others. For me, this is a non-negotiable role in a team set up to succeed. Skimp on this and you'll pay the price for it later.
I'd love to know what you think makes a great product owner.