3a. The product interview framework

How do I answer a “product question”?

During your PM job hunt, most of the interviews you’ll have will fall under the general category of “product interview”. These chats will assess how you think about product, and will resemble, at a high level, what PMs are actually charged to do: improving the product.

The questions in these interviews can run a wide gamut of topics, shapes and sizes. But luckily, there’s a common underlying framework that you can use to address most of these questions, and there’s some general advice which can help with any kind of product question thrown your way.

What makes a good product?

There is probably no right answer to this, but in general a good product should solve a user need in an effective, perhaps even elegant, perhaps even delightful, way. As more and more of users’ needs are solved, the bar for what a good product looks like might rise. But at the end of the day, people use a product because it actually does something for them.

Some problems are more fundamental than others, but problems are problems as long as any group of users yearns for a solution or derives some kind of psychologically positive emotion when the problem is addressed. Some products can have many target user groups; others may have a very niche user group. Some products might try to solve many user needs, though most products tend to start with one user need (or a tightly-related cluster), and address related user needs as the product grows. These principles are easy to spot in some of the largest tech products today. For example, Facebook now serves many target user groups, especially when you consider all the different major parts of the overall service (e.g. Facebook Events address very different user groups and needs from Facebook Pages). And, Facebook started off by allowing users to connect with their classmates, and then expanded to allow users to keep in touch with all their friends, then find users with similar interests, then find products that fulfill their interests, etc.

Good products also tend to solve user needs well, some might even say “elegantly”. An elegant solution might be one that’s so overwhelmingly simple that it’s hard to imagine on the “old way” of solving that user need. An elegant solution might also solve the user need in an unexpected way. What it means to be “elegant” is relative, and might change over time as users get used to other products in the market.

Also, it’s important to note that rarely does a user need get 100% “solved”, not would the user need be solved “for good”. Needs evolve as users get used to what they have at their disposal and develop new needs in their lives. This is what keeps product people on their toes!

So given all this, what does a strong product answer usually address?

Framework Step 1: Identify the users

With any product question, the first step is to identify the users. Seriously – this step is often hard for some questions which seem blisteringly direct or simple. Always start by clearly defining who you think the main user group is. If you think there are multiple core user groups, that’s fine – enumerate them!

Generally when you’re talking about most products, it’s fine to have a relatively broad user group. Perhaps it’s “millennials” (that’s a popular one if you as the candidate get to pick the product to discuss). Perhaps it’s “people who are used to shopping online”. It could even be something like “people who like to explore new restaurants”. In other words, the user group can be delineated by any number of factors, such as demographics, profession, background, experiences, or interest. But, you should start off by declaring who you think the user group(s) is/are.

A common pseudo-mistake is to use yourself as the user group. It is completely fine to draw upon your own experience to answer a question if you in fact are in the target user group, but you should absolutely try to generalize your own opinions to the entire relevant user group, and beyond just yourself. For example, it’s a bit too narrow to say “I think Venmo should build a feature to help split bills because I do that with my friends often”, but it’s much more interesting to say “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 here makes all the difference – the former statement is a rather self-centered statement about what you want from a product, but the latter is a more generalized statement, founded upon a reasonable assumption, that could help a product steer its attention and efforts.

Framework step 2: Identify relevant user needs

Once you’ve declared the target user, identify the need they have. If you’ve identified more than one target user group, say what the need is for each group. These needs are the “pain points” – something these users need or wish to have solved in their lives.

If you’ve previously identified multiple user groups, it’s fine if those groups share a need or very similar needs. But, try to differentiate the different groups’ needs at least somewhat, since it’s unlikely they’ll be exactly the same. It’s fine to try to minimize the difference in their needs, but you should still at least note the distinction.

Remember that when discussing a product, it’s usually not just about the main user need that the target users have. You should also be thinking about adjacent needs the target users may have, or group similar to the target group that might have similar needs.

Framework step 3: Identify how the product solves the needs

After you’ve identified the users and their needs, then you can analyze a product and how well it satisfies those needs. What does the product actually do to address these needs? Does it do it well? Does it do it with a clean UI and in an intuitive way, or does it have a lot of functionality to satisfy all the different variations on the user need?

If the product you’re analyzing is a relatively well-established product, chances are that it solves the needs of its target audience(s) fairly well. Again, users’ needs are rarely solved 100% of the time – so you can always find 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 – perhaps it’s not a topic to dwell on, but it’s always good to commend a product for achieving something relatively straightforward well.

The name of the game here is to tie everything back to the target user(s) and their needs. This sounds simple, but it’s tempting to forget, especially if your’e talking

