How to crack the PM interview

I’ve now been in a formal PM role for 18 months and have been on the “other side” interviewing candidates and making hire/no hire recommendations.

Everything below assumes you have a PM interview lined up and need tips at the actual interview, and the interview will likely involve a whiteboarding exercise. I’ll also use the following (fictitious) prompt to guide some of the recommendations:

We are an eco-conscious company and want to build an internal ride-share app for employees, since so many people drive to work. Please take us through what the MVP of this app looks like."

Use a framework

The specific framework you use doesn’t really matter, but what’s crucial is that you have a logical, repeatable process that you can mentally reference so curveball questions don’t throw you off. In addition to making sure you don’t skip a step while in the heat of the moment, having a methodology gives the impression that you have solved these problems before and the interviewers can trust you! This is particularly valuable if you are coming from a non-PM background.

I don’t recommend explicitly stating, “I will be using [Methodology X] to solve this interview problem.” That makes it sound like you learned how to do this from reading a book , and not through actual process and experimentation. If it doesn’t come naturally, keep practicing!

Don’t start solutioning (and the solution doesn’t even matter!)

One of the more frequent cardinal sins I’ve seen is after the prompt has been given, the candidate immediately starts white-boarding a solution. Unless you are specifically interviewing at Uber, Lyft, or another specific transportation company and they actually care how you would design a ride-sharing app, the purpose of the interview is to see how the candidate thinks. No sane interviewer is going to leave the interview thinking, “Wow, that candidate was clear, logical, articulate, had a great framework, asked great questions, stated her assumptions and reached a viable solution, but I would have solved the problem in a different way, so I don’t think we should hire her.”

Also, if you’re interviewing at a large enough company with a decent interview process, they likely have standardized their interview process, and maybe even their interview questions. So while it’s interesting to see how a candidate approaches the problem (because everyone does it differently) oftentimes the solutions look similar. Don’t worry about making your solution unique; the interviewer probably doesn’t care.

Ask lots of questions!

You’ve been given a super vague prompt, and you have an hour to “solve the problem”. Now what? As a general rule of thumb, I would recommend you don’t start solutioning until at least the second half of the interview. Use the first half to ask lots of questions. You can’t build a solution if you don’t understand the problem, anyway!

Here are some of the questions that you can generalize across virtually all whiteboard examples:

  • What does success look like? Are there established measurement criteria/OKRs this app is being built against?
  • Who are the stakeholders? Did they come up with this idea, or is it customer driven? Do all the stakeholders agree we should be building this?
  • What sort of market research has been done? Who/what are our competitors, and how are they doing?
  • Do we have enough evidence that building this app is a good idea?

As a side note, be prepared for the interviewer to throw all of these questions right back at you! So if you came in and asked me, “What does success look like?”, I would answer in the interview, “Hmmm…that’s a good question, what do you think?”, and if you were a great candidate, I would expect a ~5 minute back and forth on the possible measurement criteria, you weighing the pros and cons of each of them, and ultimately coming back with an OKR on what we are measuring success against.

These are just generic questions, but you should absolutely dig as deep as you can into the specific problem space of the actual exercise.

Some of examples of questions that come to mind for the specific ride-share app might be:

  • Do we have data on what % of our employees have cars?
  • Do all employees come to work at the same time? Leave at the same time?
  • Do we know where all of the employees live?
  • Are we incentivizing ride sharing, or is “going green” the only motivator?
  • What are the demographics on our employees?
  • What options exist if an employee can get a ride to work but needs to stay late?
  • Are there any legal issues if we allow employees to pay each other for gas/tolls?
  • Are there any must have features in this app to satisfy key stakeholders?

Hopefully you get the idea. Some of these questions might yield no information, some might yield a gold mine, but there’s no way to really know until you ask! Try to follow each thread to it’s logical conclusion, and if you don’t understand something, keep digging.

Use your time wisely, and listen for feedback!

Assuming you only have an hour or two, there is no way you can accurately capture the business and user needs of the app, whiteboard a solution, and answer all the questions the interviewers are throwing at you. It’s totally OK to skip some steps, as long as you explicitly communicate this to the interview.

As an example, you might say,

In the interest of time, I’m going to verbalize that I would want to talk to a group of potential users and understand their pain points, and make sure they match what I am hearing you say are the stakeholder priorities. Unless you say otherwise, I’ll proceed as if that’s the case.

