Tag: outcomes vs output OKRs

From KPIs to Comebacks: How I Lead Through Setbacks with Curiosity, Care, and Discovery

Setbacks are the tax we pay for doing meaningful product work. As a VP of Product Management, I’ve learned that what separates resilient teams from the rest isn’t a lack of failures—it’s how we metabolize them. This episode of All Things Product with Teresa Torres and Petra Wille is a powerful reminder that recovery, reflection, and rigorous product discovery are as essential as speed and execution.

Listen to this episode on: Spotify https://open.spotify.com/episode/10LYRya7boYJBHTYBnE79E?ref=producttalk.org | Apple Podcasts https://podcasts.apple.com/kh/podcast/dealing-with-setbacks/id1794203808?i=1000737190520&ref=producttalk.org

What struck me most is how Teresa shares a deeply personal story about her long recovery from an injury—and how that journey mirrors the nonlinear reality of product development. In product, just like in healing, progress is rarely a straight line. We have surges, stalls, and moments that feel like reversals. Yet with the right mindset and rituals, we still move forward.

Professionally, we all face moments when your product fails to move a single KPI, when a launch falls flat, or when you just feel stuck. I’ve been there—in quarterly reviews, post-launch standups, and board prep. The instinct is to sprint straight into solutions. The wiser move is to respond with curiosity, emotional honesty, and resilience, then re-engage our discovery habits with intention.

If you’re a PM, designer, or researcher, consider this an invitation to rebalance. Recovery and reflection are just as important as velocity and success. That’s not soft talk—it’s how empowered product teams build durable performance without burning out.

On the emotional reality of setbacks, I’ve learned to normalize naming the loss. We put immense pressure on ourselves, and it’s okay (and necessary) to grieve product failures. When we acknowledge the disappointment, we regain the ability to observe clearly—and to learn.

Leaders play a crucial role here. I create space for teams to recover before jumping into post-mortems. We don’t whiteboard over feelings; we schedule time for decompression, then conduct a crisp, blameless review. That sequencing transforms the quality of insights and strengthens psychological safety.

Another lesson that resonates is the danger of tying performance too tightly to outcomes. Outcomes matter, but they are lagging indicators influenced by many externalities. I evaluate performance on behaviors: clarity of problem framing, rigor in discovery, quality of decision-making, and stakeholder alignment. This aligns with outcomes vs output OKRs and keeps us focused on controllable excellence.

How do we build resilience? Continuous discovery builds resilience by normalizing failure. When we test assumptions routinely with customers and data, we turn large, risky bets into a series of small, learnable steps. Teams recover faster because failure becomes feedback—frequent, cheap, and informative.

For perspective, I often use the 10–10–10 framework (from Decisive by Chip & Dan Heath). I ask: How will this setback feel in 10 minutes, 10 months, and 10 years? The answers de-escalate urgency, expand our time horizon, and produce better, calmer decisions.

Here are the key takeaways I’m carrying forward. Setbacks are not just inevitable—they’re part of doing meaningful product work. Giving teams time and space to process failure builds long-term resilience. Mourning losses is just as important as celebrating wins.

Healthy discovery cultures embrace reflection, psychological safety, and emotional honesty. And most importantly, staying consistent with discovery habits helps teams recover faster and learn more deeply.

Notable moments that stood out for me include: [00:02:00] Teresa shares the story of her injury and what it’s taught her about patience and setbacks. The parallel to product cadence is both humbling and motivating.

[00:10:00] Petra talks about a team whose carefully planned launch didn’t move a single KPI. I’ve led similar debriefs; when we anchor on customer insight gaps rather than blame, the next iteration improves dramatically.

[00:20:00] Discussion on allowing space for grief and frustration after failure. In my teams, we time-box “emotional processing” before we enter analysis mode—it humanizes the work and sharpens the learning.

[00:30:00] Why organizations must decouple performance reviews from short-term outcomes. I align evaluations to strategy execution quality, hypothesis discipline, and cross-functional collaboration.

[00:40:00] How continuous discovery can help teams normalize—and even learn to appreciate—setbacks. When discovery is weekly, momentum becomes self-healing.

If you want to dig deeper, here are useful links from the episode. Follow Teresa Torres: https://ProductTalk.org

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

Mentioned in the episode: Decisive by Chip & Dan Heath — The 10–10–10 framework for perspective in decision-making https://heathbrothers.com/books/decisive/?ref=producttalk.org

Teresa Torres’ Continuous Discovery Habits — Building resilience through ongoing discovery practices. https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309?dchild=1&keywords=continuous+discovery+habits&qid=1621385051&sr=8-2&linkCode=sl1&tag=teresatorres-20&linkId=34bc439ac78da06e1398f7bf069b219e&language=en_US&ref_=as_li_ss_tl&ref=producttalk.org

Join the Conversation: Have thoughts on this episode? Leave a comment below. I’d love to hear how you create space for recovery while sustaining product velocity.

Full Transcript: Full transcripts are only available for paid subscribers.

Inspired by this post on Product Talk.

November 18, 2025
Taming 1,000+ Vendor Emails: How Xelix’s AI Helpdesk Delivers Fast, Confident Answers

Chaos in vendor communications is a problem I see across finance operations: sprawling accounts payable inboxes, slow response times, and missed context. That’s why this build caught my attention—not just because it’s GenAI, but because it’s a disciplined product strategy that converts email overload into measurable outcomes.