With some questions, at this stage you’ll have the chance to brainstorm. This is a perfect time to showcase your creativity! If you have free reign to think about ways in which a product could address its target user group better, for example, go ahead and be creative – just make sure that you tie everything back to the user and their need. And it’s fine if an idea you come up with doesn’t address the user need 100% well – if that’s the case, just note that and say what’s lacking.

Note that the scope of the question can vary widely. Sometimes you may be designing a completely new product. Other times you may be talking about a small feature that’s a part of a much bigger product. Other times you may even be talking specifically about the go-to-market (GTM) strategy of a product. In all these cases, you can still identify the target user, their user needs, and what helps (or doesn’t help) fulfill those needs.

Advice on the overall approach

To recap, the framework for product questions is relatively simple: target user group(s) -> user needs -> things about the product that satisfy that user need.

Questions you might get in interviews 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. If this is the case, feel free to address the question as given – in other words, go along with the constraints given, and talk about how certain features can satisfy (or not) certain users or their needs.

If any of the above dimensions are not restricted, then it might be worthwhile for you to get creative, and come up with a small handful of ideas for that dimension, and rank them in terms of priority order. For example, if the question does not constrain exactly which user group you should focus on, you should list out a bunch of potential user groups, and try to roughly prioritize them in terms of importance. If you do this, make sure you give some justification for why you’re picking the prioritization order.

Other general pieces of advice

Mix in obvious answers with really creative ones

Sometimes it may feel like an answer is obvious – “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, obvious answers are completely OK to state – as long as you mix them in with some creative answers. Maybe these creative answers aren’t when you’re describing how an existing product addresses an existing need, but it’s fine to state the obvious as long as you’re bringing it back to users and their needs.

That being said, if you have a chance to be creative, take it! Use those chances to show that you can think broadly, that you can come up with both creative ideas that are executable, as well as crazy moonshot ideas. If you do come out 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

If you’re ever listing out more than one of something in an answer, it may be a good idea to prioritize. If you think there’s more than one user group – prioritize by which ones you think are more vs. less important for the company. If you’re listing out more than one user need of a group – prioritize by order of importance. This prioritization doesn’t need to be more than one sentence per object, but since this is so much fo what a PM does, it’s useful to demonstrate that you can do so. Just make sure you have some justification for the prioritization you’re stating.

Call out assumptions, and note what kind of data you want

If you ever make any assumptions (e.g. of what the core target user group for a product is), feel free to do so, but just call out that you’re making an assumption. For bonus points, you can mention what kind of data you’d want to prove your assumption, or techniques for gathering that data. For example, if you’re making assumptions about who the core user group of a product is, perhaps you could propose running some in-person studies of users of your product to see if you could detect any patterns about your users’ needs or demographics.

Be data-minded

Most tech companies today claim to be data-minded. Whether or not that’s true, being data-minded is always a good quality for a PM to have. Don’t be afraid to sprinkle your answers with comments on what kind of data you’d like in order to make better decisions. Don’t forget that there is both qualitative and quantitative data that companies can get – it’s not just about logging how many times a user clicks on a button, for example. You can also actually go out and find users of your product and talk to them about their thoughts and reactions.

How would you test your ideas?

Another generally good thing to mention in your answers is how you would go about testing your assumptions or ideas. If you have an idea for a feature, great – how would you go about making sure that users actually want that feature? For example, you might want to create mocks of that feature and show them to some users to get their qualitative feedback. Or, if it’s relatively cheap to build, perhaps you want to run an A/B test exposing some users to your idea, to see whether certain metrics improve.

Don’t be afraid to blabber a bit

If you followed all the advice above, you’d be responding with a lot of information to any given question. That’s OK! As long as you don’t dwell on any given subject, it’s generally fine to cover a wider breadth in any given product question. If anything, it shows that you can think of lots of alternatives, and deal with the alternatives appropriately (e.g. deprioritizing them). As long as you keep your answer moving and you’re still addressing the question that was asked, don’t be afraid about talking for a bit – the interviewer will stop you if they want to dig deeper into a given area.

“Hidden” product questions

There are some questions you might get that might not seem like product questions, but which really are. Generally, be paranoid on this point – if you get asked a question that’s not directly a fit, analytical, or technical question, perhaps assume that it’s a product question.

Product questions sometimes take innocuous-seeming forms. For example, a question about “What is your favorite product and why?” is actually a prime product question – 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 and it doesn’t obviously seem like the interviewer is trying to test some other skillset, consider erring on the side of using the product framework to answer.