Tag: product roadmapping and sprint planning

Stop Selling Your Roadmap: Win Stakeholder Trust by Showing Your Work, Not Conclusions

I’m seeing the same pattern in product orgs everywhere—inside HighLevel and across my network: everyone is racing to add AI to the roadmap, and every stakeholder has a strong opinion about what to build next. Delivery has never been faster, which makes it dangerously easy to confuse speed with progress.

When we chase features without grounding in continuous discovery, we drift back into a feature factory. We ship more, but we ship the wrong things faster. The antidote is simple and hard at the same time: recommit to product discovery, validate with assumption testing, and let the evidence steer our AI Strategy—not the hype.

Of course, that only works if we can bring our stakeholders along. In the AI moment, it’s deceptively easy to get to a slick prototype and painfully hard to harden it for production. Early demos make almost any idea look promising. That’s precisely why stakeholder management must evolve from pitching solutions to showing our work.

In practice, stakeholder management is about alignment with the people who influence our product decisions—executives, sales, marketing, customer success, engineering leadership, and sometimes legal or finance. Some have veto power; others have input. Knowing who can block versus who can shape is crucial for where we spend our time. Even in empowered product trios, the best discovery can derail if we reveal only conclusions at the end.

I’ve tried every mapping framework—power-interest grids, RACI matrices—and they help. But the real challenge isn’t identifying stakeholders. It’s figuring out how to bring them along so that our product roadmapping and sprint planning decisions stick.

Identify who shapes your product decisions. This visual groups stakeholders into three tiers—those with veto power, key influencers, and audiences to inform—so teams can align, communicate, and reduce delivery risk.

Here’s the most common trap I see (and have fallen into): focusing stakeholder reviews on the roadmap, release plan, or prioritized backlog. That invites an opinion battle. And stakeholders have their own conclusions—usually shaped by the last customer call, a board meeting, or a market headline.

This is how the HiPPO dynamic gets created. HiPPO stands for the “Highest Paid Person’s Opinion,” and the saying goes, “The HiPPO always wins.” When we present conclusions without the journey, we set ourselves up to lose. In the gen ai rush, the chorus of “everyone is doing AI” makes that opinion even harder to counter.

So I don’t try to win opinion battles. I bring new information—fresh customer interviews, clear opportunity mapping, and results from assumption tests. The gap between what the market hypes and what customers actually need is often enormous. Our edge is evidence.

The strategy that consistently works for me is simple: show your work. If you’re practicing continuous discovery, your opportunity solution tree isn’t just a thinking tool—it’s your strongest stakeholder management asset. It helps you build confidence in your decisions, and it can help your stakeholders build the same confidence.

Avoid the stakeholder trap of selling conclusions. This visual shows how anchoring on solutions invites HiPPO battles—and how to shift the conversation by sharing discovery evidence, insights, and data.

Step 1 — Start with the outcome. I open every conversation by restating the shared goal and asking whether anything has changed. Anchoring on outcomes vs output OKRs reframes hot-button solution debates (like “we need an AI feature”) back to what will move the needle on the outcome we agreed to pursue.

Step 2 — Share the opportunity space. I show how we mapped customer needs, pain points, and desires. Then I ask, “What did we miss?” Stakeholders often surface opportunities we haven’t seen yet—signals from the field, market shifts, or partner feedback. I capture their input and commit to validating it in upcoming customer interviews.

Step 3 — Walk through prioritization. Using the tree’s structure, I explain why we prioritized one branch over another. Then I ask where they might have chosen differently. This turns debate into collaboration and lets me leverage their expertise without ceding the discovery framework.

Step 4 — Go deep on the target opportunity. Before we talk solutions, I make the customer’s problem vivid and real. Interview snapshots help stakeholders empathize and see what matters most. Once the opportunity is crisp, solution discussions become dramatically more objective.

Show your work, not just your conclusions. This infographic guides product teams through seven steps to build stakeholder confidence—align on outcomes, map opportunities, prioritize, test assumptions, and repeat.

Step 5 — Share solutions and invite theirs. I present our solution set and explicitly ask for additional ideas. If their suggestions diversify our set, we include them. Solution ideas are cheap; the opportunity is what matters. This is where product trios can benefit from leadership’s pattern recognition and industry context.

Step 6 — Share your assumption tests and results. I walk through our story maps, high-risk assumptions, and what we’ve learned so far. I invite stakeholders to add assumptions—this is where their knowledge shines. If we have data, we share it; if we’re pre-data, we share the plan to get it and ask for feedback.

Step 7 — Repeat. I don’t batch this into a big reveal. I keep a steady cadence and tailor depth to each audience: weekly for my manager, monthly highlights for marketing, and concise updates for executives. Continuous discovery pairs with continuous stakeholder management.

Showing your work doesn’t mean drowning people in detail. It means tailoring the signal to the audience. My rule of thumb is outcome, opportunity, solution, evidence—walk the lines of the tree at the right altitude for each stakeholder.

Show your work the right way for each stakeholder. Use a smart filter to turn discovery noise into clear signals—weekly journeys for your manager, focused monthly highlights for marketing, and a 30-second CEO pitch.

In a 30-second update with a CEO, it might sound like this:

“Our goal is to reduce time-to-first-value for new users. We’ve been interviewing customers and learned that onboarding is where most people get stuck—specifically, they don’t know which features to try first. We explored a few approaches and tested them. The most promising one is a guided setup flow that adapts based on the user’s role. In early tests, new users completed onboarding 40% faster.”

That pattern works across channels—Slack updates, monthly reviews, or quarterly planning. The format flexes, the structure doesn’t: outcome, opportunity, solution, evidence.

As you adopt this approach, watch for four anti-patterns that quietly erode trust.

Avoid the traps that erode stakeholder trust. This infographic guides product teams to show their work, welcome ideas, provide frequent updates, and prioritize results over ideology to build alignment and credibility.