Accounts payable inboxes can see 1,000+ vendor emails a day. Xelix’s new Helpdesk turns that chaos into structured tickets, enriched with ERP data, and pre-drafted replies—complete with confidence scores.

I dug into the end-to-end approach with the team—Claire Smid — AI Engineer, Xelix; Emilija Gransaull — Back-End Tech Lead, Xelix; Talal A. — Product Manager, Xelix—focusing on how they scoped the problem, iterated fast, and de-risked AI in production.

Their product thesis is refreshingly pragmatic. They prototyped with “daily slices” (Carpaccio-style) and built a retrieval-first pipeline that matches vendors, links invoices, and drafts accurate responses—before a human ever clicks “send.” That framing matters: enrichment and matching take center stage, with the model amplifying precision instead of improvising.

We unpacked the tricky bits that make or break an AI helpdesk at scale: vendor identity matching, Outlook threading, UX pivots from “inbox clone” to ticket-first views, and the metrics that prove real impact (handling time, stickiness, auto-closed spam). The pipeline architecture and email processing choices were grounded in operational realities, not just AI aspirations.

Several takeaways are worth pinning to any AI product roadmap. “Start narrow to win: pick high-volume, high-cost requests (invoice status & reminders).” “Enrichment > magic: accurate replies come from great retrieval/matching, not just a bigger LLM.” “Design for adoption: familiar inbox view helps onboarding, but a ticket-first UI unlocks AI features.” These are the kinds of decisions that drive adoption, trust, and ROI.

Data enrichment challenges dominated early learning curves: stitching ERP context into tickets, handling vendor identification at scale, managing email thread continuity, and calibrating response generation for accuracy. On the generation side, the team emphasized precision over verbosity—clean responses that reflect system-of-record truth—then instrumented the experience to “Evaluate System Performance” with production-grade telemetry.

Trust was treated as a product feature. “Measure outcomes, not vibes: track ‘messages sent from Helpdesk’, % auto-resolved.” And critically, “Confidence builds trust: show match quality and response confidence so humans know when to edit.” By surfacing match quality and confidence scores, they shortened coaching loops and made human-in-the-loop supervision feel natural, not burdensome.

What’s next is equally compelling: “targeted generation, multiple specialized responders, and more agentic routing.” That direction aligns with agentic AI patterns I recommend for operations-heavy workflows—route first, retrieve deeply, then generate with intent. It’s a scalable path from assistive AI to autonomous resolution while maintaining governance and auditability.

If you want a quick map of the journey, the conversation flowed from 0:00 Meet the Team: Claire, Emilija, and Talal, 00:36 Introduction to Xelix and Its Products, 01:08 Understanding Accounts Payable Teams, 01:37 Help Desk Product Overview, 03:11 Challenges Faced by Accounts Payable Teams, 04:03 AI Integration in Help Desk, 05:47 Automating Reconciliation Requests, 07:45 Development Methodology: Carpaccio, 09:11 Prototyping and Beta Testing, 12:00 Manual Tagging and Data Collection, 16:39 Focusing on High-Impact Use Cases, 18:55 User Experience and Interface Design, 24:56 Pipeline Architecture and Email Processing, 28:21 Data Enrichment Challenges, 29:04 Handling Vendor Identification, 33:33 Email Thread Management, 36:15 Generating Accurate Responses, 40:48 Evaluating System Performance, 49:20 Future Developments and Goals.

My takeaway for product leaders: when the domain is high-volume and rules-heavy (like AP), retrieval-first beats model-first. Start with the narrowest, costliest intents; prove lift with “messages sent from Helpdesk” and “% auto-resolved”; then graduate UX from familiar to AI-native (ticket-first) once trust is earned. That’s how you turn vendor chaos into answers—reliably, scalably, and fast.

Inspired by this post on Product Talk.

November 13, 2025
Global Invoicing Nightmares: Hard-Won Product Lessons on EU Tax, Compliance, and Customer Value

I hit play on Global Invoicing – All Things Product Podcast with Teresa Torres & Petra Wille and felt an immediate jolt of recognition. We’ve all launched a feature that looked solid—until a small, overlooked detail broke everything. Their stories about global invoicing and taxes echoed challenges I’ve faced leading product for international customers: if you don’t design for the last mile of compliance, you can accidentally block the very "moment of value creation" your product promises.

Listen to this episode on: Spotify | Apple Podcasts

The conversation starts as a candid rant about EU tax compliance and quickly becomes a precise product management lesson: when we fail to map the entire path to customer value—down to the tiniest regulatory requirement—we can ship something “done” that still doesn’t work in the real world. That gap between intention and outcome is where good product teams live or die.

In my experience, the nightmare of global invoicing for small online businesses is very real. Even big platforms (like Squarespace and Teachable) miss the mark on EU tax compliance, and when they do, customers feel it immediately. It’s the kind of edge case that doesn’t show up in a demo but absolutely shows up in revenue. Or as Teresa put it, “It’s not a little detail when your client won’t pay the invoice.” — Teresa Torres

I appreciated how the episode digs into the difference between passing a regulatory checklist and actually meeting customer needs. Put plainly: the product isn’t “done” when the ticket moves to Done; it’s done when the customer completes the job—receives an acceptable invoice, pays successfully, and can reconcile it without friction. That’s why I lean hard on story mapping for regulatory work; it exposes the invisible steps where value creation can silently fail.

