What is Product Discovery – and how do You get started?

In a rapidly changing and complex world, it's crucial to be able to identify and create successful products quickly if your business is to stand a chance in the marketplace. And you must quickly ensure that your products are actually the ones that customers want to buy and will love to use.

The above may sound trivial – and in my work, I've never met anyone who disagrees. Yet, time and again, I see in Danish and international companies that activities and initiatives meant to ensure that the products hit the mark are deprioritized over getting things done quickly (or just completed).

We are often too confident that we know the solutions to the problems we face. So we quickly jump to a focus on getting things done as quickly as possible.

There isn't time to stop and critically zoom in on whether we are working on solving the right problems, and whether we are actually solving them.

We are often too confident that we know the solutions to the problems we face. So we quickly jump to a focus on getting things done as quickly as possible.

The definition of Product Discovery

Working in a structured manner with Product Discovery is precisely about ensuring that we are solving the right problems and genuinely solving them. More concretely, Product Discovery can be described as an iterative and user-oriented approach to product development, aimed at identifying, validating, and delivering valuable products. It's about understanding customer needs, experimenting with ideas and solutions, and learning from feedback to create outstanding products.

One of the shorter definitions we use at Syndicate is:
"Product Discovery is the iterative proces of reducing risk and maximizing value around a problem or idea to make sure that the right product gets build"

Product Discovery is forgotten

So why don't we focus more on Product Discovery when it is so important?

As a consultant, I visit many different types of companies, where I have seen various reasons for the deprioritization of Product Discovery, whether consciously or unconsciously.

I boil them down into three categories.

3 Reasons why Product Discovery is forgotten

1) Silo, Phases, and the Disconnected Feature Team:
When ideas for new products are conceived, they often occur in a department or silo far removed from those who actually work with the product on a daily basis. Oddly enough, it is often others, not those who operate and maintain a product, who come up with ideas for new features or solutions. This often happens in a department or in the "business" side, innovation department, marketing, etc. It's a mystery why most Danish companies still have IT product departments separated from what they call "the business". If you got a krone every time someone said "the business has these requirements" or "it's the business that has decided how the solution should be," it would quickly become – well – a pretty good business.

Other times, the process of figuring out what to build is a phase before the actual work begins. It could be an innovation project, which spawns a good idea including a requirement specification based on assumptions. This then lands on the product team's desk, who cannot challenge or change the description they have been given. In this way, the product team ends up as what the author and product specialist Marty Cagan calls a "feature team". A feature team is a team that just does what others tell them to do.

2) Power struggles, politics, and egos:
‍Another unfortunate reason why Product Discovery is not carried out is something as unconstructive as internal power struggles and "politics". The challenge here is that a battle arises over who decides what to build, rather than empirical and real data forming the basis of the decisions.

It becomes a struggle to have power over the product and ultimately a question of egos and careers. Who wouldn't want to be the person who comes up with the great idea and ensures that the product was a success? The fight can be between both leaders and departments, and it often ends up being about mandate rather than what is right for the product.

3) Lack of knowledge on how to do It...‍
Another significant reason is a lack of knowledge about how to actually get Product Discovery started. That is, how to start, who does what, and how to break down the above problems so that you can actually be allowed to do Product Discovery.

You understand the empirical approach to problems and know that discovery is about understanding that you can't predict the solution to complex issues.

It all Starts with an empirical approach

Overall, Product Discovery is a mix of a mindset and a toolbox.

A mindset in the sense that it's a way to understand and view problems. If you have the right mindset and understanding of why Product Discovery is important to do, and why it should be done, then it's less important exactly which tools you use from your toolbox and when. You understand the empirical approach to problems and know that discovery is about understanding that you can't predict the solution to complex issues.

The toolbox consists of a variety of activities you can do to conduct Product Discovery, not necessarily in any order. It can be anything from working with assumptions and hypotheses, making prototypes, collecting data, conducting interviews, ideation, and data investigation.

All of this you do to minimize risk and maximize the value of your ideas and products.

One of the leading figures in describing Product Discovery is the previously mentioned Marty Cagan. In his book "Inspired: How to Create Tech Products Customers Love", he identifies four essential risks that Product Discovery helps to address. We use Product Discovery to delve into these unknowns:

Uncertainty about customers and market

One of the biggest risks is having limited or inaccurate knowledge of customer needs and preferences as well as market dynamics. Lack of understanding of the target audience can result in the development of products that do not solve real problems or create value for customers.

Technical uncertainty

Technical uncertainty arises when there is doubt about the technical realization of the product. It can be related to complexity, performance, or integration with other systems. Unexpected technical challenges can lead to delays, lack of functionality, or even failure in product development.

Uncertainty about business value

It's crucial to have a clear understanding of how the product will create business value. Lack of knowledge about the product's potential to generate revenue, attract users, or differentiate from competitors can result in a loss of investment and time.

