How to write a product retrospective document requires going beyond "what went well / what didn't" to answer the question that determines whether the retrospective actually changes anything: what specific behavior will be different next sprint, who owns the change, and how will we know if it worked?
Retrospective documents that list observations without owners and deadlines produce the same observations every sprint. The discipline of writing a retrospective document — rather than just running a meeting — forces specificity that verbal retrospectives avoid.
What Belongs in a Product Retrospective Document
H3: Section 1 — Sprint or Cycle Summary
One paragraph context: what was the sprint goal, what was completed, what was not, and what was the overall team health during this cycle?
H3: Section 2 — What Worked (Preserve)
List the practices, decisions, or processes that contributed positively to the sprint. For each:
- What specifically worked?
- Why did it work? (Causal, not just correlation)
- How do we preserve this in the next sprint?
H3: Section 3 — What Didn't Work (Change)
List the practices, decisions, or processes that created friction, delay, or quality issues. For each:
- What specifically failed?
- What was the root cause? (Use 5 Whys if needed)
- What specific change would address the root cause?
The root cause is the most important field. Teams that list symptoms ("we were blocked for 2 days") without root causes ("our deployment pipeline requires manual approval from a team in a different timezone") will address the symptom next time and experience the same blocking again.
According to Lenny Rachitsky's writing on engineering team health, the most common retrospective failure is listing symptoms rather than root causes — the "what didn't work" section should always end with a cause, not just a description of the effect.
H3: Section 4 — Action Items (With Owners and Deadlines)
Every item in "What Didn't Work" should generate at least one action item. Format:
| Action | Owner | Deadline | Success criterion | |--------|-------|----------|------------------| | Add async approval option to deployment pipeline | Eng lead | Next sprint | No cross-timezone blocking in sprint N+1 | | Clarify acceptance criteria before sprint planning | PM | Sprint planning T-2 days | Zero mid-sprint criteria changes |
No action item without an owner is real. No action item without a success criterion is measurable.
H3: Section 5 — Review of Previous Action Items
Before ending the retrospective, review action items from the previous retro:
- Were they completed?
- Did they solve the problem?
- Do they need to be re-opened?
This section is what converts retrospectives from complaint sessions into continuous improvement processes. Teams that skip it are solving new problems while unresolved old ones compound.
According to Shreyas Doshi on Lenny's Podcast, the retrospective review section is the highest-leverage section most teams never write — checking whether last sprint's action items actually changed behavior is the only way to know if the retrospective process is working or just creating the illusion of improvement.
Format and Sharing
H3: Document Format
A product retrospective document should be:
- Written, not just summarized from meeting notes
- Shared with the full team within 24 hours of the retrospective
- Stored in a searchable location (Notion, Confluence, or team wiki) so patterns across multiple sprints are visible
- Referenced at the start of the next retrospective
H3: Retrospective Patterns Across Sprints
The most valuable retrospective insight is a pattern — the same issue appearing in 3 or 4 consecutive sprints. Single-sprint observations may be noise; recurring patterns are systemic problems.
Maintain a retrospective log where action items from each sprint are tracked to completion. Review the log quarterly to identify recurring themes that individual sprint retrospectives miss.
According to Gibson Biddle on Lenny's Podcast, the test of whether retrospectives are working is whether the team is solving different problems every sprint — if the same items appear in the "what didn't work" section repeatedly, the retrospective is producing diagnosis without treatment.
FAQ
Q: What is a product retrospective document? A: A written record of what worked and what didn't in a sprint or product cycle, with root causes identified and specific action items assigned to owners with deadlines and success criteria.
Q: What should a product retrospective document include? A: Sprint summary, what worked and why, what didn't work with root causes, action items with owners and deadlines, and a review of previous sprint action items.
Q: How do you make product retrospectives actually change team behavior? A: Require root causes not symptoms, assign every action item to a named owner with a deadline and success criterion, and review previous action items at the start of every retrospective to close the feedback loop.
Q: How often should you write a product retrospective document? A: After every sprint or product cycle — typically every 2 weeks. Store retrospectives in a searchable location and review quarterly to identify recurring patterns across multiple sprints.
Q: What is the most important section of a retrospective document? A: The review of previous action items. Teams that skip this section are solving new problems while unresolved old ones compound, which is why the same issues recur sprint after sprint.
HowTo: Write a Product Retrospective Document
- Write a one-paragraph sprint summary covering the sprint goal, what was completed, what was not, and overall team health during the cycle
- Document what worked with a specific causal explanation — not just that it worked but why, and how to preserve it in the next sprint
- Document what didn't work with a root cause for each item using 5 Whys if needed — never list symptoms without causes
- Generate action items for every item in the what-didn't-work section with a named owner, deadline, and success criterion for each
- Review action items from the previous retrospective at the start — were they completed, did they solve the problem, do they need to be re-opened
- Store the document in a searchable location and review the log quarterly to identify recurring patterns across multiple sprints