How to Write a Startup Postmortem
Every startup has things that do not work: a launch that falls flat, a product line you shut down, a pivot, or sometimes the whole company. A good postmortem turns that pain into lessons you and your team can actually use. This guide shows you how to write one honestly, without blame, and in a format people will read.
Key takeaways
- A startup postmortem is a written review of a project, launch, pivot or company that did not go as planned, focused on lessons rather than blame.
- Write it within a few weeks, while memories are fresh but emotions have cooled a little.
- Gather facts first: a timeline, key decisions, numbers and input from everyone involved.
- Separate what happened, why it happened and what you would do differently.
- End with specific, owned actions or lessons, and decide carefully who will see the document.
Most founders would rather move on than look back at something that failed. That is a natural reaction. But skipping the review means the same mistakes tend to show up in the next project, the next startup or the next hire. The lessons are expensive; it would be a shame not to collect them.
A postmortem does not need to be long or formal. For a failed feature or campaign, two pages may be enough. For a company shutdown, it may be longer and more personal. The structure in this guide works for both.
What a startup postmortem is for
A postmortem is not a confession, a eulogy or a defense. It is a working document with three jobs:
- Understand what really happened. Memories blur fast and different people remember different versions. A shared, written account sets the record straight.
- Find the causes. Most failures have several causes: market timing, product choices, pricing, team gaps, cash, or plain bad luck. Naming them helps you tell which were in your control.
- Carry the lessons forward. The value comes from specific changes you or your team will make next time.
You can write postmortems at several levels. A team might review a single failed experiment. Founders might review a pivot or a missed fundraising round. And when a company winds down, a founder may write a full company postmortem, sometimes shared publicly.
Pro tip
Do not wait for a disaster to practice. Run a short postmortem after a small failed experiment first. The habit makes bigger reviews far easier and less emotional.
Set the ground rules: blameless and honest
The most useful postmortems are blameless. That does not mean nobody made mistakes. It means you focus on decisions, information and systems rather than on attacking individuals. People share more honestly when they are not afraid of being punished for it.
Agree a few ground rules before you start:
- Assume good intent. People made the best decisions they could with the information and pressure they had at the time.
- Describe, do not judge. "We launched without testing pricing" is useful. "Alex ignored the pricing problem" is not.
- Include the founders. Founders' decisions belong in the review too. Leading by owning your own calls sets the tone.
- Separate facts from opinions. Label guesses as guesses.
- Agree on privacy. Tell contributors who will see the document before they share anything sensitive.
Common mistake
Using hindsight to make decisions look obviously wrong. Many choices only look bad because you now know how things turned out. Ask "what did we know at the time?" before asking "what should we have done?"
Gather the facts before you write
Good postmortems are built on evidence, not memory alone. Spend a few hours collecting material before drafting anything.
- Build a timeline. List key dates: when the idea started, major decisions, launches, hires, funding events and when things started going wrong.
- Pull the numbers. Gather the metrics that mattered: signups, activation, revenue, retention, cash runway, or campaign results. Use the actual records, not what you remember.
- Collect documents. Plans, goals, board or investor updates, customer feedback and meeting notes show what you believed at each stage.
- Ask the team. Send everyone involved three short questions: what went well, what did not, and what they would change. Let people answer in writing before any meeting.
- Talk to a few customers if possible. Former or lost customers often explain the "why" more clearly than internal data.
A simple structure for your postmortem
Use the same sections every time so your postmortems are easy to compare. Here is a format that works for most startup reviews.
1. Summary
Three to five sentences: what the project or company was, what you hoped would happen, what actually happened and the single biggest lesson. Many readers will stop here, so make it count.
2. Background and goals
What problem were you solving, for whom, and what did success look like? Include the original goals or targets if you had them, so readers can see the gap between plan and reality.
3. Timeline
A short dated list of key events and decisions. Keep it factual.
4. What went well
Do not skip this. Even failed projects produce wins: a strong team habit, a useful piece of technology, a loyal group of early customers. These are worth repeating.
5. What did not go well, and why
The core of the document. For each problem, describe what happened, then dig into causes. A simple method is to ask "why?" several times until you reach something you could actually change next time.
6. Lessons and actions
Turn causes into specific lessons. If the team continues, add actions with owners and dates. If the company is closing, write lessons as advice to your future self or to other founders.
A postmortem lessons template
Copy this table into your document for section 6. The rows below are made-up examples.
| What happened | Root cause | Lesson | Action next time | Owner |
|---|---|---|---|---|
| Launch drew few paying users | Pricing was never tested with real buyers | Validate willingness to pay before building | Run a paid pilot with 5 customers first | Founder A |
| Runway ran short mid-build | Hiring plan assumed a raise that came late | Plan spending on cash in the bank | Review runway monthly with a worst case | Founder B |
| Key feature shipped two months late | Scope grew without a decision process | Write down scope changes and who approved them | Use a one-page change log for each release | Product lead |
Hypothetical example
Imagine Kofi, who spent a year building a marketplace for local event suppliers before shutting it down. His first draft blamed the market for being "not ready." After gathering numbers and team input, a clearer picture emerged: suppliers signed up happily, but buyers rarely returned after their first booking, and the team spent most of its time on supplier features. His final postmortem named weak buyer retention as the main cause and listed one lesson he now applies to every idea: test whether customers come back before scaling either side of a marketplace.
Run a short postmortem meeting
For team projects, a meeting helps people agree on the story and the lessons. Keep it focused and safe.
- Share the draft first. Send the timeline and early findings a day or two ahead so people arrive prepared.
- Choose a neutral facilitator. Ideally someone who was not at the center of the key decisions.
- Walk through the timeline. Correct facts before debating causes.
- Discuss causes, not culprits. Keep returning to "what made this decision seem right at the time?"
- Agree on the top lessons. Three strong lessons are better than fifteen weak ones.
- Assign owners. Every action gets a name and a date, or it will not happen.
Sixty to ninety minutes is usually enough. If emotions run high, take a break and come back. It is normal for a failure to sting, especially when people worked hard.
Sharing your postmortem wisely
Decide who should read the document before you finalize it. Common audiences include:
- Your team. The main audience for project postmortems. Store them in a shared place where new hires can find them.
- Investors and board members. A concise version shows maturity and keeps relationships strong, even after a shutdown.
- The public. Some founders publish company postmortems to help others. If you do, remove confidential details about customers, employees and partners, and check any contracts or agreements that limit what you can share.
If the postmortem relates to a company closure, it may touch on legal, tax, employment or investor matters. This article is general information, not legal or financial advice, so ask a qualified lawyer or accountant before you share anything sensitive publicly.
Common mistake
Writing a great postmortem and never opening it again. Add a reminder to review your lessons before you start your next big project or company, and check whether the actions actually happened.
Your startup postmortem checklist
- Pick a date within a few weeks of the event
- Agree blameless ground rules and who will see the document
- Build a dated timeline of key events and decisions
- Pull the real numbers from your records
- Collect written input from everyone involved
- Draft the summary, background, timeline, wins and problems
- Dig into root causes and write clear lessons
- Assign owners and dates to each action
- Share with the right audience and set a reminder to revisit
Frequently asked questions
How long should a startup postmortem be?
As short as possible while still being useful. A failed feature or campaign might need one or two pages. A full company review may run longer. Always lead with a short summary so busy readers get the main lessons quickly.
When is the right time to write it?
Usually within a few weeks. Too soon and emotions may cloud judgment; too late and details fade. If the topic is very painful, it is fine to gather facts first and write once you feel steadier.
Should I write a postmortem if I am the only founder?
Yes. Solo founders gain a lot from writing it down, because there is nobody else to remember the details. Consider asking a mentor or trusted adviser to read it and challenge your conclusions.
Is it a good idea to publish a company postmortem?
It can help other founders and show honesty, but it is a personal choice. Remove confidential information, respect the privacy of former colleagues and customers, and get professional advice if legal or investor issues are involved.
Related reading
The bottom line
A startup postmortem turns a disappointing outcome into something useful. Gather the facts, keep the review blameless, separate what happened from why it happened, and finish with a short list of specific lessons and owned actions. Then share it with the people who need it and revisit it before your next big bet.
If something did not work this spring, block out an afternoon to write it up. The lessons you capture now may be what makes your next project succeed.
