The Scrum Product Owner should be your top professional
I often get the feeling that the Product Owner in a Scrum team is a highly misunderstood role. I've seen many Product Owners, good and bad. I've had the role myself as well. It seems customary however, that in many (not all!) cases the person who got this role was given it because "somebody needs to be, so you might as well do this on top of everything else you do". This is really sad.
Of the three roles in Scrum (Product Owner, Scrum Master, Team Member) I daresay the Product Owner is the most important. Not to render the other two roles unimportant in any way, the Product Owner is special however. It's special in the sense that the Product Owner is the business-representative in a other ways tech-savvy environment, it's special in the sense that the Product Owner has the main responsibility for the direction for the product, and last but not least the role is special because being good at it requires you to be the main drive shaft of innovation within the company, project or product.
Product Owner as innovator, curator and gardener
Being the main drive shaft of innovation does not necessarily imply the Product Owner is the most innovative person. It does however imply that the Product Owner is the person who pulls on the innovative forces surrounding him/herself, and collects and curates everything that crosses his/her path. This is necessary to create a good product and to move forward. A good Product Owner has of course certain innovative skills him/herself, so that he/she can combine their own skills with ideas, thoughts and comments from everywhere else to create road-maps, impacts maps, various "value models" or other tools to discover those really important features to do next.
The Product Owner is more of a gardener; sowing and planting, pulling weeds and maintaining. It requires a certain set of skills, and a great amount of time to be this person.
At the same time the Product Owner must be able to manoeuver within the organization, where opinions will differ, politics are politics, and people are people. It takes a certain set of skills to be this type of person. It's inevitable that some priorities the Product Owner does will be unpopular by someone, which may create tension. It's key to be able to handle this correctly. I think many organizations throw the Product Owner-role at the wrong person because the management is afraid of this role. In other words; it's misunderstood. A common misunderstanding about the Product Owner is that he/she has the sole responsibility for the product. The Product Owner does not! The Product Owner has the responsibility to collect ideas, work on ideas, talk to co-workers, customers, sponsors and other stakeholders to find how the product need to change to become better. I've seen and heard managers (and others) talk about the Product Owner as if this person is the God of the product. That's the fear of the role talking. That's why the Product Owner time and time again has been given to someone who doesn't have the right set of skills or the time to be a good Product Owner. This way, preconceived ideas and opinions about the product and the way it is evolving can be kept at a higher level and micromanaged, instead of creating a unifying role so that a collaborative, data driven and innovative environment can grow and thrive. The only God-role in this context is thus the micro manager. The Product Owner is more of a gardener; sowing and planting, pulling weeds and maintaining. It requires a certain set of skills, and a great amount of time to be this person. These reasons cement the Product Owner as the most important role in Scrum. That is why your Product Owner should be your top professional, so that your product will be the best it can be.
Acquiring talent to your organization
If there is no fit person in the company to really take on this task and to excel at it, then hire someone. It might seem like a scary thought to hire someone with this much influence on your product, but is it as scary as not having the right person at the job? By my opinion it is not. Your domain might be difficult, one will need to understand the business you operate within, and no one knows the customer like you do. This might all be true, but it's also true that these things can be thought. Remember, when you hire a developer he/she must understand your domain. When you hire a UX expert he/she must learn all there is to know about the customer and the business you operate within. When you hire a project manager, he/she must know a bit of every one of those things, in addition to another set of knowledge, skills and experience. The same is true for a hired Product Owner, so given the situation there is no good fit within the organisation there's no reason not to give it a try.