Tag: outcomes vs output OKRs

  • 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
  • How I Used Claude Code to Run a Full Content Audit in Hours—and Uncovered Big SEO Wins

    How I Used Claude Code to Run a Full Content Audit in Hours—and Uncovered Big SEO Wins

    Can an AI agent actually run a credible content audit end to end? I put that to the test. In my role leading product at a high-growth SaaS and as a hands-on content strategist, I’m constantly balancing depth with reach. During a recent office-hours discussion, someone asked me to zoom out and explain when to use Claude Code. That prompt inspired me to launch a running series—Conversations with Claude—showing exactly how I apply it to real product management and SEO problems.

    I’m a heavy user and share what works for me. I receive no compensation from Anthropic for this series; if that ever changes, I’ll disclose it. With that out of the way, let’s dive into how I had Claude conduct a full content audit—and why the results exceeded my expectations.

    For the first installment, I chose a fairly complex use case: a comprehensive content audit of my site. I expected this to be a slog. Instead, it was refreshingly fast and rigorous once I set Claude up with the right scaffolding.

    I kicked off with a simple directive: start by asking clarifying questions, proceed step by step, and capture notes in a shared task file. I also provided deep context—specifically, the CDH Book (15 chapters + intro) and my entire blog archive in markdown—so the model could reason with my actual corpus rather than guessing from sparse prompts.

    Claude began with smart clarifying questions that framed the analysis well. Scope of keywords: Should it focus strictly on concepts unique to or heavily associated with my work like "opportunity solution tree" and "continuous discovery," or also include broader product management terms such as "product outcomes," "assumption testing," and "customer interviewing"? Keyword geography: Start with US-only or include UK/global? Blog coverage assessment: What counts as "well covered"—dedicated deep dives or credible coverage within broader posts? Output format: Add findings to the task file or create a separate deliverable?

    Dark-mode notes workspace titled content-audit showing task properties (type: task, due 03/06/2026, tags product-talk and content) and step-by-step instructions for a content audit.
    Peek inside a Notion-style page that turns content strategy into action: a content-audit task with due date and tags, plus clear steps for keyword research, blog gap analysis, and SEO improvements.

    I replied: 1. both 2. us only is a good place to start 3. evaluate this based on how well we rank for the keyword, if we rank reasonably well, you might suggest content improvements to rank better, if we don't rank at all, then you might suggest a whole new article 4. add to the task file

    From there, Claude read the CDH Book, extracted roughly 100 keywords, ran them through Keywords Everywhere in two batches of 50 to capture search volume, and pulled current domain rankings and traffic metrics. Within minutes, I had a high-signal view of what’s working, where we’re invisible, and how to prioritize fixes.

    The good news came first: we own our branded terms—#1 for "product discovery," "opportunity solution tree," "continuous discovery," and "product trio." That brand equity is doing real work for us.

    The biggest gaps were in broad topics the CDH Book covers but where there’s no targeted content. "Outcomes vs outputs" (1,300/mo) — Arguably THE central thesis of CDH, and no ranking. This is the single biggest gap. "Product roadmap" (4,400/mo) — I have a strong anti-roadmap POV but no content targeting this. "Product strategy" (1,900/mo) — Ch 7 argues strategy = opportunity selection. Strong differentiator, no ranking. "Story mapping" (5,400/mo) — I use story maps uniquely (for surfacing assumptions). Huge volume. "Stakeholder management" (2,900/mo) — Ch 13 is entirely about this. No ranking. "Pre-mortem" (4,400/mo) — I cover this as a product discovery technique. No ranking.

    Dark-mode markdown editor shows a chapter titled 'The What and Why of Continuous Discovery' and a left sidebar of organized folders and notes, indicating a structured, searchable content library.
    Inside a dark-themed writing workspace, a long-form chapter is open while a tidy folder tree catalogs pages and chapters. The scene invites readers to think like auditors—inventory content, track structure, and surface gaps with AI assistance.

    The trojan horse opportunity: High-volume generic terms like story mapping, pre-mortem, and usability testing could bring in readers who don't know about CDH yet. Write about these broadly-searched topics with my specific product-discovery angle.

    In just a few minutes, Claude generated an analysis of what keywords we ranked for and at what position, a ranked set of high-, medium-, and lower-volume (but strategic) keywords where we didn’t rank yet had relevant content, concrete net-new topics to close the gaps, and a list of existing articles to update to lift their SERP positions. It worked far better than I expected.

    Here’s how I set it up so the model could deliver: I didn’t simply ask Claude.ai to "audit my site" and hope for the best. I supplied rich, relevant context (my book and all blog posts as markdown) so it could anchor on my language, frameworks, and mental models. I paired that with live data via APIs like Keywords Everywhere to ground recommendations in actual search volume and competitive rankings. With the right inputs, Claude Code behaved like a capable research analyst and an SEO strategist—able to reason, prioritize, and suggest high-leverage actions.

    Next, I went deeper and used the findings to draft a long-form article that addresses the biggest gap—"Outcomes vs outputs"—and ties it directly to product roadmapping and sprint planning. I wove in continuous discovery practices, opportunity solution tree techniques, and product trios collaboration to make it actionable for empowered product teams. I’ll share the end-to-end workflow—including files, prompts, and the editorial QA checklist—in a follow-up.

    If you’re new to Claude Code and want a practical starting point, replicate the setup above: assemble your canonical sources in markdown, define a clear evaluation rubric, and ground keyword research with reliable volume data. If you want my exact task file, clarifying-question template, and step-by-step audit rubric, tell me which content gap you’d prioritize first and why—I’ll tailor the walkthrough to the highest-interest topic.


    Inspired by this post on Product Talk.


    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
  • Prevent Strategy Drift: AI that flags ‘merge conflicts’ in product plans before a quarter derails

    Prevent Strategy Drift: AI that flags ‘merge conflicts’ in product plans before a quarter derails

    "What if an AI could spot the moment two product teams start pulling in opposite directions — before it derails a quarter?" That question hooked me, because I’ve lived through the costly fallout of subtle misalignments that only surface at the end of a sprint—or worse, during quarterly business reviews.

    I recently dug into an episode of Just Now Possible featuring Matthias and Charlotte Kleverud, co-founders of Momental. Their vision for "GitHub for product management" hits a nerve in the best possible way: find "merge conflicts" in strategy, not code, and do it early enough to save execution time, trust, and outcomes.

    Here’s the core: Momental ingests documents, meeting transcripts, and voice recordings across an organization, then uses AI agents to map them into a structured context layer—a set of interconnected trees covering goals, decisions, learnings, and who's doing what. When it finds a conflict—say, one team betting on retention while another is prioritizing conversion—it surfaces the misalignment for humans to resolve, just like a merge conflict in code. That framing is both familiar (for anyone who’s shipped software) and powerful (for anyone who’s scaled product strategy across multiple teams).

    Their journey tracks with what many of us have learned the hard way. "Starting in 2022 with DaVinci 002 and learning that the market wasn't ready for AI-assisted product thinking" pushed them toward experiments with agent teams. "The origin story: building a team of AI agents in 2024, only to discover agents hit the same alignment problems as humans" is exactly the kind of meta-lesson I’d expect when you scale autonomy without shared context. The breakthrough was an "OODA-loop-driven document processing agent" that continuously curates a living knowledge graph rather than relying on static prompts or brittle pipelines.

    One model that stood out was "The product chain: signals → learnings → decisions → principles, and how AI maps it." That is the backbone of healthy product thinking. When this chain is explicit and inspectable, you can trace why a team chose Path A over Path B—and detect when new signals should invalidate old decisions. I’ve seen this accelerate continuous discovery and improve executive decision hygiene.

    I also appreciated the organizational modeling: "Three trees that model an organization: the product tree (OKRs to epics), the wisdom tree (decisions and their reasoning), and the people/time tree." This maps cleanly to how we run quarterly planning at scale—tying outcomes to work, preserving rationale, and grounding ownership and timelines. With that structure, "How conflicts are detected, auto-resolved, or escalated to humans with merge options" becomes a pragmatic workflow, not a theoretical AI demo.

    On the technical front, they’re blunt about limits: "Why traditional chunking and RAG breaks down at scale and what Momental does instead." Anyone who’s tried to stitch strategy from ad hoc notes knows that naive retrieval won’t cut it. You need durable context boundaries, rich metadata, and graph-aware reasoning. Which brings me to one of my non-negotiables: "Why metadata—who said it, when, and in what context—is critical to preventing hallucinations." In my world, we treat provenance like test coverage—you can’t ship without it.

    Process-wise, the product philosophy resonated: "How a document processing agent uses OODA-loop thinking to extract and connect context across documents" reinforces the need for short feedback cycles, explicit hypotheses, and continuous refactoring of knowledge. Pair that with "The self-improving agent: collecting user feedback weekly and rewriting its own prompts" and you’ve got a blueprint for eval-driven development that keeps the system honest over time.

    Their UI choices also mirror a pattern I’ve adopted: "Moving from chat-first to UI-first to proactive agents as an AI product design pattern." Chat can feel magical, but alignment work benefits from concrete artifacts—trees, timelines, driver trees, and opportunity solution trees—so people can reason together. Then, let proactive agents watch for drift and nudge teams before the cost of change spikes.

    Two broader themes are worth calling out. First, "Specialized tools win" when the problem is deep, cross-functional context like product strategy. General-purpose chatbots struggle here; domain-specific models with strong information architecture have the edge. Second, product culture matters: "Discovery Versus Vibe Coding" is not just a catchy contrast—it’s a reminder that disciplined discovery beats intuition theater when stakes are high.

    As for the roadmap, I’m encouraged by their "Design partner strategy and what's next for Momental's public launch." Early design partners are where you validate signal quality, precision of conflict detection, and the ergonomics of human-in-the-loop resolution. I’m especially curious how this intersects with LLMs for product managers, outcomes vs output OKRs, and product roadmapping and sprint planning in large portfolios.

    Finally, a nod to the broader ecosystem. The conversation touched on "Claude Code" and a shift "Beyond documents and vectors" that many of us are living through—toward retrieval-first pipelines that respect context windows, stronger governance, and measurable improvements in decision quality. If you care about AI Strategy for empowered product teams, this is a space to watch—and to pilot.

    Bottom line: If you’ve ever wished you could prevent strategy drift before it shows up in your dashboards, this "GitHub for product management" approach is worth your attention. Make the chain of signals, learnings, decisions, and principles explicit. Keep humans in the loop for the hard calls. And let proactive, agentic AI do what it does best: flag misalignments early, so your teams can move fast together.


    Inspired by this post on Product Talk.


    Book a consult png image
  • Stop Selling Your Roadmap: Win Stakeholder Trust by Showing Your Work, Not Conclusions

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

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

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

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

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

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

    Infographic for product teams on stakeholder management, showing three groups—veto power, influences, and needs to be informed—with guidance on prioritizing stakeholder influence.
    Identify who shapes your product decisions. This visual groups stakeholders into three tiers—those with veto power, key influencers, and audiences to inform—so teams can align, communicate, and reduce delivery risk.

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

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

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

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

    Infographic for product teams on stakeholder management, outlining the trap of anchoring in solution space, the HiPPO consequences, and the lever of bringing new discovery insights and data.
    Avoid the stakeholder trap of selling conclusions. This visual shows how anchoring on solutions invites HiPPO battles—and how to shift the conversation by sharing discovery evidence, insights, and data.

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

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

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

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

    Infographic titled A Better Stakeholder Management Strategy: Show Your Work, showing seven steps for product teams using the Opportunity Solution Tree to align outcomes, prioritize, test assumptions, and iterate.
    Show your work, not just your conclusions. This infographic guides product teams through seven steps to build stakeholder confidence—align on outcomes, map opportunities, prioritize, test assumptions, and repeat.

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

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

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

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

    Infographic for product teams on tailoring stakeholder communication. A smart-filter funnel turns the full discovery journey into updates for a direct manager, marketing counterpart, and CEO.
    Show your work the right way for each stakeholder. Use a smart filter to turn discovery noise into clear signals—weekly journeys for your manager, focused monthly highlights for marketing, and a 30-second CEO pitch.

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

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

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

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

    Infographic titled Four Anti-Patterns That Destroy Stakeholder Trust, listing: 1) telling instead of showing, 2) shooting down stakeholder ideas, 3) saving for a big reveal, 4) fighting the ideological war.
    Avoid the traps that erode stakeholder trust. This infographic guides product teams to show their work, welcome ideas, provide frequent updates, and prioritize results over ideology to build alignment and credibility.

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

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

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

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

    Infographic for product teams on stakeholder management as co-creation, showing four steps: stop selling, invite co-creation, leverage stakeholder expertise, and transform relationships.
    Shift from selling to showing. This co-creation guide invites stakeholders into discovery, taps their expertise, and turns relationships from obstacles into partnerships for smarter product decisions.

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

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

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


    Inspired by this post on Product Talk.


    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
  • Go From 3 Customer Interviews to a High-Quality Opportunity Solution Tree—In Minutes

    Go From 3 Customer Interviews to a High-Quality Opportunity Solution Tree—In Minutes

    Most product teams—and especially well-run product trios—know they should be interviewing customers. More teams than ever are actually doing it. That’s the good news.

    The bad news? Many teams still struggle with what comes next. Turning raw recordings into a structured opportunity space that truly guides product discovery can feel overwhelming.

    In my experience, interview synthesis is cognitively demanding work. You have to extract the key moments from each conversation, translate those moments into clear opportunities, and then organize those opportunities into a coherent view of your opportunity space. It’s no surprise I hear teams say, "We need to stop interviewing so we can catch up on what we’ve already learned." Too often, they pause—and never start again.

    Recordings pile up. Maybe there are scattered notes. But nothing gets turned into an opportunity solution tree. The team hasn’t synthesized what they’ve learned, so the research isn’t actionable. That’s the gap I want to help close.

    What if you could go from 3 interviews to a draft OST in minutes?

    My AI goals are straightforward: 1) build tools that help you learn discovery and 2) build tools that help you do discovery. The learning tools are coming through on-demand courses. Today, I’m excited to share the first big step on the "do" side.

    I’m excited to see an expanded partnership with Vistaly—the opportunity solution tree tool many of you already use—to bring AI-powered discovery tools directly into their platform.

    Great synthesis happens in two steps: first, you synthesize each interview separately; then you synthesize across interviews. Most AI tools skip the first step and jump straight to cross-interview analysis—exactly how teams lose the nuance and context that make research actionable.

    This approach does both. You upload three interviews for the same product outcome. The AI extracts the key moments and opportunities from each one separately. Then it synthesizes across those interviews and generates a first draft of your opportunity solution tree for you. Three interviews in. A draft OST out.

    Here’s what this is—and what it isn’t. You’ve probably heard criticism of tools that promise "one-click opportunity solution trees." Those tools ask you to describe your market, click a button, and get a tree. The point of an opportunity solution tree is not to have one—it’s to synthesize what you’re learning from real customers so your team can align on the best path forward. A one-click tree built from made-up data is useless.

    Vistaly 2.0 landing page featuring 'Build what matters,' a blue Enroll in Beta button, and a dark-grid opportunity solution tree connecting an Outcome to Opportunity and Solution nodes.
    Turn interviews into insights in minutes with Vistaly. This hero screen invites you to enroll in beta and showcases an opportunity solution tree that maps outcomes to opportunities and actionable solutions.

    This approach is fundamentally different. It starts with your real customer interviews. The AI does the heavy lifting of extracting key moments and opportunities from those conversations and organizing them into a draft opportunity solution tree. But it’s a draft—you review it, refine it, and reorganize it. You bring your judgment and context to the work.

    My vision for AI-aided cross-interview synthesis is simple: AI identifies common opportunities across interviews, suggests a tree structure, and facilitates the team’s review. Historically, it’s been hard to give AI access to an opportunity solution tree in a way that preserves structure and context. The integration with Vistaly solves that problem by building this capability directly into the tool where your tree already lives.

    In my own experiments using Claude, the AI surfaced opportunities I missed—and I caught things it missed. The highest-quality synthesis came from combining both perspectives. Research (see here and here) backs this up: Experts working with AI outperform both experts working alone and AI working alone. That’s the model we’re building toward—AI generates the draft, you bring the expertise.

    I have mixed feelings about AI doing discovery work for us because there is real value in doing the synthesis yourself. But I also know that a draft OST you actually refine is better than a perfect process you never get to. This is about raising the floor—helping more teams get to a structured opportunity space, even if they aren’t doing every step manually.

    We’re looking for a small group of alpha partners to help shape this product. To apply, sign up for a free Vistaly account and upload three customer interviews for the same outcome or product space.

    We’ll select alpha partners from the applicants. We want a range of interview styles, experience levels, and product spaces. Selected partners will get access to the AI-powered synthesis tools and will work closely with the team to shape the product. Even if you aren’t selected for the alpha, your application puts you at the front of the line when we enter beta.

    A few things to know as you apply: Your three interviews should be for the same outcome, goal, or product space, so the tool can generate a meaningful OST. You don’t need to be a Vistaly user today—the account is free. You don’t need to be an expert interviewer either; we’re looking for a range of experience levels, though we’re particularly interested in story-based customer interviews.

    This is just the beginning. The vision is a full AI-powered discovery suite inside Vistaly—from interview analysis to complete interview snapshots to opportunity solution trees and beyond. We’ll learn alongside our alpha partners and share what we discover as we go.

    If you’ve been looking to bridge the gap between your customer interviews and your opportunity space, this is your chance to help shape how that works. Apply for the alpha today.


    Inspired by this post on Product Talk.


    Book a consult png image
  • What I Learned Scaling Analytics: Candid Lessons on Product Strategy and Product-Market Fit

    What I Learned Scaling Analytics: Candid Lessons on Product Strategy and Product-Market Fit

    I write from a place many product leaders know well—the moment when the data you need to make decisions simply doesn’t exist, and you have to build the capability from the ground up. That firsthand experience with gaps in analytics shaped how I think about product strategy, product discovery, and the relentless pursuit of product-market fit lessons.

    In my work, I lean on continuous discovery to surface the most meaningful problems, then translate those insights into outcomes vs output OKRs that keep teams focused on impact. When we anchor roadmaps to real user behavior and business results, we avoid vanity metrics and create a durable plan that compounds learning over time.

    Execution matters just as much as insight. I rely on rigorous A/B testing, clear minimum detectable effect (MDE) thresholds, and retention analysis to separate signal from noise. This discipline ensures that every iteration—whether it’s a small UX nudge or a bold bet—moves us closer to measurable value for customers and the business.

    None of this works without empowered product teams. I build around product trios that partner tightly across design, engineering, and product, and I foster a product-led growth mindset so we earn activation, engagement, and expansion through the experience itself. The goal is to create a system where learning is fast, ownership is clear, and the user’s job-to-be-done stays front and center.

    On the tooling side, I favor a unified analytics platform so insights are consistent from discovery to deployment. Whether I’m instrumenting funnels with Amplitude analytics or stitching together qualitative and quantitative inputs, the principle is the same: give teams trustworthy, real-time visibility so they can make better decisions, faster.

    If you’re looking to operationalize these practices, you’ll find practical playbooks, decision frameworks, and real-world examples here—built for leaders who want clarity, speed, and confidence in how they discover, ship, and scale products.


    Inspired by this post on Amplitude – Best Practices.


    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
  • Reinventing Product Management Workflow: The AI Upgrade I Use to Ship Faster, Smarter

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    Inspired by this post on Product School.


    Book a consult png image