Here’s how the episode resonates with my own playbook: the nightmare of global invoicing for small online businesses is a systems problem; why even big platforms (like Squarespace and Teachable) miss the mark on EU tax compliance is a prioritization and discovery problem; how Petra and Teresa navigated invoicing across borders with Ableify and LearnWorlds highlights pragmatic tool choices and trade-offs; the key difference between meeting regulations and meeting customer needs is an outcomes-over-output mindset; what product teams can learn from regulatory edge cases is how to find the seams where markets, laws, and workflows collide; how missing a single detail can block the "moment of value creation" is a reminder that value is defined by customers; and why story mapping is critical for finding gaps between "we shipped it" and "customers got value" is the method that connects all of the above.

Practically, that means I treat regulatory features like any other high-stakes product surface: do real product discovery with affected users; co-design the happy path and the ugly edge cases; write acceptance criteria that include jurisdictional and document-level specifics (e.g., VAT numbers, invoice formats, timing rules); align with finance and legal early; and instrument the journey from invoice issued to invoice paid so we can see where real customers get stuck. This is outcomes vs output OKRs in action, and it’s one of the fastest ways to earn trust with stakeholders.

Key takeaways worth bookmarking: Customers define value, not your compliance checklist. Regulatory work still requires discovery—you can’t skip understanding user needs. The path to value doesn’t end when your feature works; it ends when your customer succeeds. “Sweating the details” isn’t micromanagement—it’s good product management.

Memorable quotes to bring back to your team: “If you don’t sweat the details, people choose other platforms.” — Petra Wille. “It’s not a little detail when your client won’t pay the invoice.” — Teresa Torres.

Follow Teresa Torres: https://ProductTalk.org | Follow Petra Wille: https://Petra-Wille.com

Mentioned in the episode: Squarespace | Stripe | Product at Heart | Teachable | LearnWorlds | Ablefy | Become a Better Product Leader: A 52-Week Transformation Journey | Product Talk Academy

Have thoughts on this episode? Leave a comment below.

Full transcripts are only available for paid subscribers.

Inspired by this post on Product Talk.

November 11, 2025
Prototypes vs Products: How I De-risk Ideas Fast and Ship Reliable Value at Scale

Note: This is part of the product creator series of articles, based on the overview article, The Era of the Product Creator. This series is for anyone who wants to create a successful product—whether or not you’ve had formal training or experience in product management, product design, or engineering. Over the years, I’ve watched smart teams stumble because they treated a prototype like a product. The distinction is simple but vital: prototypes exist to learn; products exist to earn trust by delivering value reliably at scale. When we blur that line, we ship avoidable risk to customers and slow ourselves down later with rework. When I build a prototype, I’m testing assumptions as quickly and cheaply as possible. It might be a clickable Figma mock, a Wizard‑of‑Oz demo, or a quick script stitching together a ChatGPT connector with a CustomGPT workflow. It’s intentionally disposable. I expect missing edge cases, fake data, hand‑waving on latency, and limited attention to security or privacy. The only goal is to answer the riskiest questions fast. A product is a promise. It’s hardened for reliability, performance, security, and privacy‑by‑design. It’s observable with real analytics, supports CI/CD and rollback, meets accessibility guidelines, and can be maintained by empowered product teams. It has clear SLAs, incident management runbooks, and instrumentation that lets me track outcomes vs output OKRs and DORA metrics. Keeping prototypes and products separate makes us faster and safer. Prototypes accelerate discovery; products operationalize value. If I catch myself “polishing” a prototype, I pause and either discard it or define the path to production with the right engineering rigor, data governance, and stakeholder management. Here’s how I decide. In prototype mode, I timebox learning to days, not weeks, and focus on a single risky assumption—value, usability, or feasibility. I validate through qualitative research and usability tests, not vanity metrics. To graduate to product work, I require a crisp problem statement, evidence of problem‑solution fit, a technical plan for scale and observability, a privacy and threat modeling review, and a measurement plan (including minimum detectable effect) for upcoming A/B testing. AI adds new wrinkles. For gen AI and agentic AI, I evaluate model behavior offline before exposing anything to customers. That includes prompt design, context window management, guardrails to minimize hallucinations, and clear fallback strategies. I define red‑team scenarios, logging for auditability, and policies for data retention and encryption as part of AI risk management. A recent example: we prototyped an agent workflow in a day that felt magical in demos. We resisted the urge to ship. Instead, we added authentication, rate limiting, PII redaction, human‑in‑the‑loop review, observability, and in‑app guides and product tours for onboarding. Only then did we move to a limited release with a well‑defined go‑to‑market strategy and support readiness. One more trap to avoid: calling a prototype an MVP. An MVP is still a product—minimal in scope but complete enough to deliver value, gather trustworthy data, and support customers. If you wouldn’t put your name on it or support it in production, it’s a prototype, not an MVP. If you’re a product creator, align your product trios around this discipline. Use prototypes to learn quickly in discovery, and use products to deliver outcomes in delivery. That mindset protects customer trust, speeds iteration, and moves you toward product‑market fit with far less waste.

Inspired by this post on SVPG.

November 7, 2025
From Code to Roadmaps: My Proven Playbook for Engineers Becoming Product Managers