Anti-pattern 1 — Telling instead of showing. The curse of knowledge makes our conclusions feel obvious to us and opaque to others. The fix: slow down, start at the top of the tree, walk the decisions, and let stakeholders reach the conclusion with you.

Anti-pattern 2 — Shooting down stakeholder ideas. As you build a library of validated assumptions, it’s easy to spot flaws in a suggestion and say “no” too quickly. Instead, place their idea within your discovery framework. If it maps to a different opportunity, say, “That idea has promise—we’ll consider it when we address that opportunity.” If it rests on risky assumptions, story map the idea together, list the assumptions, and share what you’ve already learned. People accept the evidence they help generate.

Anti-pattern 3 — Saving everything for a big reveal. Infrequent, comprehensive updates invite opinion battles because stakeholders have formed their own conclusions in the dark. Short, frequent updates build alignment as the work unfolds.

Anti-pattern 4 — Fighting the ideological war. Sometimes a more senior stakeholder will overrule you. Don’t turn it into a debate about how product decisions “should” be made. Focus on the decision at hand, do the best work within constraints, and let results—not ideology—prove the value of discovery over time.

Shift from selling to showing. This co-creation guide invites stakeholders into discovery, taps their expertise, and turns relationships from obstacles into partnerships for smarter product decisions.

Here’s the mindset shift that changes everything: stakeholder management is a co-creation opportunity. When we show our work with artifacts like an opportunity solution tree, experience maps, and interview snapshots, we’re not just communicating—we’re inviting collaboration. We’re leveraging stakeholders’ expertise, context, and connections to make better product decisions.

When stakeholders have walked the path with us, they don’t need to be sold on the destination. They become allies. Engagement stops being a status ritual and starts being real partnership—the kind that moves outcomes and builds durable trust.

Try this in your next review: don’t start with your roadmap. Start at the top of the tree. Reaffirm the outcome. Share the opportunity space. Explain your prioritization. Show what you’re learning. Invite contribution. You might be surprised how quickly alignment—and confidence—follow when you stop selling conclusions and start showing your work.

Inspired by this post on Product Talk.

March 4, 2026
Stop Blurring the Lines: Clear Product–Engineering Boundaries to Boost Quality and Prevent Burnout

Where is the true boundary between product and engineering—and what happens when it gets blurry? I’ve led and coached teams through this question many times, and I’ve learned that clarity here isn’t just a nice-to-have; it’s foundational to quality, velocity, and team health.

I’ve seen well-intentioned product managers step in to “help” by taking ownership of bug triage, tech debt prioritization, or even system architecture. At first, it feels productive. Over time, it creates role confusion, slows decision-making, and burns out PMs—while paradoxically lowering engineering quality. The “CEO of the product” myth and legacy IT, project-based mindsets are usually at the root. Treating engineers as “order takers” breaks down in evergreen product environments.

The healthiest collaboration model is simple and disciplined: The product trio owns the “what”; engineering owns the “how”. Product managers are not people managers for engineers—and shouldn’t be accountable for engineering quality. Our job is to frame the problem, align on outcomes, and continuously discover value with customers—not to supervise technical execution.

If quality is a problem, the solution is escalating and fixing the system, not managing individual bugs. In practice, that means surfacing patterns and elevating them to engineering leadership, who can address root causes—staffing, skills, code health, CI/CD gaps, observability, or process design—rather than asking PMs to paper over issues with status updates. This keeps accountability where it belongs and reinforces outcomes vs output OKRs.

One high-leverage move is to remove unnecessary intermediaries. Removing the PM as a middleman creates better flow and clearer ownership. Create direct paths for stakeholders to get bug status without routing everything through product. Use dashboards, shared tools, or Slack channels instead of one-off updates. In my teams, shared Jira views, Slack incident channels, and status pages eliminated handoffs, improved stakeholder management, and gave engineers the space to solve problems end-to-end.

Strong engineering leadership is non-negotiable. What strong engineering leadership should own (and why that matters) is the technical system, quality guardrails, sustainable pace, and the practices that uphold them—incident management, code review rigor, test coverage, and SLOs with SRE. Skilled engineering teams naturally push back when boundaries are crossed—and that’s a good thing. It signals ownership, craft pride, and a pathway to durable execution.

When do I step in as product? Primarily to clarify desired outcomes, sequencing, and trade-offs—bringing customer and business context to the table. I structure product roadmapping and sprint planning around value slices and risks, not task lists. I align on decision rights early: architecture and tech debt strategies live with engineering; product strategy, positioning, and success metrics live with product; discovery and prioritization live with the product trio.

Here are the system-level moves I’ve found most effective: Escalate systemic quality issues to engineering leadership, not individual contributors. Advocate for real engineering leadership if your org expects product teams—not IT teams. Then reinforce a culture of continuous discovery so product, design, and engineering make better upstream decisions together. This is how empowered product teams ship higher-quality outcomes—without burning anyone out.

If you’ve ever found yourself acting as the middleman for bug status or being asked to “own” engineering decisions outside your expertise, you’re not alone. Reset the boundaries, make work visible, and double down on shared outcomes. In my experience, the moment we clarify roles and remove status theater, quality rises, cycle time improves, and everyone does the job they were hired to do—better.

Inspired by this post on Product Talk.

February 24, 2026
LLMs vs AI Agents: Hard‑Won Lessons Product Teams Need to Nail for Real‑World Impact

When people ask me about "LLM vs AI Agents: What Product Teams Must Get Right," I start with a simple truth: an LLM is a powerful prediction engine, while an AI agent is a productized workflow that plans, takes actions with tools, remembers, and closes the loop on an outcome. That difference sounds academic until you’re on the hook for reliability, cost, and customer trust.

