Tag: product roadmapping and sprint planning

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.

June 2, 2026
AI Operating Model Playbook: Why 80% Stall—and How the Top 1% Accelerate with Discipline

I keep meeting talented product teams who can demo impressive proof-of-concepts but can’t get durable business impact into production. The difference isn’t raw ingenuity—it’s the operating model. As I’ve scaled AI initiatives in my own organization, one sentence has proven painfully accurate: "What the top 1% of AI-native product teams are doing differently – and why most won't catch up without rebuilding the operating model."

When I say “AI operating model,” I mean the end-to-end way we set strategy, discover value, build, ship, govern, and learn—specifically adapted for AI systems. If we try to bolt AI onto a classic software cadence, we stall. If we rebuild our operating model around AI’s unique constraints and compounding advantages, we accelerate.

It starts with strategy. I anchor our portfolio to explicit outcomes, not features—tying every initiative to measurable customer and commercial impact. Driver trees and an opportunity solution tree make tradeoffs transparent, while outcomes vs output OKRs prevent us from celebrating activity over results. This is how empowered product teams earn autonomy without losing alignment on the AI Strategy.

Next is discovery. Continuous discovery reframes “can we ship a model?” into “can we change a behavior or decision with acceptable risk?” I pair customer interviews with in-product telemetry and journey mapping to qualify moments of high value and high frequency. The litmus test: can we describe the target workflow in plain language and simulate success before training models? If not, we’re not ready.

Data foundations come third. A retrieval-first pipeline is now my default, not an afterthought. We invest in data governance, privacy-by-design, and observability so we can explain where answers come from, prove consent, and debug drift. Without trustworthy data and clear lineage, every downstream AI promise is fragile—and your AI readiness is mostly theater.

Then I insist on eval-driven development. Before we optimize prompts or tune models, we define offline and online evals that represent the real task, including safety and “gotcha” cases. We treat prompt engineering, context window management, and agentic AI patterns as hypotheses that must beat a baseline under repeatable tests. This moves debate from opinions to evidence.

Shipping is where most teams quietly stall. We integrate AI into our CI/CD with feature flags, shadow modes, and progressive rollouts, building MLOps into the same platform that runs our services. I watch DORA metrics to keep delivery velocity healthy, but I also watch AI-specific signals—input distribution shifts, response variance, and time-to-mitigation—so we catch regressions before customers do. Platform scalability matters more when inference costs and latency can spike overnight.

Governance isn’t a gate at the end; it’s a runway from the start. We operationalize AI risk management with tiered reviews, model and data cards, and clear escalation paths. The goal is not to slow down, but to reduce surprise—so product managers, engineers, and legal share the same playbook for safety, fairness, and regulatory compliance.

Value capture closes the loop. We connect product metrics to commercial levers like Net Recurring Revenue (NRR) and retention analysis, then shape packaging so customers pay for outcomes, not raw compute. This is where product-led growth meets sales-led growth: we demonstrate value in-product, then arm go-to-market teams with unambiguous proof.

So why are 80% of teams stuck? Three patterns recur: technology FOMO masquerading as strategy, fragmented data that can’t support high-quality retrieval, and a lack of evals that forces decisions by vibes. Add ad hoc governance and you get pilots that impress in slides but wither under real-world variance.

How do the top 1% think differently? They rebuild the operating model first. They position discovery around workflows, not models. They invest in retrieval-first architectures early. They standardize evals. They ship with guardrails. And they treat “learning per week” as a sacred metric—because compounding insight beats sporadic heroics.

If you need a 90-day plan, here’s the sequence I use. Week 1–2: run a content audit of data sources and map the top five repeatable workflows ripe for AI leverage. Week 3–4: define success metrics and offline evals for one beachhead use case. Week 5–8: build the retrieval pipeline, implement prompt baselines, and instrument observability. Week 9–12: ship behind feature flags, run A/B testing with safety thresholds, and iterate on failure cases. By the end, you’ll have a reusable blueprint—not just a demo.

Team design matters. I staff product trios (PM, design, tech lead) with forward deployed engineers or solutions engineering partners who sit with customers. That proximity reduces spec ambiguity and accelerates learning. It also sharpens our product roadmapping and sprint planning because we plan against outcomes, not outputs.

