From Delivery To Discovery: User Research As The Foundation For Successful Product Teams

at UXDX EMEA. Video: https://www.youtube.com/watch?v=tLQjCBzT1bw

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From a delivery mindset to discovery

[00:00:00] Hi everyone. I'm Vanessa Ko, I'm the lead UX researcher for consumer experience at Just Eat Takeaway. We are a food delivery company that operates in over 20 countries around the world. As a lead UX researcher for consumer, I manage a team of great researchers who work on research across all of our customer-facing platforms and across the customer journey: everything from how people decide what to eat, to how they expect to receive the food, and everything in between.

[00:00:28] If you've been to UXDX before, or likely if you're attending this conference now, you already know that product discovery is the process of deciding what to build, and that you should be talking to your customers on a regular basis to make sure you're building the right thing. But in practice, the first steps of getting to this discovery mindset and way of working are the most difficult. So today I want to share the journey that we've been on at Just Eat Takeaway, as we've been transitioning from more of a delivery mindset to one that embraces product discovery.

[00:01:01] We've historically been more of a technical company, and have recently started adding a lot of UX talent and investing a lot in those capabilities. UX research in particular is a new discipline and capability that we've added, and in the span of one year we've gone from one researcher to almost 15, working across most of our product teams. So it's been a really exciting time of growth for research at the company. Of course, we've had our share of successes and failures as we scaled up research and worked to move towards a more discovery-focused approach.

[00:01:31] Today I'll share a few of our learnings and a couple of stories from our journey, with a special focus on how you use research as the foundation for this transformation. In particular, how to get the most out of doing research for product discovery, why it's more than just talking to your customers, and most importantly, what has worked and what we've learned.

Research is more than talking to customers

[00:01:31] Let's dive into our first learning, which is that user research is more than just talking to your customers. This sounds a bit obvious, but I'll share it with a story. When I first joined the company, I started getting to know our product team members, as you do, across product management, UX, design, development and so on. They're a really awesome and motivated group of people, who told me that they knew how important research was, that it was a key part of their existing product development process. They told me all about how they knew the importance of talking to your customers, and that they were continually testing their ideas already. That's all really amazing to hear as a researcher that's new to the company.

[00:02:35] In reality, however, when I dug a little bit deeper, what we were doing was what I call a bit of a validation exercise. That's where you do research to validate your ideas or to check assumptions once an idea is already half or fully formed. You have some prototypes or designs, maybe, and definitely some idea of a solution. I think it's easy to fall into this validation mindset, where you have an idea and then want to do research or an experiment to see if that idea makes sense.

[00:03:13] The challenge with doing this is that you aren't actually getting the full benefit of doing research and understanding your customers. You might think you are, because you're doing this validation continually at a regular cadence, but you're missing out on a huge part of learning about your customers' needs and how you can build your product to solve those.

Research at every stage of product development

[00:03:13] That brings me to my second learning, which is that research needs to happen at all stages of product development, because there are different types of research value. The kind of research you do at each of these stages should be different, because you are looking for different outcomes. Just doing user interviews or usability testing every time won't get you all of the benefits of user research.

[00:03:43] I like to think of it in these three stages. The first is solving the right problem: identifying the problems that our users have, what their needs and their motivations are. Once you have that, you can move into getting the right idea: defining your product, doing ideation based on the insights you've learned about these user problems. And then finally, getting the idea right: iterating, optimizing and building solutions.

[00:04:12] Many companies are good at this last part, and certainly at Takeaway this was the predominant research being done when I joined: optimizing, iterating, getting feedback, collecting data on potential solutions or features. And of course, the stage of validating the ideas or designs that a team has is really important. However, what we learned from our experience of primarily doing this last type of research is that we were missing significant knowledge on the first few stages. Even though we were using market insights and data, so we weren't running on assumptions for these two stages, it was really easy to get caught up in specific features or details when building products, because the research we were doing was specifically about how users were using a feature or how we could improve it.

[00:04:45] Research in this first phase of identifying the problem should use different methods than in the other two phases. Doing things like deeper ethnographies or in-depth interviews will likely get you richer stories and an understanding of user needs and problems. In contrast, when you're in that last phase of optimizing and getting the idea right, it can be a lot more effective to use methods like usability testing to identify specific blind spots you might have missed in your design. There isn't a one-size-fits-all research method. So make sure to choose the best approach for the phase of development that you're in. By just interviewing your customers and trying the same approach for any of your problems, you could be missing out on the full benefit of all the insights you could be getting to make your product better for your customers.

The delivery time story

[00:05:48] To illustrate, here's a specific situation we had. We knew we had a lot of complaints about the delivery time that we were showing in our app. Customers felt that the time wasn't accurate. They were really unhappy about it, it was generating a lot of customer service tickets, and the team had spent a lot of time trying to figure out how to solve this issue and reduce the number of complaints. There were lots of ideas floating around, including maybe adding a label to let people track the driver, or trying to make a new, very expensive data algorithm to improve accuracy. Eventually they came to research and asked us to help them figure out a possible solution.

[00:06:23] However, what we figured out was that we had missed a big step at the beginning, which is really understanding and going deep into what the customer problem is at the start. We had assumed that the problem was about accuracy, that customers felt the delivery time wasn't accurate, and this is definitely true. However, it just wasn't the whole picture. When a researcher on my team started talking to customers, not just about this feature but about their experiences and challenges with food delivery more holistically, they realized that it's about trust in the delivery time.

[00:06:54] Most customers understood that the delivery time would never be 100% accurate, because there are so many factors that contribute to that time. However, the information that we were showing them just wasn't sufficient for them to feel confident in the time estimate. And by adding just a bit more context to it, such as a delivery time range, we could solve this problem much more easily for customers.