In my role, I’ve shipped LLM copilots that delight users and piloted agents that automate complex workflows. The pattern that never fails is this: start assistive, then graduate to autonomy. Copilots accelerate people; agents own outcomes. When we respect that gradient, adoption climbs, incidents fall, and we earn the right to expand scope.

The first decision point is use-case fit. If the task benefits from human judgment, high-context nuance, or brand voice, I frame it as a copilot with strong guardrails and crisp UX. If the task is well-bounded, tool-heavy, and verify‑able, I consider an agent—but only after we can measure end‑to‑end task success with eval-driven development.

Architecture matters. I reach for a retrieval-first pipeline to keep responses grounded in authoritative data, then add tool use for actions (search, write, schedule, transact) with deterministic scaffolding to prevent thrashing. Good prompt engineering is table stakes, but context window management and a clean memory strategy (short‑term scratchpad, long‑term facts, and policy) separate demos from durable systems.

Agents amplify both value and risk. I build safety in layers: role and scope definition, tool whitelists, unit limits, human‑in‑the‑loop checkpoints at irreversible steps, and privacy-by-design data governance. We log every decision token-for-token because auditability isn’t optional once agents touch customers, money, or data.

Measurement is non‑negotiable. For LLM features, I track time‑to‑first‑token, response latency, groundedness, and user satisfaction. For agents, I add Agent Analytics: task success rate, number of steps per task, tool error rate, loop detection, guardrail triggers, escalation to human, cost per successful task, and containment rate. If we can’t see it, we can’t ship it.

My delivery playbook mirrors modern software ops. We use feature flags, gated betas, and canary rollouts; we version prompts like code; we set incident management paths for model outages and tool drift; and we rehearse fallbacks so the experience degrades gracefully, not catastrophically. Dull operations build dazzling products.

On roadmapping, I thin‑slice value. We introduce a minimal viable copilot that handles a single, frequent job-to-be-done with high success. Only after continuous discovery confirms product‑market fit do we grant more autonomy, one capability at a time. Outcomes vs output OKRs keep us honest: if the customer’s job gets done faster, cheaper, and with fewer errors, we scale; if not, we fix fundamentals before adding scope.

Build vs buy is rarely binary. I tend to buy the undifferentiated heavy lifting—observability, prompt versioning, red‑teaming, and policy enforcement—while building the proprietary workflows, data modeling, and UX that encode our defensible advantage. The litmus test: if it’s part of our unique value proposition, we own it; if not, we integrate the best‑in‑class and move.

Go‑to‑market must be as rigorous as the tech. We position clearly (assistant vs agent), price to value with transparent consumption SaaS pricing, and communicate risk posture in plain language. Customers don’t buy models; they buy confidence that a job gets done reliably within their constraints.

Common failure modes repeat: shipping autonomy before instrumentation, treating prompts as magic instead of software, skipping data governance, and ignoring the human experience. The antidote is disciplined AI Strategy rooted in empowered product teams, tight feedback loops, and relentless evaluation.

If you take nothing else: choose the right paradigm for the job (copilot first, agent when proven), ground with a retrieval-first pipeline, instrument with eval-driven development and Agent Analytics, and operationalize like a mission‑critical system. Do that, and you’ll turn LLM capabilities into durable product outcomes.

Inspired by this post on Product School.

February 18, 2026
Reinventing Product Management Workflow: The AI Upgrade I Use to Ship Faster, Smarter

The most valuable upgrade I’ve made to my product management workflow isn’t a new framework or a shiny dashboard—it’s an AI-first operating model that compresses discovery-to-delivery cycles while increasing confidence in every decision. I built this approach to reduce context switching, remove toil, and keep the team relentlessly focused on outcomes over output. The result is a faster, clearer, and more reliable path from insight to shipped value.

Here’s how I run an AI-powered product workflow end to end: continuous discovery, opportunity sizing, solution shaping, planning, execution, and iteration—each step instrumented with automation, retrieval, and evaluation so we learn faster without compromising rigor.

Intake and triage start with a retrieval-first pipeline that unifies customer feedback, support tickets, sales notes, research transcripts, and usage analytics. I use embeddings to cluster themes, de-duplicate signals, and surface the most representative examples. This gives me an instant, always-fresh view of customer jobs, pains, and opportunities without manually combing through noise.

For discovery, I rely on “LLMs for product managers” to accelerate the hard parts without replacing judgment. I generate interview guides, summarize transcripts, extract entities, and tag moments of friction. Prompt engineering and context window management ensure the model sees the right evidence at the right time. I keep all sensitive data governed by privacy-by-design and data governance controls.

Opportunity sizing is where I connect insights to business impact. I map problems to a driver tree, quantify potential lift, and align to outcomes vs output OKRs. When relevant, I apply the Kano Model to balance performance, basic, and excitement attributes. To maintain rigor, I use eval-driven development on my prompts and heuristics so prioritization is repeatable, not anecdotal.

Solution shaping is a collaborative exercise with product trios. I draft problem narratives and PRDs, generate acceptance criteria, and create first-pass UX flows. For speed, I use gen ai for product prototyping to explore alternatives quickly, then gate final choices through usability feedback and feasibility checks. Where uncertainty is high, I define a minimum detectable effect (MDE) and design A/B testing plans upfront.

Planning ties strategy to execution through product roadmapping and sprint planning. I break work into sequenced bets, enable feature flags for controlled exposure, and wire quality signals into CI/CD. DORA metrics—like deployment frequency and change failure rate—help me keep the system honest. Observability ensures we see the “why” behind behavior, not just the “what.”

Execution is instrumented with in-app guides, Intercom messaging, and Pendo to shape onboarding and activation. I connect Amplitude analytics to measure habit formation, retention analysis, and feature adoption. When experiments run, I monitor leading indicators in near real time while protecting against peeking and p-hacking. The point isn’t to prove we’re right; it’s to learn fast enough to get right.

