Tag: product strategy

  • Intercom Rebrands to Fin: Why Shedding Brand Baggage Powers the Next AI Era

    Intercom Rebrands to Fin: Why Shedding Brand Baggage Powers the Next AI Era

    Sometimes a corporate rename lands with such obvious inevitability—and such lateness—that it feels like a quiet confession. As a product leader, I’ve wrestled with that timing question: move early and risk confusion, or wait and risk stagnation. In this case, the industry finally received the clarity it has been circling for years.

    The announcement was clear: “we’re changing the name of our company to Fin.” Crucially, the name Intercom will continue as the customer service software platform that many of the best brands rely on as their primary help desk. The team also “just launched a complete rebuild, Intercom 2,” and is doubling down investment in that product. In other words, the company brand now matches its leading customer agent platform—Fin—while Intercom remains the flagship product line.

    From a product strategy and brand architecture perspective, this move aligns the corporate identity with the growth engine. I’ve seen too many winners of a prior era cling to yesterday’s positioning while markets shift under their feet. The phrase that keeps echoing in my mind—because it’s true in practice—is that “the only path to success in the future is through destroying your past.” Culture, pricing models, product lineup, investment priorities—those can evolve. But until the company name evolves, the market’s mental model often does not.

    It’s telling that three years ago, when the team effectively created the service agent category, they led with Fin and kept Intercom in the background. That wasn’t indecision—it was smart category design. Humans don’t frequently remap old concepts; we add new ones. We don’t wake up reinterpreting what a chair is, but we do invest energy to understand a new kind of drone or an intelligent software agent. New categories deserve new names, or they’ll be dragged back into old expectations.

    This is where product positioning meets competitive differentiation. Newcomers without legacy baggage enjoy a clean slate; they never have to convince the market they’ve changed because they never had an old position to defend. Even with provably superior technology, an incumbent can find itself explaining rather than advancing. I’ve led naming and repositioning work where the hardest task wasn’t shipping new capabilities—it was unseating the entrenched narrative in customers’ heads.

    So, “baggage be gone.” Fin is clearly positioned as the future of the customer agent category and is poised to become the largest part of the business. Intercom, as a product brand, very much lives on—and with “Intercom 2” now in the world, the product roadmap and investment thesis are unambiguous. The core takeaway for product management leadership: align corporate naming with your category-creating bet, then let go. That’s how you turn momentum into market leadership.

    For leaders working through similar decisions, here’s the lesson I’m taking to my own teams: rebrands aren’t about logos, they’re about narrative clarity and execution velocity. When the corporate name and the breakout product share the same story, go-to-market motions get sharper, customer understanding improves, and AI strategy integrates more naturally into customer support workflows. Naming follows strategy—not the other way around.


    Inspired by this post on The Intercom Blog.


    Book a consult png image
  • Beyond the Product Builder Hype: How AI, org design, and joy shape PM success

    Beyond the Product Builder Hype: How AI, org design, and joy shape PM success

    I recently spent time with the debate behind the "product builder" trend—asking whether it’s the future of product management or just another wave of tech FOMO. The conversation featuring Teresa Torres and Petra Wille is a useful prompt, but what matters most is how we translate these ideas into healthy product practices inside our own organizations.

    Here’s my take: the product builder movement is neither a mandate nor a fad—it’s a tool. The right question isn’t "should product managers code?" but whether leaning into building advances outcomes for our customers and our teams. In practice, that means letting interest and skill—not pressure—set the pace.

    Petra captured it perfectly: "Just because I can do it — is it something I enjoy doing? And do I have enough experience to really get into the flow?" Those two tests—joy and depth—are underrated filters. I’ve seen PMs light up when prototyping or vibe coding a thin slice, and I’ve also seen well-meaning dabbling create hidden complexity that slows everyone down later.

    Org design determines whether this works. It’s not about the tools—it’s about clarity of roles, healthy interfaces between product, design, and engineering, and explicit guardrails for where experiments stop and production begins. AI has raised the stakes: "AI can make unskilled work look polished. That’s a feature and a bug — executives see the shine, engineers inherit the mess." If you’ve ever watched a glossy demo turn into weeks of refactors, you know exactly what this looks like.

    To avoid that trap, I deliberately separate the three layers where AI is changing product work: personal productivity, team process, and product strategy. Treating these as different stacks keeps expectations clean: a prompt that accelerates personal workflows isn’t the same as an AI-enhanced process that reshapes delivery, and neither automatically produces durable product advantage. Don’t conflate them.

    Discovery remains stubbornly human. "Why discovery still requires talking to your customers (sorry)" is more than a friendly nudge. AI can broaden our search space and sharpen analysis, but it doesn’t replace qualitative conversations or the judgment that comes from pattern recognition across real customer contexts. Continuous discovery and disciplined customer interviews are still the most reliable compasses we have.

    Where does "vibe coding" fit? It’s great for roughing out concepts, de-risking slices, and communicating intent when words or static mocks won’t cut it. Tools like Claude Code make this faster than ever, and familiar stacks like Ruby on Rails lower the bar for spinning up functional prototypes. But remember the design system trap: AI can make bad decisions look good on the surface. If you don’t control for architecture, accessibility, data contracts, and handoff quality, your team pays the integration tax later.

    In well-set-up orgs, the output-oriented muscle memory gets rewired. When AI frees up time, strong teams reinvest it into better problem framing, sharper opportunity solution trees, and tighter product strategy—rather than simply chasing more output. That’s a leadership challenge, not a tooling problem, and it shows up quickly in how teams make trade-offs.

    Here’s how I operationalize this with empowered product teams: we articulate clear boundaries for prototypes versus shippable code, define decision rights for when PMs or designers "build," and align on review gates that protect quality without stifling speed. We also make the three AI layers explicit in roadmapping and retros, so improvements to personal workflows don’t get mistaken for strategic advantage.

    My distilled guidance echoes the episode’s throughline. The product builder trend isn’t a mandate — it’s a tool. Let enjoyment and skill guide who on your team leans into it. Organizational readiness determines whether AI empowers your team or creates chaos. Don’t conflate personal efficiency, process change, and product impact—they require different responses. Discovery fundamentals haven’t changed; AI helps you go deeper, not skip the work. And the real takeaway on product builders: not everyone has to build, but everyone can if they want to.

    If you want to hear the full discussion that sparked these reflections, listen on Spotify or Apple Podcasts. Then tell me: where will you apply builder energy in your team—and where will you deliberately say no?

    Resources & Links: Follow Teresa Torres: https://ProductTalk.org. Follow Petra Wille: https://Petra-Wille.com. Mentioned in this episode: Claude Code, Vibe coding, Ruby on Rails.

    One more quote I loved because it centers autonomy and craft: "It’s a tool in our toolbox. We can decide who on our team has fun with it, wants to do it, wants to contribute." That’s the mindset that sustains both momentum and morale.


    Inspired by this post on Product Talk.


    Book a consult png image
  • How a Digital Analytics Visionary Shapes My Product Strategy for Growth, Retention & Monetization

    How a Digital Analytics Visionary Shapes My Product Strategy for Growth, Retention & Monetization

    Data has always been my compass for building products that customers love and businesses depend on. Few sentences distill that imperative as crisply as the one below—and it continues to inform how I prioritize, experiment, and scale outcomes across the roadmap.

    Krista is a digital analytics leader, product strategist, and industry evangelist. She helps businesses use data to drive growth, retention, and monetization.

    That mandate mirrors how I run product: leverage behavioral analytics to uncover patterns, translate those insights into hypotheses, and validate them through rigorous A/B testing. I start by instrumenting the user journey end to end, then use cohort analysis, funnel diagnostics, and retention analysis to pinpoint where activation, engagement, or monetization is stalling. From there, I map driver trees to connect inputs (feature adoption, time-to-value, onboarding friction) to outputs (retention, conversion, revenue), so every experiment has a clear line of sight to business impact.

    On experimentation, I hold the bar high: define the minimum detectable effect (MDE) up front, ensure clean experiment design, and size samples to reduce noise. I combine Amplitude analytics with qualitative signals from continuous discovery to prioritize tests that move the needle, not just the vanity metrics. When a variant wins, I don’t stop at the lift—I track downstream effects on user activation, long-term retention, and monetization, ensuring we’re compounding gains rather than optimizing in silos.

    For product-led growth, I focus on the moments that matter most: first-value, aha, and habit formation. Journey mapping helps me identify the shortest, clearest path to value, while targeted in-app experiences and contextual nudges accelerate activation without adding friction. Every iteration feeds a learning loop—measure, learn, and ship—so we can pursue step-change outcomes, not incremental tweaks.

    Ultimately, the craft is in translating analytics into action. When teams can trace a feature idea to a specific behavioral pattern, test it with a well-powered A/B experiment, and observe durable improvements in retention and revenue, momentum takes care of itself. That’s how I operationalize data to deliver growth, retention, and monetization at scale.


    Inspired by this post on Amplitude – Best Practices.


    Book a consult png image
  • We Rebuilt Session Replay Delivery for Blazing Speed—Lighter Pages, Richer, More Reliable Data

    We Rebuilt Session Replay Delivery for Blazing Speed—Lighter Pages, Richer, More Reliable Data

    Session replay should illuminate user behavior, not slow it down. That belief drove us to rebuild the delivery layer behind our Session Replay from the ground up so it’s lighter on your pages while capturing richer, more reliable signals for behavioral analytics and product insights.

    Our objective was clear: preserve page performance and Core Web Vitals while improving data completeness under real-world conditions. We focused on reducing client-side overhead, smoothing network bursts, and scaling the pipeline so it performs consistently during long sessions, high-traffic spikes, and complex interactions—without compromising observability or user experience.

    To get there, we redesigned how events flow from the browser to our edge and storage layers. We decoupled capture from delivery, introduced adaptive batching and backpressure-aware controls, tightened compression strategies, and prioritized critical events to reduce jitter and dropped packets. The result is a delivery path that’s resilient to network variance, efficient in payload size, and friendlier to the main thread—key ingredients for platform scalability and SRE-grade reliability.

    Get a glimpse into how we overhauled Session Replay’s data delivery, and how you can expect more complete data, lower payload sizes, and more. In practice, that means steadier capture across long sessions, fewer gaps during rapid DOM changes, and leaner, faster uploads that respect the constraints of modern browsers and mobile networks. It’s an upgrade designed to protect page speed while strengthening the fidelity of what you see in replay.

    These changes elevate how product teams, analysts, and support engineers diagnose issues and optimize funnels. With higher-fidelity replay and lighter page impact, you can connect the dots faster—from anomaly detection and conversion bottlenecks to subtle UX friction—within a unified analytics platform. It’s a meaningful step forward for data-driven product strategy and for keeping your observability toolkit both accurate and performance-aware.

    While performance guided every decision, privacy and governance stayed first-class. Our delivery patterns work hand-in-hand with data governance practices to help teams maintain responsible capture boundaries while still achieving the completeness and granularity they need. This balance lets you scale replay confidently across surfaces and teams.

    We’ll continue monitoring downstream impact across Web Vitals, long tasks, error rates, and event integrity—iterating as we learn. If you rely on session replay to inform roadmaps, triage incidents, or accelerate product-led growth, you should feel the difference: a lighter footprint on your page and a stronger foundation for trustworthy insights.


    Inspired by this post on Amplitude – Best Practices.


    Book a consult png image
  • Unlocking Session Replay at Scale: How Amplitude Elevates UX, Observability, and Trust

    Unlocking Session Replay at Scale: How Amplitude Elevates UX, Observability, and Trust

    I build products to translate noisy interaction data into clear, actionable decisions. Few capabilities deliver that clarity like session replay. It closes the gap between what analytics tells us and what users actually experience, empowering product, design, and SRE teams to learn faster, resolve issues sooner, and improve customer trust.

    Lew Gordon is a Senior Staff Engineer at Amplitude focusing on Session Replay. He was formerly an engineer at Twilio.

    In my practice, session replay complements Amplitude analytics and behavioral analytics by adding rich context to the unified analytics platform—turning charts into stories we can act on. When I can see the precise clicks, hesitations, and error states behind a spike or a drop, prioritization becomes straightforward and the path to product-market fit becomes easier to navigate.

    Operationally, replay deepens observability. I correlate console errors, network traces, and layout shifts with user intent, then tie those signals to Web Vitals, performance budgets, and SRE workflows. The result is a tighter feedback loop from incident to insight—one that shortens mean time to resolution and raises the bar on reliability without guesswork.

    Privacy-by-design is non-negotiable. I start with strong data governance: selective capture and redaction, explicit consent and retention policies, role-based access, and environment-aware sampling. These controls keep sensitive data protected while still providing the fidelity product and engineering need to diagnose issues and improve experiences responsibly.

    Strategically, I deploy replay where it moves the needle most: onboarding and activation moments, high-friction conversion flows, and critical paths with outsized revenue or trust impact. I track signals like rage clicks, dead clicks, scroll depth, and error states to inform product strategy and reduce UX debt, while linking improvements to activation and retention analysis, time to resolution, and DORA metrics.

    At scale, success requires platform scalability: efficient indexing, low-latency retrieval, and smooth playback across browsers and devices—all while maintaining tight CPU, memory, and bandwidth budgets. When integrated with CI/CD and experimentation, replay becomes a force multiplier for continuous discovery and confident, rapid iteration.

    My takeaway: session replay is not just a debugging tool—it’s a shared language across product, engineering, and design. With the right guardrails and operating model, it elevates decision quality, accelerates learning, and builds the trust customers feel with every interaction.


    Inspired by this post on Amplitude – Best Practices.


    Book a consult png image
  • Taste vs. Evidence in the AI Era: What Product Leaders Must Invest In Now

    Taste vs. Evidence in the AI Era: What Product Leaders Must Invest In Now

    I just finished listening to "Taste – All Things Product Podcast with Teresa Torres & Petra Wille," and as a product leader shipping AI-powered capabilities at HighLevel, Inc., I wanted to pressure-test the sudden obsession with "taste."

    If you're curious, you can listen to this episode on Spotify or Apple Podcasts.

    The core question landed perfectly for our moment: Is "taste" the must-have skill of the AI era — or just the latest tech buzzword in a world where AI is eating through design, delivery, and discovery?

    Teresa pushes back hard, highlighting how slippery the term can be. "It's just this month's flavor of founder mode." She points out that "taste" is rarely defined, can't be easily taught, and too often becomes shorthand for "my preference trumps yours." Just as importantly, "It's not about your taste. It's about your customer's taste."

    Petra adds needed nuance from years in the craft: pattern-recognition is real, and some people do develop sharper product sense over time. As she put it, "I am a strong believer that you develop product sense and taste over time. It's never finished."

    Both threads lead back to familiar roots in product: product sense, founder mode, and the enduring myth of the lone visionary. They even grapple with the big question on everyone’s mind—Will AI Eat Taste Too?—and where that leaves product teams navigating GenAI, LLMs for product managers, and evolving product strategy.

    Here’s my take. "Taste" can be useful as a personal north star, but it is not a decision system. In my teams, we bias toward evidence: continuous discovery, customer interviews, discovery synthesis with opportunity solution trees, and tight collaboration in product trios. Opinion can start the conversation, but evidence should end it.

    Practically, that means investing in the skills that compound: Discovery skills — understanding customers, matching solutions to real needs. Human-to-human interaction skills. Learning to collaborate with AI effectively. Critical thinking and judgment grounded in evidence.

    On AI collaboration specifically, we treat GenAI as a force multiplier, not a decider. We prototype with AI to explore breadth, then narrow with qualitative and quantitative signals, ablation-style experiments, and clear success criteria. The bar I hold myself to is simple: taste without evidence is just opinion.

    Three lines I underlined from the conversation:

    "It's just this month's flavor of founder mode." — Teresa Torres

    "It's not about your taste. It's about your customer's taste." — Teresa Torres

    "I am a strong believer that you develop product sense and taste over time. It's never finished." — Petra Wille

    If you want to go deeper, these references are helpful for sharpening judgment without falling into the "great man" theory trap.

    Follow Teresa Torres: https://ProductTalk.org

    Follow Petra Wille: https://Petra-Wille.com

    Founder mode

    Marty Cagan: Founder-Style Leadership

    Vercel/v0 CEO Guillermo Rauch on building taste: from Lenny Rachitsky’s Linkedin post

    Continuous discovery (Read Teresa’s Everyone Can Do Continuous Discovery—Even You! Here’s How

    The "great man" theory

    Steve Jobs and the myth of the lone product visionary

    Have thoughts on this episode? Leave a comment below and share how your team balances product sense with evidence in the age of AI.


    Inspired by this post on Product Talk.


    Book a consult png image
  • Stop Obsessing Over the Roadmap: The High-Impact CPO Playbook for Ambition, AI, and Focus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    Inspired by this post on Amplitude – Best Practices.


    Book a consult png image
  • Scale Support with Heart: How AI Makes Every Customer Interaction Faster and More Human

    Scale Support with Heart: How AI Makes Every Customer Interaction Faster and More Human

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

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

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

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

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

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

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


    Inspired by this post on Amplitude – Perspectives.


    Book a consult png image
  • Beyond Command and Control: How I Build Trust, Speed, and Autonomy in Product Teams

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

    When uncertainty spikes, I notice many organizations snap back to "Command and control." It feels fast, safe, and decisive—especially when the stakes are high. But in product management leadership, speed without shared context is often an illusion, and control without trust rarely scales. I’ve learned that what looks like strength from the top can quietly create bottlenecks, missed signals, and disengaged teams.

    Why do smart companies revert in tough times? Familiarity. Centralizing decisions can reduce short-term cognitive load and signal clarity. Yet the cost shows up quickly: leaders become single-threaded on context they cannot possibly hold, and teams spend cycles asking for permission rather than creating value. The result is slower learning and weaker product strategy just when continuous discovery and iteration matter most.

    Here’s the hard truth: no single leader can hold all the context required to make every decision in a modern, cross-functional environment. The hidden complexity of customer segments, technical debt, data signals, and go-to-market constraints outstrips any one person’s bandwidth. That’s why empowered product teams, staffed with domain experts, outperform command centers—provided they’re aligned on outcomes and guardrails.

    I like the burning house analogy: in a true emergency, crisp direction helps—"take the stairs, not the elevator"—because the problem is clear, the time horizon is short, and the action is obvious. But most product work is not a single burning house; it’s a city with evolving fire codes, shifting weather, and neighborhoods that look different block to block. In that environment, distributed action scales better than centralized control.

    Strong leadership is not the same as command-and-control. In practice, it means setting a compelling direction, defining guardrails, and running tight feedback loops. I aim for what I call the "Flotilla of kayaks": we’re all headed to the same lighthouse, but each kayak navigates its own currents based on local information. That’s aligned autonomy—fast, resilient, and deeply accountable.

    People often ask why some command-and-control companies still succeed. My view: beneath the surface, there’s usually more trust and unofficial autonomy than their org charts suggest. Teams earn freedom by shipping reliably, sharing decision rationales, and showing outcomes. Leaders tolerate—and even quietly endorse—those pockets of autonomy because they see the results.

    It’s a spectrum, not a binary. I flex my style based on risk, reversibility, and time horizon—what I’d call spectrum thinking. Early in a bet, or when risks are existential, I raise the altitude and tighten the cadence. As confidence builds, I widen autonomy and shift the team to outcomes over outputs. Beware "Founder mode" when it drifts from vision-setting into day-to-day decision vetoes; it’s intoxicating early and suffocating at scale.

    On decision-making, I prefer a simple principle: let the person with the most relevant expertise decide, while incorporating the right input. That’s "Consultative decision-making" in practice. In some regions, you’ll hear it called "Konsultativer Einzelentscheid." The point is to seek counsel without defaulting to consensus that bogs down speed. One person owns the call, and everyone commits to the decision once it’s made.

    Practically, here’s what works for my teams: we clarify decision rights up front, draft pre-reads with clear options and risks, involve the smallest set of stakeholders required, and document the decision and expected signals ahead of time. Product trios keep discovery tight with design and engineering, while stakeholder management focuses on context, not sign-offs. We track outcomes vs output OKRs and hold regular decision reviews so we can reverse or double down fast.

    My key takeaways are consistent: "Command and control" can feel efficient, but it doesn’t scale in complex environments. No leader can hold all the context. Strong leadership is about direction, guardrails, and feedback loops—not control. High-performing teams balance autonomy with alignment. Decision-making should sit with the person closest to the problem, supported by the right input and transparent reasoning. Trust is built and earned over time—and it changes how teams operate.

    Reflection prompts I use with my leads: Where does your team sit on the command-and-control ↔ autonomy spectrum? Are the highest-context people truly making the decisions? What would it take to increase trust and autonomy—better instrumentation, clearer guardrails, or tighter cadences? Which calls require consensus, and which deserve a decisive, single-threaded owner?

    If you’re wrestling with speed, alignment, and autonomy in your organization, start small: pilot "Consultative decision-making" on one consequential decision, set explicit guardrails, and measure the outcome. You may be surprised how quickly aligned autonomy compounds into better product discovery, sharper product strategy, and stronger execution.


    Inspired by this post on Product Talk.


    Book a consult png image
  • Master Build-to-Learn: The Essential FAQ to Supercharge Product Discovery in the AI Era

    Master Build-to-Learn: The Essential FAQ to Supercharge Product Discovery in the AI Era

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

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

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

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

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

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

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

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


    Inspired by this post on SVPG.


    Book a consult png image
  • Pretotyping vs. Prototyping: How I Validate Ideas Fast and Build Products Customers Love

    Pretotyping vs. Prototyping: How I Validate Ideas Fast and Build Products Customers Love

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

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

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

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

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

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

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

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

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

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

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

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


    Inspired by this post on Product School.


    Book a consult png image