When you’re asked to “build a product for X” or answer any other product design interview question, your task is clear: to make a case for what to build. In order to make that case, the first thing you need is a goal to train your finely honed product skills on.

It’s worth emphasizing at the outset that defining a goal isn’t just foundational for a sound argument, but it’s usually a mandatory parts of the answer. Your recruiter might have even pointed this out when they explained the interview format.

Despite this, goal definition remains a challenge for a lot of candidates. In this discussion, we’ll talk about what makes a good goal, how to put one together, and how to weave it into the rest of your interview.

Note: this article pertains to goal definition from a product sense/product design POV. For success measurement, be sure to also read the article on how to define a goal for a success measurement question.

What makes a good goal

In a product design case, a good goal has the following qualities:

• It’s Worthwhile. Your product must be anchored to an objective that people care about. This is important because a product tied to a meaningful and relevant objective is more likely to succeed due to the collective interest and engagement it generates. If the objective is not compelling, the product will struggle to gain traction, as it won't resonate with potential users or stakeholders.

• It’s Binary. Your goal must explicitly define success criteria so that it’s possible to say whether you accomplished it with a “yes or no” question. This is essential because, without clear or falsifiable criteria for success, it will be hard to argue that the solution was effective in achieving the goal.

• It’s mission-oriented. Your goal should explicitly include your company’s mission as a condition of success. The reason is simple: your product is not going to be successful if it doesn’t drive the company’s mission forward. When you discuss the company’s mission, it should always be from the perspective of defining what product ideas are acceptable, rather than from the perspective of judging whether or not the problem space would be a “good fit” for the company to solve.

• It’s people-centric. Your goal should make it clear that a successful product is one that people find engaging and get value from. This is important both on logical grounds—the product will only matter to the degree that people find it useful—but also on rhetorical grounds. As a product manager interviewing for a role, you should demonstrate your customer empathy wherever possible. Enshrining people-focus on the goal level does this very effectively, and gives you a reason to emphasize your focus again and again.

There are also some things that don’t matter nearly as much. Here are some elements you can feel comfortable skipping:

• Establising a “success metric”. You have 45 minutes or less to discuss a wide range of issues. Unless your interview explicitly asks “…and how would you measure success for this product,” go ahead and leave this part out. Most likely you will have a separate interview that will gauge your analytical ability. If you are unsure, you can always ask whether to include it or not.

• Narrowing down the space. I strongly recommend against narrowing down the problem or the solution space prior to the “body” sections (e.g., customers, pain points, solutions). This is because the body sections are for deciding what to do. The discussions of the goal matter for defining the goal, not for understanding what things to focus on to establish that goal. Keep all the narrowing for the body sections, each of which should include detailed discussions about what to prioritize.

Defining a goal

One effective way to define your goal is have a section devoted to it. In this section, you can include a “background” discussion that covers the items above in detailed, followed by a prominent and clear proclamation of the goal.

The Background

The background discussion lays the groundwork for the formal goal proclamation.

Its purpose is to justify your goal definition. Everything you say in this section should clearly have an impact on the goal that you chose. If you didn’t, you are probably rambling or pontificating. In a case interview, time is precious and we only' want to say things that move our argument forward.

Some items that are useful to include in this section include:

1. Why the problem space is important to people. This helps us prove our goal is worthwhile and people-centric (see above), while also helping us begin to imagine what motivations and problems people have in the problem space. The latter part is extra useful, because it can give you more time to think about later parts of your response while also establishing your goal.

2. How building a product in the space can drive forward the mission. This section satisfies the condition of being tied to the mission, but be careful: we can’t just assert that working in the problem space is aligned to the mission. We must explain why building a product in the space will further the objective of the parent company. This is a seemingly small difference, but talking about “alignment” is actually very ambiguous, whereas contributing to the company’s success is not.

3. Strategic considerations. While not strictly required, many candidates like to discuss strategic considerations like the competition or the state of the market. These can significantly deepen your discussion, since real-world product development must take this into account. Remember though, you’re not trying to “get points in”, you’re trying to make a case for the right product to build. Only include these items if you can explain why they matter to what you might build.

The Proclamation

I’m only kidding a little bit when I use the word proclamation. This statement should be really prominent and final, because once you say it you’re off to the next section and the real meat of your argument.

To make sure that I include all of the elements we’ve discussed so far, my goals follow a consistent, repeatable pattern that fits all of it into one sentence. As an example, let’s consider the question “build a parking feature for Google Maps.” In my background, I will have established* that parking matters to people because it’s required anytime a car is used, that Google’s mission of organizing information is furthered by making information about parking more accessible and useful for people, and that by making parking a more engaging, enjoyable experience we can make people better off. So, my goal would sound like this:

Alright, now that we’ve covered all of that, here’s how I’d like to define my goal: We’re going to build this new parking feature for Google Maps to make parking information more useful so people can have a better experience at their ultimate destination.

Let’s break this down. This goal is made up of three parts: a restatement of the prompt, a success criteria, and a statement about people impact.

