Product Thinking for Designers

Product teams in tech are looking for designers that can add value beyond strong visual or interaction design. But how? By leveraging product thinking.

As a UX/product designer, your designs directly affect the overall product direction. Your voice is key in making important product decisions and tradeoffs, so being a strong product thinker can set you far apart in an interview. In this lesson, we'll share how to demonstrate this effectively.

Product Thinking vs. Design Thinking

According to the Interaction Design Foundation:

Product thinking is a set of cognitive processes and possibly design methods that a designer has when addressing and solving a problem.

Sound familiar? At first glance, it sounds like design thinking.

You may get different answers on what the difference is depending on who you talk to. Regardless of the detail, articulating how you design for users vs. how you solve business problems is important -- both during your interview and during your design career. Interviewers (and eventually, your colleagues on the product team) are interested in both. Here's a simple framework for identifying the difference:

• Design thinking drives how you arrive at design solutions
• Product thinking drives why your solution makes the most sense for users and your company.

To illustrate, let’s say you’re asked to talk about a project where you needed to design a payment form. Some points you may address about the same project that signals one vs. the other could be:

• Design thinking: “As I was iterating on different form designs, I also did a competitive analysis to understand best practices around form patterns to apply that to this solution”
• Product thinking: “Since scope was limited, I decided to focus on solutions that accepted only credit cards because after talking to the team, we agreed that this would still cover a majority of use cases. However, I still explored designs that could accept additional payment options as a fast follow to this MVP release.”

We’re talking about the same solution, but in our first answer, we focus on user-centricity, whereas in the second section we focus on why our solution made sense from a business perspective.

How to Show Product Thinking in Interviews

The key to better product thinking in interviews and on-the-job is the same: practice.

There are two things you should do to prepare for your interview:

1. Reflect on your decision-making process in projects you’ll be talking about
2. Study product frameworks

We'll help you do both using common interview scenarios. Let's dive in.

Reflecting on Past Projects

You may have never heard the term "product thinking" before, but chances are you've used it already. Prepare for product thinking questions by going through your past projects and considering the following:

Why did you work on this project?

At the heart of every project, there was a user problem you aimed to solve. Anchoring on users shows that you were motivated by the problem space; that you don't allow (what might be very cool) potential solutions to derail you. Think through the details and expand on circumstances involving the product:

• Was this a problem that was identified as a high priority because of user or business impact? Both?
• Why did the team decide to work on this vs. something else?
• Did you discover an opportunity that strengthens product-market fit?

What assumptions did you have and/or test?

Another way to frame this question is "what were the key hypotheses driving this project?” Checking assumptions and being hypothesis-driven is important when designing to hit specific user and business goals, but it's often not articulated. Be sure you can identify hypotheses, articulate them logically, and connect your design iterations to learnings you gain as you test.

For example, we might extrapolate the following hypotheses driving payment form design:

• If we follow form pattern best practices, then users will have an easier time going through our payment flow.
• If we prioritize accepting credit card payments, then we will reach our payment conversion success metrics.

In the best-case scenarios, you’ve had opportunities to validate these assumptions through testing or research -- be sure to practice talking through these examples, from problem statement through actions taken down to your impact and results. Interviewers love to hear how you test and conduct research, especially if you had to get creative.

What kind of tradeoffs did you have to make in your design?

The strongest designs come out of a thorough understanding of priorities & tradeoffs. Don't forget to present how the tradeoffs you made benefitted the product, which can be done by focusing on scope.

Scope refers to the combination of time, effort, and resources available for a given project. In a business context, resources (including time and effort) are finite. Investing in one aspect may mean decreasing the availability of others. Otherwise, you're likely to go off-schedule, or over-budget. Properly scoping projects is an art, and may take a lot of upfront time and research, but the work pays off.

You're not interviewing for a PM role, so don't worry about theory or tools - but you should be able to articulate:

1. Why certain decisions were made in terms of scope: what resource pool made sense given the urgency, importance, and potential business impact of the project?
2. How your understanding of the entire project space and scope enabled you to make good design decisions that aligned with customer, business, and project goals.

Here are some examples of different ways you might talk about scope:

• Time: “Because we were only given two sprints to release this, we had to prioritize the main inputs needed to quickly go through the payment form.”
• Effort: “After walking through the initial designs with the rest of the team, we realized the solution would require a major refactor, blowing up scope. I reiterated the designs through close collaboration engineering t make sure our improved solution did what we needed it to do without refactoring. n”
• Resources: “We decided not to go with this design direction because it was contingent on a third-party vendor capability that was too costly to implement at the time”

Scope isn’t the only way to talk about making tradeoffs, but is a good starting point. We recommend practicing incorporating scope into your interview prep. From there, adapt your tradeoff discussion as needed once it's natural for you.

How does this solution answer the user’s need? How does this solution answer the business’s need?

Arguably the most important consideration to articulate in every interview response.

We want to say that in answering the user’s needs, we were able to serve our company's needs. Successful projects align and solve for both. For example, “not only did we receive positive feedback from users, but improving our payment form helped increase payment completion rates & thus increased revenue by 5%.”

A key mistake we see product designers make is going into interviews without concrete results data -- don't make this rookie mistake! Go the extra mile -- quantitative data closes the loop on how your projects were successful, and position you as a designer with a mind for business. This is what tech interviewers are looking for.

Product Frameworks

Another way to hone product thinking for interviews is to step into your product manager's shoes. A quick way to do that is to learn a few frameworks used in product thinking. Check out Exponent's product design for PMs module for a refresher on how PMs think about product design -- it's a good complement to your process. For a shorter read, we recommend Naren Katakam’s Product 101 article. Here are a few to get you started:

• Strengths, Weaknesses, Opportunities, Threats (SWOT) Analysis: A SWOT analysis is a framework used to assess the company’s strengths and weaknesses in relation to the overall market opportunities and threats. This is usually done to identify how to build a product that provides more value than other competitors in the market. Read more and view an example here.
• Jobs-to-be-done: Similar to defining user needs, jobs-to-be-done is a simple, tactical framework to define what types of ‘jobs’ a user needs to get done, and how your product can help complete that job, or simply, “What job(s) arise(s) in people’s lives that your product could solve?” Read more here.
• 5 Why’s: Just as it sounds, this framework is used to identify root cause-and-effect for certain outcomes. Start with some outcome, ask why that happened, and once that answer is defined ask “why” again. Read more and experiment with a downloadable template here.

Tips

• Embed product thinking in your process. A lot of what was talked about here has parallels to design thinking. They each have different focuses, but if you are able to talk about your process in a way that enables product thinking, then this should come more naturally to you. How in your process do you make sure your solutions consider the overall product, not just a specific feature’s success?
• Talk to product managers. The people that are literally paid to employ product thinking in their day-to-day jobs are a great resource to learn how you can be a stronger product thinker. Working as a product designer means you’ll be collaborating with a product manager pretty often. Learning about what a product manager does will not only help you better understand product thinking, but will make you a better product designer.
• Don’t say ‘I don’t know’. This isn’t to say that you should have an answer for everything (this is arguably worse), but there should always be some context or reasoning as to why a decision was made. And if there isn’t? Think again, there’s usually some reason (it just may not be a good reason).