PM product design interviews

Detailed overview of product design interviews, including what to expect, a sample framework and full interview example

Allen Yang, ex-Google PM, Head of PM at Bubble Updated: June 27, 2022

Frameworks | Advanced tips | Example answer | Video mock interview

In any PM interview process, you're going to encounter the product design question.

These questions gauge your ability to think about a new or potential product critically - about who its target users are, about what needs those users have, and about how the product satisfies those needs. Although these can be fairly broad, there is a straightforward framework that is useful for approaching these questions.

Product design framework (Top)

Generally speaking, a good product should solve a user's need in an effective, and perhaps even elegant or delightful, way. At the end of the day, people use a product because it actually does something for them. As users' basic needs in an area are met, the bar for what a good product looks like might rise.

Reality, of course, is nuanced. Some problems are about fundamental needs (e.g., Streeteasy for finding a new home), while others might be about desiring a psychologically positive emotion (e.g., TikTok for finding amusing content). Some products can have many target user groups (e.g. Quickbooks for accounting for businesses of different sizes); others may have a very specific target user (e.g. Jira for software development teams). Some products may end up solving many user needs (e.g., Facebook), but most products tend to start with one user need (or a tightly-related cluster) and expand from there (e.g., Google Sheets).

Good products also tend to solve user needs well, some might even say elegantly. An elegant solution could be so simple that it's hard to imagine what life was like before that solution, or a very creative solution. "Elegant" is relative and might change over time as more products come to market addressing that need.

Rarely does a need get 100% solved, nor might the need be solved permanently. Needs evolve as users get accustomed to the products out there; having one need addressed also frequently leads to developing new needs. This is what keeps product people on their toes!

So given all this, what does a strong product answer usually cover? A simple but very effective framework focuses on the users: Who are they? What do they need? How can we address that need?

Framework Step 1: Identify the users

With any product question, the first step is always to identify the users. It sounds simple, but is easy to forget sometimes. No matter how simple the question seems to be, start by clearly defining who you think the main user group is. It's fine if you think there are several core user groups - call them out!

For a lot of product design questions, it's fine to have a broad user group. Perhaps it's "millennials" or perhaps it's "people who shop online". It could be interest-focused, like "people who like to explore new restaurants". The user group can be defined by any number of factors, such as demographics, profession, background, experiences, or interest. You definitely want to define and describe the user group, but there isn't necessarily one framework for how to define a group.

Be careful when using yourself as the user group. It is completely fine to draw upon your own experience to answer a question if you do think you are the target user. But, make sure to generalize your response to the entire user group.

For example, you don't want to say "I think Venmo should build a feature to help split bills because I do that with my friends often". A stronger statement would be "Based on my own experience and that of my friends, I think millennials are often in situations where they need to split expenses among a small group, which Venmo could help with". The framing matters - note how the latter is a more generalized statement, rooted in a reasonable assumption, that could help a team steer its product decisions.

Framework step 2: Identify relevant user needs

Once you've declared the target user, identify the problem they have. If you've identified more than one target user group, state these "pain points" for each group - it's fine if multiple groups share a need, but try to differentiate different groups' needs at least somewhat. Again, it's more important that you do this step at all than to use a specific framework for thinking about the need. It could be something really obvious, like "users need to find affordable housing", or something much more nuanced, like "users need to find an atypical mortgage program which they're eligible for".

Remember that, when discussing a product, there's usually one or a couple main pain points as well as adjacent needs the target users may have.

Framework step 3: Identify product solutions

You've identified the users and their needs; now, you can analyze a product to see how well it satisfies those needs. What does the product actually do to address these needs? Is it effective? Does it do it with a clean UI and in an intuitive way? Or, does it have broad functionality to satisfy different variants of the need or a lot of adjacent needs?

