Showing Product Sense During Interviews

•

In the product management canon, there are two prominent definitions of “product sense”:

From Jackie Bavaro:

“Product Sense is the ability to understand what makes a product great. It’s the ability to hone in on the important problems a product solves and come up with ideas to make it even better.” (link)

And from Shreyas Doshi:

“[Product sense is] “the ability to make correct decisions even when faced with considerable ambiguity.” (link)

However, having good product sense and being able to showcase it in an interview are not the same thing. In this article, we’ll talk about where those differences are, and how you can convey your product sensibilities in an interview format.

How Product Sense Is Shown In Interviews

While product sense is applied throughout a wide variety of situations in a typical workday, ranging from explicit demonstrations such as choosing a design, to implicit ones, such as setting default configurations, the scope of an interview is more contrived, and therefore requires a more concerted effort to show that your problem identification and decision making abilities are up to par.

In an interview, there are a few explicit points where product sense is the primary factor at play:

  • Identifying the fundamental problem to be solved
  • Working from the POV of the user, not the builder
  • Having an opinion where one is required

Let’s take a look at how this applies in different types of interviews.

Reflection Interviews

“Reflection” style questions are about past or existing work. Two common questions are:

  • Tell me about your favorite product (and how you would improve it)
  • Tell me about a product you’ve worked on in the past

In these cases, product sense is shown through how many layers of understanding you’re able to describe and weave together. Since the product already exists, analysis of user personas, pain points, etc. all have pre-existing “answers”, and your job is to understand the original product designers. If it was a product you already worked on, this is easy, and you can let your work stand for itself.

When evaluating existing products, taking a larger view of the product is helpful for putting decisions in context. For example,

  • What role does the product serve in the company’s lineup?
  • What is the company’s mission? Their KPIs? How does this product further those goals?
  • What are the industry pressures facing the company? Are there PR, legislative, or competitive concerns they have to address as well? How might these affect decisions about the product?

Keep this larger context in mind when evaluating the immediate product scope. Frame your thinking as “How well is this product solving a problem?”, and consider these guidelines to ensure your answer remains an objective evaluation:

  • Are your frustrations personal, or generalizable to other users?
  • Are you a typical user, or do your patterns put you in a different user group?
  • If a product is failing in one aspect, is there another problem it could be solving for instead?

Product Design Interviews

The most basic product design framework (which there’s nothing wrong with, by the way) is the following:

  1. User personas
  2. Pain points
  3. Solutions

For this portion, I’ll follow the same pattern, highlighting common mistakes that impact perceived product sensibility.

User personas

Are your user personas useful?

Remember that frameworks are just a tool, not a checklist you need to complete. Structural differences in users don’t necessarily translate into differences in use cases. Before segmenting the population, consider if the distinctions you’re drawing actually have an effect on the product you’re building. Sometimes you only have one user persona, and that’s ok. Acknowledge it, and move on.

Just because you don’t focus on them doesn’t mean they’re not there.

Focusing on one user persona doesn’t mean the rest disappear. In the real world, decisions meant to have isolated effects nonetheless impact whole ecosystems. As you’re building for one user group, keep in mind how your decisions may impact the others, and if the net benefit is still positive.

Pain points

Is the posed question a root problem or a symptom?

This can be difficult to tease out depending on how prescriptively the prompt is phrased (e.g. “Build an autonomous taxi service” vs. “Build the future of transportation”), but always consider whether you’re building a feature or a solution.

Sometimes an interviewer is in fact looking for you to just build out the product they asked. Sometimes the prompt is meant to be a jumping-off point for creative problem solving. You can typically determine which it is through your clarifying questions (e.g. “Why do we need x?”) and by checking in with your interviewer as you begin your initial exploration into the space.

As an example, a prompt to “Build an elevator for a giraffe” may prompt an examination into why giraffes need to be transported by elevator in the first place. Perhaps a reconfiguration of the building, or more modular equipment could bring the necessary items to the giraffe instead.

Solutions

Does your solution actually solve the problem?

Surprisingly, a majority of interviews I conduct actually end with a product that does something, but doesn’t solve the original problem. Often this stems from a lack of a clear problem statement to begin with.

It can be easy to focus on one or two pain points, design a product that focuses heavily on those pain points, and think that your product accomplished its goals because it improved upon the pain points. Unfortunately, focusing on a handful of pain points at the expense of the rest of the product often leads to an unbalanced product.

Is your solution complete?

Walk through your “finished product” as proposed, and do a sanity check that it makes sense, doesn’t have lapses in flow, and accomplishes everything you set out to accomplish. Try to switch perspectives and identify any externalities your changes may cause.

It’s okay if you find something missing! It helps no one to pretend like you didn’t miss a use case, or to claim a clunky UX is flawless. Use the opportunity to show that you can self critique, recognize when products aren’t polished, and how you would approach iteration.

Do you agree with your solution?

A product is a series of decisions, and some matter more than others. In most cases, the color of an icon is irrelevant in an interview. The feature set to be included is highly relevant.

On the decisions that matter, you should work to develop a systematic point of view. It’s okay if you start with a simple point of view, and add nuance to it as you encounter more complexity throughout the process. It’s okay if you even decide your POV is wrong, and switch sides halfway through. But as a product manager — as the person tasked with embodying your users, your business needs, your developers, the entire world around the product — you must continuously be developing a point of view of what the product is for and how it achieves it.

Because at the end of the process, you have to ask yourself, are you personally satisfied with the experience? Would you use your product?

Product sense in interviews isn’t some intangible feeling that interviewers can simply “feel”. It’s determined from the body of your decisions, judgement, and the directions you choose to pursue. Be focused, thoughtful, and intentional, and your product sense will shine through.



Programming-curious?

I put together a 9-part course on algorithms designed for non-technical readers that's a great, gentle introduction to thinking like a programmer. Get the course for only $5, or download the first chapter.