Can an AI agent actually run a credible content audit end to end? I put that to the test. In my role leading product at a high-growth SaaS and as a hands-on content strategist, I’m constantly balancing depth with reach. During a recent office-hours discussion, someone asked me to zoom out and explain when to use Claude Code. That prompt inspired me to launch a running series—Conversations with Claude—showing exactly how I apply it to real product management and SEO problems.
I’m a heavy user and share what works for me. I receive no compensation from Anthropic for this series; if that ever changes, I’ll disclose it. With that out of the way, let’s dive into how I had Claude conduct a full content audit—and why the results exceeded my expectations.
For the first installment, I chose a fairly complex use case: a comprehensive content audit of my site. I expected this to be a slog. Instead, it was refreshingly fast and rigorous once I set Claude up with the right scaffolding.
I kicked off with a simple directive: start by asking clarifying questions, proceed step by step, and capture notes in a shared task file. I also provided deep context—specifically, the CDH Book (15 chapters + intro) and my entire blog archive in markdown—so the model could reason with my actual corpus rather than guessing from sparse prompts.
Claude began with smart clarifying questions that framed the analysis well. Scope of keywords: Should it focus strictly on concepts unique to or heavily associated with my work like "opportunity solution tree" and "continuous discovery," or also include broader product management terms such as "product outcomes," "assumption testing," and "customer interviewing"? Keyword geography: Start with US-only or include UK/global? Blog coverage assessment: What counts as "well covered"—dedicated deep dives or credible coverage within broader posts? Output format: Add findings to the task file or create a separate deliverable?
Peek inside a Notion-style page that turns content strategy into action: a content-audit task with due date and tags, plus clear steps for keyword research, blog gap analysis, and SEO improvements.
I replied: 1. both 2. us only is a good place to start 3. evaluate this based on how well we rank for the keyword, if we rank reasonably well, you might suggest content improvements to rank better, if we don't rank at all, then you might suggest a whole new article 4. add to the task file
From there, Claude read the CDH Book, extracted roughly 100 keywords, ran them through Keywords Everywhere in two batches of 50 to capture search volume, and pulled current domain rankings and traffic metrics. Within minutes, I had a high-signal view of what’s working, where we’re invisible, and how to prioritize fixes.
The good news came first: we own our branded terms—#1 for "product discovery," "opportunity solution tree," "continuous discovery," and "product trio." That brand equity is doing real work for us.
The biggest gaps were in broad topics the CDH Book covers but where there’s no targeted content. "Outcomes vs outputs" (1,300/mo) — Arguably THE central thesis of CDH, and no ranking. This is the single biggest gap. "Product roadmap" (4,400/mo) — I have a strong anti-roadmap POV but no content targeting this. "Product strategy" (1,900/mo) — Ch 7 argues strategy = opportunity selection. Strong differentiator, no ranking. "Story mapping" (5,400/mo) — I use story maps uniquely (for surfacing assumptions). Huge volume. "Stakeholder management" (2,900/mo) — Ch 13 is entirely about this. No ranking. "Pre-mortem" (4,400/mo) — I cover this as a product discovery technique. No ranking.
Inside a dark-themed writing workspace, a long-form chapter is open while a tidy folder tree catalogs pages and chapters. The scene invites readers to think like auditors—inventory content, track structure, and surface gaps with AI assistance.
The trojan horse opportunity: High-volume generic terms like story mapping, pre-mortem, and usability testing could bring in readers who don't know about CDH yet. Write about these broadly-searched topics with my specific product-discovery angle.
In just a few minutes, Claude generated an analysis of what keywords we ranked for and at what position, a ranked set of high-, medium-, and lower-volume (but strategic) keywords where we didn’t rank yet had relevant content, concrete net-new topics to close the gaps, and a list of existing articles to update to lift their SERP positions. It worked far better than I expected.
Here’s how I set it up so the model could deliver: I didn’t simply ask Claude.ai to "audit my site" and hope for the best. I supplied rich, relevant context (my book and all blog posts as markdown) so it could anchor on my language, frameworks, and mental models. I paired that with live data via APIs like Keywords Everywhere to ground recommendations in actual search volume and competitive rankings. With the right inputs, Claude Code behaved like a capable research analyst and an SEO strategist—able to reason, prioritize, and suggest high-leverage actions.
Next, I went deeper and used the findings to draft a long-form article that addresses the biggest gap—"Outcomes vs outputs"—and ties it directly to product roadmapping and sprint planning. I wove in continuous discovery practices, opportunity solution tree techniques, and product trios collaboration to make it actionable for empowered product teams. I’ll share the end-to-end workflow—including files, prompts, and the editorial QA checklist—in a follow-up.
If you’re new to Claude Code and want a practical starting point, replicate the setup above: assemble your canonical sources in markdown, define a clear evaluation rubric, and ground keyword research with reliable volume data. If you want my exact task file, clarifying-question template, and step-by-step audit rubric, tell me which content gap you’d prioritize first and why—I’ll tailor the walkthrough to the highest-interest topic.
I’m seeing the same pattern in product orgs everywhere—inside HighLevel and across my network: everyone is racing to add AI to the roadmap, and every stakeholder has a strong opinion about what to build next. Delivery has never been faster, which makes it dangerously easy to confuse speed with progress.
When we chase features without grounding in continuous discovery, we drift back into a feature factory. We ship more, but we ship the wrong things faster. The antidote is simple and hard at the same time: recommit to product discovery, validate with assumption testing, and let the evidence steer our AI Strategy—not the hype.
Of course, that only works if we can bring our stakeholders along. In the AI moment, it’s deceptively easy to get to a slick prototype and painfully hard to harden it for production. Early demos make almost any idea look promising. That’s precisely why stakeholder management must evolve from pitching solutions to showing our work.
In practice, stakeholder management is about alignment with the people who influence our product decisions—executives, sales, marketing, customer success, engineering leadership, and sometimes legal or finance. Some have veto power; others have input. Knowing who can block versus who can shape is crucial for where we spend our time. Even in empowered product trios, the best discovery can derail if we reveal only conclusions at the end.
I’ve tried every mapping framework—power-interest grids, RACI matrices—and they help. But the real challenge isn’t identifying stakeholders. It’s figuring out how to bring them along so that our product roadmapping and sprint planning decisions stick.
Identify who shapes your product decisions. This visual groups stakeholders into three tiers—those with veto power, key influencers, and audiences to inform—so teams can align, communicate, and reduce delivery risk.
Here’s the most common trap I see (and have fallen into): focusing stakeholder reviews on the roadmap, release plan, or prioritized backlog. That invites an opinion battle. And stakeholders have their own conclusions—usually shaped by the last customer call, a board meeting, or a market headline.
This is how the HiPPO dynamic gets created. HiPPO stands for the “Highest Paid Person’s Opinion,” and the saying goes, “The HiPPO always wins.” When we present conclusions without the journey, we set ourselves up to lose. In the gen ai rush, the chorus of “everyone is doing AI” makes that opinion even harder to counter.
So I don’t try to win opinion battles. I bring new information—fresh customer interviews, clear opportunity mapping, and results from assumption tests. The gap between what the market hypes and what customers actually need is often enormous. Our edge is evidence.
The strategy that consistently works for me is simple: show your work. If you’re practicing continuous discovery, your opportunity solution tree isn’t just a thinking tool—it’s your strongest stakeholder management asset. It helps you build confidence in your decisions, and it can help your stakeholders build the same confidence.
Avoid the stakeholder trap of selling conclusions. This visual shows how anchoring on solutions invites HiPPO battles—and how to shift the conversation by sharing discovery evidence, insights, and data.
Step 1 — Start with the outcome. I open every conversation by restating the shared goal and asking whether anything has changed. Anchoring on outcomes vs output OKRs reframes hot-button solution debates (like “we need an AI feature”) back to what will move the needle on the outcome we agreed to pursue.
Step 2 — Share the opportunity space. I show how we mapped customer needs, pain points, and desires. Then I ask, “What did we miss?” Stakeholders often surface opportunities we haven’t seen yet—signals from the field, market shifts, or partner feedback. I capture their input and commit to validating it in upcoming customer interviews.
Step 3 — Walk through prioritization. Using the tree’s structure, I explain why we prioritized one branch over another. Then I ask where they might have chosen differently. This turns debate into collaboration and lets me leverage their expertise without ceding the discovery framework.
Step 4 — Go deep on the target opportunity. Before we talk solutions, I make the customer’s problem vivid and real. Interview snapshots help stakeholders empathize and see what matters most. Once the opportunity is crisp, solution discussions become dramatically more objective.
Show your work, not just your conclusions. This infographic guides product teams through seven steps to build stakeholder confidence—align on outcomes, map opportunities, prioritize, test assumptions, and repeat.
Step 5 — Share solutions and invite theirs. I present our solution set and explicitly ask for additional ideas. If their suggestions diversify our set, we include them. Solution ideas are cheap; the opportunity is what matters. This is where product trios can benefit from leadership’s pattern recognition and industry context.
Step 6 — Share your assumption tests and results. I walk through our story maps, high-risk assumptions, and what we’ve learned so far. I invite stakeholders to add assumptions—this is where their knowledge shines. If we have data, we share it; if we’re pre-data, we share the plan to get it and ask for feedback.
Step 7 — Repeat. I don’t batch this into a big reveal. I keep a steady cadence and tailor depth to each audience: weekly for my manager, monthly highlights for marketing, and concise updates for executives. Continuous discovery pairs with continuous stakeholder management.
Showing your work doesn’t mean drowning people in detail. It means tailoring the signal to the audience. My rule of thumb is outcome, opportunity, solution, evidence—walk the lines of the tree at the right altitude for each stakeholder.
Show your work the right way for each stakeholder. Use a smart filter to turn discovery noise into clear signals—weekly journeys for your manager, focused monthly highlights for marketing, and a 30-second CEO pitch.
In a 30-second update with a CEO, it might sound like this:
“Our goal is to reduce time-to-first-value for new users. We’ve been interviewing customers and learned that onboarding is where most people get stuck—specifically, they don’t know which features to try first. We explored a few approaches and tested them. The most promising one is a guided setup flow that adapts based on the user’s role. In early tests, new users completed onboarding 40% faster.”
That pattern works across channels—Slack updates, monthly reviews, or quarterly planning. The format flexes, the structure doesn’t: outcome, opportunity, solution, evidence.
As you adopt this approach, watch for four anti-patterns that quietly erode trust.
Avoid the traps that erode stakeholder trust. This infographic guides product teams to show their work, welcome ideas, provide frequent updates, and prioritize results over ideology to build alignment and credibility.
Anti-pattern 1 — Telling instead of showing. The curse of knowledge makes our conclusions feel obvious to us and opaque to others. The fix: slow down, start at the top of the tree, walk the decisions, and let stakeholders reach the conclusion with you.
Anti-pattern 2 — Shooting down stakeholder ideas. As you build a library of validated assumptions, it’s easy to spot flaws in a suggestion and say “no” too quickly. Instead, place their idea within your discovery framework. If it maps to a different opportunity, say, “That idea has promise—we’ll consider it when we address that opportunity.” If it rests on risky assumptions, story map the idea together, list the assumptions, and share what you’ve already learned. People accept the evidence they help generate.
Anti-pattern 3 — Saving everything for a big reveal. Infrequent, comprehensive updates invite opinion battles because stakeholders have formed their own conclusions in the dark. Short, frequent updates build alignment as the work unfolds.
Anti-pattern 4 — Fighting the ideological war. Sometimes a more senior stakeholder will overrule you. Don’t turn it into a debate about how product decisions “should” be made. Focus on the decision at hand, do the best work within constraints, and let results—not ideology—prove the value of discovery over time.
Shift from selling to showing. This co-creation guide invites stakeholders into discovery, taps their expertise, and turns relationships from obstacles into partnerships for smarter product decisions.
Here’s the mindset shift that changes everything: stakeholder management is a co-creation opportunity. When we show our work with artifacts like an opportunity solution tree, experience maps, and interview snapshots, we’re not just communicating—we’re inviting collaboration. We’re leveraging stakeholders’ expertise, context, and connections to make better product decisions.
When stakeholders have walked the path with us, they don’t need to be sold on the destination. They become allies. Engagement stops being a status ritual and starts being real partnership—the kind that moves outcomes and builds durable trust.
Try this in your next review: don’t start with your roadmap. Start at the top of the tree. Reaffirm the outcome. Share the opportunity space. Explain your prioritization. Show what you’re learning. Invite contribution. You might be surprised how quickly alignment—and confidence—follow when you stop selling conclusions and start showing your work.
Ever feel like your product team is “lost in the woods”? I’ve certainly been there—when strategy gets fuzzy, outcomes drift, or constraints aren’t clear. What helped me reframe the chaos was borrowing “lost person” patterns from search-and-rescue and mapping them to product strategy, product discovery, and team behaviors. The result is a practical playbook for product management leadership that keeps empowered product teams moving toward outcomes—not just outputs.
Listen to this episode on: Spotify | Apple Podcasts
Here are the five patterns I see most often—and how I turn each one into forward motion: settle in place (freeze), chase shortcuts, follow the first visible path, use your own navigation (intuition/taste), and retrace your steps. Each of these has a smart, minimal move that helps teams reorient fast without abandoning continuous discovery or product strategy discipline.
Settle in place (freeze). Sometimes the smartest move is to stop. When my team lacks context or authority, I pause delivery work and escalate instead of improvising fixes. This prevents thrash, protects focus, and creates the air cover we need to realign outcomes vs output OKRs.
Chase shortcuts. Shortcuts can be brilliant—or overconfident. I’ve learned to pressure-test whether the “road” is where we think it is before we commit. That means lightweight experiments, clear exit criteria, and the humility to pivot. Think about big bets like Spotify podcasts: compelling vision, but you still have to validate assumptions step by step.
Follow the first visible path. The obvious option isn’t always the best one. My job as a product leader is to make multiple paths visible before we choose. I lean on opportunity solution trees and KPI trees (or driver trees) to surface alternatives, align stakeholders, and keep empowered product teams focused on customer impact and product-market fit—not just the loudest idea.
Use your own navigation (intuition/taste). Judgment matters, especially for product trios making fast calls—but it’s not a replacement for evidence. When my “compass” conflicts with what we observe, I anchor back to customer interviews, rapid tests, and discovery loops. Intuition should guide where we look, while data validates how we proceed.
Retrace your steps. When we’re drifting, I go back to what used to work: principles, quality practices, and discovery habits as feedback loops. Returning to fundamentals—clear problem statements, crisp value propositions, and disciplined outcomes—rebuilds momentum fast.
Team prompt to try: If your team is “lost” right now, which pattern are you defaulting to—and what’s the smallest move you can make this week to get oriented (escalate, test a shortcut, map options, validate intuition with evidence, or retrace to a principle)? I use this question in weekly reviews to keep us grounded in continuous discovery and product strategy.
Resources & Links:
Follow Teresa Torres: https://ProductTalk.org
Follow Petra Wille: https://Petra-Wille.com
Mentioned in the episode:
Lost Person Behavior: A Search and Rescue Guide on Where to Look – for Land, Air and Water
Robert J. Koester
Examples referenced: Xerox, Nokia, Kodak, Volkswagen emissions scandal, Spotify podcasts, large-org tooling contexts like Oracle and SAP
Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes
KPI Trees: How to Bridge the Gap Between Customer Behavior, Product Metrics, and Company Goals
Let's Read Continuous Discovery Habits Together (January 2026) for Continuous Discovery Habits (and the idea of habits as feedback loops)
Shifting from Outputs to Outcomes: Why It Matters and How to Get Started
I’d love to hear how your team navigates these patterns. Which small move will you try this week? Leave a comment below and let’s compare notes on product discovery, stakeholder management, and product roadmapping that actually drives outcomes.
I’m thrilled to invite you to our March session of the CDH Book Club. Continuous Discovery Habits turns five this year. And to celebrate we are reading the book together. I’ve seen firsthand—leading product trios and empowered product teams—that sharpening our discovery habits is the fastest way to better outcomes vs output OKRs, tighter team alignment, and more confident product strategy.
Each month, I am releasing an in-depth reading guide that includes:
The chapters we will be reading
A preview of the most important concepts we'll be learning about
Short videos you can share with friends and colleagues to help spread the ideas
Individual and team discussion questions to help you absorb and engage with the reading
Team exercises to help you put the ideas into practice
Additional reading to help you go deeper on the core ideas
We’ll be discussing each month’s reading in the comment section and we’ll gather quarterly to discuss on a live call. I’ll be there to trade notes, compare experience maps, and share what’s working across product discovery practices.
Joining late? No problem. I monitor the comments on each reading guide throughout the year. Start with the current month or go back to January—whatever works for you. You can ask for help, share what’s working, and connect with other readers at any point.
If you want to participate, grab a copy of the book (or dig up your old copy), share the "Spread the Love" videos, reserve some time to do the team exercises, and register for the community sessions. Let’s do this!
This Month’s Reading
Chapters:
Chapter 4: Visualizing What You Already Know
Estimated reading time: ~14 minutes
This chapter will introduce you to:
Why starting individually—rather than as a group—is the fastest path to unlocking your team’s collective intelligence
How drawing (even badly) forces you to get specific in ways that words never will
The strategic choice of setting your experience map’s scope—too narrow and you miss opportunities, too broad and you lose focus
How diverse perspectives become your team’s secret weapon when you know how to synthesize them
Why your first experience map isn’t truth—it’s a hypothesis you’ll test and evolve with every customer conversation
Need a copy? Grab the book.
Share the Love with Friends and Colleagues
We learn best in community. Use the following short videos to share the key concepts from this chapter with friends and colleagues. Invite them to participate in the book club with you. In my teams, these quick hits help us align faster before we co-create an experience map or opportunity solution tree.
Visualize your thinking – To bring others along
Unlock team alignment – With visualizations
Reflect & Discuss What You Read
When we reflect and discuss what we read, we absorb more of the material. It helps us put what we learn into practice. Don’t skip this step. In my own practice, the real unlock came when I treated mapping as a living artifact that shapes customer interviews, not a one-off deliverable.
Most of us believe we work collaboratively, but we’ve never truly experienced what it means to build shared understanding from diverse perspectives. This chapter challenges you to get uncomfortable—to draw when you’d rather talk, to work alone before working together, and to see your maps as living documents rather than one-time deliverables.
Individual Reflection
Think about the last time your team tried to align on what you know about your customers. Did everyone start by creating their own perspective first, or did you jump straight into a group discussion? What happened as a result?
When was the last time you drew something at work? What stops you from using drawing as a thinking tool—is it discomfort with your drawing skills, lack of time, or something else?
Look at your current work. If you were to create an experience map right now, what scope would you choose? How does your desired outcome help you determine what to include and what to leave out?
Team Discussion
As a trio, each person should identify one unique perspective they bring to your team’s understanding of your customer. How might these different viewpoints create blind spots if you only relied on one person’s view?
When your team disagrees about what customers need or want, how do you typically resolve it? Do you debate until someone wins, defer to the most senior person, or test your different hypotheses?
Does your team have a current experience map? If so, when was the last time you updated it based on what you’re learning from customers? If not, what’s preventing you from creating one?
Put It Into Practice
Understanding why experience maps matter is different from actually creating one that drives your discovery work. These exercises will help you practice the discipline of starting individually, synthesizing diverse perspectives, and using your map to guide customer conversations. My suggestion: timebox, embrace imperfect drawings, and let the artifact lead your next interview script.
Exercise: Create Your Individual Experience Maps
Time: 20 minutes individually, 45–60 minutes with your team
Do this: Individually first, then share with your trio
Start by agreeing on the scope of your experience map based on your current outcome. Each member of your trio should then independently create their own experience map using pen and paper (or your favorite digital drawing tool).
Focus on drawing the customer’s experience, not your product’s features. Where do they get stuck? What goes wrong? How do they work around problems? Don’t worry about drawing well—boxes, arrows, and stick figures are perfectly fine.
Once everyone has created their individual maps, schedule time to share them with each other. As you explore each person’s perspective, ask questions to understand their thinking. Pay particular attention to the differences between maps—this is where the richest insights emerge.
Exercise: Co-Create Your Shared Experience Map
Time: 30 minutes with your team
Do this: With your product trio
Bring your individual experience maps together and work to synthesize them into a single shared map. Start by identifying all the unique nodes (distinct moments, actions, or events) across all three maps. Arrange them in a comprehensive flow.
Collapse similar nodes, but be careful not to overgeneralize. Add links to show relationships and flow between nodes—including loops, error cases, and abandonment points. Finally, add context about what customers are thinking, feeling, and doing at each step.
As you work, avoid getting bogged down in endless debate. If you disagree about details, draw out the difference rather than debating it. This often reveals you already agree or helps you pinpoint exactly where your understanding differs.
Remember: This map is your current hypothesis about your customer’s experience. Use it to guide your upcoming customer interviews and plan to evolve it based on what you learn.
Go Deeper: Additional Reading
If you prefer an audio summary of this month’s reading, including the book chapters and the following resources, I’ve included an audio version for paid subscribers at the bottom of this post.
Supplementary Reading
Why Drawing Maps Sharpens Your Thinking
Core Concept: Collaborative Decision-Making in a Product Trio
Other Voices
To Draw or Not to Draw: Is Traditional Sketching Still Relevant in the Digital Design Era? by Julia Ku
Journey-Mapping Approaches: 2 Critical Decisions to Make Before You Begin by Kate Kaplan
The Visual Language of Comic Books Can Improve Brain Health by Mary Widdicks
Mapping Your User’s Day with the User Clock Sketch by Ben Crothers
Our Live Discussion Schedule
Our live discussion sessions are for paid subscribers. Sessions are not recorded. Invitations will go out to Supporting Members and CDH Members two weeks before the scheduled event. But reserve the time on your calendar now.
Wednesday, March 18, 2026: 9am–10am PDT and 4pm–5pm PDT
Tuesday, June 16, 2026: 9am–10am PDT and 4pm–5pm PDT
Thursday, September 17, 2026: 9am–10am PDT and 4pm–5pm PDT
Wednesday, December 16, 2026: 9am–10am PST and 4pm–5pm PST
Audio Summary
This summary was produced by NotebookLM. The sources supplied were the book chapters as well as all of the additional reading.
Listen here: March — Draw the User Clock to Build Empathy (audio)
This article is part of the CDH Book Club celebrating the five-year anniversary of Continuous Discovery Habits. See all book club posts.
Your team probably doesn’t lack discovery techniques. It loses discovery when delivery becomes urgent. Customer contact clusters around planning, the team commits to a solution, the calendar fills, and assumptions quietly harden into backlog items. Everyone stays busy, but no one can point to the customer evidence behind the next decision.
Durable continuous discovery is an operating rhythm, not a research phase. The goal isn’t to conduct more interviews. It is to shorten the distance between customer reality and the decisions shaping your product. A weekly rhythm owned by a product trio can reduce rework, sharpen strategy, and keep discovery alive while delivery continues.
See your real discovery system before changing it
Adding a recurring customer interview to the calendar won’t fix a decision process built around handoffs. If ideas arrive from executives, become requirements in product, move to design, and reach engineering as implementation work, the interview is an extra activity attached to the side of the system. It isn’t part of how the team decides.
Start by making the existing system visible. Map what actually happened, including the awkward shortcuts and informal approvals. Do not draw the process described in a playbook.
Spend 60 minutes drawing how your team decides what to build. Show where ideas enter, who shapes them, who approves them, where customers appear, and how the team decides whether the result worked.
Compare your drawing with the drawings made by product, design, and engineering. Differences are evidence that the team does not share the same decision model.
Audit every product decision from last week in a 30-minute session. Include small decisions, not just roadmap commitments.
For each decision, record who made it, what information informed it, and whether the team had direct customer input or received a secondhand interpretation.
Mark the places where discovery and delivery reconnect. A production problem, adoption signal, support request, or implementation constraint can create a new discovery question; it should not disappear into a separate queue.
This process map and decision audit gives you a baseline without turning discovery into a maturity score. Look for the mechanism behind the misses. Perhaps customer input arrives after commitment. Perhaps the product manager is the only person who interprets it. Perhaps the team can describe the solution but not the opportunity it addresses.
Track a compact baseline: how recently the team had direct customer contact, which current decisions include direct input, where cross-functional decisions become handoffs, and which active solutions lack a named customer opportunity. Do not set targets yet. First identify where evidence stops influencing action.
If the process looks reasonable but the habit still collapses, inspect the six prerequisite mindsets: outcome-oriented, customer-centric, collaborative, visual, experimental, and continuous. Turn them into diagnostic questions:
Outcome-oriented: Can the team name the customer or business change it is trying to create, or only the feature it plans to ship?
Customer-centric: Does the team hear directly from customers, or mainly through sales, support, analytics, and stakeholder summaries?
Collaborative: Do product, design, and engineering make decisions together, or meet mainly to exchange work?
Visual: Is there one shared representation of the outcome, opportunities, solutions, and assumptions?
Experimental: Can the team name what could make the current idea fail?
Continuous: Does each learning activity lead to the next question, or does discovery end with a presentation?
Choose the weakest link as your first intervention. A team with output-based goals does not need a better interview script first; it needs an outcome that gives the interview a purpose. A team dominated by handoffs needs shared sensemaking, not another repository.
Install a weekly loop small enough to protect
A habit survives because its trigger, action, and output are clear. Put a recurring discovery block at a stable point in the team’s operating rhythm. Tie it to a current outcome and a live decision, not to a general ambition to understand users better.
Trigger: A protected calendar block recurs every week, including during active delivery.
Focus: The trio brings one current outcome, the decision in front of it, and the uncertainty preventing a confident choice.
Customer contact: The team has a direct customer touchpoint every week. That might be a customer interview, observation of a workflow, or a usability session connected to the current question.
Sensemaking: The trio separates what it observed from what it inferred.
Update: New evidence changes the opportunity solution tree or confirms why no change is warranted.
Commitment: The team names the next uncertainty and starts arranging the next customer contact.
A customer touchpoint is not any meeting attended by a customer. A sales demo, account review, or advisory session dominated by presentation may be valuable, but it does not automatically answer a discovery question. The useful test is whether the customer can reveal a real behavior, need, constraint, or reaction and whether the team can ask follow-up questions.
Prepare each touchpoint by completing this sentence: After this contact, the trio might decide whether… If you cannot finish it, the question is probably too broad. Starting with a decision also reduces the temptation to collect interesting comments that never affect the product.
During the interaction, capture concrete observations before interpretations. Afterward, answer five questions while the context is fresh:
What did the customer do, describe, or struggle to explain?
What interpretation is the team placing on that observation?
Which opportunity or assumption does it affect?
What decision changes, if any?
What remains uncertain enough to examine next?
The distinction between observation and interpretation matters. A customer abandoning a task is an observation. Assuming that price caused the abandonment is an interpretation. If the team records only the interpretation, an early guess can become institutional memory.
Recruiting is part of the habit, not administrative work that begins after an interview is requested. Give coordination to a named owner, maintain a rolling pool of relevant customers, and create simple paths for customer success and support to nominate people who recently experienced the problem. Start the next invitation before the current discovery cycle feels complete. Otherwise, every customer cancellation becomes a reason to skip the week.
When delivery pressure rises, protect the trigger and narrow the activity. Ask a smaller question, review a focused prototype, or examine one step in a workflow. Do not silently replace direct contact with an internal meeting and call the habit complete. If a customer cancels, use the protected time to recruit, refine the decision question, and reschedule. Preserve the rhythm without pretending the missing evidence exists.
Give the product trio ownership of decisions, not ceremonies
A product trio is not three people attending the same interview. It is product, design, and engineering sharing responsibility for understanding the opportunity and choosing how to address it. Attendance can rotate. Interpretation and decision-making cannot be delegated to one function and handed back as a deck.
Make the trio’s decision rights explicit at the start of an outcome. Record the outcome it owns, the decisions it can make autonomously, the constraints it must respect, what requires escalation, and where its evidence will remain visible. Without that contract, discovery may reveal a better direction while the roadmap continues unchanged because nobody knows who can act.
The responsibilities below are a practical starting point, not rigid job boundaries:
Product keeps the outcome, strategic context, customer segment, and pending decision visible.
Design helps the trio expose customer behavior, frame opportunities, and choose an appropriate way to learn.
Engineering surfaces feasibility, system behavior, data, and implementation assumptions before the solution becomes expensive to change.
The trio decides what the evidence means, which option remains viable, and what uncertainty deserves attention next.
Use a short shared debrief after customer contact. The format can remain simple:
Observation: What happened without interpretation?
Meaning: What plausible explanations fit the observation?
Decision: What will the trio change or preserve?
Unknown: What still blocks commitment?
This prevents the loudest interpretation from becoming the team’s conclusion. It also gives engineering a role before implementation and gives design a role beyond producing artifacts.
Leadership should ask for evidence of changed decisions, not proof that ceremonies occurred. Instead of asking how many interviews the team completed, ask which opportunity became clearer, which assumption weakened, what decision changed, and how the change connects to the outcome. Interview volume is easy to report and easy to game. Decision quality is harder to display, but it is the reason the habit exists.
Connect discovery evidence to strategy and delivery
A weekly customer conversation can still become theater if its evidence floats separately from strategy, roadmaps, and sprint planning. The opportunity solution tree provides a shared spine: the desired outcome sits at the top, customer opportunities sit beneath it, and candidate solutions connect to the opportunities they could address. That outcome-opportunity-solution structure keeps the team connected to why it is considering a particular feature.
Use the tree as a decision interface, not a workshop artifact:
Product strategy: Put the intended outcome at the top so the team can test whether its discovery work supports the strategic direction.
Roadmapping: Attach candidate solutions to named opportunities. Keep alternatives visible until evidence or a real constraint justifies commitment.
Sprint planning: Require each significant item to trace back to an opportunity and outcome. If it cannot, surface the mismatch before implementation.
Customer contact: Update the affected opportunity, solution, or assumption during the debrief. Do not wait for a separate documentation session.
Stakeholder communication: Show what changed in the tree, why it changed, and which decision follows. This is more useful than presenting a collection of customer quotations.
Keep a record of rejected options and the evidence or constraint behind each rejection. Otherwise, an old idea can return with a new label and consume another round of debate. The record should remain revisable: new customer behavior, technical capability, or strategic constraints can justify reopening a branch.
Measure whether evidence enters decisions
The safest discovery metric is not an isolated activity count. Measure the health of the loop:
Cadence: Did direct customer contact happen during the weekly rhythm?
Decision integration: Which current decision did that contact inform?
Shared ownership: Did the trio participate in sensemaking, even if every member did not attend the session?
Strategic traceability: Can a delivery item be traced to an opportunity and outcome?
Learning movement: Which belief, option, or assumption changed?
A team can conduct many interviews and learn very little if every conversation validates a solution already selected. Conversely, one focused interaction can be valuable when it exposes a faulty workflow assumption and changes a pending decision. Track cadence to protect the habit, but judge value by movement in the decision model.
Separate customer, model, and operational uncertainty in AI products
AI product teams face a specific discovery trap: an impressive model demonstration can make technical possibility look like customer demand. Keep different uncertainties separate so one kind of evidence does not answer a different question.
Customer uncertainty: What job is the person trying to complete? Where does the current workflow break? Under what conditions will the person trust, verify, correct, or reject an AI-assisted result?
Model uncertainty: Does the system produce acceptable behavior for the intended context? Which failures matter to the user, and how will the team evaluate them?
Operational uncertainty: Can the product obtain the required data and permissions? Where is human review needed? How will failures be detected, explained, and supported?
Customer contact can reveal workflow, language, trust conditions, and failure consequences. It cannot prove that the model behaves reliably. Model evaluations can reveal performance and failure patterns. They cannot prove that the workflow is valuable. Operational checks can establish feasibility and controls. They cannot prove adoption. Keep all of these linked to the same outcome while using the right evidence for each uncertainty.
On the opportunity solution tree, write opportunities in customer terms. “Use generative AI” is a solution direction, not an opportunity. “Reduce the effort required to turn a customer conversation into an accurate follow-up” describes a customer problem that could have AI and non-AI solutions. That distinction helps the trio discover value without becoming attached to a technology.
Fix the mechanism when the habit breaks
What you notice
Likely mechanism
What to change
The team talks to customers, but the roadmap never changes.
Sessions are disconnected from a live decision.
Write the decision before recruiting and record what changed immediately after the interaction.
Engineering joins only after discovery is complete.
The trio label is masking a handoff.
Include engineering in opportunity framing, assumption identification, and shared sensemaking. Session attendance can rotate.
Customer sessions repeatedly fall through.
Recruitment starts only after a question becomes urgent.
Maintain a rolling pool of relevant customers and assign coordination to a named owner.
The opportunity solution tree is stale.
The tree is treated as presentation material.
Update it during the debrief and remove or annotate branches that no longer have support.
Discovery pauses whenever delivery accelerates.
Discovery is scoped as a project rather than a continuous rhythm.
Protect the weekly trigger and narrow the question or method when capacity is tight.
Leadership keeps asking the team for certainty.
The team reports activities without showing their decision impact.
Show the outcome, changed opportunity or assumption, resulting decision, and remaining uncertainty.
Do not respond to a broken habit by adding more process everywhere. Match the intervention to the failure. A recruiting problem needs a pipeline. A decision-rights problem needs leadership alignment. A stale artifact needs an update trigger. A handoff problem needs shared sensemaking.
Key takeaways
Map the current decision system and audit last week’s decisions before adding a new discovery ceremony.
Anchor a direct customer touchpoint every week to a current outcome, decision, and uncertainty.
Let attendance vary when necessary, but keep interpretation and decisions jointly owned by the product trio.
Use the opportunity solution tree as the live connection between strategy, customer evidence, roadmap choices, and sprint work.
When delivery pressure rises, protect the trigger and shrink the activity instead of suspending the cadence.
For AI products, do not use customer enthusiasm as proof of model reliability or an evaluation result as proof of customer value.
Put the recurring customer touchpoint on the calendar, choose the outcome and decision it must inform, and name the product trio responsible for acting on what it learns. At the end of the next weekly cycle, do not ask whether the team “did discovery.” Ask what changed in the decision and what the team needs to learn next.
You are looking at a roadmap full of plausible ideas, yet nobody can explain which one is most likely to change customer behavior. Sales has requests, support has complaints, leadership has strategic themes, and the product team has solutions waiting for estimates. Everything sounds important because the outcome has not been made precise enough to disqualify anything.
Outcome-driven product discovery fixes that problem by connecting every roadmap bet to the same chain: business result, customer behavior, opportunity, assumption, experiment, and decision. It gives you a practical way to invest in innovation without turning every interesting idea into a delivery commitment.
Start with the behavior you need to change
A launch is an output. Completing a first meaningful workflow is a behavior. Activation is a product outcome. Retained revenue is a business outcome. Those concepts may sit in the same strategy, but they are not interchangeable.
Start discovery with the product outcome because it is close enough to the customer experience for a team to influence and measure. Then state the business result you expect it to support. That connection is a hypothesis, not an automatic fact. Improving engagement that has no relationship to customer value, retention, conversion, or another meaningful result simply produces a more active feature.
A useful outcome statement has five parts:
Segment: the specific users, accounts, or lifecycle stage whose behavior matters.
Behavior: an observable action that represents progress toward value.
Baseline and target: the current measurement and the change the team intends to produce.
Decision window: when you will review the evidence and decide what to do next.
Guardrail: the metric or customer consequence that must not deteriorate while the primary outcome improves.
Use this template: By [decision date], change [behavior] for [segment] from [baseline] to [target], because that behavior is expected to contribute to [business result], while protecting [guardrail].
Suppose a SaaS team wants to improve new-account activation. The feature-factory version of the goal is to launch a redesigned onboarding checklist. The outcome-driven version identifies the new-account segment, the value-bearing workflow those users need to complete, the current completion rate, the desired change, the review date, and a guardrail such as downstream retention or support burden. The checklist may become one solution, but it no longer owns the roadmap before discovery begins.
Keep three measures visible on the same decision page:
Primary outcome: the customer behavior you intend to change.
Business consequence: the commercial or strategic result that behavior is expected to influence.
Guardrail: the cost, quality, trust, or downstream behavior you refuse to sacrifice.
This is the practical difference between organizing goals around outcomes instead of output and attaching metrics to a feature after it has already been approved. The first approach creates choice. The second decorates a commitment.
Before accepting an outcome, ask four questions. Can the team observe it? Can the team influence it during the decision window? Does it represent customer progress rather than product activity alone? Is its expected connection to the business result explicit? If any answer is no, revise the outcome before collecting more ideas.
Key takeaways
Begin with a measurable customer behavior, not a feature, project, or launch date.
Treat the link between that behavior and the business result as a hypothesis that needs evidence.
Map opportunities before comparing solutions, so requests do not become commitments by default.
Combine segmented customer evidence with product telemetry; neither is sufficient on its own.
Give every experiment a decision rule, a meaningful effect threshold, and guardrails.
Judge discovery by the decisions it changes, including decisions to adapt, delay, or stop a bet.
Map opportunities before you rank solutions
Once the outcome is clear, resist the urge to run an idea workshop. First map the obstacles, unmet needs, and motivations that could explain why the desired behavior is not happening.
An opportunity describes a customer condition. A solution describes something you could build. For example, users abandoning setup because they cannot tell which information is required is an opportunity. A setup wizard, template, tooltip, or assisted service is a solution. Keeping those levels separate preserves more than one path to the outcome.
Translate feature requests with a simple sequence:
Ask which user or account segment is making the request.
Identify the job that person is trying to complete.
Locate the point in the journey where progress breaks down.
Describe the consequence of that breakdown in the customer’s terms.
Connect the problem to the target outcome.
Record the requested feature as one possible solution, not as the opportunity itself.
This translation matters because a request can be accurate about the pain and wrong about the remedy. It can also be valid for one enterprise account but harmful to the broader value proposition. Segmenting feedback by persona, account tier, lifecycle stage, and job prevents unlike signals from being combined into a misleading vote count. A founder, a new user, a power user, and an account approaching renewal are speaking from different contexts.
Build the map with a product trio: product management, design, and engineering working on the problem together. Early engineering involvement exposes feasibility constraints and cheaper implementation paths. Design brings the journey and interaction risks into view. Product management connects the opportunity to customer value, strategy, and commercial consequences. The benefit is shared reasoning, not another recurring meeting.
A practical outcome-driven operating model gives that trio room to investigate opportunities before delivery sequencing hardens. Without it, discovery becomes a product-manager document handed to design and engineering after the consequential decisions have already been made.
Use the following rubric to compare opportunities. Do not collapse it into a single total score. A tidy score can hide a fatal weakness, such as no evidence that the problem exists for the target segment.
Criterion
Decision question
Warning sign
Outcome proximity
If this problem is reduced, what customer behavior should change?
The connection depends on several untested assumptions.
Segment evidence
Which target users experience the problem, and in what context?
The evidence comes mainly from unsegmented requests or one loud account.
Severity and recurrence
Does the problem block value, repeatedly create friction, or merely inconvenience the user?
The team cannot distinguish a recurring obstacle from an isolated preference.
Strategic coherence
Would solving it strengthen the intended value proposition or differentiation?
The solution adds complexity without making the product more valuable to its chosen market.
Learning value
What important uncertainty would pursuing this opportunity resolve?
The team is committing substantial delivery capacity without identifying the risky assumption.
Downside and reversibility
What could break, and how easily could the change be contained or reversed?
Trust, data, operational, or platform risk is being treated as a post-launch concern.
The result should be an opportunity map, not a backlog. A backlog asks what can be built. An opportunity map asks where a change could produce the outcome, what evidence supports that belief, and what still needs to be learned.
Match the strength of evidence to the size of the commitment
Customer interviews alone do not tell you how widespread a problem is. Product analytics alone do not tell you why a behavior occurs. Strong discovery uses each form of evidence for the question it can answer.
Qualitative evidence reveals language, context, motivation, workarounds, and consequences.
Behavioral evidence shows where users progress, hesitate, abandon, return, or differ across cohorts.
Commercial evidence shows how the opportunity appears in sales, expansion, support, renewal, or churn conversations.
Experimental evidence tests whether a specific intervention causes the intended change under defined conditions.
Start with the journey connected to the outcome. Instrument the important steps, inspect funnels and cohorts, and then use interviews, support conversations, community discussions, and sales or customer-success notes to explain the patterns. This combination of telemetry and customer narrative is more useful than collecting more comments without a decision in mind.
When qualitative and quantitative evidence disagree, do not average them into a vague conclusion. Investigate the mismatch. The interview sample may represent power users while the funnel includes new users. The telemetry may be missing an offline step. A workflow may be painful but unavoidable, producing high completion despite poor experience. A small segment may have a severe problem hidden by an aggregate rate. Contradiction is often a segmentation or instrumentation clue.
Create a shared taxonomy so evidence remains usable after the meeting in which it was collected. Tag each item by:
problem statement;
persona or account segment;
job to be done;
journey step;
lifecycle stage;
evidence channel;
related outcome;
confidence and unresolved uncertainty.
Then produce a compact evidence packet for each opportunity under active consideration:
Outcome: the behavior the team wants to change.
Observation: the measured pattern, with its segment and journey context.
Customer explanation: the recurring need, obstacle, or workaround found in qualitative evidence.
Contrary evidence: what does not fit the current explanation.
Current hypothesis: why the opportunity may be causing the behavior.
Largest uncertainty: the assumption most capable of invalidating the bet.
Next decision: what the team will decide after the next learning step.
The required evidence should rise with the cost and irreversibility of the commitment. A reversible wording change can justify a lightweight test. A new core workflow, platform dependency, pricing model, or data-access pattern deserves deeper investigation because mistakes create migration cost, operational burden, customer confusion, or trust damage.
My test is simple: can the team state what evidence would make it change course? If not, the work is advocacy rather than discovery. Evidence is being gathered to support a preferred answer, not to improve the decision.
Run experiments that force a roadmap decision
An experiment is useful only when its result can change what happens next. Before choosing a prototype or test method, write the decision the evidence must inform.
A concise experiment card should contain:
Hypothesis: If [segment] receives [intervention] in [context], then [behavior] will change because [reason].
Riskiest assumption: the belief that would make the solution unattractive, unusable, infeasible, unviable, or unsafe if false.
Method: the least expensive credible way to test that assumption.
Primary measure: the signal that directly answers the experiment question.
Meaningful effect: the smallest change that would justify a different product decision.
Guardrails: the customer, business, quality, or trust measures that must remain acceptable.
Decision rule: the conditions for advancing, adapting, stopping, or gathering different evidence.
Choose the method based on the uncertainty:
Use interviews and observation to understand the job, context, current alternative, and consequence of the problem.
Use concept tests to learn whether the proposition is understood and relevant.
Use clickable prototypes to find comprehension, interaction, and workflow problems before production work.
Use a manual or limited implementation to test whether completing the workflow creates enough value to justify automation and scale.
Use feature flags and progressive rollouts to contain operational risk and inspect real behavior.
Use an A/B test when you need a credible comparison of incremental behavior and have the traffic, instrumentation, and time to run it properly.
Do not ask one method to prove more than it can. Positive interview reactions do not prove adoption. A usable prototype does not prove retention. A short-term click improvement does not prove durable customer value. Each result should earn the next level of investment, not retroactively validate the entire strategy.
For A/B tests, define the minimum detectable effect before launch. This is the smallest difference worth reliably detecting for the decision, not the smallest fluctuation visible in a dashboard. Plan the sample around that threshold, avoid repeatedly checking results and stopping when they look favorable, and carry the analysis into downstream behavior where the hypothesis requires it. Statistical discipline and retention analysis prevent short-lived movement from being mistaken for a product win.
If the available traffic cannot support the planned effect within the decision window, do not run an underpowered test and interpret noise. Reduce the scope, extend the observation period where practical, use a stronger leading indicator, or select a different method. The method should fit the decision environment.
Guardrails deserve the same pre-commitment as the primary measure. An onboarding change that raises completion but also increases early cancellations, support contacts, errors, or later abandonment may have shifted friction rather than removed it. The team should know in advance which trade-offs are unacceptable.
End every experiment with one of four explicit decisions:
Advance: the evidence supports the assumption strongly enough to justify the next investment.
Adapt: the opportunity still matters, but the solution or segment hypothesis needs revision.
Stop: the expected outcome no longer justifies the cost, risk, or strategic distraction.
Reframe: the test exposed an instrumentation gap, a different opportunity, or an assumption that must be investigated first.
A failed solution test can still be a successful discovery decision. The value lies in avoiding a larger, poorly justified commitment.
Turn discovery into the operating system for innovation
Innovation is not measured by how unfamiliar a solution looks. It is measured by whether the team finds a better way to create and capture value under uncertainty. That requires a learning system, not a separate innovation theater filled with demos that never reach adoption.
Give every innovation bet a one-page brief:
the target segment and job;
the behavior and business outcome;
the current alternative and why it is insufficient;
the opportunity being pursued;
the intended value proposition and differentiation;
the riskiest value, usability, feasibility, viability, or trust assumption;
the next experiment and its decision rule;
the owner, review date, and current investment boundary.
This brief lets leadership compare bets without pretending that early ideas have precise forecasts. Mature work can be judged on measured outcome contribution. Earlier innovation should be judged on the importance of the opportunity, strategic fit, quality of evidence, cost of the next learning step, and whether uncertainty is falling fast enough to justify continued investment.
Differentiate deliberately. Some capabilities are points of parity that customers expect. Others are candidates for meaningful differentiation. Treating every competitor feature as strategically necessary fragments the product and consumes capacity that could strengthen the chosen value proposition. First-principles reasoning should establish which customer problem matters before competitive comparison influences the solution.
For AI products, trust belongs inside the outcome
An AI prototype can appear successful while hiding the operational conditions required for a durable product. Add trust and control questions to discovery from the beginning:
What happens when the output is wrong, incomplete, or inappropriate?
Which data can the system access, retain, or expose?
Where does a person need to review, approve, correct, or override the system?
Can the team observe failures and explain consequential actions?
Does the workflow create enough customer value after review, exception handling, and operating cost are included?
Privacy, data governance, transparent controls, and auditability are part of the product proposition, especially when the workflow has meaningful consequences. Moving from an AI demonstration to a durable capability requires evidence about the complete workflow, not just the quality of a favorable output.
Install a cadence that changes priorities
Discovery becomes operational when evidence repeatedly changes allocation decisions. A practical cadence is:
Weekly product-trio review: examine the target outcome, new evidence, contradictions, largest uncertainty, and next decision for active bets.
Monthly cross-functional synthesis: combine themes from product behavior, interviews, sales, support, and customer success; resolve segmentation questions; and identify implications for the roadmap.
Quarterly outcome lookback: compare expected and observed changes in activation, adoption, conversion, retention, or the relevant business result; inspect guardrails; and record which assumptions were right or wrong.
This feedback and synthesis cadence creates organizational memory. It also exposes a hollow process quickly. If repeated discovery reviews never stop, reorder, narrow, or reshape roadmap work, the organization has built a reporting loop rather than a decision loop.
Represent roadmap items as bets, with the outcome, segment, opportunity, evidence, hypothesis, guardrails, owner, and next decision visible. Delivery milestones still matter, but they sit beneath the reason for the work. That makes stakeholder conversations more precise. Instead of asking whether a requested feature made the roadmap, ask which outcome it supports, what problem it solves, what evidence exists, and what would justify investment.
Keep a short decision log after each review. Record the decision, evidence considered, assumptions still open, owner, and revisit condition. This prevents the organization from re-litigating old choices after context has disappeared, while allowing a decision to change when genuinely new evidence arrives.
Take the next substantial item scheduled to enter delivery and try to fill in its outcome statement, opportunity, evidence packet, riskiest assumption, experiment, guardrail, and decision rule. Any field you cannot complete is not paperwork to delegate. It is the uncertainty discovery needs to resolve before the commitment grows.
Do that with one bet first. When the resulting evidence changes an investment decision, use the same structure for the rest of the roadmap. That is the point at which discovery stops being a phase and starts becoming how innovation is managed.
