Run a 15-day kill date: one metric, reusable post-mortem

The kill sheet is the decision

You have a launch, a small team, and no clean way to stop. A 15-day kill date forces the decision before the team can soften it.

The case for it is a zero result. Callforge was a packaged voice-agent boilerplate that combined Vapi/Retell, Twilio, and Stripe metered billing. It got 15 days to earn one paying customer, and it ended with none and the website shut down. The outbound push contained 350 sends, drew 3 replies, and converted 0 times. Six visitors began a checkout for the $199 Callforge offer. A calculator that required one day to build generated more attention during 48 hours than the 350 cold emails sent across ten days.

Those numbers separate effort from demand. A team can work hard and still learn that the channel, the offer, or the buyer is wrong. The calculator comparison is the operating lesson: a small asset can outperform a large effort when it matches the buyer's question.

Before launch, write a short kill sheet. It names the date, the single metric, the outbound batch, the post-mortem owner, and the template the team will use. The sheet is the document the team signs, not a mood. It answers when to kill a product before the team invents a reason to keep it.

The metric sets the validation threshold. Once the sheet names it, the team cannot replace it with interest, a demo, or a promise. The date sets the deadline; the review is the exit. Keep the criteria narrow enough that the team cannot argue with them after the fact.

The window runs like a small experiment

• Fix the date and the metric before any send. The finished state is a kill sheet with a date, a single metric, an outbound batch, a template, and a person responsible for closing the file. The team should be able to point to the sheet in a meeting without rebuilding the argument.
• Send the outbound batch and record every reply. The finished record is a spreadsheet with sends, replies, and the reason each deal stopped. It should show what was asked, who answered, and where the conversation died.
• Watch the metric, not the activity. The trap is treating a reply as a conversion; the metric decides. The daily note is the proof: it says whether the number moved and what changed. It should be short enough to read in a standup, but honest enough to survive the review.
• Stop at the date. The window is closed, the batch is paused, and the team moves to the review.

That daily note is the operating record for the window. It keeps the team from arguing about memory. When a reply arrives, the note records the ask, the objection, and the next step. When the metric does not move, the note shows where the effort went. It also makes the review shorter, because the team is not reconstructing the window from memory.

The review becomes a reusable asset

A startup postmortem is a review with a clear question. It asks what the metric missed, why the channel failed, and what the next test should be. The review should be scheduled before the launch ends, so the team does not drift into denial.

A customer-loss postmortem uses the same discipline: review the immediate cause, the full relationship history, and possible process changes after the cancellation. Turn the findings of a customer-loss review into practical changes. Business setbacks can make a company stronger through experience with many customers.

The template has fields for date, metric, batch, and next action. The next action should be a change the team can make before the next launch, not a promise to try harder. It can be a different offer, a different channel, a different buyer, or a decision not to build.

Put the finished post-mortem in the same folder as the kill sheet, and make the next launch team read it before it starts. Name the next owner in the kill sheet. The owner should be able to explain the change in the next planning meeting.