You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 13: Killing Products — Ship the Kill #

You will write the kill protocol and then find reasons to delay applying it, and I want that prediction in writing because the prediction is the entire intervention. The protocol-without-application is a comfortable artifact — you can show it to yourself as evidence of having internalized the discipline without paying the cost of running it. This module's deliverable forces the application: one real product, formally retired, by the end of the module. The kill is the test; the protocol is the scaffolding. M4's matrix already nominated the candidates — in the worked portfolio, ShelfLife and CartTrends, the two whose status was "unclear," because unclear status is a kill decision you haven't admitted to yourself — and M7's thresholds confirmed or overturned the nomination with data. A kill decision that never executes is a keep decision with extra guilt. M13 is where the decision becomes an act.

Actually shipping the kill will feel like loss, and I want to name that explicitly, because the contrarian frame — killing a product is not failure; killing it on the wrong timeline is failure — is correct, and the frame will not prevent the loss-feeling from arriving when you do the thing. Both are true at once. In the moment you will feel three things: a small grief, a small relief, and a small embarrassment at having held on as long as you did. The grief is real and is sunk cost protesting in real time. The relief is the diagnostic that the kill was overdue. The embarrassment is the one to convert into learning, because "I'll just give it one more month" is the single most expensive habit in indie-founder life — it never costs one month; it costs one month, recurring. Read five indie post-mortems and count how many authors say they waited too long. Nearly all of them. You will say it too; the only variable is by how much.

Annie Duke's Quit is the empirical anchor and one finding deserves lifting: quitting is not the opposite of grit. The opposite of grit is quitting too late on the wrong things, and the cure is quitting earlier and more deliberately on what the data says is not working — which is why the kill criteria were written in M4 and M7, before this review, not during it. Criteria invented at decision time bend toward whatever the deciding self wants.

The engineer's lens makes the whole module click: you already run this discipline in production. When a downstream service is degrading and not recovering, you trip the circuit breaker and stop sending traffic; you do not pretend it will be healthy next minute. Most engineer-founders run their portfolios without circuit breakers, which is why the zombies limp on for years, each one consuming maintenance, emotional bandwidth, and identity-attachment while the studio ships nothing. The post-mortem is the blameless incident review — kind toward your past self, specific about the system.

Here is the thread this merged module carries that the execution-focused draft underweighted: sunset ethics. The kill decision is the what; what you owe the people who depended on the thing is the how, and doing the first without the second converts a clean decision into a reputation cost. The checklist is the deprecation policy you already respect in software — announce, version, migrate, then remove — applied to products: real notice with a real timeline, data export that works, refunds where owed, dependency warnings if the thing is a library someone builds on. A waitlist counts as someone to notify. Users of products deserve at least what users of APIs get, and the operator who sunsets with care is also, not incidentally, the operator whose next launch gets trusted. Write the sunset checklist into the protocol itself so the pressure-version of you doesn't get to skip it.

Two refusals to close. First, you will be tempted to "pause" the product instead of retiring it. Pause is denial dressed as optionality — the zombie state with better branding. Retire formally; if you ever revive it, it will be a new product and should compete for capacity as one. Second, do not expect the freed time to redirect itself. Within thirty days of the kill, the reclaimed hours will have dissipated into everything unless you consciously redeploy them to the survivors — the redeployment is a line item in the protocol, not an afterthought. I cannot kill the product for you; the act has to be yours, written, dated, posted to whatever public surface the product had, because the discipline only counts when the kill is yours to ship. Three months later you will wonder why you waited. Carry the wondering forward; the next kill arrives faster and cheaper.

Conclusion #

M13 is unsentimental engineering applied to the portfolio, with the ethics attached. The protocol is easy to write and the application is the test: one product formally retired — notice given, data exportable, README updated, post-mortem written, hours consciously redeployed. Quitting on time will feel like quitting too early; that feeling is the calibration working, not an error. The engineer who never kills anything builds a portfolio of zombies. The engineer who kills deliberately, and sunsets with care, builds an operation that ships and a reputation that survives the shipping.

Predictions #

  • You will write the protocol cleanly and then find three reasons to delay running it for two weeks. The reasons will sound legitimate. They are stalling.
  • The kill itself will take 30-45 minutes of writing and feel disproportionately heavy. The heaviness is correct and does not return at the second kill.
  • You will be tempted to label the kill a "pause." If you catch yourself reaching for the softer word, that is the tell.
  • The post-mortem will surface 1-2 lessons you had been quietly carrying without naming — usually about demand evidence you didn't gather before building.
  • The freed hours will not redeploy themselves; within 30 days they will have dissipated unless you consciously reassign them in writing.
  • If your killed product has any users or waitlist at all, at least one person will respond to the sunset notice with more warmth than you expect. Sunsetting with care costs little and is remembered.
  • Three months after the kill you will wonder why you waited so long, and the next kill decision will take weeks instead of quarters.