Finding the right Product Owner

An important question to answer, especially when launching your first Scrum team: "Should we choose of our own employees as Product Owner, and if so: whom - or should we find a contractor?" The answer is a clear: "It depends". And here's why:

Value Optimization

The most important function of the Product Owner is to optimize the value of the delivered product. Everything else is subject to that. Especially the first couple of Sprints should have a visible impact and give stakeholders the impression that the team is doing things which matter.

And here is the first splitting point:
A member of the existing staff is already familiar with the business, knows the important stakeholders and understands the work done by the organization within the product domain so far. This put them at a real advantage over a newly hired contractor.
A long-term employee might approach Product Ownership with a "Yeah, I know this" mindset, whereas a contracted PO will actively seek out what they don't know - and thereby explore important areas a current member of the staff could have skipped.

Value Organization

To build the best possible product, the backlog must be in shape. The backlog is an itemized and prioritized list of what you know. Split, slice and sort, extract value and prioritize by need. A good analyst should be familiar with most of these activities, so the PO should be able to get some support with that as needed without even being an expert in the product domain.

The second splitting point:
People who are suitable for the PO role can separate essentials from nice-to-have and need to be pretty harsh to descope even things they themselves might consider necessary. Employees of an organization who for some reason need to play favorites with specific stakeholders in disfavor of the product aren't a good fit.
Another plus for a contractor: They might not have to please one specific audience and can descope anything which has only career-political, but no business value. A note of caution though: This becomes dangerous when their paycheck hinges on a single stakeholder!

Taking Risks

Many organizations are inherently risk-averse, and so are their staff. Especially conservative enterprises where employees have learned over the years to avoid taking risks at all costs will be challenged to suddenly find people within their organization who are happy to go completely new ways, work with uncertainty and prioritize things where success or failure can only be known after the fact.
A PO who shies away from taking risks will be highly unlikely to build anything exciting and most likely will end up building something as close as possible to something which already exists.

This is the third splitting point:
The PO role isn't for perfectionists. The proverb "Perfect is the enemy of the good" comes in at this point. Most highly qualified people in organizations default on the PO role because they try to build a product based on what they know and shy away from building a product based on what they don't know.
A contractor who knows very well that they can't know everything may be much more open to explore feasible options others might never consider with their organizational shutters.

Role Assignment

Rather than start with the question "Who should be PO", we need to look at the activities which are required to be effective as a PO, then determine how we plan to make them happen. While skills can be acquired, the challenge is more in un-learning the things one has always done than it is in learning that which is now required.

By picking a member of your existing staff, there's a risk that the PO role isn't filled adequately.
Here are a few common choices for internal PO:

• Analyst as PO
  Analysts are great at supporting a PO, yet they tend to struggle with independent splitting and value-ordering. Especially if your Scrum Master is also inexperienced, such a setup has massive challenges to begin with. Try to avoid this scenario and let the analysts do what they do best: analyze the prioritized items for the team.
• Project Manager as PO
  This scenario is extremely dangerous, as PM and PO have completely different job descriptions. A PM will have to un-learn so many things in order to be effective as a PO that a new hire is probably the better fit. PM skills are still valuable, although a PM is better suited as a team member than as PO.
• Line Manager as PO
  An almost surefire road to disaster, as the Line Manager's responsibility is oriented in a different direction. This will most likely end up with either line management or PO duties being dangerously neglected. Likewise, line managers often tend to be challenged at creating, maintaining and communicating a Product Vision.
• Marketing/Sales as PO
  In some cases, this works like a charm. The danger is that Marketing mioght have very little contact with real users, risking to build the wrong thing - and Sales might be too focused on delivery and neglects strategy. Both are important stakeholders with valuable perspectives, yet they may not have what it takes to be a PO.
• Senior Manager as PO
  The worst part about the Senior Manager being PO is that they often don't have enough time to spend with stakeholders and team members to ensure the right product is being built and that the most valuable things are being done. A better setup is that the Senior Manager backs and supports a PO who is fully focused on Product Ownership.
• PO as a title
  The worst choice organizations often make is assign the PO role via "appeasement politics", i.e. give this important role to someone who would otherwise begrudge the transition to Scrum. Just don't. Instead, find out what their gripe is and coach them to find their place in the new organization.

Then - who's suitable to be a PO? 

A PO is a PO, and while any member of existing staff can learn Product Ownership, they weren't born as PO. The role of the PO must be learned, and this learning process takes time. A lot of failure learning is involved, so the main question isn't "Whom should we choose as PO?" than a series of questions about the goal of Scrum in context:

1. How fast do we need to produce something?
2. How is our organization prepare to identify value?
3. How do we know we build the most valuable thing?
4. How do we know we are building the right thing?
5. What happens when we built the wrong thing?
6. Which challenges will the product itself face?

After discussing the organizational constraints, we need to discuss the context of the Product Owner:

1. Which support can we give to the PO to learn their role?
2. Which support can we give to the PO to be effective?
3. Can our PO be politically neutral, i.e. unbiased from departmental priorities?

Finally, I would shortlist a list of candidates who might be suitable to take on the role:

1. How close are they to the required skills of a successful PO?
2. Can they formulate and communicate a Product Vision?
3. Do they have a standing of high respect within the organization?
4. Do they have an entrepreneureal mindset?
5. Will they act in the best interests of the product?
6. Do they understand business?
7. Are we willing to relieve them of other responsibilites?

While there's no "perfect PO", there are some people who are more or less suitable to fill the role. Any available person who comes sufficiently close to a good fit should be considered.

Assigning the Product Owner

Based on all the above, consider the following question:

How likely can we get an internal PO prepared for the role? 

If there's a decent likelihood, find one and give them the necessary support to succeed.

This "necessary support" will require a set of decisions and changes within the organization as well as training and coaching. It might require contracting an experienced PO to "teach the ropes" and potentially onboarding a PO coach to keep the ship afloat during the turmoils which will come.

If odds look dim, you might prefer contracting a PO.

While they are around, you should be working on resolving the organizational impediments which necessitate an external expert in this position. As soon as possible, find a staff member who can fill the role and let them learn on the job by working with the contracted PO.

Summary

The key challenges for finding the right PO include:

• Freedom from organizational structures and politics
• Entrepreneurial thinking

Most staff members would have issues with either or both of these challenges, but they're more suitable because they will be more likely to stick around for a major portion of the product's lifetime.

A contracted PO is a workaround for problems that might not be tackled on a short notice. Finding and enabling the right person within an organization to be PO is a major challenge, so a contractor buys time here without solving the issue. 

In the long term, a PO should always be a permanent ember of your organization - although supporting them with a contracted Product Owner Coach might be a great idea to maximize the value of the product they're building.