User research can be fast & easy - with Nikki Anderson @Zalando

Welcome everyone to the Product Bakery. Today we have Nikki Anderson here with us and obviously my dear friend and co-host Christian. Hey Nikki, good to see you, good to hear you. Hey, good to see and hear you both. So Nikki, to share a little bit background, you are a studied psychologist who worked many years in New York as a user researcher for different companies. And almost two years ago you decided to move to Berlin to work for the company Zalando as a user research lead. Next to that, you are also the founder and instructor of the User Research Academy. Since Alex and I are advocators of user research and we love testing, we were curious what's behind the User Research Academy. Yeah, sure. Thank you for the intro. I appreciate that. Yeah, the User Research Academy, I founded that actually back in 2018. And the reason that I started this User Research Academy was because I felt like a lot of people struggled to get into the field of user research. And in addition to that, a lot of people struggle with understanding how to start as a user researcher. So just because it's called the User Research Academy doesn't mean that it's all full of user researchers. I also have a lot of product managers, designers, developers, site researchers, and then people completely outside of the tech fields who take my classes just to understand how to do user research. So that's why I founded it, was to make that field more accessible for people who aren't directly related to it. And I applied to over 70 jobs to get my first user research internship. So I know the pain. I know the pain. So you have a platform where you provide online classes, is that correct? Yep. So it's online classes, it's as well as one-on-one mentorship. And I also do webinars and workshops and job interview prep that has become really popular recently with people looking for new jobs. So a bunch of different services that I try to give to people. Very cool. Actually, also interesting to me and Alex, because we had last week brunch and we were discussing what makes the croissant so perfect. What is the perfect croissant and how does it taste? And we asked ourselves, is this something we could research? Actually, we ended up in recording a podcast episode, the previous one. Nevertheless, we thought it would be maybe better to talk to a real expert. Maybe you can tell us how you would kick off such a project. Oh dear. That's interesting. Sure. I mean, I'm vegan, so I'm sadly not an avid croissant eater, but I used to be. I used to be an avid croissant eater. I used to eat them with Nutella all the time, like straight from the jar onto the croissant. So anyways, yeah. I don't know. For me, actually, croissant research might be more similar to A-B testing than to actual qualitative user research. So I guess maybe what I would do is I would start to ask people, what makes a good croissant? What is it that you think about when you think of a good croissant? How would you describe this? And you might hear things like the flakiness or the butteriness or the crispness and all of those things. And then I think what I would do is I would go and work with my chef and A-B test a bunch of these different ingredients to see until we got the right one. You could be a baker, not a chef. Ah, baker. Shoot. Sorry that I'm so picky on that. Speaking to a professional here, right? That's a really great point. I'm sorry to all the chefs out there who are listening. Master baker and do some A-B tests and some prototype testing, I guess, of these croissants to see if we were making it. But yeah, I would start with some qual research actually, asking people, how would you describe the perfect croissant? Is this something you would do on a qualitative level or quantitative level? So rather talking to people instead of sending out surveys? Yeah, of course you can always send out a survey to ask for data. But there are a few things that happen with surveys is that when you ask open-ended questions to get qualitative research insights, people don't like to fill them out. I feel like the only people that really like to fill these things out are user researchers, because we know the pain that other user researchers are going through to try and get this information. So I would just go and talk to people and what you could do in this scenario, which would be really fun, and I've totally done this before in New York, not in Germany yet, but you could go to a restaurant that sells these croissants and you could do gorilla research where you go and you see people who are eating croissants and you interrupt their lovely time to ask them, hey, what's up with this croissant? What do you think? What do you think about this croissant? How would you describe it? How have you seen it done better? That's what I would do. And the reason I would do that instead of a survey is because you get rich data. So you get rich qualitative data from actually having conversations with people. And I think that is super important if you're looking for insights, because analytics and surveys, they can tell us what is happening. So data analytics can tell us what is happening, but it's hard to get the why from that. So that's where qualitative research really comes in and complements this data. Yeah. Your expertise or your main focus area is around qualitative research, right? Yes, it is. I have a background in statistics, which is funny because I ran away from that so fast as soon as I was done with my master's in psychology. Everything that I learned dripped out and was replaced with qualitative research. So I do know some survey basics and some basic quantitative research. However, I definitely am an expert in the qualitative field and I would default to an expert in the quantitative field if I needed help. Cool. So you also mentioned earlier that when working in the research academy or with the research academy, you don't always speak to researchers, but you also talk to product people, tech people and everyone else who might have done research. So what is, from your expert perspective, what is important for non-experts to really get their hands on research and what do they have to pay attention to? So there are a few biases or assumptions that people have towards user research that are outside of user researchers and designers. And that's that research is expensive and it takes a really long time. I think that's true. Yes, everybody has heard it. It's been shouted from the mountaintops everywhere. But, you know, and it can, it can be expensive and it can take a whole lot of time, but it also, you can lean research out. That's kind of, to start with, something that I find really important to tell people who aren't necessarily in the user research field or directly related to the user research field. I feel like designers and researchers both have this understanding of, okay, research can take long and can be expensive, but it also doesn't have to be. So that's the first thing that I like to tell product managers is like, or other people outside of the user research field is that you can't do this. You just, you really need to practice and you really need to understand the skillset as something separate from what you normally do, but it's doable. It's very doable. And there, there are a few different ways that you can dive into user research and start getting acquainted and start trying it out. For instance, my fiance is a product manager. And when I met him, he didn't do user research. He didn't think much of it, to be honest. And I have converted him, but I converted him and I helped him with understanding like, Hey, not only is user research important, but you can do this yourself. And that's what I like to try and empower people to do both at user research Academy and pretty much every single one of the roles that I've been with in the past with, when I was an in-house researcher, I have set up education programs and training programs for other people in the company to democratize user research. And how would you run those? Like, or what are like the key things? Because one thing that I've seen is that then people start doing research. And the worst thing is if they think now that they're doing research, they can take certain decisions because they have done research. But in the end, I've seen so many interviews conducted by someone where they were just leading it way too much. And they were like, Oh yeah. So do you want this feature? Sure. Yeah. You want it. It's this feature. Isn't it cool? Yeah. Yeah. So there are some best practices, of course, that come alongside user research. And the first one is what you were talking about, Alex, with. Hey, we did the research. Let's make these big decisions. So the first one is in qualitative research. We all know that we have low sample sizes. We don't have those crazy, awesome sample sizes. We surveyed 1,500 people. We just don't have that because if I was supposed to talk to 1,500 people for one project and still be talking to my first, my first, at my first role, so I wouldn't be here right now, what I like to say is, and this is very common in the field. As you hear these, we need to talk to five to seven users for usability testing. Right. And then we need to talk to 10 to 12 users for more exploratory or discovery research. So there's some fine print that people don't like to talk about because it complicates things. But what we need to point out is when I say talk to five to seven users, it's five to seven users per segment. And that is, yeah. So it's really sad to learn this because everybody's like, I can't just talk to five random people and be done with it. That's, that's not, that's, that's what I want to do. But five to seven people per segment. So what I mean is we, there are multiple ways that you can segment your customer base. If you have personas already at your organization, if you've created personas, those are a form of segmentation. So when you go to usability test something, you need to talk to five to seven per people within each persona. That the, let's say the feature would be relevant for. So say you have three personas and the feature is only really relevant for two. You would talk to a total of 10 to 14 people because that's five to seven per persona. If you don't have personas, you can segment in so many different ways. But the one that I tell researchers to do is look at different segments where you're, where the organization is making the most money. Let's say like our customer base is throughout Europe, but we see that we're making a lot of revenue in Germany. So let's focus on the German customers first, or we can also think about, okay, are we roll, where are we rolling this feature out? Let's talk to those people first. So maybe we're rolling the feature out to France first. Let's talk to people in France. In addition to that, you can also look at active users. So number of active users, and you can maybe talk to that population first, wherever that population lies. You can also segment age as well. So let's say that the feature is more relevant for younger people rather than older people. So then you have to talk to different segmentations of age. There's so many ways that you can segment and really it's, it's up to, it's up to your organization and what your organization's goals are and, and what metrics they follow, where you should focus your energy. But I always think I'm always like revenue. That is, it's so sad, but even with user research and I've learned this is I work a lot with product managers and product managers care a lot about business. Like you're trying to put together like the business, the technology, and also the user. And if I can help you as a product manager with bringing the user and like that business together, then I've done my job. So, yeah, I always talk about segmenting, thinking about revenue or active customers or active orders or whatever metric you're following. I like that, but I have to have to be honest, talking to six to 12 customers was always clear to me and I was regularly doing this, but segmenting them, honestly, I never went that far, which makes absolutely sense. And I hope that many product people who are listening in right now will say, Oh, Christian, thanks God. I'm not as bad as you are. It can never hurt to repeat, to repeat this. Yeah. Or to, to mention this. Out of curiosity, right? Because when we talk about segments, you work for Zalando only if we can talk about it, but if you have to test something at Zalando, I would imagine like you have this huge amount of very different segments, how many interviews would you run to validate something then? Like how, how are you approaching it? Or is it like, do you only go about validating with the most relevant segments? Yeah, that's a great question. So we generally will validate with the most relevant segments and we will start always in Germany. Generally, like we are always starting with Germany because that is our main and target market. And it's also the market that we know the best because the most research has been done on that. But we also are talking to people in Italy and France as well. In Amsterdam, we base it off of a few different things, such as what I always talk about, where is this feature going to be rolled out and are we rolling at it out slowly to different areas? Let's say we roll it out first to Germany. Let's start there. And then if we're going to roll it out to France, then let's go there next. But primarily we're looking at a German market and only will speak to, let's say UK, if it's for some reason, very English specific or UK specific, but. Yeah, I can't come up with any concrete examples off the top of my mind, but yeah, we are generally looking at like the German population and then we will look into things like age range, if there's something more relevant for certain ages and then finally gender, because in fashion you get a lot of discrepancies with gender. So that's also an important segmentation for us to keep in mind while we're recruiting. Let's imagine we do have a segmentation as a company and we do have a couple of personas in place. Sure. Now to me as a product manager, or maybe looking at your fiance, how would you recommend to kicking off this whole user research topic in general on a project level, let's say we want to launch a new croissant, a new feature in WhatsApp or Facebook, no matter what it is, how would you kick it off? And when is the right time? Maybe we can deep dive into this a little bit. Yeah, let me tackle a few different things first. We will tackle the difference between generative research and evaluative research, we're going to start there because then that kind of dictates the rest of the conversation. So yeah, there are two buckets of user research. The first one is generative research and that is the problem space, understanding the problem space. So you are saying something like, Hey, I want to better understand what the greatest croissant is so that I can create a croissant that is aligned with people's experiences, or I want to better understand people's mental models about croissants. So how they think about croissants so that I can create the best croissant in the world. Oh, yeah. So yeah. The underlying problem, why do people even eat croissants? Yes, why croissants? Why not a bagel? Why not a muffin? There's so much to choose from. So that's generative research. It's really exploring that problem space. You don't want to necessarily tie it to like a product, like a digital product. So a lot of times when we go into user research or when I see other people going into user research, they already have a solution in mind. Or they are already like, okay, I'm very focused on my product, whatever that is, either a croissant or WhatsApp or Facebook or any of those things. So what we want to actually do is decouple the product of the research. You're going in to understand people. And this is where user research becomes much more of a social science and much more like anthropology than it does tech. Because in this kind of area, you are just trying to understand people. You're just like, Hey, what's up? What's on your mind? What are you thinking about this and that and the other thing? That is that kind of form of research, which is more of the problem space and exploring that. And what's cool about that is it generates a lot of new ideas. Then you have the other side, which is evaluative user research. And what evaluative user research is, it's quite self-explanatory. It's evaluating solutions. So after the generative research, what happens is you come up with some insights and you build some prototypes, and then we have evaluative research, which is maybe doing research on those prototypes, or you can do research on a live product. So those are like the two different buckets, the generative and the evaluative research. So problem space versus solution space. So now that we understood those two buckets, which are very important to understand, I think, especially in companies, when things have to happen in the past, people do not take the time, at least in smaller companies, to make the distinction. So there are people who are trying to push the founders, the managers, et cetera, to get things quickly out of the door without really looking at it holistically. So I think it's very valuable that we make a step back and talk about the basics first. Yeah. And the thing is, when you have a research idea, so you're that product manager that has some personas, and you're thinking about all these different croissants, you have to kind of, before you just dive into this, you have to decide which bucket are you in? Are you trying to understand the problem space, or are you trying to evaluate? So are you trying to say, why do people eat croissants? What are they? think about them? And why do they choose these over other things? Or are you saying we have five croissants and we want people to test them and give us feedback on them? I don't know. This example is just really sticking for some reason. It's okay. It matches our podcast logo. Yeah, perfect. And this can obviously be used as well for digital products. Understanding that problem or understanding if you want to evaluate a solution. The reason that this is so important is that when you are going to begin a research project, what you want to do is you want to come up with goals. So research goals. And these goals are what you want to figure out during the research project. What questions are you trying to answer by the end of this project? What are you trying to achieve by the end of this project? And what that will help you with if you form these goals in a very nice way. And what I will do is I will link to you or send to you a template for a research plan that you can put in the show notes that have an explanation of all these things. Yeah, it has really great examples and explanations because it's very hard to explain these super in depth. But these research goals, if you create them correctly, what they do is they enable you to ask the right questions. So then instead of asking, how awesome is this? Don't you want this awesome croissant? How great is this croissant? Eat the croissant and love the croissant and then buy croissants. Instead of saying those things, you are forming questions that are more open ended. Because if you're trying, if one of your goals is to just understand why people eat croissants, you're not going to ask them, how amazing is this croissant? You are going to say something like, why do you eat croissants? If you form those goals correctly, they really help you ask more open ended questions. So the best thing that you can do when you're kicking off a research project is to understand, hey, am I trying to understand a problem space or am I trying to evaluate something that's already a solution? And then come up with more of a plan, which includes goals and then includes open ended questions. Because what I see is a lot of people who are not researchers or who have not trained as researchers or anthropologists, they ask very leading questions. They ask priming questions. You ask double barreled questions, which is two questions in one, which is very common and very hard for participants to answer. And so there are all these things that end up happening. But if you define the goals better, then you are better off with writing questions. And I can also, if it's helpful, go over some tips for writing questions to writing more open ended questions. Sure. Yeah. Cool. Do you want me to go over the tips for open ended questions? Sure. Please feel free to share some great tips. Absolutely. And I can just directly start taking notes in parallel for my croissant research. Amazing. Amazing. Yeah. So what I'm going to share with you is something that I learned about years ago. I don't have a source for it because I have no idea where it came from. I learned about it in some weird training thing that actually had nothing to do with user research. And I teach this to everybody. And I think it's amazing. So I'm very biased. So example. Yes. Yes. That's very promising. Yes. So the way that I recommend writing and asking open ended questions is by following an acronym. And that acronym is TEDW or my fiance likes to call it TEDWA, which I'm not a fan of TEDWA. I like the TEDW. So TEDW is an acronym that stands for four different phrases. The T in TED stands for talk me through or tell me about. The E stands for explain, explain what you mean, explain what you said. The D stands for describe, describe what you mean, describe how you felt, describe a croissant, the perfect croissant. And the W stands for walk me through, walk me through the last time you ate a croissant. Let's say that acronym. And if you use that acronym and those phrases when you're writing questions or asking questions, you are always asking open ended questions and you are not leading people and you are making it more of a conversation rather than an interrogation and an interview. And that's the aim of user research is to have a conversation with somebody rather than an interview. Whenever I do my intros for my calls, I'm always like, I don't want this to be an interview. I want this to be more of a conversation. And that sets it up for actually having these open ended, honest, really insightful, rich conversations. Yeah. And I remember you when we last time spoke, you also mentioned that you personally, most of the time don't even use scripts when you go in an interview. I don't know. I, yeah, but that's eight years worth of doing research. So I would recommend having a script. I would, I would also recommend right in the script, write out these questions like that. Tell me the last time you ate a croissant, how was it? What was the experience like? And so then you have it in front of you. If you're like, oh no, what's the next thing? Cause I know that people get really stressed. They're like, what's the next question? You have this thing in your mind where you can say, okay, talk me through, explain, describe, walk me through. And then I always say, if you are struggling with what to ask next, just ask why. That's the best question that you could ask. Just ask why. Or you can say, Hey, can you explain that more? Or can you describe that more? Can you explain what you mean by flaky or buttery? You can always just default. If you're like, oh my God, what's next? What's next? You can always just default to why, or explain that more. It's actually quite interesting what you get back from people when you ask why on. Yeah. Yeah. Honestly, it's fascinating to just keep asking them why, because when you practice a lot of user research and when you have done it quite a lot, you get used to asking why a lot. You ask it continuously. They have that saying of the five whys. Ask why five times. And why? Because what that does. Exactly. But it's so cool because what happens is you watch the person also discovering things that are a little bit subconscious to them. And so that's why when people ask me things like, oh, why do you love user research? Or they're like, oh, but you're just talking to people about how they order clothes. I'm like, no, you have no idea what these sessions are because somebody's core values behind ordering clothes and somebody's motivations behind it. When I ask why, why over and over, these things that come out, you could be ordering clothes because of a funeral. That's not what people think. You could be ordering clothes because you're really sad because you couldn't go to your sister's wedding because of COVID and it's a coping mechanism and all of these things. Or you gained a lot of weight and you're feeling really uncomfortable. There are just so many deep reasons and motivations behind every action that we have as human beings. So even if you take something that seems as simple as ordering clothes online or ordering food delivery, you can just get to this core value that's unbelievable where the person even says on the other line, the participants, oh, wow, I had no idea. They're like, I learned something about myself too. I guess it's almost like a psychotherapist session. You get people to think about reasons that they maybe never thought about. And when you learn those things, like when you learn a core value, it doesn't just impact your team. Let's say it can impact sales, marketing, account management, tech and product. It can impact so many different roles in an organization and so many different departments in an organization. And that's when user research becomes so much bigger than just product. Because some of the things that I have learned through user research, I've gone to marketing with and they're like, this is gold. We can use this for marketing strategy. Yeah. To target people more directly, right? Yeah. When I have my interview set up now and I have my goals and my questions defined, I think that goes kind of hand in hand as far as I understood. So what are the steps to continue? And also to come into this mode where I have the data in place and I want to make a decision or should make a decision. Okay. So you've done your interview and you have data. Okay. Then the next step is something called affinity diagramming or clustering. I know that some people are familiar with this, but essentially what it is, you're going through all of the different interviews that you did. And you are bringing out patterns and trends throughout these different interviews. So the way that I do this, and nobody is going to want to do this way, but I will explain my process and then where you can cut it out. So what I do is I have my interview, right? So let's say we just had an interview. It was one hour. I listened to that interview all over again, and I transcribe it myself. Well, that you don't have to do. You can get a transcription service because I know that's a lot of effort. If you are not dedicated to user research, like it is part of, I find it part of my job. However, if you're a product manager, designer, developer, anybody else trying to do user research, you ain't got time for that. So the best thing to do there is get like a transcription service or use something like otter.ai, which transcribes. And so after that, what you do is you look at the notes and you start tagging things that you see in the notes. Now, what I mean by tags is there are some common ways that you can tag user research, qualitative user research data. And the common tags are things like goals and motivations and tasks and pain points. Pain points is huge. If you're going to focus on anything, focus on pain points, because that's what sucks and we want to make it better. Yep, exactly. So pain points are very important and goals as well are very important because what goals do is they are what people are trying to achieve. And if our product enables the people to achieve that, then our product is good. So if somebody, let's say has a goal of eating five croissants at once for breakfast, for whatever reason, if we as a bakery only sell croissants in threes, that's not helpful for them. And thus they cannot achieve their goal. This can also be more relevant maybe is if let's say somebody is trying to travel somewhere, they're trying to get somewhere on a budget. If we don't allow them to, let's say filter or sort or search by budget, then what we're doing is we're putting a roadblock in their goals and what they will do is they'll just go somewhere else to better accomplish that goal. So that becomes like, I'm trying to get to this goal where I'm budget traveling. We don't allow that. And we also somehow become a pain point because we don't allow that. So what happens is because we don't have filters or sorting by budget or searching by budget, what happens is we become a pain point. Our product becomes a pain point that doesn't allow the person to get through their goal, they will just go somewhere else. So that's why when you're reading through your transcript, if you hear things like, I didn't like this, or this was frustrating, this was confusing. Those are all pain points. And then if you're looking through your transcript, trying to find goals or like I was trying to fly on a budget, that is a goal when you say, I was trying to fly on a budget because I lost my job. That's a motivation. So I was trying to fly on a budget is a goal. I'm trying to buy a flight that is cheap because I lost my job motivation. However, I could not search by my budget or I could not filter by my budget and that's a pain point. That sentence, let's say has all three goal, motivation and pain point. So you want to go through your transcript and be like tagging. You can highlight them in different colors. And then what you do is once you've done that with all the transcripts, you create sticky notes. So you take all of the pain points from each of the transcripts and you put them up and you try to find the patterns and trends across the different participants. And you can do the same for goals and motivations. And that's how you start to make sense out of qualitative data. And then if you want to take it one step further and be a super awesome research product manager hybrid person, then you can then take, let's say we have this cluster of people who are, whose pain point is not being able to search for a destination on a budget. Let's say, I don't want to spend any more than 30 euros going from Berlin to Russia. So I need to be able to search by a budget, this certain amount of money. What you could do, if you find that's like a pattern and trend across your seven participants, what you can do is you can come up with, how might we statements? And so what this is, is how might we allow users to search via a budget? And then what's cool, you give this to your designer and you're like, Hey, what do you think about this? They come up with two or three different ideas. You prototype test them and bam, you got like a potentially great way of solving this pain point. Yeah. Instead of just guessing. I think Alex, this, how might we statements we also use together at SumUp when we were working on features, especially to prepare a feature for the designer to be able to really think of a better ways to design a solution instead of just dictating what you want to have. It's just like also like the starting point before you go or before you move into a design thinking session or into a design sprint and so on. I think that would be sometimes that as we try to use the outcome of interviews and research and previous studies, and then as a group also try to come up with the, how might we, and I think it just depends a little bit on where you're coming from and who's like in the session, I think if it's about. Creating this common understanding and getting everyone on the same page, it's quite helpful to be like, okay, we have lightning talks and deep dive content sessions about the outcome and then, okay, let's try and write them together is one thing, but at the same time, I think if you are already like in a more, let's say mature team from processes, I think it's super helpful. And I was also, when me and Christian talked about the croissant slightly trying to, to make, to, okay. So my, my statement was that especially also generative and evaluative research while I think we were more talking about the foundational research and especially also moving to more the setup in a company, let's say Scrum and Sprints and so on. What I was thinking of was how do you fit both together? And while the more evaluative research can totally fit into a regular Sprint, the generative one is something that should be longer and like really an ongoing process and maybe even be like, I would not say separate without creating silos, but it should be something. And you also said it can inform the whole business. This is maybe moving it a little bit into a direction of less best practices around user research, but more into structures and research in a company. What are your thoughts? It's like now I just had my monologue. No, it was a great monologue. As you said, evaluative research like prototyping fits much more neatly and nicely into Scrum and Sprints and works nicer with product and tech and the general cadences that everybody is following and ceremonies that people generally follow in product and tech. What generative research does, however, is it can operate outside of this regular kind of cycle of Sprints. And so how I generally set up generative research is in a few different ways. So generative research, which you can also call discovery research, foundational research, exploratory research, like it's okay to interchange these things. So I just call it generative research because it's, it tends to be a buzz, more of a buzzword for this. But the way that I set this up is in a few different ways. So you can do generative research based on business strategy. So if you have an understanding of where the business is going in the next six months, 12 months, et cetera. And let's say you want to maybe open up a line of muffin croissants as a new innovative product. So it's like a hybrid between a muffin and a croissant. So let's say that's our business strategy is to start expanding our menu of croissant related products. So that's where user research can come in. And instead of saying, okay, let's just like create this muffin croissant hybrid and throw it out there and see what happens and invest a lot of time, energy and money into creating this thing, what user research can do and what generative user research can do is back it up a little bit and say, okay, before we just like jump into this, let's just do a little bit of generative research beforehand to understand, okay, what's the difference between muffin and croissant? What are the situations that people eat them in and how can we maybe combine them or is there a better alternative for a product that's where generative resource can help inform or give a little bit more direction to the business strategy. Now, when we funnel down to, let's say a particular product team, so a squad or a scrum team or however you want to call the team. What I always do is I work directly with the product manager and I'm like, Hey, what's on your roadmap? And I know that some product managers are like, please don't ask me that because I don't know. And I don't want to think about that, but it's really interesting for me to look and see what the topics might be for the next one or two quarters. What will happen is then I see next quarter and the quarter after that we're thinking about focusing on these different topics, right? And so what I will do is I will start generative research then to help inform Q the next quarter. Let's say we're in Q1 right now and you have a basic roadmap or a basic kind of thoughts around Q2 and Q3, anything that we think, Hey, we need to understand this problem space more. I will start doing generative research for that now so that we don't need to wait for it so that when Q2 and Q3 come, we are like, Hey, we have prototypes. Let's test them in these sprints that are happening. And that is how you fit in generative research. Unfortunately, you have to plan for it. It's not a reactionary type of research. It's much more planning focused and sitting down with the product manager and saying, these are the concepts, let's do them now. And it doesn't exclude the explorative research as well, which can still happen in parallel inside the sprints, for example. Yep. To be completely honest, I am always running a generative research study, like almost always running generative research because if your company has the budget, has the resources and can do something like that, there's always something that needs to be understood more about a concept. Do you do it on different levels? Like one is the company overall and then more specific products in the company and you have studies running the whole year? I try to do more of a company level one, once a quarter. It doesn't always equal out because sometimes there's not something that makes exact sense to research. And that's why I also find it important to say not everything needs user research. If you don't need to, you don't need to, and that's okay. And if it's been validated already from whatever means, then that's also totally fine. Sometimes it's once every two months, or sometimes it's once a quarter, or sometimes it's once every six months. It's to the needs of the business and to the needs of the business strategy. Whereas that more like product focused, so product team focused generative research. So in the past, I've worked across five to 10 scrum teams or squads at once. So I'm always, because I'm like 10 different teams, I have 10 different topics. So I'm always doing discovery research for someone. But I do try and do certain discovery research that something called Walk the Store, which is going through an entire product. And it's a mix between interviewing and contextual inquiry, which contextual inquiry is just a fancy name for observing and watching people and silently stalking them from behind. Essentially, you're walking. Yes, it is. People get very used to it very quickly, though, participants are like, Oh, I forgot you were here. And I was like, I didn't. But you're watching somebody use your product. And every once in a while, when they do something a little bit odd, you're asking them, hey, why did you do it like that? Or walk me through the last time you did this? Why did you do it? Why was it like this? Why did you click there? Why? You know, what was the problem here? And so that kind of baseline research, I tried to do as well, because that can generally be used across a lot of different teams, because the way that a lot of different teams are structured is they're like siloed in different areas of a product, checkout, and sign in and search results and search or acquisition and retention and things like that. So if you do an overarching view of an entire product, you can impact multiple teams with those insights. Yeah. A pressing question from my side, because I'm now totally committed to starting my croissant business, my own bakery. Zalando is a company that has the budget that has the people for user research, also has the market to do a lot of user research. I don't have that yet. But I will in a couple of years, I hope. When do you think is the right time for a company to get started with a research department? Or when should I hire my first user researcher? Yes, there are a few different ways that you can determine, hey, it's time for user research to come in. The first one is capacity. When you as an individual, as a product manager, let's say you're also doing user research or a designer who is also doing user research. So you're like, hey, I'm doing this, we don't need one. If you are doing so many different things, and also trying to do research, something will generally suffer and not be done as well. So when it becomes too much for you to properly do user research, that is a nice indication of, hey, maybe we hire a part-time user researcher, and start out with that part-time. Because let's say you don't have the budget for a full-time, start out with somebody who is a part-time user researcher. And I promise you, they are out there, because I would like to be one. And I know a lot of other people who would love to be part-time researchers. So that's a great indication right there is when your capacity is running out to do this properly. Because I will go against what people say, and I will say, do not do research if you're not going to do it well. Because this is how user research gets a really bad reputation. If you do not do user research well, you make really bad decisions, or you run the risk of making very bad decisions. Thinking they are informed. Yes, you think you're informed, and you're like, we should do this. And then it's completely wrong. And then you're like, I hate user research. And then everybody hates user research. Same with German Kanban. Yes, exactly, exactly. You can mess it up. So don't do it if you're not doing it properly. And so if you don't have the capacity to do it properly, then it's time to think about hiring a user researcher. Also, if you have found market validation, so market fit and validated your idea in the market, that's a great time to bring in a user researcher. Because what that researcher can then do is say, OK, yay, we are validated. The idea is validated. So let's research to find out how we create that idea into a proper experience. And that is something that a researcher can help with. Or you hire somebody who's 50-50 design and research, and can do that research, and then create that design. The only problem is when you hire designers who both design and do research, it's very hard because I used to design. It's very hard to research your own designs because you have such an inherent bias to them. You're like, no, please like this. So that can just be a little bit complicated. But once you're like, OK, this idea works, this idea is more or less OK with the market, how are we going to build this? What features do we need? What does the experience need to be like? What feelings should people have? How should we create these flows? That's when user research can come in, and a specialist can come in and ask the right questions to get you those answers. And I would also say, in addition to that, generally, if you have the budget, hire an in-house researcher, even if it's only part-time. Because what happens with in-house, and I've been both a freelance and an in-house researcher, so I'm not saying anything bad about freelance. But if you want somebody to come in and help you for a while, which is generally more helpful, and if you don't have a research department set up, what you want is to hire somebody in-house so that they can build the domain knowledge. So I don't know anything about croissants. What I need to do when I come into your company is learn about croissants, learn about the product, learn about how things work, learn how the stakeholders are thinking about things, and then go about and do my research and deliver it in a way that aligns with stakeholders and the business. It's harder to do that as a freelancer. So generally, if you have no research department, it's really hard to get a freelancer to come in, do this stuff, hand it to you, leave, and then you're like, wait, what do we do with this? Budget in mind, speaking about the two different parts, like qualitative and quantitative research, is it realistic that I find someone who can do both at its best, or how should I prioritize the two roles? Yeah. So there are mixed method researchers who are super human. I don't know how they do that. I am always so impressed when I see mixed method researchers, and they're like, yeah, I'm 50-50. I'm like, how? So I think that it depends where you are. So if you're in like a very like product discovery phase of we don't really know yet what we want to build, we're just trying to understand some things, get a researcher that specializes in qualitative research, but can also run surveys. So what you can do with those qualitative insights is you can run an opportunity gap survey, which essentially helps you prioritize the insights that you found from qualitative research. A lot of qual researchers also have the ability to run these surveys. If you already know everything, and you're at a point where you're really trying to like validate and generalize and go into more the numbers focused game, then go for the quant researcher who can continue to run satisfaction surveys and do satisfaction analysis. So those are the two. Obviously, it makes sense to have both or somebody who can do both. But if you have to prioritize, think about where you are with your product. Niki, that was all very helpful. And we are also time-wise close to the end of the show. I would love to still give you the opportunity to add something if you think there is something that must be said or something that you definitely want to place or see Christian has. Maybe you can wrap it up because there are so many practical and actionable things to share today for product people who want to get started with user research. What would be your key takeaways? A great question. My key takeaways is remember when you have a project in mind, start thinking about user research. It's okay. You can do it. It's not impossible. Start thinking about generative research versus evaluative research. Think about your goals and then write your questions based on those goals. Always write your questions based on research goals. And those goals are what you want at the end of the research study, what you want to achieve. And then always remembering this whole sad fact of per segment, five to seven people per segment. Because if you do honor that rule, what will happen is you will just get better insights and then user research will be much more useful. So the insights that you get, you can go and create things that are applicable for more people. So five to seven people per segment is super important. Also just a final note, try not to ever ask future based questions. So would you like this is not a good question because people can't predict the future. We are terrible. I would say that I'm going to the gym every single day this week and I am lying to you. So what I would say is always base your questions in the past instead of asking something like, would you use this? Ask something like, have you used something similar to this in the past? And base all of your insights off of the past rather than the future. So those are just some, and don't forget about TED-W. You can do user research if you use TED-W. Awesome. Well, Miki, then I would say thanks a lot. It was a really interesting session. I think there are parts of learnings for anyone who's not yet in research and probably also for one of the other researcher. We will make sure that we share the guideline for the goals, for the research goals. And yeah, thanks a lot. Enjoy the rest of the evening. Yeah. Thank you so much for having me. It was fantastic. I enjoyed the conversation. Great, Miki. Have a good night. Bye-bye. You too. Bye. Wow, Alex, so many insights and blown away. How do you feel about the conversation today? Super helpful. I think there were so many actionable tips and really the basic best practices to start doing research or to improve your research if you're already doing it. And I think the good thing is really what we see is that research is nothing new anymore. People know about importance, know about the relevance of the company. And it's really about like how to get started and giving the tools to everyone to at least start or have a basic understanding also on how to get your first researcher in the company and also have enough of an understanding about research to maybe even know how to interview a researcher or just to make sure that they actually have the right level or understanding that you would want to get in the team. And I think for that, it's super helpful to get all these small little tips and tricks like starting from the T, D, W, and so on. So really can't wait to click the publish button for this one. Absolutely. I really like that she also started with the basics, that everyone is on the same page and we all have this common understanding of what the methodologies and also the vocabulary is behind user research. And something that we touched already in our previous episode was this kind of dual track research that you do to focus first of all on the problem and at the same time on a solution, which I liked a lot. I was a big fan of the fact that Nikki was so honest about the way she structures her research. What I really liked was that she starts with the questions you want to phrase, but at the same time also things about the answer she wants to get out of it. And people attempt many times to jump too fast into either the question or the outcome, but it's so important to look at both to be able to really define a good user interview, for example. I was a big fan of that and it also reminded me again to really focus on both parts and not just getting quickly started with one and ignoring the other. One final thing that I at least noted also for myself again was when we talked about quantitative versus qualitative and when to get it into your company. The way Nikki put it was when you still need to figure out what you need to do, then you need to have the qualitative part. When you already have all the information and it's like about, let's say it's a wider validation and statistics and so on, then you can get the quantitative data in. This is something, or this is probably one of the biggest parts still at least like out of my experience where you need to educate stakeholders a lot in the different companies because what I see a lot is, yeah, but five interviews are still not enough. We need to prove the business case, so we need to have a lot of quantitative data and so on and so forth. That's even before what you want to build, even just like with a value proposition in place and then they want to blow it up with this massive quantitative status and so on. Also hearing it again from Nikki, the focusing on really understanding the users first and the what you want to do and how you want to do it and so on, this really needs the interaction with the user and you cannot be user-centric if you only look at data. I guess you really lose this conversational part as well. That's another really big takeaway from my side. Yeah. She really nailed that down. In case you are interested in getting deeper into research, I recommend checking out userresearchacademy.com. Nikki will share with us the material that we're going to link into our episode and we will also make sure that to link her on all relevant platforms. So Alex, we should wrap it up here and mention one more time our 24-7 availability on hello at product-bakery.com for feedback, tips and questions. And other than that. Yeah. Drop us a line if you want some special guests or if you think we should change something in our formats for the ones that are already following us, they know it's also an early start for us as well and we try to iterate and improve as we go. So feedback is highly appreciated. Great. And have a good night. Bye Christian.