So recently I’ve been thinking a lot about product management interview processes, both the ones that I have put together myself as well as the ones that I went through in the past. A popular element of most of these interview processes is a case of some sort.

Usually the interviewing company will try to provide a case that is somewhat related to the business, e.g. they might give you a problem that they have solved recently in the past or something that they are considering to solve for in the future.¹ This is usually beneficial and insightful for both sides:

• The company gets to see how well you adapt to their problem space and how much you already know, can extrapolate or transfer from past experiences
• You get a really good look into what they’d consider interesting problems. The difficulty of the case (if you are certain you can read that), can tell you a lot about their expectations.

Interestingly enough I think after having gone through a bunch and also having seen a bunch (both successful and unsuccessful on both ends), I do see some kind of a skeleton for good cases. Every good solution (no matter whether it’s a presentation or a ) will cover roughly the following topics:

• A quick summary of the case sticking to the facts, no interpretation or anything. This makes sure the whole audience knows the deal, no matter whether they read the case beforehand or not, and also demonstrates that you understood the case.

• The “things I’d do if this was real“-section: This is the section where you basically unpack your methodology kit and show all the things that you skipped because it’s an interview without saying that the case is not a real product management situation but purely hypothetical.

  Mention all the validation, discovery, opportunity sizing and other things you would do in this place. You can even throw in that you would base the scope of discovery work on how quick a solution could be implemented and how important this problem is for the company.

• Assumptions: The previous section is methodology, this one is content. You’re basically saying “here are all the things that I am taking for granted that I’d usually validate one way or another”.

  This might be the most important section, since that’s often the difference between a successful and an unsuccessful interview. What frequently happens if you don’t do this, is that the interviewer disagrees with your conclusions and thinks you are wrong. When you make your assumptions explicit and your analysis is logical, nothing can really go wrong. The interview can call you on your assumptions, but when they do that, they will have to tell you what to assume instead and you can change up your answers based on the new assumptions. This section is also fun for the interviewer, what I frequently like to do with candidates, is throw some of the assumptions over and see how they react. Can they think on the spot and come up with alternatives or are they stuck with what they come up with? Tells a lot about the candidate.

• Analysis: You analyse the information in the case and prepare an analysis of what you think the problem is, basing things on your assumptions. Shows you took in all the information and managed to interpret it.

• Solution(s): You propose one or more solutions that work well given the analysis you just performed. Make sure to link these back to your assumptions also to make them solid.

  The scope of the solution is often pretty different, sometimes you’ll be expected to make some wireframes or some kind of simple prototype, sometimes they’ll just expect some specs. What I’d recommend in any situation is to keep an eye on data here. Mostly people will expect you to explain how you will know whether this solution is actually doing the job it’s supposed to, ideally by the way of KPIs: Define some measurements of how you know if it succeeds or fails, e.g. a retention, conversion or adoption metric. This is also a good point in time to show off your knowledge about analytics, you might throw in a balancing KPI or talk about leading or lagging metrics. Generally throwing in a comment a la “this would be an initial approach that we’d plan on shipping fast, but based on the data we’d like to iterate quickly”. You might want to adapt that comment though depending on your audience, it might not work so well in more corporate, risk-averse or hardware product companies.

• Implementation: Not always, but sometimes, someone will ask you for a roadmap or an implementation plan or similar, maybe even an estimate of how long you think it will take to implement. Some might disagree with me on that, but I’d generally advise to NOT include any dates or specific timelines. It will be really hard to not set yourself up for failure by doing that. The likelihood you end up where they think is reasonable, is incredibly low and it’s generally not something you should do as a PM.

  If someone pushes you on this, don’t let them put you in a corner and stick your ground on that (you’ll definitely win over the engineers in the audience this way). Instead I recommend talking about phases, stages or iterations, give a general sense that the speed can be impacted in many ways, but you’d really want to talk to the engineering team first and dig a bit deeper into the requirements before giving an estimate.²

There will be some variance depending on the case, sometimes there will be specific aspects empathised or things requested to be included specifically (or excluded specifically), but generally if you cover all the above points you should hit a lot of the requirements of any of the cases. In any case: best of luck!