Iteration closes the loop. I use a unified analytics platform to compare expected vs actual outcomes, harvest qualitative feedback, and push new evidence back into discovery. The system improves with each cycle because the retrieval-first pipeline and eval harness both get smarter as data grows.

Governance is non-negotiable. AI risk management, cybersecurity, and regulatory compliance sit alongside model evaluations to prevent drift, leakage, or bias. I document decisions, model versions, and test artifacts so we can audit how we got to a call—especially when trade-offs are nuanced.

If you’re standing up this AI workflow from scratch, I recommend a 30/60/90 rollout. In the first 30 days, audit your data sources and build a retrieval-first pipeline. In days 31–60, pilot two high-leverage workflows—continuous discovery and PRD drafting—backed by eval-driven development. By days 61–90, scale to prioritization and experiment design, then thread the outputs into your planning and CI/CD rhythms.

Common pitfalls I watch for: over-automation that blurs context, lack of evaluation frameworks, ungoverned data that undermines trust, and vanity metrics that celebrate activity over outcomes. The antidote is simple but disciplined—clear decision criteria, measurable hypotheses, and automated evaluations that run as guardrails, not bottlenecks.

This AI upgrade doesn’t replace the craft of product management; it amplifies it. By combining judgment, clear strategy, and reliable automation, we ship value faster, reduce risk, and make better calls under uncertainty. The payoff is durable: compounding learning velocity and a team that spends more time solving the right problems—and less time wrestling the process.

Inspired by this post on Product School.

February 11, 2026
From Idea to Impact: My PM-Friendly Blueprint to Building Your First AI Agent Fast

AI agents are quickly moving from novelty to necessity, and the fastest way to capture value is to approach them like any other high-stakes product initiative. In this guide, I share how I plan, build, and launch production-grade agents with a product mindset—balancing ambition with risk, speed with governance, and innovation with measurable outcomes.

I start by getting crisp on the outcome. Who is the primary user, what job are they hiring the agent to do, and how will we know it’s working? I translate this into outcomes vs output OKRs, such as resolution rate, time-to-value, cost-to-serve, or qualified pipeline influenced—anchoring the roadmap before a single line of code or prompt is written.

Next, I map the agent’s scope and boundaries. I write a simple capability canvas: the tasks the agent must perform, the tools it can use, the data it can access, and the constraints it must respect. Most successful builds follow a retrieval-first pipeline: connect trusted knowledge sources, enrich with metadata, and manage a lean context window to keep responses relevant and cost-efficient. From the start, I bake in privacy-by-design, data governance, and AI risk management so compliance isn’t an afterthought.

Model selection comes after the workflow is clear. I choose an LLM for the job (latency, cost, multilingual needs, and tool-use fidelity) and pair it with the right connectors and actions—think CRM integration, ticketing, search, or internal APIs. For voice experiences, I define a voice AI agent persona, turn-taking rules, and barge-in behavior. This is where agentic AI patterns shine: structured planning, tool invocation, and verification loops create a resilient, goal-directed system.

Prompt design is product design. I write system prompts that define role, tone, constraints, data sources, and success criteria. I add few-shot examples that mirror my top use cases and edge cases, then apply prompt engineering best practices to control style, limit speculation, and encourage citations. For voice, I include prompt engineering for voice to optimize brevity, warmth, and disfluency handling without sacrificing accuracy.

Before launch, I build an eval-driven development workflow. I curate golden datasets from real user intents, add adversarial cases, and automate evals for accuracy, safety, grounding, and tool-use success. I set a minimum detectable effect (MDE) so A/B testing can validate improvements with confidence, and I define go/no-go thresholds to prevent regression. This becomes my continuous discovery loop for the agent.

Instrumentation is non-negotiable. I wire up Agent Analytics to track task success, containment/deflection rate, handoff quality, cost per task, and user satisfaction. I supplement with a unified analytics platform and session replays to observe failure patterns. These signals feed prioritization and help me decide when to expand scope versus harden reliability.

For delivery, I rely on CI/CD with feature flags to gate risky capabilities, plus canary releases for new tools and prompts. I monitor DORA metrics to maintain deployment frequency without trading off quality. When incidents happen, I treat them like production issues: incident management playbooks, rollbacks, and clear postmortems.

Trust is earned through safety and transparency. I enforce least-privilege access, structured logging, and red-teaming for jailbreaks, prompt injection, and data exfiltration. Threat detection and response plus clear user disclosures keep the experience responsible and compliant with regulatory requirements.

GTM is product-led. I use in-app guides, product tours, and onboarding checklists to drive user activation and early wins. I define success moments, turn them into habit loops, and run retention analysis to find where users stall. This tight loop of messaging, measurement, and iteration accelerates product-market fit.

Common high-ROI use cases I prioritize include customer support ai strategy (automated resolution and augmented agent assist), sales and success workflows (lead qualification, QBR prep), and internal knowledge copilots (policy, process, engineering runbooks). Each starts narrow, ships fast, and scales with proven evidence from analytics and experiments.

If you’re skimming, here’s the blueprint: clarify outcomes, design AI workflows with a retrieval-first pipeline, select the right LLM and tools, engineer robust prompts, institutionalize evals and A/B testing, instrument Agent Analytics, ship with CI/CD and feature flags, and iterate with discipline. In the walkthrough video above, I go deeper on templates, prompts, and experiments you can use to build your first agent with confidence.

Inspired by this post on Product School.

February 5, 2026
Stop Measuring Output, Start Driving Outcomes: My February CDH Book Club Guide

“Continuous Discovery Habits” turns five this year, and I’m celebrating by reading the book together with you. Each month, I’m releasing an in-depth reading guide designed for empowered product teams and product trios—complete with the chapters we’ll read, a preview of the key concepts, short shareable videos, individual and team discussion prompts, team exercises you can run immediately, and additional reading to go deeper.

