Category: Product Management Leadership

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
Unlock Instant Product Analytics with Amplitude Wizard CLI—One Command, Zero Friction

I’ve long believed that the fastest path to high-quality product decisions is eliminating friction between code and insight. That’s why the Amplitude Wizard CLI immediately grabbed my attention: it streamlines setup right where work happens—inside the codebase—so teams can start learning from real user behavior sooner.

Read about the new easiest way to set up Amplitude, the Wizard CLI: a one-command path to a fully instrumented Amplitude project, without leaving your terminal.

In practice, setting up analytics from the codebase means instrumentation travels with your source control, peer reviews, and CI/CD checks. This “docs-as-code” approach improves accuracy, preserves intent through pull requests, and keeps event definitions auditable over time. The result is cleaner behavioral analytics and fewer production surprises.

Developers benefit from staying in the terminal—no context switching, no brittle copy-paste steps. The workflow plugs into CI/CD, scales across environments, and supports observability from day one. For onboarding new engineers, a single command lowers cognitive load and standardizes how events are captured and named, which reduces drift as teams grow.

For product leaders, the payoff is speed and confidence. With Amplitude analytics instrumented in minutes, we can analyze behavioral analytics sooner, validate activation and retention hypotheses, and accelerate product-led growth. Because the setup aligns to a unified analytics platform, insights flow consistently across teams, and decisions reach parity with how quickly we ship.

My recommended rollout is simple: start in a feature branch, run the Wizard CLI, review the generated changes in a PR, and align naming with your event taxonomy. Gate merges with lightweight review from analytics owners, then promote via CI/CD. This keeps quality high without slowing delivery—and it makes the analytics layer as versionable and testable as the application itself.

If you’re aiming to cut time-to-first-insight, reduce setup risk, and empower engineers to own analytics instrumentation, the Wizard CLI is a pragmatic upgrade. One command, clear governance, and measurable impact on how quickly your team learns—exactly what effective product management demands.

Inspired by this post on Amplitude – Best Practices.

April 30, 2026
Making (Great) Data Flow Effortless in Amplitude to Unlock Faster Activation and Product-Led Growth

On the Amplitude growth team, the mission is clear: make it easier than ever to get (great) data flowing in Amplitude. That focus resonates deeply with me because, in my experience leading product organizations, nothing accelerates value creation faster than clean, trustworthy behavioral data reaching the right people at the right moment.

When Amplitude analytics is fueled by high-quality event streams, product teams can move from guesswork to precision. With consistent, enriched signals, behavioral analytics becomes a daily superpower—shortening time-to-first-insight, sharpening user activation strategies, and aligning everyone on outcomes. This is the foundation of a unified analytics platform that actually drives product-led growth.

“Great” data isn’t accidental; it’s designed. It starts with a clear tracking plan, human-readable event names, and strict schema validation. It continues with robust data governance, CI/CD-friendly instrumentation, and docs-as-code so analytics definitions don’t drift. When teams instrument once and trust forever, they reduce thrash, avoid rework, and build a durable decision-making muscle across product, engineering, and customer success.

The payoff shows up where it matters: onboarding becomes clearer, user activation improves, and experiments become more conclusive. With in-app guides and thoughtful product tours reinforced by reliable event data, I can see where users hesitate, why they drop, and which nudges actually help them succeed. That makes it easier to prioritize the highest-leverage changes and to communicate impact credibly to stakeholders.

I’ve repeatedly seen teams cut weeks of analysis down to days once they standardize event taxonomies, automate QA for instrumentation, and establish lightweight governance. The result is a smoother path to retention analysis, faster iteration on activation milestones, and a culture that treats data as a first-class product—not an afterthought.

Ultimately, making it effortless to get (great) data flowing in Amplitude is about dignity for the end user and leverage for the business. It’s how we turn curiosity into clarity, align teams around measurable outcomes, and scale product-led growth with confidence.

Inspired by this post on Amplitude – Best Practices.

April 30, 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
Break the Headcount Ceiling: How AI Agents Create Net-New Pipeline at Scale

I’ve been through enough planning cycles to know the impossible math sales leaders juggle. Every year, we’re asked to deliver more pipeline, and the expectation is that the team will somehow hit the target—whether headcount follows or not. In a good year you close some of the gap, but the underlying constraint remains: your pipeline ceiling is tied to your headcount. The ask gets bigger, but the resources rarely keep pace. There’s never been a convincing answer to “how do I grow pipeline by 30% without 30% more people?”

