Tag: opportunity solution tree

  • The Hidden Leadership Skills Product Managers Need Before the Title Change

    The Hidden Leadership Skills Product Managers Need Before the Title Change

    Every product manager eventually confronts the same uncomfortable paradox: Every product manager wants to move into leadership — but nobody wants to hire a leader without leadership experience. I have seen this pattern across product teams at every stage of maturity, and I have felt how frustrating it can be for strong individual contributors who are ready for more responsibility but are still waiting for a formal title change.

    The mistake I see many product managers make is assuming that leadership begins only after promotion. In practice, product management leadership starts much earlier. It begins when we understand what our organization actually expects from its leaders, then deliberately practice those behaviors in the role we already have.

    That first step sounds simple, but it is often skipped. Before I can grow as a leader, I need to know what leadership means in my specific context. Some companies define it through leadership principles, values, management training, or competency models. Others leave it implicit, which means I need to study who gets promoted, ask recently promoted leaders what changed, and observe which behaviors earn trust from executives and peers.

    General frameworks can help. Petra’s Product Leadership Wheel – A Framework for Defining and Growing Product Leadership at Scale, Korn Ferry’s competencies, Gallup, and Amazon’s Leadership Principles all provide useful language. But the most important version is the one inside my own organization. Leadership is not abstract; it is contextual, cultural, and operational.

    One leadership muscle I believe every product manager must build early is the ability to say no with evidence and clarity. Saying no is easy. Saying no well is the skill. The goal is not to become a gatekeeper, reject ideas reflexively, or hide behind process. The goal is to make the reasoning so clear that stakeholders can almost reach the “no” themselves.

    This is where stakeholder management becomes a serious product management leadership capability. When we explain why a request does not align with the strategy, customer evidence, business outcome, or current opportunity space, we are not simply declining work. We are teaching the organization how decisions get made. Over time, that clarity reduces thrash, builds trust, and raises the quality of future conversations.

    The second foundational skill is directional clarity. I think of directional clarity as the ability to help a team understand where we are going, why it matters, and how today’s decisions connect to a larger outcome. It is the crux of leadership because teams do not need leaders merely to assign tasks. They need leaders to reduce ambiguity without pretending certainty exists.

    For an individual contributor, the practical path is incremental. I can start by creating clarity for the current sprint. Then I can extend that clarity across two sprints. Then a quarter. As my product leadership grows, my planning horizon expands from the immediate work to broader customer outcomes, product strategy, and organizational tradeoffs.

    Podcast cover for Episode 67, Stepping Into Leadership, showing abstract connected nodes beside All Things Product text with Teresa and Petra.
    Stepping Into Leadership sets a calm, thoughtful tone with connected-node artwork and bold purple typography for an All Things Product podcast episode with Teresa and Petra.

    This shift can feel strange because the work becomes less concrete over time. Early in a product career, clarity often looks like a prioritized backlog or a crisp sprint goal. Later, clarity looks more like a strategic narrative, a set of outcome-based priorities, and a decision framework that helps teams navigate uncertainty. Getting less concrete over time is a feature, not a bug.

    Tools like the Decision Stack, the Now-Next-Later roadmap, and the Opportunity Solution Tree are useful because they help us communicate at different abstraction levels. The Decision Stack connects company strategy to product decisions. The Now-Next-Later roadmap gives teams a healthier way to plan under uncertainty. The Opportunity Solution Tree helps us connect customer needs, business outcomes, and solution bets without collapsing discovery into feature delivery.

    I also like the metaphor of Powers of Ten because product leadership requires constant movement between levels of abstraction. One moment, I may need to discuss a specific customer pain point. The next, I may need to connect that pain point to a quarterly outcome, a market shift, or a broader product strategy. Strong product leaders know how to zoom in and out without losing the thread.

    The most encouraging lesson is that I do not need a large scope to practice. Even on a team with a narrow mandate, the product manager usually has more business context than anyone else. I can use that context to explain the why behind the work, not just the what. I can connect sprint planning to customer value. I can connect customer value to product strategy. I can connect product strategy to business outcomes.

    That habit compounds. The product manager who consistently creates clarity, communicates tradeoffs, and says no with evidence begins to operate like a leader before anyone changes their title. This is how the IC to manager transition becomes less of a leap and more of a visible progression.

    For me, the practical takeaway is clear: leadership is not something I wait to be granted. It is something I practice in increasingly larger circles of responsibility. I start with my team, my sprint, and my immediate stakeholders. Then I expand toward quarters, outcomes, strategy, and organizational alignment.

    If we want to grow into product management leadership, we need to stop treating leadership experience as something that only appears after promotion. The work is already available to us. We can study our organization’s definition of leadership, practice saying no well, build directional clarity, and use product roadmapping and discovery tools to communicate at the right level of abstraction. That is how we earn trust before the title arrives.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Supercharge Product Discovery: A Practical July Guide to Better Team Ideation

    Supercharge Product Discovery: A Practical July Guide to Better Team Ideation

    Continuous Discovery Habits turned five this year, and I see that milestone as a useful reminder: great product teams do not discover customer value through occasional workshops. We build the habit of discovery through repeated practice, structured reflection, and honest conversations about what we are learning.

    This month, I am focusing on Chapter 8: Supercharged Ideation. For product leaders, product trios, and empowered product teams, this chapter is especially practical because it challenges one of the most persistent myths in product discovery: that traditional brainstorming is the best path to better ideas.

    In my own product management work, I have seen teams move too quickly from opportunity to solution. We often identify a real customer problem, feel the pressure to show momentum, and then rally around the first plausible idea. The problem is not that the first idea is always bad. The problem is that our first idea is rarely our best idea.

    This Month’s Reading

    Chapters:

    • Chapter 8: Supercharged Ideation

    Estimated reading time: ~18 minutes

    This chapter introduces several ideas that matter deeply for product discovery, prioritization, and product strategy:

    • Why quantity of ideas leads to quality – your first idea is rarely your best idea
    • The four reasons traditional brainstorming doesn’t work (and what to do instead)
    • How to generate 15-20 ideas for a single opportunity without getting stuck
    • Why individuals outperform groups at ideation – and how to get the best of both
    • Using dot-voting to whittle ideas down to three for a compare-and-contrast decision

    I find the compare-and-contrast framing particularly important. Too many product decisions are framed as whether or not decisions: should we build this, should we not build this, is this feature good, is this feature bad? A stronger product discovery process forces us to compare multiple viable paths before we commit.

    Why Supercharged Ideation Matters

    Supercharged ideation is not about being louder, more creative on command, or filling a whiteboard with random concepts. It is about creating enough solution diversity that the team can make a more informed choice. That distinction matters because product teams are not rewarded for having ideas; we are rewarded for solving customer problems in ways that support business outcomes.

    Traditional brainstorming often feels productive because everyone is in the same room and ideas are moving quickly. But group dynamics can quietly narrow the range of thinking. Senior voices carry more weight, early suggestions anchor the conversation, and quieter team members may never share the insight that could reshape the direction.

    The individual-then-share approach gives each person space to think before the group converges. I have found this especially useful with cross-functional product trios because design, engineering, and product often see different constraints and possibilities. When each discipline ideates independently first, the team gets a richer set of options.

    Reflect and 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.

    This chapter challenges how most of us think about ideation. We’ve all been taught that brainstorming is the answer, but research tells a different story. This month, I am examining my own relationship with idea generation and where I may be falling into common traps.

    Individual Reflection

    1. Think about the last time your team generated ideas for a solution. Did you generate multiple ideas for one opportunity, or did you generate one idea per opportunity? What was the outcome?
    2. When you ideate, where do you get stuck? Is it after the first few obvious ideas? Do you struggle with wild ideas that feel unrealistic? Or do you find it hard to avoid jumping into evaluation mode too early?
    3. Be honest: Do you have a favorite idea right now that you’re pushing for? What assumptions are you making about why it’s the best option? Are you falling in love with your idea before testing it?

    That third question is the one I would push every product manager to answer honestly. Attachment to an idea can feel like conviction, but conviction without evidence can become a liability. Continuous discovery gives us a healthier path: generate multiple options, expose assumptions, and test before we over-invest.

    Team Discussion

    1. Walk through your team’s typical ideation process. Does it look more like traditional brainstorming (everyone sharing ideas out loud) or more like the individual-then-share approach the chapter recommends? What’s working and what isn’t?
    2. Pick one opportunity from your current tree. As a team, can you generate 15-20 ideas for how to address it? If you get stuck before reaching 15, use the chapter’s techniques: look at analogous products, consider extreme users, or think about wild ideas.
    3. Discuss: When you evaluate ideas as a team, do you tend to set up “whether or not” decisions (Is this idea good?) or “compare and contrast” decisions (Which of these ideas looks best?)? How might you shift to more compare-and-contrast decisions?

    Put It Into Practice

    The best way to learn supercharged ideation is to practice it with your team. These exercises help turn the concepts into a working product discovery habit rather than a theory we agree with but never operationalize.

    Book cover of Continuous Discovery Habits by Teresa Torres, shown at an angle for a July 2026 CDH Book Club reading guide
    A featured image of Teresa Torres' Continuous Discovery Habits, inviting Product Talk readers to join the July 2026 CDH Book Club and explore better product discovery practices together.

    Exercise: Generate 15-20 Ideas for One Opportunity

    Time: 45-60 minutes
    Do this: With your product trio (and consider inviting other team members for more diversity)

    Choose a target opportunity from your opportunity solution tree. Set a timer and go through this process:

    1. Individual ideation (5 minutes): Everyone generates ideas on their own. Aim for at least 7-10 ideas each. Write them down on sticky notes or in a shared doc.
    2. Share round one (15 minutes): Take turns sharing your ideas. No evaluation yet – just share and ask clarifying questions if needed.
    3. Individual ideation round two (5 minutes): Generate more ideas individually. The first round should have sparked new thinking. Push yourself to consider analogous products, extreme users, or wild ideas.
    4. Share round two (15 minutes): Share your new ideas with the group.
    5. Review and refine (10 minutes): Count your ideas. Did you reach 15-20? If not, do another quick round. Then, review the list together and remove any ideas that don’t actually address the target opportunity.

    After the exercise, I would ask the team to pause before evaluating the ideas. What did we learn? Were the later ideas more creative than the earlier ones? How did hearing others’ ideas spark new thinking? Those questions help the team understand not only which ideas emerged, but how the quality of thinking changed through the process.

    Exercise: Practice Dot-Voting

    Time: 20 minutes
    Do this: With your product trio

    Using the 15-20 ideas generated in the previous exercise, I would use dot-voting to narrow the field to three ideas:

    1. Set the criteria: Remind everyone that you’re voting based on how well each idea addresses the target opportunity – not on feasibility, not on how “cool” it is.
    2. Vote (5 minutes): Give each person three votes. You can put all three on one idea, split them across three ideas, or any combination.
    3. Review the results (10 minutes): Which ideas got the most votes? If it’s clear that three ideas stand out, you’re done. If several ideas have similar vote counts, take a few minutes for people to advocate for their top picks, then vote again.
    4. Check alignment (5 minutes): Once you have your top three, do a quick poll: Is everyone excited about at least one of these ideas? Does each idea have a strong advocate on the team?

    Save these three ideas – you’ll use them for assumption testing in Chapter 9.

    The discipline here is subtle but powerful. Dot-voting is not a popularity contest when it is used well. It is a lightweight mechanism for helping a product trio move from an overwhelming idea set to a manageable comparison set, while preserving enough variation to support real learning.

    Go Deeper: Additional Reading

    For teams that want to go deeper on product discovery, team creativity, and structured ideation, I would keep the following resources close. They are useful companions for product managers, designers, engineers, and leaders who want to build stronger discovery habits.

    Supplementary Reading

    • Stop Brainstorming and Generate Better Ideas
    • That’s Not Brainstorming
    • How to Turn Bad Ideas Into Good Ideas
    • Product in Practice: Getting Engineers Involved in Brainstorming

    Other Voices

    • On the Quest for Originality, Recombine the Familiar by Adam Alter
    • Creativity Is Not an Accident by Scott Berkun
    • A Data-Driven Approach to Group Creativity by Bastian Bergmann and Joe Schaeppi

    Live Discussion Schedule

    For teams following the July 2026 reading cadence, the live discussion schedule is:

    • Thursday, September 17, 2026: 9am-10am PDT and 4pm-5pm PDT
    • Wednesday, December 16, 2026: 9am-10am PST and 4pm-5pm PST

    My Product Leadership Takeaway

    My biggest takeaway from Chapter 8 is that better ideation requires both independence and collaboration. We need independent thinking to expand the solution space, and we need collaborative discussion to clarify, combine, and compare ideas. When we skip either side, the quality of our product decisions suffers.

    For me, this is where continuous discovery becomes a leadership practice, not just a team ritual. Leaders have to create the conditions where teams are not punished for exploring multiple options, questioning favorite ideas, or slowing down long enough to test assumptions. That is how product discovery becomes more than a process. It becomes a product culture.

    If I were applying this immediately with a product trio, I would choose one opportunity from the current opportunity solution tree, generate 15-20 ideas, dot-vote down to three, and carry those three into assumption testing. That simple sequence can turn a vague conversation about creativity into a concrete product management habit.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Join Me in June: Master Opportunity-First Product Strategy with Continuous Discovery Habits

    Join Me in June: Master Opportunity-First Product Strategy with Continuous Discovery Habits

    I’m celebrating the five-year anniversary of Continuous Discovery Habits by inviting you to read it with me this June. As someone who leads product management and coaches product trios, I’ve seen how a shared discovery practice tightens alignment, speeds up learning, and drives outcomes. This month, we’ll go deep on prioritizing opportunities—not solutions—and I’ll guide you step by step so you can apply the ideas on your own team.

    Each month, I’m releasing an in-depth reading guide that includes:

    We’ll discuss each month’s reading in the comments, and we’ll gather quarterly on a live call to unpack real-world applications, trade wins and missteps, and keep the momentum going.

    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. 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 dust off your old copy), share the “Spread the Love” videos with your team, block time for the exercises, and register for the community sessions. Let’s do this.

    This Month’s Reading

    Chapter:

    Estimated reading time: ~16 minutes

    This month's chapter will introduce you to:

    Need a copy? Grab the book

    Share the Love with Friends and Colleagues

    We learn best in community. Use these short videos to spread the key ideas across your product trios, engineering partners, and stakeholders. Invite them to read along with you so your discovery cadence—and your product strategy—advance together.

    Reflect & Discuss What You Read

    When we reflect and discuss what we read, we absorb more and apply it faster. This chapter challenges a deeply ingrained habit: prioritizing solutions. I’ve been in those meetings—spreadsheets full of features, heated roadmap debates, and a creeping sense that we’re optimizing outputs rather than outcomes. The shift to opportunity-first thinking changed how my teams frame bets, sequence discovery, and communicate product strategy.

    Individual Reflection

    Team Discussion

    Put It Into Practice

    This month is all about shifting from solution-first to opportunity-first thinking. These short, focused exercises will help your product trio practice opportunity prioritization and improve decision speed without sacrificing product discovery rigor.

    Exercise: Map Your Roadmap to Opportunities

    Time: 45 minutesDo this: With your product trio

    Take your current roadmap or backlog and work backwards. For each planned feature or solution:

    This exercise often reveals that you're either:

    Use these insights to inform your next prioritization conversation.

    Exercise: Practice Two-Way Door Thinking

    Time: 30 minutesDo this: With your product trio

    Choose 3-5 recent or upcoming product decisions. For each one, discuss:

    The goal is to calibrate your team's decision-making speed. Two-way door decisions should be made quickly with "just enough" evidence. One-way door decisions deserve more deliberation and data.

    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 members at the bottom of this post.

    Related In-Depth Guides

    Supplementary Reading

    Related Courses

    Our Live Discussion Schedule

    Our live discussion sessions are for registered members. Sessions are not recorded. Invitations will go out two weeks before the scheduled event—reserve time now.

    Audio Summary

    Prefer to listen? Stream the audio overview here: June — Prioritizing Opportunities (audio).

    Ready to put continuous discovery into action? Grab the book, share the videos with your team, schedule the exercises, and join the community sessions. Opportunity-first product strategy is a muscle we can build together.

    The chapters we will be readingA preview of the most important concepts we'll be learning aboutShort videos you can share with friends and colleagues to help spread the ideasIndividual and team discussion questions to help you absorb and engage with the readingTeam exercises to help you put the ideas into practiceAdditional reading to help you go deeper on the core ideasChapter 7: Prioritizing Opportunities, Not SolutionsWhy product strategy happens in the opportunity space, not the solution spaceHow to focus on one target opportunity at a time to deliver value iterativelyUsing the tree structure to simplify prioritization decisionsThe four criteria for assessing opportunities: sizing, market factors, company factors, and customer factorsWhy treating prioritization as a messy, subjective decision leads to better outcomes than scoring formulasThe concept of two-way door decisions and how they apply to opportunity prioritizationWork on one small opportunity at a time – Reduce your batch sizeGetting started with compare and contrast decisions – Choose the right target opportunityTurn big intractable problems into smaller, more solvable problems – The power of decompositionThink about your team's current roadmap or backlog. How much of your time is spent prioritizing features versus understanding and prioritizing customer opportunities? What would change if you flipped that ratio?Reflect on the last time you made a product decision. Did you treat it as a one-way door (irreversible) or a two-way door (reversible)? How did that framing affect your decision-making process and timeline?Consider the four assessment criteria (opportunity sizing, market factors, company factors, customer factors). Which of these does your team currently emphasize most? Which do you tend to overlook or underweight?As a team, list the top 5-10 items on your current roadmap or backlog. For each one, try to identify the underlying customer opportunity it addresses. If you can't clearly articulate the opportunity, what does that tell you about how you're making decisions?The chapter argues against scoring formulas (like RICE or ICE) for prioritization, calling them "made-up math." If your team uses a scoring system, discuss: What is it really measuring? Does it help you make better decisions, or does it just make subjective decisions feel more objective?Walk through a recent prioritization decision. Did you assess options in isolation ("should we build this?") or compare and contrast them? How might your decision have been different with a compare-and-contrast approach?Identify the customer opportunity it's meant to addressWrite it as something a customer might say (e.g., "I can't find anything to watch" not "We need better search")Look for patterns: Are multiple solutions addressing the same opportunity? Are some solutions disconnected from any clear customer need?Spreading yourself thin across too many opportunitiesOver-investing in a single opportunity with multiple solutionsBuilding solutions with no clear opportunity attachedIs this a one-way door decision (hard to reverse) or a two-way door decision (easy to reverse)?If it's a two-way door, what's the smallest step we could take to learn whether we're on the right track?What would we need to see to know we made the wrong choice?If we realize we're wrong, how quickly could we course-correct?Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive OutcomesCustomer Interviews: Uncover Hidden Insights from Every ConversationPrioritize Opportunities, Not Solutions7 Key Benefits of Using Opportunity Solution TreesProduct in Practice: How 2-Way Door Decisions Helped Simply Business Learn FastProduct in Practice: Getting Started with Opportunity Solution Trees at SuperAwesomeProduct Discovery Fundamentals: Learn a structured and sustainable approach to continuous discovery.Tuesday, June 16, 2026: 9am-10am PDTThursday, September 17, 2026: 9am-10am PDTWednesday, December 16, 2026: 9am-10am PST

    Inspired by this post on Product Talk.

    Book a consult png image

  • Level Up: May 26 Claude Code Show & Tell + Final Product Discovery Fundamentals Cohort

    I’m excited to share two opportunities this season to uplevel your craft, connect with peers, and leave with practical, repeatable techniques you can apply immediately to your product work.

    We will be doing another round of Claude Code: Show and Tell on May 26th at 9am PDT. These community-driven sessions are hands-on and fast-paced—we swap proven workflows, compare prompts, and pressure-test approaches together. You’ll see how product teams are operationalizing AI workflows in real contexts and walk away with ideas you can adapt for your own roadmap and experimentation pipeline. Invites will go out to Supporting Members and CDH Members tomorrow. If you'd like to join us, keep an eye on your inbox for the invite.

    I love these Show & Tell sessions because they translate tacit knowledge into clear, reusable playbooks. Whether you’re refining evaluation loops for LLMs, streamlining discovery synthesis, or standardizing prompts for consistency, the shared rigor and camaraderie make it a high-signal hour for any product leader invested in AI workflows.

    I also want to share that I'll be teaching our June 4th – July 9th cohort of Product Discovery Fundamentals. This is the last time I'll be teaching this cohort in its current format. If you've been thinking of enrolling in this program, and want to take it with me, this is your last chance. Register here.

    Across this cohort, we’ll practice continuous discovery habits—framing opportunities, tightening assumptions, running lean experiments, and aligning product trios on evidence-backed decisions. If you want a rigorous, repeatable system for turning customer insight into confident prioritization and compelling product strategy, I’d be thrilled to have you in the room.

    Inspired by this post on Product Talk.

    Book a consult png image
  • From Prototype to Production: How I Built Reliable AI-Generated Opportunity Solution Trees

    From Prototype to Production: How I Built Reliable AI-Generated Opportunity Solution Trees

    I just wrapped an all-out engineering sprint. That still sounds odd coming from me, because while I’ve written code on and off for years, I don’t self-identify as an engineer. I’m a product manager who used to be a designer. It’s been a long time since I wrote code for a living.

    But AI has expanded what’s just now possible—for our products, and for us. It’s pushed me to do more than I imagined. In that spirit, I want to share a recent engineering story. It includes technical details, and a year ago I couldn’t have done any of it. I learned it with the help of AI, and my aim is to show what’s now within reach.

    I’ve been building two services with a partner at Vistaly: AI-generated interview snapshots and AI-generated opportunity solution trees. We put out a call for alpha partners, received over 100 applicants, and selected eight design partners to start.

    Opportunity Solution Tree diagram with a blue Desired Outcome branching to green Opportunity nodes, yellow Solution nodes, and orange Assumption Tests for product discovery and AI workflows.
    A clear, color‑coded map from desired outcome to opportunities, solutions, and assumption tests—showing how to structure discovery work and prompt AI to generate, compare, and validate product ideas.

    Each team uploaded three customer interviews. I identified the key moments and opportunities and then generated an opportunity solution tree from those snapshots. I provide the AI services; Vistaly is building the UI and workflows around them.

    Early feedback was strong. Teams immediately asked to upload more interviews—exactly the kind of demand signal you hope to see—so we got to work making that possible.

    Dark interface screenshot of an opportunity solution tree with colored cards and dotted connectors, showing merged, moved, and evidence-added Opportunity notes about onboarding, support, and bot readiness.
    Go behind the scenes as AI turns raw feedback into a clear Opportunity Solution Tree. Linked cards reveal user needs—onboarding, support offload, and bot-readiness signals—so product teams can spot priorities and next steps at a glance.

    Updating an opportunity solution tree with new interview content is far harder than generating a new tree from scratch. I initially underestimated the complexity. Our goal wasn’t to produce a tree and declare it truth. We wanted teams to engage, correct, and collaborate with the AI—scaffolding cross-interview synthesis instead of doing it for them.

    To support that, we needed a way to communicate precisely how a tree would change after new interviews were added. We took inspiration from git diff and set out to build the equivalent for opportunity solution trees—step-by-step change sets that explain each proposed modification.

    Diagram of an opportunity solution tree with an Outcome node pointing to Opportunity A and Opportunity B; B branches to child opportunities and shows source evidence, labeled “Updates Can't Result in Data Loss.”
    A clear visual of AI‑generated opportunity solution trees: outcomes feed opportunities that branch into sub‑opportunities, while evidence is preserved. The structure ensures updates stay traceable and never cause data loss.

    That decision was right, but the lift was larger than I expected. It wasn’t enough to generate an updated tree; I also had to provide a clear, ordered walkthrough of what changed and why.

    I often see the same pattern with AI: it’s easy to get to an impressive prototype, but much harder to reach a production-grade product. That was exactly my experience here. My service actually comprised two sub-services: generating a new tree from scratch and updating an existing tree with new interviews. The first worked well in alpha; the second had to be built before anyone could add a fourth interview.

    Opportunity Solution Tree diagram: teal Outcome links to Opportunities A and B; Opportunities C and D branch under B; right panel lists the change set steps for adding nodes.
    Explore how an outcome expands into an Opportunity Solution Tree: Opportunities A and B stem from the goal, with C and D nested under B, while a concise change set tracks every node added along the way.

    On the surface, these services look similar. In reality, updates must preserve existing structure unless new evidence requires a change. You have to account for compound operations—merges, splits, deletes—while guaranteeing no data loss. Every node has source opportunities (supporting evidence from interviews) and children (tree sub-opportunities), and neither can be dropped.

    In classic AI fashion, I got a reasonable version working in a few days and shipped it to our design partners. One team quickly hit our beta limits and asked to convert to a paid subscription so they could keep going. They showed a willingness to pay, converted, and started uploading aggressively.

    Diagram of an Opportunity Solution Tree showing how parent 'Opportunity A' with children x, y, z is split into 'Opportunity A' and 'Opportunity B' to reassign evidence and connections.
    Watch an Opportunity Solution Tree evolve: the original parent A with x, y, z branches is split into A and B, shifting evidence while preserving links—mirroring how AI refines scope and structure in discovery.

    At the 14th, 15th, and 16th uploads, the cracks appeared. We saw odd behavior in some trees. The Vistaly team noticed that the change sets—the step-by-step instructions emitted by my service—didn’t always reconstruct the final tree my service also emitted. We needed those steps to match exactly, so teams could review and accept, modify, or reject each change with confidence.

    They flagged the issue the day I was flying to New Orleans for Jazz Fest. In hindsight, I’m glad I didn’t grasp the scope of what awaited me. I had roughly 80% of the work still to do to make tree updates rock solid. At least I got to enjoy the music first.

    Flowchart merging two opportunity solution trees: Opportunity B with children y and z, and Opportunity C with t, u, v, consolidated into one tree led by Opportunity C connected to five child opportunity nodes.
    From fragments to focus: this diagram shows how Opportunities B and C are merged into a single Opportunity Solution Tree, removing duplicates and unifying context so AI can rank and explore five related opportunities with clarity.

    Back home, I started diagnosing. My service was a pipeline: several LLM-driven steps followed by deterministic code to compare trees and produce change sets. As I dug in, I realized that approach was flawed. Tree diffs, unlike linear document diffs, are ambiguous.

    In a document, if I add a sentence, the diff shows an addition. If I delete a paragraph and rewrite it, the diff shows a removal and an addition. Simple. But trees are different. Suppose I split opportunity A into A and B, and later merge B with C. The split can disappear from the final diff.

    Diagram of an opportunity solution tree labeled 'Input Tree' showing an Outcome node branching to Opportunity A and C, each with child nodes x-z and t-v, with arrows indicating hierarchy.
    Peek inside our process: a simple opportunity solution tree maps an outcome to prioritized opportunities A and C with downstream options x-z and t-v. A clear snapshot of how AI organizes product discovery.

    When the model splits an opportunity, it must distribute A’s source opportunities and children between A and B. For instance, if A has source opportunities 1, 2, 3 and children x, y, z, after the split A might keep 1, 2, and x, while B takes 3, y, and z.

    Now suppose the model merges B into C. If C originally had source opportunities 4 and 5 and children t, u, v, then after the merge C now has source opportunities 3, 4, 5 and children t, u, v, y, z. When you compare the original and final trees, it looks like A somehow donated some evidence and children directly to C. The split and merge that explain why are invisible to a naive diff.

    Opportunity Solution Tree diagram titled Output Tree: a blue Outcome node branches to green Opportunity A and Opportunity C, which expand to nodes x-v with arrows; Product Talk badge.
    See how an AI-generated Opportunity Solution Tree unfolds: one Outcome flows to Opportunities A and C, then into options x–v. Clean colors and arrows reveal the hierarchy from goal to opportunities at a glance.

    That was the core insight: we didn’t just need to show what changed—we needed to show why it changed. I had to reconstruct each move step-by-step. That meant getting the model to show its work, which opened a new can of worms.

    I refactored my prompts so the model produced both the final output and the exact change set it used to get there. The action language was explicit: add, delete, reframe, merge, split, and so on. Crucially, I asked the model to describe its moves in user-meaningful terms—“split A into A and B, then merge B into C”—not as opaque reassignments of sources and children.

    Diagram of an AI-generated Opportunity Solution Tree: blue Outcome node with children Opportunity A and Opportunity B; B branches to Opportunity C and D. A right-hand list shows the change set for each step.
    Watch an opportunity solution tree take shape: start with the outcome, add opportunities A and B, then extend B to C and D. The paired change set makes every edit transparent—ideal for AI-assisted product discovery.

    For each LLM step, the model now emitted its recommendation and the corresponding change set. This helped, but it wasn’t perfect. After extensive testing and error analysis, two classes of errors emerged: (1) the model attempted an invalid move, and (2) the change set didn’t actually generate the recommendation.

    Category 1 felt like designing a game while the model played it creatively. For example, what happens when the model tries to merge a parent with a child? If opportunity A has children B, C, and D and the model merges A with B, the merge is directional. If the instruction is “keep A, delete B,” that works—the parent absorbs the child. But if the instruction is “keep B, delete A,” then C and D become orphans. These puzzles were solvable and even fun.

    Diagram of Opportunity Solution Tree merge rules: merging node B into parent A is allowed, while merging A into B is not because it would orphan opportunities B, C, and D.
    Visual explainer from Product Talk on AI-generated Opportunity Solution Trees. It contrasts an allowed merge (B into A) with a not-allowed merge (A into B) that leaves child opportunities orphaned, guiding safe hierarchy edits.

    Category 2 was harder. Despite prompt iterations, I could only push the discrepancy rate down to about 1 in 40 instances. With 10–20 LLM calls per run, that meant roughly half of all runs still failed. Not acceptable for production. I hit a wall. A paying customer was waiting, and more design partners were queued up.

    Next, I tried to correct the model’s mistakes with deterministic code. I had promised that my change sets would generate the output tree, so I wrote verifiers: detect conflicts (e.g., delete a node, then try to use it later), guard against data loss, prevent orphaned nodes, and more. Detection was straightforward; correction was not. Fixing issues required guessing the model’s intent. If the sequence said “delete A, then merge A with B,” should I remove A entirely or salvage A’s sources and children by merging into B? There were dozens of such cases with no unambiguous answer.

    Workflow diagram titled 'My Simple Repair Loop' showing an iterative validation cycle: Generate the Change Set → Run the validation tool → Check Result, with branches to retry on failure or exit on pass.
    A step-by-step loop shows how changes are validated: generate a change set, run a validation tool, review the result, then repeat on failure and exit on pass—mirroring iterative work behind AI-built Opportunity Solution Trees.

    After 11 straight days of deep work—including weekends—I was exhausted. I dislike hustle culture; this isn’t how I design my life. But I was stuck, and then I had an insight.

    On a walk with my husband (also an engineer), I realized I could have the LLM repair its own mistakes. My data contract with Vistaly requires that the change set must generate the output tree. I had already built robust validation code. I knew exactly when a change set failed—and why. No amount of prompt tuning alone was fixing it. So I turned the validator into a tool for the model and created a simple agentic loop.

    The loop works like this: the model proposes a change set, calls the validation tool, and gets back a pass/fail plus specific feedback. If it fails, the model uses those instructions to repair the change set and calls the tool again. Iterate until success or a max number of turns.

    I prototyped in Node.js with a single model call, a verifier pass, and a repair attempt. At first, the loop didn’t converge—it just accumulated compute. I experimented with how to communicate errors, how much context to include, and how to sequence feedback. Eventually, it clicked: the model began fixing its own mistakes and typically returned a valid change set in one or two repairs. It was, in practice, eval-driven development applied to LLM outputs.

    I had already built an agent loop utility for another AI workflow, so I productionized quickly: model call, optional tool invocation, tool result returned to the model, repeat until the validator signals success or the loop times out. I integrated the new loop into the pipeline and shipped the revamped service to Vistaly on Monday at noon. They’re integrating now, and it will be in the hands of our design partners shortly. I’m relieved—and ready for a day off.

    Reflecting on the last two weeks, a few things stand out. First, I shed limiting beliefs about being an engineer. To make this reliable, I had to solve legitimately hard problems, and that feels good.

    Second, this was genuinely fun. Designing the action set and watching the model push those boundaries was like working through elegant puzzles. Models are incredibly creative, and harnessing that creativity with the right constraints is deeply satisfying.

    Third, I learned when I can and can’t trust Claude to write code for me. Since Opus 4.6 came out, I gave Claude a much longer leash. After the past two weeks, Claude is back on a short leash. I found a lot of gaps in my implementation in areas where I simply trusted that Claude got it right, when in fact it didn’t. If you don’t have the right infrastructure—planning, testing, code review—this can be disastrous. I’ll be investing more here and sharing what I learn.

    Finally, if this work had been spread over two months, it would have been thoroughly enjoyable. I’m discovering how much I like being an AI engineer. It feels like a new chapter where I can combine opportunity solution trees with modern AI engineering—and deliver real value to product teams doing continuous discovery.

    I’m excited to share more of what we’re building with Vistaly and to onboard more design partners soon. If you’re interested, get on the waiting list. And if you’ve been hesitant to stretch beyond your current skill set, I hope this story nudges you to take the first small step toward what’s just now possible.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Taste vs. Evidence in the AI Era: What Product Leaders Must Invest In Now

    Taste vs. Evidence in the AI Era: What Product Leaders Must Invest In Now

    I just finished listening to "Taste – All Things Product Podcast with Teresa Torres & Petra Wille," and as a product leader shipping AI-powered capabilities at HighLevel, Inc., I wanted to pressure-test the sudden obsession with "taste."

    If you're curious, you can listen to this episode on Spotify or Apple Podcasts.

    The core question landed perfectly for our moment: Is "taste" the must-have skill of the AI era — or just the latest tech buzzword in a world where AI is eating through design, delivery, and discovery?

    Teresa pushes back hard, highlighting how slippery the term can be. "It's just this month's flavor of founder mode." She points out that "taste" is rarely defined, can't be easily taught, and too often becomes shorthand for "my preference trumps yours." Just as importantly, "It's not about your taste. It's about your customer's taste."

    Petra adds needed nuance from years in the craft: pattern-recognition is real, and some people do develop sharper product sense over time. As she put it, "I am a strong believer that you develop product sense and taste over time. It's never finished."

    Both threads lead back to familiar roots in product: product sense, founder mode, and the enduring myth of the lone visionary. They even grapple with the big question on everyone’s mind—Will AI Eat Taste Too?—and where that leaves product teams navigating GenAI, LLMs for product managers, and evolving product strategy.

    Here’s my take. "Taste" can be useful as a personal north star, but it is not a decision system. In my teams, we bias toward evidence: continuous discovery, customer interviews, discovery synthesis with opportunity solution trees, and tight collaboration in product trios. Opinion can start the conversation, but evidence should end it.

    Practically, that means investing in the skills that compound: Discovery skills — understanding customers, matching solutions to real needs. Human-to-human interaction skills. Learning to collaborate with AI effectively. Critical thinking and judgment grounded in evidence.

    On AI collaboration specifically, we treat GenAI as a force multiplier, not a decider. We prototype with AI to explore breadth, then narrow with qualitative and quantitative signals, ablation-style experiments, and clear success criteria. The bar I hold myself to is simple: taste without evidence is just opinion.

    Three lines I underlined from the conversation:

    "It's just this month's flavor of founder mode." — Teresa Torres

    "It's not about your taste. It's about your customer's taste." — Teresa Torres

    "I am a strong believer that you develop product sense and taste over time. It's never finished." — Petra Wille

    If you want to go deeper, these references are helpful for sharpening judgment without falling into the "great man" theory trap.

    Follow Teresa Torres: https://ProductTalk.org

    Follow Petra Wille: https://Petra-Wille.com

    Founder mode

    Marty Cagan: Founder-Style Leadership

    Vercel/v0 CEO Guillermo Rauch on building taste: from Lenny Rachitsky’s Linkedin post

    Continuous discovery (Read Teresa’s Everyone Can Do Continuous Discovery—Even You! Here’s How

    The "great man" theory

    Steve Jobs and the myth of the lone product visionary

    Have thoughts on this episode? Leave a comment below and share how your team balances product sense with evidence in the age of AI.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Master Opportunity Mapping with Continuous Discovery Habits — Join the May 2026 Book Club

    Master Opportunity Mapping with Continuous Discovery Habits — Join the May 2026 Book Club

    Five years in, Continuous Discovery Habits continues to be one of the most practical frameworks I use to align empowered product teams, sharpen product strategy, and convert customer interviews into outcomes. To celebrate its impact, I’m hosting a community read-along and inviting you to dig in with me this May.

    Each month, I’m releasing an in-depth reading guide to make learning stick. You’ll find the chapters we’ll be reading, a preview of the essential concepts, short videos to help you spread the ideas across your organization, individual and team discussion prompts, team exercises to put the concepts into practice, and additional reading if you want to go deeper. My goal is simple: help you turn product discovery into a steady habit, not a once-a-quarter activity.

    We’ll discuss each month’s reading in the comments, and we’ll gather quarterly on a live call to compare notes and share what’s working. Joining late is absolutely fine—I monitor the conversation throughout the year. Start with the current month or rewind to January; you can ask for help, share wins and roadblocks, and connect with other readers anytime.

    If you want to participate, grab a copy of the book (or dust off your old one), share the "Spread the Love" videos with your team, block focused time for the exercises, and register for the community sessions. Let’s do this together.

    This Month’s Reading

    Chapter: Chapter 6: Mapping the Opportunity Space

    Estimated reading time: ~23 minutes

    This month’s chapter will introduce you to why opportunity mapping is critical for structuring the ill-structured problem of reaching your desired outcome; how to move from overwhelming opportunity backlogs to well-structured opportunity spaces; the power of tree structures for depicting parent-child and sibling relationships between opportunities; how to identify distinct branches in your opportunity space using key moments in time; common anti-patterns to avoid when building your first opportunity solution tree; and why structure "gets done, undone, and redone" as you continue to learn.

    Need a copy? Grab the book.

    Share the Love with Friends and Colleagues

    We learn best in community. Use these short videos to spread the core concepts from this chapter—then invite your team to join the book club with you.

    The need for opportunity mapping – You will never fully satisfy your customers' desires

    Understanding the structure of an opportunity solution tree – Depicting two types of relationships

    Turn big intractable problems into smaller, more solvable problems – The power of decomposition

    How to map an opportunity space – Getting started with opportunity solution trees

    A well-structured opportunity space has distinct branches – Identify key moments in time

    Reflect & Discuss What You Read

    Reflection turns reading into capability. This chapter asks us to shift from reacting to every request to deliberately structuring the opportunity space. If you’ve ever felt overwhelmed by a never-ending backlog or pressure to ship output over outcomes, this is where the fog starts to lift. As you read, focus on how your team currently organizes (or doesn’t organize) what you hear from customers.

    Individual Reflection

    1) Think about your current product backlog or opportunity list. Is it a flat list, or do you have some structure to it? If you were to group similar opportunities together, what patterns would emerge?

    2) When was the last time you heard a customer need and immediately jumped to a solution without exploring whether there were related opportunities? What would change if you took the time to map how that opportunity connects to others?

    3) Review the anti-patterns from the chapter (opportunities framed from your company's perspective, vertical opportunities, opportunities with multiple parents, etc.). Which of these do you recognize in how your team currently talks about opportunities?

    Team Discussion

    1) As a team, pick a top-level opportunity you're currently working on. Try breaking it down into sub-opportunities together. Where do you struggle? Where do you disagree about how to frame or group opportunities? What does that tell you about gaps in your shared understanding?

    2) Look at your experience map (from Chapter 4) and identify 3-5 distinct moments in time during your customer's experience. Could these become the top-level branches of your opportunity solution tree? Where do you see overlap, and where are there clear distinctions?

    3) Discuss the quote from Barbara Tversky: "Structure gets done, undone, and redone." How does your team currently respond when you discover new information that changes how you understand the opportunity space? Do you treat your opportunity map as fixed or as something that evolves?

    Put It Into Practice

    Reading is step one; building your first opportunity solution tree is where the real learning happens. The exercises below are exactly how I coach product trios to transform ambiguous problems into aligned action.

    Exercise: Build Your First Opportunity Solution Tree

    Time: 60 minutes. Do this: With your product trio.

    Start by reviewing your interview snapshots from the past few weeks. For each opportunity you captured, ask the three questions from the chapter:

    Is this opportunity framed as a customer need, pain point, or desire (not a solution)?

    Is this opportunity unique to one customer, or have we seen it in more than one interview?

    If we address this opportunity, will it drive our desired outcome?

    Then, using your experience map, identify 3-5 distinct moments in time to serve as your top-level opportunities. Group the opportunities from your interviews under these top-level branches.

    Look for opportunities to add structure to each branch. Group similar opportunities together and identify a parent opportunity. Look for vertical stacks (one parent, one child) and fill in missing siblings. Reframe opportunities that are too broad or that could live in multiple branches.

    Don’t aim for perfection. Get something on paper (or a digital canvas) and iterate the tree with every new interview.

    Exercise: Practice Framing Opportunities from Your Customer’s Perspective

    Time: 30-45 minutes. Do this: With your product trio.

    Take 10-15 opportunities from your current backlog or list. For each one, ask: "Can I imagine a customer saying this?" If the answer is no, reframe it from your customer’s perspective. For example:

    "Increase subscription conversions" becomes "I want to know if this product is worth paying for"

    "Reduce support tickets" becomes "I can't figure out how to do X"

    "Improve onboarding completion" becomes "I'm not sure what to do next"

    This exercise helps you spot business-centric opportunities disguised as customer opportunities. It also trains your team to listen for opportunities in interviews that are framed from the customer’s point of view.

    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.

    Related In-Depth Guides

    Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes

    Customer Interviews: Uncover Hidden Insights from Every Conversation

    Supplementary Reading

    Prioritize Opportunities, Not Solutions

    Product in Practice: Opportunity Mapping at Grailed

    Product in Practice: Opportunity Mapping at trivago

    7 Key Benefits of Using Opportunity Solution Trees

    Getting Started with Opportunity Solution Trees at SuperAwesome

    Bringing Order to Chaos: Using Opportunity Solution Trees in Everyday Life

    Other Voices

    Why Groups Struggle to Solve Problems Together by Al Pittampalli

    More PM Problem Areas by Marty Cagan

    Five Superpowers of Diagrams by Abby Covert

    Critical Thinking is Product Management by This Is Product Management

    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.

    Tuesday, June 16, 2026: 9am-10am PDT

    Thursday, September 17, 2026: 9am-10am PDT

    Wednesday, December 16, 2026: 9am-10am PST

    Audio Summary

    This summary was produced by NotebookLM. The sources supplied were the book chapters as well as all of the additional reading.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Master Build-to-Learn: The Essential FAQ to Supercharge Product Discovery in the AI Era

    Master Build-to-Learn: The Essential FAQ to Supercharge Product Discovery in the AI Era

    In the age of AI, I’ve come to believe we’re all builders—yet not all building is the same. There is a very meaningful difference between building to learn (known as product discovery) versus building to earn (known as product delivery). When we confuse the two, we waste precious time, budget, and team energy on output over outcomes. My goal in this FAQ-style reflection is to clarify when and how to choose each mode so we can make smarter, faster, more confident product decisions.

    Why does this distinction matter so much right now? Because as the cost of product delivery continues to drop, the scarce resource shifts from shipping capacity to clarity of problem, solution, and value. Cloud infrastructure, CI/CD, feature flags, and even gen AI code assistance have made it cheaper to launch. That’s great—but if we don’t learn the right things before we scale, we’ll efficiently deliver the wrong product. Discovery is how we de-risk that.

    What do I mean by build to learn? I use discovery to quickly validate problems, test value, and shape solutions before committing delivery teams to scale. In practice, that means continuous discovery with customer interviews, rapid prototyping, and lightweight experiments that put us in front of real users fast. I rely on product trios and empowered product teams to co-own outcomes, not just output, and I anchor decisions with outcomes vs output OKRs so we stay focused on measurable impact.

    How do I structure discovery sprints? I start with an opportunity solution tree to map customer pain points and candidate solutions, then select the smallest test that can invalidate a risky assumption. When signals are ambiguous, I refine the questions and instrument better learning loops rather than pushing harder on delivery. For experiments, I keep a bias to speed: clickable prototypes, concierge tests, or gen ai for product prototyping often reveal more in days than a coded MVP does in weeks. When experiments go live, I use a clear minimum detectable effect (MDE) and resist reading noise as signal.

    Where does AI change the calculus? LLMs for product managers are turbocharging discovery by accelerating research synthesis, persona drafts, and early concept validation. I pair that with eval-driven development to set crisp acceptance criteria for AI behaviors before any production integration. Prompt engineering and conversation design are part of the toolkit, but the same rule applies: prototype to learn, not to impress. AI can make bad ideas cheaper to build—so disciplined discovery matters more than ever.

    So when do I switch to build to earn? Once I have evidence of value and feasibility, I shift into product delivery to scale with quality, security, and reliability. This is where I bring in product roadmapping and sprint planning, DORA metrics to monitor deployment frequency and lead time, and strong SRE and observability practices to safeguard the user experience. The handoff isn’t a wall; discovery continues inside delivery to refine scope, reduce risk, and maintain momentum.

    What pitfalls do I watch for? The biggest is treating delivery as discovery—shipping features to “see what happens” without a clear learning thesis. Another is tech-first decisions driven by technology FOMO instead of product strategy and customer value. I also see teams set output-based commitments that crowd out learning; outcomes vs output OKRs keep us honest. And when considering build vs buy, I evaluate whether the capability differentiates us; if not, I’ll buy to preserve discovery capacity on what truly matters.

    My operating conviction is simple: invest early and deliberately in build to learn so build to earn becomes high-confidence, high-velocity, and high-impact. In practical terms, that means smaller bets, faster feedback, clearer outcomes, and tighter collaboration across product, design, and engineering. If we get discovery right, delivery feels inevitable—and customers feel understood.

    Inspired by this post on SVPG.

    Book a consult png image
  • Outcome-Driven Product Development: A Practical Operating Model

    Outcome-Driven Product Development: A Practical Operating Model

    Your team has hit its release dates, the roadmap is moving, and the launch calendar is full. Then someone asks the question that exposes the problem: what changed for the customer or the business? If the answer is a list of shipped features, activity is visible but progress is still uncertain.

    Outcome-driven product development closes that gap. It gives a team a measurable problem to solve, enough freedom to change its solution as evidence changes, and a clear point at which exploration should become committed delivery. The result is not less shipping. It is less investment in work that has never earned the right to scale.

    Replace the feature request with an outcome contract

    A feature describes what the team will produce. An outcome describes the change the team intends to cause. That distinction sounds simple, but it changes planning, discovery, measurement, and accountability.

    Suppose the roadmap says, “Launch an AI onboarding assistant.” The statement has a deliverable, but it leaves the important questions unanswered. Which customers are struggling? What behavior needs to change? How will the assistant cause that change? What evidence would justify continued investment? What must not get worse?

    Rewrite the request as an outcome contract before discussing scope. A useful contract contains:

    • Target customer and context: the specific user or account segment experiencing the problem, plus the situation in which it occurs.
    • Problem evidence: the interviews, behavioral data, support patterns, or other observations showing that the problem is real.
    • Behavioral outcome: the customer action that should become more frequent, successful, or efficient if the problem is solved.
    • Business connection: the reason that behavior matters to activation, conversion, retention, revenue, cost, or another strategic result.
    • Baseline, target, and measurement window: the current state, the intended direction or threshold, and the period over which the change will be assessed.
    • Guardrails: the customer, operational, financial, ethical, or reliability measures that must not deteriorate while the primary metric improves.
    • Decision point: the evidence that will trigger scaling, iteration, another experiment, or stopping the work.

    The rewritten AI onboarding bet might be: “For new workspace administrators who struggle to complete setup, increase the share who reach their first useful workflow during onboarding, without increasing support demand or incorrect automations.” The assistant is now one possible solution, not the definition of success.

    That wording gives the team room to discover that a checklist, better defaults, a guided setup flow, clearer copy, or a narrower AI capability solves the problem more effectively. It also prevents a common failure mode: launching the requested feature and retroactively selecting whichever metric happened to move.

    Use three tests before accepting an outcome:

    • If the proposed feature disappeared, would the stated customer and business result still matter?
    • Can the team observe the target behavior with enough precision to distinguish exposure, use, and successful completion?
    • Does the team have permission to change the solution while preserving the outcome and agreed constraints?

    If any answer is no, you probably have a feature commitment decorated with outcome language. Fix that before the roadmap item absorbs a delivery team.

    Use an evidence gate between learning and earning

    Outcome-driven teams still build. The important choice is what they are building for at each moment.

    In build-to-learn mode, the objective is to reduce uncertainty cheaply. The team is trying to understand the problem, test whether a solution is desirable and usable, and expose delivery or business risks before making a large commitment. Customer interviews, lightweight prototypes, assumption mapping, an opportunity solution tree, and narrowly scoped experiments belong here.

    In build-to-earn mode, the objective changes to dependable value capture. The team has enough evidence to invest in production quality, integration, operational readiness, adoption, and scale. Acceptance criteria, sprint planning, release discipline, observability, and post-launch measurement become central.

    These are modes of investment, not separate departments. A product trio can move between them as confidence changes. The practical goal is to learn only until the evidence supports conviction, then move decisively into value capture while keeping discovery alive.

    Make every learning activity answer a decision

    Discovery becomes theater when teams collect feedback without specifying what the feedback will change. Give each experiment a compact brief:

    • Hypothesis: what the team currently believes about the customer, problem, solution, or expected behavior.
    • Riskiest assumption: the belief most likely to invalidate the bet if it is wrong.
    • Method: the cheapest credible way to test that assumption.
    • Evidence: the observable result that would strengthen or weaken confidence.
    • Timebox: the boundary that prevents exploration from continuing without a decision.
    • Next action: scale, revise, run a different test, or stop.

    Match the method to the question. Interviews can reveal whether a problem exists and how customers describe it, but they do not prove that a shipped solution will change behavior. A prototype can expose comprehension and usability problems, but it does not establish durable adoption. An A/B test can quantify incremental impact when exposure, instrumentation, and analysis are suitable, but it cannot rescue a weak problem definition.

    An opportunity solution tree helps keep those questions connected. Start with the outcome, map the customer opportunities that could influence it, attach possible solutions to those opportunities, and place experiments under the assumptions they test. This makes it easier to notice when a favored solution has become detached from the original problem.

    Define the evidence gate before enthusiasm takes over

    There is no universal discovery duration or confidence score. The appropriate threshold depends on the cost, reversibility, operational risk, and strategic importance of the decision. A narrow, reversible change should not face the same gate as a platform migration or a customer-facing AI system with meaningful risk.

    The team is usually ready to enter build-to-earn mode when it can answer yes to these questions:

    • Is the target problem supported by evidence from the intended customer segment?
    • Does the proposed solution reliably address that problem in the contexts tested so far?
    • Has the team observed a credible leading signal connected to the desired behavior?
    • Can the outcome, baseline, primary measure, and guardrails be instrumented?
    • Are delivery, operational, and business risks understood well enough to make a commitment?
    • Is the expected value sufficient to justify production investment and opportunity cost?

    Do not wait for certainty; product decisions never get it. But do not confuse executive sponsorship, customer enthusiasm, a polished prototype, or engineering progress with evidence that the bet will produce the intended result. If the gate is not met, fund the next learning step rather than pretending the full solution is ready to scale.

    The transition does not have to happen all at once. A team can productionize a narrow use case while continuing to test adjacent opportunities. What matters is that learning work and scaling work are identified honestly, funded deliberately, and judged by different standards.

    Run discovery and delivery as one product system

    An outcome will not survive if strategy, discovery, delivery, and stakeholder management operate as separate handoffs. It needs an operating model in which the same people retain context from the problem through the impact review.

    Organize the work around an empowered product trio: product management, design, and engineering jointly own the outcome and the evidence behind the solution. That does not erase specialist responsibilities. It removes the pattern in which product writes requirements, design decorates them, and engineering discovers the hard constraints after the decision has already been presented as final.

    Discovery and delivery should run as coordinated tracks. While validated work moves through implementation, release, and adoption, the trio continues testing the assumptions behind upcoming bets and watching what released behavior teaches them. This preserves learning without making committed delivery wait for every future question to be answered.

    Maintain a compact bet record for every meaningful investment. It should show:

    • the customer problem and strategic outcome;
    • the current solution hypothesis;
    • the evidence gathered so far;
    • the assumptions that remain unresolved;
    • the current mode: learning or earning;
    • the next decision and the evidence required to make it;
    • the primary metric and guardrails;
    • the delivery constraints and dependencies that materially affect the bet.

    This record should travel into roadmap and sprint decisions. A roadmap then becomes a sequence of outcome bets, ordered by expected leverage, evidence, dependencies, and strategic fit. Sprint work remains concrete, but each significant task can be traced to the hypothesis it supports. That traceability exposes orphan features: work with no defined problem, no testable belief, and no measurable result.

    Turn stakeholder reviews into decision reviews

    Stakeholders usually ask for feature certainty because feature status is what the operating system gives them. Change the review format and the conversation changes with it.

    For each bet, report the outcome, the evidence gained since the previous review, the decision that evidence supports, the largest remaining risk, and the delivery forecast when the work is in earn mode. Then ask:

    • Has the customer problem or strategic priority changed?
    • Did the latest evidence increase or reduce confidence?
    • Is the team still testing the highest-risk assumption?
    • Has new scope appeared without a corresponding outcome or risk reduction?
    • Does the next investment buy learning, value capture, or neither?

    This is also how you control scope without turning every discussion into a negotiation. New work must improve the expected outcome, address a documented risk, or satisfy an explicit constraint. If it does none of those things, it belongs outside the current bet.

    A stakeholder can still impose a solution for regulatory, contractual, architectural, or strategic reasons. Record that constraint plainly. Then preserve the team’s responsibility for validating the problem, minimizing unnecessary scope, instrumenting the result, and reporting whether the mandated solution actually changed behavior.

    Instrument the decision loop, not just the launch dashboard

    A release is evidence that the team produced something. It is not evidence that customers encountered it, understood it, used it successfully, or changed their behavior because of it.

    Build a metric chain before production work becomes expensive:

    • Business result: the strategic effect the company ultimately cares about.
    • Customer behavior: the action expected to contribute to that result.
    • Product signal: the observable event or state that indicates the behavior occurred successfully.
    • Capability: the shipped solution intended to influence the signal.

    If retention is the business result, successful setup or repeated use might be an earlier behavioral signal. That relationship is still a hypothesis in your product. Do not assume a leading indicator matters merely because it is easy to move. Validate its connection to the downstream result over an appropriate measurement window.

    Before release, define who is eligible, how exposure will be recorded, what successful use means, which segment will be analyzed, what baseline or comparison will be used, and which guardrails could stop expansion. Verify the instrumentation itself. Otherwise, a missing event can be mistaken for missing adoption, while duplicate or ambiguous events can create fictional progress.

    Where traffic and exposure permit, an A/B test can estimate whether the capability caused an incremental change. Where randomization is not practical, a staged release, cohort comparison, or carefully monitored pilot can still provide directional evidence, provided its limitations are stated. In either case, observability should cover both customer behavior and the operational health of the released system.

    Use the post-launch review to make a decision, not to celebrate a dashboard. Work through the causal chain in order:

    • No meaningful exposure: investigate eligibility, distribution, rollout, onboarding, or instrumentation before judging the solution.
    • Exposure without use: examine relevance, comprehension, trust, discoverability, and usability.
    • Use without the intended behavior: challenge the solution mechanism and the definition of successful use.
    • Behavior change without the business result: reassess the assumed link, segmentation, and measurement window.
    • Primary improvement with guardrail damage: pause expansion and address the tradeoff rather than averaging the harm away.

    These are diagnostic starting points, not automatic conclusions. Their value is that they direct the next investigation. The review must end with an explicit choice: expand, continue observing, revise the solution, test a different opportunity, or stop investing.

    AI changes the cost of learning, not the evidence standard

    Generative AI can make prototypes, interface variants, and qualitative synthesis much faster. That is useful because it lowers the cost of testing assumptions. It also makes it easier to produce a convincing solution before anyone has established that the problem deserves investment.

    Treat an AI-generated prototype as a learning instrument, not customer validation. A plausible interface or polished response does not show that customers will trust it, incorporate it into their workflow, or achieve a better result. Those questions still require evidence from the intended users and context.

    For an AI-powered feature, separate system quality from product outcome. Prompt changes, model changes, response quality, and task-level evaluations can explain how the capability behaves. The customer outcome tells you whether that capability improved the workflow that matters. A better model-level result can coexist with a flat customer outcome if the feature addresses the wrong problem, appears at the wrong moment, or creates too much friction around the generated output.

    Keep risk guardrails beside the primary outcome from the beginning. The relevant guardrails depend on the use case, but they should capture the ways an apparently successful AI feature could create unacceptable customer, operational, ethical, or business consequences. Faster experimentation is valuable only when the decision loop can detect both value and harm.

    Outcome-driven product development FAQ

    What if an executive has already specified the feature?

    Treat the feature as a proposed or mandated solution, then ask what result makes it worth building. Document any non-negotiable constraint and write the outcome contract around it. Offer alternatives when discovery shows a cheaper or more effective route, but do not hide the original decision. The team should still instrument the feature and report whether it delivered the intended behavior.

    How long should discovery take?

    Long enough to cross the evidence gate for the decision being made, and no longer. Timebox each experiment, not the truth of the entire opportunity. A reversible, limited bet may need modest evidence; an expensive or risky commitment warrants more. If discovery continues without changing confidence or informing a decision, narrow the question or stop the activity.

    Can an outcome-driven team still commit to a delivery date?

    Yes, once the work is in build-to-earn mode and the important delivery unknowns are bounded. Keep the delivery forecast separate from outcome confidence. A team may be highly confident about when a capability will ship while remaining uncertain about the behavior it will cause. Reporting both prevents schedule confidence from being mistaken for product confidence.

    What should happen when the outcome does not move?

    Start with exposure, then use, then behavior, then the business connection. Identify where the chain broke before adding scope. If the evidence weakens the underlying hypothesis, revise or stop the bet. Outcome accountability means changing course when the mechanism fails, not punishing a team for refusing to manufacture a favorable story.

    At your next roadmap review, take the highest-investment item and replace its feature description with an outcome contract. If the problem evidence, behavioral measure, guardrails, or decision rule is blank, fund the missing learning before you fund scale. That single change will reveal whether the roadmap is managing customer and business progress or merely scheduling production.

    References

  • How Top Product Teams Roadmap Through Uncertainty: Align Faster, Adapt Smarter, Deliver

    How Top Product Teams Roadmap Through Uncertainty: Align Faster, Adapt Smarter, Deliver

    Product roadmaps should not be promises etched in stone; they are portfolios of bets made under uncertainty. When I build a roadmap, I’m not predicting the future—I’m designing a system that helps the team learn faster than the market changes, allocate capital wisely, and create alignment across engineering, design, go-to-market, and leadership.

    The best roadmaps I’ve seen and shipped anchor on outcomes rather than features. “Outcomes vs output OKRs” is more than a slogan; it’s how we translate strategy into measurable impact. I start by defining a small set of outcome metrics that matter—such as activation rate, time-to-first-value, or expansion revenue—and attach clear key results and guardrails to each theme. This reframes prioritization from “what can we build?” to “what must change in customer behavior?” and gives empowered product teams real autonomy.

    I organize the roadmap into time horizons—Now, Next, Later—with explicit confidence levels. Near-term items have higher confidence and more specificity; mid- and long-term bets are thematic with wider time windows. This approach reduces false precision and builds trust because stakeholders can see both the intent and the uncertainty. When dates matter, I use windows and service level expectations rather than single deadlines, and I pair each initiative with a lightweight risk scoring so we can discuss uncertainty explicitly rather than implicitly.

    Continuous discovery keeps the roadmap honest. I partner in tight “product trios” across product, design, and engineering to run rapid customer interviews, opportunity sizing, and assumption tests before we commit significant delivery capacity. The opportunity solution tree is my favorite artifact here; it visualizes the path from outcomes to opportunities to experiments and solutions, making trade-offs and sequencing transparent. By the time something moves into sprint planning, we’ve already reduced key uncertainties and clarified the narrowest viable slice we can ship.

    Uncertainty demands options. I plan initiatives as options with stage gates and explicit kill criteria rather than as single monolithic projects. For every significant theme, I outline base, best, and worst-case scenarios with pre-decided triggers for when we escalate, pivot, or stop. This practice prevents sunk-cost fallacy and keeps the team focused on evidence. We treat scope as a knob, not a switch, and we bias toward small, sequential bets that compound learning.

    Capacity is strategy. I routinely reserve a discovery buffer—typically 10–20%—and a contingency buffer for integration, security, and performance risks that always show up late. I ruthlessly control work-in-progress to limit thrash and protect the team’s ability to respond when new information arrives. When we must navigate dependencies, I use thin vertical slices and decouple via contracts or feature flags so discovery momentum doesn’t stall while platforms evolve underneath.

    Prioritization under uncertainty benefits from explicit models. I combine value, effort, and confidence with risk scoring to surface where the unknowns are hiding. Driver trees help us connect top-level outcomes to leading indicators, so we can place bets where they have the highest causal leverage. I also lean on the Kano Model and qualitative signals to avoid over-investing in performance attributes while neglecting excitement features that unlock differentiation and word-of-mouth.

    The most effective stakeholder management is narrative-first. For executives, I present a one-page outcomes roadmap that shows themes, expected shifts in key results, and the learning plan. For teams, I provide a more detailed plan that links discovery insights, assumptions-to-test, and decision points. I make room for a “what we’re not doing” section to reduce noise and prevent shadow backlogs from reappearing in every meeting. Most importantly, I socialize change before it happens, explaining the evidence and the trade-offs so adjustments feel like progress, not whiplash.

    Measurement closes the loop. We instrument experiments and releases with leading indicators tied to the driver tree and review them on a predictable cadence. If movement stalls, we diagnose whether we have a targeting problem (wrong audience), a value problem (weak proposition), or a friction problem (broken journey). That discipline lets us iterate with purpose instead of chasing vanity metrics or isolated anecdotes.

    Here’s a concrete example of roadmapping through uncertainty. Suppose our Q3 objective is to “Increase user activation” with key results to raise the Week-1 activation rate from 32% to 45% and cut time-to-first-value by 30%. In discovery, customer interviews reveal confusion in the first-run setup and a missing integration that advanced users expect. We map an opportunity solution tree and identify two high-leverage opportunities: simplifying the first 10 minutes and offering a guided setup for the integration. We then shape two minimal bets: an in-app guide to streamline the first three tasks and an integration wizard behind a feature flag. Each bet has an explicit decision rule and a two-sprint runway. We ship the guide first, confirm a statistically significant lift via A/B testing, then expand scope. The integration wizard underperforms initial expectations, so we pause, revisit the assumptions, and re-allocate buffer to the stronger path. The roadmap updates in real time, and everyone understands why.

    When uncertainty spikes—new competitor, pricing shock, platform deprecation—I shift the roadmap cadence to rolling-wave planning. We shorten planning horizons, increase the frequency of readouts, and elevate discovery allocations temporarily. We also create thematic “containment zones” where we explore multiple options in parallel with small budgets until one path justifies scale. This allows us to stay responsive without abandoning strategy.

    Good governance accelerates, it doesn’t slow. A lightweight product council that reviews outcomes, risks, and cross-functional dependencies prevents surprise escalations and ensures we keep shipping what matters. We avoid death-by-approval by agreeing in advance on decision rights and thresholds—for example, a product trio can pivot a bet within a theme up to a certain budget or timeline impact without additional approval, as long as it improves the outcome likelihood.

    If you’re evolving your roadmap practice, start with three moves. First, reframe your plan in outcomes and publish a driver tree that connects those outcomes to the few leading indicators you believe move them. Second, stand up a continuous discovery cadence with a visible opportunity solution tree and an assumptions-to-test backlog. Third, implement time windows and confidence levels for all mid- and long-term items, and pair each major initiative with explicit kill criteria. You’ll feel the difference in a single quarter: clearer trade-offs, faster learning, and more predictable delivery—despite uncertainty.

    In the end, a roadmap that thrives in uncertainty is an agreement about how we learn and decide together. It aligns the organization on outcomes, it funds options—not fantasies—and it gives empowered product teams room to maneuver. That’s how top product teams plan for uncertainty and still deliver with confidence.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Beat AI FOMO: A Product Leader’s Playbook to Choose Tools, Stay Focused, and Learn Deeply

    Beat AI FOMO: A Product Leader’s Playbook to Choose Tools, Stay Focused, and Learn Deeply

    Lately, it feels like every morning brings a new AI launch, a dazzling demo, or a must-try tool. I love the pace of innovation, but the constant stream can trigger counterproductive FOMO if I’m not intentional. As a product leader, I’ve learned to turn that anxiety into a disciplined learning system—one that keeps me curious without letting novelty hijack my focus.

    That’s exactly why this conversation with Petra Wille and Teresa Torres resonated with me. They explore how to stay experimental in the AI era without chasing every shiny object. Their perspective aligns closely with my own operating cadence: start with real problems, go deep on a small set of tools, and create explicit boundaries between work, learning, and play.

    Listen to this episode on: Spotify | Apple Podcasts

    Here’s the mindset I apply. I don’t start with tools—I start with problems. When I encounter concrete friction in a workflow or see a credible opportunity to improve an outcome, that’s my trigger to explore a new capability. This mirrors the continuous discovery habit of prioritizing opportunities over solutions, and it’s how I avoid performing “innovation theater.”

    To keep exploration healthy, I time-box my learning. I block recurring windows specifically for experiments, reading, and hands-on trials so they don’t overrun my core product work. During these blocks, I’ll set a clear question, run a tight test, and capture what I learned. No rabbit holes, no endless tinkering.

    I also separate “interesting” from “actionable.” Plenty of inputs are worth awareness, but very few deserve immediate action. I bookmark the rest for later. This simple filter reduces cognitive load and keeps my backlog—from ideas to proofs of concept—well-governed.

    Social media can amplify technology hype cycles, so I establish boundaries. I batch consumption, mute low-signal channels, and prioritize practitioner communities over performative threads. The goal isn’t to be first; it’s to be right for my customers, my team, and our strategy.

    When choosing what to try next, I use a practical rubric. Does the tool target a real friction I’ve seen in discovery or delivery? Can it plug cleanly into our AI workflows without unsustainable glue work? Do we have a safe, compliant way to test it? Is there a plausible path from trial to compounding value? If the answer isn’t a confident yes to most of these, I wait.

    Depth beats breadth. I’d rather take one promising tool into a real use case, instrument it, and measure outcomes than skim ten trending demos. That tighter loop produces sharper intuition, clearer product bets, and better partner decisions. A quick opportunity solution tree helps me connect user pain to outcomes before I let any solution onto the field.

    In the episode, Petra Wille and Teresa Torres talk candidly about managing FOMO, deciding which tools to explore, and designing intentional learning systems. They discuss why starting with a problem is more valuable than starting with a tool, how social media amplifies technology FOMO, and why going deeper with fewer tools can lead to better learning. If you’ve ever felt like you’re falling behind because you haven’t tried the latest AI tool yet, this conversation will help you rethink how you approach learning and experimentation.

    If you’re curious about what came up, here are some of the tools and communities mentioned: Claude Code, OpenClaw (formerly Clawdbot, Moltbot), NotebookLM, Product Talk, ElevenLabs, Lenny’s Newsletter Community, and even a nod to Bridgerton for a touch of levity.

    My takeaway is simple but powerful: curiosity doesn’t require constant experimentation. The best product managers cultivate a balanced system—grounded in product discovery, energized by focused experiments, and protected by clear boundaries—so we can learn faster while staying pointed at outcomes that matter.

    Discussion Question: How do you decide which new tools or technologies are worth exploring—and which ones you can safely ignore?

    Resources & Links: Follow Teresa Torres: https://ProductTalk.org | Follow Petra Wille: https://Petra-Wille.com

    Full transcripts are only available for paid subscribers.

    Have thoughts on this episode? Leave a comment below.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Outcomes vs Outputs: How I Stopped the Feature Factory and Drove Real Product Impact

    Outcomes vs Outputs: How I Stopped the Feature Factory and Drove Real Product Impact

    “Outcomes over outputs” is the right mantra—and one I’ve championed across product teams—but turning it into daily practice is where most teams stumble.

    It’s simple in theory: focus on the impact of what we build, not just shipping features. In reality, it’s rarely black and white because most teams are asked to do both—hit outcomes and deliver specific outputs—at the same time.

    In a benchmark survey, 20% of product teams claim to be outcome-focused, nearly half describe themselves as working in a mix of outcomes and outputs, and about 30% are still primarily working with outputs. I’ve seen versions of this in my own org: we aspire to outcomes, but our rituals, roadmaps, and reporting still reward shipping.

    Here’s how I draw the line clearly, coach my teams to avoid common traps, and negotiate better, more actionable outcomes that unlock genuine product discovery and business results.

    Simple definitions we live by

    An output is something you build or produce—a feature, a project, an initiative. It’s something your team ships.

    An outcome is the impact of that output—a change in customer behavior or a business result.

    Josh Seiden puts it well in his book Outcomes Over Output: “An outcome is a change in human behavior that drives business results.”

    Infographic comparing outputs vs outcomes in product management: outputs are what you ship—feature, project, integration; outcomes are what changes—customer behavior and business results; arrow notes where value happens.
    Shift from shipping to shaping results. This graphic clarifies outputs vs outcomes, revealing that value emerges between deliverables and impact—when features change customer behavior and move business results.

    I distinguish business outcomes from product outcomes. Business outcomes are typically financial metrics that measure the health of the business (e.g. increase revenue or reduce costs) while product outcomes measure a customer behavior in the product or a sentiment about the product.

    Here’s a simple example I’ve used with platform teams. Many B2B companies support a number of integrations. Integrations are outputs. Having integrations alone doesn’t create value. Customers using and finding value in those integrations—that’s an outcome. If those customers retain their subscriptions longer because of the integrations—that’s also an outcome.

    Building something isn’t the same as creating value. That’s the core of this distinction, and it’s what separates empowered product teams from feature factories.

    Why this distinction matters for empowered product teams

    When we task teams with delivering outputs, they’re done when the software ships. When we task teams with delivering outcomes, they aren’t done until the software ships and has the expected impact.

    That small shift changes almost everything about how a team works: what we measure (impact, not just delivery), how we know we’re done (measurable behavior change, not release notes), the autonomy we grant (told what to achieve, not what to build), and the planning artifacts we use (an opportunity solution tree beats a feature roadmap when we’re exploring the best path to an outcome).

    When I assign outcomes, I’m giving the team latitude—and responsibility—to figure out the best path to success. That’s what opens the door for real product discovery and continuous discovery habits.

    Infographic comparing output-driven vs outcome-driven teams, covering metrics measured, team autonomy, definition of done, and planning artifacts: feature roadmap vs opportunity solution tree.
    Shift your lens from shipping features to achieving impact. This side-by-side visual explains how outcome-driven teams measure success, grant more autonomy, define 'done' by results, and plan with an opportunity solution tree.

    Examples: spotting outputs disguised as outcomes

    Clear-cut example: “Our outcome is to deliver an Android app.” An Android app is something we build and ship. It’s clearly an output.

    To get to an outcome, I ask, “What’s the value of having an Android app?” or “How will we know the Android app is successful?”

    We might answer: “Having an Android app will allow us to engage more users. We’ll know it’s successful when people engage with the app on a regular basis.”

    This answer uncovers the hidden outcome: engage more people. Now we can set the right scope: increase the percentage of engaged users across any platform; increase the percentage of engaged mobile users; or increase the percentage of engaged Android users.

    Any of these outcomes gives us more room to explore than a fixed output. Maybe we don’t need a native app at all. We could deliver the same engagement through a mobile web experience, notifications, or email. And we’re not done when we ship—we’re done when the right people are actually engaged.

    Tricky example 1: measure the value creation moment (hires, not applicants)

    Infographic showing shift from output to outcome: build an Android app -> ask when it is successful -> increase engaged users. Highlights value, goals, and accountability in product management.
    Move beyond shipping features to the impact that matters. This visual maps the path from build an Android app to the real goal, increase engaged users, by asking why, defining value, and owning results.

    When setting outcomes, it’s tempting to choose the easiest-to-measure metric. But a good outcome measures the customer’s value creation moment.

    I worked at a company that helped new college grads find their first job. When I started working there, the primary outcome was “increase job applications.” This technically is an outcome—it measures a specific behavior in the product.

    But it doesn’t measure the value creation moment. A job seeker doesn’t get value when they apply for a job. They only get value when they get the job. Similarly, employers don’t get value from any job applicant, they get value when the right job applicant applies.

    Many job boards try to measure qualified applicants—instead of counting any applicant, they compare the credentials of the applicant to the job description and only count qualified applicants. This is better. But it still doesn’t measure the value creation moment. Both the job seeker and the employer get value when an open job is successfully filled. The right metric is hires.

    Yes, “hires” can be hard to instrument because it happens off-platform and incentives misalign. Measure it anyway, even with proxies. The easy metric isn’t always the right outcome.

    Tricky example 2: measure impact, not user-generated output (the course reviews trap)

    I worked with a team that helped students choose university courses. They set their outcome as: “Increase the number of course reviews on our platform.”

    Infographic titled '4 Outcome Traps to Avoid' for product teams, highlighting wrong moment, output in disguise, traction trap, and sentiment alone with concise guidance.
    Confusing activity with impact? This visual breaks down four common outcome traps—measuring at the wrong moment, mistaking outputs, chasing adoption, and relying on sentiment—so teams focus on real value.

    Sounds like an outcome, right? It’s a metric. You can measure it. It’s an action users take on the site—writing a review. But it’s actually an output in disguise.

    Reviews are valuable when they help a student evaluate a course. They don’t create any value if a student never sees them. More reviews aren’t always better, especially if they’re clustered where nobody looks.

    A better outcome is “Increase the number of course views that include reviews.” Now we’re measuring impact on the decision moment, not just the production of content.

    If you can hit your metric without helping customers, you’re tracking an output, not an outcome.

    Tricky example 3: measure success, not just adoption (the traction metric trap)

    “Increase the percentage of users who viewed the performance report.”

    This looks like a good outcome. It measures a specific behavior in the product. It’s within the team’s control. But it’s what I call a traction metric—it measures adoption of a single feature, not value to the customer.

    Infographic 'Why Teams Stay Stuck on Outputs' with a trust cycle—manager micromanages, team reports features, manager stays in details—and an accountability trap about safe targets and disguised outputs.
    Why teams get trapped in shipping features: a vicious trust cycle fuels micromanagement, while performance-linked outcomes push safe targets. Break the loop and refocus on customer outcomes that truly move the needle.

    Two problems arise. First, people can view the report and still not find what they need. Second, we might have perfectly happy customers who don’t need the report at all. Driving usage of an unneeded feature wastes time and erodes trust.

    Measure the value creation moment, not just feature adoption.

    Tricky example 4: pair sentiment with behavior

    I define a product outcome as a metric that measures either 1. a specific behavior in the product or 2. a sentiment about the product. But sentiment metrics—like CSAT or NPS—can be tricky on their own.

    Sentiment metrics are outcomes, but they aren’t directional. They don’t tell us where to explore or set guardrails for what to avoid. So I pair a behavior with a sentiment, for example: “Increase engagement without negatively impacting satisfaction.” I use sentiment as a counterweight.

    Facebook and Instagram illustrate why this matters. Meta is exceptional at driving engagement—but to a fault. Many of us don’t like these addictive products. Pairing engagement with a satisfaction guardrail prevents “engagement at all costs.”

    Why getting this right is hard (and how I counter it)

    Infographic, 'How to Make the Shift,' shows five steps to move teams from outputs to outcomes: translate metrics, negotiate with teams, expect iteration, watch for traps, and go deeper.
    Ready to move from shipping features to creating impact? This visual playbook shares five practical moves—translate metrics, partner with teams, iterate, avoid traps, and dig deeper—to turn outputs into measurable outcomes.

    The trust cycle. Managers don’t trust that teams can reach outcomes on their own. So managers micromanage the outputs. Teams, in turn, don’t communicate their progress toward outcomes—they communicate their progress on features. This reinforces the manager’s belief that they need to stay involved in the details. It’s a vicious cycle.

    I break it by asking teams to show their work—share assumptions, research, opportunity solution trees, and evidence behind choices—and by giving feedback on the thinking, not just the solutions.

    The accountability trap. When performance reviews are tied to hitting outcomes, teams play it safe. They sandbag their targets. They disguise outputs as outcomes to guarantee “success.”

    I treat outcomes as learning opportunities first. When we start on a new outcome, I set a learning goal—“learn what moves the needle on this metric”—before a performance goal—“increase X by Y%.” This creates space to explore without fear.

    How I get teams started with better outcomes

    Translate business outcomes to product outcomes. Business outcomes like revenue, retention, and market share are lagging indicators—by the time you see them, it’s too late to act. Product outcomes measure behavior changes within the product that lead to those business results. They’re leading indicators within the team’s control.

    Negotiate outcomes with your team. Outcome-setting should be a two-way conversation. Leadership brings the cross-company context. The team brings customer insight and technical realities. Neither side dictates; we co-own the target and the constraints.

    Infographic on outcomes vs outputs in product management: side-by-side panels show Feature Factory (measure what you ship) versus Product Team (measure what it changes), highlighting the shift to impact.
    Stop celebrating shipped features and start celebrating change. This visual contrasts a feature factory mindset with a true product team, urging teams to track impact, not output, and define success by outcomes.

    Expect to iterate on your metrics. Your first outcome metric probably won’t be right. That’s normal. Sonja at tails.com went through four iterations—from 90-day retention to 30-day to 5-day to behavior-based metrics—before landing on something actionable. Thomas at Bluestone Analytics iterated three or four times before finding the right metric. Iteration is the work.

    Watch for common mistakes. Outputs disguised as outcomes. Traction metrics masquerading as product outcomes. Sentiment metrics without direction. Business outcomes assigned directly to product teams without translating to behavior change.

    Use the right artifacts. Replace feature roadmaps with an opportunity solution tree to explore multiple paths, test assumptions, and sequence bets explicitly against a clear outcome.

    Align OKRs with outcomes. If your company uses OKRs, make sure the “KR”s are true product outcomes (behavior change and value creation), not a list of features to ship.

    The bottom line

    When we shift from an output-first mindset to an outcome-first mindset, it doesn’t mean that outputs stop mattering. Product teams will always ship features, and the ability to do so quickly and with quality still matters. This shift simply ensures those features achieve the intended impact. We aren’t done when we ship—we’re done when what we shipped has the intended impact.

    Measure success by the impact of what you ship and you’ll build a product team that learns, adapts, and creates real value. Measure success by what you ship and you’ll get a feature factory.

    Quick self-check: is your “outcome” really an outcome?

    Ask yourself: 1) Does it measure a behavior change or a sentiment tied to value creation? 2) Could we hit it without helping customers? 3) Is it adoption of a single feature (a traction metric) or a result that customers and the business care about? 4) Do we have a counter-metric to prevent unintended harm? If you stumble on any of these, refine it before you commit.

    Inspired by this post on Product Talk.

    Book a consult png image