If your interviewer is experienced with the process, they might guide you down this route, anyway. For example, your interview may say, “You only have 30 minutes left, let’s start seeing the solution.” In this case, don’t argue or proclaim that you “Can’t possibly develop a solution without talking to users” - just follow their guidance. On the other hand, if they are engaging you in the questions you ask them, and are giving you good information, keep asking!

As a rule of thumb, I would much prefer to see 80% of an interview go great and have the candidate run out of time, than the candidate getting through the whole interview but feeling rushed and missing key steps.

State your assumptions explicitly!

Stating your assumptions is a super easy way of letting the interviewers know you are methodical and are thinking about the edge cases.

My assumptions for this ride-share app might look like:

  • Employees have reasonable access to a smartphone + data/wifi
  • Employees are willing to share personal information (e.g., home address) in order to carpool
  • Employees live close enough together to make carpooling feasible
  • Employees are actually driving and not taking public transportation
  • Company’s Legal Department is cool with allowing this due to potential liabilities.

(Your assumptions might be totally different, based on what you perceive the risks to be. That’s OK! There’s more than one way to skin a cat, which is what makes Product Management so magical.)

De-risk your assumptions

Now that I have my assumptions, I want to figure out which is the most risky (or in other words, which is most likely going to cause my product to fail) and de-risk that assumption. Some of these assumptions are super easy to test.

For the smartphone assumption, I may ask, “Is it a reasonable assumption that employees have smartphones?” Your interviewer will likely say, “Yeah, sure”, but if the answer is “How would you verify that?”, I would just go poll 20 people and measure the results, no software needed. Same with the Legal Department - it would be totally fine to say in the interview, “I would validate this assumption by making a quick phone call to the legal department and getting a thumbs up.” (This is a much better answer than saying, “I would build it first and then see if any problems come up”)

Validating assumptions is a lot like building products, in that you should validate your assumption in the leanest way possible. (As a bonus point, I tell a lot of the guys I work with, validating an assumption and invalidating an assumption are equally good. What’s not good is running an experiment and not knowing if your assumption has been validated or not!)

Remember the “minimum” in MVP!

Another cardinal sin that I see frequently is candidates putting in cool bells and whistles. This is not the purpose of the exercise. At every step of the way, you should be asking, "Is there any way I can defer this feature or leave it out for a minimum release?

Keep in mind that an MVP need not even be software - for example, my MVP for the ride-sharing app might be setting up handful of WhatsApp groups that are based on geography, and I would run an experiment by measuring at the end of the week if any Carpool groups organically sprouted.

Any time you have a choice where you can build software and accomplish an outcome, or not build software and accomplish the same outcome, choose the latter. Building software is time-consuming and messy, so the more software you choose not to build, the better!

As a rule of thumb - if your wireframe mockup is more than 2 or 3 screens, it can likely be simplified.

Practice, practice, practice!

If you’re new to the game, this sounds like a ton of work…and it is! Getting this right is not something you can achieve by simply reading a reddit post. I would set aside 10 to 20 hours of focused interview prep to really feel prepared. If you’re not cool talking to strangers, find a friend, family member, or closest person in your company who does product and ask them to give you a mock interview. Run through the mock interview as if it were real (so a whiteboard, or at least a facsimile, is mandatory!), and spend a good 15 to 30 minutes afterwards debriefing. Ask things like:

  • Was my thought process logical and orderly?
  • Did my conclusion seemed justified based on my assumptions?
  • Were there assumptions you had that I wasn’t able to discover? If so, what questions should I have asked?
  • Did I come across as cool as a cucumber, or a nervous wreck?
  • Was I confusing? What would you have liked me to clarify?
  • Did any part feel rushed?

If you are aware of a certain skill gap that you have, focus on upskilling that area!

Be nice

Hopefully this is self explanatory, but…

If a candidate comes in and aces every part of the interview, but is is rude, I’m not going to recommend a hire. Why? Because I don’t like working with rude people, and neither should you. As a bonus tip, try to get your interviewers to laugh, or at a minimum smile. If they like you, they will have a harder time turning you down.

Hopefully this has been helpful. Feel free to ask me anything, and debate encouraged :slight_smile:

2 Likes

I have been in product for a long time and I loved how you broke down things into easy and actionable tasks. I would love to share this with my future hires if you are ok with that.

Only thing I don’t agree is your take on building whatsapp groups for your MVP. That’s just testing your hypothesis not building MVP :).

:slight_smile: Loved reading this. Thank you.

I feel at times I’m in the wrong job sometimes as I’m a front end dev with lots of business background. I’m also good at troubleshoot because of divergent thinking and asking questions.

This was really good to read though just to see what makes sense. Just all over helpful.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.