How To Hire Scrum Product Owners

Viktor Cessan, https://www.viktorcessan.com/, @viktorcessan

Many companies try to hire for their Agile and Scrum teams Product Owners (or Product Managers) with "many years of previous experience from the role" and with "many years of experience from their specific technical solution" or product but that is looking for a needle in a haystack (wishful thinking), prone to bias because eventually, and instead of waiting for this unique person to come along, you select the person you liked the most, and you risk hiring someone poorly matched to your needs and conditions.

Pay attention to two perspectives: Your ability to grow Product Owners, and team empathy

Before you hire Product Owners you need to understand your organisation's ability to grow Product Owners and team empathy towards your customers (or users). As soon as you know these two perspectives you can decide whether to hire for experience and knowledge or potential.

First think about your organisation's capability to train, mentor, and get Product Owners up to speed in the domain product management.

If your organisation has a good understanding of what it means to be a Product Owner, what the Product Owner contributes with, and the Product Owner gets a buddy and a mentor, and is expected to learn fast, then you don't need to hire an experienced Product Owner with a track record. And that might be good news because such Product Owners can be difficult to find.

On the other hand, if you have an organisation that doesn't know anything about that domain you will want to hire someone experienced with a track record, otherwise the team might solve the wrong problems, the manager will have to try to support the Product Owner (the manager that knows little about Product Ownership!), the users or customers problems will not be solved, and ultimately your company KPI will suffer.

But how your organisation grows Product Owners (e.g. through mentors, buddies, forums, guilds, in house trainers, agile coaches, or the manager teaching Product Ownership) is less important than the fact that it does.

How To Hire a Product Owner

Your teams empathy towards the customer

Here team empathy means actually understanding and feeling the customer's pains. Having direct access to customers or users. Meeting them regularly. So it is not about the ability to understand and feel, it is about actually having it.

The more empathy a team has towards the customer the better they understand their pains, needs, desires, expectations, problems, and goals. Having empathy makes problem solving, prioritisation, and collaboration easier. The more empathy the team has, the less important it is that the Product Owner has pre-existing empathy for your customer.

Combining the perspectives

When you put these two perspectives together it becomes clearer what to hire for. And while this is not an almighty truth, it has helped me find more suitable candidates faster, to ask more relevant questions in the interviews, to better evaluate candidates, and to do so less biased.

How To Hire a Product Owner for a Scrum Team

It is possible to weigh in additional perspectives

If you want, you can add additional perspectives e.g. experience from the technology you are using, or with a legal perspective that is important for you. Adding additional perspectives might give you a better holistic overview and better help you decide what to hire for, but I always encourage organisations to at least keep these two perspectives.

What you are hiring influences your entire hiring process

Once you have decided what to hire for you can decide what questions to ask, what you want your interview process to look like, who you want as interviewers, and how you will evaluate the candidate. If you decide these things up front you make your hiring process less prone to bias.

For example if you are hiring for potential you might not want to explore if the candidate knows what a user story map or what WSJF is. Instead how the candidate has developed as a person, and in her role is more important. And figuring out what kind of support she needs is also important. You could spend time exploring courses they have taken, books they have read, feedback they have received, etc. In contrast when hiring for experience you want to know exactly how much they know about Product Ownership. You might want to see work samples e.g. roadmaps they have created, backlogs they have managed, etc.

The same goes for team empathy. If your team has empathy, you might want to know how much empathy your candidates have for their customers in their current roles and how they engage them. If your team doesn't have empathy, you might want to explore how well the candidate understands your target audience and the market.

Common anti-patterns are...

  1. That organisations try to recruit a perfect match, don't find one, then decide to chose someone they liked. However this person wasn't interviewed based on your actual conditions or needs so you don't know whether the person is a good match or not.
  2. The hiring manager doesn't have time to explore this and just wants to recruit a Product Owner as quickly as possible. Sometimes it is because a Product Owner is leaving and other times it is because there are important market opportunities. But if the hiring manager doesn't have time now just wait and see what happens when you hire someone who's needs and strengths are misaligned with your expectations, needs, and conditions.
  3. Not deciding/aligning on what to explore in each interview step. This might result in two people asking the same questions or no one asking important questions that you need answered.
  4. Hiring a Product Owner to bridge technical, legal, or product knowledge gaps. Product Owners were never intended to be tech experts or product specialists. When Product Owners focus on architecture, information/process flows, and products rather than on helping their team prioritise or facilitating activities that increase the teams empathy, it becomes difficult to be congruent.

Here are some questions that might help you evaluate candidates level of experience from Product ownership, and questions that might help you discover if they have potential to learn the role.

