Product Discovery
I would hate to lose $1 billion dollars.
Quibi, the short-form video streaming service, announced recently that they would be shuttering. I know little about Quibi. It looked interesting, but was never something I’d pay for personally. Their timing was not great as we entered the pandemic. But most strikingly, they raised and spent over $1 billion dollars before making real contact with customers. As a product manager, that strikes me as terrifying. It’s a colossal risk to not validate your idea before going so big.
Which is the point of product discovery. To vet our ideas iteratively to avoid catastrophic failures. So let’s put all the pieces together.
What & Why
The purpose of product discovery is to understand user and customer problems so we can create compelling, meaningful solutions.
Product discovery is fundamentally about understanding as early as possible if our ideas are good for users and for our business. It is meant to reduce the risk before we go down the wrong path.
Product discovery and user research are some of the most critical parts of product development. There is no other way you can understand what your users need, the genuine problems they are facing based on actual feedback and evidence from the field, and what you should focus on for potential solutions.
It is important because it allows us to validate not only that users care and it is worthwhile and doable for our business, but to do all this before we commit ourselves, along with massive time and energy and money, to a specific path.
For an in-depth analysis of all the what and why, look at my previous post and newsletter on Product Discovery - What & Why.
Who & When
When should we do product discovery? My simple answer is that we should always include discovery work as part of our process.
As long as software has existed, we’ve been doing some form of “discovery” to understand what we should develop and send to users.
With modern product development and modern product teams, we have largely moved away from the need to ship once a year or once every six months (though I realize that’s not the case everywhere, and I send my sincere condolences).
With that comes the need to shorten our discovery cycles, making them work continuously with our development cycles. This should make sense. If we were releasing software once per year, our discovery may take 4 months followed by 6 months of development and 2 months to prepare and release. If we shortened that cycle to every 6 months, then we’d need to shorten our discovery to a month or two. Keep shortening the window of delivery, and we’d keep shortening the overall cycle like in the image.
In the past, discovery and development were typically separated. But now they can run in tandem, and should run together as we are continuously doing user research and product discovery as a product team (product managers, UX designers and engineers) while also developing and releasing small increments of our product to users. This way we are continuously learning, continuously improving and continuously launching.
A VP of engineering recently asked me who I thought should be involved in product discovery. The answer can vary from company to company depending on team and structure. But at its core, we should always have our product manager, UX designer, and engineering lead involved in our ongoing product discovery and research. If you’re fortunate enough to have dedicated user researcher as well, then you’d want them involved too.
It may also be good to periodically expand this core group and involve others. That may include additional members of the development team for their insight, members of your sales team or client management team, members of your marketing team, and other key stakeholders as needed. Depending on the area you’re working in, partners in each of these groups may offer key insights in your discovery process. I’ve found outstanding success adding people from our support groups or other areas when we are doing discovery (interviews, discussions, etc) directly relating to their area of expertise.
Finally, it may occasionally be good to invite senior leaders to some of your product discovery sessions. I’ve had mixed success with this. Some senior leaders are very interested in seeing and hearing what users have to say while others don’t have time for it. Often the best thing to do is to package what you learn into bite-size chunks and summarize so you can inform everyone and give a sample of what you’re learning without involving executives in the full sausage making.
For more on this topic, take a look at my post on Product Discovery - Who & When.
How
Now that we’ve covered who, what, when and why, we need to talk about how we accomplish good discovery using some fundamental principles and frameworks.
Principles
Understand the problem deeply
Talk to people
Make it visible
Shorten the time to value
Prepare to be wrong
Drive outcomes
Test and improve
Make time all the time
Frameworks
There are a variety of frameworks that are useful when thinking about product discovery. From design thinking to separating out the problem and solution space, these are popular ways of breaking down discovery. 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.
For more discussion of this topic, take a look at my post about Product Discovery - How, and don’t forget to subscribe to get the weekly updates!
Discovery Tools & Techniques
Customer Interviews
If you do nothing else for product discovery, get out of the office (either figuratively or literally) and talk to your customers and users. Watch how they are using your products. Ask questions. Get feedback. Even if you have nothing new you’re trying to learn, you will undoubtedly learn a great deal you didn’t expect.
Early Adoption Groups/Advisory Boards
Whether formally or informally, create a group of users who will give you feedback on your ideas and products. Not all of your customers want to be your early adopters, but chances are there are some who want to be on the cutting edge of your technology and influence the direction.
Future Press Releases
I’m a big advocate for the future press release. The idea is to think ahead to the launch of your product or major feature, before you even begin work, and write a press release as if you are announcing it to the world. How is it a game changer for users? What has it done for the business? How did you get from here to there? What are people saying about it? It forces you to think through some interesting and difficult questions to decide if it is worth pursuing.
User Story Mapping
The idea behind user story mapping is relatively simple. What is the story behind your user’s journey through your product? What are they doing? What problems are they solving? What is the actual story in human terms?
I love the book User Story Mapping by Jeff Patton. It is a great place to start if you want to use this technique for your products.
Lean Canvas
When I’ve started big new initiatives, I’ve frequently used lean canvases to lay out our ideas in a simple but powerful format.
The format is pretty simple and asks you to fill in 9 boxes including things like customer segments, the problem, revenue streams, key metrics, etc. Each box is meant to deconstruct your idea (or product or feature) into its key assumptions.
Design Sprints
A design sprint is a way to uncover a problem, decide on a potential solution, prototype it and test it, all within a brief time, typically a week. I’ve used the same principle for shorter sprints as well, taking ideas, refining them, putting together a prototype and testing it out within a day or two for smaller things. It’s a great tool for your arsenal.
The book Sprint is a great place to find out more.
Of course, for more on this, I’ve got a whole post on Tools & Techniques.
Product discovery is critical. You can’t know for certain if your ideas are good until you test them out. And you can’t know how customers are using your product until you go talk to them and see what they are doing. There are numerous tools to help you with your discovery practices, and these are some of my favorites and the ones I’ve used most often. I hope they inspire you to do more of your own discovery and start changing your products for the better.
Best of the Rest
Continuing Development As Product Managers and Designers (Podcast) - It's critical we continue our learning and development as product managers and UX designers. But it can be hard when our jobs take up so much time day-to-day. What are some of the best ways to continue professional progression? We dive into that topic and more on this episode.
Discovery - Delivery (article) - As if reading my mind, Marty Cagan also put out an article today around discovery and delivery. In my experience, I couldn’t agree more. Separating discovery and delivery doesn’t work and everyone pays a high price eventually.
Top 10 Product Discovery Mistakes (article) - Product discovery ensures we do the right thing for our business and our customer, but if we only do discovery for its own sake, or others don’t understand the value, it will fail to answer the “so what”. This is a good article on common mistakes in discovery.