The hardest part is emotional, not technical: letting go of familiar software rituals that don’t serve AI. Once we accept that AI demands a different operating rhythm, progress feels lighter. The top 1% don’t have secret models; they have disciplined systems. Rebuild yours, and the compounding benefits will outpace any single model upgrade.

Inspired by this post on Product School.

May 28, 2026
Principal Product Manager Playbook: Strategy, Discovery, and Measurable Impact That Lasts

I’ve spent my career building products that move the needle, and as a Principal Product Manager and product leader at HighLevel, I focus on the work that compounds: clear strategy, rigorous discovery, and measurable outcomes. My role is to turn ambition into traction by aligning vision with execution, then proving impact with data, not anecdotes.

Great product strategy starts with customer value and ends with business results. I frame the narrative around a defensible value proposition, clarify points of parity and points of differentiation, and translate that into driver trees tied to outcomes vs output OKRs. This creates line-of-sight from our roadmap to metrics that matter—Net Recurring Revenue (NRR), activation, retention, and expansion—so teams know exactly why their work matters.

Discovery is continuous, not a phase. I partner in product trios to run continuous discovery through customer interviews, journey mapping, and an opportunity solution tree that separates signal from noise. By keeping a weekly cadence of learning, we reduce risk early, refine problem statements, and ensure we’re solving the highest-leverage jobs to be done for our customers.

Evidence beats opinion, so I obsess over instrumentation and experimentation. I rely on Amplitude analytics for behavioral analytics, cohorting, funnel health, and retention analysis, and I validate hypotheses with A/B testing designed around a minimum detectable effect (MDE). With feature flags, we decouple deployment from release, ramp value safely, and learn fast without exposing the entire base to risk.

Execution only works when planning is pragmatic and transparent. I run product roadmapping and sprint planning as living systems informed by discovery insights and real usage data. That means tighter stakeholder management, clearer trade-offs, and fewer surprises for go-to-market partners—so we ship confidently and tell a crisp story from beta through scale.

I also apply modern AI practices where they create real leverage. For exploration and prototyping, I use gen ai for product prototyping and practical workflows from LLMs for product managers to accelerate research synthesis, scenario mapping, and content generation—always with human-in-the-loop judgment, data governance, and privacy-by-design as non-negotiables.

The result is a disciplined, human-centered, and data-powered approach. I build empowered product teams that learn faster than the market, align on few-but-mighty bets, and compound outcomes over outputs. That’s how a Principal Product Manager consistently turns strategy into durable, product-led growth.

Inspired by this post on Amplitude – Perspectives.

May 12, 2026
Unlock High-Leverage PM Work: 5 Claude Cowork Playbooks to Turbocharge Your Strategy

In my role leading product teams, I’m relentless about freeing time for high-leverage work—clarifying strategy, sharpening positioning, and unblocking execution. Claude Cowork has become a reliable AI partner in that mission, helping me automate repeatable tasks while preserving judgment for the decisions that matter most.

Get 5 playbooks to automate common product management tasks with Claude Cowork and free yourself for higher-leverage PM work.

When I say “playbooks,” I mean structured, repeatable workflows that turn messy inputs into crisp outputs—without sacrificing rigor. With agentic AI, LLMs for product managers, and thoughtful prompt engineering, these playbooks plug directly into my product roadmapping and sprint planning process, accelerating discovery, analysis, and stakeholder alignment.

Playbook 1: Continuous discovery synthesis. I route raw customer interviews, support threads, and behavioral analytics into Claude Cowork to cluster themes, extract Jobs-to-Be-Done, and propose opportunity areas. It drafts an initial opportunity solution tree with clear problem statements, target outcomes, and candidate solutions, which I then refine with the team. This shortens the loop between customer interviews and actionable insights while preserving the nuance that continuous discovery requires.

Playbook 2: Strategy-to-roadmap alignment. Starting from our product strategy and target outcomes, I ask Claude Cowork to translate goals into a prioritized roadmap, calling out outcomes vs output OKRs and showing driver trees that connect initiatives to measurable impact. It flags dependencies and suggests stakeholder management touchpoints, making the narrative behind prioritization transparent and easier to socialize across product trios and leadership.

Playbook 3: Experiment design and A/B testing. To move from ideas to evidence, I have Claude Cowork generate testable hypotheses, success metrics, and guardrails for A/B testing. It produces experiment briefs, checks statistical assumptions like minimum detectable effect (MDE), and suggests instrumentation plans for tools such as Amplitude analytics. I use these drafts to speed up reviews without compromising on methodological rigor.

