Learn
A short, honest retrospective. Two questions: did this do what we set out to do? What would we do differently?
This is not a debrief meeting with a full-team agenda and a Miro board. It's a brief, deliberate pause to look at what actually happened and capture what's worth carrying forward. Keep it tight. The goal is signal, not coverage.
Did It Work?
Go back to the problem statement from Discover. The feature shipped. Is the problem solved?
Look at the metrics you defined in Define. If you said "reduce support tickets by 30%," check the ticket volume. If you said "increase completion rate on the scheduling flow," check the completion rate. Give it enough time to be meaningful — one week for features with high daily usage, longer for lower-frequency workflows — but don't wait so long you've forgotten the context.
Be honest. "We don't know yet" is a valid answer when data is thin. "It seems to be working" is not — either you have the number or you don't. If you can't measure whether it worked, that's the most important learning: you didn't define success well enough in Define, and you won't make that mistake on the next one.
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 you estimated? These are different failures with different implications, and collapsing them into "the feature underperformed" doesn't help you.
What Would You Do Differently?
Think through the whole journey. Discover, Define, Build, Launch — where was the friction? Where did you lose time? Where did a decision in an earlier stage make Build harder? Where did something go better than expected?
Be specific. "Communication could have been better" is not a learning. "We defined the milestone as 'backend complete' but didn't align on what complete meant, and spent two days resolving that" is a learning. Specificity is what makes a retrospective useful.
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 of work? What open source tool turned out to be perfect? 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 doesn't get better at achieving success.
What Carries Forward
After the retrospective, there are usually two kinds of things to act on. Process changes — things about how we ran this project that we should change for the next one. And product decisions — things about the feature itself that we should iterate on now that we have real usage data.
Process changes go into how we approach the next project. If you found that release notes were always rushed, add time for it. If Define sessions kept running long because the problem wasn't specific enough, add a "is the problem statement complete?" check before scheduling Define.
Product iterations go back into the discovery queue. They're just new problems — informed by real data from the launch — and they move through the same stages. Discover, Define, Build, Launch, Learn.
The cycle doesn't end. It just gets better.
Back to: How Systeric Works