Three key steps to doing a product deep dive before your PM interview

Very few things will impress a PM interviewer more than bringing a new insight to them about the product he/she works on.

How can you do that? Go deep on the product.

Interviews are *not* product demos

First, let's get one thing straight: interviews are not the right venue to be learning basics about how the product works.

Remember, if you get the job, you will be managing the product, determining which features to build, etc. Thus, it's not confidence inspiring if you walk into an interview and don't have the foggiest idea about how the product works. It seems obvious, yet many candidates screw this up. Don't be one of them!

Instead, you want to make the opposite impression. In fact, if the very first question was: "Explain our product to me as if I were your grandmother" it would roll off of your tongue.

Three key steps to a product deep dive

  1. Define the value proposition
  2. Model the core mechanics
  3. Wear the CEO hat (i.e., ask the tough questions)

#1: Define the value proposition

If you're going to succeed as a product manager, you'll need a strong understanding of the value proposition and why customers use it / buy it / etc.

A value-proposition mad lib

If you're struggling to define the value proposition, a "mad lib" exercise can kick start the process. It's a simple exercise that requires you to think deeply about what belongs in each of those blanks.

Sample mad lib

Customers that have [ problem type ] ___________ use our product because it helps them accomplish [ task ] ___________. Before our product / service existed, they solved the problem by [ manual task(s) / alternative product(s) / ignoring it ] ___________. Our competition, [ company(s)___________ ], wins some customers away from us because its [ feature X, Y or Z, network effects, brand reputation ] ___________ is compelling. But, ultimately, we believe our [ secret sauce ] ___________ will enable us to earn a market leading position.

But what if the product doesn't have customers?

But what about a PM role managing the internal analytics dashboard? There are no customers. Wrong!

Every product has a customer, whether that end customer is a consumer, an enterprise, a small business, a developer or an internal executive, it is a customer. For example, a PM managing an internal analytics dashboard has customers - it's just that his/her customers are any internal stakeholders that rely on that dashboard.

#2: Model the core mechanics

The next step: model the core mechanics of the product and/or service.

Don't worry! The intent isn't to build a 27-page Excel model that can predict user engagement next quarter or revenue a year from now. Your goal is simply to start building a simple, mechanical model that can inform your understanding of how the product fits together.

To start, you can draw on questions which naturally bubble up as a by product of defining the value proposition:

  • How many customers actually use this product?
  • What do those customers pay to use the product?
  • What core actions do users complete in the product and how frequently do they do it?
  • What type of staff is required to support this business?
  • How does the product acquire customers and what does it cost?
  • And so on...

The most pertinent questions will vary depending on the product so you'll need to think critically about what matters. For example, if you're interviewing for an internal facing product, how much customers pay will be irrelevant (barring any transfer pricing). However, how often customers engage per day and what actions they take would be important.

Furthermore, there will be a bunch of variables you don't know - that's OK! Just use placeholders and make a mental note of an open question (those become great questions to ask your interviewer!).

Sample model

To illustrate, here's a real example from an interview process our CEO went through in 2014 for a role as Head of Product at a food delivery startup. From press releases and blog posts, he was able to garner a few key facts that served as baseline assumptions and "sanity checks": the company was doing around $20K in revenues per day and they operated in 6 US cities.

Given the intense competition for on-demand delivery contractors, the goal of the model was to understand how many drivers were really needed to support their demand, how much driver acquisition would cost and what levers could help reduce that cost.

Insights from the model

Once you've built a model, it serves as a jumping off point for additional probing and insights.

  • Driver acquisition costs are about ~30% of overall revenue
  • If you reduced monthly driver churn to 10%, it would bring driver acquistion costs down to ~20% of revenue
  • If you reduced average delivery time to 24 minutes from 30 minutes, it would bring driver acquistion costs down to ~23% of revenue

#3: Wear the CEO hat (i.e., ask the tough questions)

This third exercise will flow naturally from the prior two exercises.

For example, you might want to drill into what efforts have been made to reduce monthly driver churn. Given the importance of that metric on controlling costs, it seems that the company should be laser focused on driver retention and happyness. On a related note, you might be curious about what avenues the product team is exploring to bring down average weight delivery time (another metric which if improved would ultimately reduce driver acquisition costs).

These are the type of strong product questions that make for good fodder if you're asked about what questions you have. Once it's interview time, you can start asking the relevant people you meet the various questions they might have insight into.

The benefit is massive for two reasons: 1) these questions demonstrate to your interviewers that you've already started thinking deeply about the product and 2) they will further your own understanding of how the product and business works (NOTE: it's important to recognize interviewers may not be able to answer if the info is sensitive so don't be too pushy).

Back Next: PM organizations