Playbook 4: Launch communications and in-product guidance. After we ship, I leverage Claude Cowork to assemble UX writing, release notes, and in-app guides tailored to user segments. It proposes short product tours, contextual tooltips, and support macros that keep messaging consistent across Pendo or Intercom while reinforcing our value proposition. The result is faster, more cohesive go-to-market execution with fewer round-trips.

Playbook 5: AI risk, governance, and quality checks. Before anything goes live, I use Claude Cowork to run structured reviews for data governance, privacy-by-design, and AI risk management. It helps draft acceptance criteria, red-team prompts for edge cases, and an eval-driven development checklist so the team can track model behavior and mitigate regressions over time. These safeguards maintain trust as we scale AI workflows across the product surface.

To make these playbooks sing, I seed Claude Cowork with a retrieval-first pipeline of canonical docs—vision, strategy, OKRs, analytics dashboards, and definition-of-done checklists—plus prompt templates tuned for our voice and review standards. Tight context window management, explicit role instructions, and lightweight evaluations keep outputs accurate, auditable, and on-brand.

The impact has been compounding: faster discovery-to-decision cycles, clearer roadmaps tied to outcomes, stronger experiments, and launch content that lands. Most importantly, the team spends more time on creative problem solving and stakeholder partnership, not manual synthesis or formatting. If you’re ready to reclaim your calendar and elevate your product strategy, start with these five Claude Cowork playbooks and iterate from there.

Inspired by this post on Amplitude – Perspectives.

May 12, 2026
My Playbook for a Smarter Feature Launch Slack Channel with Agents, Feature Flags, and Readouts

Feature launches move fast, and the Slack channel is our command center. Recently, I leveled it up with agentic AI so every data question, feature flag decision, and post-launch readout lives in one trusted place—faster, clearer, and with less operational drag on the team.

Learn how to set up your launch Slack channel so agents handle your data questions, feature flags, and post-launch readouts in one place.

Here’s the strategy I use. I treat the launch Slack channel like a real-time control room: agentic AI handles the repetitive asks, experts handle the judgment calls, and stakeholders stay aligned through crisp, automated summaries. The result is tighter stakeholder management, quicker go/no-go calls, and fewer meetings—without sacrificing data quality or governance.

First, I set clear channel rituals. I name the space #launch-[feature], declare scope and SLAs, and pin the success metrics, dashboards, and rollout plan. Product, engineering, data, support, and GTM all join. I keep threads focused: one for metrics, one for incidents, one for enablement, one for feedback. This small bit of structure makes agent responses and human follow-ups easy to find.

Next, I add a data questions agent. The agent connects to approved sources and answers the most common queries—activation by cohort, conversion by segment, latency by region—directly in-thread with citations and timestamps. When the question requires nuance, the agent routes to an owner and posts a handoff note, preserving context. This keeps our AI workflows safe and reliable while giving the team quick visibility.

Then I wire in a feature flags agent. It exposes read-only status by environment, shows rollout percentages, and links to change history. When a toggle is requested, the agent enforces approvals and logs who asked, who approved, and why. We can pause, ramp, or roll back in seconds—with auditability intact. Feature flags become an operational muscle instead of a bottleneck.

Finally, I schedule post-launch readouts. The readout agent publishes T+1 hour, T+24 hours, and T+7 days summaries: adoption, performance, anomalies, and key learnings. It highlights A/B testing results, flags outliers, and threads follow-up actions to owners. The team gets a single source of truth for post-launch readouts without scrambling across tools.

Governance matters. I apply role-based access, protect PII, and make the agent cite sources so we can trust what we see. I use Agent Analytics to monitor response accuracy, deflection, and time-to-answer, then refine prompts and permissions. This is practical AI risk management: clear boundaries, human-in-the-loop for consequential decisions, and transparent logs.

The impact has been real: faster decisions during go-to-market, fewer pings to data and engineering, and higher confidence in our product management rituals. Centralizing “questions, flags, and readouts” in Slack doesn’t replace expertise—it frees it to focus on the hard problems.

If you’re rolling this out, start small: define the channel, pin your metrics, launch the data agent with a handful of approved queries, add the feature flags agent with strict approvals, and automate a simple daily readout. Iterate weekly. Within one or two launches, you’ll feel the compounding benefits.