We’ll discuss each month’s reading in the comments, and we’ll gather quarterly for live calls. If you’re joining late, no problem—I’ll be monitoring comments throughout the year. Start with the current month or go back to January (https://www.producttalk.org/lets-read-continuous-discovery-habits-together-january-2026/). Jump in where it serves you best, ask for help, share what’s working, and connect with other readers any time.

If you want to participate, grab a copy of the book (https://amzn.to/3hGkNYT?ref=producttalk.org)—or dust off your old one—share the “Spread the Love” videos with your colleagues, set aside time to run the team exercises, and register for the community sessions. Let’s do this.

This Month’s Reading

Chapters: Chapter 3: Focusing on Outcomes Over Outputs

Estimated reading time: ~22 minutes

This chapter zeroes in on the critical difference between business outcomes and product outcomes—and why it matters which one your team is assigned; how to translate lagging business metrics into actionable product outcomes you can actually influence; why setting outcomes should be a two-way negotiation between leaders and product trios; when to start with a learning goal versus a performance goal; and five common anti-patterns that derail outcome-focused teams. Need a copy? Grab the book (https://amzn.to/3hGkNYT?ref=producttalk.org).

Share the Love with Friends and Colleagues

We learn best in community. I like to seed conversations across my org with short, high-signal content—especially when I’m shifting a culture from outputs to outcomes and sharpening OKRs. Use these short videos to bring peers into the conversation and invite them to read along:

“What’s an outcome?” (https://videos.producttalk.org/videos/ea9fdab71d1ee3c263/whats-an-outcome?ref=producttalk.org) — The real value of starting with an outcome. “Business outcomes vs. product outcomes” (https://videos.producttalk.org/videos/069fd5b5101ee2c78f/business-outcomes-vs-product-outcomes?ref=producttalk.org) — Why product teams need product outcomes, not business outcomes. “What’s the difference between OKRs and outcomes?” (https://videos.producttalk.org/videos/069fdab61919e4c38f/whats-the-difference-between-okrs-and-outcomes?ref=producttalk.org) — Any outcome can be represented as an OKR. “Understanding revenue model formulas” (https://videos.producttalk.org/videos/799fd5b5101ee2c4f0/understanding-revenue-model-formulas?ref=producttalk.org) — How to identify the business outcomes your company cares about. “Revisit your outcome every quarter” (https://videos.producttalk.org/videos/449fd5b4111ee0cfcd/revisit-your-outcome-every-quarter?ref=producttalk.org) — Don’t abandon your outcome, but do revisit how you measure it.

Reflect and Discuss What You Read

Reflection is the conversion rate optimizer for learning. When we pause to discuss what we’re reading, we retain more and apply it faster—especially in product discovery and product strategy work. This chapter challenges us to update our definition of success: away from features shipped and toward outcomes achieved. This month, I’m examining my own relationship with outcomes—where I’ve been rigorous, where I’ve drifted, and how I can help my teams strengthen day-to-day behaviors.

Individual Reflection

If your team isn’t working toward an outcome, look at the features or projects on your roadmap and ask: What impact are they supposed to have? If they succeed, what customer behavior or business result would change? If your team does have an outcome, consider whether it’s a business outcome, a product outcome, or a traction metric—and how that choice shapes your daily decisions and discovery cadence. Finally, think about the last time your team’s outcome changed: Was it a deliberate strategic shift, or did it feel like ping-ponging from one priority to the next?

Team Discussion

As a team, classify your current outcome: Is it a business outcome, a product outcome, or a traction metric? If it’s a business outcome, identify the leading customer behaviors that would signal momentum; if it’s a traction metric, broaden it to a product outcome that gives you more room to explore. Then, name which of the five anti-patterns (pursuing too many outcomes, ping-ponging, individual outcomes, outputs as outcomes, or tunnel vision) shows up for you and pick one concrete change. Finally, assess how outcomes are set: Are they handed down, or does your product trio co-create them? What would it take to make this a true two-way negotiation?

Put It Into Practice

Understanding the difference between business outcomes and product outcomes is table stakes. Translating one into the other is where product management leadership shows up. These exercises will help you connect company goals to customer behavior, avoid outcomes vs output OKRs traps, and increase your span of control over meaningful change.

Exercise: Map Your Revenue Model

Time: 30 minutes. Do this: Solo first, then share with your team. Start with this question: How does your company make money? Write out the formula for your revenue model. For example, a subscription business might be: Revenue = Number of Customers × Average Monthly Spend × Retention. Once you have the formula, identify each variable as a potential business outcome. Then, for each business outcome, brainstorm two to three product outcomes (customer behaviors or sentiments) that might be leading indicators. Which of these product outcomes is your team best positioned to influence?

Exercise: Audit Your Current Outcome

Time: 45 minutes. Do this: With your product trio. Take your team’s current outcome and run it through a quick diagnostic: Is it a business outcome, product outcome, or traction metric? If it’s a business outcome, what product outcomes might drive it? If it’s a traction metric, how might you broaden it to a product outcome? Is it a leading indicator or a lagging indicator? Can you measure progress weekly, or do you have to wait months? Is it within your team’s span of control? Based on your answers, draft a revised outcome that offers more actionable feedback while still connecting to business value, and prepare to discuss this with your product leader.

Go Deeper: Additional Reading

If you prefer an audio summary of this month’s reading, including the book chapter and the resources below, I’ve included an audio version at the end of this post for paid subscribers.

Related In-Depth Guide: Shifting from Outputs to Outcomes: Why It Matters and How to Get Started (https://www.producttalk.org/shifting-from-outputs-to-outcomes/).

Supplementary Reading: Empower Product Teams with Product Outcomes, Not Business Outcomes (https://www.producttalk.org/2020/05/product-outcomes/). Defining Product Outcomes: The 8 Most Common Mistakes You Should Avoid (https://www.producttalk.org/2022/12/defining-product-outcomes/). Understanding How Product Outcomes Connect to Revenue and Costs (https://www.producttalk.org/2023/04/connecting-product-outcomes-to-revenue-and-costs/). Product in Practice: Iterating to an Actionable Outcome at tails.com (https://www.producttalk.org/2020/08/actionable-outcomes/). Product in Practice: Iterating on Outcomes with Limited Data (https://www.producttalk.org/2023/12/iterating-on-outcomes-with-limited-data/). Measurable Outcomes – All Things Product with Teresa Torres and Petra Wille (https://www.producttalk.org/measurable-outcomes-all-things-product-podcast-with-teresa-torres-petra-wille/).

Other Voices: The Business Equation by Brett Bivens (https://venturedesktop.substack.com/p/the-business-equation?ref=producttalk.org). KPI Trees: How to Bridge the Gap Between Customer Behavior, Product Metrics, and Company Goals by Petra Wille and Shaun Russell (https://www.petra-wille.com/blog/kpi-trees-how-to-bridge-the-gap-between-customer-behavior-product-metrics-and-company-goals?ref=producttalk.org). Persistent Models vs. Point-In-Time Goals by John Cutler (https://cutlefish.substack.com/p/tbm-2553-persistent-models-vs-point?ref=producttalk.org). Is It Time to Ditch the Old SaaS Metrics? by Kyle Poyar (https://openviewpartners.com/blog/saas-metrics-plg/?ref=producttalk.org). How Engagement Metrics Can Be Misleading by Oleg Yakubenkov (https://gopractice.io/blog/how-engagement-metrics-can-be-misleading/?ref=producttalk.org). Subscription Churn Metrics and Benchmarks for Operators by Elena Verna (https://www.elenaverna.com/p/subscription-churn-benchmarks-and?ref=producttalk.org).

Related Courses: Business Fundamentals: Navigate Your Business Context with Confidence (https://learn.producttalk.org/course/business-fundamentals?utm_source=Product+Talk&utm_medium=cdh-book-club-february-2026).

Our Live Discussion Schedule

Our live discussion sessions are for paid subscribers and will not be recorded. Invitations will go out to Supporting Members and CDH Members (http://members.producttalk.org/?ref=producttalk.org) two weeks before each event—reserve time on your calendar now so you can participate fully and bring real examples from your team.

Wednesday, March 18, 2026: 9am–10am PDT and 4pm–5pm PDT. Tuesday, June 16, 2026: 9am–10am PDT and 4pm–5pm PDT. Thursday, September 17, 2026: 9am–10am PDT and 4pm–5pm PDT. Wednesday, December 16, 2026: 9am–10am PST and 4pm–5pm PST.

Audio Summary

Prefer to listen? I’ve included an audio summary—Stop Measuring Code Start Measuring Behavior—at the end of this post so you can review the main ideas on your commute or between meetings.

I’m excited to dive into outcomes with you this month. As a product leader, I’ve seen teams transform their product discovery, product roadmapping and sprint planning, and OKR quality when they anchor on clear product outcomes tied to business value. Let’s build that muscle together and make this a quarter where we stop measuring output and start driving outcomes.

Inspired by this post on Product Talk.

February 2, 2026
The Solutions Engineering Edge: How Chris Landon Bridges Product Strategy and Customer Value

I see the strongest products emerge where customer outcomes, sales insight, and engineering rigor intersect. That’s precisely why I value the craft of solutions engineering—and why I’m excited to share how Chris Landon exemplifies it.

Chris is a seasoned professional with extensive experience in solutions engineering and sales consultancy. He's currently a senior solutions engineer.

From a product management leadership vantage point, this blend bridges discovery and go-to-market strategy, converts ambiguous requirements into crisp product positioning and value proposition, and ensures we’re solving the right problems for the right personas. The result is a tighter feedback loop between field reality and product intent—an essential ingredient for sustainable product-led growth.

In practice, senior solutions engineers partner closely with product trios, informing product roadmapping and sprint planning with field-tested evidence. In my experience, their input sharpens stakeholder management, de-risks complex integrations, and equips sales with narratives that reflect genuine customer outcomes rather than feature lists.

On the analytics side, the most effective partners help define decision-ready metrics across a unified analytics platform, enriching retention analysis with qualitative context from customer conversations and proofs of value. That closed loop turns demos and early deployments into high-signal inputs for learning, prioritization, and go-to-market strategy.

If you’re building a modern product organization, invest in this partnership. Clarify the value proposition together, test product-market hypotheses with real customers, and translate learnings into clear roadmaps. Leaders like Chris make that collaboration seamless—and the result is not just a stronger product, but a more resilient, customer-centered growth engine.

Inspired by this post on Amplitude – Perspectives.

January 23, 2026
Pendomonium 101: Insider Tips, Proven Strategies, and Why This Product Festival Is Can’t‑Miss

Every year, I circle Pendomonium on my calendar because it reliably delivers the perfect blend of strategy, execution, and community. It’s where product leaders, builders, and operators compare notes on what actually moves activation, adoption, and retention—and where I pressure-test my roadmap and go-to-market assumptions against real-world data and peer experience.

Pendomonium is a product festival by Pendo in downtown Raleigh. Get answers to all your questions about the best product festival of the year.

From a product management leadership lens, the value is clear: Pendomonium is a concentrated learning loop for product-led growth. I come to deepen my craft around in-app guides, onboarding flows, user activation, and product tours—then translate those insights into roadmap bets and experiments my product trios can execute immediately.

Why attend? First, signal over noise: the sessions focus on measurable customer behavior and practical playbooks, not vague inspiration. Second, community: the hallway track and roundtables are some of the best conference networking moments in our field. Third, clarity: I leave with sharper product strategy, a prioritized backlog, and a short list of experiments to validate with customers.

If you’re a first-timer, arrive with intent. Define two or three outcomes you want—such as improving onboarding completion, increasing feature adoption, or tightening product roadmapping and sprint planning—and build your agenda around those goals. Star sessions on product discovery, product strategy, and hands-on Pendo use cases like in-app guides and product tours so your notes translate into immediate action.

Make the most of the community. Treat the hallway track like a scheduled session: set a goal to meet ten peers, bring a crisp introduction, and ask concrete questions such as, “What measurable behavior change did your in-app guide drive?” or “Which activation metric mattered most for your last launch?” Swap templates and dashboards, and follow up within 24 hours while context is fresh.

Logistics matter more than most people admit. Downtown Raleigh is walkable, but high-demand sessions fill quickly—arrive early, wear comfortable shoes, and keep a portable charger handy. Schedule buffer time between talks to debrief, review notes, and have serendipitous conversations with the Pendo team and practitioners who can deepen your approach.

Capture, then operationalize. I use a simple note structure: Insight → Hypothesis → Experiment → Metric. Turn session takeaways into tests (for example, variations of onboarding checklists or empty-state prompts) and define success criteria in advance. Align those experiments with your OKRs and use QBRs to review outcomes, ensuring what you learned at the festival translates into measurable product impact.

Post-event, run an internal readout within a week. Demo two applicable ideas, propose a 30-60-90 day experiment plan, and tie each initiative to a customer behavior metric such as time-to-value, daily active usage, or feature adoption. This is how Pendomonium goes from inspiring to invaluable—by turning insights into shippable, testable work that advances your strategy.

If this is your first Pendomonium, expect high energy, candid conversations, and a wealth of practical tactics you can apply immediately. I’ll be there comparing notes, learning from peers, and sharing what’s worked—and what hasn’t—in scaling product organizations. If you spot me in a session on activation or onboarding, come say hello.

Inspired by this post on Pendo – Best Practices.

January 23, 2026
11 Product Management Shifts Redefining 2026: Actionable Signals from Top Leaders

2026 is closer than it feels, and the signals are already clear. I’ve been synthesizing what I’m seeing across empowered product teams, boards, and cross-functional partners into a practical view of what matters next. A sharp look at product management trends for 2026. Not guesses, but signals from top product leaders shaping how PMs will actually work next.

In this analysis, I distill eleven shifts that are changing the craft—from outcomes vs output OKRs and continuous discovery to stronger product strategy and tighter product roadmapping and sprint planning. The throughline is simple: prioritize customer value, ship with focus, and measure what moves the business. These aren’t headline trends; they’re working patterns I’m seeing across high-performing organizations.

AI is no longer a side project—it’s part of the product manager’s core toolkit. Agentic AI, LLMs for product managers, and trustworthy AI workflows are accelerating discovery, sharpening problem framing, and enabling faster iteration. The best teams pair this with disciplined evaluation and experimentation, so insight compounds without sacrificing safety, privacy, or product quality.

Execution is getting crisper through product trios and stronger stakeholder management. When design, product, and engineering co-own discovery and delivery, teams reduce handoffs and increase clarity. That alignment translates into better prioritization, fewer context-switches, and a roadmap that reflects real trade-offs—not wish lists.

On growth, product-led growth remains a durable engine when it’s anchored in a compelling value proposition and instrumented end-to-end. Clear activation moments, in-app guides, and thoughtful product tours outperform brute-force acquisition. When we connect these motions back to product strategy and the roadmap, we create a repeatable loop that compounds adoption and retention.

Governance and trust are now table stakes. Privacy-by-design, data governance, and a pragmatic approach to regulatory compliance protect both users and velocity. Teams that build these practices into their operating model move faster because they avoid late-stage rework and maintain stakeholder confidence.

If you’re leading a product org—or aspiring to—this is your field guide to 2026. I’ll unpack where these shifts are strongest, how to apply them in your context, and the pitfalls to avoid. The aim is to give you clear language, concrete practices, and a sharper edge as you shape what your team builds next.

Inspired by this post on Product School.

January 12, 2026
Turn Every Support Ticket into Product Truth: My Playbook for Data-Driven CX Wins

Support tickets are the rawest signal of product truth. Leading product teams at HighLevel, I’ve learned that the fastest way to build what customers value is to transform frontline conversations into a repeatable, data-driven system for discovery, prioritization, and execution.

What if your support and product teams could unlock CX insights to turn every ticket into strategic product intelligence? Explore how.

Here’s the operating system I rely on. First, I connect our support stack (think Intercom and our CRM integration) into a unified analytics platform so every conversation, tag, and resolution is queryable. I don’t just count tickets—I segment them by product area, customer segment, lifecycle stage, and revenue impact to reveal patterns that roadmaps can act on.

Next, we standardize a shared taxonomy. Agents apply concise, high-signal labels (problem type, severity, intent), and we augment that with AI-driven auto-tagging to reduce noise and improve recall. The result is trustworthy “voice of the customer” data that product managers and support leaders can both stand behind.

Prioritization then becomes rigorous and fair. I weight themes by severity, frequency, ARR exposure, and time-to-value, and tie them directly to outcomes vs output OKRs. Amplitude analytics helps me quantify impact—what’s breaking activation, what’s dragging conversion, what drives retention analysis—so the backlog reflects business outcomes, not opinions.

Discovery is continuous by design. Product trios (PM, design, engineering) run weekly reviews of the highest-signal themes, recruit users straight from recent tickets, and prototype solutions quickly. We validate ideas with A/B testing when appropriate and ship targeted in-app guides to reduce confusion before it becomes a ticket.

Crucially, we close the loop. When we release a fix or improvement, we notify affected customers and the agents who flagged the issue. We track downstream effects—ticket deflection, CSAT, feature adoption, and time-to-resolution—so everyone sees how customer support ai strategy accelerates product-led growth.

This approach also builds culture. Empowered product teams treat support as a strategic partner, not a cost center. Agents become co-creators of the roadmap, and PMs gain a steady stream of product discovery opportunities grounded in real user outcomes.

If you’re getting started, a simple 30-60-90 can help: in 30 days, unify the data and agree on taxonomy; in 60, instrument dashboards and adopt a weekly insights ritual; in 90, align priorities to OKRs, launch targeted fixes, and measure business impact. That’s how tickets turn into product truth—and how CX insights drive compounding wins.

Inspired by this post on Amplitude – Perspectives.

January 8, 2026
7 Proven Steps to Win Stakeholder Buy-In with Clarity, Data, and Lasting Trust

Buy-in isn’t a single meeting; it’s a designed journey. Over the years leading product strategy at HighLevel, I’ve learned that the fastest way to earn durable support is to reduce uncertainty, align on outcomes, and create visible momentum. Explore how to get buy-in from stakeholders with practical strategies, clear communication tips, and proven methods used by the best. Here’s the 7-step playbook my teams and I rely on to move from idea to aligned action.

Step 1 — Anchor on outcomes, not outputs. I start by writing a crisp problem statement, the target customer, and the measurable outcome tied to our North Star metric. I translate this into outcomes vs output OKRs so every stakeholder can see the difference between what we’ll ship and what we intend to change. This framing keeps discussions grounded in impact, not features.

Step 2 — Map stakeholders and incentives. Effective stakeholder management begins with a living map: economic buyers, executive sponsors, influencers, and operators. I capture each person’s goals, risks, and decision cadence. When I speak to Finance, I foreground cost and runway; with Sales, I emphasize pipeline and win rate; for Customer Success, I speak to retention and NPS. Meeting stakeholders where they are builds trust quickly.

Step 3 — Co-create early with the product trio. I pull the product trios (PM, Design, Engineering) into continuous discovery with GTM partners to validate assumptions and de-risk the solution. This is where empowered product teams shine—rapid discovery sprints, early prototypes, and clear learning objectives. Co-creating exposes blind spots early and transforms critics into champions.

Step 4 — Socialize a narrative, not a deck. Before any formal review, I circulate a short narrative memo that ties our product strategy to a clear value proposition, competitive differentiation, and go-to-market strategy. I include options and trade-offs so stakeholders feel invited to shape the path, not just stamp approval. Pre-wiring conversations ensure that the “meeting” is simply the last 10% of the decision.

Step 5 — Back the story with data and a viable plan. I combine retention analysis, funnel metrics, and customer evidence to demonstrate opportunity size and risk reduction. Then I outline a phased approach with product roadmapping and sprint planning, milestones, and success metrics. I highlight the smallest viable bet that proves value fast, along with contingency paths if we learn something unexpected.

Step 6 — Design the decision. I define the decision we need, by whom, and by when. The decision doc includes the problem, options, risks, mitigations, and the explicit ask. I schedule 1:1s to address concerns, then run a focused review with clear roles and time-boxed discussion. Clarity about the decision—and the criteria—prevents drift and protects timelines.

Step 7 — Sustain momentum post-approval. After the green light, I convert the plan into execution cadences: weekly demos, transparent dashboards, and QBRs vs OKRs check-ins to reinforce outcomes. We celebrate learning milestones, not just launches, and keep stakeholders informed with concise updates that tie progress to the original outcomes and value proposition. Momentum is the best antidote to second-guessing.

Clear communication and a repeatable process turn buy-in from a hurdle into a habit. When stakeholders see a compelling narrative, credible evidence, and a path to value, they don’t just approve—they advocate. Follow these seven steps and you’ll build alignment faster, ship smarter, and strengthen trust across the organization.

Inspired by this post on Product School.

January 7, 2026
Unlock Travel & Hospitality Growth: Product Benchmarks and Metrics Top Teams Rely On

I lead product teams building travel and hospitality experiences, and one lesson keeps repeating: companies that measure what matters move faster. Benchmarks turn gut feel into grounded product strategy, making it clear where activation, conversion, and retention are underperforming—and where we can unlock outsized growth.

Discover exclusive data and strategies from our Product Benchmark Report. Compare the travel and hospitality industry’s performance across key product metrics.

When I evaluate a product line, I start with a simple model: attract, convert, delight, and retain. For travel and hospitality specifically, I focus on search-to-book conversion, onboarding completion, first-booking activation rate, time-to-book, average booking value, cancellation rate, support contact rate, DAU/MAU stickiness, repeat booking rate, and long-term retention. These key product metrics reveal friction in discovery and checkout flows, surface pricing and inventory gaps, and quantify loyalty.

From there, I assemble a test-and-learn plan. Using Amplitude analytics to instrument the funnel and Pendo for in-app guides and product tours, my teams design A/B testing with a clear minimum detectable effect (MDE), prioritize hypotheses, and execute rapid, weekly iterations. This is classic product-led growth: reduce cognitive load in onboarding, streamline search and filter UX, clarify policies before payment, and personalize reactivation nudges to improve user activation and retention analysis.

Benchmarks are only as trustworthy as the underlying data. I insist on strong data governance, privacy-by-design practices, and clear event taxonomies so that insights remain reliable across quarters and across markets. That foundation keeps our decisions defensible with stakeholders and regulators while accelerating delivery.

Finally, we translate insights into action with crisp product roadmapping and sprint planning. Cross-functional product trios align OKRs to the biggest benchmark gaps, and we review progress in weekly performance rituals so every experiment ladders up to strategy. This cadence helps teams stay empowered and keeps leadership focused on outcomes, not output.

If you’re building in travel and hospitality, use these benchmarks as your starting line and your ongoing scorecard. Calibrate targets against peers, double down on what moves the needle, and let the data guide bold, customer-centered bets. When teams rally around meaningful metrics, momentum compounds.

Inspired by this post on Amplitude – Perspectives.

January 5, 2026