The Product Discovery 101

Believe it or not, but the whole topic around product discovery is on my table right now. And we've talked about it a couple of times and I was just curious. Actually, just a very simple question that I never asked you in our show is, hey, Alex, how are you doing product discovery? Am I doing product discovery? Are you doing product discovery? Ah, yes. It's actually one of my favorite topics. I know you love it. Without discovery, our jobs would just be so boring, right? And I mean, I think I just over the years, I found to the process that I like the most. I think like, there's a lot of different things one can follow. In practice, it's always a little bit different, right? When you start working with different teams, when you start working with your senior management leadership that has like also certain ideas, when you have a lot of people also in the mix and you want to get into one direction. So I mean, how am I doing it? How does a team do it? At the moment, I mean, our process looks a lot like, I would say, double diamond design thinking. Crazy, crazy buzzword, by the way. Yes, that's why I'm throwing it in here. But I like to look at it a little bit. I like to look at starting earlier than where the double diamond starts and finishing after it, right? To look a little bit more into how does the overall product development cycle look like? To use another buzzword, I would say, dual track agile is definitely something that's also somehow within that process. But so if we look at the very beginning, the question is like, where does discovery start? How do you start it? What initiates a discovery? And I think obviously there is multiple different things. It could be an insight, a problem or an opportunity that you heard from your users, or that customer success brought to you or you were going through some of the emails and you saw a recurring theme there. That could be a very nice first trigger. At the same time, you could get some feature requests from within the business. I think that's another really good trigger. Or you could just start also from an idea or you look at your existing products, you do some heuristics analysis, and then you see that there are some quite obvious problems with your flow, right? So I think the initial generation of ideas is a really, really important part in where the discovery starts. Because I think you need to have an idea of what are all the topics that are not clear to you, where you need to do discovery on, where you need to go deeper and then prioritize them. So I think already there, it's a bit of a question of, okay, what could have big impact? What is the effort for a specific topic? And then based on that, you can define, okay, where do I actually go into this double diamond process? And I think also in the prioritization here, it depends on the business, right? Who needs to be involved in prioritizing it? Do you prioritize only based on your objectives that you've set? Do you prioritize by presenting it to some of the key stakeholders? Will some of these tasks, because even discovery eats up resources. So will some of these discovery tasks actually take priority over some other tasks that might already be on the roadmap? And who do you need to involve? And I think here, obviously it's going more into the direction of our beautiful triads for everyone who's listening for the first time. What's the triads question? Well, before that, I need some more clarification on this whole double diamond part, by the way. I mean, we're not there yet. Yeah. So please. So one thing I do understand totally where it starts and how to move on, but I'm product manager. I'm thinking in what I'm thinking about. I'm thinking in columns and processes, right? And I try to, I don't know, to visualize what kind of steps are being followed in your product discovery. And maybe you can just elaborate a little bit on that. So I mean, it's this idea that is like, okay, there are multiple things where you can go from this idea, right? By validating it, by testing it, by designing it, by moving on into the product development process. So how do you do it at the moment? Yeah. And I mean, so far we've only talked about the capturing of those ideas and problems. Yeah. Okay. So this is not yet the discovery. I think the discovery then like really starts. There is like, if you want to look at it in like columns, more of the Kanban style, you have like two main parts. One is like really focused around the problem itself. What is it that we're trying to solve? What is it that we're trying to understand? And then after that, you have the solution space. I think this is like how I look at the two diamonds, right? So you first try to like really get a lot of knowledge around the specific problem or the specific problem space or opportunity, right? This can be very broad or very narrow, but you're trying to get as much information as possible. And that's usually done through research. So you can talk to people, you can look at data, you can do some tests and so on and so forth. When you then have all that information, and this is again, if so for everyone who's like thinking about it visually, the double diamond looks like you take two squares and you rotate them to 45 degrees, right? So now we are at the top of this first square, right? So we went broad, we have a lot of information. So you now want to converge down into this synthesis, right? So like you're taking all the data and you're trying to analyze it so that at the end you come out with a really clear problem definition and you have like a good understanding of the problem space so that you can go into this next diamond or 45 degrees turned square, which then would be ideation. So how can you solve that problem? What are different possibilities to solve it? And then from there, through testing and again, analyzing, you're trying to narrow it down to the final solution that you want to build. So it's like really research, broad synthesis, narrow ideation, broad testing, narrow. That is pretty much what the double diamond is. Got it. I like to look about it less than those two diamonds. I like to look at it more as like a circular thing where also in the synthesis, you might like get more information, you might have to then go back, do some additional research until you really come back to the final definition of the problem or to the final definition of the solution, right? So I think like it's like really something where you can, it's not a linear process. You might have to run through it, multiple circles, multiple iterations before you go to the next step. And between all of these steps, what we also do is we try to have these like alignment meetings most of the time, like also with the senior leadership. So teams would prepare quick sessions. It's really like a pitch where they would come in and present, hey, this is the problem. This is what we found. This is why we think it's important for us to work on this. And this is why we should prioritize it. And that's usually the case for tasks that are not yet somewhere on the roadmap and so on, right? So I think those quick pitches allow the teams to present it, to get also the feedback from senior leadership. Again, this is where the Triad PM, engineering manager PD comes in, this time on more the management level, and then the team gets the feedback that they need to prioritize it or to move it forward. And the same happens again with the solution space. And only then, after the solution is like defined, that's then where you would move it towards the sprint planning, roadmap planning, and when the task moves into this crumb backlog. So all of this happens a little bit like in line with the normal development. So you do have like, usually different tasks that the engineers are working on. You need to make sure that you have like some time dedicated in each sprint that people can work on discovery. Obviously like the product manager and the product designer, most of the time leading the discovery, but you might need input from the rest of the team. And then only after it's like defined, it moves into the sprint, people start working on it, and the role of the designer and the product manager becomes more of a supportive role. In that case, more of the designer supporting the engineers, like also with the development, with the specs, with all of the assets that they need. We just talked about it, right? The product design and engineering collaboration. Absolutely. I want to catch up on the whole topic of this circulation, right? Because something that I like to talk about when I'm working with product teams and I like to educate on is this whole topic around transition guidelines. So that you make sure that before you move on, you have to fulfill certain criteria in order to be able to move on to the next step. Yeah. And what I see many times is that these things are, I don't want to say getting ignored, but where people tend to be too fast by trying to deliver something. But that's the reason why you have rules and guidelines, right? To ensure that the quality is given and that you have the clarification on what you want to build or how you want to solve it, or at least what the real problem is. So therefore, I just want to stress that point of the importance of having those transition rules and also making sure to not skip that. How do you think about that? I mean, you're pointing something out that when we first launched this process within the organization, exactly that happened, right? I think people looked at the process and they looked at it of like, okay, I now promise that I do discovery on a certain topic. So I need to have an outcome. I've seen teams even having discoveries and those alignment meetings that we call product gems. They even had those as their own KRs. So in Q4, I want to have like a product gem on a solution for problem X. Now, the thing with discovery is that if it would be already clear to you what the problem is and what the solution is, you wouldn't have to do a discovery. That's a waste of time. You need to admit that there is a space of uncertainty where you need to discover. I mean, that's what the word says, right? So I think it's good to have like these touch points in between. And this is like where those alignment meetings help because it's also a good reality check for you and for the team. Like you can present it. You try to like also avoid that you're biased or it's a certain direction. I think this is also where then other team members need to challenge and need to make sure, okay, are we answering all properly or are we like interpreting certain data or certain research or certain information just because we want to build this and because we want to take it off, right? So I think it's important that you don't have like a fixed timeline. And that's why I also like to remove it from the actual sprint and to say it needs to run in parallel or run a little bit in advance. But also there, it's not like, oh, like there is the development team working on feature X in this sprint. Therefore the designer and the product manager working on the next feature for the next sprint. That doesn't work because like you will end up building something just because you have to. And because now it's there in a sprint. So you need to have like your roadmap plan. You need to have the team working on things and discovery is on top. And then depending on your findings and the importance and the impact and so on, you can reprioritize it. And that's also where the beauty of agility and lean development comes in because like you can potentially change also the roadmap and put something in that's like having a higher impact. Yeah, but I fully agree. But in addition to that, I think it is just super important for product people to do all this, this research and discovery part during the sprint. And what I see many times is that the product people are super busy by asking questions, identifying that something in the process, in the product is not working. So they have to discuss and do many things during the sprint. And I just want to stress that again, I'm not today in a kind of stress mode, that a sprint should start when these things are clear, actually. For sure, you can always leave some things open. I mean, it's not like bureaucratical work, but still, even according to the idea of agile and scrum, stuff should be clear before it's getting pulled into the sprint by the team. And once you accomplish this by doing good research and doing a good discovery, you free up yourself to be able to continue this process. And I see that many product managers and also designers are getting trapped into the operational work during the sprint by not spending enough time to prepare. But I'm also happy to hear if you see this happen different, which I guess in your beautiful team. Yeah, I mean, it's down to also time management, right? That's what I'm saying. You need to block a certain percentage for those like operational tasks. And you need to block a certain percentage of the time for the discovery. And it's very important that you have the time for discovery because that will then define what's coming in in the future. And that's why it's also like two things that you need to separate and run in parallel, right? So that what is being developed, as you say, needs to be clear. What is being discovered is something that's unclear. So what is currently being discovered should also not be scheduled for any of the upcoming sprints until it's not clear. Otherwise, like you will end up being in that sprint, building something, still having a lot of uncertainty, still having to go back and forth on the specific solution or trying to find out even more on the specific problem or to align even more people. And then you're in this crunch, and then you won't be able to deliver properly. Yeah, that also brings us to the discussion of a definition of ready and definition of done, right? That usually if you follow some scrum rules should be in place to ensure that you do not have these issues during or at the end of the sprint. Absolutely. And for each part of the discovery process, you should have, let's say, it's not so much a definition of done or ready. It's more of like some fixed questions that you need to be able to answer. Yeah. Which I see as the transition guidelines, rules, however you call it. There was a better word actually, but I forgot about it. So need to use that for the moment. Well, once you think about it, you should bring it up again. We add it into the description if I'm going to find it. Absolutely. I think that transition guidelines is something I can agree on right now. Let's call it transition guidelines. But yeah, I mean, that's how I look at discovery. Yeah, thank you. And I found it also really interesting to see how you start actually within your company, right? By people just skipping steps, which is also a natural thing. And from my side, one inspiration or one idea to talk about it today is also to share with the world that you always have these problems of the processes are changing, ways of research are going to change with that transition guidelines. So these processes need to be regularly reviewed and updated. So it's not set in stone by just having like this planning phase where you say we are going to introduce a new process. No, it's not only that. It's something you need to work on continuously. And if you don't, it's going to fail. Yeah, absolutely. Absolutely. And I think just talk also as early and often about the things that you're trying to discover to get feedback, to get input and so on. Don't think about it as like a process that should take a month, two months, a quarter or even longer, right? Really try to quickly go through those circles, right? And keep sharing, keep getting feedback, keep prioritizing, put some things away if you don't come to a conclusion, if you can't validate that it's a good problem to solve for or a good opportunity to work on. And just like stay flexible. Well, Alex, aiming to that. Cool. I mean, let me know if there's anything else. Otherwise, I'm curious to hear also from our listeners how they're approaching discovery. Totally. And I just want to highlight that there is this new Spotify feature that allows you to interact with us directly on Spotify. So you can ask questions and just feedback ideas or something to talk about. Cool. Christian, I see you next week. Have a good day and talk to you soon. Bye-bye.