I’ve led product teams through countless discovery cycles, and nothing has accelerated our learning loops like AI. By weaving AI into our continuous discovery practice at HighLevel, I cut time-to-insight, reduce risk earlier, and keep our product strategy relentlessly focused on customer outcomes.
AI streamlines product discovery by accelerating research, prototyping, and validation, enabling teams to make faster, smarter, and user-driven decisions.
In the research phase, I use gen ai and LLMs for product managers to synthesize interviews, cluster themes, and surface unmet needs in minutes instead of days. Pairing those qualitative insights with behavioral signals in Amplitude analytics helps me spot high-intent cohorts and friction points at scale, so our problem framing is both human-centered and data-backed.
From there, I translate insights into crisp hypotheses and prioritize with the Kano Model and outcomes vs output OKRs. To keep experiments honest, I define a minimum detectable effect (MDE) up front and design A/B testing plans that reflect realistic traffic and seasonality, ensuring our decisions are statistically grounded rather than anecdotal.
Prototyping is where gen ai for product prototyping really shines. I spin up multiple UX flows, UI copy variants, and edge-case scenarios using prompt engineering, then iterate with rapid feedback from product trios. When needed, I mock in-app guides and product tours to validate onboarding concepts before we commit to code, preserving velocity without sacrificing quality.
For validation, I lean on a mix of lightweight experiments—fake-door tests, concierge pilots, and targeted A/B testing—augmented by in-product surveys via Pendo or Intercom. For AI-powered features, I apply eval-driven development to measure relevance, latency, and safety, so we can ship responsibly while maintaining the pace of learning.
This approach only works when the team is structured to move fast. Empowered product teams and product trios own discovery end-to-end, with clear guardrails around data governance, privacy-by-design, and AI risk management. That alignment lets us shift from opinions to evidence, and from output to outcomes, without friction.
If you’re getting started, pick one discovery loop to transform: automate research synthesis, prototype two to three variants with AI, and validate with a tightly scoped experiment. Instrument your analytics, track time-to-insight and time-to-prototype, and iterate your product roadmapping and sprint planning with what you learn. The payoff is immediate: faster cycles, stronger conviction, and a more user-driven path to product-led growth.
Happy New Year! I’m kicking off 2026 with a behind-the-scenes look at what’s changing in my product practice, the experiments I’m running with my teams at HighLevel, and the trends I’m most energized by—especially around continuous discovery, AI workflows, and building stronger coaching cultures.
If you want to listen to the conversation that sparked many of these reflections, you can find it here: Spotify | Apple Podcasts.
Why Teresa sunset the live deep-dive cohorts—and how on-demand and the new Discovery Habits Toolbox better support real behavior change. This pivot resonated with my own experience: some skills, especially discovery habits, only stick when they’re reinforced in the flow of real product work, not just in a time-boxed cohort. In my org, we’re leaning into on-demand learning paired with manager coaching to drive durable behavior change.
What leaders actually need to coach interviewing, assumption testing, and core discovery habits inside their orgs. I’ve found that empowered product teams thrive when leaders have lightweight coaching tools, practical prompts, and clear expectations for product trios. This is less about one-off training and more about building communities of practice where deliberate practice and feedback loops become routine.
Why training is shifting toward ongoing, leader-supported learning (and how AI will accelerate the shift). AI Strategy isn’t just about tools—it’s about learning systems. For LLMs for product managers to create leverage, we need eval-driven development, privacy-by-design, and clear guardrails. I’m building AI workflows that enable managers to review interviews, spot anti-patterns, and nudge teams toward better decisions—without replacing critical thinking.
Teresa’s move into paid subscriptions and why AI content doesn’t fit the classic “design once, run for years” course model. I see the same reality in my content roadmap: the half-life of AI guidance is short. That pushes us toward subscription models, tighter feedback loops, and a more adaptive go-to-market strategy for education products.
A sneak peek into the AI tools Teresa is building for discovery work—from interview coaching to near-ready interview snapshot generation. I’m particularly excited by tooling that scaffolds better interviews, sharpens assumption testing, and speeds up synthesis without skipping the human judgment step. These capabilities map directly to where I want my teams investing time: spending less energy on admin and more on learning from customers.
Petra’s plans for the year: community building with Product at Heart, a new product leadership email course, her Product Leadership Wheel, and workshops launching in Cairo. As someone who believes in conferences as high-quality “energy wells,” I’m inspired by how these programs create momentum for leaders who are upgrading their coaching muscles.
The role of conferences and retreats in staying grounded, inspired, and connected. I treat these gatherings as strategic resets—spaces to test ideas, confront blind spots, and deepen my network for future collaboration. The best outcomes often come from serendipitous hallway conversations and hands-on sessions where you can pressure test frameworks with peers.
How Teresa is staying on top of academic research (and why “synthetic users” aren’t ready for prime time). I agree: while synthetic data can be useful for scaffolding, it’s not a substitute for direct customer contact. Combine academic rigor with real-world interviewing and strong data governance—especially when operating under General Data Protection Regulation (GDPR).
The shared challenge of evaluating vendors and conference speakers making questionable AI claims. My heuristic: ask for clear problem statements, reproducible evaluations, grounded benchmarks, and a path to safe deployment. If a pitch can’t show measurable uplift or ignores compliance, it’s not ready for empowered product teams.
Key takeaways I’m carrying into 2026: delivery models matter; leaders need coaching tools, not just training; AI is reshaping how we teach and learn; experimentation is the theme of 2026; and community still energizes. That’s the blueprint I’m using to strengthen continuous discovery, refine our AI workflows, and sustain high standards in product management leadership.
What about you? How are you integrating AI workflows into your discovery practice, and what coaching tools are helping your managers reinforce the right habits? Share your approach—I’d love to learn what’s working in your context.
Resources & Links:
Follow Teresa Torres: https://ProductTalk.org
Follow Petra Wille: https://Petra-Wille.com
Teresa’s website: Product Talk
General Data Protection Regulation (GDPR)
Product Talk Academy
Deliberate Practice – ATP episode where Teresa talked about the ending live cohorts for Deep Dive classes
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.
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.
I’ve never seen great products emerge from a one-sided mindset. Inside-out thinking (strategy-first) and outside-in thinking (customer-first) aren’t rivals—they’re a flywheel. When I weave product vision and defensible differentiation together with real customer signals and behavioral data, adoption climbs, engagement deepens, and the roadmap becomes a catalyst for growth rather than a list of features.
For clarity: inside-out anchors on product strategy, value proposition, and the unique capabilities only we can deliver. Outside-in centers on continuous discovery, user research, and telemetry that reveals what customers actually do—not just what they say. At HighLevel, we pair these perspectives in every planning cycle so we’re bold in direction and grounded in evidence.
Increase revenue, cut costs, and reduce risk with Pendo’s Software Experience Management platform. Optimize the entire software experience to drive adoption and improve engagement.
That promise captures why the blend matters. Product-led growth lives or dies on moments like activation, time-to-first-value, and day-30 retention. Inside-out thinking ensures we’re building toward a compelling vision; outside-in thinking ensures users can discover, adopt, and realize value through clear onboarding, in-app guides, and contextual product tours.
Here’s how I apply it in practice. We start by articulating the smallest, sharpest version of our strategy—who we serve, the jobs we must win, and the non-negotiable outcomes. Then we pressure-test that thesis with continuous discovery: call snippets, funnel analysis, pathing, and retention analysis by cohort. When friction shows up in onboarding or early feature adoption, we deploy targeted in-app guides and tours to accelerate user activation without bloating the product or training costs.
A simple operating rhythm keeps the balance: begin each quarter with outcomes vs output OKRs tied to adoption and retention; instrument flows to expose drop-offs; ship iterative improvements; and reinforce them with just-in-time guidance. We use outside-in signals to sequence what we tackle next, and inside-out conviction to avoid chasing noise. The result is faster learning cycles and fewer expensive reworks.
Measurement closes the loop. I track activation rate, time-to-first-value, engagement with the few behaviors that predict renewal, and the impact of each guide or tour on completion rates. When we see lift, we codify the pattern; when we don’t, we prune and refocus. That evidence-based cadence keeps teams empowered and stakeholders aligned.
Culture makes this sustainable. Empowered product teams own outcomes, not tickets. Stakeholder management becomes easier when decisions are grounded in a clear strategy and transparent evidence from real users. And customers feel the difference when the product teaches itself—meeting them with the right help, in the right moment, without getting in their way.
If you’ve been choosing between inside-out and outside-in, stop. Fuse them. Lead with a crisp product strategy, listen with humility, and operationalize adoption through purposeful onboarding, in-app guides, and product tours. That’s how we compound learning, reduce risk, cut support costs, and accelerate product-led growth.
You ask an AI model for a feature brief. It returns polished prose, sensible recommendations, and a tidy set of success criteria. Then the review starts: the target segment is wrong, the customer evidence is anecdotal, a strategic constraint is missing, and nobody can tell where the claims came from.
The goal is not to give the model everything your company knows. The goal is to provide the smallest sufficient body of evidence for the decision in front of you, while preserving enough lineage for a reviewer to inspect the result.
Key takeaways
Start with a decision contract that defines the decision, audience, constraints, evidence standard, and required output.
Build a compact context pack from canonical strategy, relevant behavioral data, direct customer evidence, operating constraints, and decision history.
Retrieve before you generate. Use metadata, recency, authority, and relevance to select evidence instead of dumping entire repositories into the context window.
Preserve traceability. Every important claim should point to an evidence identifier, and the output should separate observations, inferences, and recommendations.
Version the prompt and context together, then evaluate the complete system through rework, review time, first-pass alignment, and evidence fidelity.
Start with the decision, not the document
Product teams often describe the artifact they want rather than the decision it must support. Draft a PRD, summarize these interviews, or write a roadmap rationale sounds concrete, but each request leaves the model to infer what matters.
That ambiguity changes retrieval. A positioning decision needs competitive and customer-language context. A prioritization decision needs strategy, affected users, behavioral evidence, constraints, and opportunity cost. Release notes need verified product behavior, the intended audience, and approved terminology. The same generic prompt cannot reliably determine those boundaries.
Before gathering evidence, write a decision contract with these fields:
Decision: What choice, judgment, or next action will this output support?
Audience: Who will review or use it, and what do they already know?
Deliverable: What sections, level of detail, and format are required?
Boundaries: What is explicitly out of scope, already decided, or prohibited?
Evidence standard: Which claims require direct evidence, and how should citations appear?
Uncertainty: What should the model do when evidence is missing, stale, or contradictory?
A weak request is: Summarize onboarding research. A decision-ready request is: Help the product trio decide whether the onboarding problem should enter discovery. Identify the affected cohort, observed friction, strength of evidence, unresolved questions, and the next research step. Do not recommend a roadmap commitment.
The second request gives retrieval a job. It tells the system which evidence to find and gives reviewers a basis for rejecting unsupported output.
Give conflicting evidence an explicit hierarchy
Most internal knowledge bases contain competing versions of reality. A planning deck may conflict with an approved strategy. A recent support conversation may contradict an older research summary. A customer request may not match observed behavior. Without an authority rule, the model may blend these artifacts into a confident compromise that nobody actually endorsed.
A practical default hierarchy is:
Current, approved strategy and explicit leadership decisions establish the frame.
Behavioral evidence establishes what users did within the measured population and period.
Verbatim customer evidence establishes what particular customers said and how they described the problem.
Support and operational signals reveal recurring friction that may need further validation.
Team hypotheses remain hypotheses until stronger evidence supports them.
This is a starting rule, not a universal ranking. Your hierarchy should match the decision. The important move is to state it. Freshness alone does not make an artifact authoritative, and authority alone does not make old evidence current. When two credible artifacts disagree, instruct the model to expose the conflict rather than reconcile it silently.
Build a minimum viable context pack
A context pack is the evidence package for one task. It is deliberately narrower than a company knowledge base. Each item earns its place by answering a question the requested output must address.
Context layer
Question it answers
Useful artifact
Strategic frame
Why does this problem matter now?
Approved strategy statement, objective, or decision principle
Affected user
Who experiences the problem?
Cohort definition, segment criteria, or relevant account profile
Behavior
What happened in the product?
Usage pattern, funnel analysis, retention signal, or journey evidence
Customer need
How do users describe the problem?
Verbatim interview excerpts, support conversations, or research synthesis
Constraints
What limits the solution space?
Technical, operating, commercial, or policy constraint
Decision history
What has already been decided or rejected?
Decision record with rationale and status
Do not fill every row by default. For a narrow writing task, two layers may be enough. For a prioritization decision, several may be essential. Start with the requested output and ask which evidence would allow a skeptical reviewer to verify each section.
The example works because each artifact has a different job. Five documents making the same strategic argument would create repetition, not coverage. Context quality comes from complementary evidence, not document count.
Turn each artifact into an evidence unit
Raw files are difficult to retrieve and easy to misread. Wrap each relevant slice in a small evidence unit:
Identifier: a stable label such as E1 or E2 that the output can cite.
Origin: the system, analysis, interview, or decision record from which it came.
Status: approved, draft, superseded, disputed, or observational.
Scope: the segment, cohort, workflow, product area, and period to which it applies.
Relevant finding: a concise summary written for the current decision.
Raw evidence: the excerpt, data slice, or linked artifact needed to inspect the summary.
Caveat: a known limitation, missing comparison, or unresolved contradiction.
This two-layer structure solves a common compression problem. The short summary conserves context-window space, while the raw excerpt preserves wording and qualifiers when nuance matters. Do not repeatedly summarize prior summaries. Each compression step can remove scope, uncertainty, and disagreement. Keep a path back to the underlying evidence.
You have enough context when every required part of the deliverable has relevant evidence, major conflicts are represented, and additional artifacts merely repeat what is already present. If an output section has no supporting evidence, either retrieve more or label the section as an open question. Do not ask fluent prose to hide the gap.
Retrieve, compress, and assemble in that order
Large context windows make it tempting to attach whole repositories. That usually transfers the curation problem to the model. Relevant evidence must now compete with stale plans, duplicate findings, unrelated segments, and abandoned decisions.
Translate the decision contract into evidence questions. Ask what strategic frame, customer signal, behavior, constraint, and decision history are required.
Filter by hard boundaries first. Exclude the wrong product area, segment, status, or period before semantic ranking.
Retrieve relevant slices rather than complete files. A paragraph, chart interpretation, interview excerpt, or decision entry is often the useful unit.
Check authority and freshness. Mark superseded items and retain an older artifact only when its historical context matters.
Check coverage and contradiction. Confirm that the pack represents the affected population and does not hide credible opposing evidence.
Compress each selected item into an evidence unit, retaining a link or raw excerpt for verification.
Assemble the context in a fixed interface so the model can distinguish instructions, evidence, and the requested output.
Retrieval should also preserve access boundaries. An AI layer should not expose an artifact to someone who could not access it in its system of record. Treat customer material and internal strategy as governed inputs, not convenient prompt text.
Use a stable context interface
I treat the prompt as an interface to the context system, not as the system itself. A useful interface contains these blocks in a consistent order:
Role and objective: the perspective the model should take and the decision it must support.
Audience: the people who will use the deliverable and the assumptions they already share.
Constraints: scope boundaries, settled decisions, prohibited claims, and required terminology.
Evidence: labeled units such as E1, E2, and E3, each with status, scope, summary, raw support, and caveats.
Explicit ask: the analysis or artifact required, expressed as concrete questions.
Output contract: required sections, length, ordering, and citation format.
Evidence rules: cite material claims, distinguish observation from inference, expose conflicts, and avoid unsupported facts.
Self-check: identify missing evidence, unverified assumptions, constraint violations, and statements that lack citations.
Do not rely on instructions such as be accurate or think carefully. They do not define what accuracy means for this task. A stronger rule is: Cite an evidence identifier after every material claim. If the pack does not support a claim, label it as an inference or omit it. List unresolved questions separately.
Diagnose output failures as context defects
Output symptom
Likely context defect
Corrective move
Generic recommendations
The pack lacks customer, behavior, or constraint evidence
Add decision-specific evidence instead of more role-playing instructions
Confident but outdated claims
Retrieval ignored status, authority, or recency
Filter superseded artifacts and define which record is canonical
Important nuance disappears
Compression removed qualifiers or disagreement
Restore raw excerpts and carry caveats into the evidence units
Long output that does not support a decision
The ask names an artifact but not the decision
Rewrite the decision contract and remove irrelevant context
Stakeholders distrust the result
Claims have no visible lineage
Require evidence identifiers and preserve links to underlying artifacts
Repeated runs produce different conclusions
The prompt or context changed without version control
Snapshot both inputs and compare one controlled change at a time
This diagnostic matters because prompt edits can disguise the real failure. If the wrong cohort entered the pack, a more detailed output format will only produce a better-organized mistake.
Manage context quality as a product system
A single well-curated prompt can produce a good result. A product team needs a system that can produce a good result again, show why it was good, and reveal what changed when quality declines.
Make the output auditable
Ask the model to separate three kinds of statements:
Observation: directly supported by an evidence unit.
Inference: a reasoned interpretation that connects observations.
Recommendation: a proposed action that depends on evidence, assumptions, and product judgment.
This distinction prevents a plausible interpretation from being presented as a measured fact. Behavioral analytics can show a pattern within its defined cohort and period; it does not, by itself, establish why the behavior occurred. A customer quote can establish that a person expressed a need; it does not, by itself, establish prevalence. The final recommendation still needs human judgment about strategy, tradeoffs, and risk.
For consequential work, request a smaller cited output first. Review its evidence mapping, then expand it into a PRD, roadmap narrative, or executive brief. This makes unsupported reasoning easier to catch than reviewing a long deliverable after the model has built several sections on the same weak assumption.
Version the whole generation package
Store these elements together for each run:
Workflow and template version
Decision contract
Context snapshot and evidence identifiers
Retrieval and filtering rules
Prompt version
Model output
Human review result and requested changes
Prompt versioning without context versioning is incomplete. Two runs using identical instructions can diverge because an approved strategy changed, a stale analysis entered retrieval, or a different set of interviews was selected. The context snapshot lets you explain that difference.
Evaluate the workflow, not the elegance of one answer
Create a small evaluation set from real, recurring product tasks. Keep the decision and expected evidence stable while testing changes to retrieval, compression, context ordering, or instructions. Change one major variable at a time; otherwise you will not know what improved the result.
Review each run against a consistent rubric:
Evidence fidelity: Do claims accurately represent the cited material and its scope?
Coverage: Does the output address every required part of the decision?
Constraint adherence: Does it respect settled decisions, exclusions, and required terminology?
Traceability: Can a reviewer follow important claims back to evidence?
Uncertainty handling: Are missing, stale, or contradictory inputs visible?
Decision usefulness: Can the intended audience act, decide, or request the right next evidence?
When an evaluation fails, route the defect to the right layer. Evidence fidelity usually points to retrieval, source selection, or compression. Constraint failures point to the context interface. A technically correct but unusable deliverable points back to the decision contract. This turns AI quality from a subjective debate into a product improvement loop.
Template workflows only after you understand their evidence needs
Discovery synthesis, roadmap rationale, feature briefs, and release notes are good candidates because they recur and have recognizable inputs. Give each workflow its own decision contract, required context layers, retrieval filters, output contract, and evaluation rubric. Do not force them into one universal mega-prompt.
Start with one workflow your team already performs frequently. Take a real task, define the decision, assemble a compact evidence pack, assign identifiers, and review the result against the rubric above. Save the complete generation package. On the next run, change one weak layer and compare the review burden.
Once that loop is repeatable, AI stops being a blank page with a clever prompt. It becomes a governed product workflow whose inputs, reasoning boundaries, and quality can be inspected and improved.
Experience quality compounds just like code quality. To align teams and accelerate outcomes, I rely on a clear, five-stage software experience maturity model to assess where we are, why we’re there, and how to advance. It turns fuzzy debates into concrete product strategy and reinforces a product-led growth mindset.
Find out where you stand—and what to fix first—with this maturity framework.
Why a five-stage model? It gives product, design, engineering, and go-to-market a shared language for trade-offs, helps us move from opinions to evidence, and ties day-to-day improvements to outcomes vs output OKRs. Instead of spreading effort thin, we sequence the right bets at the right time and build momentum with measurable wins.
Here’s how I apply it in practice. I start with a brief, honest self-assessment across the customer journey: onboarding clarity, user activation moments, in-app guides and product tours, UX writing, support loops, reliability, and analytics coverage. Then I layer in learnings from continuous discovery and product discovery—interviews, usage patterns, and support transcripts—so we see the experience as customers do, not just as we intended.
When it comes to what to fix first, I prioritize prerequisites over polish. If the value proposition isn’t clear, onboarding is confusing, or activation is inconsistent, we address those before adding new features. I instrument the funnel end-to-end, establish a minimum detectable effect (MDE) for A/B testing, and ensure we can answer basic questions about who activates, who retains, and why.
Measurement is non-negotiable. I pair retention analysis and activation metrics with qualitative signals to avoid local maxima. Amplitude analytics helps reveal behavioral patterns, while Pendo and in-app guides close gaps in comprehension and guidance. Intercom and CRM integration with HubSpot connect product signals to account health, so we can see how experience maturity drives revenue and retention.
Operationally, I anchor the roadmap to a small set of experience outcomes, link them to product strategy, and review progress in cadence with leadership. This approach builds product management leadership muscle: sharper stakeholder management, clearer trade-offs, and faster feedback loops. Most importantly, the team sees how each improvement ladders up to a better, more durable user experience.
If you’re mapping your own path across the five stages, start by sizing the gaps that block activation and retention, commit to a few high-leverage fixes, and measure relentlessly. With a shared maturity model, your team gains focus, your customers feel the difference, and your product compounds value with every release.
When I map the customer lifecycle, I look for the precise moments where guidance, context, and timing can transform a casual click into a committed relationship. That’s exactly why I rely on Pendo Orchestrate—to turn intent into a systematic, repeatable product strategy that scales across every stage of the journey.
From first click to lifelong retention, you’ll deliver the right message at the exact right time, every step of the way. With Pendo Orchestrate, you can design those kinds of moments with intention. And in this blog, we’ll show you how.
In practice, I translate that promise into four lifecycle journeys every product team should be running with Pendo Orchestrate: new user onboarding, activation to the aha moment, expansion and upsell, and renewal and retention. These journeys power product-led growth and keep the roadmap aligned to measurable business outcomes.
Onboarding: I use in-app guides and product tours to welcome new users, set expectations, and reduce time-to-value. Contextual tooltips and gentle checklists keep users moving, while clear, concise UX writing removes friction. The goal is simple: accelerate early wins so onboarding naturally flows into user activation.
Activation: To help users reach the aha moment, I pair behavioral insights with targeted in-app guides. When a user approaches a key milestone, Pendo Orchestrate triggers just-in-time prompts that reinforce the value proposition. I keep these nudges focused, specific, and measurable so activation improves without overwhelming the experience.
Expansion: Once users adopt core workflows, I introduce advanced capabilities through tailored tours and contextual education. These cues appear where they’re most relevant—in the flow of work—so cross-sell and upsell moments feel helpful, not salesy. The intent is to deepen adoption by connecting features to outcomes users already care about.
Renewal and retention: I watch for patterns that suggest risk (stalled usage, incomplete workflows) and offer supportive interventions. Lightweight guides, quick tips, and feedback loops help resolve issues before they become churn. Combined with retention analysis, these orchestrations keep customers engaged and set the stage for long-term value.
When these four journeys run in concert, your product becomes the primary engine of growth. Pendo Orchestrate ensures the right in-app guidance shows up at the right moment—so your product strategy, product discovery, and day-to-day execution stay tightly aligned. That’s how you move beyond one-off campaigns and build a durable, product-led growth system.
INDUSTRY 2025: The Product Conference is circled on my calendar for good reason. In my role leading product management at HighLevel, I look for events that sharpen strategy, accelerate learning, and connect me with operators who ship. This one consistently delivers on all three, and 2025 promises to raise the bar for product management leadership.
Join Pendo at INDUSTRY in Cleveland, Ohio.
First, I expect deeply actionable product strategy insights—beyond platitudes. I’m prioritizing conversations on outcomes vs output OKRs, product roadmapping and sprint planning, and how great teams articulate a crisp value proposition while maintaining points of parity that matter. I’m going in with specific questions on product-market fit lessons and how to systematize strategic bets without stifling discovery.
Second, the surge of AI in product work is too important to observe from the sidelines. I’m comparing approaches across AI Strategy, LLMs for product managers, prompt engineering, and eval-driven development—especially in retrieval-first pipeline patterns. My focus: where AI genuinely improves product discovery, in-app guides, and customer support ai strategy, and where it risks adding complexity without outcomes.
Third, the community is unmatched for conference networking and pragmatic learning. I’m intentional about meeting product trios who run continuous discovery at scale, as well as leaders who’ve cracked stakeholder management under pressure. These are the moments where competitive differentiation is born—through candid stories of what didn’t work and why.
Fourth, I’m eager to stress-test data practices that power product-led growth. I’ll be exchanging notes on retention analysis, unified analytics platform decisions, user activation, and how teams integrate qualitative feedback with event data to inform roadmaps. I’m also interested in how practitioners leverage platforms like Pendo, Amplitude analytics, Intercom, and HubSpot to reduce time-to-insight and craft effective product tours and in-app guides.
Fifth, I treat INDUSTRY as a checkpoint for leadership growth. I’m looking for fresh takes on empowering product teams, first principles decision making, organizational development, and the IC to manager transition. The best sessions don’t just inspire; they give me two moves I can apply with my team on Monday.
To make the most of the week, I’m applying a continuous discovery mindset: arrive with clear learning goals, capture portable frameworks, and translate at least two insights into experiments before wheels-up. If you’re focused on product strategy, product discovery, and product-led growth, we’ll have plenty to compare and build on together.
I’ll be in Cleveland ready to learn, share, and connect with peers who care about craft and outcomes. If you’re attending, let’s compare notes on what’s working, what’s stalled, and how we can raise the bar for product management leadership in 2025 and beyond.
I build AI products with a simple conviction: disciplined experimentation beats intuition. Over the years, I’ve refined a practical playbook that helps my teams learn faster, reduce risk, and turn every release into a smarter next step.
Product experimentation isn’t luck; it’s a method. Learn how top AI product managers test, measure, and grow smarter with every release.
I begin every effort with a crisp hypothesis, an expected user or business outcome, and unambiguous success criteria tied to outcomes vs output OKRs. Before writing a line of code, I define primary metrics and guardrails so we know what “good” looks like—and what to stop.
When the change affects UX, pricing, or activation flows, I favor A/B testing with the statistical rigor to back decisions. We calculate the minimum detectable effect (MDE), choose appropriate randomization units, and pre-register the analysis plan to avoid p-hacking. This gives the team the confidence to scale wins and sunset underperformers quickly.
AI features demand a tailored approach, so I run eval-driven development before any user sees a variant. We curate golden datasets, score candidate prompts and models, and stress-test failure modes. This is where LLMs for product managers matters: prompt templates, context window management, and a retrieval-first pipeline are all evaluated for quality, latency, and cost-to-serve. I treat “hallucination rate,” safety violations, and bias as first-class metrics under AI risk management.
To de-risk launches, we ship behind feature flags with CI/CD, monitor DORA metrics, and roll out in stages. Product trios own problem framing to solution delivery, which shortens feedback loops and preserves accountability. If early signals drift from our hypotheses, we pause, adjust, and re-run—no sunk-cost thinking.
Measurement is non-negotiable. I instrument user journeys end-to-end with Amplitude analytics, track activation and retention analysis, and map behavior to learning objectives. We consolidate logs and events into a unified analytics platform so qualitative insights from customer research pair cleanly with quantitative trends.
Continuous discovery keeps the engine running. Weekly customer conversations, in-product feedback, and lightweight prototypes ensure we validate needs, not just solutions. The output flows into product discovery, product roadmapping and sprint planning, and a reusable AI product toolbox that scales across teams.
Finally, I protect the culture that makes experimentation work: we celebrate invalidated hypotheses, document decisions, and optimize for outcomes over output. That’s how empowered product teams sustain product-led growth—even as complexity grows.
If you’re building AI features today, adopt this playbook to maximize learning velocity, minimize risk, and compound advantage. The method is straightforward: form strong hypotheses, test with rigor, measure what matters, and let evidence—not HiPPOs—guide the roadmap.
Quantitative metrics tell the story in numbers; qualitative ones whisper why it matters. Both shape how products grow. Here’s what you need to know.
In my day-to-day, I rely on quantitative metrics to surface what’s changing in the business and where we need to focus. Activation rate, conversion through the onboarding funnel, feature adoption, retention analysis, and LTV/CAC give me a precise read on performance. I also keep an eye on DORA metrics to understand delivery health and deployment frequency, but I never mistake those for customer outcomes. Numbers spotlight signal—but they rarely explain causality on their own.
That’s where qualitative analysis earns its keep. Customer interviews, usability studies, win/loss debriefs, support transcripts, and community feedback give me the context behind the charts. Tools like Pendo help me layer in in-app guides and micro-surveys to capture intent and friction in the flow. This combination turns raw data into decisions that actually move the product strategy forward.
My operating cadence is simple: weekly dashboards to monitor quantitative metrics, ongoing continuous discovery to collect qualitative insight, and a monthly synthesis to reconcile both with our outcomes vs output OKRs. The aim is to move from opinions to evidence, and from anecdotes to patterns. When quant and qual agree, we execute confidently; when they diverge, we design the smallest experiment to learn fast.
I use a three-question decision tree to choose the method. First, are we exploring or validating? Exploration leans qualitative; validation leans quantitative. Second, do we have enough volume for statistical power? If yes, I’ll run A/B testing with a clear minimum detectable effect (MDE) to avoid false positives. If not, I’ll rely on targeted qualitative discovery until we can instrument a meaningful test. Third, will this decision meaningfully impact our product-led growth or user activation goals? If it will, we invest in both measurement and discovery to reduce decision risk.
Here’s a concrete example. We once saw a sudden drop in user activation. The quantitative dashboard flagged a step-function change at onboarding step three, but it couldn’t explain why. A quick round of qualitative interviews revealed that our tooltip design buried a critical permission request. We shipped a Pendo-powered in-app guide variant and ran an A/B test to validate the fix. Activation rebounded within a week, and 30-day retention followed suit.
There are common pitfalls I actively avoid. Chasing vanity metrics that don’t ladder up to outcomes. Conflating shipping speed with customer value by over-indexing on DORA metrics. Overfitting with A/B testing when the MDE is unrealistic for our traffic. And on the qualitative side, mistaking a compelling anecdote for a representative sample without triangulating evidence.
If you’re looking to tighten your practice, start with a lightweight playbook: instrument core events in Amplitude analytics; define a small set of outcomes vs output OKRs; schedule recurring customer conversations as part of continuous discovery; tag qualitative insights so patterns surface over time; and pair every material UX change with either a well-powered experiment or a clear qualitative learning goal. This creates a unified analytics and discovery loop that compounds.
Ultimately, quantitative metrics help me prioritize with clarity, while qualitative analysis helps me decide with confidence. When you weave them together, you not only ship faster—you ship the right thing, for the right reason, at the right time.
I’ve been systematically exploring how the product model shows up inside iconic companies. After studying “The Product Model at Spotify” and “The Product Model at Amazon,” I’m turning my lens to Google—specifically, how the product operating model, product culture, and product strategy manifest in practice and what we can pragmatically take back to our own organizations.
When I talk about the product model, I’m looking at the machinery that connects strategy to outcomes: empowered product teams, clear decision rights, tight product trios, continuous discovery, data-informed bets, and an operating cadence that enables learning at speed. My goal here is to unpack how those elements come together at Google and translate them into repeatable patterns you can adopt.
At a high level, I focus on how teams are empowered to solve problems rather than ship outputs, how outcomes vs output OKRs clarify what matters, and how experimentation (from rapid prototyping to A/B testing) de-risks decisions before they scale. I also examine how engineering and product partner to balance platform scalability with customer value, and how stakeholder management reinforces alignment without slowing teams down.
Why does this matter? Because the product model is a lever for resilience and speed. When product strategy is explicit and the operating model is built for learning, organizations multiply the impact of talented people. That’s how small, focused teams repeatedly deliver outsized results—even in complex, regulated, or high-scale environments like Google.
In the sections that follow, I’ll synthesize what I see as the core patterns behind Google’s approach and distill them into actionable guidance: how to structure product trios, how to run continuous discovery alongside delivery, how to set and calibrate OKRs for outcomes, and how to evolve your product culture so empowered product teams can do their best work. My aim is not to idolize a model, but to extract what’s portable and help you adapt it to your context.
