Learn
A short, honest retrospective. Two questions: did this do what we set out to do? What would we do differently?
Do this together. Learn is a team session with PM, PD, and PE in the room. Not a PM-written summary sent async. The shared debrief is where the real learning happens: different roles saw different things, and the combination is what’s valuable. Keep it tight, but do it live.
The goal is signal, not coverage.
Did It Work?
PM and Tech review different things. Both matter.
PM reviews impact and adoption. Go back to the problem statement from Discover and the success metric defined in Define. Did the problem get solved? Is the feature being used by the people it was built for? Adoption and impact are PM’s accountability. Not just whether the feature shipped, but whether it landed and moved the number.
Tech reviews the quality of what was built. Is the code maintainable (can someone who didn’t write it understand and change it)? Is it performant under real load? Will it still work when usage doubles? Did anything degrade as a result of this release? These are the engineer’s accountability. Not just “it shipped,” but “it was built right.”
What good looks like: Both reviews have specific answers. “Cart save rate is at 43%, above our 40% target. Adoption in the first two weeks was 28% of eligible sessions.” (PM.) “No performance regressions. The session logic is clean, well-tested, and the next engineer to touch it will be able to follow it.” (Tech.) Not vibes. Honest assessments.
How to get there:
Give it enough time to be meaningful: one week for high-frequency features, longer for lower-frequency workflows. 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.
Knowledge Artifact
Every project produces something the team did not know before. Leave a record of it.
Before the Learn session closes, PM and PE each write a short answer to: what would someone need to know to work in this area with confidence? Not a full design document. One paragraph per significant decision, written for the next person who touches this.
PM covers: why this problem was prioritized, what was tried and cut in Discover or Define, what trade-offs shaped the solution, what to watch for based on how it performs.
PE covers: how this area works at a high level, why it is structured the way it is, what the non-obvious constraints are, what someone would need to know before making changes here.
This lives in the project record. When someone new comes into an area — a new hire, an engineer picking up a bug fix six months later — this is what they read first.
If either answer takes more than ten minutes to write, the scope is too broad. Keep it short enough that it actually gets read.
Related: Collective Knowledge
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