For the first time in my 20-year sales career, there’s a real answer, and it comes from how we’re using our Customer Agent—internally nicknamed “Fin”—for inbound sales. What changed my perspective wasn’t faster execution on the same tasks; it was recognizing that an Agent can generate its own pipeline, consistently and at scale.

Most conversations about AI in sales focus on efficiency—do the same work, just faster. That’s helpful but incomplete. In practice, the Agent is producing net-new, attributable pipeline. It’s not simply an efficiency layer inside the SDR team; it’s a distinct source that deserves its own targets, its own owner, and clear visibility in our pipeline analytics.

Here’s how we run it. Fin has dedicated performance metrics but is held to the same outcomes as any rep: meetings booked, pipeline created, and revenue generated. On live chat, we track qualified, disqualified, and dropped conversations, then follow those cohorts through to opportunity and close. When you fold the Agent’s numbers into the team’s aggregate, you lose the crucial signal of what the Agent is actually doing. Reframing this with explicit attribution changes the boardroom conversation from “efficiency gains” to “a new, incremental source of pipeline.” Last month was our highest pipeline month from Fin to date—stronger than when live chat was handled by humans alone.

The template for this transformation came from customer service. Before we operationalized AI for sales, I partnered closely with our support organization. They built the organizational architecture we’re applying today: clear ownership of the AI motion, Agents and humans running in parallel, and a continuous optimization loop that treats the Agent as a living system, not a set-and-forget tool. The workflows in support and sales are more similar than people expect—qualify the need, guide to the right solution, and move decisively toward an outcome.

“The right benchmark is matching a high-performing rep on that channel, consistently and at scale”

When the Agent reliably meets that benchmark, the gains compound. The team wins back time for work where relationships truly matter—multi-threading across stakeholders, tailoring value narratives, and navigating complex buying processes. That is where human judgment shines.

The most common question I hear is what this means for SDRs. If the Agent owns the frontline, what are SDRs actually doing? The answer is: higher-leverage work. The Agent handles frontline inbound—engaging instantly, qualifying, routing high-intent prospects to the right team, and keeping lower-intent visitors warm by directing them to self-serve resources or remembering their context until they’re ready for a real conversation. It does this 24/7, across languages, without the capacity constraints that come with a human-only model.

What changes is where SDRs’ time goes. For us, that’s phone-based qualification, where we still see the strongest conversion. It’s also deeper relationship-building across multiple stakeholders in an account—the kind of multi-threaded engagement that takes time and judgment. Trials are a great example: rather than treating a trial as a conversion mechanism, SDRs can help prospects get real value from it through guided setup and outcome-oriented check-ins.

Introduce Fin for Sales to your team with this clean hero banner: bold headline, signature blue spiral, and a clear 'Start free trial' call to action—inviting readers to explore an AI customer agent built for revenue.

“That’s work they rarely have capacity for right now, because too much of their time goes to the frontline. Fin changes that”

I want to be direct about one thing: replacing your SDR function entirely with AI is a mistake. SDRs are the talent pipeline for closing teams. The reps who become your best AEs are, more often than not, people who came up through an SDR role. That’s where they learn to qualify and build relationships at speed. Eliminating that function to reduce cost creates fragility further up the funnel that can take years to surface.

Across the market, many sales organizations are still early in this journey. Startups and smaller teams are ahead—they’re building AI-first motions from the ground up and deliberately designing to avoid scaling headcount in the traditional way. Larger, more established sales development functions are mostly still running standard workflows. That makes sense—transforming a mature org is harder than building anew—but complexity isn’t a reason to wait. Momentum is building, and the gap is widening between teams leaning in and those holding back.

What’s emerging now is dedicated AI ownership within sales. It requires someone with program-level responsibility for how the Agent actually performs, rather than bolting AI tools onto an existing job description. We created that role – it’s called “AI SDR program lead.” This role owns the strategy, implementation, and optimization of Fin within the inbound SDR motion, ensuring it drives pipeline growth and integrates well across our systems and workflows. It’s a new career opportunity that came directly from the AI motion, with one of our existing managers moving into it.

The long-held assumption that pipeline growth requires proportional headcount growth is no longer a fixed law. AI-generated pipeline is real, measurable, and improvable with the same rigor we apply to any other part of the function. Treating it as its own source—with explicit targets, attribution, and dedicated ownership—is the difference between marginal efficiency gains and truly breaking the link between pipeline growth and headcount.

