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.
The retrospective trap
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.
The four questions that fix retrospectives
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.
What honest retrospectives look like
With pre-written criteria, your retro becomes a one-page debrief:
- Did the metric hit the target? (Yes/No, with data)
- Did the killer assumption hold? (Yes/No, with evidence)
- What does this tell us about the next decision?
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
