Death through research

Welcome to the Product Bakery. I'm sitting here today with Alex and we had a quite nice and decent brunch this morning. It's 12 p.m. in Berlin. That's the luxury again of working with a former baker. Yeah, but I have to say I didn't bake myself today. Nevertheless, Alex and I had a very nice conversation this morning talking about what makes the perfect croissant so delicious. While we were brainstorming and discussing how to bake it, etc., we realized this could be something that needs to be researched. And once we were starting discussing how you can research what the perfect croissant is and how to bake it, we realized, okay, there are so many things that you can do. You need to consider there are so many people from different countries, different tastes, etc. that would be able to give us some feedback. And we asked ourselves, would we somehow come to a conclusion or not? And with that, we realized research is quite a tough topic, especially related to croissants. Not only that, we also realized research is a topic that is also not easy to approach in companies sometimes. Alex, what are your thoughts about that? That's an amazing intro that I definitely did not expect. But yeah, especially when it comes to taste, it's really hard to judge it. Some have taste, some don't. In my mind, I'm laughing because I'm referring to a meme that I've seen just this morning, but it's a pretty dark one, so I won't. Anyway, but coming to the research topic, I would almost try and ask you something back, because the way you just opened it with asking or with stating that we need to research something, it's not always the case that people think about research as the first immediate thing to answer a question. Generally, or especially like in our industry, where you have a lot of professionals with a lot of experience, sometimes research is played a little bit down because people think they already know the answer and so on. It really depends. If you think of the companies that you worked with in the past, when skipping research, what would you say is the main reason why people would skip research? Yeah, that's a good question. I would say it depends. On one point, I think people know the answer, and on the other hand, people think they know the answer. And what is the difference here? Let's say you are working in the industry of fintech, where we're coming from. You have many times topics that are strongly and heavily regulated, so you don't necessarily need to research whether it makes sense to build something, it's quite clear, but you still have the research part where you need to figure out how it will look like at the end for the customer, for example. If we look more into the area of B2C, or apart from strong regulated topics, here people tend to rather jump on solutions than really asking themselves, hey, what's the real problem? So research is something that maybe sometimes gets skipped, because people don't want to waste time. With the result that you build something that is not necessarily what the customer wanted. Yeah, that's definitely a good point. I think quite often, especially because we have a lot of best practices already in place, and it's fairly easy to copy something or to really like something that you've seen somewhere, let's say, I don't know, over the last couple of years, there was like a pattern that came up quite often was like the interaction of Tinder, and then it's, oh, why are we not building Tinder for banking? Or why are we not building Tinder for insurances, and so on, or jobs? Yeah, I totally see the point of falling in love with existing solutions, ideas, and so on. I really have to also start by saying that the trend is going in the right direction. And most companies that I've spoken to, and also like most designers that I've talked to, would say that the companies are moving in a direction where they value and understand research, and where people know that you need to do research. I think it's just too obvious. You need to build a solution that your users want, that they can use, and that they automatically like will use. And you also need to get it in front of your users early in order to be able to iterate and to don't build something that maybe won't work in the market. Let's say I'm a CEO who believes that research is not needed. How would you convince me? Here, the important question is, why do you as a CEO think that it's not needed? Because I know what the vision is, and I have the solution already in place, and we just need to build it. Well, there are some ways to prove you wrong. And usually what works the best is to really get you either in front of users or get users' feedback in front of you. And it might sound weird, but the simple act of recording some user interviews, cutting it together with the key insights, and showing it to someone who doesn't believe in research, which again, I feel like it rarely happens nowadays that the people are like, yeah, no, I know it better. We don't need to do research. But simply showing them the user's feedback and so on can be quite eye-opening for many people who initially don't believe in it or don't think research can be anywhere helpful. So you're saying that the data-driven approach or collecting data would be one way to open the eyes of people and say, hey, you believed that X, Y, Z would be the solution. We have done the research. You're right. Or there are data that prove that we're wrong, and we should maybe take another step back and ask ourselves again, what is the problem? Do you see this happening in companies? Because from my experience, I see many times that people don't find the time or even don't find the motivation to go out and talk to people. So I think it's like a tough topic somehow in companies these days. I agree with you that we are going into the right direction and product discovery and research becomes more and more famous and also more and more accepted by companies. But still, I see sometimes people hesitating. Are there any tips you can share to product people out there to quickly get the information they need in order to convince the upper management or colleagues that first of all, research is needed, and secondly, that prove or disprove the feature to be built? I think we are opening a lot of different topics here, and probably I would go through them one by one, ideally. And one of the questions that you just raised is the time, right? And I think the time is definitely one of the biggest issues or the main reasons why some companies decide to not conduct research or to not go outside in the streets, because it's generally hard to have enough time to do research. Time is money. At the same time, we also need to look at two different ways of research. What you just mentioned is how can I validate a feature? How can I validate, let's say, an assumption or a hypothesis for, okay, does this work? And the other one is more the foundational research of what do our users need and what do our customers need moving forward. With those two things in mind, and especially focusing on the time, I also have to say that I really like the term, I'm not sure when I heard it last time, deaf through research. Because while I think that obviously, like we just discussed that research is super important, but at the same time, if done wrong, you can research projects to death. And here, we also need to look at the maturity of a research department in a company and of the understanding of how to conduct research. Because what I've also seen is that designers, product managers, analysts, they fall into the trap of trying to answer everything with research at one point. The second you start researching, it's hard to decide, okay, when do I have enough information? When do I know it? And frankly speaking, it will happen a lot that you don't have the final answer. It's very hard to, in a research phase, be able to say 100% what the final outcome will be. And that's where building it is simply the only way to get the final answer, the feedback that you get from the market. So you say you get the 100% confirmation once stuff is on production. Yeah, that's like when you see if people are using it and how they're using it. Before that, you always have some sort of bias of the research methodology that you use, of how you ask some questions, of how the prototypes look like that you show, and so on and so forth. So it's really hard. Going back to my initial question, how a product person can get started quickly to gather data. So your first recommendation is don't overblow it. My question is here, when is the point you would make a cut to not research to death? I think it's really on team that is responsible for building the functionality to make the decision to also break it down into the smallest part that they can ship to then get like real life data. And yeah, to come into an iterative approach and to like really try to break it down, have small assumptions or hypothesis that you can answer, that you can answer in a short time without trying to have an answer for everything. That means the first thing I should do would be defining some hypothesis that I want to prove or disprove. Okay, let me take one step back, because then we can like really jump into also the operational part of how to do it. When we say time is like one of the big problems with research, and when we say that you can research projects to death, research, especially like the foundational research, tends to be slow. Because it takes quite some time, or it can take quite some time to find that one killer insight that makes you understand what to build next. Or like, it's not something that you can force into a sprint specifically and be like, okay, something that you see quite often is you have research integrated in a delivery team, in a squad, especially now where we speak about cross functional teams. And what you would do is you have the researchers working ahead in time. You have one sprint, researchers work, I don't know, one, two, three sprints ahead. And then you have designers implementing for the delivery sprint that's currently ongoing. And the problem now is the team wants to build something. The researcher steps in and says, oh, yeah, no, sorry, we didn't research this, or we don't have enough data for this, or we are still working on discovering this other part. And again, as we said earlier, it's like really hard to plan when you will find that insight that helps you like move the product forward. I think in general, the way I like to look at research is to separate it and to take this foundational research out of the delivery. So that means you make a cut in terms of the process, and start splitting it to parallelize things. Is that correct? Yeah, so more of you always will have like your delivery team. Let's call it delivery team for now. So you're talking about the teams that is developing the feature? Okay, exactly like the scrum team or the squad. And they need to do research. But they need to do research on this level of delivering. And what they test is, they can test the desirability of a specific feature, they can test the usability of a specific feature. But what that means is that you always try to get one specific answer to a question. As you said, will someone use this feature? That's something that the squad scrum team delivery team can answer themselves and as a collaborative effort of the team. So this also means this could be simply setting up one new point in the navigation to see do people click on this. So it's a very specific question. You can say, okay, what's like our KPI? Or how do we measure success of this question? You test it, and then you build it. And that easily fits into the normal like sprint rhythm. And using some buzzwords, dual track HR, right? So within your squats, you kind of for each sprint, you try to look at what do I want to discover? What do I want to deliver? And then these two things work in parallel, and they can follow the same rhythm. Now, at the same time, when I speak about like foundational research, that's really looking at the whole picture of the users of what are their needs? What are their goals? What are their pain points? What are their jobs to be done over time. And this is something that needs to be an ongoing effort. It's not something that you can specifically time box the way you would time box research in delivery. It's more something that you need to constantly do, you need to constantly stay in contact with the users, constantly need to try and find some new insights, learnings, and so on. And those insights and learnings will also change as you change the product, as maybe something changed, like in society, let's think about Coronavirus at the moment. It's something that's constantly changing. So you need to have this ongoing effort. And that's where I'm saying, this is something that should rather happen outside of the sprint. Because if you keep those two things separate, so that you say, okay, someone looks at the foundations and shares this insights, then with all the delivery teams and with the business, this still allows you to keep the pace that you want to have on the delivery sprint and within the squad, and not slowing down the whole process, which is the fear sometimes when companies look at research and research being executed in the wrong way, for example, by also setting it up in the wrong way within the teams. To summarize that, for now, you're saying that generally, you should look at research from two different angles. One point is the research within the squad to answer the question on if and how the user will use the feature. And then on the other hand, you will have this kind of paralyzed research that focuses more on a big picture and more on the why. Can this be done by one person? Or do you see this always split it in two kinds of departments? Where is there the line to be drawn? As usual, there is no right and wrong answer. You can probably combine things depending on also what you're building and what you need to kind of ship. But I think in general, I would suggest to keep those two things separate. And I'm super curious also, we will soon have a conversation around exactly this topic with Niki Anderson, which is the head of research at Zalando and also runs the Research Academy or is co-founder of the Research Academy. So she probably can share maybe some different perspectives also on this. But I think by separating, you can exactly allow doing what we discussed earlier, which is like keeping the speed of delivery high, while also constantly looking at the big picture and constantly looking at user needs and understanding them. And one needs to inform the other. I would say there are probably ways to combine this or to move also a little bit the line. But every company needs to find what works best for them and for their team setup and structure and also the functions that you have in place. But for example, the way one could apply it is that the delivery research is more driven by product designer, for example, within the squad looks at a little bit more holistically, while the whole foundational research. And we're talking about ethnography, diary studies, user journey maps, personas, and they are just relevant also for every single team in the company and for even business level of the company. There, I would definitely see like more kind of the research function as a researcher, maybe someone with even background in psychology, like to really be able to fully understand also the insights from the users and yeah, combine it like this. To summarize it again, I like the idea of keeping these things separate by looking at the squad and then looking at this on a more kind of user level. And then at the same time, having the particular research for more looking at the big picture and the customer. So you were saying that we will have a guest who will also next week, share some insights on the holistic big picture research and how to approach it best. We will see what she gives us in detail, but I would imagine that she also has like more insights on the very specific level of research. And I think something I'm also curious to hear from her is like how she would look at this whole topic of how to integrate research in a company. I think she's definitely the right person to speak about it. But yeah, in a nutshell, independently of team structure and the end process, just make sure to use research in a way that you can answer some very specific questions quickly, which helps you like to keep the speed of the delivery up, which is very important, especially like also with pragmatism. Don't try to get stuck in this trap of endless research, because again, at some point, you just need to take the leap of faith and take a decision, build it, get it into the market and see like the real reaction. Ideally, you can break everything down in very small steps so that you can release something quite early to get feedback and then try to balance it with some longer studies that should not block you from shipping, but that help you like understanding the user needs, understanding where you want to go. And the other one is understanding how to get there. I like that. And looking back at our croissant research this morning, I think the kind of research to death is very applicable there. Instead of figuring out what is the perfect croissant, we should rather bake one and figure out if people like the version we have shipped and then from there on iterate. So what you're saying is that research to death happens especially when you do not formulate your question that you want to answer in a specific way rather than when you're going too broad, right? Correct. All right, then let's wrap it up. Alex, thank you very much for this insight today. I really like the key takeaway to make sure that you be as specific as possible when you want to do research. And other than that, as always, a small hint on our 24-7 online availability via hello at product-bakery.com. We are always up for feedback. And other than that, I wish you a great afternoon, Alex. Thanks a lot and see you soon.