A Post-Launch Retrospective Template

The week after a launch is a strange time. You are tired, relieved, a little flat. The temptation is to move on straight away, fix the loudest bug and start the next thing. But the days right after a launch are when you know the most about what happened and when you will forget it fastest. A retrospective captures that knowledge before it fades.

A retrospective, as the term is used in project work, is a meeting held at the end of a project or period to discuss what was successful, what could be improved and how to incorporate the successes and improvements in future work. This article gives you a template you can use as it is or adapt.

Before the meeting: collect the facts

A good retrospective starts with evidence, not impressions. Before you meet, gather:

• Your goals from the plan, with the targets.
• The numbers: visits by source, sign-ups, activation, conversations, revenue if relevant, rank if you tracked it.
• The timeline: what happened when, from the scribe's log.
• The feedback log: what people said and what you did about it.
• The incident list: what broke, when and how long it took to fix.
• Support patterns: the top questions and complaints.
• Screenshots of key pages and any board positions, with dates.

Put these in a shared document or folder and ask everyone to read it beforehand. Ask each person to jot down a few notes in advance: one thing that went well, one thing that did not, one surprise.

Set the ground rules

State them at the start.

• Blame-free. The goal is to improve the system, not to find fault with people.
• Honest. Say what you really think, kindly.
• Specific. Talk about events and facts.
• Time-boxed. Each part has a time limit.
• Action-focused. End with decisions and owners.

If the launch was stressful, acknowledge it. Say thank you before anything else.

The template

1. Opening and thanks (5 minutes)

The facilitator thanks everyone, names the contributions, and restates the purpose. If volunteers helped, thank them by name.

2. The goals and the results (10 minutes)

Read the main goal and the supporting measures, then the actual numbers.

Measure	Target	Result	Notes

Fill it in as a group. Keep it factual: did we meet it, miss it or exceed it? Note anything that distorted the numbers, such as a bug or a counting problem.

Goodhart's observation, that a measure used as a target ceases to be a good measure, is a useful prompt here. For each number, ask: does it truly reflect what we cared about, or did we start chasing the number?

3. The timeline (10 minutes)

Walk through the week using the scribe's log. Mark the moments when something significant happened: a spike, a failure, a decision. Everyone adds what they remember. Differences in memory are informative.

4. What went well (10 minutes)

Each person shares things that worked. Write them on a list. Look for patterns. Examples: the rehearsal caught a serious bug, the prepared answers saved time, the listing text was clear, the team communicated well.

For each, ask: how do we make sure we repeat this?

5. What did not go well (15 minutes)

Each person shares things that were difficult or disappointing. Write them without commentary. Then group them. Ask for each: what was the cause? Avoid stopping at the first answer. Ask "why" a few times to reach the underlying issue.

Example: "The welcome email did not arrive for some users." Why? "The sending domain lacked authentication." Why? "Nobody owned email setup." The root cause is an ownership gap, which is a different fix from changing a setting.

6. What surprised us (5 minutes)

Surprises reveal assumptions. Perhaps more people came from an unexpected source, or a feature nobody cared about turned out to matter, or a question came up that nobody had anticipated.

7. Feelings (5 minutes)

Briefly, how did people feel? Stressed, proud, bored, anxious? A launch is a human experience, and ignoring it leads to burnout. Note anything that should change in how you work together.

8. Decisions: keep, change, try (15 minutes)

Turn the discussion into three lists.

• Keep. Practices to repeat.
• Change. Things to do differently, with a specific alternative.
• Try. Experiments for next time.

For each item, assign an owner and a date. Limit yourselves to the few that matter most. A list of twenty actions will be forgotten. Three to five will happen.

9. Customer follow-up (5 minutes)

Who needs a message? Early users who gave feedback, people who reported bugs, supporters who helped, anyone whose problem is not yet resolved. Decide who writes to whom and when.

10. Close (5 minutes)

Summarise decisions, confirm owners and thank everyone again. Decide when you will check progress on the actions.

After the meeting

• Write it up within a day: the numbers, the main lessons and the action list.
• Share it with the team and with anyone who helped.
• Store it where you will find it when you plan the next launch.
• Follow up on actions at the agreed time.
• Close the loop with the community, if appropriate. A short honest post about what you learned can earn goodwill.

Google's guidance on helpful content stresses originality and first-hand experience. A public lessons post that describes what you actually did and what you found is valuable to others and tends to be well received.

Variations

Solo founder. Do the same on your own. Write answers to each section, then step away for a day and reread them. If you can, ask a friend to listen as you talk through it.

Large team. Split into small groups for the "what went well" and "what did not" sections, then share.

A smaller launch. Use a short version: three questions in fifteen minutes. What went well? What did not? What will we change?

Pitfalls

1. Skipping it. The week after a launch is busy, but the lessons are time-sensitive.
2. Blame. If people fear being blamed, they will hide problems.
3. Only the loudest voices. Invite quieter people to share, perhaps by writing first.
4. Too many actions. Choose a few.
5. No follow-up. An action list that is never checked is the same as none.
6. Ignoring the good. Success deserves understanding too.

A worked example

A three-person team launches a recipe-planning app. Their retrospective takes seventy-five minutes. The numbers show that visits exceeded their target but sign-up conversion was lower than expected. In the timeline, they notice a dip in conversion on day two, coinciding with a change they made to the sign-up form. Under "what went well", they list the rehearsal that caught a payment bug, the quick support replies and a customer story that brought many visitors. Under "what did not go well", they list the sign-up change, a late press kit and a week of broken sleep.

Asking why, they find that nobody was assigned to approve changes during launch week. They decide to keep the rehearsal and the prepared answers, change the process so that the lead approves every change during the window, and try an A/B test of the sign-up form in the next sprint. Each action has an owner and a date. They send personal messages to the twelve people who reported bugs, and publish a short post about what they learned. The write-up sits in a shared folder labelled with the launch name, ready for next time.

A one-page version

• Goals and results
• Timeline highlights
• Went well
• Did not go well, with causes
• Surprises
• Keep, change, try
• Owners and dates
• Follow-ups

On this site, the launches page shows scheduled launches and the submit page lets you create your next listing. If you are weighing paid visibility next time, the pricing page lists options, and your retrospective notes will help you judge whether it paid off.

Questions that dig deeper

If the conversation stays on the surface, a few prompts can help. What did we assume that turned out to be wrong? What did we do that we would be proud to explain to a customer? What would we do differently if we had half the time? If we could change one decision from the past month, which would it be? What helped us make decisions quickly, and what slowed us down? What did we learn about our customers that we did not know a month ago? Asking each person to answer one or two of these in writing before speaking often draws out views that quieter team members would not otherwise share.

Keeping a library of retrospectives

Store every retrospective in the same place with the same name format, such as the launch name and date. Before planning the next launch, read the last two. You will find that the same issues tend to recur until someone owns them, and that things you have already solved quietly become habits. Over a few launches, the library becomes your team's own handbook, written from experience, and new helpers can read it to get up to speed in an evening.

Frequently asked questions

Do I need a facilitator? It helps. Rotate the role so that everyone has a turn.

What if people disagree? Note both views and decide what to test. Disagreement is information.

Should I share the retrospective publicly? A summary, yes if you wish. Keep private details private.