This is an article I've been dragging around for far too long, but I finally decided it was time to finish it. When I first started drafting it, I wasn't as experienced as I am today. I was trying to figure out the "perfect recipe" for product discovery and, like most things in product management, I eventually realized there isn't one.
Instead, there are principles, techniques, and questions that can help us navigate the uncertainty and increase our chances of building something that actually creates value.
This article is primarily for people who are new to product management or are taking their first steps into product discovery. Think of it as a starter package: a practical, high-level framework for moving from a customer problem to an MVP.
Teresa Torres, in her book Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value, takes a deep dive into the topic. Personally, I consider her one of the leading voices in product discovery.
For me, product discovery is a muscle that I had to train. And honestly, it is now one of the parts of my role as a product manager that I enjoy the most.
There is something incredibly rewarding about taking an ambiguous problem, understanding the people affected by it, exploring different possibilities, and eventually bringing something new to life.
👉 So, let's cut to the chase.
The Product Discovery Board
I created a board to help navigate the journey from an initial customer problem all the way to the delivery of a Minimum Viable Product (MVP).
The template provides a basic structure for gathering the information you need from customers and stakeholders in order to design a product that ultimately delivers value.
Disclaimer: The purpose of this board is not to capture every aspect of a product in exhaustive detail. More detailed requirements can live in a Product Requirements Document (PRD) or in prototypes developed using tools such as Lovable, Claude, etc.
To demonstrate how the template works, I'll use a hypothetical scenario. The "client" in this example is internal: managers from the sales department of Company X.
Their request is extremely open-ended:
"Build something for us with AI".
Sounds funny, right?
Unfortunately, the AI hype has encouraged people to jump straight from a problem to a technology or solution: AI, AI, AI...
But that's precisely where product discovery should push back. 💡 We should start with the problem, not the technology.
Contents
-
Product Discovery
- Problem statement
- Impact and opportunity assessment
- Opportunity identification
- KPIs and goals
- Target group
-
MVP
- User stories and prototypes
- Evaluation
- Delivery
In a Nutshell
You don't need to fill the buckets sequentially. The most important thing is to start with the problem and the customer needs. You will iterate many times.
Prerequisites for Successful Product Discovery
1. People
First things first: bring the right people together.
Depending on the situation, this could be a face-to-face workshop or a virtual session. The important thing is to have the people who understand the customer, the business, the technology, and the problem in the room.
2. Data
Don't rely solely on what people say during a workshop.
Look at your company's data, customer complaints, surveys, industry reports, and competitor activity. The objective is to build a 360-degree view of the key pain points and their potential impact so that decisions are grounded in evidence rather than assumptions.
3. Tools
You'll need a board to facilitate the workshops. If you're meeting face-to-face, a physical board and Post-it notes can work perfectly well.
For remote collaboration, tools such as Miro can recreate the collaborative experience digitally.
4. Duration
The duration of product discovery depends on the complexity of the product and the problem you're exploring. As a starting point, I usually recommend planning an initial two-hour workshop, including breaks, to establish the foundation.
Design Thinking Principles
Over the years, I've found Design Thinking particularly useful for Product Discovery and for building MVPs.
One of the concepts I find especially useful is the combination of divergence and convergence.
During divergence, we aim for quantity. We explore many customer problems, ideas, and possible approaches without narrowing down too early.
During convergence, we narrow the field. We assess the alternatives and focus on the opportunities and solutions that appear to have the greatest potential impact.
Source: ProdPad, Double Diamond
More information about Design Thinking can be found here.
Product Discovery
1. Problem Statements: Understanding Customer Pain Points
🔎 DIVERGENCE
Start by gathering as many pain points as possible.
Don't limit yourself to what customers mention during the workshop. Dig deeper into historical customer complaints, surveys, support data, and feedback. Look at competitors and the broader industry as well.
The goal is to build a comprehensive understanding of customer needs before jumping into solutions.
2. Impact: Opportunity Assessment
🔎 DIVERGENCE
Once you have identified a number of pain points, assess their potential impact.
This is where a data-backed approach becomes particularly important. Prioritize pain points based on measurable impact, rather than intuition alone.
If you cannot articulate why a problem matters and what impact solving it could have, you probably need to investigate the problem further before investing in a solution.
For each potential pain point, I usually perform a lightweight opportunity assessment covering:
- Problem statement
- Objectives
- Potential solution, at a very high level
- Potential impact
- Success metrics / key results
- Why now?
- Alternatives, supported by market research
- Why our team?
- Risks and dependencies
Keep this lightweight — two pages at most. If the initiative gets the green light, the detailed description can be developed later in the PRD.
Market Research
Market research is important for evaluating whether a genuine product opportunity exists.
This example provides only a simplistic view to get you started. For more advanced assessments, you can use frameworks such as 📊 Porter's Five Forces or 📊 SWOT analysis.
3. Opportunity Identification
🎯 CONVERGENCE
Now it's time to narrow down the opportunities.
Based on the customer pain points, their potential impact, the market context, and the available capabilities, identify the opportunities that are worth pursuing.
This is the point where the discovery process starts moving from exploration toward a clear product direction.
4. Target Group
🎯 CONVERGENCE
Be explicit about who you are solving the problem for.
A product cannot effectively solve a problem for "everyone". Identify the specific customer or user group that experiences the problem and would benefit most from solving it.
5. KPIs and Goals
🎯 CONVERGENCE
At this point, we need to define how we are going to measure the success of the initiative.
Most importantly, estimate the potential impact of the solution. What ROI are you expecting? Is that return sufficient to justify the investment?
Also consider the 🛡️ guardrail metrics that need to be established. Success isn't only about improving the primary metric; we also need to make sure that we aren't creating negative consequences elsewhere in the product or business.
Start Defining the MVP
An MVP is one of the fastest ways to test a hypothesis.
But there is an important detail that is often overlooked: the "V" in MVP stands for Viable 🚀.
That means the MVP should not simply be the easiest version of the product to build. It should deliver enough value to solve a real customer problem and allow us to learn from real usage.
1. User Stories and Prototype Preparation
🔎 DIVERGENCE
User stories can guide the creation of requirements in the PRD.
At this stage, we once again aim for quantity. We explore different ways the product could work and start translating the ideas into prototypes.
Prototyping allows us to make assumptions visible and test them before committing significant engineering resources.
2. Risks and Dependencies
🔎 DIVERGENCE
Capture as many risks and dependencies as possible — even the seemingly small or "silly" ones.
A minor dependency can become a major bottleneck later in the process. Identifying these issues early gives the team an opportunity to mitigate them before they affect delivery.
A proactive approach is almost always better than discovering a critical dependency when you're already committed to a release.
Here is another example, including potential mitigation strategies:
3. Define the MVP
🎯 CONVERGENCE
Now we need to decide how the first version of the product is actually going to work.
This is where the concept of Minimum Viable Product becomes particularly important.
The MVP should deliver value. We should not use the term MVP as an excuse to ship something simply because it is technically easy to build.
A good MVP solves a meaningful customer problem while keeping the scope focused enough to allow us to learn. Nice-to-have functionality can wait.
The following screenshot shows examples of user stories that could subsequently be translated into requirements and prioritized using the 📌 MoSCoW framework.
4. Evaluation: How Will We Measure Success?
Before reaching this point, the measures of success should already be crystal clear.
Now we need to define how we are going to test the effectiveness of the MVP.
In many cases, an A/B test can be a powerful way to measure the impact before a full rollout. When an A/B test isn't applicable, a difference-in-differences approach can be considered, depending on the context and data available.
There are several important concepts to consider when designing an A/B test, including:
- Experiment duration
- Cohort split
- Statistical test
- Power analysis
- Reporting and dashboards
This is only a teaser, but experimentation deserves a whole article of its own.
5. Delivery
Delivery is the stage where I have limited contribution.
Once the user stories and requirements are sufficiently defined, the tech lead can estimate the effort and organize the technical work.
If the architecture is clear and the experiment for measuring success has been properly designed, you should have enough information to create a high-level release plan. After that the project manager or delivery lead can track and manage the execution.
Wrapping Up
And that's it — a high-level overview of the key elements I keep in mind when working through the discovery of a new product.
Of course, product discovery is rarely a perfectly linear process. You will move backwards and forwards between problems, opportunities, customers, solutions, and assumptions.
And that's okay.
The board is not a checklist that you have to complete from top to bottom. It is a structure that helps you ask the right questions, make assumptions visible, and bring the right people into the conversation.
The most important principle I want to emphasize is simple: 🎯 As product people, our job is to solve customer problems.
When we solve meaningful customer problems, business value follows. Customer value and business value are not competing objectives — when approached correctly, they go hand in hand.
So before someone asks you to "build something with AI", take a step back.
❓ What problem are we actually trying to solve?
Start there.
🚀 Happy product discovery!
Comments
Post a Comment