Learn
A short, honest retrospective. Two questions: did this do what we set out to do? What would we do differently?
Keep it tight. The goal is signal, not coverage.
Did It Work?
What's expected: You go back to the problem statement from Discover, look at the metrics defined in Define, and give an honest answer on whether the problem was solved.
What good looks like: A specific, data-backed answer. Not "seems to be working" — either you have the number or you don't. "Rebooking time dropped from 10 minutes to 2 minutes, support tickets from that flow are down 60%" is good. "Users seem happy" is not.
How to get there:
Give it enough time to be meaningful — one week for high-frequency features, longer for lower-frequency workflows. Then look at the metric you defined. Compare against the target. If you can't measure whether it worked, that's the most important learning: you didn't define success well enough in Define.
If it didn't work — or worked less than expected — figure out why before moving on. Did you solve the wrong problem? Was the solution right but the execution off? Was the problem real but less impactful than estimated? These are different failures with different implications.
Tools:
- Iceberg model — if results are below expectations, use this to ask whether there are underlying patterns or structures that the feature didn't address. Often a miss points to a problem that was defined too narrowly.
- Second-order thinking — did the feature produce any unintended effects? A feature that hits its primary metric but creates a new problem elsewhere is a partial success at best.
What Would You Do Differently?
What's expected: Specific, actionable observations about the process — not categories, not vibes.
What good looks like: "We defined the milestone as 'backend complete' but didn't align on what complete meant, and spent two days resolving that" is a learning. "Communication could have been better" is not.
Think through each stage: Discover, Define, Build, Launch. Where was the friction? Where did a decision made early make something downstream harder? Where did something go better than expected?
How to get there: Go through the timeline and mark moments where you either lost time, made a decision you later regretted, or did something that made the next step easier. For each: what was the decision, what was the effect, what would you do differently?
Tools:
- Productive thinking model — structured approach to move from "what went wrong" to "what could be better" to "what will we actually change." Keeps the retro from being only a complaint session.
Wins and Learnings
This is not just about what went wrong. It is also a space to share what worked.
What creative approach paid off? What did the engineer do that saved the team a week? What AI prompt produced output that was better than expected? What decision in Define made Build unusually smooth?
Share it. These learnings compound. A team that documents what worked builds a playbook over time. A team that only documents what went wrong gets better at avoiding failure but not at achieving success.
What Carries Forward
After the retro there are two kinds of things to act on: process changes and product iterations.
Process changes go into how you run the next project. If Define sessions kept running long, add a "is the problem statement complete?" check before scheduling one. If release notes were always rushed, budget time for them in the release plan.
Product iterations go back into the discovery queue as new problems — informed by real usage data — and move through the same stages again.
The cycle doesn't end. It just gets better.
Back to: How Systeric Works