Skip to content
Back to Launch & Discoverability

Launch Retrospective

Writing the post-launch retrospective — what worked, what didn't, what to do differently next time — to capture lessons and share them with the team and the community.

Why

The launch retrospective is the single highest-leverage post-launch activity: it captures the lessons while they're fresh (1 week after launch), turns gut feelings into data ('I think PH went well' → 'PH drove 60% of signups at 23% activation'), and creates a playbook for the next launch. Without a retrospective, each launch is a one-off event and you repeat the same mistakes (forgetting email, posting at the wrong time, not segmenting the waitlist). The retrospective also becomes valuable content: a 'how we launched X and what we learned' post is the most-read content for other founders (your peers share it, your future investors read it, your next launch's audience finds it). The retrospective takes 4 hours to write and returns value for every future launch — it's the compounding investment that makes each launch 20-30% better than the last. Skipping it means your next launch starts from scratch instead of from the accumulated learnings.

When

Write 1 week after launch (T+7) when the data is in but the memory is fresh; share with the team at T+7, publish as a blog post at T+14, and reference in the next launch's planning.

How

1. Gather the data: total signups, signups by channel, signups by region, activation rate, week-1 retention, revenue, top-performing channel, bottom-performing channel, biggest surprise (positive or negative)
2. Write the retrospective in 5 sections: (a) what we set out to do (goals), (b) what happened (results vs goals), (c) what worked (the 3-5 things that drove 80% of the results), (d) what didn't (the 3-5 things that failed or underperformed), (e) what we'll do differently next time (actionable changes)
3. For 'what worked', identify the 20% of effort that drove 80% of results: maybe Product Hunt (4 hours of prep) drove 60% of signups, and dev.to (30 minutes of cross-posting) drove 24%; these are the channels to double down on
4. For 'what didn't', be honest: maybe the press outreach (8 hours) drove 0 signups because no journalist covered it, or the LinkedIn post (1 hour) drove 3 signups because the audience isn't there; these are the channels to deprioritize
5. For 'what we'll do differently', make 3-5 specific, actionable changes: 'next launch, we'll send the email 24h before PH (not simultaneously)' or 'next launch, we'll invest in native zh content (translated drove 22% but native would drive 50%)'
6. Share the retrospective with the team in a 30-minute meeting: walk through the data, discuss the changes, assign owners for the next launch's improvements
7. Publish the retrospective as a blog post at T+14: 'How we launched EZ4Code v2.0 and what we learned' — this is valuable content for other founders and becomes an evergreen SEO asset
8. Add the retrospective to your launch playbook (a running doc of all launch learnings) and reference it in the next launch's planning; this is how each launch gets 20-30% better than the last

Example

# Launch Retrospective — ez4code v2.0 (T+7)

## (a) Goals vs (b) Results
| Metric        | Goal   | Actual | Hit?  |
|---------------|--------|--------|-------|
| Signups       | 2,000  | 4,127  | 206%  |
| Activation    | 25%    | 28%    | 112%  |
| W1 Retention  | 70%    | 74%    | 106%  |
| Revenue       | $5K    | $8.9K  | 178%  |
| PH upvotes    | 500    | 623    | 125%  |

## (c) What worked (80/20)
1. Product Hunt (4h prep) → 60% of signups
2. Hacker News (15min submit) → 24% of signups
3. Email to waitlist (2h write) → 39% of signups (overlap)
4. Native zh content (Juejin) → 22% of signups at 34% activation

## (d) What didn't
1. Press outreach (8h) → 0 coverage, 0 signups
   (pitched 12 journalists, 0 responses)
2. LinkedIn (1h) → 3 signups (audience not there for dev tools)
3. Reddit r/programming (30min) → removed by mods
   (should have posted in r/webdev only)

## (e) What we'll do differently
1. Send email 24h before PH (not simultaneously) — email
   voters need a heads-up before the PH voting window
2. Invest in native zh/ja/ko content (translated drove 22%,
   native would drive 50% based on ko activation data)
3. Skip press outreach for v2.1 (0/12 hit rate, 8h wasted);
   revisit for v3.0 with a PR agency
4. Post to r/webdev only (not r/programming) — r/programming
   has stricter rules and removed our post

## Published as blog post (T+14)
"How we launched EZ4Code v2.0 and what we learned"
→ 2,100 reads, 78 signups (evergreen content)
→ 34 backlinks from other founders' roundups
→ referenced in next launch's planning doc

Common Problems

  • ⚠Writing the retrospective 3 months later (not 1 week) — by month 3, the memory is fuzzy and you forget what worked and why; the retrospective at T+7 captures the lessons while they're fresh and the data is still in your analytics tool.
  • ⚠Only celebrating wins (not documenting failures) — 'PH drove 60%' is useful, but 'press drove 0% and here's why' is equally useful; the failures are where the biggest learnings are, and omitting them means you'll repeat them.
  • ⚠Vague lessons ('we should do better next time') — 'we should do better' is not actionable; 'send email 24h before PH' is actionable; every lesson in the 'what we'll do differently' section should be specific enough to implement.
  • ⚠Not publishing the retrospective — an internal-only retrospective helps the team but not the audience; publishing it as a blog post brings 2,100 reads, 34 backlinks, and positions you as a transparent founder that other developers want to work with.

Best Practices

  • ✓Write the retrospective at T+7 (not T+30 or T+90) — at T+7 the data is in (signups, activation, retention) and the memory is fresh (you remember why the press pitch failed); at T+30 the memory is fuzzy and you lose the nuance.
  • ✓Document failures as honestly as wins — 'press drove 0 signups because we pitched 12 journalists with a generic press release' is more valuable than 'PH drove 60%'; the failure has a specific, fixable cause; the win is hard to replicate.
  • ✓Make every 'what we'll do differently' lesson specific and actionable — 'send email 24h before PH' (specific, actionable) not 'improve email timing' (vague, unimplementable); the specificity is what makes the next launch better.
  • ✓Publish the retrospective as a blog post — it's valuable content for other founders (2,100 reads, 34 backlinks), it positions you as transparent, and it becomes an evergreen SEO asset that brings signups for months; the internal-only version helps the team, the published version helps the team + the audience + your SEO.