If you're analyzing an established product, chances are that it does solve the needs of its target audience(s) - that's what keeps it in business. But, users' needs are rarely solved 100% of the time, so you should think about ways the product could improve. Don't be afraid to describe in plain language why you think a product fulfills the user's need well, even if it seems relatively obvious.

The most important thing to do is to tie everything back to the target users and their needs. This sounds simple, but it's easy to forget in the heat of the moment.

With some questions, at this stage you'll have the chance to brainstorm, which is a great way to showcase your creativity! If you're asked how a product could better address its target user group, then go ahead and be creative - just make sure that you tie everything back to the user and their need. It's fine if an idea you come up with doesn't address the user needs 100% - if that's the case, just note that and say what's lacking. At this stage, it's less about having a "right" answer and more about showing how much you think and care about the user.

Extending the framework

That basic framework will get you pretty far with a product design question. Often, there are next steps which would strengthen your answer or which the interviewer might request.

One extension goes into product metrics. Given the user, user need and product, how do we know quantitatively how well the product solves the need? This is an opportunity for you to demonstrate knowledge about how to measure the impact of a product (for more advice on this topic, see [this blog post]). Relatedly, you could discuss how you get qualitative feedback about the idea from users.

Another direction that could be fruitful is considering the competitive landscape - is there a product out there that does something similar to what you're describing? How well do they solve the user need? How can your product differentiate yourself? Or, you could discuss any business considerations here, like how you think your product could be monetized. These are all topics that a PM might think about; hopefully your interviewer will give you some guidance on whether they want you to delve deeper in a particular direction.