Please note that:

  1. Treat these questions as inspiration and use the ones you think can be helpful to you. This is not a guide to follow step by step.
  2. If a candidate is unable to answer these questions it does not necessarily mean that she does not have the potential to learn fast, it might just mean she hasn't thought of these things.
  3. Most of these questions are exploratory and the purpose is to help you get to know your candidate - they don't necessarily have one correct answer.
  4. Create a safe environment for your candidate. It is important that she feels comfortable with these questions. For example start by mentioning that you are going to be asking questions that do not have a correct answer. That you are just exploring her perspective and in the case where there might be a correct answer, you will let her know for those specific questions.

Questions that explore understanding of and experience from the Product Owner role

Questions that explore potential in learning the Product Owner role

Questions that explore potential in gaining customer empathy and technical awareness

Don't be afraid to explore the technical questions with candidates that do not have an engineering or development background. Many Product Owners without that experience fully understand and can describe technical implementations as well as challenges.

Additionally you can explore your candidates knowledge of several past teams, just repeat the same questions again. If she can tell you what it has looked like for 2 or 3 teams, it is likely she will be able to understand your teams problem no matter how technical you think your problem is.

The rationale behind each questions a.k.a what am I looking for with each question?

The majority of these questions really do not have one correct right answer. They are open ended and meant to create a conversation. I tried writing down a few thoughts about each question but that quickly became long so in an effort to keep this article short. I'm not sharing the rationale behind or thoughts about every specific questions.

Effort and reward

How To Hire a Product Owner for a Scrum Team

Before you decide how to evaluate your candidates, consider the amount of time and energy you are willing to invest to learn about your candidates. Asking for work samples and evaluating them yourself requires little effort while running auditions require the most time and energy but is also generally most rewarding.

Work samples

Work samples are artifacts that the candidates have produced in their current or previous roles and could be:

Viewing a candidates work samples gives me a better understanding of her style. However, as some companies prescribe how to do things e.g. how to write user stories and how to create roadmaps, it is important that you distinguish between her style and parts that are prescribed.

I have used work samples in three different ways:

  1. Reviewing candidates work sample together with the candidate in an interview (most often)
  2. Providing work samples to the candidate in an interview and asking her to evaluate them (more often)
  3. Evaluating candidates work sample by myself (less often)

Potential things to explore in a roadmap work sample

Potential things to explore in a backlog work sample

Potential things to explore in a prototype work sample

Providing work samples of your own

If your company does things in a very specific way or if the candidates work samples differ a lot from your style, it might be valuable to provide work samples that you think are good and then have the candidate evaluate them. Ask them what they think is good and what they think is missing. Explore which parts they disagree with and which parts they don't understand, or explore what they would need to be able to create artifacts that more resembles your own.

Running auditions

Auditions are real exercises that your candidates facilitate or run while you get to observe. When I have recruited this has usually been one of the final steps in our recruitment process due to the amount of coordination required to find a time that works with a team, myself, and the candidate. While auditions require the most amount of time and energy they also generally return the highest reward.

Examples of auditions are to have the candidate:

  1. Run a session or workshop of their own choice.
  2. Facilitate a planning meeting.
  3. Facilitate backlog grooming.
  4. Facilitate user story mapping.
  5. Pitch their vision for the product/service/team they are going to be Product Owner for (but remember you are not evaluating the content, you are evaluating how she does it!).
  6. Pitch the vision for her current team.

I usually try to set candidates up for success since that is how we would treat them if they got the job. That means that I share more context than they ask for and particularly relevant information about the group dynamics and domain knowledge they need to be aware of. I would also ask what help they needed, what kind of room they would like etc.

After running an audition, you have a great opportunity to offer observations and feedback to see how she responds to it. Does she go into defensive mode, shut down, or does she explore it with you and listen? This is also useful information.

Poor performance is not always caused by inexperience

Some people get really nervous in interviews and if someone performs poorly it does not necessarily mean that they do not know the role. They could just be nervous or maybe jetlagged if they have travelled from a distance to conduct this interview, etc. It is also quite uncommon to run auditions, so people tend to get nervous because they have never done it before.

This article is based on blog posts that were originally published on https://www.viktorcessan.com/thoughts-about-hiring-product-owners-part-1/, https://www.viktorcessan.com/thoughts-about-hiring-product-owners-part-2/, https://www.viktorcessan.com/2018/01/thoughts-about-hiring-product-owners-part-3/.

Related product owner and agile hiring articles

Hiring for Agility - Mindset Matters in an Agile Organisation

Immersive Interviewing - Building Great Agile Software Teams

The ScrumMaster Job Description

Agile Hiring or Hiring for Agile

More Agile Knowledge

Scrum Expert

Agile Tutorials and Videos

Click here to view the complete list of Methods & Tools articles

This article was published in March 2018