A launch produces two things: traffic and evidence. Traffic disappears. Evidence disappears too, unless somebody writes it down.
The launch retrospective is not a victory lap and not a trial. It is a short record of what the team believed, what users did, what failed, and what should change next.
A launch is useful when it changes your mind precisely.
Run it while the details are still unfriendly
Hold the review within two working days. By the following week, the sharp edges become a story: the outage was brief, the confused users were unusual, and the encouraging comment meant more than it did.
Invite only the people who handled the launch, product, support, or data. Sixty minutes is enough. Assign one person to write and one person to keep the discussion on evidence.
Bring the launch-day runbook, deployment timeline, analytics, support messages, error log, channel posts, and any promises made publicly.
Begin with the bet
Before discussing results, restate what the launch was meant to test.
Write down:
- the intended user;
- the problem and promise presented to them;
- the channel used to reach them;
- the action that counted as reaching value;
- the result that would have changed the next decision.
If none of this was explicit before launch, say so. Do not invent a target that makes the observed numbers look sensible.
The Hacker News founder community often distrusts postmortems that reduce a complicated company to one tidy cause. That skepticism is healthy. A retrospective should preserve uncertainty, not manufacture wisdom after the event.
Rebuild the timeline
Create one list of material events with times:
- deployment and announcement;
- traffic spikes;
- first signup and first completed job;
- errors, slowdowns, and rollback;
- copy, pricing, or product changes;
- notable user questions;
- recovery and follow-up.
Facts belong here. “Users hated onboarding” does not. “Seven of the first twelve signup attempts stopped at email verification” does.
The timeline prevents sequence errors. A drop in conversion after a pricing change means something different from a drop that began before it.
Separate the four kinds of signal
Product behavior
How many relevant visitors began the core journey, reached its first useful result, returned, paid, or invited somebody? Which step lost them?
Raw visits belong in context, not at the top of the page. A thousand curious readers and three intended users are not a thousand failed prospects.
Reliability
Which user journeys failed? How many people were affected? How long did detection and recovery take? Did monitoring find the problem, or did a user?
Include near misses. A payment duplicated in testing but not during the public launch is still evidence.
Understanding
What did users repeatedly ask? Which words did they use for the problem? What did they think the product did before trying it?
Compare this with the homepage promise. If visitors understood the product but did not care, do not label the problem “messaging.”
Demand
Who made a costly commitment: paid, imported data, invited a colleague, booked the next step, or returned without prompting? Compliments are welcome. Commitments are stronger.
YC’s published advice from first-time founders returns to the same hard lesson: customers may use a product differently from the category its founders imagined. Record the work users actually attempted.
Ask where learning was delayed
A useful question surfaced in a widely discussed Hacker News startup postmortem: when was a lesson learned, and when could it have been learned?
Use it without turning hindsight into theatre:
- What did we learn?
- What evidence changed our belief?
- When did that evidence become available?
- What prevented us from noticing or acting sooner?
- Which small system would shorten that delay next time?
Perhaps the team first saw failed verification emails during launch, but could have run an inbox test three days earlier. The action is not “test more.” It is “add the production signup journey to the release check, with an owner.”
Refuse the soft conclusions
These statements sound responsible and change nothing:
- We need better marketing.
- We should improve onboarding.
- Communication could have been clearer.
- We need more testing.
- The audience was wrong.
Replace each with an observable claim and a decision. “Eight qualified visitors reached the pricing page; six asked whether exports were included. Add that fact beside the plan and test the same channel again.”
Do not create twelve priorities. Choose the largest product risk, the largest reliability risk, and the most valuable unanswered question.
Use this one-page launch retrospective
Copy this into the team’s working document:
The bet
Audience: Problem and promise: Launch channel: First useful result: Expected signal:
What happened
Timeline: Qualified visitors: Core journeys started/completed: Returns or commitments: User-facing failures: Repeated questions:
What changed our mind
Belief before: Evidence: Belief now: Confidence and uncertainty:
What happens next
One product change: One reliability change: One question to test: Owner and date for each:
Publish carefully; keep the honest version
A public launch note can earn trust when it is candid and useful. It can also become performance. Remove private user details, security-sensitive information, and blame. Keep concrete numbers when they do not expose customers or the business unfairly.
Maintain the internal version even if the public version is shorter. The purpose is not to sound reflective. It is to make the next launch less ignorant.
End the meeting with three owned decisions. Then return to users. The retrospective is complete when it changes the work, not when the document looks complete.