Inspired by this post on Amplitude – Best Practices.

May 11, 2026
5 Proven Agent Skills I Use to Automate Weekly Product Reviews with Claude, Cursor, and Codex

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.

May 4, 2026
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.

May 4, 2026
Stop Obsessing Over the Roadmap: The High-Impact CPO Playbook for Ambition, AI, and Focus

I used to treat the roadmap like a sacred artifact. Over time, I learned the uncomfortable truth: the best product leaders stop obsessing over the roadmap and start obsessing over ambition. My number one job isn’t shipping features—it’s raising the bar for what the team believes is possible and carving out the time to think deeply. When I spend half my time thinking (not doing), the business moves faster, customers feel the lift, and outcomes finally outpace output. The impact of a great product leader starts with context-setting. Under a founder, the role often skews toward influence without deference—pressure-testing ideas, bringing data and customer insight, and helping translate founder vision into a portfolio and product strategy. Under a hired CEO, it’s about aligning capital allocation, setting clear investment theses, and ensuring product roadmapping and sprint planning connect directly to financial and go-to-market realities. Ambition beats activity. I push teams beyond “what we can fit this quarter” and anchor on value creation: how does this create net-new customer advantage? We measure with outcomes vs output OKRs, tie initiatives to activation, retention, and Net Recurring Revenue (NRR), and celebrate learning velocity as much as shipping velocity. When the narrative moves from features to outcomes, customers notice—and so does the business. I’m demanding without breeding fear. The trick is a high bar plus psychological safety: crisp quality standards, blameless postmortems, and an expectation of intellectual honesty. I separate people from problems, model curiosity over certainty, and use stakeholder management to align early, not late. The result is a culture where empowered product teams volunteer for the hard problems because the path to excellence is transparent. Most “politics” is an incentives problem. When functions optimize for different scorecards, status games fill the vacuum. I fix this with a shared driver tree, clarified decision rights, and compensation aligned to company-wide outcomes. Once incentives match the strategy, alignment stops being a meeting and starts being momentum. I use a three-bucket framework to delegate decisions. Bucket 1: I decide (irreversible, cross-company implications, or existential risk). Bucket 2: Team decides; I’m consulted (reversible or scoped risk with clear guardrails). Bucket 3: Team decides; I’m informed (local optimization and execution details). This creates speed without surrendering strategic coherence, and it’s a practical approach to building empowered product teams. I’m militant with my calendar to protect thinking time. I block two to three mornings per week for deep work, partner with executive assistants to defend those blocks, and aggressively prune low-ROI rituals. “Thinking time” isn’t a luxury; it’s where product strategy is forged, complex bets are sequenced, and product-market signals get synthesized. I also fly at a low altitude—joining customer calls, reviewing designs and PRDs weekly—so judgment stays grounded without micromanaging. The AI era demands more risk in our roadmaps. I place a few venture-like bets, timebox them, and instrument eval-driven development so we can kill or scale quickly. The concept of an app is changing—from static screens to adaptive workflows, assistants, and agentic AI. This shifts product roadmapping and sprint planning toward capabilities, data leverage, and safety systems (privacy-by-design, data governance, and AI risk management) rather than a linear feature list. Innovation teams need shelter from the core. I separate their KPIs from immediate monetization, create technical sandboxes with clear guardrails, and run a parallel discovery track. Forward deployed engineers sit with customers; continuous discovery ensures we converge on problems worth solving; and when something works, we integrate it into the core without smothering it with legacy processes. I use a barbell planning horizon: 12 weeks of executional clarity and 12–24 months of strategic theses. Anything beyond that is scenario planning, not a promise. We revisit the theses quarterly, tie them to product strategy and go-to-market strategy, and ensure each increment is measurable. This balances focus with optionality. Excellence in 2026 looks different. It requires fluency in AI Strategy, strong data governance, and the ability to move from feature leadership to system leadership. Product leaders must be bilingual—equally comfortable discussing LLMs and retrieval-first pipelines as they are speaking in NRR, gross margin, and payback periods. The job is to translate technology shifts into durable customer advantage. Being a great C-suite partner means acting enterprise-first. I co-own capital allocation with finance, sequence hiring with people and engineering, and encode our strategy into operating cadence. I treat sales-led growth and product-led growth as complementary systems, not rival religions, and I bring clarity to trade-offs with driver trees and scenario plans. Chase impact, not titles. The fastest growth I’ve seen comes from optimizing for scope, learning rate, and mentors—not for role labels. If you want comp and career to compound, maximize the value you create: fix activation, improve retention, unlock expansion, or reduce cost-to-serve. Titles follow impact, not the other way around. Four bottlenecks stall careers repeatedly. First, a scope ceiling—holding too much IC work and not scaling through delegation. Second, stakeholder friction—underinvesting in alignment and communication. Third, weak people leadership—not hiring, coaching, and performance-managing decisively. Fourth, fuzzy strategy—if your strategy can’t be drawn as a driver tree, your teams can’t execute it. Remove these bottlenecks and your trajectory changes fast. In the end, the roadmap is an instrument, not the strategy. Raise the team’s ambition, align incentives, protect deep work, and take smarter AI-informed risks. Do that consistently and the roadmap stops being a crutch—it becomes a flywheel.

