Product Discovery - How
Product Discovery - How
How To Do Meaningful Product Discovery
We visited the local aquarium a while back. It is one of our kids’ favorite places, so it’s been difficult not to go there more frequently since Covid-19. As we were leaving, we let the kids each pick out a souvenir. Our daughter picked a stuffed animal and our son picked a jelly fish lava lamp. As we were checking out, my wife chatted with the salesperson about the lava lamp, asking how it worked and such. And that’s when we got some advice we never would have learned without this conversation. She mentioned that they work great, but only if you add dish soap to the water to keep the jelly fish moving. And you need to add a few drops periodically to keep them moving smoothly. My wife told her that was good to know and thanked her for the advice.
When we got home, sure enough, the jellyfish did not want to swim well. I tried followed all the instructions, but had forgotten about the advice we received at the gift shop until I had exhausted everything else. Then I finally remembered to add dish soap to the water and everything operated much better. And when the jelly fish stop swimming, we add some more.
Having a small conversation often yields significant results. If we hadn’t asked, we would have ended up frustrated trying to use my son’s toy. But asking a few questions gained us the insight we needed for an exceptional experience.
We’ve been talking in the past few newsletters about product discovery. You can check out Product Discovery - What & Why as well as Product Discovery - Who and When to catch up.
In this post, I want to address how we can go about doing discovery work. This includes some principles I’ve used and some common frameworks others have developed, as well as one I’ve used loosely in my own work.
Principles
Understand the problem deeply — Discovery and research starts with understanding the problem deeply. The old product management adage of falling in love with the problem is exactly right. Don’t fall in love with your solution, fall in love with the problem, or at least deeply understand it so you can get to the right solution.
Talk to people — You need to get out and talk to your users. Let the data inform you. Look at surveys and dashboards and metrics. But you have to talk to people to do proper discovery. There is no way around it. You won’t know that customers are using your product differently than you ever realized if you don’t talk to them.
Make it visible — just like we fill our backlogs with development tasks, we need to make the discovery work visible. It should be part of each sprint, discussed as a team and given space just like writing code. It is just as important. Treat it that way.
Shorten the time to value — Like I mentioned last week, the purpose of discovery is to validate our ideas as quickly as possible. Rather than spending months developing a product only to find that users don’t need it or want it, we should spend days validating it in discovery to figure that out. We need to shorten the time to value through discovery and research.
Prepare to be wrong — If you always validate that you are right, something is wrong with your process or with your assumptions. You can’t and shouldn’t always be right. You need to disprove some hypotheses and prepare to be wrong. But that is part of the beauty of the process. You will be wrong quickly and move on to better, more correct solutions.
Drive outcomes — Discovery isn’t about just learning and doing research. It is about creating solutions that customers want and that will create value for your business. So you need to drive outcomes for users and for your company.
Test and improve — You may not be good at discovery and research practices, so keep testing out what works and what doesn’t. Refine the skills and practices and continually improve.
Make time all the time — Discovery should be an ongoing activity along with product development. Make it visible with your development activities. Get everyone involved. Share your findings and how they are improving your outcomes and driving your results forward. That will not only increase credibility, it will help others with the practice as well.
Discovery Frameworks
Design Thinking
Product discovery aligns closely with design thinking.
I like the model that the Neilson Norman Group has popularized, as shown here. The main phases of design thinking, and of product discovery, are understanding the problem, exploring solutions, and materializing those solutions.
There is a lot more that goes into each of those phases, which I’ll explore more in-depth later, but this is an excellent framework for thinking about design and discovery work for our product development.
Problem & Solution
Similar to design thinking, Tim Herbig offers another framework that separates out the problem space and the solution space.
Many of the components are like the ones above, namely that we need to understand and research the problem, then start ideating and creating solutions, along with validating and refining them.
Conceptually it is helpful to separate out the problem space and the solution space, but it is important to remember that they are going to overlap in product development and within the team. No one should own the problem in a silo and then handing off their findings to someone else for a solution. That’s not how excellent products are built and not how talented teams function.
Understanding to Outcome
Another framework I’ve used loosely is the idea of developing understanding to create experiments to find solutions to problems that drive outcomes.
Like I mentioned in previous posts and other articles, the purpose of product discovery is to create solutions to real problems that will create value for users and our business. So the result needs to be outcomes. That’s the whole point. What we start with understanding users, the market, and our business. We develop a deep understanding of the problem. From there, we create experiments to solve the needs we’ve found. Once we’ve experimented, we implement our solutions addressing the problems or needs or gaps. And this drives the outcomes and creates value. All along the way it is also feeding back, informing our decisions so we’re building and learning at each step.
Regardless of the framework, the principles are similar and revolve around the same set of ideas. We need to understand our users, understand the problem, test our ideas and get feedback often.