Product Discovery Fundamentals
How to use discovery to avoid building features no one wants or needs
You’ve seen it happen: someone on your team has a great idea for a new feature—it’s obvious to everyone that this will help your users and make money for your company. So your designer spends weeks crafting designs that are intuitive and match your product’s brand. You even take time to usability test a prototype. Your engineers then spend months building and testing until the new feature is ready. It is released into the world. The result?
Crickets.
The metrics show that no one is using that feature that you thought would change your users’ lives for the better. What happened? And better yet, how can we avoid it?
Many of us (including me) have worked with teams who have spent months, sometimes years, creating pristine back-end architectures and innovative designs for products that were flops. Why? Because the product didn’t fulfill a need or desire that people have.
Or maybe the feature couldn’t be executed well, or the version that ended up getting shipped was so scoped down that it didn’t provide the value that users actually wanted. Whatever the reason, my hope is that I can help teams avoid making this mistake.
One way to avoid launching features and products that no one wants is to use a process called Product Discovery. Its goal is to help us come up with better ideas in the first place based on what our users actually desire and need and throw away the ideas that won’t succeed before we start building them.
Product Discovery as a process was created by Marty Cagan from Silicon Valley Product Group. As he explains, going through the process helps us to answer four questions:
Will our target audience use this product or feature? (Is is desirable?)
Can they use it? (Is it usable?)
Can we build it? (Is is feasible?)
Can we support it? (Is it a viable business for us?)
These questions are extremely important to figure out before your team starts debating UI colors or writing any code; yet many teams fall in love with their ideas and don’t bother to test their assumptions. Or they are handed a list of features to create by upper-level management and aren’t given the time or ability to question and test whether these are the right things to build.
Product Discovery has four crucial phases that a team must go through in order to decide what to build. They are:
Frame: defining and scoping the problem or idea
Understand: getting to know your users’ pain points, needs, behaviors, and desires
Envision: coming up with many potential ideas or ways to solve the problem
Focus: selecting one or several ideas to test in the real world
If you’ve done Google Design Sprints, these phases will seem very familiar. And if you’re a designer, you might be thinking that this process sounds very similar to Design Thinking, which also asks whether products are desirable, feasible, and viable. They are all very similar processes, which I think is a positive because it means there is fundamental agreement on how to build successful human-centered products. So, I’m not here to argue that any of these processes is better than another. Each one has a different emphasis (and in the case of Design Sprints, a different timeline). What’s most important is that each process shares a focus on learning from and empathizing with the people who will use your product.
It’s important to note that during the discovery process, you are not building a production-quality feature that can be shipped to all of your users at scale. What you will have is a validated, well-formulated idea that you can make into an MVP to launch and then continue learning from your users. This will save you time and money in the long run, because even an MVP takes time to build; going through discovery means you won’t be building features and products that your users will ignore or dislike.
In addition, going through the Product Discovery process will actually help your team throw away many ideas. You should be throwing away more ideas than the ones you actually build; that’s a sign that you’re generating lots of concepts, (which is good!) but you aren’t falling in love with them before finding out whether they pass the four-question test.
Let me give you an example of a feature that we threw away while I was working at Trustpilot.
A quick mockup that we used for concept testing
We had the idea that people using our business product might want to connect their Facebook page to their Trustpilot account. Seems like a no-brainer, right? We tested this idea by creating a quick mockup and asking our users during interviews what they thought about it. The response was negative: people in our target audience did not want to or couldn’t connect their company’s Facebook page to our business product, or they had a lot of questions about what would happen if they did. The reasons varied—for example, some of our interviewees just didn’t have access to their company’s Facebook page, while others worried that they would accidentally connect with their private Facebook account. This was great information, because it meant we needed to go back and rethink our messaging and audience. We didn’t waste time having our team create this feature and then find out it wasn’t being used.
If we had gotten positive feedback from the concept tests, our next step would have been to implement the feature in our product as quickly as possible, using throw-away code and designs (it’s just a test, so no need to make things perfect). We would have shown this new feature to a small percentage of our users to see whether people actually used it. If so, then we would have built it out with full attention to design and code quality in order to launch the best possible feature to all of our users. This type of phased, test-and-learn approach ensures that you don’t spend too much time on creating perfect production-level code or designs for a feature that you will end up throwing away.
As a designer I like Product Discovery partly because it has a similar process to Design Thinking and Human-Centered Design and it shares many of the same methods. Product Discovery, however, takes things further by also focusing on the business side of creating features and products and emphasizing the importance of both qualitative and quantitative feedback. This is important because what people say is often different from what they actually do. And personally, I want to know that my designs are creating real value for people and for the company I work for.
I also love that Product Discovery inherently brings designers, product managers, and developers together as equal partners working toward a shared goal. In my experience, this always leads to better products because each role has valuable expertise. By simply following the process, no one role gets overlooked.
Illustration by Jeff Patton representing Dual-Track Development
Many companies working on digital products are already doing agile in order to build their products. To do Product Discovery well, often teams will use a process called Dual-Track Agile (sometimes called dual-track development; these term were co-created by Marty Cagan and Jeff Patton). Basically, a normal scrum team will focus on development (building and shipping software); with dual-track we add another “track” of people focusing on discovery (learning and experimenting). My experience with Dual-Track Agile has been positive and I’ve seen it work very well for teams—if you want to learn more, here’s a great in-depth post by my former colleague from Trustpilot, Jacob de Lichtenberg.
However, if you’re just getting started with Product Discovery and are overwhelmed with the idea of learning how to do dual-track (or don’t think you could convince your coworkers to make it happen), don’t despair! You don’t have to formally change your entire development process in order to start getting some of the benefits of Product Discovery. Instead, you can experiment with trying out some Product Discovery methods at a small scale first. In the same way you test out new ideas with your users, start small and expand in stages when you see success signals. For example, you might simply try doing one discovery method with your team that is appropriate for where you are now in your process.
Crazy 8 sketching helps us rapidly ideate without censoring ourselves
Are you just getting started with a new idea for a feature? Use a method or tool that helps you frame the problem, such as an opportunity canvas. If your team already understands what your users need, you’re in the Envision stage. You might come up with ideas using a quick-ideation method such as Crazy Eights. Once your team starts seeing success from using discovery methods, then you’ll be more likely to convince everyone to go through the entire process, and then to try out a new structure such as dual-track development.
You can learn much more about Product Discovery on the Mind the Product website, which has all kinds of helpful articles and videos from past conferences. I will also be writing more articles on the details of my favorite discovery methods, as well as more on how designers can uniquely contribute to Product Discovery. If you’re ready to stop wasting time designing and building features no one wants, I highly encourage you to give it a try!
If you want to learn the basics of Product Discovery along with a few methods you can immediately use, check out our 90-minute class, Intro to Product Discovery.
