Product Discovery: A Practical Guide for Product Teams
Feb 1, 2025
Product Discovery: A Practical Guide for Product Teams
If you've ever been told to "just talk to users more" and felt like that advice didn’t quite cut it—this guide is for you.
In this practical deep dive, I’ll walk you through specific techniques I use with Product Teams worldwide to navigate the messy world of user problems and uncover which solutions are actually worth building. The goal? Help you run Product Discovery that leads to better decisions and real progress—not just more research for the sake of it.
What You’ll Learn in This Guide
How Product Discovery connects with core product management practices like Product Strategy, Scrum, and OKRs
How to build a flexible, structured Discovery process without turning it into a rigid checklist
How to blend the essentials—alignment, research, testing—without getting stuck in templates
Hands-on tools and methods that are light on process and heavy on results
A bunch of advanced techniques you can adapt to your real-world environment
If you’re looking to build the right product for the right people, this is your starting point.
Introduction
When you're planning your next roadmap cycle, you need more than just gut instinct to back your themes. Whether your focus comes from strategic goals, past epics, OKRs, or user feedback—you need to connect the dots with confidence.
At a high level, it’s usually clear what direction the product should go. But zoom in, and the questions get trickier: What specific problem are we solving next? Who exactly are we solving it for? What will actually make an impact?
That’s where a clear and adaptive Product Discovery process becomes your best asset.
This guide is designed to show just how broad and valuable Discovery can be—while giving you concrete, actionable tactics to run your own version of it. Don’t expect a fixed formula. This isn’t a paint-by-numbers playbook. Think of it more like a toolbox—something you can tailor to fit your team’s goals, stage, and constraints.
Table of Contents
Product Discovery Fundamentals – Understand the basics and how Discovery fits into your product workflow
Phases and Team Involvement – Organize your process and align participation
Techniques and Frameworks – Apply practical tools without overengineering
Reality Check – Keep your process grounded and effective in real-world conditions
Chapter 1: Product Discovery Fundamentals
Let’s kick things off with the basics. This chapter lays out what Product Discovery actually is, and how it connects to everything else product teams do.
What You’ll Take Away:
A clear definition of Product Discovery
How Discovery works alongside Scrum in a Dual-Track Agile model
How to connect Discovery to Strategy, OKRs, and Roadmaps
What Is Product Discovery and Why Does It Matter?
At its core, Product Discovery is about reducing uncertainty using real evidence. It’s how product teams figure out what problems are worth solving—and what solutions are worth building. You do it through non-linear activities, in collaboration with a cross-functional team.
Discovery is the part of the work where you ask, "Are we building the right thing?" It’s different from Delivery, which is about "Are we building the thing right?"
Discovery isn’t a phase or a checklist. It’s an ongoing mindset and set of activities that shift your team from reacting to features toward solving actual problems. Later in this guide, we’ll explore the many shapes Discovery can take.
In practical terms, you’ll usually find your team operating in one of two spaces:
Problem Space: Trying to understand if the problem is real, urgent, and meaningful to your users or business
Solution Space: Exploring how to solve that problem once it’s validated
You need both. But most teams tilt too heavily toward execution and forget to carve out time for proper Discovery. Great Product Discovery is about rebalancing that focus—and making the problem space your primary starting point.
So yeah, it’s tempting to dive headfirst into designing clever solutions the moment an idea pops up. But before you start sketching wireframes or writing user stories, hit the brakes.
No matter how flexible or individual your Product Discovery path is, aligning around the problem space is non-negotiable. It might not feel as exciting as jumping into solutions, but if you skip it, you're building on shaky ground. Clarity on the problem space keeps your team focused, aligned, and working on something that actually matters.
Avoiding Alibi-Discovery and Owning the Problem Space
Let’s talk about Alibi-Discovery. If you haven’t come across the term, here’s the quick version: It’s when a team goes through the motions of Discovery just to rubber-stamp an idea that’s already been decided. The clearest red flag? Kicking off a Discovery process with ideation sessions.
If you go by the actual definition of Product Discovery—reducing uncertainty by finding real problems worth solving—then it’s easy to see why starting with brainstorming features is a backwards move. Discovery isn’t about coming up with solutions to validate an executive’s hunch. It’s about turning vague company-level goals into specific, measurable outcomes that teams can actually work with.
Here are a few go-to questions I use to check how well a team understands their problem space:
What are three pieces of first-hand evidence showing this problem is worth solving?
When was the last time you spoke to someone in your actual target audience?
Can you describe the exact behavior change users would need to make to achieve their goal?
Do you have both qualitative and quantitative insights into this problem?
Discovery isn’t about hitting a quota of interviews or experiments. You’re not just swapping out feature launches for user conversations on a different kind of hamster wheel. The goal is to reduce the right kind of uncertainty at the right time—whatever shape that takes.
Connecting Product Discovery to Scrum and Product Delivery
Here’s the reality: If your team is remotely user-centered, you're always doing some kind of Product Discovery. Every bit of feedback you gather, every insight that pops up, feeds that process. That’s why Product Discovery can’t be a “sometimes” thing.
Most Product Managers work in what’s called Dual-Track Agile. That’s where Discovery and Delivery happen side by side. You’re applying Agile thinking—collaboration across Product, Design, and Engineering; user-centered development; fast iterations—to both figuring out what to build and actually building it.
Discovery and Delivery aren’t phases. They’re ongoing. But the intensity of each will ebb and flow—more like overlapping S curves than neat, isolated blocks on a project plan.
Balancing Discovery and Delivery Modes
Discovery and Delivery aren’t two isolated tracks that you switch between with a button. They constantly influence one another, and in practice, they run in parallel—most of the time.
That said, the level of involvement in each track varies depending on the team member and the phase you’re in. A new Discovery mission might start with everyone in the room, but as it unfolds, your Product Manager, UX Designer, or Engineers will naturally lean more toward one side of the work. And that’s okay. What matters is that your team has the skills and autonomy to manage both ends—when and how it makes sense.
Here’s the reality: you’re almost always working in a hybrid mode. One week might lean heavily toward Delivery, the next toward Discovery. That shift in balance depends on one thing—uncertainty.
If you’re unclear about what solutions are needed to move the needle on business goals, it’s a sign to double down on Discovery. But the key shift here is mindset. Discovery isn’t a box you check or a phase you complete. It’s a toolkit—a set of habits—that helps you navigate both the problem space and solution space as they evolve.
Adjacent Product Discovery Processes
Being great at Product Discovery isn’t just about user interviews or running tests. That’s only one piece of the puzzle.
If you want to consistently focus on outcomes, you need to understand what enables that kind of thinking. I like to call this the Outcome Quadrant—a system made up of four foundational pillars that shape your ability to stay outcome-driven throughout Discovery.
Why Strategy, Goals, and Roadmaps Also Matter
Product Discovery might be a critical part of the puzzle—but it’s not the whole picture. To really make it work, you need to make sure your approach to Product Strategy, Product Goals, and Roadmaps supports your Discovery efforts, not blocks them.
As a Product Manager, this is your arena. These are the levers you can pull and the areas where you should demand clarity. If your Discovery work feels sluggish or off-track, the issue may not be your interview skills or testing tactics. It’s often that the surrounding systems—strategy, goals, and roadmaps—aren’t built to support how you work.
How Product Strategy Informs Product Discovery Priorities
At its core, Product Strategy is your plan for how to win. It’s how you define your playing field and how you’ll stand out. That includes:
Who your strategic audience is
What alternatives your users are choosing from
How your product will differentiate itself
What your long-term vision and organizational strengths are
Product Discovery doesn’t exist in a vacuum. It starts with the context your Product Strategy provides. No need for a 100-slide strategy deck—but you do need a clear, shared reference point when trade-offs come up and the team needs to make real decisions about where to focus.
Without a grasp on what your strategy is aiming to achieve, Discovery quickly loses direction.
Here are the foundational elements your Product Strategy should cover:
1. The Strategic Narrative
This is your “why.” What future are you trying to create? How will you measure whether you're making progress toward it? Your vision, guiding principles, and longer-term goals all fit here.
2. The Playing Field
This is the market space you're operating in—defined by:
The audience segments you’re targeting
The jobs they’re trying to get done
The alternatives they’re comparing you against
3. The Winning Moves
This is your tactical game plan:
What are the offerings and value props you’ll prioritize?
Through what channels will you reach users?
How will you clearly differentiate from the alternatives?
A quick tip: Product Strategy templates can be helpful, but they’re not the point. The goal isn’t to fill in boxes. It’s to develop a flexible, evolving strategic mindset—one that can guide your Discovery work and inform decisions without locking you into a rigid formula.
Let Strategy Gaps Shape Your Discovery Priorities
The missing pieces in your Product Strategy are what should guide your next steps in Product Discovery.
Ask yourself:
Are you trying to fix a performance gap in your current market? Then your focus might be on iterating an existing product.
Or are you aiming to solve an opportunity gap—maybe by entering a new market or redefining your vision? That calls for broader exploration.
Your Discovery work should directly align with the kind of gap you’re trying to close.
For example, if your goal is to understand and support new jobs for your current users, then double down on what you already know. Dig into qualitative and quantitative insights from active or churned users. Use that to shape targeted research, rather than jumping straight into exploratory interviews with a completely new audience.
And don’t guess. Look back at your Product Strategy stack. Use it to figure out which gap really matters most for your team right now—and let that drive how you prioritize your Discovery efforts.
How Product Discovery Connects to OKRs
Objectives and Key Results (OKRs) are the bridge between Product Strategy and day-to-day execution. They take the high-level strategic choices and turn them into measurable definitions of success, so your team can prioritize work accordingly.
Done well, OKRs offer a clear picture of what success looks like—expressed through metrics that reflect progress toward your product’s goals. This gives your team the structure to make focused decisions in Discovery without losing sight of the bigger picture.
Distinguishing Product Goals from Strategy
Product goals often get mistaken for strategy—especially in both B2B and B2C environments. But here’s the thing: strategy is the plan to reach a goal, not the goal itself.
One of the toughest parts of using OKRs in Product Management is syncing your Discovery and Delivery work with the rhythm of your goal-setting cycles. If the two aren’t aligned, you risk setting objectives that sound great on paper but don’t reflect what’s really needed on the ground.
Planning Ahead: How Discovery Supports OKRs
Instead of cramming Discovery, Delivery, and iteration into a single OKR cycle, Product Teams should get ahead of the curve. Use one cycle to explore and reduce uncertainty, and the next to deliver. That only works, though, if your Discovery-oriented OKRs are grounded in real outcomes—not just a disguised to-do list to keep the team busy.
To make OKRs actually useful—not just another set of vanity KPIs or abstract wishlists—Product Teams need more than textbook guidance. Your OKR system should work with your product process, not against it.
How Product Discovery Connects to Product Roadmaps
One overlooked tool for shaping and prioritizing Discovery is the Product Roadmap. Done right, roadmaps are more than just delivery deadlines—they’re a way to make future priorities visible and aligned with strategy.
But roadmaps can easily become handcuffs. If your team technically has the time to explore the problem space, but the roadmap says, “Ship this new feature by March 31,” then that’s not Discovery—that’s polishing a predetermined solution.
Product Teams should feel confident about what they’re focusing on this quarter, but assume that what they learn might reshape next quarter’s plan. That’s where theme-based roadmaps come in. They define what matters now, leave room for change later, and stay flexible the further out you plan.
Update these roadmaps on a rolling cadence and align them with strategy and OKR cycles.
Chapter 2: Product Discovery Phases and Team Participation
In this chapter, we’ll break down the key phases Product Teams cycle through in Discovery—and how to structure your efforts without falling into a linear trap.
Key Takeaways:
How to prioritize and structure your Product Discovery efforts
Who needs to be involved (and when)
What the essential elements of Discovery look like
Product Discovery Isn’t Linear—And That’s a Good Thing
Every Discovery effort starts somewhere different. That’s normal. What matters is that you move forward with intent. The model below outlines a few core phases that help organize your thinking as you go.
Just don’t treat them like a checklist. You’ll probably hit a wall at some point, backtrack, or shift gears completely. That’s fine. Discovery is messy—and pretending otherwise just makes it harder.
The key is adaptability. That’s why I built the Adaptable Product Discovery Approach: so teams can pull the right technique at the right time and make it work in their context.
How to Prioritize Discovery Opportunities
Discovery is about confidence. It’s about proving a problem is worth solving before you pour time and money into a solution. That’s why quick-and-dirty frameworks like Effort-Impact Scoring often miss the mark—you don’t even know what the solution is yet.
So instead of guessing, use a better grading system:
Prioritize by Reducing Uncertainty
When you start evaluating ideas through the lens of uncertainty, the picture gets clearer fast. The upper right of your grid? That’s where your next Discovery priorities live. The lower right? That’s Delivery territory—no need to explore those further.
Prioritization will always feel a little rough. That’s fine. You’re not trying to be 100% right—you’re trying to get aligned. You’ll refine as you go. The real clarity comes from actually doing the work, not from perfect planning.
How to Structure Your Product Discovery Process
Planning your Discovery work shouldn’t start with the tactics. Zoom out first. The bulk of Discovery should focus on understanding the problem—not jumping straight into brainstorming shiny solutions.
That said, I’m not a fan of arbitrary Discovery deadlines. But timeboxing? That’s a different story. A six-week cycle has worked well in many teams I’ve worked with. Why?
It doesn’t pretend to know everything in advance.
It’s a low-risk starting point, not a final timeline.
It leaves room for course correction.
It balances structure with adaptability.
Structure isn’t the enemy of good Discovery. Just don’t confuse structure with rigidity. Think of your timeline as scaffolding, not a cage. It helps shape your progress, but it shouldn’t block flexibility.
A six-week cycle gives enough room to explore, test, adjust—and ship with confidence.
Don’t Just Start Fast—Start Right
Here’s a common mistake: teams rush to “talk to users” as soon as possible. So they hit the street or pop into a coffee shop hoping to strike gold. Unless your product is for coffee drinkers in general, odds are that’s wasted effort.
A better approach: define your target audience clearly, schedule more interviews than you need, and get access to relevant users in the first 1–2 weeks. Sure, it might take longer to line things up. But when you do, you’ll get valid insights that actually move your Discovery forward.
Who Should Be Involved in Product Discovery?
Ah, the classic question: who should participate in Product Discovery?
While it’s tempting to list job titles, the real answer depends on your context. Forget rigid roles. Discovery is about cross-functional collaboration. That means the right people at the right time.
Think in three groups:
Core Team — your permanent Discovery crew
Temporary Contributors — folks who step in when needed
Supporters — adjacent roles who stay in the loop
Your Discovery setup should flex based on the mission—not a fixed org chart.
roduct Discovery Roles Should Evolve Over Time
The roles people play in Product Discovery aren’t fixed—they’ll shift as your Discovery evolves. The level of involvement from different groups should depend on your setup, the phase you’re in, and what you’re trying to achieve.
Maybe you need another Product Team involved early on to align on dependencies. Maybe your sales team has real value to add during ideation—or maybe not, depending on how they typically engage. None of this is set in stone. It’s all context-driven.
Why Broader Involvement Matters
There are two key reasons to go beyond the typical trio of Product, Design, and Engineering during Discovery:
Empowered, Accountable Teams
When a Product Team owns its Discovery, it can generate insights, make decisions, and move at its own pace. Sure, they might share research findings with central teams. But the core Discovery process—and the responsibility for outcomes—belongs to them.
Balanced Perspectives That Prevent Bias
Different departments bring different views. When interviews, ideation, or validation sessions include voices across domains, it helps avoid tunnel vision. You’re less likely to chase confirmation bias, and more likely to get to a shared, actionable understanding.
Dedicated Discovery Teams? Not So Fast
Some companies try to solve the focus problem by spinning up separate Discovery-only teams. These teams do the exploration, then throw their findings over the fence to the Delivery teams.
On paper, it sounds efficient. In practice, it fragments ownership.
If Discovery is detached from those who will build and iterate on the product, you lose out on speed, depth, and accountability. Instead of creating a Discovery team, make Discovery something your whole team is capable of—and confident in—doing together.
What Are the Key Elements of Product Discovery?
Let’s go back to that familiar metaphor: Product Discovery is like driving toward a destination with no GPS. You’re trying to avoid two extremes:
Taking the first exit: You commit to building too early, before you know the problem is even real.
Missing every exit: You stay in “research mode” forever, chasing new data while never shipping anything valuable.
Your job is to navigate the messy, non-linear phases of Product Discovery with just enough direction to reduce uncertainty—and move forward.
Creating Alignment to Unlock Autonomy
One of the first real challenges in Discovery is creating alignment without sacrificing team autonomy.
If there’s no clarity on why this Discovery effort matters in the first place, the team’s going to drift. You’ll either end up building something random to check a box—or worse, chasing solutions that confirm what you already believe.
That’s where alignment comes in. But here’s the catch: not all alignment is created equal.
The Feature Trap
We’ve all been there. A stakeholder hands you a “must-have” feature they want added. They’re not giving you a problem—they’re giving you their solution. That’s not collaboration. That’s a symptom of mistrust.
They don’t believe your team will deliver what they want, so they’re prescribing exactly what to build. The only way out of that loop? Align early. Shift the conversation away from features and toward outcomes.
Red Flags That Signal You’re Misaligned
When alignment is too focused on solutions, not problems, these warning signs often show up:
Creating Alignment Is About Commitment, Not Consensus
Getting aligned doesn’t mean sending an email. And it definitely doesn’t mean getting everyone to nod along in agreement.
Real alignment comes from commitment—and that’s a whole different game. You’re not looking for everyone to agree with every detail. You’re looking for them to back the plan, even if they’d take a different route themselves.
One way to create that kind of alignment is through a structured approach like the Mission Briefing—which we’ll get into later.
Understand Real User Problems to Define Outcomes That Matter
When defining Outcomes, don’t make the mistake of focusing on what you want users to do. That’s a sign you need deeper insight into the user’s actual problem space.
Yes, your business wants people to “add more items to their cart.” But that’s not a user problem—that’s a business metric. You can’t assume that just naming the behavior you want to see makes it a legitimate outcome.
Instead, get into the mindset of what’s blocking your users from achieving what they already want to do. Solve that, and your business goals will follow. For example:
“Continue shopping without leaving the basket view.”
“Compare items on mobile without opening multiple tabs.”
“See delivery time estimates for multi-item baskets without going to checkout.”
See the difference? These are friction points. Solve them, and you improve both user experience and business performance.
Don’t Default to Interviews—Start With Intent
When teams think “we need to do research,” they usually rush to interviews or surveys. That’s not wrong, but it’s often premature.
Instead, start by getting clear on your research intent:
What is the biggest area of uncertainty right now?
What kind of behavior or evidence would reduce that uncertainty?
Once that’s defined, pick your methods—qualitative, quantitative, or both.
A powerful example comes from a recent Spotify research initiative. Their user research and data science teams teamed up to investigate user behavior from multiple angles. Instead of just asking what people do, they observed it, mapped it, and compared the results.
That’s how you move from surface-level feedback to real insights—by finding the overlap between what people say and what they actually do.
Turn Feedback into Evidence, Not Just Noise
You don’t always need to launch a new research initiative. Sometimes, your best insights are already sitting in front of you—scattered across incoming support tickets, user comments, or feedback forms. The key is turning that ongoing stream of feedback into structured, accessible evidence.
Tools like EnjoyHQ or Reveall make this easier by giving teams a way to collect, organize, and turn qualitative input into something usable. Whether you're improving an existing product or building something brand new, your job is the same: understand what users want and what’s getting in their way.
Why Traditional Research Workflows Hold Teams Back
Most product teams still rely on the same outdated user research playbook—and it’s flawed in four major ways:
It runs through centralized authority. Teams need to “ask permission” to run interviews.
Participant quality is hit-or-miss. Most recruitment lacks the context needed to qualify users properly.
You’re lost in panel averages. Feedback from large panels is often too generic to act on.
It’s slow and project-based. Research becomes a one-off task instead of a continuous capability.
Teams that don’t speak with users regularly never improve how they do it—and that’s a problem.
That doesn’t mean recruiting should be random or messy. Structure is still necessary. But the “research request queue” model? That just slows everything down. Thankfully, a new generation of tools is changing the game.
One of those is Orbital, a platform designed to help product teams speak with the right users consistently, without the bottlenecks. (Note: Orbital is a fictional name used for illustrative purposes and anonymized to respect NDA agreements.)
Ideate Boldly—Then Narrow Down with Discipline
Once you’ve got a solid understanding of your users’ problems, it’s time to explore possible solutions. And no, this isn’t the moment to pull out your CEO’s “cool idea” wish list.
Effective ideation is about getting people out of their comfort zones and thinking boldly. You’ll scale things down later—right now, aim high.
Of course, a giant stack of sticky notes is great—until you need to pick one. Don’t fall into the trap of the highest-paid person in the room picking their favorite. Democratize the process.
Start by clustering ideas by theme or pattern.
Use something like dot voting to narrow 40 ideas down to a manageable 10.
Don’t worry about saving every single one. Great ideas will resurface when they’re actually needed.
Forget the idea backlog. If it’s that good, it’ll find its way back.
Prototype the Experience, Not Just the UI
Throwing sticky notes at your users won’t cut it. You need to turn ideas into something they can interact with. But that doesn’t mean high-fidelity design or polished mockups right away.
You’re not prototyping a screen—you’re prototyping an experience.
Let’s say you’re testing the idea of a “personality assessment.” You don’t need to build a product. You can:
Create a landing page where users start the “test.”
Use a tool like Typeform to simulate the quiz.
Hook it all up with Zapier to process inputs.
Generate a tailored result using prewritten content.
Send it via Mailchimp or another email service.
Congratulations, you’ve just prototyped the full experience—without writing a line of code.
David Bland puts it well: Don’t build more than you need to learn. With today’s no-code tools, it’s tempting to overbuild. Resist it. Keep the prototype lean and focused on validating one key behavior or assumption.
Run Experiments That Actually Validate Assumptions
Testing assumptions isn’t about checking a box. It’s not about the number of A/B tests or how fancy your prototype looks. It’s about collecting evidence that helps you decide whether to move forward.
To do that, you need to evaluate the quality of the signals you’re getting.
Two dimensions matter most:
Proximity: How close were you to the source of the feedback or behavior?
Commitment: How serious was the user’s action? Did they click a button—or did they actually pay for something?
Combine these into a simple structure: Insights Mapping. This framework helps you judge which experiment results are strong enough to influence your product decisions—and which ones aren’t.
Make Experiments Count by Testing the Right Assumptions
Like most 2x2 matrices, your sweet spot is the upper right. That’s where insights are both close to the source and backed by real commitment. And just like with any matrix, your goal is to avoid that lower left—where evidence is weak and distant.
That said, there’s no universal rule for which type of evidence always wins. Depending on the decision you're making and what data you already have, even the same piece of evidence could shift categories. You don’t need a perfect catalog of signal strength. What you do need is a shared understanding as a team—something like “we prioritize direct user interviews over competitor launches.”
When it comes to choosing the right experiment, don’t jump to your favorite tactic right away. Start by writing down the assumptions that must be true for an idea to work. Only then should you decide on how to test them. Most teams do this backwards—they run the same kind of test every time and then wonder why they’re not learning much.
Here’s a quick distinction to keep in mind:
Assumption: Something you accept as true (without proof).
Experiment: A methodical way to prove or disprove that assumption.
Later in this chapter, we’ll walk through how to structure your experiments so they actually give you confidence—not just check a box.
Refining Validated Ideas
Product Discovery rarely moves in a straight line. Even after you validate something, there’s a good chance you’ll need to take a step back—maybe to ideation, maybe to research. That’s not failure. That’s how real progress happens.
Let’s say your team has validated a few assumptions and ideas. You’re ready to turn them into something shippable. Now you enter one of the most critical—but often overlooked—phases: refining the concept for actual delivery.
That scrappy prototype you threw together for testing? It probably cut corners. Maybe it looked rough. That’s fine for testing. But before you hand anything to engineering, you need to clean it up. Polish it just enough to avoid unnecessary confusion or tension during implementation.
You’ll also need to slice the concept into shippable pieces. This means translating your validated idea into user stories, defining releases, and scoping for value—not just for deadlines. Don’t fall into the trap of launching a watered-down version of everything you originally imagined. That’s not a true MVP—that’s a half-baked feature dump.
A real MVP focuses on a reduced scope, not reduced quality.
Make slicing a collaborative task between product, UX, and engineering. Every decision should reflect both user needs and technical realities.
Bottom line: Your backlog should be shaped by the most urgent user problems—not by someone’s favorite feature.
Chapter 3: Product Discovery Techniques and Frameworks
In this chapter, we’ll cover the techniques that help Product Teams move with clarity and confidence through the Discovery process.
Key Takeaways:
How to use Mission Briefing and Impact Mapping to navigate problem and solution spaces
How to translate user insights into actionable outcomes with Actor-Jobs-Outcome-Mapping
Earlier, I shared a few of my go-to questions for assessing a team’s understanding of the problem space. Here are the ones I like to use when navigating the solution space:
Which feature ideas are most likely to shift user behavior in a way that supports business goals?
Which assumptions are behind your top three ideas?
Which of those assumptions are most critical?
Which ones are still unproven?
What’s the leanest test you could run in the next ten days to validate or invalidate those assumptions—without writing a single line of code, if possible?
The Mission Briefing
The Mission Briefing comes from Stephen Bungay’s book The Art of Action, where he explains how military leaders set up their teams for autonomous execution. They didn’t micromanage—they created alignment without dictating every move.
Here’s the gist of Bungay’s approach:
Define and communicate intent from the top.
Let teams adjust their actions within that intent.
Each layer owns the “how” of execution and reports back via a “back brief.”
It’s been adapted in product circles for years. I use a slightly modified version to help teams align during Product Discovery. It has five core elements:
The Context – What’s going on, internally and externally, without opinions or solutions.
The Higher Intent – What broader goal this Discovery effort connects to.
The Team Intent – What success looks like for this team, specifically.
The Key Implied Tasks – What naturally follows from the intent (but not in checklist form).
The Boundaries – What constraints, limitations, or non-negotiables exist.
Work through each section together. Don’t move on until you’ve aligned on the current one. One decision can dramatically shift the others.
Impact Mapping
Impact Mapping is one of the best tools for connecting tactical feature ideas to big-picture goals. It creates a logical thread from business objectives to user behaviors to potential solutions.
Originally introduced by Gojko Adzic, I’ve tailored the approach to better support Discovery and outcome-thinking.
This framework helps you avoid the trap of jumping straight from business needs to “we need a mobile app.” Instead, it forces you to map the impact you want to achieve, the actors involved, and the outcomes you need to see—before you even talk about solutions.
At a high level, it’s structured around five levels:
Making Discovery Work: Why Impact Mapping Matters
Each level of the Impact Map represents a key piece of the Product Discovery puzzle. And because of that, it’s one of the most practical ways to structure how your team explores both the problem and solution space.
Here’s what makes it valuable in practice:
It helps you connect the dots. Strategic guidance, research insights, ideation outputs, test results—they all find their place in a shared context. No more floating documents or ideas with nowhere to land.
It keeps you from skipping steps. Teams and execs often want to jump straight from a vague goal like “increase retention” to building something. Impact Mapping forces you to walk through what needs to change—and why—before chasing solutions.
It supports day-to-day decisions without losing sight of the big picture. That means you can focus on the next test or prototype while still staying grounded in how it contributes to broader goals.
The best part? This isn’t just a neat diagram for a workshop. Most of your Discovery efforts—alignment, interviews, prototypes, experiments—can be mapped directly onto this structure.
When you flip the visual upside down, it changes how teams think. Instead of starting with what to build, you’re forced to confront what change you’re trying to make and for whom.
From Impacts to Experiments: Making Every Layer Count
Whether you're aiming to move the needle on something like “average number of posts per iOS user” or “number of posts that include an image,” the decisions you make around Product Discovery will look different.
Why? Because those Impact goals shape how you segment users, what behaviors you care about, and how you interpret feedback.
For example:
If your target is image-rich content, you’ll zoom in on users who already attach media. What’s stopping others from doing the same?
If your focus is post frequency, your audience is already narrowed down to a platform segment—and your job becomes understanding what drives or blocks consistent use.
Your chosen Impact influences everything: who you talk to, which problems you prioritize, and how you validate your assumptions. The less clarity and testing you have around Outcomes, the more likely your Outputs will fall flat.
This is where Impact Mapping really proves its worth.
It’s not just a decision-making tool—it’s a powerful input into OKRs. When teams use Impact Mapping to connect the dots between evidence, action, and strategy, they’re able to articulate how their work ladders up to broader company priorities.
To help illustrate how Impact Mapping aligns (and differs) from other popular product frameworks, I’ve created a comprehensive comparison overview—something I regularly walk through in workshops and planning sessions.
Note: This is part of the approach I teach in my Adaptable Product Discovery program, where we use tools like Impact Mapping to bring structure and clarity to the messy problem space.
The Idea Validation Grid
Once you’ve got an idea worth testing, it’s time to shift from general alignment to execution. And just like research methods, there’s no single “best” experiment to jump into. The key is knowing why a specific experiment makes sense for the current questions you’re trying to answer.
The Idea Validation Grid gives teams a structured way to make that decision—and to explain it to others. It’s helpful for resourcing discussions, but it also sharpens collaboration with peers across design, engineering, data, and beyond.
Here are the five components that make the Grid work:
Idea Description – A clear, concise summary of what you want to test.
Prioritization Score – Use a method like ICE (Impact, Confidence, Effort) to reflect how valuable or realistic the idea is.
Assumptions List – What must be true for this idea to succeed? These are the user behaviors or business results you're betting on.
Behavior Link – Describe how the idea drives a specific, desirable change in user behavior.
Experiment Setup – Define the test you’ll run to validate the assumptions, including what success looks like.
You don’t need to use this exact format, but I’ve seen this version work well for both junior and senior product teams. It’s just enough structure to make discussions productive—without turning experimentation into a bureaucratic mess.
Validating Ideas, Not Just Experiments
One key difference between the Idea Validation Grid and many other frameworks is that it centers on the idea itself—not just the test. It’s not about validating something for the sake of checking a box. It’s about pressure-testing whether an idea can actually create user and business value. That’s the point of Discovery.
Actor-Job-Outcome Mapping
During Discovery, teams encounter all kinds of user insights: behaviors, requests, friction points, and sometimes deep motivations. These insights are valuable—but they’re not immediately actionable.
Turning raw insights into real impact takes an extra step. You need to interpret what the insight actually means in terms of user behavior change. That’s where Outcomes come in. They help teams shift from "what we heard" to "what we need to change."
An Outcome is a measurable signal that helps you understand whether you’ve both solved a real user problem and moved the business forward. It’s not just “we launched a new feature”—it’s “we helped users complete a task faster,” or “we increased retention by removing friction.”
And while this all sounds neat and logical, real user behavior doesn’t unfold in a straight line. Discovery work is messy. That’s why you need a mapping technique that brings clarity to the chaos—one that helps you see what you’ve got and what’s still missing.
That’s where Actor-Job-Outcome Mapping comes in.
This model blends elements from Impact Mapping and jobs-to-be-done thinking. It connects ACTORS (who you’re serving) with OUTCOMES (what change you need), using real-world jobs and motivations as the bridge.
It helps teams answer questions like:
Who is experiencing the problem?
What job are they trying to get done?
What’s blocking them?
What change in behavior would indicate we’ve solved that?
The beauty of this approach is that it works even when your insights are incomplete. You can map what you know, see where the gaps are, and plan your next research or experiment accordingly.
Don’t Just Map What You Know—Map What You’re Missing
Maybe you already understand the core motivations and problems your main Actor faces. Great. But what about other barriers that might be blocking the same motivation? Or new motivations entirely—ones you didn’t spot during your initial research?
What if you’re missing an entirely different context that could help unlock more impact for that Actor?
And remember—your Impact Map likely includes more than one Actor. You’ll need a different set of insights and behaviors mapped for each one. Even if things seem straightforward, mapping what you do know will quickly surface what you don’t. That’s how you spot the real gaps—and figure out which research or validation technique to use next.
Chapter 4: Discovery Practices Reality Check
Let’s wrap this up with a reality check. Product Discovery needs to work for your team, inside your company, in your industry. So let’s talk about individual starting points and the false “best practices” that get recycled without context.
Your Main Takeaways:
Why interview and experiment cadence alone don’t mean you’re making real progress
What to focus on when getting started in your specific environment
Perfect Conditions Rarely Exist—and That’s Fine
Everything in this guide is designed to help you start or evolve your Product Discovery process using real-world examples and flexible tools. But here’s the truth: your work environment won’t be perfect. And that’s OK.
This isn’t about doing everything “by the book.” It’s about progress. In your context. With the tools and people and constraints you have.
The worst mindset you can adopt is: “If I can’t do this the ‘right’ way, I shouldn’t do it at all.” That’s a trap. Even small changes to how your team approaches Discovery will help you build better products, faster, and with more confidence.
No, You Don’t Need to Talk to Customers Every Week
That “talk to one user a week” mantra? It’s catchy, and sure, it helps nudge orgs toward more user focus. But as a tactical rule, it’s flawed.
Talking to users regularly is good. But forcing a weekly cadence can backfire—fast.
Why? Because it makes teams reactive. You hear a user complaint on Tuesday and feel pressure to act by Friday. Not every problem is worth solving. Not every opinion deserves a ticket.
The point of Discovery isn’t to stack up anecdotes—it’s to understand the behaviors and obstacles that matter strategically. If you’re scrambling to meet a weekly quota of interviews, chances are you’re not talking to the right users. You’re just scratching whatever itch showed up most recently.
And when you start chasing every problem you hear, it becomes harder to commit to anything. Endless feedback becomes noise.
Bottom line: stay in touch with your customers, yes. But don’t confuse calendar discipline with insight quality.
Experimenting Isn’t About Numbers—It’s About Insight
Here’s another myth that needs a reality check: “We need to run more experiments.”
Sounds productive, right? But it’s not the number of experiments that matters. It’s whether those experiments actually teach you anything that changes what you do next.
Running 10 experiments doesn’t mean you’re doing good Discovery. It just means you weren’t coding.
What does matter:
Did the experiment target the right assumption?
Did it yield a clear, actionable result?
Did it increase your confidence in an idea—or kill a bad one early?
If the answer is no, then you’re just running laps in a different hamster wheel.
Discovery is supposed to get you out of the feature factory, not into an “experiment factory.”
Final Takeaway: Context Beats Best Practice
Don’t chase someone else’s checklist. Don’t mimic frameworks just because they’re popular. None of this is about hitting some golden metric of how many interviews or experiments you log each quarter.
It’s about building enough evidence to answer two questions:
Is this a real problem worth solving?
Is this solution likely to work?
That’s the work. Not the rituals. Not the optics. Just decisions, made with confidence, because you’ve earned that confidence through thoughtful, contextual Discovery.