April 30, 2026
Principal Product Manager Playbook: Strategy, Leadership, and Execution That Scales

I’ve learned that the Principal Product Manager role is the crucible where strategy, execution, and leadership meet. It’s less about owning a backlog and more about owning an outcome—aligning a portfolio of bets to a clear vision, then guiding empowered product teams to deliver measurable impact at pace.

Unlike a Senior PM who may anchor a single area or a Group PM who often has direct people management, I operate as a force multiplier. I set product strategy, shape cross-functional operating rhythms, mentor PMs and product trios, and influence executives and partners—without relying on formal authority. The bar is outcomes over output, clarity over activity, and learning over certainty.

My first move is to define a crisp North Star and the driver tree beneath it. I translate company goals into outcomes using outcomes vs output OKRs, ensuring every roadmap item ties to a measurable lever (conversion, retention, activation, expansion). This structure prevents feature factory drift and creates a shared language for prioritization and trade-offs.

Discovery is continuous, not a phase. I run weekly customer interviews, synthesize insights with journey mapping, and map opportunities with an opportunity solution tree so teams solve the right problems before building the right solutions. I use the Kano Model to calibrate expectations on “delighters” versus “must-haves,” and I document assumptions so we can invalidate them early instead of discovering them late.

Data sharpens judgment. I rely on Amplitude analytics for behavioral analytics, retention analysis, and funnel diagnostics, pairing this with A/B testing to validate causal impact. I size experiments with minimum detectable effect (MDE) to reduce false negatives, and I instrument leading indicators to shorten feedback loops—so we can pivot weeks earlier, not quarters later.

Execution is where strategy earns its keep. I plan in outcomes-based quarters and deliver in two-week sprints, keeping a living roadmap that reflects new learning. Product trios (PM, design, engineering) co-own problem framing and solution shaping, while I maintain stakeholder management with transparent trade-offs and crisp decision records. This balance preserves autonomy while ensuring alignment.

High standards spread through coaching. I mentor PMs on writing testable bets, crafting compelling problem statements, and telling a metrics-first narrative. I champion empowered product teams because autonomy plus accountability consistently outperforms mandate-driven delivery—and because it attracts and retains top talent.

As scope scales, so does storytelling. I align leaders through a brief, repeatable operating cadence: monthly business reviews tied to driver trees, quarterly OKRs grounded in outcomes, and QBRs vs OKRs alignment to keep customer-facing teams in lockstep. I choose first principles decision making for high-ambiguity calls, and I make risks explicit early.

Go-to-market is part of product, not an afterthought. I partner with marketing and customer success to craft value propositions, then validate them in-product with in-app guides and product tours. We define user activation precisely, instrument it, and iterate messaging and onboarding until time-to-value collapses. This is how product-led growth compounds.

Technical excellence reduces product risk. I advocate for feature flags to decouple release from launch, CI/CD to increase deployment frequency, and observability to catch regressions fast. These practices make experimentation cheaper and safer, which in turn makes bold bets possible.

My 30-60-90 framework is simple. In 30 days, clarify outcomes, baselines, and constraints; in 60, run discovery sprints and ship the first experiments; in 90, land two to three measurable wins, prune low-signal bets, and scale the operating cadence. The goal is momentum with meaning—evidence, not theater.

At HighLevel, I’ve seen that the Principal Product Manager unlocks leverage by combining strategic clarity with disciplined learning and empathetic leadership. When we align on outcomes, instrument for truth, and empower teams, we don’t just ship features—we shift the trajectory of the business.