"From code commits to boardrooms. Here are real stories of software engineers who swapped bugs for roadmaps on the road to product manager." I’ve made that leap myself and helped many engineers do the same. In this piece, I share the playbook I use to guide high-potential ICs into impactful product management roles—without losing the engineering rigor that makes them special.

Engineers make exceptional product managers because we’re trained to decompose complex systems, debug ambiguity, and reason from first principles. The transition isn’t about abandoning code; it’s about expanding your scope from implementation details to customer outcomes, market context, and business impact.

The first shift is mental: move from shipping outputs to driving outcomes. Features are a means; value is the end. I anchor this change with outcomes vs output OKRs, ensuring every roadmap item ties to a measurable user or business result rather than a checklist of tickets.

Next, upskill deliberately in three areas: product discovery, product positioning, and stakeholder management. Learn to design unbiased customer interviews, synthesize patterns from qualitative and quantitative signals, and craft crisp value propositions that resonate with real segments. Then practice executive-ready communication—clear decisions, concise narratives, and no jargon crutches.

Here’s the practical, low-risk way to get PM experience without changing your title: form a product trios working group (design, engineering, product) around a real problem. Lead discovery with a weekly cadence, run lightweight experiments, and translate insights into a draft product roadmapping and sprint planning artifact. Ship small, learn fast, and narrate the learning.

Build a simple portfolio that proves product judgment. Include one-page problem briefs, discovery notes, customer quotes, prioritized opportunity trees, and a before/after roadmap snapshot. For each artifact, quantify the impact: activation lift, support ticket reduction, conversion improvement—whatever outcome your work influenced.

If you want to pivot internally, propose a 90-day experiment. Volunteer to own a well-bounded problem, commit to an outcomes dashboard, and set a weekly stakeholder update. Keep a minimal engineering contribution during the trial to de-risk the transition for your team while you demonstrate PM leverage across the squad.

If you’re interviewing externally, prepare two deep case studies: one discovery-led (how you reduced uncertainty) and one delivery-led (how you aligned stakeholders and shipped). Be explicit about trade-offs, risks you retired, metrics you moved, and lessons learned. The best signals of product sense are clarity under constraints and an ability to say “no” for good reasons.

Once you land the role, use a 30-60-90 plan. In the first 30 days, map users, workflows, metrics, and decision rhythms; in 60, run a focused discovery sprint and align on your hypothesis-led roadmap; by 90, deliver a thin slice that proves value and establishes credibility with empowered product teams. Keep your communication tight, your dashboards honest, and your customers close.

Common pitfalls: translating directly from solution space to roadmap without validating problems; equating stakeholder satisfaction with customer value; and mistaking velocity for progress. Avoid them by running small tests early, revisiting segment-specific value propositions, and anchoring trade-offs to product-market fit lessons.

If you’re standing at the edge of this transition, start where you are: choose one user pain, one measurable outcome, and one small bet. Treat it like a product: define success, experiment thoughtfully, and learn in public. The road from engineer to product manager isn’t a title change—it’s a shift in how you create value.

Inspired by this post on Product School.

November 3, 2025
Impact Analysis Mastery: Proven Steps to Predict, Measure, and Maximize Product Outcomes

When I think about the difference between a roadmap that moves the business and one that simply ships output, impact analysis is the habit that changes everything. It gives me and my product trios a disciplined way to forecast value, align stakeholders, and de-risk bets before a single sprint starts. Over the years, I’ve seen great ideas fail not because they were bad, but because we couldn’t articulate, test, and track their true impact. That’s the problem impact analysis solves.

Impact analysis, in practice, is a structured method for predicting how a proposed change will influence user behavior and business outcomes—and then validating those predictions with data. Uncover what impact analysis is, why it matters, and how to do it with proven methods and clear steps for product teams. When done well, it translates strategy into evidence-backed choices that strengthen our value proposition and accelerate product-led growth.

I use impact analysis at three key moments: during product discovery to vet opportunities, in product roadmapping and sprint planning to prioritize, and post-launch to confirm that outcomes beat expectations. It is equally useful for net-new features, UX improvements, pricing changes, and even enablement like in-app guides or product tours.

Step 1: Define the outcome with precision. I anchor every proposal to outcomes vs output OKRs, choose one primary success metric, and record the current baseline. If we plan to experiment, I estimate the minimum detectable effect (MDE) to ensure our A/B testing can actually validate the expected lift. This protects us from investing in ideas that are too small to measure or too broad to manage.

Step 2: Map the causal chain. I translate the idea into a simple impact map: feature change → user behavior (activation, frequency, conversion, retention) → business outcome (revenue, cost, risk, satisfaction). This clarifies what must change in user behavior and why users would care—forcing us to revisit our value proposition if the link feels thin.

Step 3: Size the upside and reach. I estimate who will be exposed (reach), how often (frequency), and the expected behavior change (conversion delta). I complement this with RICE (reach, impact, confidence, effort) or cost of delay to compare options. The goal isn’t perfect math; it’s consistent, transparent assumptions that we can pressure test with data.

Step 4: Evaluate risk, complexity, and dependencies. I assess technical effort, privacy-by-design considerations, data governance needs, and cross-team sequencing. This is where stakeholder management becomes essential—aligning Engineering, Design, GTM, and Security early so we don’t discover hidden blockers mid-sprint.