The constraint hasn’t disappeared; it has moved. It’s no longer just about how many people you can hire. It’s about how well the Agent understands your product, your customers, and your qualification logic—and how quickly your team can iterate the workflows, knowledge, and guardrails around it. For the first time, the pipeline ceiling can be higher than your headcount allows.

If you’re standing up this motion now, start with three moves: give the Agent its own KPIs and attribution, put a single owner in charge of performance and iteration, and reorient SDR time toward high-conversion conversations and multi-threaded account development. That’s how you scale pipeline with AI Strategy and sales-led growth—without scaling headcount in lockstep.

Inspired by this post on The Intercom Blog.

April 28, 2026
Inside AI Product Management at Amplitude: How Leaders Turn Data into Better Products

When I think about the impact of AI on product management, one line sums it up for me: "Spencer Whittaker is a senior AI product manager at Amplitude. He focuses on using AI to advance Amplitude's mission of helping companies build better products." That focus on outcomes reflects how I frame AI Strategy—grounding every model and workflow in customer value and product-led growth.

In practice, that means pairing Amplitude analytics and behavioral analytics with A/B testing and continuous discovery. I lean on eval-driven development to keep models honest, and I coach LLMs for product managers techniques so teams can prototype safely while we protect signal. Using a unified analytics platform clarifies what to build next and how to iterate faster.

On teams I lead, product discovery stays tightly coupled to AI workflows: we map hypotheses to metrics, design experiments, and close the loop with instrumentation before we ship. That discipline turns AI from a demo into durable value, accelerating activation, retention, and feature adoption without sacrificing quality. A pragmatic AI product toolbox keeps us focused on measurable outcomes, not just novel capabilities.

If you’re building with AI today, take a page from leaders pushing the craft forward: start with clear outcomes, connect your data in a unified analytics platform, and let A/B testing and continuous discovery guide your roadmap. With the right foundations—Amplitude analytics, behavioral analytics, and a sharp AI Strategy—you’ll transform insight into impact and build better products, faster.

Inspired by this post on Amplitude – Perspectives.

April 28, 2026
Scale Support with Heart: How AI Makes Every Customer Interaction Faster and More Human

Every day at HighLevel, I talk with support leaders who are balancing two imperatives that can feel at odds: scaling service efficiently while deepening empathy in every interaction. My product lens is simple—use AI to clear the path for humans to do what only humans can do: listen, understand, and solve nuanced problems with care.

Discover how AI helps support teams deliver faster, more empathetic experiences. Automate the repetitive, so agents can focus on what matters: the customer.

That principle anchors our customer support AI strategy. We deploy AI workflows that handle the heavy lift—classification, intent detection, summarization, knowledge retrieval, and next-best-action—so agentic AI can triage, resolve routine issues, and hand off the right context when a human touch is needed. The result is a queue that moves faster, with more signal and less noise, and a team freed to bring empathy and judgment to the moments that matter most.

On the front line, a voice AI agent or chat interface deflects repetitive requests, while conversation design ensures the experience feels respectful, transparent, and helpful. Inside the console, Agent Analytics surface what leaders care about: which topics spike, where customers get stuck, how sentiment and CSAT shift, and which playbooks actually shorten time to resolution. When an agent steps in, AI-assisted replies, real-time summarization, and suggested macros reduce cognitive load—so attention goes to the customer, not the keyboard.

Shipping these capabilities responsibly requires rigor. My playbook pairs LLMs for product managers with a retrieval-first pipeline that grounds responses in audited knowledge, backed by privacy-by-design and data governance. We use eval-driven development to measure safety and quality, and A/B testing to quantify impact before broad rollout. This isn’t just about automation; it’s about trust, reliability, and continuous discovery with real customers.

Context is king, so CRM integration is non-negotiable. By unifying tickets, purchase history, prior conversations, and lifecycle stage, agents walk in with empathy already loaded. Whether the channel is Intercom, HubSpot, or native chat, a unified analytics platform connects signals across journeys, enabling proactive outreach, smarter product tours, and in-app guides that prevent avoidable tickets in the first place.

The outcome is a support organization that scales without sacrificing humanity. AI handles the repetitive; people handle the relational. Teams spend less time searching and more time solving. Leaders coach with data instead of guesswork. And customers feel heard—because they are. That’s how we make human support more human, at scale.