Inspired by this post on Amplitude – Best Practices.

April 29, 2026
Beyond Command and Control: How I Build Trust, Speed, and Autonomy in Product Teams

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.

Inspired by this post on Product Talk.

April 28, 2026
AI Agents That Truly Help Product Teams: A Practical Framework for When—and When Not—to Use Them

Every week, I field the same question from product leaders and engineers: should we deploy an AI agent here, or are we overfitting the problem to a shiny solution? Learn when AI Agents actually help product teams—plus a simple framework to decide when not to use them.

When I say “AI agents,” I’m talking about autonomous or semi-autonomous systems that can perceive context, plan steps, and take actions across tools and data sources with minimal supervision—what many now call agentic AI. In product management terms, they’re not just another feature; they’re an operating model shift. Used well, they compound team leverage. Used poorly, they add invisible complexity, new failure modes, and governance headaches.

To make the call with confidence, I use a straightforward VITAL framework that my team can apply in minutes. It keeps us honest about where AI agents are a force multiplier—and where a simpler automation, rule, or in-product UX is the better choice.

V is for Volume. Agents shine where there’s sustained, repetitive, high-throughput work: triaging inbound support, cleansing CRM records, orchestrating QA checks, or synthesizing weekly research summaries. If the workflow happens rarely or ad hoc, an agent is often overhead in disguise.

I is for Instructions. Can I specify success in clear, testable terms? Strong instructions include measurable acceptance criteria and constraints. If I can’t articulate what “good” looks like without hand-waving, the task likely needs product discovery, not autonomy.

T is for Tolerance. What is the blast radius if the agent makes a wrong call? Low-stakes, reversible actions with tight guardrails are ideal. If the tolerance for error is near zero (e.g., irreversible financial transactions or sensitive regulatory actions), favor human-in-the-loop, stronger approvals, or defer agents entirely.

A is for Access. The agent needs the right data, tools, and permissions, with privacy-by-design and data governance in place. If telemetry is sparse, integrations are brittle, or you can’t enforce least-privilege access, you’ll fight fragility more than you’ll gain leverage.

L is for Learning loop. Agents require eval-driven development, Agent Analytics, and continuous feedback to stay accurate as reality shifts. If you can’t measure quality, latency, and cost per outcome—or you lack a retrieval-first pipeline to ground responses—expect drift and stakeholder distrust.

Now, the counterweight. Don’t use agents when the problem is novel or strategically ambiguous and you still need exploratory research; when outcomes are unmeasurable or subjective without heavy context; when stakes are high and the acceptable error rate is effectively zero; when data is siloed, stale, or legally constrained; when the work is one-off or low-volume; or when your team can’t commit to instrumentation, evaluations, and ongoing maintenance. In these cases, a simpler rules engine, a clearer UX, or a well-defined workflow usually beats agentic complexity.

Here’s how this plays out in practice. We’ve seen agents materially improve customer support triage (categorization, priority, and next-best-action suggestions), CRM hygiene (deduplication, enrichment, and routing), and release QA (regression check orchestration with human sign-off). Conversely, we avoid agents for nuanced pricing decisions, sensitive risk scoring without robust datasets, or any workflow where “explainability” and auditability trump speed.

Operationalizing agents is a product problem before it’s an ML problem. Start narrow with a retrieval-first pipeline and rigorous prompt engineering, define success metrics upfront (quality, latency, cost per task), and run head-to-head evaluations against human baselines. Ship behind feature flags, monitor with Agent Analytics, and graduate from assisted to autonomous modes only after you’ve proven stability. Align this with product roadmapping and sprint planning so the work lands as durable capability, not a lab demo.

Finally, be honest about build vs buy. If the workflow is a point of parity, consider buying and focusing your team on integration quality and governance. If it’s a potential source of competitive differentiation, invest in a modular architecture with clear context window management, strong observability, and a feedback loop tightly coupled to your empowered product teams.

The bottom line: AI agents unlock leverage when there’s volume, clarity, tolerance, access, and a learning loop. If any of those pillars is missing, pause. Your best next move is likely better instrumentation, sharper problem framing, and continuous discovery—not more autonomy. That discipline is how product teams turn agentic AI from hype into habit.

Inspired by this post on Product School.

