The Product Discovery

Whatever you do: Document, share, ask for feedback, iterate and improve.

Jul 18, 2021

Product discovery is a method of deeply understanding your customers to develop products that perfectly suit their needs. It’s a critical stage in the product development process because if companies do not accurately prove or disprove their assumptions about their customers, they may waste time building products that nobody needs. Product analytics software is key to product discovery.

The product discovery process is important because it helps teams build products that are vital to their customers, not simply nice to have. A necessary product is one that solves such a deep and genuine need for the customer that they feel unable to live without it.

In order to be effective, discovery should be broad and technology- or solution-agnostic. When teams carry out a discovery on a product they have already decided to build, it no longer is a discovery, but, instead, it becomes a requirements-gathering exercise or a validation exercise where teams seek to confirm that their solution is the best.

The discovery is off track when teams are asked “How do we make [insert name of solution] work for users?” or told to “Go find out what the user needs are for [insert name of solution]”.

A discovery should start with a broad objective such as like: “Go find out about this problem, just how big it is, and what the opportunities might be.”

Well-done discoveries ensure that any solutions proposed later are desirable to users, viable for the organization, and feasible with the technology made available.

Discovery :

Every product journey begins with Discovery. This typically happens over a fast-paced, two-week period during which we learn as much as possible about the product space, the business drivers, any existing technology or technical constraints, and the users. During the Discovery period, teams prioritize the key problems that represent the highest business and user value so that they can use this information to inform potential solutions.

There are three necessary actions for Discovery:

Identify your assumptions A business often begins Discovery with an opportunity or business problem they’re looking to solve. This is a strong starting point. However, it’s even more critical to validate that a solution has the desired outcome, is valuable to users, and is feasible to deliver. To do this, the full balanced team works together to build a shared understanding of the business, user, and technology motivations that make up the problem space. For example, they may talk with stakeholders about their desired outcomes and the problems they believe they’re solving (and for whom). The team may also conduct an exercise with a wide array of stakeholders and subject matter experts to identify any assumptions held about the problem space. These assumptions—particularly those that pose the most risk to product success—are key to guiding research efforts.
Gather Evidence and Validate Once the underlying assumptions have been identified, we engage with end-users and subject matter experts to validate or invalidate those assumptions. We use methods like 1:1 interviews with users or contextual inquiries (i.e., observing users). While these methods can often comprise much longer research efforts, our focus is specifically on validating key assumptions. This means our research can be simultaneously efficient, effective, and directional—at times requiring only a handful of users to identify trends. At this stage, the team has likely seen and heard user comments that both confirm and conflict with their initial beliefs. To avoid confirmation bias, it’s important that we step back from our personal feelings and look objectively at the notes taken in each session. By looking across all of the research data and synthesizing it into key insights, patterns, and problems, we can determine if we have sufficient evidence to validate our riskiest assumptions and avoid narrowly focusing only on the findings that resonate with us personally.
This stage of activity is particularly exciting because it helps us discover things we didn’t know that we didn’t know—surprising challenges or user desires that can help us create meaningful and delightful solutions. A word of caution: one common research pitfall is to jump into “solutioning” too quickly.
For example, we may get excited about building a possible feature or product and let that potential solution blind us to other, more interesting directions. As much as possible, we want to stay focused on needs, challenges, and behaviors during this stage.
Prioritize the key problem to solve the Discovery process will have uncovered various validated user problems and invalidated myriad others. Solving any of these problems could create value for the user and the business; however, that value will only be recognized once we deliver a solution. Products often fail when they don’t solve a real user problem, but they can also fail when the team making them attempts to deliver too many solutions. Prioritization is the best way to mitigate that risk. Unfortunately, prioritization can be difficult because problems are often interconnected and our empathy for users biases us toward taking on as much as we can. We can break through this by employing a prioritization framework, like the 2x2 matrix that helps balance key decision-making factors. Ranking the problems by their relative business and user value is a great way to begin the decision-making process. A team that’s shared the experience of interviewing stakeholders and users—and has synthesized those learnings—is well-positioned to do the hard work of discussing this critical dimension.

Define

After we have prioritized the first problem to solve, we’re ready to move into Framing. During this period, many potential solutions will be explored, evaluated, and iterated. As we move through the phases, we’ll continue to discover new information about our users and the technology we’ll use to deliver our solution. Framing is about answering the initial questions of solution direction so we can start building the product and get it into users’ hands.

We break this into three main action areas:

Explore many solutions For almost any problem, there’s a variety of solutions. Looking back at the insights and evidence gathered from research— particularly those that helped determine whether or not a risk assumption was validated—is important for refocusing the team.
Although our focus on a single, validated problem is narrow, finding the solution requires us to go wide. At this stage, we aren’t trying to design the entire product, but rather generate many possible solutions that address the single prioritized problem. Collaborative sketching exercises—like Design Studio—are one way to use the collective creativity of the team to quickly generate many options for key features. At this point, a solution may not be a software design concept. Business processes, services, technical architectures, and other approaches may provide a better solution than software, and those opportunities should be explored.
Focus on a high-value starting point Moving quickly isn’t about how fast you work—it’s about how well you prioritize what you need to build and deprioritize what you don’t. We do this by creating a prioritization framework for the features we’ve identified. We may use the same framework we used to prioritize problems: weighing user value against technical complexity and looking for a high-value, low-complexity starting point. Other times, we may choose to tackle a more complex technical element early because it meets our criteria of reducing the most risk while delivering the most user value. We build the highest value core functionality pared down to its simplest form in order to validate that the most important aspects of the product work with the least amount of effort. From here, we can begin evolving and iterating the product based on the initial high-value feature we’ve validated.
Run experiments to validate concepts As we move through the product design process, we continually generate ideas that we believe can deliver real value for our users. As exciting as that is, these ideas contain assumptions. Some are low risk and easy to iterate on; others are high risk, and if we’re wrong, we might build something of little value and waste a huge amount of effort. We use Lean design experiments to reduce those big risks. Lean experiments are structured, short learning activities for testing our ideas and assumptions. They set out to validate the “leap of faith” (i.e., the riskiest) assumption about a specific hypothesis in the quickest, cheapest way possible. At the end of the experiment, the team will know whether or not their solution addresses a real end-user problem and will have gathered even more learnings about its users. Lean experiments have the added benefit of reducing the cost of failure. This creates an environment of increased psychological safety for the team in which trying out new innovative ideas is welcomed and not risky.

Delivery :

Discovery and definition lay out the process of understanding a problem space and defining a solution to get a product or feature off the ground. The key to this process is that the initial research phase is not the only time that you’re understanding user needs and defining solutions for your product.

Here’s how we continue understanding user needs and validating concepts throughout the life cycle of a product:

Release valuable functionality quickly With a focused and high-value product concept coming out of Discovery and Framing, it’s often tempting to continue designing new features and testing wireframes without actually releasing any software to real users. Although running Lean experiments and testing wireframes is valuable in determining initial product direction, the best test for a product is shipping it to production and using it in the real world. By narrowing focus and shipping a high-value vertical slice of the product, we’ve spent the minimum amount of time and money possible to find out if the core of the product works for its users.
The most common term for this idea is Minimum Viable Product (MVP). We find MVP means different things to different people, which causes confusion and uncertainty. To us, it means thinking in thin slices with end-to-end value—it’s important not to consider everything all at once. Focus on a small part of the broader user journey, but one that has a beginning, middle, and end that makes sense to someone using it. We call this a vertical slice.

Measure outcomes to determine success The complexity of building software makes it difficult to define all of its future functionality upfront. Large enterprises have been applying traditional management principles, intended for creative processes where the cost of change is extremely high. One of the biggest challenges for product teams working in Lean and Agile is defining the future vision for a product while providing enough flexibility for the team to learn from users, test ideas, and build a product incrementally. One of the best ways to align the vision and plan for a product is to define and measure outcomes that a product aims to accomplish, allowing iterations and learning to drive product decisions toward those goals.
Grow the product through continuous validation In order to build upon and iterate on an MVP, the ideas and processes described in Discovery and Framing continue as part of defining and validating new functionality for our product. Framing puts an emphasis on narrowing our scope and focusing on a vertical slice of high-value functionality. Once this functionality is released in the form of an MVP, the work begins to find out what to build next. The team can take the following steps to determine a direction to grow our product:
• Identify the next outcome on the roadmap.
• Use feedback from the MVP to plan any necessary iterations or pivots.
• Monitor the backlog of prioritized user problems from Discovery efforts.
This is the start of what continuous validation looks like. Based on these considerations, we can make informed decisions about whether more user research is needed for the next feature, or whether the team can jump into creating solutions. Either way, once a new feature is designed, some form of validation is needed before investing time in development. Once software engineers have begun building the MVP, product designers work a few weeks “ahead,” designing new features or figuring out what to build next.

Share Product Mindset's Newsletter