The Scrum Guide defines the role of the product owner as “responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”
So this is very much open to interpreation. Personally I see a vital part of the POs role as being a bridge between the business and the Scrum Team. I have found that IT in general have a very poor reputation in many of the organisations I have worked in. Software development is costly, complex and does not always deliver the value they expect. Or takes so long to come to market that the original driving needs are no longer as valid by the time the software is in their hands.
On IT's side, they often find the customers demanding, unforgiving and intolerant of the difficult nature of software development. Getting past this divide is in my opinion a responsibility of the PO. The PO has one foot in the business and one in IT. They have the unqiue perspective of seeing the issues within both camps and as they mature they are in a better position to avert problems before they can fester.
For example, I was a PO in one company where the the product sponsors were a committee. At my first meeting they told me how rubbish IT were and that I had to take a firm hand and force them to do what the business wanted. I didn't immediately jump to the defence of IT, as I didn't know the background yet, but regardless, the business had a perception that I took on as a challenge to change to a more positive and engaging one. So I brought the focus back to the next release and started getting to know the features and changes they wanted.
I pushed back on some things, agreed to look into the rest and get back to them. They were not expecting this and they saw this as weak. I explained that from "our" perspective the requirements were reasonable, had good business value and should be done immediately. However, I needed to get the perspective of the guys who would actually be doing the work first.
So off I went for a backlog grooming session with the team and explained why the business wanted these changes. I didn't get a lot of engagement from the Scrum team at first. So I challenged them to challenge me and slowly but surely they ventured forth their opinions and suggestions and concerns. I was then more confident when I went back to the business to confirm that we could do most of the changes but that some would not be achievable in the expected timescales and I presented some of the new ideas the Scrum Team had come up with. More than a few eyebrows were raised in pleasant surprise and the feedback was well received and they made some adjustments to the requirements that were more likely to be achievable.
This was the start of a more positive relationship with IT that fostered respect and more understanding on both sides. Bridge building!