April 27, 2026
Pretotyping vs. Prototyping: How I Validate Ideas Fast and Build Products Customers Love

I learned early in my career that beautiful prototypes don’t save you when you’re solving the wrong problem. What does save you is separating market risk from solution risk and choosing the fastest, lowest-cost way to get evidence. That’s why I rely on pretotyping to test demand in days and prototyping to refine usability and feasibility once I see a strong signal. The result: faster cycles, fewer wasted sprints, and products customers genuinely want.

Pretotyping vs. prototyping explained: differences, benefits, examples, and when to use each approach to validate ideas before you build.

Here’s how I define the two in practice. Pretotyping answers, “Should we build this at all?” Its goal is to validate real user intent and behavior with the lightest-weight artifact possible—often before any code. Think painted-door (fake door) experiments, Wizard-of-Oz flows powered by humans behind the scenes, concierge tests, landing-page smoke tests with waitlists or preorders, and simple A/B testing to gauge click-through intent. It optimizes for time-to-signal and cost-to-learn.

Prototyping answers, “Can we build this well?” and “How should it work?” Once demand is evidenced, I prototype to de-risk solution details: usability, architecture, performance, and integration. This might include interactive UI models, high-fidelity flows, technical spikes, or service stubs. Here, I optimize for learning about user experience and technical feasibility without fully committing to production.

When should you use each? If your biggest unknown is market risk—whether customers care at all—start with pretotyping. If your biggest unknown is solution risk—how to deliver an experience that’s usable, reliable, and scalable—move to prototyping. In other words, validate the “right thing” before you perfect the “thing right.”

My decision rule is simple: identify the dominant risk, then pick the smallest experiment that can credibly invalidate it. For market risk, I look for evidence of behavior, not opinions: clicks on a painted door, signups on a landing page, willingness to pay (deposits, preorders), or sustained repeat usage in a Wizard-of-Oz flow. For solution risk, I look for task completion, time-on-task, error rates, and qualitative friction from usability sessions with a realistic prototype.

Concrete examples from recent work help illustrate the difference. When exploring a new analytics insight, I shipped a fake door inside our product nav; a simple tooltip explained the concept and captured interest. Click-through rate, conversion to a short explainer, and waitlist signups told me whether the value proposition resonated before building anything. For a complex AI-assisted workflow, I ran a Wizard-of-Oz experiment: users experienced the end-to-end flow while our team manually handled the “AI” behind the curtain. That gave us real engagement data and edge cases to inform the prototype and later the MVP.

Metrics matter. I set a clear hypothesis with a guardrail on sample size and a minimum detectable effect I’d consider actionable. For pretotyping, I focus on time-to-first-signal, intent conversion (CTR to interest, interest to signup), cost-per-qualified-lead, and evidence of willingness to pay. For prototyping, I prioritize task success rates, usability severity findings, and qualitative insights that materially change the design or technical approach. Above all, I avoid vanity metrics and anchor decisions to outcomes, not output.

My repeatable playbook looks like this: (1) Frame the problem and value proposition in one crisp sentence. (2) Choose the leanest pretotyping method that can reveal real behavior. (3) Define success metrics and a decision rule before you run the test. (4) Launch quickly, instrument well, and let the data run long enough to be credible. (5) If demand is strong, promote to a prototype to refine UX and de-risk technicals; if not, iterate the proposition or stop. This keeps product discovery continuous and ensures roadmapping and sprint planning are guided by evidence.

There are ethical guardrails I never skip. Painted doors must set correct expectations once clicked; waitlists or learn-more pages are honest and respectful. For Wizard-of-Oz and concierge tests, I’m explicit about data handling and provide timely follow-up. Trust compounds when experiments are transparent and user time is valued.

Tooling can accelerate the cycle without diluting rigor. I often use lightweight design systems and no-code automations to stitch together realistic flows, and I’ll leverage gen AI for product prototyping to generate copy, microinteractions, or data scaffolding. But the principle remains: don’t over-invest until evidence earns the investment. Empowered product teams thrive when they optimize for learning velocity, not feature velocity.

If you’ve ever felt the tension between shipping fast and shipping right, this approach resolves it. Pretotype to prove the market; prototype to perfect the solution. Do that consistently and you’ll spend more time delivering outcomes customers value—and far less time debating outputs.

Inspired by this post on Product School.

April 27, 2026