Swinging to the other extreme

[00:07:26] Now the research team had grown, and product teams were excited about doing research to understand customer problems instead of just validating ideas. There was a huge appetite within the company to do research and go deeper on user problems, especially on some big, fuzzy topics that we wanted to work on, such as personalization, which cut across product teams and was a new topic for us. We hadn't dived into it. But the next challenge we had was that teams had now swung to the other extreme, where teams were asking researchers, or even wanted customers, to tell them what to build.

[00:08:00] Since we now knew that we really had to spend more time understanding the user problem, without going on assumptions or limited data, we settled on investing time in a bunch of research upfront to really dive into this topic of personalization. There are, of course, many ways you could see that topic, and lots of different directions, many of which could be applicable to a product and company. Personalization can mean providing better recommendations, or understanding data privacy concerns, or tailoring to dietary preferences; the list goes on. Since the possible outcomes were seemingly endless, research was asked to talk to customers and understand which option we could pursue, and that would determine what the next steps could be for the product. So they asked us to go off and do the research and come back with an answer.

[00:09:11] This is another easy temptation for product teams. Since research is responsible for talking to customers, understanding their needs and translating that into product opportunities, teams wait for research to tell them what direction to go in. And this was especially true when the teams were really busy. They had a ton of delivery work to get through in the quarter, and discovery still seemed like a nice-to-have.

[00:09:11] There are three main challenges with this approach of having research figure out a direction separately from the team. The first is that research is working in a silo, away from the rest of the product team. You're disconnecting your team members from the insights that they're going to have to use. You're also relying on research, or your customers, to determine the product outcome. Research can certainly help identify potential value propositions, but we still need a product goal to work towards. And lastly, you're relying on research, or your customers, to tell you what to do. It's clear what the dangers are of going in this direction. You aren't working towards a bigger vision and product goals, and you're disconnecting your teams from insights and evidence that they're going to have to take action on later.

Start with a clear product outcome

[00:10:12] Now I want to move into some of the principles we have set up to ensure that we're doing successful research and discovery. Of course, this is still a work in progress for us, but keeping some of these principles in mind helps us ensure that we get the most out of research and do effective discovery.

[00:10:39] This first principle isn't about research at all, but about product development in general, which is to always start with a clear product outcome. Research is about creating a body of evidence that helps you make better decisions. It doesn't mean you can skip having a clear vision or product outcome from the start. So, first, what is the goal you're aiming for? Second, what is the business goal that we're looking at? For example, increasing the number of new customers is very different from trying to increase retention in some situations. Being really crystal clear about where we're heading helps refine the research that we can do. And lastly, identify any hypotheses or assumptions that you might have.

[00:11:13] Thinking about these three things is really the first step. Before you even think about doing research or talking to customers, you still need to use your entire product team's expertise, in product management, design, data, research, all of the disciplines you have, to define not only what potential solutions could be, based on the knowledge of user needs that you have, but also to shape a clear direction and vision. Because without that, you can easily lose focus and miss out on all the benefits of doing research in the first place.

The right research at the right time

[00:11:45] Our second principle is that different types of user research need to happen at all stages of product development: doing the right research at the right time. I shared this framework earlier, but it really helps us assess which research method is most appropriate for the stage of product development we're in, so that we can get the most out of doing research.

[00:12:20] And along the way, it's important to continue to challenge our assumptions at all stages. This is an exercise you can do along the way to test your assumptions. Think about what you want to know, what you think you know, and what you actually already know, and then see where there are any overlaps or gaps. You might find that you actually already know a lot, or that you were operating on assumptions more than anything. These are really simple questions, but they help you challenge your assumptions in a really simple way, and you can do this collaboratively with your team. I think it's easy to get caught up in the tiny product changes that you want to fix, but take a step back. What is the overall, holistic goal that your users have, and is your product solving that goal or challenge?

Make research and data work together

[00:12:51] The last principle that I'll share with you today is: make your research and data work together. I think user research and data are often seen as completely different disciplines, and they don't often work together. But research and data are really two sides of the same coin. They're both sources of knowledge and insights, just conducted and packaged in a different way to achieve different outcomes. At Takeaway, research and data often work in tandem to get to deeper insights about a challenge or a new product direction.

[00:13:22] At the beginning of projects, when we start to discuss our assumptions and hypotheses, we bring in our data experts, who may be able to provide deeper insights or context about behaviors that they see in the data: identifying what is happening. This helps us pinpoint where the biggest unknowns are, so that we can dig into them with research to get at the why. On the flip side, you can also use user research to drive further discovery with data. We sometimes do research with customers to diagnose pain points and user needs, and then our data team can use those pain points to go deeper and see how they match with behavioral data. By triangulating different sources throughout the project, we can work more efficiently and effectively, and get the most out of research and data to drive better discovery for better outcomes.

Summary

[00:14:32] To summarize, there are three learnings that I've shared with you today. The first is that user research is more than just talking to people. Second, research really needs to happen at all stages of product development. And third, research doesn't tell you what to do; it produces evidence for you to make better decisions. The three principles that come out of those learnings are: always start with a clear product outcome, do the right research at the right time, and make your data and research work together.

[00:15:05] In conclusion, I hope these learnings and experiences from our journey at Takeaway towards better product discovery help you in your journeys as well, to get to more discovery-oriented approaches. We still have a lot to learn, but we hope that sharing our stumbles and successes helps inspire you all to make the most of doing user research to build better and more inspiring products. Thank you.