Introduction to Continuous Product Discovery | Paweł Huryn

Hey, welcome to the Continuous Product Discovery Masterclass. My name is Paweł, I'm the author, product coach and I also work as a product manager at Regiondo. I have over 9 years of professional experience and for 5 years I was running a successful startup in Poland. I am truly passionate about building customer-facing tech products, sharing knowledge and helping others, like you, grow. Are you ready for the masterclass? Great, so let's get into it right now. In product, we should be obsessed with the why question. So let me ask you the question. Why do we need product discovery? Because before I define product discovery, I would like to define the problem that we are trying to solve. Let me tell you a secret. In product management, the... Simple truth is that most of your ideas are not going to work. In Inspired, Marty Kagan even said that good teams assume that at least three quarters of their ideas won't perform as they hope. Why does it happen? I would argue that product management is in its heart about managing risk and product manager should be obsessed with five risk areas. The first one. is value. So will it create value for the customers? Will they desire it? The second is usability. Can they find this feature? If they find it, can they figure out how to use it? Viability is about can our business support it? Can different parts of the business support this solution? So marketing, sales, customer success, support, finances. Will they work for them? Feasibility is about technology. Can it be done with the current technology? Can we integrate with that external system? Can we create an efficient algorithm? And last but not least, ethic. Are there any ethical considerations? Should we do it at all? Won't it make any harm to the users or in a broader context to the environment, to the society? And unfortunately, in most cases, one of those risk areas materializes. You may know this diagram. This is Scrum framework, of course. And I must say that Agile did an amazing job when it came to delivering software in small iterations, inspecting, adapting and asking, are we building the right thing? So for example, in Scrum, we have a sprint review, which is in theory a workshop, not a presentation. So we can, together with stakeholders, inspect what has been done, we can discuss the progress and collaborate on what to do next. And this allows us to react to changes in business environment. But what will happen if we start throwing random ideas into the product backlog? So as you see, some ideas do not work, others Proof to have potential, but most of them are not good ideas. And the problem with this is that we select those ideas for the implementation. We go through the whole cycle and when the idea is ready, when everything is implemented, when definition of done is fulfilled. So just before idea is ready to be released, we find out that this idea doesn't work. it was not a good idea. And some may say, yeah, Paweł, but is it really a problem? Sprint is like a week or two, so the risk is limited to the length of the sprint. And of course, this is true, but this will happen every sprint. So every sprint, you select some ideas for the implementation, you work on them, you deliver production ready increment, and most of the work is waste and rework and this is agile learning by delivering another issue is that the best ideas might not even be on the list so we have some ideas that have potential but can it be done better are there any better ideas that we have not think about we don't know and we would like to know how can we first came up with better ideas and how we can validate those ideas before the implementation so that the risks related to value, usability, feasibility, viability and ethics are addressed before we start working on those ideas. Ideally, we would end up with a validated product backlog and the answer is product discovery. Today, We will focus on continuous product discovery, which is a special type of product discovery that you perform for an existing product. Jeff Patton and others in the agile product space have been big proponents of an approach called Dual Track Agile or Dual Track Development. In this setup, there are two streams that run in parallel. The goal of product discovery is to discover the product to build and product delivery aims to deliver this product to the market. And what is essential here is that this is not a waterfall. So those activities run in parallel. For example, every iteration, the core product team discovers some ideas, talks to the customers, validates those ideas and the same team is working on delivering some ideas to the market. And there is this common misconception. Some say that product manager decides on what to build and software engineers, designers, they should just focus on how to build it. Have you heard that before? It hurts my ears. Because product discovery is not a task for a single person. In continuous discovery habits, Teresa Torres introduced the concept of the product trio. I deeply believe that instead of building silos with stage gates, we should embrace a collaborative approach. So make sure that product designer and at least one engineer are included. This will let you build a shared understanding within a team and stay open to different perspectives. And if we believe that customers don't know how to solve their problems because customers are not experts in technology, why so many people believe that product manager can do it? Product manager can be tech literate, but product managers are not technology experts. And I have repeatedly found that the best ideas often came from engineers because they are the experts. in the enabling technology. So what's inside product discovery? There are two groups of activities. You may recognize this diagram. This is a Dibble Diamond from Design Thinking. And the first group of activities is exploring the problem space. Within exploring the problem space, we first would like to discover, collect information. So this may be done by performing customer interviews. You can utilize product analytics, interview internal stakeholders, perform some surveys. And once we collect information, we would like to structure, to define our knowledge. And my favorite approach is by using Opportunity Solution Tree by Teresa Torres. And once we have a specific problem, we would like to explore possible solutions. We would like to brainstorm. We would like to think about different ways. of what can we do to solve this specific problem. And then we would like to formulate testable hypotheses related to those ideas and run experiments to prove or disprove them. And the outcome of product discovery is a specific validated solution idea. So it means that risks related to value usability, feasibility, viability and ethics are addressed. Even though product discovery, I would argue that this is the most important area for product manager, especially for an existing product. Continuous product discovery is what you should spend most of your time on. Many people struggle after reading books how to implement the theory in practice. So the basic tool that you can use is already mentioned opportunity solution tree. This is proposed by Teresa Torres in continuous discovery habits. And what you can see on the top is some product outcome. Product outcome is the goal. It can be expressed, for example, as an objective key result. But what's important, this is the goal that the team can directly influence. So it's not about growing sales. It's not about reducing costs. It's not about those high level business objectives. This is something that if you work in a core product team, this is what your core product team can directly influence by your product efforts. So, for example, if you want to increase sales and this is a sales growth model, the goal for your core product team may be to increase engagement. That's just an example. And then we start interviewing customers. And Teresa Torres recommends that we should interview our customers at least every week. And this is done by the whole trio. Marty Kagan is even more rigorous about this because he says that if the whole trio is not present, we should cancel the interview. Regardless of your approach, the goal is to first understand customers and then map problems that way that they have, but not any problem that they can mention, but the problems that when solved will drive the expected outcome. So we are focusing on increasing engagement by 20% and the way to do it is to solve specific customer problems. And one of the problems for a web video platform may be that the person cannot find anything to watch and if we ask additional questions it might turn out that they cannot figure out how to search for a specific show. So there is this structure of opportunities. We call them opportunities, but those may be problems, needs, desires, pains that people have. And then we ideate on how to best solve those problems. So for example, one of the idea for a person that cannot figure out how to search for a specific show, maybe displaying a simple search box. Another one might be a recommendations engine. Once we have those ideas, we would like to identify what needs to be true for this idea to work. So this is about identifying risks related to value, usability, viability, feasibility, and you can also think about ethics. The one way to do it, and I will also present it in a moment, is to use user story map. But once we identify those assumptions, we can design and run experiments. You can do it in Mario, you can do it in PowerPoint, you can do it even on paper. But I would like to show you the template that I am using and this template is available as part of product management resources. You can go to the PM resources and duplicate my Notion collection so you will have access to editable version. And the approach that I will present combines three techniques. So one is Opportunity Solution Tree, of course. Another one is Opportunity Score Formula by the Nolson, and we will use them to prioritize problems, prioritize opportunities. And the last element is Strategizer Testing and Learning Cards to collect information, plan our experiments and select which experiments should be performed and which can be perhaps ignored.

Product Discovery is the most important area for a Product Manager. 

But it’s largely misunderstood. Teams struggle to implement the theory in practice. And waste time and energy delivering ideas that don’t work.

I prepared a free course, Introduction to Continuous Product Discovery, a shorter version of my full course.

Let’s get into it right now:

1. In case you don’t know me (00:00)

2. Why do we need Product Discovery? (00:38)

From this part, you will learn:
- The problem with new ideas.
- 5 risk areas Product Managers should be aware of.
- Why learning by delivering is not a good idea?
- Why do we need Product Discovery?

3. Continuous Product Discovery (05:45)

From this part, you will learn:
- Dual Track Agile and Continuous Product Discovery.
- What is the Product Trio, and why does it matter?
- Design Thinking and Continuous Product Discovery

4. Opportunity Solution Tree (09:56)

From this video, you will learn about Opportunity Solution Tree, as defined by Teresa Torres.

Hope that helps!

- - -

Continuous Product Discovery Masterclass is a self-paced video course.

For more information, visit the course website:
https://www.theproductcompass.tech/cpdmasterclass

Or become a premium subscriber to access the course for free:
https://huryn.substack.com/p/cpdm