Continuous Discovery Crash Course (Step By Step)

I used to believe that product discovery was a one-soft thing that you would do as part of something called a design sprint and I now realize how wrong I was but I also realized that most organizations totally mess up product discovery. Today I want to give you the structure on how to run a great product discovery, how it should be a continuous thing you do and give you a bit of a hint into some of the methods you should be considering. Stick with me to the end to get five killer tips on how to make your product discovery a huge success. So why do we do product discovery in the first place? There's a classic Steve Jobs quote that talks about most people thinking that 90% of the work behind creating something new is the idea itself, but it's not. It's in understanding the problem space and exploring that problem and evolving the solution over time. Product discovery tries to help us do this. It's about understanding what the problem is we're trying to solve and then finding the right solution for that problem and doing that in a way that helps us move quickly and reduce risk. We often look at the four big risks when it comes to a product. So that is the value risk. Will customers actually want to pay for this? Viability, is it something that we as a business can support operationally? Does it sit right with our values? Feasibility, is it something technically we can even build? And finally, usability, which is can people actually use the product in a way that makes sense? The problem is all companies do product discovery at some point. I learned this from Christian Idioti from... Silicon Valley product group. Now you either do discovery before you build the product or you do it after it's launched. The thing is when you do it before the product is launched or you're building it you can actually make sure it fits the market and serves the customer's needs. Now that doesn't mean that it's a staged activity. That's what I used to believe. I used to think you had to do a design sprint. You'd understand the problem space. You'd understand the customer's solution that they need and then you'd get into building it and that'd be it. That'd be all the discovery you'd do and how wrong I was. you need to do is you need to be talking to the customers constantly and this is where we talk about continuous discovery some people call it dual track but really in its simplest form what it means is that we start working on a problem space we understand what does the customers need and we find ways to solve those problems Now, we come up with as many solutions as we can, and we kill those off by looking at what assumptions would need to be true for each of these ideas to work. And eventually, you're going to whittle down to one idea that really hits the nail on the head. Now, this involves the entire team. We talk about the product manager who's really focused on the viability and the value that this product will bring. We've got the tech lead who's going to bring the engineers along the journey and involve them in the product discovery, taking a lead on Is the solution something we can build? Is it technically possible? We have our product designer who's going to be designing a great experience from the customer journey end-to-end, but also the interactions. We can test all of our assumptions and that's where discovery helps us unpick that. So let's be clear on the difference between problem discovery and solution discovery. Problem discovery requires a bunch of research to really understand the customer, their environment, what needs they have. If you want to check out a framework called jobs to be done, it's a really powerful way to think about what are those underlying needs that a customer has. Once we've understood those needs, we can make sure that they align to our product strategy. This is one of the key things for discovery to work well. If you don't have a product strategy, You have no effective means to prioritize the problems you're solving. You might as well just be solving things at random. What you want to know is what are those biggest problems you need to solve? And that should be referenced in your product strategy and your problem discovery is going to be informed and fed into that product strategy. Now that we know what problems we need to solve and we know which are the biggest, most important problems we need to solve, we can then get into... How do we now best solve them? And that's where the continuous discovery comes in. We're picking up these needs and exploring them. In terms of how to run incredible continuous discovery, Silicon Valley Product Group have done the heavy lifting for us and have come up with four principles we need to follow. These aren't tools and methods. We're going to touch on those in a moment. Here's some of the ways in which we can set up the team for success with the right principles. First is minimize waste. We want to minimize waste. So everything that we do here is all about doing it as quickly as possible to give us a good enough signal that this is the right thing to do. This is where I love a quote from Teresa Torres. Teresa says, product teams work on a faster cadence. We don't have time for perfect research. And that's okay. We're trying to mitigate risk, not seek truth. What we're trying to do is look at a bunch of different solutions, test a bunch of different ideas out. get a reasonable signal that this is the right thing to do, and then we go and start to build it. And again, those signals come through running different experiments, which leads me to the next principle. Embrace rapid experimentation. So what we're trying to do there is run lots of quick experiments. There's different ways that you can do this. You might want to run a test that people can click and use. You might want to go and test the feasibility, run a bit of a exploration piece around can we actually build this item? And that's where we're actually testing the risks. And that's where the third principle comes in. We're wanting to experiment and test the risks. We're checking these risks. So generally, every solution has a set of assumptions. What would need to be true? for that solution to work, those are all risks. So for the key ones, we need to go and test those to make sure that we're solving the problem in the right way. Of course, when we're running these experiments, we don't want to do anything that's going to harm the business. And so this is where you want to try and test ideas out in a safe manner. And that leads us to the fourth and final product discovery principle. And that's test ideas responsibly. Redbubble did a really great job of doing an experiment around should they integrate the Amazon payment gateway into their checkout. They set it up so only a small part of the customer base would see this. And basically you had your normal options to be able to do a checkout on. credit card and PayPal, they added in Amazon and all they did is when you clicked on Amazon, it'd throw up a little spinner and say, whoops, currently unavailable. Now that little experiment led them to a really incredible insight that there was no change on the click through rate for credit card or PayPal, but a bunch of people dropping off on that page. went through and tried to click on Amazon. Of course, when it wasn't there, they bailed. Now they did that experiment by only showing it to a small percentage of the people going through that checkout. So not many people hit that situation, but it gave them some really great data that confirmed they should go and build this. What are some of the simple steps you need to take to make this happen? Because again, we've all talked about the principle level right here. There's a few tools that I turn to. First and foremost, this is arguably not really a method. It's more of a practice, but it is interviewing your customers. Book in a customer interview every week, and we want to have the trio present for these. This is so critical and so many people miss this. They think it's up to design or something like this to run it. No, the trio need to get together and make these sessions happen. meet with the customer with your tech lead your product manager and your product designer the three of you get together and have this conversation with the customers to understand their needs and start to test some of those assumptions that you've got now make sure you're bringing along the engineers you don't want a cast of 50 people in these interviews arguably probably two to three people is the max number that you want So maybe the beginning it's three and then you might start subbing people out. But it's important to give the entire team exposure to the customer so that they can really empathize with their situation and build the best solutions possible. Now we need to choose the right problem to solve using simple prioritization techniques. There's heaps of them. I like Dan Olson's prioritization matrix. It's a simple framework which helps you weigh a problem against how important it is to the user and how satisfied they are with current solutions today. Anywhere where the customer is. unsatisfied they've got a need and it's not being met by the current solutions out there and it's really important to them that's the area you should be focusing on. Dan talks about anything which is not all that important to the customer don't even bother going after. One of the things I like to do at this point is set my objectives and key results. A lot of teams set OKRs which is their goals and the measures for the quarter based on just gut feel. But if we know there's a problem we want to solve and decide we're solving that this quarter, you can write an incredible OKR that sets an objective that talks about solving that problem and key results that measure that problem actually being solved. If you want to hear more about OKRs, there's a video over here you can check out or in the description below if it doesn't pop up for you. Now we're ready to get into the solution discovery space. And we're going to be running lots of tests and experiments as we've talked about through the quarter as we build this out. This is a continuous process. It's not a phase. We're not setting stuff up for the next quarter. It's all happening this quarter. So this is where I quoted earlier Teresa Torres. She created an incredible framework called the Opportunity Solution Tree. This is where we start from the top. We've got an outcome, what we're trying to achieve. Sometimes you want to link it to the business objective, then down to the team objective. we then bring it down to okay here is the customer's needs so this is where we've got an outcome we're trying to achieve generally that's a metric or a goal something very tangible we're trying to increase the conversion rate from x to y something like that and then we map out the opportunities underneath that that is the different customer needs that people have. This is the best way I've found to map this out because often you'll have a bunch of related problems and really that might tie into a single opportunity or a single need that the customer is trying to serve and the reason they've got all these problems is because they're using different solutions to get around it today. So this is where jobs to be done is a really powerful framework to try and condense down what is that opportunity, that need that the customer has. Now that we've captured an opportunity and how it links into the outcome we're trying to achieve, we can come up with different solution ideas. And this is where you want to be wild and wacky. Come up with lots of different ideas. Once you've done that, cull it down to just a few of the key ideas you think have the best potential. And then we capture assumptions underneath that map back to those four risks that we talked about earlier. Now, those assumptions, you want to go and test them. But how do you do that? What you don't want to do is go and test every single assumption there because that'll take you forever. My go-to tool to choose which assumptions to test is this assumption map. It helps me work out which of these are most important to the customer and relevant and those which I have lots of data on or not much data on. All I want to be testing is the assumptions which are important that I'm lacking data on so I can go and validate those assumptions. Now it's time to build the actual solution. The key thing here is to do this into small chunks. You should be doing deployments at least every two weeks. I would love to see it daily. Most teams have really got this down to an art where it is a continuous deployment cadence all the way into production, write some code, commit it, and off it goes into production. That's what we call deployment. Deployment doesn't mean the customers are getting it. Then comes release, and release is when customers are getting a feature, and that might be a very limited feature set to a very limited part of the custom base in the beginning. Again, although we've tested our assumptions, none of this is a guarantee. So we're working on building on this continuously as we feed into the customer experience. The third thing that people might talk about is in a launch. And this is something that I don't like to use too much, but when you're releasing something new to a mass market, maybe you want to do that. And so it really is more of a marketing term. And this is where we've seen a lot of organizations do this, where they've launched some AI capability. They've slept it all over their product and they've released some marketing material and some videos about it. How well they've done it, it's a bit of a mixed bag. But the point is they're doing a big launch because they're trying to get attention. Realistically in product management, you want to be doing small releases all the time. Don't change. things a lot for your customer all the time in big leaps. We want to do that continuous improvement so that every time the customer gets on, there's a little bit more capability in it. There's a little bit more fun and they can learn as they go. My challenge to you when doing product discovery is release regularly. Ideally, soon as you start a quarter, within a week or two, you've got some features out in market that people are using. They might be really basic, really rudimentary versions of what you're doing, but you've got something out there. This is all about speed and through that, We're measuring the success of discovery through the outcomes the team are achieving. Not that they've done the discovery. That is irrelevant here. It's about did we solve those customers problems and does the data confirm that? There it is. That is how you start with product discovery. I want to hone this in now though on just a few tips that you can use to make your products discovery incredible. First, I just said this but it's the most important one. Release regularly. Get the features in the customer's hands. It's so important. Number two, strategic context is critical and that comes from your product strategy. If you don't have that, then you have no hope of prioritizing the right problems to solve or the right solutions to build. Anytime you're doing discovery, focus on one problem or one need. Try and keep it honed in as much as possible until that problem or need is solved. As a team, do a daily check-in. Talk about how the experiments are going, what are some of the wins, and make sure that everyone's aligned and successful on where we're headed. This also would mean as the product manager, you probably want to keep your product leader up to date on what are you working on and how is the discovery going. I see way too many teams really mess this one up. It's set a recurring time to meet with your customers. Make it weekly, make it an hour or two. And if you don't have time for that, you're working on the wrong things. Get that time in the calendar to meet with your customers. There's different ways to source customers. That can be the topic of another video, but just have that time. Don't make it a manual thing different every single week because you'll stop doing it and it all gets too hard. You can use things like AI to condense that all up. So there you have it team. There is a rapid fire class on how to run incredible continuous product discovery in your product team. If you have any questions, drop a comment below. I would love to answer them for you and check out productcoach.com.au for some incredible resources on continuous product discovery. Oh, forgot to add. That's the end of the video. Catch you in the next one.

