🎙️Recorded Conversations We now record almost everything — every meeting has an AI note-taker, and some people wear glasses that capture every word. So what does that do to our relationships when nothing is forgotten and everything can be fact-checked? Petra Wille and Teresa Torres explore the promise and the unease of a fully-transcribed world. Teresa shares how checking her own Granola transcripts revealed she'd been misremembering conversations — and getting frustrated with people over things she never actually said. Petra describes the strange feeling of a colleague pulling up a transcript to correct her recollection of her own past opinion. Together they get to the bigger question: should we hold people accountable to what they said weeks ago, or grant each other permission to evolve? Key Takeaways 🧠 Your memory is not a recording — Teresa's transcripts repeatedly showed her that her confident recollections didn't match what was actually said. 🪞 Use it on yourself first. Checking your own transcripts to spot blind spots feels very different from having someone use them against you. 🌱 Give people permission to evolve. What someone said three weeks ago matters far less than what they think now. ⚖️ The same record can be a collaboration tool or a weapon — the difference is intent and the permission to change your mind. 🔍 Notes ≠ transcript ≠ truth. Each layer adds interpretation, so don't build a conversation on a record you haven't verified. Pull Quotes 🗣️ "My perception of reality is not the same as reality." — Teresa 🗣️ "Why does it matter what you might have said three weeks ago? Doesn't it matter more what you think now?" — Teresa 🗣️ "We need to grant each other the right of evolved opinions." — Petra 🗣️ "My brain just made up a whole new t-shirt that does not exist in the world." — Teresa Links to Spotify, Apple Podcasts, and YouTube: 📺Youtube: 🎵Spotify: 🍎Apple Podcast: Give it a listen and share your thoughts in the comments below.💬👇

Product management is laced with one stubborn bias: we overvalue our own ideas about what to build next. Steve (Vistaly) says minds rarely change until teams hear customers describe the problem in their own words. That's why Vistaly puts interview evidence directly on the opportunity solution tree—so everyone can quickly hear it, see it, and align on what the real problems are. 👉 Find a link to the full episode here: Spotify: Apple Podcast: YouTube:

Inspired by Git diff, Teresa Torres started simple: compare the input tree to the output tree and generate a change set. Then she learned the same pair of trees can produce multiple change sets—and only one tells the real story. A semantic merge means something very different from a delete plus reassigned sources. The fix: teach the agent a game with rules for meaningful moves, and log every move as it builds the tree. 👉 Find a link to the full episode here: Spotify: Apple Podcast: YouTube:

Teresa Torres wants to believe every product team does careful synthesis after each customer interview. The reality? It's hard, so teams give up and grab the two or three things they remember most. "We're not competing with making good synthesis faster. We're competing with making shallow synthesis better." That realization reshaped the approach: if product teams won't do the deep work, maybe the software should do it for them. 👉 Find a link to the full episode here: Spotify: Apple Podcast: YouTube:

What happens when you hand your opportunity solution tree to an AI? Vistaly rebuilt its entire product to find out—and the agents were the easy part. In this episode of Just Now Possible, Teresa Torres talks with Matt O'Connell (Co-Founder and CEO), CP Dehli (Co-Founder), and Steve Klein (Co-Founder) at Vistaly, a company Teresa partners with and builds for. V1 was a purpose-built canvas for continuous discovery. V2 is a ground-up rewrite: upload customer interviews, get a snapshot of each, and let an agentic workflow draft and update your tree. They get specific about what broke. A chat-based synthesis experiment users found too slow. A "house of cards" problem where one badly framed opportunity corrupts every layer above. Teresa walks through the AI evals work behind one customer complaint—"I'll have to come back and clean up this branch"—including an LLM as a judge she couldn't calibrate and the orchestration change that fixed what no prompt could. You'll hear why change sets had to be taught to the agent as the rules of a game instead of diffed at the end, how data residency pushed them onto Bedrock, and why their hardest problem isn't output quality—it's helping people comprehend what changed. Guests - Matt O'Connell – Co-Founder and CEO, Vistaly - CP Dehli – Co-Founder, Vistaly - Steve Klein – Co-Founder, Vistaly - Teresa Torres – host of Just Now Possible, building the AI synthesis services for Vistaly V2 Key Takeaways - The competition isn't good interview synthesis done faster—it's shallow synthesis that never really happened. That changes what "good enough" means. - Layered analysis matters more than whether a step is a pipeline or an agent. If the interview snapshot is wrong, every layer above it inherits the error. - Prompt changes run out. Balancing two opposing error modes took an orchestration change—moving the check into an agentic repair loop—not a better prompt. - Change sets can't be diffed at the end. The same input/output tree pair has multiple valid change sets, and only the semantically meaningful one makes sense to a user. - Users don't want to collaborate with the AI step by step. They want the answer, then the ability to correct it. In this episode - Why Vistaly rebuilt from scratch instead of layering AI features onto V1—and shut off V1 signups to protect the rewrite - Rebuilding nearly all of V1's functionality in two and a half months, after three years of building it the first time - The V1 chat interface that walked users through insights one at a time, and why "still faster than before" wasn't fast enough - How V2 works: upload three interviews, generate an interview snapshot for each, then synthesize a first-draft opportunity solution tree - The "house of cards" problem: garbage in at the snapshot layer corrupts the tree above it - Using a code assertion (too many children on a node) as a cheap pre-filter before spending money on an LLM as a judge - Four new evals and 16 experiment variants to break a seesaw between missing subgroupings and badly framed parents - Why the fix was a repair loop in the orchestration, not a better prompt—and how that eval became a production guardrail - Teaching the agent "the rules of the game" so it logs semantic moves (merge, move, reframe) and produces reliable change sets - Stable IDs, data provenance, and the "basic computer science" Teresa swept under the rug in the prototype - What beta data revealed about interview quality: sales demos, stakeholder meetings, and LLM-generated fake transcripts uploaded as "interviews" - Building a 40-point system for generating realistic synthetic transcripts as test data - Driving tree edits through MCP, including mapping a full Jira epic backlog into the opportunity space - Adding an agent back to the canvas, and the versioning and rollback problem that comes with it - Data residency, SOC 2, GDPR, and moving to European Bedrock inference - Why model upgrades aren't drop-in: prompts are model- and version-specific, and Bedrock constrains tokens independently of the model Resources & Links - Vistaly: — Opportunity solution tree software with AI-generated interview snapshots and tree synthesis - Product Talk: — Teresa's AI evals guide and her blog posts on building the Vistaly synthesis services - Model Context Protocol: — How Vistaly users drive tree edits from outside the product - AWS Bedrock: — Where Vistaly runs inference, including EU-hosted inference for European customers - Just Now Possible episode with Banani: — the canvas-plus-agent design UX Teresa references - Just Now Possible episode with Zencity: — the layered data pyramid Teresa references - All Things Product episode on the quality of evidence, with Petra Wille: Chapters 00:00 Meet the Founders 01:05 How Vistaly Began 03:10 Community First Partnership 04:56 Why Build OST Software 07:18 OST Explained Fast 10:28 Evidence Inside the Tree 12:56 AI Changes Discovery 16:58 Chat UI Experiment 23:00 Should AI Do Synthesis 27:10 Rebuilding as V2 32:08 Turning Off V1 Signups 34:43 V2 Workflow and Tensions 39:35 Trusting AI Outputs 39:56 Layered Analysis Pyramid 41:25 Building Better Trees 43:34 Bad Inputs and Coaching 47:20 Teaching Through Software 50:12 Evals and Guardrails 55:23 Deterministic Change Sets 01:00:54 UX for Tree Updates 01:07:12 Chat Agents and Versioning 01:11:17 Privacy Compliance Tradeoffs 01:15:06 Model Selection Reality 01:17:32 What Comes Next 01:19:08 Closing and Links Listen on Spotify, Apple Podcasts, or watch on YouTube. Spotify: Apple Podcasts: YouTube:

