I saw this link the other day: http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell
Another of Knibergs cool descriptions of the PO role and things that happens arround the PO.
A practical problem not described here, is that in some projects the customer and their wish is not know. If you have a customer who hired your company to do a specific thing, then the requirements will flow into the PO's backlog, but if you create something that you want to sell, i.e. a new program for some computer system (PC, mobile etc.) and you want to make this a fantastic product without telling the user about it first, then the requirements will not flow into the PO's backlog in the same way.
The PO need to have the vision about the product, but getting the flow and functionality right is difficult; there are probably several ways to get this right, but one logical way (when working with Agile) is the iterative way, discuss with the team and interaction designers and then do a test with potential customers to find out what works and what problems they see and repeat until you have something that you can launch.
What I often see is PO's who just hand out high level stories (sometimes called Epic stories) without driving the story description (including DoD) to a level where the team have enough information and do not secure that the customers are happy about the outcome.