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

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. And as a lead UX researcher for consumer, I manage a team of great researchers who work on research across all of our customer placing platforms and across the customer journey. So, everything from how people decide what to eat to, how they expect to receive the food, and everything in between.

So, if you've been to UXDX before likely if you're attending this conference now, you know already 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 there 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. So, we've been historically more of a technical company and have recently started adding a lot of UX talent and investing a lot in those capabilities. So, 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. So, of course, we've had our share of successes and failures. As the scale, deputies are research and work to move towards some more discovery focus approach.

So, 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.

So, dive into our first learning, which is that user research is more than just talking to your customers. And this sounds a bit obvious, but I'll share this with the story. So, when I first joined the company, I started getting to know our product team members, as you do across product management, UX design development, et cetera. And they're really awesome and motivated group of people who told me about how they knew how important research was that it was a key part of their existing product development process. And they told me all about how they knew the importance of talking to your customers and that they were continually testing their ideas already so that's all really amazing to hear as a researcher that's new to the company.
In reality, however, when I dug a little bit deeper, what we were doing was what I call a bit of a validation exercise. So, where we 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 an 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 experiment to see if that idea makes sense. 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 it is because you're doing this validation continually at a regular cadence, but you're missing out on a huge part of learning about your customer's needs and how you can build your product to solve those.

So, that brings me to my second learning, which is that research needs to happen at all stages of product development because there's different types of research value. And the kind of research you do at each of these stages should be different because you are looking for different outcomes. So, just doing user interviews or usability testing every time won't get you all of the benefits of user research.

I like to think of it in these three stages. So, the first is solving the right problem, identifying the problems that our users have, what are their needs, their motivations. Once you have that, you can move into getting the right idea. So, defining your product, doing ideation based on the insights you've learned about these user problems. And then finally getting the idea right. So, iterating, optimizing and building solutions. Many companies are good at this last part. And certainly, a take away, this is predominant research being done when I joined. So, optimising iterating, getting feedback, collecting data on potential solutions or features. And of course, the stage of validating 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. So, 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 this feature or how we could improve it. And research in this first phase of identifying the problem should use different methods then for the other two phases. So, 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. 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 aren’t a one size fits all research methods. So, make sure to choose the best approach for the phase of development that you're in by just interviewing your customers and trying to do the same approach for, for there. 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.
So, illustrate a specific situation we had. So, we knew we had a lot of complaints about our delivery time that we were showing on 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 show people track the driver or trying to make a new very expensive data algorithm to improve accuracy. And eventually they came to research and asked us to help them figure out a possible solution. However, what we figured out was that we 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 the customers felt delivery time wasn't accurate and this is definitely true. However, it just wasn't the whole picture. So, 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 realise that it's about trust and the delivery time. 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 that such as adding a delivery time range, we could solve this problem much more easily for customers.

So, now the research team had grown and product teams were excited about doing research failure, doing research, to understand customer problems instead of just validating ideas. And now there's this 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 personalisation that 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 are asking researchers or even wanted customers to tell them what to build. Since we now knew that we really had to spend more time understanding the user problem without going with assumptions or limited data. We settled on investing time on a bunch of research upfront to really dive into this topic of personalisation. There 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. Personalisation can mean providing better recommendations or understanding data privacy concerns, tailoring to dietary preferences; the list goes on. Since the possible outcomes where seemingly endless research was asked to talk to customers, understand what 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.

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 are waiting for research to tell them what direction to go in. And this was especially true when the teams are really busy, they had a ton of delivery work to get through in the quarter. And discovery still kind of seem like a nice to have.

Just kind of three main challenges with this approach thought of having research figure out a direction separate from the team. The first is that research is working in a silo away from the research 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 product outcome research can certainly help identify potential value propositions, but we still need a product goal to work towards from this. And lastly, you're relying on research or your customers to really tell you what to do. And 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 our teams from insights and evidence that they're going to have to take action on later.

So, 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, help us ensure that we get the most out of research and do effective discovery.

This first principle, isn't about research at all, but it's about product development in general, which is to always start with the clear product outcome. Either 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, what is the goal we you're aiming for.

Second, what is a 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, identifying any hypotheses or assumptions that you might have. And 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.

Our second principle is that different types of user research need to happen at all stages of product development. So, doing the right research at the right time. I've shared this framework earlier, but this really helps us assess which we search method is most appropriate for what stage of product development we're in so that we can get the most out of doing research. 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. So, think about what do you want to know? What do you think you know, and what you actually already know, and then see where there any overlaps or any 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 that they help you challenge your assumptions in a really simple way. And you can do this collaborative collaboratively with your team. I think it's easy to get caught up in these tiny product changes that you want to fix, but it takes a step back. What is the overall and holistic goal that your users have and is your product solving that goal or challenge that they have?

And our last principle that I'll share with you today is make your research and data work together. I think often user research and data are seen as completely different disciplines and 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 and work in tandem to get to deeper insights about a challenge or a new product direction. At the beginning of projects and we start to discuss our assumptions and hypothesis, we bring in our data experts who may be able to provide deeper insights or contexts about behaviors that they see in the data. So, identifying what is happening. This helps us pinpoint where the biggest unknowns are so that we can dig into with research to get into 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 that our data team can use those pain points to go deeper and see how that matches 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.

So, to summarise, we have 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 research, doesn't tell you what to do. It produces evidence for you to make better decisions. And the three principles that come out of those learnings are to always start with a clear product outcome, to do the right research at the right time, and to make your data and research work together.

In conclusion, I hope these learnings and experiences from our journey at takeaway to doing 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 by sharing our stumbles and successes help inspire you all to make the most of doing user research to build better and more inspiring products.

Thank you.