Inspired by this post on Amplitude – Perspectives.

April 28, 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
Master Build-to-Learn: The Essential FAQ to Supercharge Product Discovery in the AI Era

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

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

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

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

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

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

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

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

Inspired by this post on SVPG.

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
Unleashing Inbound Sales with AI: My Playbook for Launching and Scaling Sales Agents Fast

Inbound leads shouldn’t wait for a rep’s calendar. When we first launched The Service Agent Blueprint, support leaders finally had a clear AI path. Go-to-market and revenue teams are now facing similar uncertainty, so I’m introducing The Sales Agent Blueprint—a practical map for launching and scaling AI for sales with confidence.

For most sales teams, inbound motions require a lot of manual work. I’ve watched leads pile up in queues, waiting for availability rather than being prioritized by buyer intent. That delay costs meetings, pipeline, and momentum—and it’s exactly where a modern AI Strategy can transform your go-to-market strategy.

Agents can run sales conversations end to end – engaging buyers, qualifying leads, and routing high-intent opportunities to the right team to move prospective buyers forward quickly. Humans will still be involved, but will move their focus to the consultative conversations and higher-value work they did not have time to focus on before. In practice, this shift enables cleaner AI workflows, better conversation design, and a healthier balance between sales-led growth and product-led growth.

The questions many go-to-market and revenue leaders are facing now are where do you start? What should success look like? How do you actually test and deploy these solutions? These are the right questions—and the ones I hear most often when teams weigh build vs buy decisions, evaluation frameworks, and CRM integration nuances.

The Sales Agent Blueprint answers those questions. It’s designed to be a strategic guide for sales, revenue, and AI transformation leaders who want to deploy AI for inbound sales fast, prove value, and build momentum. If you’re aiming for eval-driven development, this will help you define success up front and operationalize it.

What’s inside is simple by design yet deep enough to take you from zero to value. The Sales Agent Blueprint is structured around two tracks that reflect how high-performing teams adopt agentic AI: first, launch for quick wins; next, scale for durable growth.

Coming soon: Sales Agent Blueprint. A sleek, blueprint-inspired teaser with the call to 'Scale it' signals tools, playbooks, and workflows to grow revenue, streamline operations, and scale teams with confidence.

Today, I’m releasing the first part of the Blueprint: “Launch it.” It’s a practical guide for getting your Agent live and seeing real results. You’ll learn how to deploy a Sales Agent that runs inbound sales conversations end to end, engaging buyers, qualifying leads, and routing high-intent opportunities to the right outcome in real time—without disrupting your current CRM integration or pipeline processes.

By the end of the “Launch it” track, you’ll be ready to execute with clarity. Here’s how I frame the essential steps, based on what consistently works in the field.

Understand what a Sales Agent is: Discover why they’re different from chatbots and how they work. Build a business case: Prove the basic economics of AI, decide whether to buy or build, and get the buy-in and budget you need to move forward.

Evaluate an Agent: Learn how to define success, choose the right evaluation criteria, and run a focused, high-impact assessment with our five-step framework.

Deploy with confidence: Build a deployment plan that gets your Agent live quickly to engage buyers at peak intent. Learn what to expect at each stage.

Introducing the Sales Agent Blueprint. This crisp, grid-based graphic spotlights step 1—Launch it—signaling day-one activation for an AI sales agent. Explore the framework and get started at fin.ai/blueprint/sales.

Continuously improve performance: After launch, your Agent becomes a system to manage. We’ll show you how to implement a repeatable process to train, test, deploy, and optimize.

The second track, “Scale it” (coming soon), focuses on the organizational and systems design work that unlocks compounding gains. Launching AI is only the beginning. To unlock its full potential, you need to rewire your inbound sales motion—redesigning the buyer journey, building AI-first systems and ownership models, and rethinking how pipeline is generated and scaled. This is where governance, measurement, and team roles evolve to support sustainable growth.

I’ll be building this Blueprint in public as I navigate the same challenges—sharing what works, what to avoid, and how to accelerate time-to-value without sacrificing quality or trust. If you’re ready to turn intent into revenue with agentic AI, this is your head start.

The Sales Agent Blueprint is live now. Explore the full guide at fin.ai/blueprint/sales and start your “Launch it” sprint today.

Inspired by this post on The Intercom Blog.

April 23, 2026