Product discovery is a process to define a product that is valuable, useful, and feasible.
There are two key elements of the Product Development cycle: Discovery and Delivery. Many teams are focused on the Delivery aspect of this process, which is supported by tools like Jira, Github, Asana, Trello, and many others. However, a strong product or feature development cycle will begin with understanding the need of the customer and the problem being solved. Product discovery and validation is the process by which product teams, UI/UX Researchers, designers, innovators, and entrepreneurs figure out what they should build and if people will actually want to use it. It is a critical process to increase the likelihood of success for any new product or service launch. The specific steps include problem definition, exploring, solutioning and prototyping. In product-driven organizations, there is a continuous cycle between discovery, to figure out what to build or how to improve existing features, and delivery, which actually gets those products and features working.
One of the top reasons that 80-90% of startups and new product launches fail, is because they are creating a product that no one wants or needs to use. Instead, products should be created to solve a problem that a large number of people need to be solved. Otherwise, you run the risk of dedicating significant amounts of time, money and human resources on a product that no one will ever use. This page outlines key concepts and real-world examples of successful product discovery and validation.
Modern product discovery and validation really began with Steve Blank’s Customer Development in the 1990s and his first book, The Four Steps to the Epiphany: Successful Strategies for Products that Win. This thinking led to the Lean Startup movement and Customer Development became part of the three main pillars of a lean startup.
In parallel, Anthony Ulwick was developing CD-MAP at his newly formed consultancy The Total Quality Group. This evolved into Outcome-Driven Innovation®, which in turn gave rise to the Jobs-To-Be-Done theory.
Today, product research, discovery and validation has been essential to the success of tech companies, from Amazon to Airbnb. The process of product discovery and validation has an outsized impact on whether or not a new product will succeed or fail. In fact, Ulwick claims that while traditional innovation processes yield a 17% success rate, ODI achieves a stunning 86%.
In the years between 2000-2015, these processes and strategies aimed at startups and enterprise innovation teams respectively began to merge with product management and development thinking like agile software development. Regarding “product validation” specifically, Marty Cagan of the Silicon Valley Product Group wrote this seminal post on the topic in 2005 and the term has grown in popularity since.
Today, much of the recent thinking applies equally to startups, product teams, and enterprise innovation teams.
In the past, companies would often make one of several new product development mistakes:
There is no shortage of product management theories and practices. Today, the more common practices blend elements of agile, design thinking, lean, and other famous strategies.
In his book Competing Against Luck, Harvard professor Clayton Christensen proposed the Jobs-to-Be-Done approach to building products, which was built upon Anthony Ulwick’s Outcome-Driven Innovation. According to Christensen, people don’t buy products, they hire them to do a specific job. This goes hand-in-hand with product discovery - products need to fulfill a specific use case. As shown in the graphic below, solutions can change dramatically in the pursuit of better solving the same job-to-be-done. Products can also serve several disparate jobs, like flares serving both “detect enemy at night” as well as something like “warn oncoming traffic about road hazards”.
JTBD helps product teams validate or invalidate crucial assumptions about customer segmentation, needs, pain points, use cases, etc.
To validate a product, you need to understand your customers. Customer development should, therefore, be the first step in your product development process.
Effective product teams may start with a list of assumptions, but it serves as a jumping-off point. From there, it is essential to validate or invalidate all assumptions with thorough research, iterative tests, experiments, and data. This is the phase where many pivots happen. Product teams may find that their idea appeals most to a customer segment that they had not considered. Or that their assumption about the key segments was correct, but that the solution the product team has in mind is not ideal for that segment.
Here are some commonly used tools, called design artifacts, that help you understand your customers better:
These tools can deepen understanding of the customer and lead to more useful products. Furthermore, having a deep understanding of customers helps trigger ideas in the product discovery and validation process.
There are numerous methods and approaches to product discovery, but most encompass these four phases. As you can see from the graphic below, these four phases have a lot in common with modern design thinking.
What jobs do users need done? What problem needs solving most urgently? This is where you lay out all your assumptions and goals. Develop a shared understanding of the customer needs. Empathize with the customer. This is where artefacts like Customer Journey Maps come in.
What solutions are out there? If there isn’t a solution, what do people do instead? Start thinking about what solutions you can offer and sketch possible options. Gather and conduct market research as well as customer research.
Choose which solution is best for the problem and start mapping out exactly what the product’s user flow would look like. Storyboards can help visualize the product.
This is where many companies would begin to formulate a minimum viable product (MVP). That MVP would be released to a sample set of target customers and then the company would use feedback from those early users to help drive the evolution of the MVP. As you’re building the MVP, the team should be listing and prioritizing assumptions, then conducting experiments to validate or invalidate the hypotheses that derive from those assumptions.If the product is a piece of hardware or some other tangible good, this is also where prototyping may be a good approach. Create an early version or prototype of the product based on the storyboards and mapping. Then, test out the prototype with focus groups and other members of your target audience to gain feedback on the experiences, issues and other concerns before the product goes to market.
Minimum Viable Product, or “MVP”, is what most product teams seek to test. It focuses the development team on the core attributes of their eventual fully-featured product. In doing so, it also allows for incremental validation before the team invests too many resources only to find out the demand for their fully-featured product doesn’t exist.
Many people criticize the MVP approach saying that is often taken too far, leading a team to release a product that is so minimal that no audience would ever love it. This can lead to negative brand equity, which becomes very difficult to overcome. A rebranding may even become necessary.
There are specific tests that should be considered to validate a product before it gets the green light: feasibility, usability, and desirability.
These three phases are visually represented on the business model canvas:
Jeff Bezos is known for leading with a Day 1 mentality. Outlined in a letter to shareholders, Bezos says being customer obsessed is the key to the e-commerce giant’s success.
“There are many ways to center a business. You can be competitor focused, you can be product focused, you can be technology focused, you can be business model focused, and there are more. But in my view, obsessive customer focus is by far the most protective of Day 1 vitality.”
This is why Amazon starts with the customer first and uses a “working backwards” process when proposing new ideas. To validate a product’s viability, individuals must write a PR FAQ, which consists of one-page press release and the most anticipated customer questions, which outlines the problem customers face and why the product will offer a compelling solution. In this case, the product hasn’t been created yet, but it doesn’t matter. It’s all about the customer. It forces individuals to think about the product’s value proposition and pitch for customers.
If the press release doesn’t excite readers, it’s likely that the product isn’t something that they should create. Before launching their cloud computing arm, Amazon Web Services (AWS), current CEO Andy Jassy went through 31 different drafts of the proposal before presenting it to Bezos. It may seem excessive, but the cost of rewriting press releases and reworking your ideas is much less than the cost to redo code or products.
In addition to writing a press release, Amazon requires six pages in the format of Frequently Asked Questions (FAQs). It anticipates questions that customers might face when using the product or service. This also lays out other details of the product, which helps the team understand how it will work, and answers some of the non-customer driven aspects of the idea.
A product doesn’t need to be released yet in order to test its viability. There are a number of ways to do discovery on a product without ever writing a line of code or building something. For instance, Dropbox founder Drew Houston published an MVP explainer video about the file-sharing service on Digg and got over 70,000 sign-ups. Even though the product wasn’t released yet, from the video and other online sign-ups, they knew that they had a substantial number of potential users and market demand to move forward. All they needed was to show the benefits and value propositions of the idea. Other examples of this are creating a sample report that represents the output of a product, Concierge and Wizard of Oz tests, or wireframes of a process.
The hard truth is that most product and feature launches don’t live up to expectations. Most of the time this results from a failure in discovery rather than a failure in delivery. GLIDR puts discovery and validation at the center of your roadmapping process so that you can ship products that matter.
GLIDR helps keep product development grounded in customer research and hard evidence from experimentation, so that companies and product managers make better, smarter decisions. Entrepreneurs and innovators can validate their ideas by planning, running and analyzing product tests in GLIDR and easily share results across teams and stakeholders.
Teams of all sizes across the world use GLIDR to validate their ideas and business models. GLIDR is built upon the lean startup methodology of shortening feedback loops through iterative experimentation, and helping teams capture insights during the Discovery phase of bringing a new product to market. Innovators and product managers can more quickly arrive at a better Minimum Viable Product and a more attractive business model.
Learn more about GLIDR's core features here and try GLIDR today.
The Lean Startup by Eric Ries
Inspired by Marty Cagan
Jobs to Be Done by Anthony Ulwick
Dropbox MVP Explainer Video by Drew Houston
The Evolution of Modern Product Discovery by Teresa Torres
Cognitive Biases & The Questions you Shouldn’t be Asking by Cindy Alvarez
Working Backwards by Hiten Shah
Silicon Valley Product Group Insights
Product Talk by Teresa Torres