Uncertainty about delivery

The risk of delivery concerns the ability to bring the product to market within the necessary timeframes and budgets. Lack of effective processes, poor management, or resource issues can lead to delays or failure to meet the product's planned delivery date.

Problem Discovery and Solution Discovery

We cannot talk about Product Discovery without discussing its two closely related family members: Problem Discovery and Solution Discovery.

Problem Discovery involves activities aimed at understanding and identifying the real problems and needs faced by potential users or customers. Instead of jumping straight to solutions, time is dedicated to thoroughly investigating and validating the challenges that actually exist and are worth solving.

Here are examples of key aspects of Problem Discovery:

User-Centered research: This involves talking to users, observing them in their natural environments, and understanding their daily challenges. It can also include analyzing user data to identify patterns and pain points.

Data Collection and analysis: Gathering quantitative and qualitative data to gain a deeper understanding of the scope and context of the problem.

Hypothesis formulation: Formulating assumptions about the problems believed to be faced by users, which can later be tested and validated.

Validation: Through interviews, surveys, and other research methods, efforts are made to confirm or refute the formulated hypotheses.

Prioritization: Identified problems are evaluated to determine which are most significant for users and which represent the best opportunities for the product.

Defining user needs and requirements: Once the problems are identified and validated, precise user needs and requirements are defined, which the product development team can use as a basis for solution development.

Problem Discovery ensures that the development team does not waste time and resources building a product that does not address a genuine need or that does not create value for the target audience. It is a way to minimize the risk of failure and maximize the chance of creating a product that truly makes a difference for users.

Solution Discovery involves activities where, after identifying and understanding the fundamental problems faced by users (through Problem Discovery), different solutions are explored, designed, and tested. This is crucial to ensure that the product or service you develop not only solves the right problem but does so in a valuable, usable, and viable way.

Here are examples of key elements in Solution Discovery:

Idea generation: Based on the identified problems, a wide range of potential solutions are generated. This can involve brainstorming, workshops, and other creative processes.

‍Concept development: The most promising ideas are transformed into concrete concepts, which can range from sketches to prototypes.

Prototyping: Developing quick and cost-effective prototypes that can be tested with users to gather feedback. This can be anything from paper prototypes to interactive digital versions.

User testing: The prototypes are presented to users to understand how they interact with the solution and the value they perceive. This is an iterative process where feedback is used to improve the solution.

Solution validation: Testing whether the solutions actually address the user's needs and problems identified through Problem Discovery.

Viability assessment: It's important to assess whether the solutions are technically and economically feasible to develop and maintain.

Refinement and iteration: Based on user feedback and viability assessment, the chosen solutions are further refined through repeated iterations.

Business model and strategy: Developing a business model and strategy for how the solution can be implemented in the market, which can include pricing, marketing, and sales strategies.

Solution Discovery ensures that you are equipped with a thoroughly tested, user-validated solution, which is not only desirable and usable for the target audience but also viable from a business perspective. It helps teams avoid frequent setbacks and costly detours later in the development process by having a solid foundation for their design decisions.

A rocket to get you started 🚀

Now you're ready to start minimizing risk and maximizing value for your products and business area. But how do you do it, practically speaking?

Well, just dive into it 😊

It's easier said than done, but since the core of Product Discovery is "learn fast," the same applies to getting started.

To make it concrete, here is a 3-step rocket to get you off the ground:

1. Create a cross-functional team
   Product development is a cross-functional process that requires input from different perspectives. Make sure to assemble a team consisting of members from various departments like product management, design, development, and marketing. This helps to ensure diverse insights and expertise. And allow them to have decision-making power over the product.
2. Identify your most Important questions
   What is the most crucial business question for you to answer right now? What is the question that could make your product fail or succeed? It could be assumptions about your customers, it could be assumptions about which market you should enter, or it could be very specific assumptions about an upcoming feature in your product. Does it really solve a problem for your customers?
3. Find the hypotheses and conduct experiments
   Once you know your burning questions, you need to come up with a hypothesis that can help you find an answer to your questions. It could be a hypothesis about your upcoming customer, about the market, or about a product feature.

For example, a hypothesis might sound like this:
We believe that 40% of busy families with children would prefer not to make lunchboxes every day.

‍The next step is to conduct an experiment to answer the hypothesis. This could be anything from interviews, data research, a landing page, visual prototypes, or something completely different. Here, only your imagination sets the limits.

The last piece of advice from here, before you embark on Product Discovery, is that you and your team must remember to be open and curious, because at its core, it's about exploring so you can find new exciting paths.

Happy product discovery journey!

P.S. At Syndicate, we've helped many get started with Product Discovery. If you need help on a discovery journey in your business area, feel free to contact us.