Step 5: Design the evidence plan. For changes where causality matters, I prefer A/B testing with the right MDE and guardrail metrics. I instrument events and set up dashboards in a unified analytics platform (Amplitude analytics, Pendo, or a homegrown stack) so we can monitor leading indicators quickly. If experiments aren’t feasible, I use sequential rollouts, synthetic controls, or pre-post analyses with clear caveats.

Step 6: Communicate the decision. I share a one-page impact brief that summarizes objectives, hypotheses, metric choices, expected lifts, risks, and the test plan. This reduces debate time, improves stakeholder trust, and enables empowered product teams to move faster with clarity.

Step 7: Ship, monitor, and learn. After launch, I track leading indicators within days and validate lagging outcomes over weeks. I run retention analysis and cohort reviews to confirm that behavior change sticks, and I write a short learning memo—especially when we miss—so future bets get sharper.

On a recent initiative, our team debated whether to build a new onboarding flow or invest in targeted in-app guides. The impact analysis showed the guide approach would reach 3x more users in the next quarter, require half the effort, and be easier to A/B test end-to-end. We shipped the guides, saw a measurable lift in activation, and then recycled those insights to inform the broader onboarding redesign. The analysis didn’t just pick a winner—it created a faster path to compounding outcomes.

Common pitfalls I watch for: chasing vanity metrics, assuming linear impact at scale, ignoring confidence and variance, and skipping instrumentation. Another trap is treating impact analysis as a heavyweight doc—keep it lightweight, comparable across initiatives, and tightly tied to decision-making.

My lightweight template: one sentence on the desired outcome and OKR; a causal chain with the key behavior change; a simple sizing with reach, impact, and confidence; risk and dependency notes; the experimentation plan; and the decision. If we can’t write that in one page, we probably don’t understand the bet well enough to pursue it yet.

The next time you review your roadmap, pick your top three bets and run this playbook. You’ll sharpen your prioritization, increase stakeholder confidence, and give your team a clear line of sight from product discovery to measurable outcomes. That’s how we build momentum, quarter after quarter.

Inspired by this post on Product School.

November 3, 2025
Product Tree 101: The Visual Prioritization Framework I Rely on to Align Teams Fast

When my team is drowning in requests, the Product Tree is the visual tool that brings clarity and momentum. "Learn what a product tree is, how to use the product tree framework, and why it’s a powerful tool for smarter product prioritization." That’s exactly what I aim to share here—how I use it to align stakeholders, sharpen product strategy, and translate ideas into outcomes.

A product tree is a simple yet powerful metaphor for your product. The trunk represents the core value, the roots are the technical foundations and platform capabilities, the branches are product areas or themes, and the leaves are features, experiments, or opportunities. By placing ideas as leaves on the right branches—and making sure roots can actually sustain that growth—we turn a messy backlog into a coherent product roadmap.

Why do product managers swear by it? Because it forces outcomes over outputs, exposes trade-offs visually, and reveals where strategy is thin or overgrown. In one view, you see customer value, technical debt, and strategic focus—crucial for empowered product teams, product discovery, and stakeholder management. It’s also an excellent way to connect outcomes vs output OKRs to tangible delivery paths.

Here’s how I set it up. First, I define the trunk with a crisp product value proposition and the minimum set of experiences that make the product viable. This anchors everything else so we don’t mistake a shiny leaf for the core of the tree.

Next, I map branches to clearly named themes that mirror how customers perceive value—onboarding, activation, collaboration, analytics, or reliability. I keep branches aligned to outcomes to avoid feature-first thinking; this pays dividends during product roadmapping and sprint planning.

Then I add leaves: research insights, customer requests, experiments, and enabling features. I note intent (e.g., drive activation, reduce churn), expected impact, and a rough effort signal. This quickly surfaces which leaves grow the product and which are just twigs.

Finally, I draw roots—the enabling platform work and technical investments that make the branches sustainable. Performance, data governance, privacy-by-design, and scalability belong here. If the roots can’t support the canopy, the tree is at risk, and that becomes a visible, prioritizable problem rather than an invisible liability.

Once the tree is sketched, I facilitate a collaborative session with product trios and cross-functional partners. We prune low-impact leaves, cluster work by outcomes, and explicitly link branches to OKRs. In QBRs vs OKRs reviews, the tree becomes our single source of truth for trade-offs, helping stakeholders see why some requests move up and others wait.

In practice, I use the Product Tree to shape a near-term delivery plan and a longer-horizon narrative. Near term, it informs sprint planning and sequencing by ensuring the right roots land before the heavier branches. Longer term, it clarifies the growth story for product-led growth—what we’ll grow next and why it matters for customers.

A few tips from the trenches: anchor branches to customer outcomes, not internal org charts; spotlight enabling work so platform investments aren’t deprioritized; and revisit the tree after each discovery cycle to keep it fresh. The moment the tree feels lopsided, that’s your signal to rebalance bets or revisit assumptions in product discovery.

If you’re preparing for your next planning cycle, try a 60-minute Product Tree workshop. You’ll come away with a shared mental model, sharper prioritization, and a roadmap that is easy to communicate and defend—because everyone can see the product’s future taking shape right in front of them.

Inspired by this post on Product School.

November 3, 2025
Stop Shipping for the Sake of It: Master Outputs vs. Outcomes to Build Products That Win