I used to think product discovery was just a one-off sprint. Run some workshops, do a few interviews, then you’re done. Onto delivery. But that was completely wrong.

If you're a Product Manager or a Product Leader who wants to solve customer problems faster, deliver results that actually matter for the business and engage your entire team, then this is for you.

This video breaks down how to actually do discovery in a way that works – continuously, with your whole team involved, and focused on solving real customer problems. Not just ticking boxes or running more meetings.

What you’ll get here isn’t theory. It’s a practical guide to setting up discovery as a repeatable, team-wide practice that ships value faster – and reduces the risk of building the wrong thing.

Stick around to the end for five simple but critical tips that make the difference between chaotic guessing and real customer impact.

Here’s what’s inside:
Why discovery isn’t a phase and never should be
The four product risks you need to uncover before you ship
The difference between problem discovery and solution discovery (they’re not the same)
What a product trio is and why you need one
How to structure your discovery work using Opportunity Solution Trees
What assumptions are actually worth testing (and which ones to ignore)
Why fast, safe experimentation beats perfect research
When to set OKRs and how to tie them into your discovery work

And yes, I’ll also walk through the biggest mistakes I see teams make, and how to avoid them – including the one where discovery becomes a never-ending pit of research with no actual delivery.

If you’ve ever felt stuck between strategy and shipping, this video will give you a way forward.

Chapters
0:00 – The myth of one-off discovery
1:10 – 4 Big Risk for Products
2:05 – Problem Discovery and Solution Discovery
3:48 – Continuous Discovery
4:01 – 4 Discovery Principles
6:35 – Steps to get started on Continuous Product Discovery
8:33 – Solution Discovery Space
12:23 – 5 Tips to make an incredible Product Discovery

#productdiscovery  #productmanagement  #ContinuousDiscovery #BuildBetterProducts #customercentric  #okr #jobstobedone  #productstrategy