Product Owner is a new role

It is a well-known but still common mistake that many organizations during their Scrum transformation try to map their existing roles such as project managers into Scrum Master role. Recently, i notice that same happens to PO role as well. Not realizing that PO is a new role is as bad as not realizing that SM is a new role. Let's elaborate why.
Starting from PO's responsibility. Here's PO's role definition from Scrum source.

• Should have a vision for the product.
• Defines the features of the product, decides on release date and content.
• Is responsible for the profitability of the product (ROI).
• Prioritizes features according to market value.
• Can change features and priority every sprint.
• Accepts or rejects work results.

The keyword in the above list is ROI, others are necessary but more as means to great product and maximized ROI. When thinking of who shall be PO, I believe that passion for product is the first consideration, since that is the foundation.
A natural but undesired approach to find PO during Scrum transformation is trying to map the existing role to PO role. Let's look at a few common cases of mapping.
Mapping System Engineer (Architect/Business Analyst)
System engineer is a typical role in telecom industry. It is close to a combination of Business Analyst and Architect, working on both requirement analysis and architecture design. The most appealing reason for them to take on PO role is that they have been working on requirements, while PO clarifies requirements with team too. The close relationship with customers makes it an advantage for them to be customer representative. They may innovate on some product aspects, though it may lack the big context.
However, there are drawbacks on this mapping. System engineers are often technology savvy. Even when they work with customers, they tend to push technology solutions, rather than truly listen to customers and understand their problems first. They traditionally care less about ROI, which makes them perfect the system more than necessarily, without creating more value for customers and realizing the cost effect. PO leads release planning and management, while it has traditionally been program/project manager's responsibility. Few system engineers already know how to do that. In waterfall mode, system engineers are usually located in a single functional team, and they communicate via documentation. Chances are, they continue by writing user stories and handing over to team, which breaks the collaboration spirit in Agile development.
Mapping Program/Project Manager
Program/Project manager already does release management, which makes them good candidate for PO in this regard. They normally have better sense of ROI than system engineers. Their skills on risk management helps them manage the release in more predictable way.
However, there are other hurdles to overcome for them. Traditional project manager is control focused. Many of them are good at command and control type of management, while PO works with self-organizing team. PO looks at the unit of PBI, sprint and team, rather than task, day and individual. Project managers need to fight with the tendency of micro-management in order to effectively work with teams. Though project managers manage releases, they focus more on execution, while PO requires the product leadership based on great understanding on customers and constant product innovation through releases.
Mapping Product Manager
Product managers are great source for PO. They are responsible for the profitability of the product and ROI. They work closely with customers, and execute the product leadership by managing the product roadmap and releases.
The major problem for them is the traditional contract game between product management and R&D. They treat release as one unit, set contract in the beginning of the release with R&D, then, go away for future releases. While for PO, the constant collaboration with R&D team and making ROI decisions on sprint basis is the key to reap the benefit of Agile development.
Conclusion
If we look at the main themes appearing in PO role - ROI, product leadership, collaborate with team, release management, really, no existing role in the traditional organization does all of these. PO is a new role! It will certainly lead to problems, if we try to map the existing role to PO role. Telling people that you are PO from now on, while they keep doing what they used to do, does not make them PO.
On the other hand, people with any of the above background may become PO, with certain qualities and skills, as well as the realization that they need to transition to a new role. I have encountered Scrum transformation in several organizations, during which they introduced PO as new role and selected people with different background to fill it. It worked pretty well.