5 Design Thinking Concepts for Product Managers

I first heard the term Design Thinking about 4 years ago when one of my seniors from IIT Delhi who pursued a Master’s in design from Stanford d.school helped us redesign the mobile app experience for Fitso. I really admired his data-backed approach and creative confidence in making us question a lot of our assumptions and constraints. 

In the last one year, I spent quite a bit of time learning Design Thinking concepts through courses and workshops at Kellogg School of Management and from online resources (Design Thinking by Darden Business School on Coursera and Stanford d.school) and books. I am writing this blog to have some handy toolkits with me when I start working as a full-time Product Manager. With these toolkits, I hope to avoid mistakes that I made in the past in understanding user needs, conducting brainstorming sessions and giving back. 

Here are 5 design thinking toolkits that I believe would be useful for product managers:

1. Empathize (User Research)

As a Product Manager in a team of engineers and designers, I believe the understanding of users is one of the core parts of what we bring to the table. There isn’t a dearth of concepts and recipes to conduct user research. 

Let me highlight some approaches and frameworks that I found useful. 

First, starting with the approach. Early in my career, I remember judging when users mentioned some weird opinions instead of trying to understand. That’s not a good approach. As per Stanford d.school’s approach to user research, the research should be done without judgment, with a beginner’s eye and with curiosity and respect. This is easier said than done.

Next, let’s discuss methods. Here is a list of methods that could be used for user research:

• User persona: It’s a fictional character created based on deep user research to represent a typical user of the product. It’s extremely helpful in keeping the team clear about who they are building for! (refer to this article)

• Customer journey mapping: Idea is to plot all the interaction points and events a typical user goes through in the process of achieving his goal. It consists of a timeline of the events, and emotions that a user goes through at each step. (refer to this article)

• Empathy Map: It has four quadrants (Says, Thinks, Does, and Feels); helpful in understanding user attitude and behavior. (refer this article)

• Extreme Users Analysis: Understanding extreme users who have amplified needs (similar to the concept of Inclusive Design)

• “Five Why” technique: It is simple yet powerful in unearthing the right problem.

• Projective Technique (user interview): Idea is to use open-ended ambiguous stimuli to uncover hidden or deeper thoughts. For example, ask users to note down experience with the brand (withdrawal technique). Or respondents are asked to close their eyes and guided through space to land on “Planet of Product X”. Then asked questions like, What does it look like? What are people like? (guide fantasy technique). 

One of my skepticism about design thinking approaches was the usage of a low sample size.  However, in user research, it’s sometimes okay to go ahead with smaller sample size. That’s because the idea is to get insights and understand deep thoughts. It’s an exploratory phase, and we are not trying to validate in this phase. 

2. Framing the problem

The second critical tool is framing the problem. Whether it’s a product launch, growth, or redesign, how we define the problem is crucial. Two frameworks that I have found useful include:

• “How Might We” statement (HMW): It’s a short question that should be broad enough that there is a wide range of solutions but narrow enough that the team has some helpful constraints. Generally, it’s a follow-up step after unearthing and zoning on a problem. An example of HMW statement for people in essential services looking to stay safe could be: how might we design a product (protocol) to keep individuals in essential services protected from COVID-19?. (Refer Stanford article). The solution here isn’t just restricted to Santisers and masks, but could go beyond – maybe some EM ray, which can destroy this virus, installed at hotspots.

• “Job to be done” framework: It is also a pretty popular framework and was taught in our Product Management course at Kellogg. It’s based on the idea that whenever users hire (or use) a product, they want to get a specific job done. User’s don’t care about features. Instead, they want an outcome.
  
  An example of a “job to be done” for someone who does the grocery shopping in a nearby store instead of traveling to a bigger and cheaper store could be: Get food to eat with minimum time and effort investment (Even a food subscription service could solve my problem). (Refer Mozilla Open Innovation Toolkit) 

3. Feedback Approach

Giving feedback is one of the critical parts of being a team contributor. Further, it’s not just how you provide feedback, but also how the team shares feedback during brainstorming sessions. There is a fine line between value-adding feedback and demoralizing feedback. In this context, I found the following frameworks helpful in sharing feedback:

• I like, I wish, What if?: Idea is to express a “Like”, a “Wish”, and a “What if”. I find this approach to be the simplest when reflecting on a piece of work or an idea. For example, I like how actively our government is dealing with the COVID pandemic. I wish we would have been better prepared and started early. What if we build the best team of doctors from all over the world to form “Global Pandemic Team (GBT)” and provide them with all the resources possible?

• Rose, Thorn, Bud: It’s similar to the previous framework, but the constructive feedback here is more direct in this approach. Idea is to convey what’s good about the idea (rose), what could be explored  – opportunity area (bud), and what’s not working (thorn).

• Product Feedback: In the feedback grid we share what worked, what needs to change, questions, and new ideas (refer to IBM article).

4. Compartmentalized Thinking

I couldn’t find a better word for what I observed a recurring theme in various courses and material on design thinking to deliberately keep certain approaches such as convergent and divergent thinking separate. 

• Distinct problem and solution space: It’s crucial to keep problem and solution space distinct. By coming up with “what to solve” and “how to solve”, we run the risk of anchoring questions to a solution.
  
  It’s important that the execution and solution isn’t part of the discussion during problem or user research brainstorming sessions. The HMW and Job-To-Be-Done frameworks help to alleviate this risk to an extent.
  
  For example, one of the arguments against user research is Henry Ford’s quote that If I had asked people what they wanted, they would have said faster horses. However, if we dig deep into user needs, we would see travelers need greater speed to save time in commute. Hence, if we keep problem and solution space distinct, the problem statement wouldn’t be anchored to the solution (faster horses). Instead, the problem statement, in this case, would be about greater speed or productive commute time. 

• Convergent and Divergent Thinking: Divergent thinking is coming up with a lot of ideas, while convergent thinking is the prioritization of the ideas. The Intuit Product Team at a workshop at Kellogg shared a similar concept “go broad to go narrow”.
  
  The idea is simple to get a lot of solutions before narrowing on one. If we start narrowing before going broad, we might have to settle for a mediocre solution, as people aren’t comfortable doing expansive thinking when ideas start getting filtered out. 

• Analysis and Synthesis Phase: Similarly, it’s important to separate the analysis and synthesis phase. The analysis stage is collecting data in all possible ways – survey and ethnographic studies. Synthesis is sitting with a team, making sense of the data, and building a story. 

5. Less but more (Minimalism)

Dieter Rams, a German Industrial Designer, popularized this concept of less but more. Across design thinking materials, it’s one of the recurring themes, and I believe this principle applies across our role as a product manager. 

I would just quote Steve Jobs here – “Simplicity is the ultimate sophistication that takes a lot of hard work to make something simple, to truly understand the underlying challenges and come up with elegant solutions“. Jony Ive, Apple’s chief designer describes Jobs’ mindset in the following way  – “The art of focus – even if it’s something that you think passionately about – focus means ignoring it and putting it to the side. And often it’s at a real cost. And he (Jobs) was remarkable at that.” That’s probably why Apple could take the risk of removing the headphone jack from the iPhone and launch Airpods. Or when this didn’t support Flash on the iPhone. We all would agree that Apple is one of the best consumer product companies in the history of mankind, and its design is testimony to the concept of minimalism (~less but more). 

Steve Jobs here, in a way, talks about the essence of product management. As a PM, we always have to manage trade-off, and it’s crucial to prioritize and be clear about key problems we are trying to solve and key themes in our solutions. If it’s a long list of things, then probably it’s not right.