Tag: empowered product teams

  • Inside Zipline’s Wild Pivot: My Take on Hiring Heat-Seekers and Scaling to 5,000 Hospitals

    Inside Zipline’s Wild Pivot: My Take on Hiring Heat-Seekers and Scaling to 5,000 Hospitals

    I’m consistently drawn to stories where product strategy and operational grit collide to change real lives. Zipline, the world’s largest commercial autonomous delivery system, is one of those rare cases. Serving 5,000 hospitals across multiple countries and saving an estimated 17,000 lives per year, it embodies the kind of mission-driven execution I try to model in product management. The arc—from a near-dead home robot startup to a scrappy bet on drone blood delivery in Rwanda, to 135 million autonomous miles flown—offers some of the clearest lessons I’ve seen on hiring, leadership, and product-market fit under extreme constraints.

    One principle that immediately resonated with me: why Zipline doesn’t hire for experience. The idea behind “Why Zipline hires teenagers over PhDs” isn’t a dismissal of expertise; it’s a commitment to learning velocity, ownership, and unteachable hunger. The best startup employees, as described here, are “heat-seeking missiles for pain”—people who chase the hardest problems, not the shiniest projects. In my org, I look for the same signal: candidates who can move from ambiguity to action, who find the bottleneck without being asked, and who care more about outcomes than optics.

    I also appreciated the unapologetic stance that “blind references are a non-negotiable.” In high-stakes builds—especially in regulated or safety-critical categories—the cost of a mis-hire compounds. I routinely validate for two traits during references: intellectual humility and accountability. “Can candidates admit when they screwed up?” is a powerful filter. If someone can’t name a hard mistake and how they specifically changed as a result, they’re unlikely to scale with the organization.

    Equally important is clarity about who not to hire. The employees Zipline doesn’t want are those who optimize for status, process theater, or low-friction work. In practice, that means pressure-testing for problem-finding, not just problem-solving. I often design interviews around messy, cross-functional constraints (regulatory, operational, and financial) to see who can integrate tradeoffs, not just ideate features. That’s how we build empowered product teams that ship consequential outcomes, not outputs.

    There’s a reference to “Zipline’s secret leadership playbook,” and while the specifics remain private, the spirit is unmistakable: first principles decision making, ruthless focus, and a culture that rewards radical responsibility. Translating that to my product organization, I emphasize five behaviors: orient to the mission under uncertainty, run fast but close the loop with data, communicate constraints early and often, own the long tail of consequences (especially in safety and reliability), and scale judgment by teaching the why, not just the what. That blend of clarity and autonomy is the backbone of product management leadership at any growth stage.

    On the other side of the culture coin is “Why you should always fire quickly” and “The brutal firing advice that shaped Keller’s leadership.” I’ve learned (sometimes the hard way) that slow decisions erode trust and team velocity. Moving quickly doesn’t mean being harsh; it means being fair, explicit, and humane—tight feedback loops, role clarity, and decisive action when the gap persists. If your bar is clear and your coaching is consistent, acting fast protects both the mission and the team’s energy.

    Strategically, the origin story reads like a masterclass in choosing the right problem. The team moved “from toy robots to drone delivery: Zipline’s pivot,” then partnered deeply with Rwanda, where “How Rwanda’s health minister changed everything” is a pivotal moment. It wasn’t a linear climb—”How Zipline almost died – twice” and “Why Zipline’s launch was a ‘complete disaster’” underline a tough truth: breakthrough products rarely arrive fully formed. What matters is the operating cadence that turns early chaos into repeatable reliability—especially when the stakes are measured in minutes and lives.

    Scaling from 1 hospital to 5000 required more than product brilliance; it demanded systems thinking across logistics, compliance, safety, and community trust. That’s stakeholder management at its highest level. The product lessons are durable: anchor on outcomes, not artifacts; build reliability as a feature; and practice founder-led GTM where your credibility is on the line with customers and regulators. This is where first principles decision making beats benchmarking—particularly in novel categories where there are no playbooks to copy.

    There’s also a hard-nosed operational takeaway in “The 10x hardware cost rule every founder should know.” My read: assume total cost of ownership will balloon once you account for manufacturing variability, support, redundancy, maintenance, and compliance. In product strategy, I treat those multipliers as design inputs, not afterthoughts. If the unit economics can’t survive these realities, the idea isn’t ready—no matter how elegant the prototype looks in a lab.

    Across all of this, a few product management patterns stand out for me: build teams around outcomes vs output OKRs; hire for slope, not just intercept; make continuous discovery routine with real users (in this case, clinicians and health systems); and treat operational excellence as a product surface. When a mission is this consequential, culture becomes a safety system—and every leadership decision compounds into either speed with quality or speed with regret.

    For leaders building in complex domains, this journey is a blueprint: pick problems that matter, hire “heat-seeking missiles for pain,” keep blind references non-negotiable, lead with first principles, and scale with responsibility. Do that well and even a “complete disaster” launch can become the inflection point of a category-defining company that flies 135 million autonomous miles and saves 17,000 lives per year.


    Book a consult png image
  • Inside Amplitude’s AI Acquisition: Career Lessons Product Managers Can Use to 10x Impact

    Inside Amplitude’s AI Acquisition: Career Lessons Product Managers Can Use to 10x Impact

    I’m often asked how to translate early-stage experience into outsized product impact at scale. In my own practice, I study real career arcs that crystallize the habits of high-leverage product managers—especially those operating at the intersection of analytics and AI strategy.

    Consider this path: Lucas is a Product Manager at Amplitude. Previously, he was employee #1 at Command AI, acquired by Amplitude in October 2024. Lucas studied computer science at Princeton.

    What stands out to me is the compounding effect of being an early builder. When you are employee #1, you live close to the user problem, own outcomes end-to-end, and develop a bias toward focused, continuous discovery. That foundation creates durable instincts around product strategy, sharp prioritization, and empowered product teams—skills that transfer directly to later-stage environments where clarity and speed become competitive advantages.

    Acquisition integration is where those instincts meet enterprise rigor. Folding Command AI into a unified analytics platform like Amplitude requires disciplined product roadmapping and sprint planning, precise stakeholder management, and a strong POV on where AI augments core “Amplitude analytics” versus where it creates net-new value. The north star remains unchanged: deliver measurable customer outcomes that strengthen product-led growth and reduce time-to-value.

    On the AI front, I’ve seen the most successful PMs treat gen ai and LLMs for product managers as means, not ends. They anchor use cases to concrete analytics workflows—accelerating insight generation, surfacing anomaly detection, improving retention analysis, and driving user activation—while validating each step through continuous discovery and rigorous experiment design. This balance of ambition and evidence protects teams from shiny-object drift and keeps investment tethered to business impact.

    Execution-wise, the playbook is straightforward but unforgiving: clarify the problem through customer interviews; define crisp outcomes vs output OKRs; map the journey end-to-end; ship in thin slices; and iterate with observability baked into every release. Along the way, keep your cross-functional partners close—solutions engineering, customer success, and GTM—so that your learning loops extend beyond the product surface and into real adoption dynamics.

    If you’re building analytics or AI-powered experiences today, borrow these lessons: translate early-stage builder energy into enterprise-scale focus; make AI serve the product, not the other way around; and use Amplitude analytics to close the loop from idea to impact. That is how PMs compound credibility, accelerate careers, and, most importantly, create products customers can’t live without.


    Inspired by this post on Amplitude – Best Practices.


    Book a consult png image
  • Kill Your Darlings: Why I Sunset ‘Successful’ Products to Fuel Real Portfolio Growth

    Kill Your Darlings: Why I Sunset ‘Successful’ Products to Fuel Real Portfolio Growth

    There’s a moment in every product leader’s career when the bravest decision isn’t to build—it’s to stop. That’s why the “Kill Your Darlings” theme resonated so strongly with me. In this episode of All Things Product, Teresa Torres and Petra Wille dig into the courage and craft it takes to sunset products that look successful on the surface yet quietly block your path to meaningful growth. As someone accountable for portfolio outcomes, I’ve learned that disciplined endings are often the catalyst for exceptional beginnings.

    Listen to this episode on: Spotify | Apple Podcasts

    The heart of the conversation is that uncomfortable middle ground between obvious failure and runaway success: products that are profitable, loved by customers, but fundamentally flatlining. Teresa shares candid stories from her own business, including a decision to cut 40% of revenue on purpose. I’ve been there—choosing to retire a “working… kind of” product to free up discovery capacity felt risky in the moment, but it created the focus we needed for durable growth.

    Here’s the trap: some traction can be more dangerous than no traction at all. Early fans are not the same as durable product–market fit, and “stable but not growing” can lull leaders into maintaining instead of learning. Every hour of design, engineering, and go-to-market attention that props up a flatlining product is an hour not invested in the next breakthrough—an opportunity cost that rarely shows up on a dashboard, yet compounds month after month.

    From a portfolio perspective, this is continuous discovery in action. If we want empowered product teams to tackle meaningful outcomes, we have to protect their capacity from zombie work. That means setting clear thresholds for when we double down, shift strategies, or sunset—before attachment and inertia take over. When I’ve institutionalized this discipline, our throughput of high-quality bets increased, and our confidence in what not to do became a strategic advantage.

    Organization design can make sunsetting harder than it needs to be. Dedicated, long-lived teams are fantastic for compounding capability, but they also create emotional and structural ties to specific products. Petra’s point lands: leaders need explicit sunsetting conversations and a portfolio decision-making cadence that sits one level above teams. In my org, we treat sunsetting as a strategic reallocation—not a verdict on a team’s talent—so people are celebrated for learning, not punished for outcomes outside their control.

    Killing profitable products can be the right strategic move when the growth ceiling is clear and the opportunity cost is high. I’ve chosen to “burn the ships (on purpose)” more than once—retiring add-ons that generated reliable revenue but diluted our value proposition and spread discovery thin. Yes, it stings in the quarter you do it. But it’s astonishing how quickly focus restores momentum when you create intentional space for what’s next.

    Practically speaking, I make sunsetting easier and less traumatic by operationalizing it: Regular portfolio reviews focused on outcomes and opportunity cost; a visible “sunsetting” column so everyone sees what’s on the table; the Horizon (H1 / H2 / H3) model to balance core, adjacent, and transformational bets; and making portfolio decisions one level above teams to avoid local optimizations. Add explicit exit criteria and success metrics for endings, the same way we set entry criteria for new bets.

    Another theme I appreciated is designing for the right customers. Teresa highlights intentionally limiting access and pricing to work with customers who show agency and commitment. I’ve applied the same principle: when we’re clear about who we serve and who we don’t, our product–market signal sharpens, churn narratives simplify, and roadmaps get crisper. Focus is a growth strategy.

    If you’re leading a product portfolio, running discovery, or wrestling with a product that “works… kind of,” this conversation is permission to act. Product–market fit isn’t binary, and mediocre success can be the most dangerous place to stay. Sunsetting is a portfolio decision, not a team failure; teams shouldn’t be punished for reaching the end of a product’s natural lifecycle. If experimentation isn’t in your DNA, killing products will always feel traumatic—so make space for it intentionally, not passively.

    Key moments and themes worth bookmarking: 00:00 – Why “kill your darlings” matters; 04:30 – The dangerous middle ground; 09:30 – The opportunity cost of “okay” products; 14:30 – Sunsetting in product organizations; 19:00 – Real examples of killing revenue streams; 28:00 – Designing for the right customers; 33:30 – Burn the ships (on purpose); 38:00 – Making sunsetting easier with Regular portfolio reviews, a visible “sunsetting” column, the Horizon (H1 / H2 / H3) model, and making portfolio decisions one level above teams; 46:00 – Normalizing product lifecycles.

    Resources & Links:

    Follow Teresa Torres: https://ProductTalk.org

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

    Mentioned in this episode:

    Ways to Work with Petra Wille

    Product at Heart

    CDH Membership by Teresa Torres

    Product Talk by Teresa

    Product Talk Academy by Teresa

    Enduring Ideas: The three horizons of growth

    Join the Conversation:

    Have thoughts on this episode? Leave a comment below.

    Full Transcript

    Full transcripts are only available for paid subscribers.


    Inspired by this post on Product Talk.


    Book a consult png image
  • Lost in the Woods: 5 Survival Patterns Every Product Leader Must Master Now

    Lost in the Woods: 5 Survival Patterns Every Product Leader Must Master Now

    Ever feel like your product team is “lost in the woods”? I’ve certainly been there—when strategy gets fuzzy, outcomes drift, or constraints aren’t clear. What helped me reframe the chaos was borrowing “lost person” patterns from search-and-rescue and mapping them to product strategy, product discovery, and team behaviors. The result is a practical playbook for product management leadership that keeps empowered product teams moving toward outcomes—not just outputs.

    Listen to this episode on: Spotify | Apple Podcasts

    Here are the five patterns I see most often—and how I turn each one into forward motion: settle in place (freeze), chase shortcuts, follow the first visible path, use your own navigation (intuition/taste), and retrace your steps. Each of these has a smart, minimal move that helps teams reorient fast without abandoning continuous discovery or product strategy discipline.

    Settle in place (freeze). Sometimes the smartest move is to stop. When my team lacks context or authority, I pause delivery work and escalate instead of improvising fixes. This prevents thrash, protects focus, and creates the air cover we need to realign outcomes vs output OKRs.

    Chase shortcuts. Shortcuts can be brilliant—or overconfident. I’ve learned to pressure-test whether the “road” is where we think it is before we commit. That means lightweight experiments, clear exit criteria, and the humility to pivot. Think about big bets like Spotify podcasts: compelling vision, but you still have to validate assumptions step by step.

    Follow the first visible path. The obvious option isn’t always the best one. My job as a product leader is to make multiple paths visible before we choose. I lean on opportunity solution trees and KPI trees (or driver trees) to surface alternatives, align stakeholders, and keep empowered product teams focused on customer impact and product-market fit—not just the loudest idea.

    Use your own navigation (intuition/taste). Judgment matters, especially for product trios making fast calls—but it’s not a replacement for evidence. When my “compass” conflicts with what we observe, I anchor back to customer interviews, rapid tests, and discovery loops. Intuition should guide where we look, while data validates how we proceed.

    Retrace your steps. When we’re drifting, I go back to what used to work: principles, quality practices, and discovery habits as feedback loops. Returning to fundamentals—clear problem statements, crisp value propositions, and disciplined outcomes—rebuilds momentum fast.

    Team prompt to try: If your team is “lost” right now, which pattern are you defaulting to—and what’s the smallest move you can make this week to get oriented (escalate, test a shortcut, map options, validate intuition with evidence, or retrace to a principle)? I use this question in weekly reviews to keep us grounded in continuous discovery and product strategy.

    Resources & Links:

    Follow Teresa Torres: https://ProductTalk.org

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

    Mentioned in the episode:

    Lost Person Behavior: A Search and Rescue Guide on Where to Look – for Land, Air and Water

    Robert J. Koester

    Examples referenced: Xerox, Nokia, Kodak, Volkswagen emissions scandal, Spotify podcasts, large-org tooling contexts like Oracle and SAP

    Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes

    KPI Trees: How to Bridge the Gap Between Customer Behavior, Product Metrics, and Company Goals

    Let's Read Continuous Discovery Habits Together (January 2026) for Continuous Discovery Habits (and the idea of habits as feedback loops)

    Shifting from Outputs to Outcomes: Why It Matters and How to Get Started

    I’d love to hear how your team navigates these patterns. Which small move will you try this week? Leave a comment below and let’s compare notes on product discovery, stakeholder management, and product roadmapping that actually drives outcomes.


    Inspired by this post on Product Talk.


    Book a consult png image
  • March CDH Book Club: Master Experience Mapping to Align Teams and Accelerate Discovery

    March CDH Book Club: Master Experience Mapping to Align Teams and Accelerate Discovery

    I’m thrilled to invite you to our March session of the CDH Book Club. Continuous Discovery Habits turns five this year. And to celebrate we are reading the book together. I’ve seen firsthand—leading product trios and empowered product teams—that sharpening our discovery habits is the fastest way to better outcomes vs output OKRs, tighter team alignment, and more confident product strategy.

    Each month, I am releasing an in-depth reading guide that includes:

    The chapters we will be reading

    A preview of the most important concepts we'll be learning about

    Short videos you can share with friends and colleagues to help spread the ideas

    Individual and team discussion questions to help you absorb and engage with the reading

    Team exercises to help you put the ideas into practice

    Additional reading to help you go deeper on the core ideas

    We’ll be discussing each month’s reading in the comment section and we’ll gather quarterly to discuss on a live call. I’ll be there to trade notes, compare experience maps, and share what’s working across product discovery practices.

    Joining late? No problem. I monitor the comments on each reading guide throughout the year. Start with the current month or go back to January—whatever works for you. You can ask for help, share what’s working, and connect with other readers at any point.

    If you want to participate, grab a copy of the book (or dig up your old copy), share the "Spread the Love" videos, reserve some time to do the team exercises, and register for the community sessions. Let’s do this!

    This Month’s Reading

    Chapters:

    Chapter 4: Visualizing What You Already Know

    Estimated reading time: ~14 minutes

    This chapter will introduce you to:

    Why starting individually—rather than as a group—is the fastest path to unlocking your team’s collective intelligence

    How drawing (even badly) forces you to get specific in ways that words never will

    The strategic choice of setting your experience map’s scope—too narrow and you miss opportunities, too broad and you lose focus

    How diverse perspectives become your team’s secret weapon when you know how to synthesize them

    Why your first experience map isn’t truth—it’s a hypothesis you’ll test and evolve with every customer conversation

    Need a copy? Grab the book.

    Share the Love with Friends and Colleagues

    We learn best in community. Use the following short videos to share the key concepts from this chapter with friends and colleagues. Invite them to participate in the book club with you. In my teams, these quick hits help us align faster before we co-create an experience map or opportunity solution tree.

    Visualize your thinking – To bring others along

    Unlock team alignment – With visualizations

    Reflect & Discuss What You Read

    When we reflect and discuss what we read, we absorb more of the material. It helps us put what we learn into practice. Don’t skip this step. In my own practice, the real unlock came when I treated mapping as a living artifact that shapes customer interviews, not a one-off deliverable.

    Most of us believe we work collaboratively, but we’ve never truly experienced what it means to build shared understanding from diverse perspectives. This chapter challenges you to get uncomfortable—to draw when you’d rather talk, to work alone before working together, and to see your maps as living documents rather than one-time deliverables.

    Individual Reflection

    Think about the last time your team tried to align on what you know about your customers. Did everyone start by creating their own perspective first, or did you jump straight into a group discussion? What happened as a result?

    When was the last time you drew something at work? What stops you from using drawing as a thinking tool—is it discomfort with your drawing skills, lack of time, or something else?

    Look at your current work. If you were to create an experience map right now, what scope would you choose? How does your desired outcome help you determine what to include and what to leave out?

    Team Discussion

    As a trio, each person should identify one unique perspective they bring to your team’s understanding of your customer. How might these different viewpoints create blind spots if you only relied on one person’s view?

    When your team disagrees about what customers need or want, how do you typically resolve it? Do you debate until someone wins, defer to the most senior person, or test your different hypotheses?

    Does your team have a current experience map? If so, when was the last time you updated it based on what you’re learning from customers? If not, what’s preventing you from creating one?

    Put It Into Practice

    Understanding why experience maps matter is different from actually creating one that drives your discovery work. These exercises will help you practice the discipline of starting individually, synthesizing diverse perspectives, and using your map to guide customer conversations. My suggestion: timebox, embrace imperfect drawings, and let the artifact lead your next interview script.

    Exercise: Create Your Individual Experience Maps

    Time: 20 minutes individually, 45–60 minutes with your team

    Do this: Individually first, then share with your trio

    Start by agreeing on the scope of your experience map based on your current outcome. Each member of your trio should then independently create their own experience map using pen and paper (or your favorite digital drawing tool).

    Focus on drawing the customer’s experience, not your product’s features. Where do they get stuck? What goes wrong? How do they work around problems? Don’t worry about drawing well—boxes, arrows, and stick figures are perfectly fine.

    Once everyone has created their individual maps, schedule time to share them with each other. As you explore each person’s perspective, ask questions to understand their thinking. Pay particular attention to the differences between maps—this is where the richest insights emerge.

    Exercise: Co-Create Your Shared Experience Map

    Time: 30 minutes with your team

    Do this: With your product trio

    Bring your individual experience maps together and work to synthesize them into a single shared map. Start by identifying all the unique nodes (distinct moments, actions, or events) across all three maps. Arrange them in a comprehensive flow.

    Collapse similar nodes, but be careful not to overgeneralize. Add links to show relationships and flow between nodes—including loops, error cases, and abandonment points. Finally, add context about what customers are thinking, feeling, and doing at each step.

    As you work, avoid getting bogged down in endless debate. If you disagree about details, draw out the difference rather than debating it. This often reveals you already agree or helps you pinpoint exactly where your understanding differs.

    Remember: This map is your current hypothesis about your customer’s experience. Use it to guide your upcoming customer interviews and plan to evolve it based on what you learn.

    Go Deeper: Additional Reading

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

    Supplementary Reading

    Why Drawing Maps Sharpens Your Thinking

    Core Concept: Collaborative Decision-Making in a Product Trio

    Other Voices

    To Draw or Not to Draw: Is Traditional Sketching Still Relevant in the Digital Design Era? by Julia Ku

    Journey-Mapping Approaches: 2 Critical Decisions to Make Before You Begin by Kate Kaplan

    The Visual Language of Comic Books Can Improve Brain Health by Mary Widdicks

    Mapping Your User’s Day with the User Clock Sketch by Ben Crothers

    Our Live Discussion Schedule

    Our live discussion sessions are for paid subscribers. Sessions are not recorded. Invitations will go out to Supporting Members and CDH Members two weeks before the scheduled event. But reserve the time on your calendar now.

    Wednesday, March 18, 2026: 9am–10am PDT and 4pm–5pm PDT

    Tuesday, June 16, 2026: 9am–10am PDT and 4pm–5pm PDT

    Thursday, September 17, 2026: 9am–10am PDT and 4pm–5pm PDT

    Wednesday, December 16, 2026: 9am–10am PST and 4pm–5pm PST

    Audio Summary

    This summary was produced by NotebookLM. The sources supplied were the book chapters as well as all of the additional reading.

    Listen here: March — Draw the User Clock to Build Empathy (audio)

    This article is part of the CDH Book Club celebrating the five-year anniversary of Continuous Discovery Habits. See all book club posts.


    Inspired by this post on Product Talk.


    Book a consult png image
  • Stop Blurring the Lines: Clear Product–Engineering Boundaries to Boost Quality and Prevent Burnout

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

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

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

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

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

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

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

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

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

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


    Inspired by this post on Product Talk.


    Book a consult png image
  • Human-in-the-Loop Mastery: Proven Oversight Tactics That Elevate AI Quality and Trust

    Human-in-the-Loop Mastery: Proven Oversight Tactics That Elevate AI Quality and Trust

    Human-in-the-loop oversight is the fastest and most reliable way I know to elevate AI quality, build user trust, and reduce risk. At HighLevel, my teams treat oversight as a product feature—not an afterthought—because dependable AI experiences come from deliberate design choices across data, models, and people.

    When I say “human-in-the-loop,” I mean a system that blends automation with targeted human judgment at key moments: during data curation, prompt engineering, evaluation, deployment, and post-launch learning. This approach turns “AI workflows” into measurable, repeatable processes and keeps me honest about what’s working, what’s drifting, and where a human safety net must step in.

    Architecturally, I start with a retrieval-first pipeline to ground outputs in trusted knowledge, then wrap it in guardrails. Deterministic preprocessing, careful prompt engineering, and post-processing validators catch obvious failure modes. Confidence thresholds and policy checks route ambiguous or sensitive cases to a human reviewer, while clear, auditable traces show why the system chose automation versus escalation. This balance supports reliability at scale while preserving agility for “agentic AI” patterns when they add value.

    Quality is only real if I can measure it, so I build with eval-driven development from day one. I maintain golden datasets, rubric-based scoring guidelines, and an automated evaluation harness that runs on every change to prompts, models, or data. Pre-production gates protect against regressions, while production telemetry surfaces drift by segment and use case. When it’s time to run experiments, I use A/B tests sized with a minimum detectable effect (MDE) to avoid overfitting to noise.

    Operationally, I optimize for outcomes, not output. I track task success rate, time-to-resolution, safety violation rate, hallucination rate, and cost-to-serve, then connect these to outcomes vs output OKRs. The signal I want is simple: are we reliably solving the user’s job-to-be-done with lower effort and higher confidence? If not, I tighten prompts, refine retrieval, or expand human review where it pays off most.

    Risk governance is non-negotiable. I design with privacy-by-design and data governance from the start—role-based access, audit trails, PII redaction, and red-team tests for safety. Clear reviewer playbooks and calibration sessions reduce bias and ensure consistent decisions. These practices aren’t bureaucracy; they’re how I operationalize AI risk management while maintaining velocity.

    Teams make or break this model. I empower product trios to own the full lifecycle—discovery, build, and learning—so feedback loops close quickly. In-product feedback widgets, reviewer queues, and incident management playbooks help us respond in hours, not weeks. Over time, human review becomes a targeted scalpel rather than a blanket requirement as the system learns and improves.

    Economics guide the level of oversight. I treat each workflow like a portfolio: where the value of accuracy is high and ambiguity is common, I route more to humans; where tasks are simple, frequent, and well-bounded, I automate aggressively. The goal isn’t zero humans—it’s optimal humans, deployed precisely where their judgment compounds ROI.

    If you’re getting started, begin with one high-impact workflow, establish your golden set and evaluation rubric, and wire in a simple review queue. Prove the lift, then scale. In the short video above, I walk through the patterns I use to design these loops, measure quality with rigor, and ship AI that teams—and customers—can trust.


    Inspired by this post on Product School.


    Book a consult png image
  • Why “Figma Is Not the Source of Truth”: My Playbook for Design Leadership That Scales

    Why “Figma Is Not the Source of Truth”: My Playbook for Design Leadership That Scales

    I keep a simple mantra front and center: Figma is not the source of truth. The customer is. In practice, that means the only thing that truly counts is what we ship, how it performs, and whether users come back for more. Mockups are hypotheses; production usage is evidence. When my teams adopt this lens, velocity improves, judgment sharpens, and quality rises where it matters most.

    So what does design actually do in a software company? At its best, design builds leverage for the whole system—engineering, product, and marketing—by clarifying problems, raising the quality bar, and making complex decisions legible. The standard I hold is ancient and still essential: products must be useful, usable, and desirable — and above all, used. When we calibrate around “used,” debates about pixels give way to outcomes, and cross-functional partners feel the difference.

    I often trace the roots of our craft back well beyond the digital era. The lineage from industrial design to software is real; constraints, ergonomics, affordances, and systems thinking didn’t start with screens. If you’ve ever mapped delight, performance, and reliability in a Kano Model, you’ve touched this lineage. The translation to software is simple: design the full journey, not just the interface—prioritize what improves time-to-value, reduces cognitive load, and earns habitual use.

    One lesson I’ve learned the hard way: why design leaders who stop designing stop leading. I still sketch flows, write UX copy, and prototype when it unblocks the team or sets a decisive quality bar. The altitude changes constantly—one hour I’m in a strategic roadmap review, the next I’m in a critique or poking at a prototype. Great design leaders jump up and down in altitude to connect vision to details without becoming a bottleneck.

    Over time, I’ve come to rely on four pillars every design manager must master: craft (raising taste and execution), product strategy (clarifying choices and trade-offs), people leadership (coaching, feedback, and hiring), and systems (processes, rituals, and design ops that scale). Neglect any one of these and either quality, speed, or team health will eventually falter.

    Perfectionism is a double-edged sword. Over-indexing on quality can paralyze decision-making, but lowering the bar indiscriminately is worse. I’ve seen moments where relaxing standards to “go faster” actually cost the business—rework piled up, trust eroded, and customer value stalled. The answer is principled delegation: I define what “must be true” at each milestone, delegate ownership with clear guardrails, and reserve my veto power for moments where product integrity is genuinely at risk.

    Measuring success as a design leader starts with outcomes vs output OKRs. I care about activation, retention, time-to-first-value, NPS verbatims tied to key journeys, and the operational metrics that earn the right to build the next thing. Design output is visible; design outcomes are durable. When trade-offs are needed, I optimize for the smallest shippable surface that still proves the core value proposition, then expand with data.

    Scaling judgment is the multiplier. I build it through pattern matching—studying enduring product systems from companies like Airbnb, Amazon, Apple, Asana, Notion, Stripe, Nest, and others—to distinguish where polish compels usage versus where it’s ornamental. Strong opinions matter, but so does being easy to convince with new evidence. I encourage designers to articulate the pattern they’re invoking, why it fits the job-to-be-done, and how we’ll know it worked.

    Operating cadence matters. My week is anchored around recruiting, crits, and staff meetings that actually make decisions. In critiques, I use the Do/Try/Consider framework to give actionable direction without micromanaging. On one-on-ones, the question isn’t “Should one-on-ones exist?” but “What are they for right now?”—coaching, performance, or clearing execution blockers. If a meeting doesn’t increase clarity or commitment, it gets redesigned or removed.

    Execution-wise, I’ve taken inspiration from Rippling’s operating system—especially its emphasis on speed, precise ownership, and hard commitments. The lesson is timeless: go fast on the right things, make clear promises, and instrument your work so you can see reality quickly. When speed is paired with crisp decision rights and observable outcomes, momentum compounds rather than frays trust.

    Hiring your first design leader? Look for someone who can set standards, scale judgment, and ship. They should be able to zoom from company narrative to interaction copy in a single afternoon, coach product trios, and build rituals that make taste and trade-offs explicit. Above all, they should have a point of view on where quality moves the business and where speed is the quality.

    Here’s how my team’s approach differs from many: Figma is not the source of truth. We design in Figma, but we learn from production. We pair designers with engineering early, prototype in code when it reduces risk, and wire telemetry into every critical path. Product trios use discovery to validate “useful, usable, desirable — and used,” then commit to outcomes with clear, testable definitions of success. The result is faster iteration, fewer surprises, and experiences customers actually adopt.

    If you want to deepen your own pattern library, study products and practices from leaders like Airbnb (https://www.airbnb.com/), Amazon (https://www.amazon.com/), Apple (https://www.apple.com/), Asana (https://www.asana.com/), CrossFit (https://www.crossfit.com/), Figma (https://www.figma.com/), Honeywell (https://www.honeywell.com/), Nest (https://store.google.com/category/google_nest), Notion (https://www.notion.so/), Retool (https://retool.com/), Rippling (https://www.rippling.com/), and Stripe (https://www.stripe.com/). Pay attention to how they balance versatility with clarity, defaults with flexibility, and speed with trust.

    The throughline is simple and demanding: design for reality, not for the board. Keep your standards where they create business value, scale judgment with explicit patterns, and instrument everything so learning never stops. When teams embrace that, the work gets better, customers feel it, and the roadmap starts to pull you forward.


    Book a consult png image
  • Stop Groupthink in Hiring: Proven Product-Led Tactics to Make Faster, Fairer Decisions

    Stop Groupthink in Hiring: Proven Product-Led Tactics to Make Faster, Fairer Decisions

    Is hiring broken—or just badly designed? I’ve been sitting with that question after a recent conversation that crystallized what I see across product organizations: AI-fueled application overload, sprawling interview loops, and fuzzy criteria that invite groupthink at exactly the wrong moments. If you’ve ever watched a promising candidate stall out late in the process, you’re not alone. Listen to this episode on: Spotify | Apple Podcasts.

    Here’s the reality I’m observing in the market: Layoffs and hiring freezes have flooded the funnel, while AI tools make it trivial to submit hundreds of applications. Companies are overwhelmed, so they respond by adding more interviews and more stakeholders, hoping more touchpoints equal better signal. In practice, that complexity often dilutes accountability and increases noise—especially for product management leadership roles where clarity, not consensus theater, determines success.

    I’ve seen too many offers derailed by “one last step.” A candidate clears every structured interview, then a casual lunch or unframed panel suddenly becomes the deciding factor. The team isn’t briefed on what to evaluate, one lukewarm comment lands, and group dynamics cascade into a no-hire. That’s not rigor—it’s randomness masked as prudence.

    Groupthink ≠ good hiring decisions. When everyone has veto power, risk-averse no-decisions become the default. Focus-group-style interviews create bias, not signal, and “culture fit” often becomes a proxy for stereotyping or personal preference. As product leaders, we’d never ship a feature based on vibes; we shouldn’t make high-stakes hiring calls that way either.

    There’s a better way—and it mirrors how we run great product discovery. Define who you’re hiring before writing the job description. Set clear success metrics for the role. Assign each interviewer specific criteria to evaluate. Treat hiring like product discovery: intentional, structured, and evidence-based. In my teams, that looks like tight scorecards, interviewer calibration, and a decision owner who synthesizes evidence—not a popularity contest where the loudest voice wins.

    Chemistry checks still matter, but only when we define what collaboration actually means for the role. Introversion, debate style, or lunch-table small talk are not performance indicators. I look for behaviors we value in empowered product teams—clarity of thinking, healthy dissent, co-creation under constraints—often via a real working session with the future product trio. Diverse teams outperform homogenous ones, even if not everyone “vibes,” so I optimize for complementary strengths over sameness.

    If you’re a candidate, remember: When a process feels broken, it’s often not about you. Ask how you’re being evaluated to gauge process maturity; a thoughtful team will happily walk you through their rubric and what great looks like. For structure and support, I’ve seen “Who: The A Method for Hiring” help leaders clarify requirements; “Never Search Alone” and joining a Job Search Council (JSC) can give you peer accountability and sharper narratives. For current openings, I regularly point PMs to Scott Baldwin’s PM job postings on LinkedIn.

    My challenge to fellow product leaders: Audit your hiring process the way you’d audit your roadmap. Where are decisions getting stuck? Where are you over-indexing on consensus and under-indexing on evidence? Tighten the criteria, streamline stakeholders, and instrument the funnel so you can learn and improve. The payoff is faster, fairer, more confident decisions—and teams that reflect the rigor we expect in product strategy and stakeholder management.

    What’s one change you can make this week—reworking the scorecard, calibrating interviewers, or replacing an unstructured lunch with a real collaboration exercise? Small improvements compound. Let’s build hiring systems that are worthy of the talent we’re trying to attract.


    Inspired by this post on Product Talk.


    Book a consult png image
  • Stop Measuring Output, Start Driving Outcomes: My February CDH Book Club Guide

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

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

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

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

    This Month’s Reading

    Chapters: Chapter 3: Focusing on Outcomes Over Outputs

    Estimated reading time: ~22 minutes

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

    Share the Love with Friends and Colleagues

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

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

    Reflect and Discuss What You Read

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

    Individual Reflection

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

    Team Discussion

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

    Put It Into Practice

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

    Exercise: Map Your Revenue Model

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

    Exercise: Audit Your Current Outcome

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

    Go Deeper: Additional Reading

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

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

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

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

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

    Our Live Discussion Schedule

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

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

    Audio Summary

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

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


    Inspired by this post on Product Talk.


    Book a consult png image
  • Inside Product at Heart 2026: Bold Single-Track Vision, AI Everywhere, Deeper Connections

    Inside Product at Heart 2026: Bold Single-Track Vision, AI Everywhere, Deeper Connections

    I just tuned into the latest conversation on the upcoming Product at Heart 2026, and it hit on the exact challenges product leaders are navigating right now: curating meaningful content in a world where AI moves faster than our agendas, designing formats that create real connection, and ensuring every minute earns its place. Listening to Petra Wille and Teresa Torres map out the speaker lineup, workshops, and structural shifts, I found myself nodding along—this is the kind of thoughtful curation we need if we want product teams and product leaders to walk away with practical value, not just inspiration.

    Listen to this episode on: Spotify | Apple Podcasts

    What stood out immediately is the bold move to a single-track conference for 2026. In an era of gen ai hype and endless breakouts, this choice signals clear intent: tighter curation, a shared experience, and less FOMO. The team isn’t carving out a separate AI track—and I love that decision. Their stance is simple and sensible: No AI track—AI will show up everywhere, but not as a siloed topic. The team sees it as part of the everyday toolkit. That mirrors how high-performing, empowered product teams actually work today—AI Strategy and AI workflows are part of the operating system, not a side show.

    The keynote lineup is already compelling. Christian Idiodi (SVPG) brings storytelling that turns product principles into habits you can actually use on Monday. Elaine Kasket, cyber-psychologist, exploring digital afterlife and AI replicas, will push us to think more deeply about the human side of our systems. And Teresa Torres will be sharing what she’s learning about AI—exactly the kind of continuous discovery mindset we need as we integrate LLMs into product discovery and delivery.

    I’m also thrilled to see roundtables become what they’re calling an “alternative track.” That’s a smart way to deepen learning without fragmenting attention. The best conference ROI I’ve had often comes from targeted small-group conversations—where product trios compare approaches, swap metrics frameworks, or challenge each other’s product strategy assumptions. It’s a design choice that rewards curiosity and builds communities of practice.

    We also get a behind-the-scenes look at Teresa’s Maker Studio workshop, where participants will build personal AI workflows. That’s exactly the hands-on, practitioner-first approach teams need right now—less demo theater, more systems that stick. If your roadmap includes integrating LLMs into continuous discovery or augmenting your team’s decision velocity, this kind of guided practice is gold.

    The broader workshop slate looks deep and balanced. Expect returning favorites and practical frameworks: Rich Mironov on the realities of product leadership in complex orgs; Büşra’s metrics workshop translating outcomes into action; and an overview of additional workshops from Rich Mironov, Büşra Coşkuner, Marcus Castenfors, and Özlem Yüce. From success metrics to toolkits for product managers, the content spans IC to product management leadership—ideal if you’re stepping into new roles or scaling empowered product teams.

    One of the most exciting evolutions is the Product Leadership Event, now a 1.5-day retreat. The format blends talk sessions, mini-workshops, dinners, and small-group excursions (boat rides, improv, etc.), giving leaders time and space to exchange playbooks, stress-test decisions, and build real relationships. It’s capped at 60 attendees (all in product leadership roles) to keep it intimate and useful. As someone who believes in outcomes vs output OKRs and first principles decision making, I appreciate how this structure encourages depth over breadth—and real accountability among peers.

    Here are the core takeaways I’m carrying into my own planning: single-track means tighter curation, so every talk has to earn its place. Roundtables are growing into an “alternative track,” offering more ways to engage beyond stage talks. Workshops go deep and meet you where you are—IC, manager, or executive. And the leadership retreat expands to maximize learning from peers, not just from the stage. If you care about product discovery, product strategy, and conference networking that leads to actual business impact, this program looks thoughtfully engineered.

    If you’re planning your 2026 calendar—or just curious how conferences evolve alongside the craft—this is a thoughtful walkthrough of what to expect. Come say hi to Teresa and Petra—on stage, at a roundtable, or somewhere in the hallway conversations that make these events memorable.

    For more context and resources mentioned, explore: Product at Heart, Arne Kittler, Mind the Product, Christian Idiodi of Silicon Valley Product Group, Elaine Kasket, House of Beautiful Business, The 7 Habits of Highly Effective People by Stephen Covey, Rich Mironov, Marty Cagan, Claude Code, Codex by OpenAI, Marcus Castenfors, Büşra Coşkuner and her Success Metrics: A Playbook for Product Managers, Özlem Yüce’s Essential Toolkit for Product Managers, Petra’s Product Leadership Wheel (PLwheel), and Netlight.

    Follow Teresa Torres: https://ProductTalk.org

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

    Full transcripts are only available for paid subscribers.


    Inspired by this post on Product Talk.


    Book a consult png image
  • How I Harness AI to Supercharge Product Discovery for Faster Research, Prototyping, and Validation

    How I Harness AI to Supercharge Product Discovery for Faster Research, Prototyping, and Validation

    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.


    Inspired by this post on Product School.


    Book a consult png image