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.

• What does it look like?
• How much support can a Product Owner expect?
• What kind of support will she get?
• What level of understanding of the role does your organisation has?

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.

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.

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

• High level understanding of the role
  • What is your definition of the Product Owner role?
  • How do you want to be evaluated as a Product Owner?
  • What is different about being a Product Owner for a team doing scrum and one doing kanban?
  • What does the Product Owner do to help the team get a strong sense of purpose?
  • What level of technical insight/awareness do you think a Product Owner should have?
• Vision
  • What makes a good product vision?
  • What does the Product Owner do to help the team understand the vision?
  • Who owns and maintains the vision?
  • How do you translate the vision to a roadmap or backlog?
• Product success
  • What does success mean for a product?
  • How do you measure product success?
  • Who is responsible for the products success?
• Prioritisation
  • How do you prioritize between defects, new features, technical debt, and learning activities (e.g. hypothesis validation)?
  • What do you do when the team gets stuck in a prioritisation discussion or there are two or more people who can't agree?
  • How do you prioritise your backlog?
• Understanding the customer and discovering their needs
  • What are some of the purposes with using personas?
  • How do you engage the team better understanding the users and customers?
  • What is product discovery and why is it important?
  • What is different about leading in product discovery and in product delivery?
  • Why are short feedback cycles important in product discovery and product delivery?
  • What can the Product Owner do to help create short feedback cycles?
  • How do you plan and arrange work for a cross functional team that both does product discovery and product delivery?
  • Why is empathy important and how to you create it?
• Working more effectively / optimizing for flow
  • What is cycle time and why is that important for you and the team to know?
  • Why is limiting WIP important for you, the team, and the organisation?
  • What can you do as a Product Owner to help the team limit WIP?
  • Tell me about a time your team didn't meet the organisations expectations in terms of delivery or impact and what you did.
  • Why is it a bad idea to have one UX specialist and one developer focus on work for the coming sprint separately from the rest of the team?
• Collaborating with others
  • Tell me about something you worked on that needed input or collaboration from several stakeholders, teams, or managers, what your role in that was and how things went.
  • Tell me about a time when you failed to engage or include the organisation in the work you and your team was doing, and what happened.
• Growth
  • What do you need to or want to develop within Product Ownership?
  • How do you stay up to date in Product Ownership?
• Working with legacy
  • What is technical debt and why is it important for you as a Product Owner to be aware of?
  • What happens if you don't reduce technical debt?
  • How much technical debt should you remove?
  • Isn't it just better to deprecate/close an old system that has a lot of technical debt and build something new than to remove the legacy?
  • What can you as a Product Owner do when technical debt is slowing your team down?
  • How does Agile try to avoid technical debt from occuring?

Questions that explore potential in learning the Product Owner role

• Asking for help / knowing your limitations / Self awareness
  • Tell me about a time when you didn't know how to do something.
  • What do you feel personally responsible for doing in the team?
• Basic understanding of the Product Owner role
  • What is your definition of the Product Owner role?
  • What problem does the Product Owner role solve (or what value does the role bring)?
  • What do you imagine will be easy and difficult for your personally with the Product Owner role?
• Basic understanding of Agile
  • Who is responsible for the quality of the product?
  • What does it mean to work as a team as opposed to working as a group of individuals?
  • What are the advantages of working as a team?
  • What does success mean for a product?
  • How do you measure product success?
  • Who is responsible for the products success?
• Personal development
  • Give me an example of how you have developed the past year?
  • How do you learn / prefer to learn?
  • What are some recent books you have read?
    • What were your takeaways?
    • Why those books?
  • What is some recent feedback you have received about your leadership style and how have you changed as a result of it
  • Tell me about a time you had to adapt to changing conditions?
  • Tell me about a time you put your own work or needs aside to help the team out.
  • What are some points in your career when you have made noticeable change in your style, mindset, behaviour.
  • What are some tools (e.g leadership and prioritisation models etc) you use that you picked up recently?
  • Give me an example times you have changed your mind and why.
  • Knowing what you know today and if you could mentor your younger self, what would you start with?

Questions that explore potential in gaining customer empathy and technical awareness

• What is your current teams value proposition?
• What does their technical solution look like?
• What are some challenges you have had with your technical implementation and why?
• Who are your users?
• What do they care about?
• Why do they care about those things?

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

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:

• Backlogs
• Roadmaps
• Vision decks
• Prototypes
• Product canvases
• Personas

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

• How is this roadmap linked to the company goals?
• What kind of roadmap is this? An impact map? A user story map? A release map? A timeline with deliverables?
• Does it contain exact scope and deadline? Where is it flexible?
• Are the goals achievable ones or stretch goals?
• How big is it? Is there an end to it?
• What does it contain? Functionality? Impacts? Financial metrics? Quality metrics? Experiments?
• Who is the target audience?
• Who took part in creating it? The team? Stakeholders?
• What is the time horizon? 3 months? 6 months? 3 years?
• How is it maintained, and by who?

Potential things to explore in a backlog work sample

• What does it contain? Outputs or outcomes? Problems? Tasks? Solutions? Mix?
• How detailed is the backlog? Are all items equally detailed?
• How long is the backlog? (10 items? 100 items? 500 items?)
• How is it organised? Per issue type (bugs, feature requests, tasks), type of customer value? Or something else?
• Who took part in creating it? The team? Stakeholders?
• How is the backlog aligned with the company's roadmap? Is there a clear connection?
• How much time does she spend maintaining the backlog?
• How does she maintain it?
• Where is the backlog stored?
• How many backlogs are there? Idea BL, Product BL, Sprint BL, System BL?

Potential things to explore in a prototype work sample

• What was the first hypothesis?
• Who was involved in defining it?
• What happened? Was the hypothesis correct? If not, how did it evolve over time.
• Where and how is learning stored?
• What did the different iterations of prototypes look like
• How did she test the hypothesis?
• How did she determine the magnitude of the prototype?

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