Too many teams still celebrate what they ship rather than what they change. I’ve learned—sometimes the hard way—that the most expensive mistake in product management is confusing outputs with outcomes. Understand the key differences between output vs. outcome in product management — and how to keep your team focused on what really drives results.

Here’s how I draw the line: outputs are the features, tickets, and releases we produce; outcomes are the measurable changes in user behavior and business performance we create—activation rates, retention, expansion, and time-to-value. If an initiative doesn’t move a metric that matters, it’s output without impact. That’s how feature factories are born.

The confusion is costly because it distorts incentives. Teams optimize for velocity, story points, or deployment frequency and mistake motion for progress. Engineering excellence and DORA metrics matter, but they’re not substitutes for product outcomes. When OKRs drift into task lists, we ship more and learn less. I’ve seen ambitious roadmaps hit every delivery date and still miss the market because we didn’t change customer behavior.

To break that cycle, I anchor planning and reviews to outcome-based OKRs. A good objective might be: increase new-account user activation from 28% to 45% this quarter. The anti-pattern is: ship onboarding redesign v2. The former sets a clear behavioral target; the latter constrains creativity and locks us into a solution before discovery. This is the practical heart of outcomes vs output OKRs.

From there, I define leading indicators that predict the desired outcome—time-to-first-value, completion of core actions, day-7 retention—and instrument them early. Tools like Amplitude analytics help us see whether an experiment is unlocking behavior change or just producing activity. I also set guardrail metrics (support volume, performance, and NPS) so we don’t “succeed” by creating a new failure mode.

The delivery model matters, too. Empowered product teams—built as product trios of product, design, and engineering—own the problem and the outcome. We invest in product discovery to validate assumptions, size opportunities, and find the minimum viable change that moves the metric. A/B testing with a clear minimum detectable effect (MDE) makes our experiments faster, cheaper, and more conclusive.

Roadmaps then become strategic bets rather than feature lists. Each bet articulates the opportunity, the hypothesized solution, the expected outcome, and the evidence that would change our mind. In sprint planning, we slice increments to learn sooner, not just to deliver sooner. CI/CD accelerates shipping; outcome instrumentation accelerates learning.

Stakeholder conversations shift as well. Instead of debating which features to build, we align on the customer problem, the value proposition, and the measures of success. QBRs showcase what changed—activation, adoption, retention—not just what shipped. This is how we move from feature requests to outcome commitments and sustain product-led growth.

I’ve found that outcomes-first execution energizes teams. Clarity of purpose invites creativity, and the autonomy to experiment fuels ownership. When we celebrate behavior change over backlog burn-down, we stop playing to the roadmap and start playing to win the market.

If your team is stuck in output mode, start small: rewrite one key objective as an outcome, instrument a leading indicator, and run a scoped experiment. When the metric moves, let that win reset the culture. Momentum follows outcomes.

Inspired by this post on Product School.

November 3, 2025
Mastering AI Evals: The Essential Product Manager Skill to Ship Safer, Smarter AI

In every AI-powered product I ship, evaluation is the difference between a compelling demo and a dependable customer experience. AI evaluation isn’t a nice-to-have; it’s a core product management competency that shapes quality, safety, and business outcomes from the first prototype to scale.

When I talk about AI evaluation, I mean a disciplined, repeatable way to measure model behavior across quality, safety, reliability, latency, and cost. Gen AI has changed the cadence of product decisions—models evolve weekly, prompts drift under real-world load, and edge cases multiply. Without rigorous evals, we risk shipping unpredictability.

My goal in this piece is simple: “Dive deep into AI evals, why they matter for PMs today, and how to master them with clear steps, examples, and best practices.” If you’re leading product strategy for LLMs, agentic AI, or applied AI features, this is the playbook I rely on.

Why this matters now: customers don’t judge AI by benchmarks, they judge by trust—did it help me, was it safe, was it fast? Strong AI evals let me set outcomes vs output OKRs, quantify risk, and make transparent trade-offs between accuracy, latency, and cost. They also give engineering and design clear guardrails to move fast without breaking user trust.

Step 1: Define the product problem and success metrics. I start by tying AI metrics to business outcomes—resolution rate, deflection rate, revenue lift, time-to-value—and include model-centric measures like hallucination rate, harmful content rate, latency, and token cost. This keeps experiments anchored to impact, not just model scores.

Step 2: Build a high-signal golden dataset. I curate real, anonymized user prompts from discovery and support channels, then add adversarial and long-tail cases. For generative tasks, I create rubric-based criteria for correctness, helpfulness, tone, and safety. This dataset becomes my regression suite as prompts, RAG pipelines, or models change.

Step 3: Choose the right evaluation methods. I combine deterministic unit tests for rules with LLM-as-judge scoring, pairwise preference tests for prompt variants, human review for critical flows, and red teaming for safety. I also apply privacy-by-design and strong data governance to ensure eval data handling meets compliance and customer expectations.

Step 4: Operationalize with CI/CD. Evals run automatically on every prompt, retrieval, or model update, with pass/fail gates and alerting. I track results in a unified analytics platform so product, engineering, and go-to-market teams see the same truth. If a change regresses key thresholds, we pause rollout or roll back.

Step 5: Optimize the cost–quality–latency triangle. Real products live within constraints. I analyze token budgets, caching strategies, model selection (e.g., small for classification, larger for complex generation), prompt structure, retrieval quality, and function-calling patterns. For agentic AI, I evaluate tool-use correctness and task completion reliability, not just text quality.

