I read an interesting study from Metis Strategy this week that basically that if 2025 was the year of AI experimentation, 2026 is the year of proof. Boards and leadership teams want to know what the AI investment actually changed not what shipped, what changed. And a lot of teams built the pilot but never built the reporting or feedback loop. They can describe what they shipped without being able to prove what it worked. I think that the feedback loop is probably the Product Manager's to solve. Which by default means the PM role isn't shrinking because of AI. Instead we are being asked to use our judgement to decide what is worth building, prove it works, and know when to pull the plug. Just like always. :) How are you measuring whether what you built with AI is actually working?

Discovery is a "you are here" problem Every mall map and trailhead sign has that little flag: YOU ARE HERE. You can't navigate without it. New product, new company, or a discovery cycle on something vague? Same deal. The instinct is to jump straight to the roadmap. But a roadmap drawn before you've located yourself is just a confident guess about someone else's campus. Your first customer conversation isn't really about the product. It's about finding the flag. Questions like: - Walk me through the last time you dealt with this. What did you actually do? - What have you already tried? Why did you stop? - If nothing changed for a year, what would that cost you? Notice none of those pitch anything. They locate you: where the pain actually lives, what's already been ruled out, and whether this problem even matters enough to build for. Where do you start when you're handed a blank product space? What's your first question, and why that one?

Looks like nobody could make it last night. Thought I'd share where my head is at on Product Disocvery anyway, in case it's useful. I still start where I always start: BJ Fogg Fogg's model is B = MAP. Behavior happens when Motivation, Ability, and a Prompt show up at the same moment. If a behavior isn't happening, one of those three is missing. The reason I keep coming back to it for discovery is that most discovery asks people what they want. Fogg's model says wanting isn't usually the constraint. Motivation is the least reliable leg of the three because it moves around constantly. So if you build on what people say they want, you're building on the wobbliest part. Ability and prompt are where the leverage is. Practically, that changes the question. Instead of "would you use this," you ask "what happened the last time you tried to do this, and what stopped you." One gets you enthusiasm. The other gets you friction, which is the thing you can actually design against. His other idea that shows up in my work a lot: target behaviors, not outcomes. "Get healthier" isn't a behavior. "Floss one tooth" is. Most feature requests are outcomes wearing a costume, and the job is getting back to the behavior underneath. How I've traditionally thought about discovery: Interviews. Contextual inquiry. Surveys when the question is countable. Usability testing. Session replay for what happened, analytics for how often, and then talking to people for why. A repository so the last six months of learning doesn't evaporate. None of that has stopped working. Three things have genuinely shifted, and I'd separate them: - AI-moderated interviews. Running conversational interviews in parallel and getting a synthesis back the same day. This is the real change, and it's the one I'm most curious about. - Feedback aggregation. Pulling support tickets, sales calls, and surveys into one place and finding themes across all of it. Mostly this means you can now read things nobody had time to read before. Hard to argue with. - Synthetic users. AI-generated participants you interview instead of people. I haven't used them. I'm open to it, and I'm also suspicious, and I'd like to talk to someone who has.

Quick reminder: we're planning to meet next Tuesday, July 28th. We're diving into the changing roles in product management. And I think this one matters because a lot of folks come into PM thinking there's one way to do it. One archetype. But the reality is way messier and more interesting than that. Want to check to see who is thinking they'll be able to join? If everyone is on holiday, we can postpone to August?

Four of us sat down to talk about Prioritization Hell. A few things that stuck with me: - Clear is kind. Brené Brown said it and every one of us had a story that proved it. The support team that replaced "we've logged your feedback" with "honestly, there's a 0.5% chance this happens" — and customers thanked them for it. The product leader who killed a low-traffic website simply by saying it wasn't in Q2, Q3, or Q4. They shut it down. Right outcome, finally. - Frameworks are a communication tool, not a decision engine. Did the iPhone come out of a spreadsheet? Use RICE when you have a specific problem. Use it to break a tie. Use it to teach a junior PM how to think. Don't use it to pretend a decision you've already made is data driven. - The hardest no isn't the off-strategy stuff. That gets easier with experience. The hard no is the thing that's genuinely good, has real support, and you still have to kill it because you only have so much bandwidth and you have to protect the best stuff. - AI is making prioritization harder, not easier. Everyone sees what's possible now. The CFO wants to know why you can't ship faster. The backlog got longer. The requests got louder. "I've created a monster" was said out loud by at least one person in the room. This is what The Product Room is for. Not slides. Not frameworks. Just honest conversation with people who've been in the same rooms. Next session coming next month. Watch this space. @Rob Taylor @Therese Alburg @Jay Fluegel what landed for you last night? Did I miss anything? Drop it below.