How to Structure Your Product Discovery
Creating room to drop ideas that distract teams from what truly matters
Many people ask me a common question: How do I bring product discovery to life when nobody supports that?
It’s a genuine question, and I know the pain very well.
First, don’t bother with the term product discovery.
Bother with what product discovery does.
Product discovery done right proves you’re wrong soon enough.
Dropping bad ideas fast enough is what matters most.
We all think our ideas are awesome. They may be, but only a few will resist contact with reality. It’s unwise to keep investing in what doesn’t work. It’s wise to cut bad investments short and double down on the promising ones. The big question is, how do you make that possible?
The biggest challenge of being a PM is that almost nobody gets your job. Nearly everybody distracts you from doing what matters most.
Let me help you apply enough structure to your product discovery to succeed. Don’t worry—I won’t load you with theory but will give you hands-on practice.
Setting expectations:
Free subscribers will benefit from an overview of the structure.
Premium subscribers will get a detailed guide on how to structure product discovery.
Announcement: I’m running my Product Discovery Done Right cohort in a few weeks. You can book your seat now, and I want to be transparent. I’ve got a lot on my plate, so I will pause my cohorts for a while. I don’t know when the next group will initiate, but it will probably be in six months or more.
Understanding Reality: We Don’t Know What We Don’t Know
Whenever we have an idea, we are excited. We believe we will change the world. Yet ideas are often wrong; they should point to where to start, not where to land. It’s too naive to believe we know everything upfront.
Look at the following image. Reflect on it briefly, and tell me, what’s your best move when you want to start with an idea?
When you have an idea, you probably have:
Weak evidence
A glimpse of what it could be
Loads of risks of going wrong
Will customers use it?
Can we monetize it?
Will we manage to get it done?
Despite the above points, teams often create plans to implement ideas. The result leads to:
Timelines without supporting evidence
Deadlines without knowing what makes sense
Focus on implementing solutions over solving problems
Lack of strategy to de-risk the idea
If you want to fail, go all in when you lack enough knowledge.
Now, you may wonder, how do you change this game? That’s when bringing some structure to your product discovery will help you.
Structuring Discovery: Dropping Bad Ideas Fast Enough
As you probably know, creating digital products is complex. You also know that people add complexity and tend to make it more complicated than it should be. Have you ever stumbled upon any of the following?
Endless prioritization discussions
Too much talk about how to do the work instead of doing it
Trapped in meeting rooms
Output oriented roadmaps
Slow decision-making
All of the above is related to a poorly structured way of working. Let me help you simplify what others complicate.
I like setting up a Kanban board that encourages proper discussions. This way, we can gradually increase investment instead of wasting time on things that don’t matter.
The following image represents how I structure product discovery.
Let me give you an overview:
Goals: Start with what you want to achieve. Without knowing where to end, you will end up discussing everything. Focus on a goal at a time and drop ideas unrelated to it.
Value Drivers: What would get you closer to your goal? These are your value drivers. Strive to uncover what creates customer and business value. You’re exploring the problem space, not the solution, at this stage.
Craft the Future: As you prioritize the few value drivers you want to focus on, it’s time to explore the solution space. What could you create to drive expected results? Explore multiple solutions as quickly as possible.
Assumptions: What do you assume will happen? Prioritize critical assumptions you lack evidence for and strive to test them. You will realize that some of your assumptions are wrong, which is good because it enables you to adapt course.
Experiments: After testing assumptions, you may want to implement a full-blown solution. Not that fast. Scale the reach and run more robust experiments to understand what works and what doesn’t.
Delivery: Once you have found a solution worth building, it’s time to focus on delivering it properly to your audience. First, you build to learn, then to scale.
Done: When you learn your solution drives expected results, you make it scalable, pay off the debt, and let all customers benefit. Do not skip this iteration. Otherwise, your product will become unmaintained, and nobody will want to work with something like that.
These iterations will help you focus on progress instead of abstract discussions. You can have objective exchanges where evidence speaks louder than opinions. Now, let me walk you through each part in more detail.
Goal: Defining What You Want to Achieve
“The things that matter most should never be at the mercy of the things that matter least.” – Johann Wolfgang von Goethe
Unfortunately, we live in a world where people believe having multiple priorities will accelerate the process. Such a perception is incorrect. The more you juggle, the less meaningful work you can achieve.
It’s paramount to define what your priority is. That’s singular, not plural. With one goal at a time, teams can focus and deeply work on what matters instead of constantly switching contexts.
Lack of prioritization is a leadership failure. That contributes to endless discussions and tremendous time waste. Once you agree on a goal, you can ask the following questions to any request you receive or opportunity you identify:
How does this contribute to our current goal?
How do we know this is the right thing to do?
How do we measure success?
How would we collect value?
When you lack answers to the above, ideas are good to go. At best, you can explore them further to get those answers but do not proceed until you get convincing answers.
Goals empower teams to focus on what truly matters. Yet, setting goals isn’t enough. It’s critical to understand the whole playing field. Here’s what goals should tell you:
Where to land: That describes what success looks like.
Trade-offs: It helps you understand which trade-offs you can use.
Guardrail: It tells you what you should preserve while reaching the goal.
Let me give you an example.
Goal 1: Accelerate customer acquisition by 20%
The good thing is that it’s an outcome goal, but you’re left without knowing which cards you have, making it harder to uncover what to do.
Goal 2: Accelerate customer acquisition by 20%, even if that increases acquisition costs by 10%, but do not negatively impact retention.
This goal tells you where to land, possible trade-offs, and guardrail metrics, making it easier to play the game.
Make your goal actionable so teams know where to land, potential trade-offs, and what to preserve.