The Product interview — a prioritization exercise

5 min readMay 21, 2019

The PM role includes many skills. In job interviews, candidates are often tested on their UX skills, reasoning skills, and presentation skills. I’ve rarely seen, both in person and online, interview questions regarding roadmap prioritization, so I wanted to contribute an exercise I often use when I interview.

I like this exercise for a number of reasons: It’s simple (and some might say simplistic), yet very similar to the actual task of roadmapping. It doesn’t take long to do, and it’s thought-provoking and makes a good basis for conversation.

This exercise can also be used for training junior or aspiring PMs. I’ve actually used it in a talk I gave to students, and it seemed to be very mind-opening for them.

The rationale

Roadmapping is considered one of the key skills every PM need to master. Still, I was surprised by the amount of PMs I interviewed that had little to no experience doing it. In some companies, roadmapping was left to either the VP Product (in larger companies) or it was done by the CEO herself (in smaller ones). The PM was often left with the task of execution.

Another common reason for lack of roadmapping experience is the distinction, in some companies, between inbound and outbound Product Managers. In those companies, roadmapping is often the sole role of the inbound PM (although confusingly, it’s sometimes exactly the opposite). In any case the result is PMs with 2–3 years of experience that have never prioritized a roadmap for their products.

The assignment (10 minutes by themselves to plan, followed by 10–15 minutes of discussion)

Download the full assignment here.

This assignment is comprised of 12 features with partial information — feature description, reasoning, reach, impact, and dev effort estimation. You’re in charge of a team of 3 developers and are asked to give a roadmap for one quarter (total of 9 dev-months). The interviewee is required to select and prioritize features to create that roadmap, and of course provide a rationale. They’re also given a set of company strategic goals.

Feel free to use this in your interviews and training. You’re of course welcome to make your own copy and add or change list items, according to your own company and experience.

Before continuing this article, I recommend you take 5 minutes to scan through the assignment. It will make the rest much more understandable.

Follow-up questions

I usually start by asking something like:

(1) so, what do you think the right answer is?

When someone answers “well, there’s never a right answer here, but here’s what I’d do”, they definitely get a few extra points. Junior PMs will rarely acknowledge this. It takes experience to come to that conclusion.

Usually, 10 minutes give them just enough time to get to know the items and start thinking about it, but not to finish up the list. That actually a good thing. I often like to ask:

(2) which features are you considering? Which features did you rule out?

In general, I’d classify the batch in three batches: easy elimination, obvious candidates, and “up for debate”.

The easy eliminations

While there is no right answer, there are definitely some wrong ones (in my opinion, you’re welcome to disagree). I’ve had interviewees that said they’ll always start with the feature the CEO first demanded. In my personal experience as a PM, I often felt like half my job was to say no to the CEO, and explain why we’re not going to drop everything to do that feature he dreamt about last night.

And how about #2? The company is on the right track and growing. Is this really the time to attempt a hail-mary towards a possible pivot? Can we get a little focus here?

The obvious candidates

In item #10, a strategic partner is changing an API, and if you want to keep working with them, you’ll need to update some code. This happens to every PM that worked with external integration. It sucks, as it doesn’t provide new value to your users. However, almost always, this simply has to be done. With the info given, if a candidate doesn’t mention this in the shortlist, it should be a red flag. Ask them why.

#5 (onboarding improvements) is another easy pick for me. One of the strategic goals of the company is to make the product more self-served, and it’s only 2 dev-months of work.

Up for debate (this is the fun part!)

What do you think about the refactoring item? Do you include it? There no obvious answer here IMO, but it definitely leads to some good info about the person interviewing. Some asked me what refactoring is, which testifies to little technical understanding and little past experience working directly with dev (might have done a more outbound position). Some proudly told me they always decline such requests from dev, which is a disaster both in terms of their technical understanding, and their understanding of the symbiotic relationship a PM should have with their dev team lead.

And how about the internal analytics tool? Can you do without it for another quarter? Probably. Should you? That’s a great lead to see how data-oriented your candidate truly is.

Or take item #12. The customer says they’re gonna leave without this one special feature, but will they? Can this be resolved in other, more creative ways? Is it possible to talk them down without building an ad-hoc feature that might not be relevant to other users?