As @Contrarian mentioned, the Product Owner needs to understand the requirements and is usually involved in a business perspective with clients or Product Managers who are influencing the overall product releases. Prioritization is a key feature here as well, so this person needs to be granted the power to decide on priority of what to do.
In most situations, a Business Analyst makes the jump to a Product Owner very easily. If you currently have somebody playing this role, they make a great PO.
In some organizations, however, the requirements are actually clarified to the team by an architect who has an overall vision of the product or of a particular module/component of the product. These individuals can act as the Product Owner and can help with prioritization, though they may not necessarily be involved in the business/client-facing side traditionally.
As for using a team's direct development manager, I would caution against this. It is one thing to have a colleague informing you of priorities and representing the client's needs, and quite another to have your boss doing it.
Imagine your colleague tells you: "Jay, the buttons here aren't going to work for the client. They don't match the branding guidelines." You can have a conversation about it, go back to your work, and ship out something new for a review.
Now put your boss in that place. Suddenly it's no longer about a conversation to get to the right deliverable and is now about performance. You will avoid showing things early on to get feedback because you might look bad to your boss. You will not necessarily be honest about what you are building or how much you have left. An agile team needs to be transparent to each other so that they can react and adjust.
That being said, we have put development managers in some of our teams, just not as the Product Owner. We will have them involved as a team member who happens to also be providing technical advice or support to the Product Owner and Scrum Master. This allows their knowledge and access to other levels of the organization to be a tool that the team can use, without them being able to have complete control over all aspects of the sprint.