According to the Scrum Guide, a Product Owner is the sole person responsible for:

• Managing the Product Backlog's content and order
• Representing the desires of a committee in the Product Backlog
• Defining the Development Team's requirements

Note the key phrase, "sole person".

If the Product Owner is  not the sole person responsible for these things, all the benefits of running an 'agile' Scrum team collapse.

Let me pitch this from a different angle: If Barack Obama makes the wrong call, it doesn't matter how many qualified people were involved in the decision, it’s still wrong. What's the point of delivering software fast if you can’t deliver what 'the people' want?

Build what's 'RIGHT'

There's no point in being 'agile' if you're speeding into failure. If all you do is deliver software faster, all you will be doing is guessing what your customers want.  That's kind of stupid, isn't it?

As a Product Owner you need to help define the right work to do, so that your rock star developers are not developing software no one uses. If you don't do this, it'll only be a matter of time before your product fails; you can only guess what's right so many times.

So what can a Product Owner do to ensure their team builds the right software?

1. Power to Prioritize

The Product Owner  must be able to order the tasks that their team works on.

It doesn't mean no one else can help, but it does mean you get the final call. It especially doesn't mean that your 'manager' can jump into your team and change the course of your ship. You'll never be able to be a 'proper' Product Owner if that's the case.

And when I say order tasks, I don't mean move what kind of makes the most sense to the top of the backlog. To order the backlog, tasks must be ordered according to a number of common factors (see prioritization methods here, e.g. the Kano Model, MoSCoW, etc.). It doesn't really matter how many factors, what matters is that you stay consistent across your body of work.

This helps to prevent emotion and ulterior motives from changing priorities, and is why you need to be the one voice of the team.

2. The 'One' Voice

So when that manager/CEO/stakeholder/customer does jump into your team and tries to change everything, you need to be the 'one voice'.

A stakeholder might have a screaming customer who tells them that X, Y, Z bugs need to be fixed. That's great, but it might just be that one customer's problem. A Product Owner should know that another problem which 100 customers are (validly) screaming about should be actioned first, even though there isn't an internal stakeholder pushing the Product Owner to get it done. In essence, this is the point of having a Product Owner.

On the flip side, if there are 100 screaming customers who want something (e.g. we want this product to be free!), you might not want to do what they tell you. You need to fight for your customers, but you also need to be the product's guru.

3. The Product Guru

Your manager wants you to build X, some customers want Y to be fixed, and the development team thinks Z is a great option.

How do you decide what to do when you're stuck in the middle?

This is where product vision and strategy come into play. Tools like product roadmaps, the Lean Canvas, and product vision boards all help. Tool or no tool, it simply comes down to "Goals Come First, Features Second". You need to define the 'why' before the 'what'.

As Simon Sinek preaches in his Ted Talk on How great leaders inspire action:

"People don't buy WHAT you do but WHY you do it"

Make sure your product vision and strategy align to a great 'why'. There will always be talent out there to help you implement the ‘what’. And sure, someone else might be paying the bills, but they can't do what you do.

The hardest part of being a Product Owner is that no matter how much you prioritize and filter, you can still build the wrong thing. But that's the fun of it, right?

So now you're a (real) Product Owner!

Just remember that your job is to get the team to build what's 'right'.

Being the sole person responsible for ordering work, communicating for the team and understanding the product are just a means to an end.