🎙️Unpacking Innovation Is innovation the goal — or just a byproduct of solving customer problems well? In this episode of All Things Product, Petra Wille and Teresa Torres unpack one of the most misused words in product: "innovation." Teresa makes the case that chasing novelty for its own sake pushes teams toward complex solutions that don't actually serve customers better, while Petra argues that simplicity and reduction can be their own kind of innovation. Using the surprisingly rich history of the humble login — from passwords to single sign-on to Slack's magic links, 1Password, and passkeys — they explore why yesterday's breakthrough becomes today's friction, why novelty carries a hidden cognitive cost for users, and where the best innovation actually comes from (hint: it's often a cross-functional "just now possible" moment). A must-listen for product managers who want to differentiate without over-engineering — and who'd rather be great at solving customer problems than "innovative" for its own sake. In this episode 🎯 The problem with "innovation" as a target. Teresa explains why the word bothers her: when teams optimize for novel ways to serve customers, they often land on complex solutions that aren't the best ones. Petra reframes innovation as reduction — leaving things out, minimizing steps, "innovating on behalf of the user." 🔐 The login timeline. A concrete walk through how one "boring" problem kept getting reinvented: username/password → single sign-on adding a two-step flow → Slack's magic links as a genuine moment of innovation → 1Password making magic links annoying again → passkeys, which most people don't yet understand. The lesson: an innovative solution changes the industry, then stops being innovative — and sometimes the company that changes the game (1Password) isn't even the one that owns the problem. 👁️ Not all innovation is novel to the user. Something can be genuinely novel on one dimension — technical feasibility, a new framework, the business case — while looking completely ordinary to the customer. Novelty on one axis doesn't require novelty on the others. 🧠 The cost of novelty. Beyond R&D, there's a cognitive cost: every novel flow asks users to learn a new system. Passkeys are the current example — friction now, in the hope of less friction later. 💡 Where good innovation comes from. The "just now possible" moment: in a truly cross-functional team, discovery surfaces a real customer struggle, and an engineer says, "there's a new way to solve that — and it's easier." Petra's pitch for cross-functional collaboration as the source of the good kind of innovation. ✅ The bottom line. The goal is to solve the customer problem. Innovation is only valuable when it does that. There's a whole industry built around helping companies "be more innovative" — Teresa would rather help them get better at solving customer problems. Key takeaways 🎯 Innovation is a means, not the goal — it only matters when it serves the customer better. 🌀 Chasing novelty tends to produce complexity; optimizing for the best solution sometimes lands on a familiar pattern, and that's okay. ✂️ Simplicity and reduction are a legitimate form of innovation. 🧠 Every novel solution carries a cognitive cost — users have to learn it. ⚙️ A solution can be innovative for the business or the tech stack while looking totally ordinary to the user. 🤝 The most durable innovation often emerges from cross-functional discovery, not an "innovation department." ✨ Differentiation through novelty is valuable — as long as you don't drop the "when it serves the customer" part. Links to Spotify, Apple Podcasts, and YouTube: 📺Youtube: 🎵Spotify: 🍎Apple Podcast: Give it a listen and share your thoughts in the comments below.💬👇

🎙️Trash Can Tracking What if the ideas you throw away tell you more about the health of your product process than the ones you ship? In this episode of All Things Product, Petra Wille introduces trash can tracking — a deceptively simple technique for making discovery work visible. By adding trash can symbols across your discovery and delivery boards, teams can see (and celebrate) the customer problems and solutions they deliberately choose not to pursue. Petra and Teresa dig into what an empty problem-space trash can versus an empty solution-space trash can each signals about your team's innovation, strategy, and discovery culture. Along the way they wrestle with the "golden trash can," the hidden cost of solving every customer problem that lands on your plate, and how psychological safety shapes which problems ever surface in the first place. Whether your trash cans are overflowing or suspiciously empty, this conversation will change how you think about the work you decide to walk away from. Key takeaways 🗑️ Trash can tracking means placing trash can symbols along your discovery and delivery boards so that discarded work is tracked as deliberately as delivered work. ❓ It helps answer two questions leaders and teams ask often: "Are we innovating enough?" and "Is our discovery actually working?" 🏆 The "golden trash can" is what happens when a shipped feature flops and the team removes the code — Petra and Teresa debate whether that belongs on the delivery board (as wasted effort to avoid) or the discovery board (as learning to celebrate). 🚩 An empty solution-discovery trash can is a clear red flag: it means the team isn't comparing and contrasting multiple options. 🧐 An empty problem-space trash can is more nuanced — it could signal an innovation gap, a command-and-control culture, or, if your strategy and vision are strong, a perfectly healthy filter working as intended. 🛡️ Whether customer problems even reach the board depends on psychological safety — can support agents, salespeople, engineers, and customers all bubble problems up to be assessed? 🧟 The trash can also becomes a ritual for retiring "zombie opportunities" — decisions a team made to walk away from a problem that the rest of the org keeps resurfacing. Also discussed 🙅 Why saying no to certain customer problems is a sign your strategy is actually working. ♻️ A brief detour into German recycling supremacy. 🔮 A teased future episode: "Unpacking Innovation." Links to Spotify, Apple Podcasts, and YouTube: 📺Youtube: 🎵Spotify: 🍎Apple Podcast: Give it a listen and share your thoughts in the comments below.💬👇

"It can feel like you are the lone champion pushing for change in your organization." That's why we are reading Continuous Discovery Habits together throughout 2026. 📚 The book turns five this year and many of you have bought and read it. But reading isn't the same as doing. So we are reading together—one section per month—with discussion questions, practical exercises, and resources to help you actually build the habits. Here's what you'll get each month: 📖 Monthly reading guides with reflection questions and exercises 🎥 Short videos you can share with teammates to spread the ideas 💬 Quarterly live discussion sessions to connect with other practitioners By December, you won't just understand continuous discovery—you'll be practicing it. This month's reading covers Chapter 10—it's all about testing the assumptions your ideas depend upon. We'll cover good test design, how to define success criteria upfront, and we'll even cover the risk of false positives and false negatives and how to mitigate them. Read the chapter: 🤔 Does your team systematically test your assumptions? Share your experience in the comments.

Product managers keep coming back to Aha! with the same request: "This prototype is great—now I want it to actually integrate with other systems and do real things." Chris (Aha!) explains how that moment—prototype meets production—reshaped their roadmap. Instead of handing the app to an engineer, Aha! built the tooling for PMs with zero coding experience to build, run, and operate a working application on their own. 👉 Find a link to the full episode here: Spotify: Apple Podcast: YouTube:

The supermarket shelf used to hold maybe 1,000 SKUs. Now it can hold 10,000, because AI makes it just as easy to build the wrong thing as the right one. Brian (Aha!) argues this is exactly where product managers earn their keep: strategy and discovery decide what deserves a spot on the shelf. Builder plugs directly into that workflow—turning roadmap strategy into deployable prototypes, collecting real feedback, and promoting validated ideas straight into production. 👉 Find a link to the full episode here: Spotify: Apple Podcast: YouTube:

Customers describe the problem right in front of them—not their wildest dreams. That's the trap Chris (Aha!) sees teams fall into during discovery. "It's very difficult for them to imagine that you might deliver their wildest dreams." The real skill in product discovery is extrapolation: taking that small, literal ask and building outward—using the customer persona to predict what they'll need next, before they ever ask for it. 👉 Find a link to the full episode here: Spotify: Apple Podcast: YouTube:

What does it take to build an AI app builder specifically for product managers—not engineers—inside an already crowded market? In this episode of Just Now Possible, Teresa Torres talks with Brian De Haaff (CEO and Co-Founder), Chris Waters (CTO and Co-Founder), and Sarah Moisan-Thomas (Senior Product Manager) about Aha! Builder, Aha!'s AI-powered app builder built for product managers. Aha! is a fully bootstrapped, profitable, remote-first company that has served product teams for over 13 years without a single salesperson. Guests: - Brian De Haaff – CEO and Co-Founder, Aha! - Chris Waters – CTO and Co-Founder, Aha! - Sarah Moisan-Thomas – Senior Product Manager for Aha! Builder, Aha! They walk through Aha!'s five-step product discovery framework—spark, paper prototypes, proof of concept, early access, and general availability—that led them to Builder. They share why their first version, built on containerized Ruby on Rails infrastructure, proved too wasteful to scale, and how they rebuilt it on a single-instance, multi-tenant architecture using V8 isolates. Along the way, they explain their approach to deterministic guardrails for things like authentication, SSO, and databases, and how a multi-phase, multi-agent pipeline generates a design system, a prototype, and a working application in minutes. You'll hear how they think about the line between what AI should build and what should stay deterministic, how they handle enterprise concerns like SSO and PII, and why they believe knowing what to build—not how to build it—is where product managers will increasingly add value. Key Takeaways: - Aha! is fully bootstrapped, remote-first, and profitable—built by product people, for product people - Containerized infrastructure proved too wasteful for AI app building at scale, pushing Aha! to rebuild on a single-instance, multi-tenant architecture - Deterministic, pre-built components (authentication, SSO, database, email) cut token cost and guarantee reliability that AI-generated code can't - A multi-phase, multi-agent pipeline—design system, then prototype, then backend—produces better outcomes than a single open-ended chat prompt - As building gets easier, knowing what to build becomes the product manager's real differentiator In This Episode: - Aha!'s 13-year bootstrapped, remote, no-salespeople business model - The five-step discovery framework Aha! uses for every new product, including Builder - Why their first containerized version was too slow and expensive to scale - Rebuilding for a single-instance, multi-tenant architecture - Reusing the agent framework and tool set originally built for "Elle"—Aha!'s roadmapping AI assistant - Deterministic components for authentication, SSO, database access, and email - The multi-agent, multi-phase build pipeline: design system, then prototype, then full application - Enterprise governance: authentication policies, deployment guardrails, and PII/PHI considerations - Why Aha! is optimizing for prototypes, proofs of concept, and internal "meta applications"—not primary line-of-business apps - What's next: expanded design systems and tighter feedback loops across Aha!'s product suite Resources & Links: - Aha! Chapters: 00:00 Meet the Aha! Team 00:19 Aha! Bootstrapped Remote Story 01:29 What Is Aha Builder 02:27 Leaders Stay Hands On 04:49 Origin and AI Shift 07:44 Why Build in Aha! 14:12 Discovery Framework 17:50 From Slides to Early Access 21:40 Proof of Concept Approach 23:36 Under the Hood Architecture 27:01 Agent Tools and UX 30:59 Deterministic Components 33:42 Skills Docs and Iteration 35:48 Higher Level Building Blocks 36:33 Knowing What To Build 38:57 Builder UX For PMs 44:10 Enterprise Governance Guardrails 47:29 What Builder Is For 50:39 PII Security And Compliance 53:15 Quality Evals And Pricing 55:29 V8 Isolates Architecture 58:22 Multi Agent Build Pipeline 01:01:14 Roadmap Design And Feedback 01:03:01 PMs Engineers And PR Flow 01:05:52 Wrap Up And Thanks Listen on Spotify, Apple Podcasts, or watch on YouTube. Spotify: Apple Podcast: YouTube:

💭 "I wish I could click on this card and be like, 'Clean this up.'" When a customer pointed out a flat, unstructured branch in her AI-generated opportunity solution tree, it sparked a three-week journey to fix the problem at its source. Here's what you'll learn from this article: How one customer complaint led to building 4 new AI evaluation metrics and testing 16 different experiment variations to get to the root cause—and why a quick fix wasn't the answer. Key takeaways: 🔍 Building reliable AI products requires more than just prompt engineering—you need evals, guardrails, and orchestration working together 📊 Calibrating your AI judges against production data is harder than it sounds; your judges can fail in ways you don't expect ⚖️ Fixing upstream errors (like poorly framed parents) is essential, but it can accidentally make downstream errors worse 🔄 Sometimes the best solution isn't tweaking prompts endlessly—it's building an agent that audits its own work and fixes mistakes 🎯 Sweating the details matters because the real benefit of an opportunity solution tree is knowing exactly what to work on next Read the article: ❓ What's one quality issue you've noticed in AI outputs that seemed simple to fix but turned out to be more complicated than expected? Share your thoughts in the comments below.

🎙️Delivery Isn’t Free Everyone's saying it: "Now that AI makes delivery free…" But is it? In this episode of All Things Product, Petra Wille and Teresa Torres pull apart one of the most repeated claims in product right now. They dig into why building a single feature has gotten dramatically cheaper — while building a real, production-quality product has not. Teresa breaks down what happens when teams treat coding agents as "free": spaghetti code, Frankenstein data models, feature bloat, and the maintenance nightmare waiting three weeks down the road. Along the way, they unpack the crucial difference between build to learn and build to earn, why the last 30% of a product is where the real work lives, and why AI products (not just AI-assisted code) are far harder to ship than the demos make them look. If you've been tempted by the "delivery is free, taste/discovery is all that matters" narrative, this conversation is your reality check. Delivery got cheaper. It did not get free — and it never will. Show Notes 💸 Petra Wille and Teresa Torres take on the popular claim that AI has made software delivery essentially free — and explain why that framing falls apart the moment you care about shipping something real. 🧱 Why "building a single thing" getting cheaper doesn't mean delivery is cheaper — especially when teams respond by building far more things 🧟 The three-week feature spiral: how "free" delivery quietly produces Frankenstein data models, duplicated code in 17 places, and tanked performance 👷 Why you still need a skilled engineering team observing and steering what AI produces — and why architecture decisions can't be outsourced to a coding agent 🧪 Build to learn vs. build to earn (via SVPG): throwaway prototypes for discovery are dirt cheap and great — as long as you actually throw them away 📱 The app store paradox: apps released are spiking, but apps actively used stay flat — and how users are getting sharper at sensing "AI app slop" 🤖 Why AI products are a different beast than deterministic code — error analysis, evals, LLM-as-judge, prompt and orchestration iteration all take real time 🌳 A candid behind-the-scenes look at building AI-generated opportunity solution trees with Vistaly, and the quality issues only a domain expert can catch ⏳ The 60–70% trap: getting to a good-looking prototype is fast; closing the last 30% to a trustworthy product is months to years of work 🔑 The real hidden sentence: "Delivery is free" is almost always followed by "…so taste is all that matters" or "…so discovery is all that matters." Both are wrong. Delivery and discovery both matter — forever. Notable Moments are in the comments. Links to Spotify, Apple Podcasts, and YouTube: 📺Youtube: 🎵Spotify: 🍎Apple Podcast: Give it a listen and share your thoughts in the comments below.💬👇

Later this month I'll be hosting two mini-workshops on the skills that I think will differentiate the best product teams from the rest. AI Evals: The New Discovery Habit 🗓️ September 23, 2026, 9am-10:30am PDT In this session, you'll get introduced to what AI evals are, you'll receive a blueprint for how to get started with this new skill, and we'll leave ample time for your questions. We'll explore both how you can use evals in your personal workflows and in your customer-facing products and features. Story-Based Customer Interviews 🗓️ September 24, 2026, 9am-10:30am PDT As delivery gets cheaper and faster, it becomes more tempting to simply build every idea. Choosing what to build is becoming more critical than ever. In this session, you'll get introduced to story-based customer interviewing. You'll learn why continuously collecting customer stories is the secret to uncovering opportunities that can guide what we build next. And you'll get a round of hands-on practice with this new skill. Both workshops are free for Supporting Members and CDH Members of Invites go out to all subscribers one week before the event. Get access by subscribing today. To subscribe, go to On desktop, click on the Subscribe button in the top right. On mobile, the Subscribe button is at the bottom of the hamburger menu.

🎙️Facilitation Skills Conflict on a product team isn't a warning sign — the absence of it usually is. In this episode of All Things Product, Petra Wille and Teresa Torres tackle a question Teresa hears constantly: what should a product trio do when collaboration breaks down and disagreement turns into friction? Petra makes the case for something many teams quietly abandoned — the retrospective — and argues that facilitation is a genuine, learnable skill that product people should invest in, not outsource by default. Teresa introduces a framework from academic research on team dynamics: the distinction between task conflict (we disagree on how to do the work) and relationship conflict (something about how we work together puts us at odds). The two require completely different responses, and confusing them is where teams get stuck. Together they get practical about team charters, when to bring in a neutral third party, how to choose that person, joint escalations, and why running an experiment often beats arguing over opinions. If your trio is avoiding hard conversations — or having the same one on repeat — this one's for you. Key takeaways 🔄 Retrospectives still work. Agile may feel unfashionable, but the practice of pausing to ask "how are we working together?" is one of the most valuable things a team can protect time for. 🎤 Facilitation is a skill, not a personality trait. Someone in the organization needs to be good at it — and product people should be learning it, not just relying on an agile coach or scrum master. 📜 Team charters go deeper than mission statements. The powerful version isn't "what's our outcome" — it's working hours, communication preferences, and how each person likes to make decisions. Making implicit norms explicit prevents friction before it starts. ⚖️ Task conflict vs. relationship conflict. Task conflict is disagreement about the work. Relationship conflict is about how you work together. Team charters address the second; shared discovery addresses the first. 👍 Task conflict is good. It's how teams get to better problem solving. If there's none at all, that's likely a psychological safety problem, not a harmony win. 🗣️ Bring task conflict to the team. What looks like two people disagreeing is often a disagreement others share silently — or one someone else on the team can resolve. 🤝 Relationship conflict starts one-on-one. Try to resolve it directly first; HR or mediation is the escalation path, not the opening move. 🎯 Choose your facilitator deliberately. Ask whether context helps or hurts. An embedded agile coach may know too much history to stay neutral; sometimes the product person — or a senior engineer with strong facilitation instincts — is the better pick. 🚪 Leave your ego at the door. A facilitator writes the headline post-its and nothing else. Skilled facilitators even signal role changes physically — Petra describes one who literally switched chairs to mark "team member" vs. "facilitator." 🧪 When it's opinion vs. opinion, run an experiment. Design a test rather than escalating a debate. 📝 Joint escalation as a tool. Having both parties write down the conflict together often shrinks it — and gives leadership something concrete when escalation is needed. Links to Spotify, Apple Podcasts, and YouTube: 📺Youtube: 🎵Spotify: 🍎Apple Podcast: Give it a listen and share your thoughts in the comments below.💬👇

AI evals have been the "it" skill for product teams for over a year. I've even called evals a new discovery habit. But I still meet product teams who only have a vague idea of what evals are. And it's not their fault. Most of the writing on this topic is intended for engineers or just isn't specific enough. I recently created an in-depth eval guide to explain what evals are and why product teams can and should create them. I did my best to make it practical, hands-on, and easy to follow. AI evals (short for evaluations) are methods for measuring whether an AI product or workflow is performing well. Evals give teams confidence that their AI applications are doing what they expect them to do. They help teams maintain quality and catch issues before they reach users. Similar to other discovery habits like interviewing and assumption testing, evals can act as a feedback loop to ensure we are on the right track. If you want to learn more about this new discovery habit, explore my new guide:

"The only way to know if our AI products and workflows are any good is with evals." 💡 If you're using AI to write PRDs, analyze customer feedback, or build customer-facing AI products, you need to understand evals. This guide breaks down what evals actually are and why product teams should be building them. Here's what you'll learn: 🔍 What evals are and why they're different from traditional software testing
📊 How to do error analysis to identify which mistakes matter most
🛠️ Four types of evals: golden datasets, code assertions, LLM-as-a-Judge, and customer feedback
✅ How to choose the right eval for each type of error
🔄 How to run experiments and measure if your changes actually work The key insight: with LLMs, you can't just test once and expect the same result. You need to measure how often your AI gets it right, and that starts with defining what "right" actually looks like for your specific product. Check out the article: ❓ What's one error you've noticed in an AI tool you use regularly? Share your thoughts in the comments below.