Product management tools can reduce coordination work, preserve decisions, and help teams turn customer and product signals into action. Choosing them well, however, requires more than comparing feature lists.
The supplied Amplitude – Perspectives excerpt defines these tools broadly as platforms, websites, and software that make a product manager’s job easier. Because the excerpt does not include the product names, evaluations, senior-PM advice, or supporting details promised by its headline, the framework below does not attempt to reconstruct that missing list.
What belongs in a product management tool stack
A product management stack is the collection of systems used to support recurring product work. Depending on the organization, that work may include collecting customer evidence, analyzing behavior, defining priorities, documenting decisions, planning delivery, running experiments, and communicating progress.
The important distinction is between owning software and enabling a workflow. A tool creates value when it makes a necessary activity clearer, faster, more reliable, or easier to share. If it merely duplicates an existing system, it can add another place to search, update, and reconcile.
Key takeaways
Start with the product workflow and its friction points, not a catalog of vendors.
Evaluate adoption, integration, governance, and decision quality alongside features.
Give each system a clear purpose and a defined owner.
Reassess tools when the team, product, or operating model changes.
Begin with the decision the team needs to improve
A useful selection process begins by naming a specific decision or handoff that is not working. The problem might be scattered customer feedback, weak visibility into user behavior, inconsistent prioritization, unclear ownership, or roadmap updates that require repeated manual effort.
From there, the team can define what better performance looks like in general terms: less duplicate entry, a more dependable record of decisions, easier access to evidence, or clearer communication between product, design, engineering, and go-to-market groups. This keeps procurement tied to an operating need rather than enthusiasm for a new interface.
It also clarifies whether software is actually the answer. Some problems come from missing ownership, inconsistent terminology, or an undefined process. Adding a platform to that environment may formalize the confusion instead of resolving it.
Assess the full cost of fit
Functional coverage matters, but it is only one part of fit. A team should also consider how naturally a candidate tool enters existing work, which systems it must exchange information with, how permissions will be managed, and what effort will be required to maintain trustworthy data.
Adoption deserves particular attention. A sophisticated platform offers little practical value if contributors avoid it or if stakeholders cannot understand its outputs. A narrower tool that supports a well-defined workflow may outperform a broader suite that demands extensive configuration and behavior change.
The evaluation should therefore test real work rather than an idealized demonstration. Representative users can walk through a normal task, identify where information enters the system, and examine how the resulting decision reaches everyone who depends on it. That exercise reveals workflow gaps that a feature checklist may miss.
Control tool sprawl with ownership and review
Every adopted system should have a stated job, an accountable owner, and a clear relationship to the team’s source-of-truth systems. Those boundaries reduce the risk that roadmaps, customer insights, and delivery status drift into conflicting versions across multiple platforms.
Periodic review can then focus on outcomes: whether the tool is used, whether its information remains credible, whether it supports better decisions, and whether another system now covers the same need. The goal is not the largest possible stack. It is a coherent product operating environment in which each tool continues to earn its place.
Inspired by this post on Amplitude – Perspectives.
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.
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.
I’m processing a milestone moment for SaaS, AI strategy, and product leadership. One statement captures the news with clarity: “We’re excited to share that we just signed an agreement for Salesforce to acquire Fin for ~$3.6B. The transaction is expected to close in the fourth quarter of Salesforce’s fiscal year 2027.” As a product leader, I see this as a high-conviction bet on agentic AI, Customer Agents, and CRM integration at massive scale.
The backstory matters, and it’s remarkable: “Fin started as Intercom 15 years ago. We changed our name to cap our transformation just weeks ago. We were a darling of the SaaS era and invented so many of the patterns you see in software today. Nearly four years ago, in need of a reboot, we jumped on weeks-old modern LLMs to create and define the category we know as Customer Agents today.” That arc—from SaaS pioneer to LLM-powered category creator—illustrates how bold pivots, shipped with urgency and clear product strategy, can reset the trajectory of a company and a market.
From a product management lens, this deal reinforces a few truths: category creation rewards those who move first with conviction; “reboots” succeed when they’re anchored in genuine customer value; and modern LLMs, applied through disciplined roadmapping and eval-driven development, can unlock step-change outcomes in customer support ai strategy and product-led growth. It also signals the rising centrality of agentic AI and operational AI workflows inside the CRM.
The leadership dimension is just as instructive. As the announcement framed it: “Salesforce invented modern software and SaaS. And Marc Benioff is like the final boss of tech founder CEOs. In seat for 27 years, he’s one of the last of his era. Still pushing, pivoting, placing big bets.” That ethos—placing big, principled bets while adapting the operating model—sets the tone for what sustained product management leadership looks like at scale.
Customer continuity and acceleration are clearly emphasized: “To our customers: Over the past few years we’ve been shipping intensely. Including recently our groundbreaking model, Apex, and our paradigm-defining internal agent, Operator. With the resources of Salesforce this will only accelerate. And yet little will practically change. I’ll still be CEO, Des will still be running R&D, we’ll both still be committed to continuing to lead this category. Thank you very sincerely and deeply for your belief in us.” For practitioners, the signal is strong: continued focus on shipping, sharper execution readiness, and tighter integration paths inside the Salesforce ecosystem.
Smiles, clinking glasses, and a roundtable toast in a cozy private room capture the energy of a big day—celebrating Salesforce's definitive agreement to acquire Fin and the teams joining forces for what's next.
There’s a human heartbeat here too: “While this is not the end, it is a major, pivotal, special, and emotional moment for us.” Moments like this remind me that building enduring products is equal parts craft and courage—powered by teams who commit to the long game, navigate uncertainty, and still ship relentlessly.
Strategically, I expect near-term priorities to center on secure data flow and governance, deep CRM integration, and unifying telemetry for Agent Analytics across channels. On the roadmap, I’d anticipate tighter alignment between LLM safety, retrieval-first pipelines, and enterprise-grade observability—plus thoughtful go-to-market strategy enabling sales-led growth to complement product-led growth. The real unlock comes when Customer Agents are natively orchestrated with Service, Sales, and Marketing workflows—measured with clear outcomes vs output OKRs and reinforced by robust knowledge management.
For fellow product leaders, the takeaways are actionable: define category boundaries with crisp value propositions; balance speed with governance; invest in eval-driven development and continuous discovery; and keep your product trios aligned around measurable customer outcomes. Above all, build the operating cadence—metrics, rituals, and talent—that lets you compound small wins into durable differentiation.
And I appreciate the spirit of this closing line: “And now, time to get back to work. See you at our next product launch in a few weeks. (:” That’s the mindset that turns a headline into execution: celebrate briefly, then ship the next proof point.
I build products under constant pressure to learn faster without breaking trust. Claude Code has become a pragmatic addition to my AI product toolbox because it helps me move from idea to evidence with less friction—while keeping engineering, design, and compliance in the loop.
“Claude Code for Product Managers explained: what it is, why it matters, and how it helps PMs prototype, validate, and move faster.” That line captures the essence. In practice, I use it to turn ambiguous problem statements into tangible artifacts—API stubs, SQL queries, test data, and lightweight prototypes—that sharpen conversation and accelerate decision cycles.
What is it in PM terms? A code-aware assistant that helps me prototype safely and quickly. I can generate example API calls, transform messy CSVs for retention analysis, draft instrumentation plans for Amplitude analytics, or spin up a mock service to validate an integration. Because it understands structure, it’s effective at scaffolding small utilities (e.g., a data cleaner or a CLI harness) that make discovery and validation faster.
Day to day, Claude Code reduces handoffs. If I’m exploring a new partner integration, I’ll have it produce a curl library and a Postman collection, then annotate each step with acceptance criteria and expected responses. When I’m shaping a feature, I lean on it to outline event taxonomies and feature flags so that engineering can wire telemetry without guesswork. For insights work, I’ll ask it to propose SQL for cohort, funnel, and retention analysis—always verifying against source schemas before anything touches production.
Speed is only useful when it improves signal quality. I anchor the workflow in continuous discovery: small hypotheses, thin-slice prototypes, and fast instrumentation. Claude Code helps me estimate A/B testing readiness (including minimum detectable effect), generate smoke tests for critical user paths, and structure an eval-driven development loop so we learn from every iteration. It also supports context window management by summarizing long PRDs into the few constraints a prototype must respect.
Governance matters. I apply AI readiness and AI risk management principles: never paste secrets or PII, isolate sandboxes, and log prompts as docs-as-code for auditability. I prefer a retrieval-first pipeline that feeds approved product docs, OpenAPI specs, and design tokens so generations stay grounded. When tools are integrated, I favor the Model Context Protocol (MCP) to constrain capabilities and maintain least-privilege access. Human-in-the-loop review is non-negotiable—especially for anything that might influence customer data or pricing.
The best outcomes show up in product trios. I’ll facilitate a live session with design and engineering: we co-create prompts, compare alternatives, and converge on a thin slice we can ship. That collaboration keeps us empowered, reduces interpretation drift, and turns Claude Code into an accelerant rather than a sidecar. Over time, the trio curates a reusable prompt library for PRD outlines, experiment checklists, and integration playbooks.
Getting started is straightforward: define a safe environment, assemble your authoritative corpus (requirements, specs, taxonomies), and codify a few high-value templates—API exploration, instrumentation plans, sandbox data generators, and acceptance tests. Track impact with simple, objective metrics: cycle time from hypothesis to instrumented prototype, time-to-first-signal, and the proportion of decisions made with data versus opinion.
There are pitfalls. Hallucinated fields can creep into API calls, schema drift can break generated queries, and “clever” refactors may miss edge cases. I mitigate this by grounding generations in current specs, asking for unit tests alongside any code, and validating against a staging environment before anyone talks about production. Treat Claude Code as a collaborator, not an oracle.
If your mandate is to learn faster, de-risk bets, and ship with confidence, Claude Code is worth adopting. Used thoughtfully, it compresses the distance between questions and answers, elevates product discovery, and lets teams validate more ideas with fewer meetings—without compromising on governance or quality.
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
Weekly product reviews are where strategy meets execution, and over the past year I’ve turned them into a high-signal, low-friction ritual by leaning on agentic AI. As VP of Product Management at HighLevel, Inc., I’ve standardized a set of agent skills that compress preparation time, surface the right insights, and keep PMs, engineers, and designers focused on decisions—not document wrangling.
"Learn how our teams use agent skills with claude, cursor and codex to run product reviews as PMs, engineers, and designers. Here are 5 killer use cases for builder."
Below, I walk through the five skills I rely on most in our weekly cadence—each one mapped to a clear product management outcome. They’re simple to set up, easy to govern, and aligned with core practices like continuous discovery, product roadmapping and sprint planning, and eval-driven development.
Skill 1 — Backlog triage with signal extraction: I point an agent at fresh tickets, customer notes, and experiment results to cluster themes, tag impact, and flag regressions. Using a retrieval-first pipeline and Agent Analytics, the assistant ranks items by value, effort, and risk so our meeting starts with a prioritized, explainable shortlist instead of a raw queue.
Skill 2 — PRD and spec synthesizer: Ahead of the review, an agent drafts a one-page PRD update from design diffs, git history, and decision logs. With Claude Code and Cursor, it highlights interface changes, acceptance criteria, and open questions, linking back to sources. The result is a crisp, auditable brief that keeps product trios aligned without re-litigating context.
Skill 3 — Experiment and metrics analyzer: An analytics agent pulls A/B testing readouts, checks minimum detectable effect assumptions, and annotates anomalies. It turns raw telemetry into a narrative: what moved, by how much, and whether we trust it. This makes our discussion about tradeoffs, not spreadsheets, and speeds commitments on next steps.
Skill 4 — Voice-of-customer synthesizer: The assistant clusters interviews, support threads, and NPS verbatims into jobs-to-be-done and pain themes. It proposes opportunity solution tree updates and calls out places where our roadmap diverges from customer signal. That keeps continuous discovery alive in the room—even when time is tight.
Skill 5 — Roadmap and sprint planning co-pilot: After decisions, an agent converts outcomes into scoped backlog items, engineering tasks, and stakeholder updates. It drafts sprint goals, flags dependency risks, and aligns work to objectives. Because it’s grounded in the meeting record, it preserves intent while removing ambiguity.
Under the hood, prompt engineering patterns and guardrails keep these workflows predictable: a retrieval-first pipeline for context, eval-driven development for quality checks, and role-specific prompts for PMs, engineers, and designers. With Claude Code I generate structured diffs and test scaffolds; with Cursor I accelerate code-review summaries; and with codex I bootstrap utility scripts that keep the loop tight between insights and implementation.
The payoff is tangible: higher decision velocity, fewer meetings to “re-clarify,” and clearer accountability across the product organization. Just as important, governance and privacy-by-design are built in—every agent logs rationale, cites sources, and respects data boundaries—so leaders can scale AI workflows confidently.
If you’re looking to level up your product reviews, start with these five skills, measure impact with Agent Analytics, and iterate. Small automations compound quickly, and the more consistently you run them, the more your team’s attention shifts from preparing content to making better product decisions.
Inspired by this post on Amplitude – Perspectives.
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.
When uncertainty spikes, I notice many organizations snap back to "Command and control." It feels fast, safe, and decisive—especially when the stakes are high. But in product management leadership, speed without shared context is often an illusion, and control without trust rarely scales. I’ve learned that what looks like strength from the top can quietly create bottlenecks, missed signals, and disengaged teams.
Why do smart companies revert in tough times? Familiarity. Centralizing decisions can reduce short-term cognitive load and signal clarity. Yet the cost shows up quickly: leaders become single-threaded on context they cannot possibly hold, and teams spend cycles asking for permission rather than creating value. The result is slower learning and weaker product strategy just when continuous discovery and iteration matter most.
Here’s the hard truth: no single leader can hold all the context required to make every decision in a modern, cross-functional environment. The hidden complexity of customer segments, technical debt, data signals, and go-to-market constraints outstrips any one person’s bandwidth. That’s why empowered product teams, staffed with domain experts, outperform command centers—provided they’re aligned on outcomes and guardrails.
I like the burning house analogy: in a true emergency, crisp direction helps—"take the stairs, not the elevator"—because the problem is clear, the time horizon is short, and the action is obvious. But most product work is not a single burning house; it’s a city with evolving fire codes, shifting weather, and neighborhoods that look different block to block. In that environment, distributed action scales better than centralized control.
Strong leadership is not the same as command-and-control. In practice, it means setting a compelling direction, defining guardrails, and running tight feedback loops. I aim for what I call the "Flotilla of kayaks": we’re all headed to the same lighthouse, but each kayak navigates its own currents based on local information. That’s aligned autonomy—fast, resilient, and deeply accountable.
People often ask why some command-and-control companies still succeed. My view: beneath the surface, there’s usually more trust and unofficial autonomy than their org charts suggest. Teams earn freedom by shipping reliably, sharing decision rationales, and showing outcomes. Leaders tolerate—and even quietly endorse—those pockets of autonomy because they see the results.
It’s a spectrum, not a binary. I flex my style based on risk, reversibility, and time horizon—what I’d call spectrum thinking. Early in a bet, or when risks are existential, I raise the altitude and tighten the cadence. As confidence builds, I widen autonomy and shift the team to outcomes over outputs. Beware "Founder mode" when it drifts from vision-setting into day-to-day decision vetoes; it’s intoxicating early and suffocating at scale.
On decision-making, I prefer a simple principle: let the person with the most relevant expertise decide, while incorporating the right input. That’s "Consultative decision-making" in practice. In some regions, you’ll hear it called "Konsultativer Einzelentscheid." The point is to seek counsel without defaulting to consensus that bogs down speed. One person owns the call, and everyone commits to the decision once it’s made.
Practically, here’s what works for my teams: we clarify decision rights up front, draft pre-reads with clear options and risks, involve the smallest set of stakeholders required, and document the decision and expected signals ahead of time. Product trios keep discovery tight with design and engineering, while stakeholder management focuses on context, not sign-offs. We track outcomes vs output OKRs and hold regular decision reviews so we can reverse or double down fast.
My key takeaways are consistent: "Command and control" can feel efficient, but it doesn’t scale in complex environments. No leader can hold all the context. Strong leadership is about direction, guardrails, and feedback loops—not control. High-performing teams balance autonomy with alignment. Decision-making should sit with the person closest to the problem, supported by the right input and transparent reasoning. Trust is built and earned over time—and it changes how teams operate.
Reflection prompts I use with my leads: Where does your team sit on the command-and-control ↔ autonomy spectrum? Are the highest-context people truly making the decisions? What would it take to increase trust and autonomy—better instrumentation, clearer guardrails, or tighter cadences? Which calls require consensus, and which deserve a decisive, single-threaded owner?
If you’re wrestling with speed, alignment, and autonomy in your organization, start small: pilot "Consultative decision-making" on one consequential decision, set explicit guardrails, and measure the outcome. You may be surprised how quickly aligned autonomy compounds into better product discovery, sharper product strategy, and stronger execution.
I move fastest in Generative AI when I strip work down to its essential signals. At HighLevel, I rely on a single-page format—”Prototyping Requirements: The One-Pager for AI PMs”—to turn ideas into testable artifacts within hours, not weeks. This approach reinforces AI Strategy, minimizes coordination overhead, and keeps Product Management focused on learning over ceremony.
“Prototyping requirements go rogue: one page, zero bureaucracy, built for AI. Shape concepts fast, prompt tools directly, and get to the truth sooner.”
In practice, my one-pager captures only what’s required to run an immediate experiment: the user problem, the target behavior change, success signals, core constraints, intended AI workflows, and the smallest realistic path to an evaluable demo. I also include example prompts, guardrails, and evaluation criteria so the team can apply prompt engineering and LLMs for product managers without guessing.
This is eval-driven development in action. I document a minimal hypothesis, concrete inputs/outputs, and a quick plan for metrics, including qualitative signals from product discovery and continuous discovery. By prompting tools directly, we expose assumptions early, shorten feedback loops, and build an AI product toolbox that compounds learning sprint after sprint.
I run this with a product trio to ensure we balance feasibility, usability, and value. We align on risks, dependencies, and what “good” looks like, then we integrate the learnings into product roadmapping and sprint planning. The result: fewer meetings, tighter collaboration, and empowered product teams delivering sharper outcomes with less friction.
If you want speed and clarity without sacrificing rigor, adopt the one-pager. It centers the conversation on evidence, accelerates AI workflows from prompt to prototype, and makes it obvious what to try next—and what to stop doing. Most importantly, it keeps the team focused on truth over theater, which is how great AI products actually ship.
Your leadership team wants a firm answer: which AI bets belong on the roadmap, and which ones are expensive distractions? The difficult part is not generating ideas. It is deciding what to fund when customer adoption, interfaces, economics, and enterprise constraints could each develop differently.
A useful scenario plan does not hide that uncertainty behind a confident forecast. It converts uncertainty into conditional commitments: what you fund now, what you preserve as an option, what evidence would change the decision, and what you refuse to scale until the right signal appears.
Frame the exercise around a decision, not the future of AI
Broad questions such as “What will AI look like?” produce interesting conversations and weak strategy. Nobody has to choose anything at the end. Start with a decision that has an owner, a planning window, and a meaningful consequence if the underlying assumptions prove wrong.
A usable decision statement looks like this: “For this customer and workflow, should AI become the primary experience, remain an embedded assistant, or stay in discovery while the existing product carries the outcome?”
Write down five elements before discussing scenarios:
The decision: State the product, investment, or sequencing choice that must be made.
The planning window: Define when the choice needs to be made and when it can be reconsidered.
The expensive assumption: Identify what must be true for the proposed strategy to work.
The reversal cost: Separate choices that can be changed cheaply from commitments involving substantial architecture, hiring, migration, or go-to-market work.
The decision owner: Name the person accountable for changing the plan when the evidence changes.
A scenario belongs in the exercise only if it could change that decision. If two imagined futures lead to the same investment, combine them. More narrative does not create more strategic value.
Next, identify the customer need that should remain valid across the plausible futures. Customers may still need to complete a workflow with less effort, avoid costly rework, understand what the system did, or retain control over a consequential action. Those durable needs become the anchor. They keep an empowered product team focused on outcomes when a particular interface, model, or market prediction stops holding up.
Build scenarios from uncertainties that can change the plan
Do not begin by writing a best case, a base case, and a worst case. That format encourages everyone to treat the base case as the forecast. Instead, find uncertainties that are both unresolved and capable of changing your product choice.
Useful uncertainty prompts include:
Customer behavior: Does repeated AI use spread through the intended market, or remain concentrated among enthusiasts and specialists?
Interaction model: Does AI become the main way customers initiate work, or does it operate inside a familiar interface?
Scope of autonomy: Do customers delegate complete tasks, or accept AI only for bounded assistance and recommendations?
Product economics: Does the value created support the cost and operational burden of delivering the experience?
Enterprise constraints: Do security, privacy, compliance, procurement, and change-management requirements permit the proposed workflow?
Organizational readiness: Can the company evaluate, support, govern, and improve the product after launch?
Select the uncertainties with the greatest decision impact, then push competing possibilities to useful extremes. Extremes expose assumptions that a comfortable middle case can conceal. “Graphical interfaces disappear” and “AI remains an invisible utility” should not be treated as predictions. They are boundary conditions for examining what your product would need in very different environments.
For example, crossing the pattern of customer adoption with AI’s place in the workflow creates the following set of hypothetical futures:
Adoption pattern
AI’s place in the workflow
Plausible future
Decision it tests
Use broadens across intended segments
AI becomes the primary interaction
Customers increasingly start and complete the workflow through AI
Whether to redesign the core experience around an AI-first path
Use broadens across intended segments
AI remains embedded
AI becomes valuable infrastructure inside a familiar product
Whether intelligence, context, and workflow integration matter more than a new interface
Use remains uneven
AI becomes primary for specialists
A smaller group wants an AI-native experience while the broader market retains existing habits
Whether to support distinct experiences instead of forcing one migration
Use remains uneven
AI remains embedded
Bounded assistance improves parts of the workflow without replacing it
Whether focused augmentation is a better investment than broad transformation
The point is not to choose your favorite quadrant. Develop each one far enough to reveal its product implications. For every scenario, describe the target customer’s behavior, the job that still matters, the role AI plays, the constraints that become binding, and the most likely way the strategy fails.
Keep the scenarios plausible rather than theatrical. A future that cannot affect a real decision is entertainment. A future that merely restates the current roadmap is confirmation bias.
Turn each scenario into signals, triggers, and stop conditions
A scenario without observable signals is just a story. A decision-ready scenario tells you what to watch, how that evidence relates to an assumption, and what action follows if the signal appears.
The common mistake is to monitor whatever is easiest to count. Trial starts, demo enthusiasm, and requests from technically confident customers can show interest, but they do not establish broad adoption. Early adopters cannot stand in for the whole market. Segment the evidence so that enthusiasm in one cohort does not silently become a claim about every customer.
Build a signal set that answers distinct questions:
Adoption: Are intended customers returning to the AI workflow after the initial trial, and is use spreading beyond opt-in enthusiasts?
Customer value: Is the core outcome improving through less effort, less rework, fewer avoidable errors, or another measure that matters for this workflow?
Trust and control: How often do customers accept, modify, override, or abandon the result, and what reason do they give?
Enterprise viability: Are security, compliance, procurement, or change-management reviews blocking deployment or narrowing the acceptable use case?
Operational viability: Are reliability, latency, support demand, and cost-to-serve compatible with the value being delivered?
Interface behavior: Do customers initiate work through AI, or invoke AI at specific points inside an established process?
Pair every confirming signal with a disconfirming signal. This prevents the team from collecting only evidence that supports the roadmap it already wants.
Strategic assumption
Confirming evidence
Disconfirming evidence
Product response
AI should become the primary interface
Intended customers repeatedly initiate and complete the core workflow through AI
Customers retreat to the familiar interface for consequential work
Keep the AI-first experience as an option while improving embedded assistance and control
Broader autonomy will create more value
Outcome quality improves while customer intervention and rework decline
Escalations, corrections, or abandonment persist as scope expands
Narrow the delegated task and strengthen evaluation, permissioning, and fallback behavior
Adoption can expand through the target market
Repeated use spreads across intended cohorts and survives enterprise review
Use remains concentrated among specialists or stalls during approval and rollout
Preserve a dual experience and address the blocking constraint before funding broad migration
Write the trigger before launching the bet. A practical format is: “When this signal persists in the target segment and this guardrail remains acceptable, move this investment from an option to a commitment. If this disconfirming signal appears, stop, narrow, or redesign the bet.”
The exact threshold will depend on your product, baseline, risk, and decision cost. What matters is agreeing on it before stakeholders can reinterpret ambiguous results. If nobody can say what evidence would reduce or end the investment, the roadmap contains a belief, not a testable strategy.
Convert the scenarios into a portfolio, roadmap, and sprint choices
Once the scenarios and signals are explicit, separate the portfolio by commitment type. This is where scenario planning becomes operating discipline rather than an occasional workshop.
No-regret bets: Investments that support the durable customer outcome across several scenarios. Depending on the product, these may include better evaluation, permissions, observability, fallback paths, data governance, or clearer measurement. Do not label generic platform work “no regret” unless it supports a named customer outcome.
Option bets: Bounded, reversible work that buys information or preserves a future choice. A prototype, limited workflow, architecture seam, or controlled release can test an assumption without committing the entire product.
Contingent bets: Investments that make sense only after a defined signal appears. Keep the entry condition beside the roadmap item so it cannot become committed work through inertia.
High-regret commitments: Expensive moves that are difficult to reverse, such as a forced workflow migration or a large architecture and hiring commitment. Require stronger support across scenarios before making them.
This creates a roadmap with different funding postures, not a backlog pretending every item has equal certainty.
Roadmap lane
Why it exists
What earns progress
What removes it
Durable outcomes
Advance needs that remain important across plausible futures
Evidence that the customer outcome is improving
The need or outcome no longer matters
Evidence bets
Reduce uncertainty between competing scenarios
A learning milestone tied to a strategic assumption
The assumption is resolved or the evidence cannot affect a decision
Triggered scale
Expand an option after its entry condition is met
The agreed confirming signal appears while guardrails remain acceptable
A stop condition appears or the economics no longer support expansion
Deferred commitments
Preserve ideas that are valid only in a narrower future
A named scenario becomes more plausible through observable evidence
The relevant scenario is disconfirmed
At sprint planning, ask what kind of item is entering delivery. Work should either create durable customer value or buy decision-relevant information. “Build an AI assistant” is an output. “Determine whether target customers will delegate this bounded task while retaining acceptable control” is a learning goal that can change a strategic choice.
For each evidence bet, require the product trio to answer:
Which scenario and assumption does this work test?
Which customer segment must provide the evidence?
What behavior or outcome will be observed?
What result would justify more investment?
What result would stop, narrow, or redirect the work?
Which part of the work remains valuable if the favored scenario is wrong?
This also changes the stakeholder conversation. Replace “Which prediction do you believe?” with “Which commitments are justified across plausible futures, which ones are options, and what signal unlocks the next level of funding?” The latter question makes uncertainty governable.
Review the decision when a trigger fires, a critical assumption changes, or the next expensive commitment approaches. A recurring calendar review can help, but elapsed time alone is not evidence. Keep a short decision record containing the active scenarios, current signals, funding posture, stop conditions, owner, and next decision point.
Key takeaways for your next AI roadmap review
Start with a product or investment decision that could genuinely change. Do not try to describe the entire future of AI.
Build scenarios from unresolved uncertainties with high decision impact, including customer behavior and real-world constraints.
Anchor the strategy in customer needs and outcomes that remain valuable across several plausible futures.
Separate confirming evidence from disconfirming evidence, and segment adoption so enthusiasts do not masquerade as the whole market.
Predefine the signal, guardrail, trigger, and stop condition for every material option bet.
Fund no-regret moves now, use reversible work to buy information, and hold contingent commitments until their entry conditions appear.
Connect every sprint item to either durable value or a decision-relevant uncertainty.
At your next roadmap review, choose the most expensive assumption behind one AI initiative. Write the opposite plausible scenario, identify the customer need shared by both futures, and name the signal that would change the funding decision. If the roadmap still makes sense, the strategy is more resilient. If it does not, you have found the adaptation point before the market finds it for you.
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.
“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.”
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.
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)
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.”
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.
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)
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.
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.