1. The Prompt Restatement. In the example, that’s “We’re going to build this new parking feature for Google Maps...” This is important for the clarity of the goal, but doesn’t do much by itself beyond making it clear that your focus is on the right thing.

2. The Success Criteria. Here, it’s “…to make parking information more useful…” This statement captures a lot in just a few words, but above all else it defines what the product must accomplish in order to be acceptable as a solution for the prompt. In this case, the word useful does the job of defining a binary criteria: the product either succeeds in making parking information useful, or it doesn't. Additionally, focusing on information aligns the product with Google's mission to “organize the world’s information,” reinforcing the importance of driving the company’s mission forward.

3. The People Impact. The final clause emphasizes the core purpose of building the product: “…so people can have a better experience at their ultimate destination.” This statement addresses why people care about this problem space, reinforcing a people-centric vision. Demonstrating a focus on what matters to people shows an understanding that a successful product must help users achieve their goals. In this case, it’s about ensuring that people can reach their destinations easily and do what they intended to do there.

Including Strategic Elements

Other things that you might include in your goal include strategic considerations you may have define during your background statement. For instance, if you placed a lot of emphasis on Google’s user penetration with Google Maps, you can include that as a way to clarify what solutions are reasonable for Google to develop:

We’re going to use Google’s superior computation power to develop a new feature in Google Maps to make parking information more useful. Ultimately, this product will ensure that people have a better experience at their ultimate destination.

If you discussed Google’s compute advantage during your (optional) strategic discussion, this modification makes it clear that it’s important enough to be a condition of success. That makes your discussion of this strategic consideration relevant to your overall argument. Remember, if you bring something up you should find a way to incorporate it into your argument. If you don’t do it explicitly in your goal definition, be sure to find a way to include later in your discussion, such as the solutions prioritization section. If you don’t, then you’ll have to ask yourself why you discussed it at all.

Be sure to remember that including this additional criteria narrows the solution space. Be absolutely sure that you aren’t doing this accidentally. We’ll discuss that next.

Premature narrowing

Candidates often feel pressured to narrow their solution space during goal-setting. I strongly recommend against this because the purpose of the goal section is to define success, not to determine a solution. The body sections of your response (customers, pain points, solutions) are designed to identify the best solutions, each section focusing on narrowing down the best customers, pain points, and solutions. Premature narrowing can make it difficult to identify good alternatives for these sections.

Although it may feel uncomfortable, the ideal goal does not narrow the solution space. Instead, it keeps the solution space as broad and ambiguous as the original prompt. By avoiding premature narrowing, you allow yourself the latitude to develop solutions that credibly solve the problem and, with some creativity, stand out as original and innovative.

Here’s an example goal that unwittingly narrows the solution space:

My goal is to build a feature for Google Maps that organizes information so people can find parking fast so that they can get to their chosen activity without fear of being late.

First, let’s talk about the positives. The goal is worthwhile and addresses a concern that many people care about—getting to their destinations quickly. It clearly defines success and aligns with Google's mission.

However, the issue with this approach is that "the fear of being late" is a concern significant to only a subset of users. For instance, individuals with accessibility concerns may prioritize safe and accessible parking over speed. Since demonstrating empathy is a major objective of the design case interview, prematurely focusing on specific pain points can lead to the underrepresentation of critical user groups. Additionally, by narrowing the goal to making parking faster, you limit the potential for solutions that offer compelling value outside of speed.

Weaving the goal into your argument

Now that you’ve defined a goal, your next step is to craft the body sections of your argument. You’ll learn how to structure these sections in subsequent lessons, but for now, we’ll focus on the “section headers” that introduce each section. The section header is a useful device for two reasons: first, it provides wayfinding for your interviewer. By telling them what you’re going to discuss in the following section, you “prime the pump” and enable them to anticipate the content you’ll be presenting.

In addition, and more critically to this discussion, it provides an opportunity to explain how the discussion will help achieve the goal you defined. Doing this makes your entire discussion sound more goal-oriented and persuasive. By asserting that your discussion drives towards the goal, you help your interviewer come to the same conclusion.

Here’s an example section header for the customer section:

Alright, now that we’ve aligned on a goal, I want to begin discussing the people in this space. To make sure that we’re able to give people a better experience at their destination, we first need to understand the people who park, what matters to them, and what they’re all about. By understanding different groups of people and their diverse needs, we’ll be able to identify a group that will help us deliver a powerful product that resonates with them and eventually the broader audience.

As important as it is to have great content within the customer section itself, framing the discussion in terms of the goal makes it clear that you understand the underlying logic of the interview structure. This approach gives you the confidence to make strong choices throughout the interview.

Wrapping Up

Defining the goal with the three part structure we described is a great way to reliably define a goal that amplifies your argument throughout your response. Remember the basic pattern:

[prompt restatement][ success criteria][people impact].

Now that you’ve learned the technique, practice defining goals for as many product design questions you can think of. Ask yourself if your goal is worthwhile, binary, mission-oriented, and people-centric. If it is, you’ve set yourself up for a strong interview.

Want to do more to prepare for your interview? Book a professional coaching session now.

* I will of course have expanded upon all of these points!