Your PM Retrospectives Are Lying to You

According to the article, product team retrospectives often fail because success criteria are not defined before work begins, leading to post-hoc rationalization rather than genuine evaluation. The author argues that effective retrospectives require pre-written, measurable success metrics and a clear identification of the initiative's "killer assumption" to enable honest learning. The key to compounding team growth is not shipping speed, but the ability to learn fast by knowing what you were trying to prove before you started.

Every quarter, product teams hold retrospectives. Someone asks "what went well?" and "what didn't?" The team lists bullet points. Someone writes "we should communicate better." Everyone nods. Nothing changes. The problem isn't the retro format. It's that you never defined what success looked like before the work started — so you can't actually evaluate anything now. I've run product teams at iQIYI, NIO, and Alibaba. The retrospectives that mattered had one thing in common: a pre-written success criterion that existed before any work began. Every other retro was theater. When you define success after seeing the results, you unconsciously fit the definition to the outcome. If engagement went up 5%, that was the goal. If it went down 5%, you pivot to "we learned a lot." The retro becomes a narrative exercise, not a learning exercise. Real learning requires a pre-mortem question: "What would we need to see to know this worked?" That question, answered before the sprint starts, is the only thing that makes a retrospective honest. Before any significant initiative, write answers to these four questions: 1. What is the decision we're making? Not "build feature X." The actual decision: "Are we betting on engagement-led growth over acquisition-led growth this quarter?" Name it. A decision that can't be stated in one sentence is a decision you haven't made yet. 2. What does success look like — exactly, in advance? One sentence. Measurable. Time-bound. Not "improve retention" but "increase D30 retention from 22% to 28% by July 15." If you can't write this before you start, you're not ready to start. 3. What's the killer assumption? Every initiative rests on one belief that, if wrong, invalidates the whole effort. Find it. Name it. Write it down. "We're assuming that power users are churning because of the onboarding flow, not the core product." If that's wrong, no amount of onboarding optimization saves you. 4. When is the assumption review date? Not the ship date — the date you'll check whether the assumption held. Six weeks post-launch, you open the document and ask: did the metric move? Did the assumption prove correct? This is the only retrospective question that matters. With pre-written criteria, your retro becomes a one-page debrief: That's it. No "communication" bullet points. No vague learnings. Just a clear verdict on whether the bet you made was right, and what you now know that you didn't before. The teams that compound the fastest aren't the ones that ship fastest. They're the ones that learn fastest — and learning requires knowing what you were trying to prove before you tried to prove it. I built a complete 4-step decision framework around this: https://dcljoyful.gumroad.com/l/toPM