Step 6: Close the loop with experimentation. Offline evals get me confidence; online A/B testing validates business impact. I design tests with a clear minimum detectable effect (MDE), guard for novelty bias, and instrument activation, retention, and satisfaction in Amplitude or Pendo. Agent analytics help me pinpoint where users succeed or get stuck.

Step 7: Govern responsibly. I maintain model cards, decision logs, and incident playbooks. For customer-facing assistants, I gate risky actions, log explanations, and add human-in-the-loop escalation. AI risk management isn’t bureaucracy—it’s how we earn trust at scale.

A concrete example: building a customer support assistant. My success metrics include deflection rate, first-contact resolution, median response latency, and safe action rate. The golden dataset blends common queries, billing edge cases, account-specific retrieval checks, and adversarial prompts. Evals measure factuality against a knowledge base, tone alignment with brand guidelines, and safe tool use for CRM integration. Only after passing offline gates do we A/B test deflection and CSAT in production.

Common pitfalls I watch for: overfitting prompts to a tiny test set, relying solely on LLM-as-judge without human calibration, skipping safety tests when latency rises, and treating evaluations as a one-time launch task. The antidote is simple—regularly refresh datasets, diversify eval methods, and wire evals into the same release discipline as any core feature.

The payoff is compounding. With strong AI evals, we ship confidently, reduce incident rates, accelerate iteration, and communicate trade-offs clearly to stakeholders. More importantly, we build products customers trust—because quality isn’t a promise, it’s a practice we can measure every day.

Inspired by this post on Product School.

November 3, 2025
Organizational Development Demystified: The Engine Behind Smarter Teams, Culture, and Growth

When people ask me how product organizations actually scale what works, I point them to a simple truth: organizational development is the operating system that makes strategy executable, teams empowered, and outcomes repeatable.

It turns out that organizational development isn’t just HR lingo. It’s the engine behind smarter teams, better culture, and long-term growth.

In practice, I think of organizational development as the discipline that aligns structure, incentives, rituals, and learning loops so empowered product teams can do their best work. It connects product management leadership with execution through clear decision rights, transparent roadmapping, and ways of working that reduce friction across product, design, and engineering.

On the ground, this looks like moving from activity measures to outcomes vs output OKRs, forming durable product trios to own customer problems end to end, and tightening stakeholder management so priorities don’t whipsaw week to week. It also means investing in onboarding that accelerates time-to-impact, creating feedback rituals that surface risks early, and using retention analysis to make smarter bets about where to double down.

The payoff is tangible: faster decision-making, fewer handoffs, and clearer accountability. Teams ship with confidence, leaders get leading indicators instead of lagging surprises, and employee retention at startups improves because people see how their work connects to a meaningful value proposition and product-led growth.

In my own practice, shifting to outcomes-first planning, establishing product trios, and clarifying interfaces across functions reduced decision latency, improved deployment frequency, and made ownership unmistakable. The organization became more resilient because the culture, processes, and metrics reinforced one another instead of competing for attention.

If you’re starting from scratch, begin by aligning on a small set of outcomes that matter, then redesign ceremonies and artifacts to serve those outcomes. Next, empower teams with clear autonomy and constraints—enough freedom to discover, enough guardrails to focus. Finally, make learning visible: use lightweight postmortems, discovery reviews, and customer signal dashboards so your operating system continuously improves.

Organizational development isn’t a one-time reorg; it’s a habit. When we treat it as a product—iterating on roles, rituals, and metrics just like we iterate on features—performance compounds, culture strengthens, and growth becomes sustainable.

Inspired by this post on Product School.

November 3, 2025
Innovation Strategy in the Age of AI: Proven Playbooks, Real-World Examples, and What Works Now

AI has rewritten the rules of how we create value, and I’ve watched the most resilient organizations treat innovation as a disciplined, outcomes-driven capability—not a one-off initiative. In my role leading product teams, I’ve refined a practical approach that blends rigorous product management with an adaptive AI Strategy so we can ship faster, learn faster, and de-risk smarter.

Learn what an innovation strategy is, how to build one, which types to use, and see real examples that drive meaningful change.

At its core, an innovation strategy is the intentional system that aligns vision, portfolio bets, and execution mechanics to measurable business outcomes. I anchor this in outcomes vs output OKRs, ensuring every experiment, feature, and GTM motion ties to a clear value proposition and reinforces hard-won product-market fit lessons rather than chasing novelty.

I design portfolios around three types of innovation that work well in the age of AI. First, core optimization: drive compounding gains with CI/CD, DORA metrics, and A/B testing to improve activation, retention, and profitability. Second, adjacent expansion: extend value via new segments, channels, or use cases—often enabled by product-led growth tactics like in-app guides and product tours. Third, transformational bets: leverage gen ai and agentic AI to create step-change capabilities while proactively addressing AI risk management, data governance, and privacy-by-design.

Building the strategy starts with empowered product teams and product trios who run continuous product discovery to validate problems before validating solutions. I keep discovery tight with a minimum detectable effect (MDE), instrument the journey with a unified analytics platform, and thread learnings into product roadmapping and sprint planning so we prioritize the smallest, fastest path to decision-quality data.

