Thoughts about hiring Product Owners, Part 1

I’m going to publish three blog posts that I hope will help organizations more effectively recruit Product Owners (POs). In the first one (this one) I share my thoughts on how to decide whether to hire for potential or experience. I also share some thoughts on how to reduce bias in your recruitment. In the next two posts, I’m going to share potential questions that you can ask during your interviews, examples of how to conduct practical tests with POs, and how to work with work samples.

Part 1 – Are You Recruiting For Potential Or Experience? <- This post.
Part 2 – Questions You Can Ask In Your Interviews
Part 3 – Work Samples And Auditions 

Why am I writing these posts?
Many companies try to hire POs (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’s 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 POs, and team empathy
Before you hire POs you need to understand your organisation’s ability to grow POs and team empathy towards your customers (or users). As soon as you know these two perspectives you can decide whether to hire for experience & knowledge or potential.

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

1. What does it look like?
2. How much support can a PO expect?
3. What kind of support will she get?
4. What level of understanding of the role does your organization have?

If your organization has a good understanding of what it means to be a PO, what the PO contributes with, and the PO gets a buddy and a mentor and is expected to learn fast you don’t need to hire an experienced PO with a track record. And that might be good news because such POs can be difficult to come by.

On the other hand, if you have an organization 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 PO (the manager that knows little about PO-ship!), the users or customers problems will not be solved, and ultimately your company KPI’s will suffer.

But how your organization grows POs (e.g. through mentors, buddies, forums, guilds, in-house trainers, agile coaches, or the manager teaching PO-ship) 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’s not about the ability to understand and feel it’s 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, prioritization, and collaboration easier. The more empathy the team has the less important it is that the PO 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’s possible to weigh in additional perspectives
If you’d like you can add additional ones e.g. experience from the technology you’re using, or with a legal perspective that’s 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 organizations to at least keep these two perspectives.

What you’re hiring influences your entire hiring process
Once you’ve 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’ll evaluate the candidate. If you decide these things up front you make your hiring process less prone to bias.

For example, if you’re 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’ve taken, books they’ve read, the feedback they’ve received etc. In contrast, when hiring for experience you’ll want to know exactly how much they know about PO-ship. You might want to see work samples e.g. road maps they’ve created, backlogs they’ve 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. 1. That organizations try to recruit a perfect match, don’t find one, then decide to choose 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 PO as quickly as possible. Sometimes it’s because a PO is leaving and other times it’s 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 PO to bridge technical, legal, or product knowledge gaps. POs were never intended to be tech experts or product specialists. When POs focus on architecture, information/process flows, and products rather than on helping their team prioritise, or facilitating activities that increase the teams empathy etc it becomes difficult to be congruent.

If you found this blog post valuable and would like to try it out, consider sending it out to everyone involved in your recruitment and together reflect upon the perspectives.

If you try it out please drop me an email and let me know how it went! Also, if you have any questions feel free to reach out to me for a casual chat about recruiting POs. I’d love to help out and bounce ideas.

Thanks for reading and good luck!

-V