Note that the scope of a product design question can vary a lot. Sometimes you may be designing a new product. Other times you may be talking about a small feature in a bigger product. Other times you may even be talking about the go-to-market (GTM) strategy of a product. In all these cases, you can still identify the target user, their needs, and what does (or doesn't) fulfill those needs.

💡 Got a PM interview? Our PM interview drills help get you in top form

Additional tips on the overall approach (Top)

To recap, the framework for product questions is relatively simple: identify the target user group(s), describe their user needs, and think about how the product satisfies those needs. Note that interviewers usually constrain some part of the problem - either they'll give you the product to analyze, the user group to target, a specific need of a specific group, or parameters of a given solution. But such a constraint will rarely invalidate the framework.

There are some more tips that you should keep in mind to make your response even more solid.

Mix in obvious answers with really creative ones

Obvious answers are completely OK to state - "of course, Spotify addresses the user need of wanting to listen to songs from the past by having a library of almost 100% of songs from history". But, remember to show some creativity at some point in your answer! Creativity for a PM means that you can think broadly, coming up with ideas that are executable as well as crazy moonshot ideas. If you do come up with a moonshot idea, it often helps to qualify it as a crazier idea, but it's rare that you get penalized for being too excited about cool, new ideas.

Prioritize whenever you can

A core part of the PM job is to prioritize. In your response, if you're ever listing out more than one of something in an answer, it's probably an opportunity to prioritize.

For example, if you think there's more than one user group, then prioritize which ones you think are more vs. less important for the company. If a target user group has more than one user need, then prioritize by order of importance. You don't need to go crazy doing this but, since this is so much of what a PM does, it's useful to demonstrate that you can do it too.

Just make sure you have some justification for your prioritization. Justification might be quantitatively based, such as with market data or usage numbers that suggest potential impact. If you don't have this data, it could be useful to mention what kind of data you wish you had in order to prioritize. It can also be qualitatively based, if you have a gut feeling about why one thing might be more important than another - remember to explain your gut feeling though.

Call out assumptions and note what kind of data you want

Feel free to make assumptions in your answer (e.g. of what the core target user group for a product is), but call out that you're making an assumption. For bonus points, mention what kind of data would help to prove your assumption, or mention techniques to gather that data. For example, if you're making assumptions about the core user group, then perhaps you could propose running some in-person studies of users to verify your hypothesis.

Be data-minded

Most tech companies today either are or aspire to be data-minded, so being data-minded is a good quality for a PM to have. To demonstrate this skill, sprinkle your answers with comments on what data you'd like in order to make better decisions. Don't forget about both qualitative and quantitative data. For the former, you generally go out, find users of your product, and talk to them about their thoughts and reactions. For the latter, you can do things like log how many times a user uses a particular feature, for example.

How would you test your ideas?

PMing is not just about having assumptions, but it's also about verifying those assumptions. If you have an idea for a feature, great - how would you see whether users actually want that feature? For example, you might want to get users to react to some mocks of a potential feature. Or, if it's relatively cheap to implement technically, perhaps you want to run an A/B test exposing some users to your idea, to see whether metrics improve.

Don't be afraid to go on for a bit

The framework and tips above all result in a lot of information to any given question. That's OK! As long as you don't belabor a point so much that the interviewer suspects you're buying time, it's fine to cover a wide breadth in a product design question. If anything, it shows that you can think of lots of alternatives and deal with uncertainties appropriately. As long as you keep your answer moving forward and you're still addressing the question that was asked, then don't be afraid about talking for a bit - the interviewer will redirect you if they want.

Hidden product questions

There are some questions that might not seem like product design questions, but they really are. Generally, be paranoid on this point: if you get asked a question that's not obviously a fit, analytical, or technical question, you can probably assume it's a product design question.

Product design questions sometimes take innocuous-seeming forms. For example, "What is your favorite product and why?" fits in this category - you should definitely talk about the target user and how the product solves the user needs! If you have a chance to apply the product framework, then consider erring on the side of doing so.

Product design interview questions (Top)

Here's a list of 10 example product design interview questions to get a sense of the scope of questions you can expect in an interview:

Example question #1: If you moved to a different city, how would you design an app to search for doctors in your locality?

Example question #2: How would you design a motorcycle renting app for tourists?

Example question #3: How would you design YouTube for kids?

Example question #4: Design a social travel product

Example question #5: How would you design a mentorship program for LinkedIn?

Example question #6 How would you design a new peer to peer payment app?

Example question #7: Design a blood donation app

Example question #8: How would you redesign an ATM?

Example question #9: Design a touchscreen table for restaurants

Example question #10: How would you design a wellness focused smart watch?

Example product design question (Top)

"Design an X for Y" is a common product design question, where X is a noun and Y is a user group.

"Design a refrigerator for the blind."

Example answer

We want to design a refrigerator for the blind. [Note: the target user is given in this question - that's fine!] Normal refrigerators may be challenging for blind users to use because they rely on users' vision. There's generally little guidance from the product about what's inside of it and where things are, so users have to look to navigate the contents.

First, let's think about our target user group. Blind users are the target audience, but there might be a few different subgroups. Some users may have been blind at birth - they might have fewer preconceived notions about what the inside of a fridge looks like or how they're typically organized. Others may have lost vision sometime later in life - they might know what a "typical" fridge looks like inside and where things generally go. Yet another sub-group is those who are severely vision impaired or legally blind - I don't know the technical definition here, but I'll assume that these users can see general outlines but not at very high definition.

Next, what are the needs of these different subgroups relative to a fridge? A fridge stores food at certain temperatures. In order to use a fridge, a user needs to know what is in it and where. So for all our subgroups of blind users, they will need some way to learn about what is in the fridge and where. As they're using the fridge, they may also want to put items into the fridge - in our case, we need the fridge or something relating to the fridge to "remember" what is being put in it and where, so that this information can be surfaced later. This is all assuming, of course, that we want the fridge to help out with this problem at all - blind users can probably use their sense of touch with a "normal" fridge to identify items in it, but this is not a very empowering experience. I'll assume that we want to design a solution that's a bit more elegant for this target user.

How do the needs of our subgroups differ? Those who were blind from birth and those who became blind later in life may need some kind of introduction the first time they use a particular fridge, so that they learn what the layout of the fridge is. For example, they may need to know that the fridge has three shelves and two drawers at the bottom, with three shelves on the inside of the door as well. For those who are legally blind, they may be able to see the rough layout of the fridge, so they may not need such an introduction feature.

So how can we address these needs? The main thing about these users is that they can't rely on vision. So, the fridge has to rely on some other means of communicating with the user - voice and touch are appealing choices.

A very basic way to address this need, although not a smart one, is to rely on braille. Based on studies we do of the typical proportions of what people store in their fridge, perhaps different sections of the fridge can be labeled in braille with different categories of foods. For example, we can label one area of a shelf on the inside of the door for "milk", a drawer at the bottom for "vegetables", etc. The problem is that the user may not store items in the same proportions as what the labels assume. To address that, perhaps we could also test the idea of just braille-labeling the different sections of the fridge with just a coordinate system, such as "top shelf left", "top shelf center", "top shelf right", etc. This has the advantage of offering the user flexibility, but at the cost of having less descriptive labels. This would be a pain for another blind user coming to this fridge for the first time, since they wouldn't be able to guess what's in each section by just reading the labels.

A smarter fridge might allow the user to record what's in each section of the fridge. While this user is loading the fridge, the user finds an empty section, pushes a small button there, and then verbally says what is being stored there. The fridge records this and later, it can repeat back an inventory of the fridge with where each item is. There could be a cool feature whereby the user can ask the fridge where something is, and the fridge will look that item up in its inventory to report its location.

An even smarter fridge might sense how full a section is, either by detecting the size of the objects in that section or measuring the weight of the contents. This could be helpful for our blind users because it could answer questions like "How full is the egg section" or "How much milk is left?". This feature is much like how sighted users can see with a glance what groceries they may need to replenish.

Do our different subgroups need different features? So far, the features I mentioned are mostly with completely blind users in mind, but they do benefit legally blind users as well. One difference in needs is that legally blind users probably need a light in the fridge still, while completely blind users don't. When designing some of our ideas, the different subgroups also matter - for example, it may be easier for legally blind users to spot major interface points, like buttons, inside the fridge that are needed to trigger any of these features.

What's cool about some of our ideas is that they could benefit users who aren't blind too. For example, fridge alerts about being low on an item could be generally useful for all users. With some of these building blocks, eventually the fridge can keep track of a shopping list for you in an app, or allow you to see, on the go, like at the grocery store, a general sense of how full your fridge is in different sections.

There are so many more cool features that might be useful for blind users. For example, a built-in bar code scanner may make it easier for the fridge to identify items as they're being put in. The fridge could also integrate with online shopping services like Instacart, if it knows its current inventory level. Our fridge might also help alert blind users when something might be going bad soon, with warnings like "Warning: you last recorded putting milk in the fridge 4 weeks ago. Check to see if it's spoiled." Sighted users can rely on their vision for seeing some of this, but the fridge can help blind users with the same need.

How would we go about testing some of these ideas? A prototype might be effective - we could retrofit a fridge with some additional buttons hooked up to a prototype app. Ideally, we'd test it with a bunch of users in our target group, and see if it helps them solve some of the key user needs we're thinking about. We'd definitely want to develop some score for how easily they can accomplish key fridge-related tasks with and without our new features, so that we can see how helpful they are.

Additional example: product design mock interview video (w/ Google PM)

For another example, check out the video below where RocketBlocks Founder, Kenton Kivestu, gives me a product design case interview.

Final commentary on product design interviews (Top)

This answer could have gone in many other directions depending on the ideas you came up with in the interview.

But, in this answer, we identified some subgroups of users, noted their user needs (which actually are pretty similar, which is fine), and then dove into some ideas of what that means about the fridge. We brought up a bunch of different ideas for features, which hopefully shows off creativity, and we capped it off by talking about how we might test our product ideas.

Remember that it all comes back to the target users and their needs; with this question, we brought them up constantly and tried to create a product to satisfy their needs.