On the AI front, my operating model combines an AI product toolbox (prompt patterns, evaluation harnesses, and safety rails) with LLMs for product managers to accelerate research, prototyping, and content generation. We standardize CustomGPT workflows where appropriate, define CRM integration and data boundaries early, and adopt a clear build/partner/buy decision tree to protect focus and speed without compromising risk posture.

Here are real patterns that consistently deliver meaningful change. We’ve used generative AI for product prototyping to compress concept validation from weeks to days, then confirmed impact with rapid A/B testing tied to MDE. We’ve implemented agentic AI for customer support triage to reduce response times and free human agents for high-complexity cases, all under strict data governance. And we’ve paired new AI features with a focused go-to-market strategy—clear positioning, sharp onboarding, and outcome-centric messaging—to accelerate user activation.

Measurement makes or breaks innovation. I combine deployment frequency and DORA metrics on the engineering side with activation, retention analysis, and value-moment telemetry on the product side. QBRs vs OKRs alignment keeps leadership focused on outcomes, while experiment scorecards ensure we learn even when results are neutral. The goal is to increase the rate of validated learning across the portfolio, not just ship more.

Governance is a feature, not a tax. We embed threat detection and response, privacy-by-design, and transparent data policies from day one. Stakeholder management and board management stay tight with simple narratives: the bet, the hypothesis, the metric, the MDE, the timeline, and the kill-or-scale criteria. That clarity builds trust and protects speed.

If you’re recalibrating your innovation strategy right now, start small and deliberate: define the outcomes, select one core, one adjacent, and one transformational bet, and wire in learning loops from discovery to delivery. With empowered product teams, disciplined analytics, and a pragmatic AI Strategy, you can move from interesting ideas to durable competitive differentiation—faster and with far less risk.

Inspired by this post on Product School.

November 3, 2025
Build Customer Feedback Loops That Actually Drive Growth and Get Your Product Unstuck

What if your customer feedback loop is the reason you're stuck? Learn how to build one that fuels real growth and changes your product for the better.

I’ve seen talented teams spin for months because their customer feedback loop was noisy, slow, or misaligned with outcomes. The result is predictable: roadmaps packed with output, not impact. When we design feedback loops that are intentional, instrumented, and closed with customers, the product starts compounding value—and the business moves from reactive to product-led growth.

My definition of a strong customer feedback loop is simple: capture the right signals, synthesize them quickly, prioritize against outcomes, experiment to de-risk, and close the loop visibly with customers. If any link is weak, the whole system underperforms. More feedback isn’t better—better feedback is better.

Start with who you listen to. Segment feedback by persona, account tier, lifecycle stage, and “jobs to be done.” A founder’s feature request, a new user’s onboarding friction, and a power user’s edge case should not be weighted the same. This is the foundation of credible product discovery.

Instrument your product so qualitative and quantitative signals reinforce each other. I rely on funnel and cohort views in Amplitude analytics to see where activation or retention breaks, then layer in interviews, support tickets, and community threads for context. When telemetry and narrative align, the signal gets unmistakable.

Capture feedback where the user is. In-app guides and lightweight surveys via Pendo or Intercom surface timely prompts during key journeys (onboarding, activation, adoption, renewal). Pair those with structured inputs from sales notes and customer success reviews so you don’t bias toward only the most vocal users.

Standardize how you synthesize. Tag every item by problem statement, persona, job, and affected step in the journey. Roll these up into weekly themes your product trios can act on. The discipline here turns anecdotes into addressable opportunities.

Prioritize against outcomes, not volume. If your OKRs are outcomes vs output OKRs, tie each opportunity to a measurable product outcome like user activation rate, adoption depth, conversion, or retention. A thousand upvotes mean less than a clear path to move a core metric.

De-risk with evidence, not opinion. Frame hypotheses, define success metrics, and run A/B testing with a clear minimum detectable effect. Guardrail metrics matter—never trade a short-term click lift for a long-term retention drop. Experiments should accelerate learning, not justify pet projects.

Fold learning into product roadmapping and sprint planning. I expect prioritized feedback themes to map to roadmap bets with clear owners, milestones, and expected impact. This is how product management leadership signals what we will do—and what we will not do—based on evidence.

Close the loop, every time. Tell customers what changed because of their input—release notes, in-app messages, CSM follow-ups, or community updates. When people see their voice shaping the product, engagement and loyalty rise. This is also how you earn higher-quality feedback next time.

Set a cadence and governance that sticks. A weekly Voice of Customer review for the product trio, a monthly synthesis for cross-functional stakeholders, and a quarterly lookback tying changes to retention analysis creates organizational memory. Feedback isn’t a meeting; it’s a muscle.

Beware common failure modes. Don’t overweight loud accounts, confuse feature requests with problems, or ship one-off fixes that fragment your value proposition. Avoid vanity dashboards that show activity without decision-making power. If your loop doesn’t routinely change priorities, it isn’t a loop—it’s a suggestion box.

If you’re starting from scratch, keep it simple: define your core outcomes, instrument the top journeys, establish two capture channels (in-app and human-led), create a shared taxonomy, and commit to a weekly synthesis ritual. In a few cycles, you’ll see cleaner insights, tighter bets, and faster learning.

Done right, customer feedback loops are a competitive advantage. They sharpen product discovery, accelerate user activation, and compound retention—exactly what a modern, product-led organization needs to grow with confidence.

Inspired by this post on Product School.

November 3, 2025