How do you Choose who to Hire as a Junior Product Manager?
Who to hire as a junior-level product manager is one the most difficult decisions a product leader has to make. Most product jobs require some level of product management experience, so you can focus on understanding what a candidate has done and how their existing skill set will fit with what you need for your team.
But, by design, the candidates for an entry-level product management role will not have any experience in product. You have to determine which candidates might have the mindset of a product manager without any relevant examples of them showing it. You’re hiring someone purely for their potential, but you have little evidence with which to make an educated decision. And to make matters more complicated, you will be looking at candidates from a variety of backgrounds – and with product sitting at the intersection of business, UX, and tech, no path is clearly the “right” one.
So you need to find ways to explore if a junior product manager candidate is able to think like a product manager without requiring them to have experience of doing the job.
When interviewing entry-level candidates, besides looking at traditional soft skills, I want to understand their natural inclinations in two areas: Can they balance competing priorities? and Can they find small pieces of value to deliver?
If a candidate can prioritize and inherently understand delivering value iteratively, execution skills like backlog management and story writing can be taught, and more strategic skills like user research and discovery can be grown into.
Can They Balance Competing Priorities?
To get a view on a candidate’s ability to prioritize, I use a card sorting exercise. For this example, I have used a travel app, as travel is an approachable domain that most candidates can understand easily. I prepare a set of notecards with high-level roadmap features, mixing items that hit different priorities: some items focus on leisure travelers while others are primarily business travel-related. Some are primarily revenue drivers, some are user acquisition focused, and some are about engaging current users. The important thing is to have a good mix of items with no obvious “right” answer.
I explain the app, tell the candidate that these are potential items for the roadmap, and ask them to sort the cards into priority order. Often, the candidate will jump into prioritizing and make some general assessments of what they think is the most important. If they ask for guidance, I will give them a goal such as: “Our primary focus is new users this year, but we also have a goal to increase revenue by 5%.” Once they have determined a priority, I ask them to walk me through their thinking. There is no single correct answer, so I am more interested in understanding why they reached the conclusion they did.
From there, I want to see if they can shift priorities with new information. Typically entry-level candidates looking at travel will skew towards prioritizing revenue-driving items and fun items for leisure travelers – it is what they know at that point. So I’ll ask: “How would this priority change if we decided to shift and focus on capturing business travelers?” Ideally, they should be able to identify that different items in the list would hit that market better, and adjust.
Can They Find Small Pieces of Value?
For the second question, I have another set of cards, this time with high-level pointed user stories on a particular feature. The format of stories is not important here – just enough information for them to understand how it is broken down. I also like to include some bugs of varying degrees of criticality. I explain the feature that we’re building and that these cards are the pieces of work that are ready for the developers to code. I ask them to sort the cards in order of what we would build first to what we would build last.
Once they have their first pass, I ask them to walk me through it and explain their thought process. Things I find particularly interesting: where is their natural inclination to place bugs? Do they walk all the way down one part of a workflow or do they move between different items? I then explain that we do frequent releases whenever we feel there is enough to provide value to users, and ask them to show me where their line for release would be and why. It allows us to have a discussion about where they find value.
If the line they draw is fairly bloated, and it usually is, I will ask them how this would change if they find out tomorrow that their budget is cut in half (or whatever feels appropriate) and they have to hit that release line with fewer items. This should result in some level of reshuffling to get the most value in the smallest amount of work.
Beyond the two product-focused exercises, I look for other traits in junior product managers like intellectual curiosity, an appropriate level of technology familiarity for the role, and an ability to add to the culture of the organization. You won’t necessarily see these things in the exercises, so make sure you have a line of questions that will help uncover these parts of a candidate’s story.
A Final Word
The crucial thing to remember when using these exercises with a junior product manager candidate is that they have never done this before. There is a good chance that the candidate will say that we should prioritize adding filters to profile pictures over some deeply valuable feature, or think they need six ways to search before a user can ever save an input, or any other number of odd decisions that, as an experienced product manager, I know are unwise. But that is okay as long as they have a logical thought process as to why they got there. The art of product management takes years to develop – you’re simply looking for someone who has the potential, and you’re signing up to help them refine their craft. Once you know they can inhabit the mindset of a product manager, you’ll have plenty of time to teach them the rest.