In 2022, I helped a SaaS company shut down a product line that represented 35% of their revenue. It was the right decision. It was also terrifying, slow, and handled worse than it should have been. By the time we finished the wind-down, we had lost two customers we should have kept, delayed the surviving product line's growth by four months, and burned through one unit of reputational credit with an investor who felt blindsided.
All three of those outcomes were preventable. This is the playbook I would have used if I had known then what I know now.
The Boring Reality
Sunk-cost bias is the dominant force in product-line wind-down decisions. The engineering months, the sales cycles, the customer references you worked to earn: all of it creates psychological friction against a decision that is clearly correct on the numbers.
I have watched founders hold a product line alive for twelve months longer than they should because the team that built it still worked there and shutting it down felt like a judgment of their work; because the handful of customers using it were vocal advocates; and because there was always one more thing to try before giving up.
None of these are financial reasons. The financial signal to kill a product line is usually visible months before the decision gets made.
The Decision Framework
Four questions. If you answer "no" to two or more, start the wind-down process.
1. Does this product line have a credible path to 20% of total company revenue within 12 months?
Not a theoretical path. A credible path, based on current pipeline, current conversion rates, and the resources you are willing to allocate. If the answer requires a breakthrough that you do not have evidence for, it is not credible.
2. Is the gross margin on this product line above 40%?
A product line running below 40% gross margin at seed or Series A stage is consuming resources that would generate better returns elsewhere. This threshold is lower for hardware or marketplace models, but SaaS lines below 40% gross margin are structurally difficult to defend.
3. Are the customers in this segment the same buyer as your core product's buyer?
If you are maintaining a separate product for a segment you will not ultimately focus on, you are running two go-to-market motions simultaneously. That is expensive and dilutive to focus.
4. If we had not already built this, would we build it today with what we know?
This is the cleanest version of the sunk-cost question. The answer has to account for current opportunity cost, not prior investment.
When to Pivot vs. When to Kill
There is a version of this decision where the product line becomes a feature of the surviving product rather than a standalone line. This is a pivot, not a kill, and it deserves consideration before committing to full wind-down.
| Situation | Recommendation |
|---|---|
| Core customers already use both products | Integrate as a feature; do not maintain two products |
| Product-line customers overlap less than 10% with core | Full wind-down; you are serving a different segment |
| Product line has unique technical IP that differentiates core | Reabsorb the IP; discontinue the product surface |
| Product line requires separate support, billing, and onboarding | Full wind-down; the operational tax is too high |
| Product line is on a separate codebase | Almost always wind down; integration cost is rarely worth it |
The Execution Checklist
# Product Line Wind-Down Execution Checklist
phase_1_decision: # Week 1
- "Document the decision rationale (two pages, shared with board)"
- "Identify all affected customers: name, ARR, contract end date"
- "Identify all team members whose primary work is this product line"
- "Calculate true cost of wind-down: refunds, migration support, severance if applicable"
phase_2_communication: # Weeks 2 to 3
- "Notify affected customers before any public announcement"
- "Offer migration path or credits where applicable"
- "Personal calls for any customer over $10K ARR"
- "Notify board and key investors before customer notifications go out"
- "Prepare internal communication for the team"
phase_3_execution: # Weeks 3 to 8
- "Freeze new feature development on wind-down product immediately"
- "Set hard end-of-life date: no more than 90 days from decision"
- "Build data export tools for customers who need their data"
- "Reassign or wind down team members clearly and promptly"
- "Publish wind-down announcement: blog post, support page update"
phase_4_closure: # Weeks 8 to 12
- "Complete data deletion and confirm to customers in writing"
- "Archive codebase and documentation"
- "Post-mortem document: what we learned, not why we failed"
The two mistakes I see consistently in wind-downs: the timeline is too long (keeping the product alive for 12 months "to avoid upsetting customers") and the communication sequence is reversed (public announcement before customer calls).
Communicating to Customers
The customers you most need to retain for the surviving product are the ones most likely to be upset about this change. Handle them first, personally, and with a clear offer.
The message structure that works:
- Here is what is changing and when.
- Here is why (honest, not corporate).
- Here is what we are offering you (migration path, refund, or credits on the surviving product).
- Here is who to call if you have questions (a specific person, not a support inbox).
A concrete example: "We are discontinuing [product name] on [date]. We made this decision because [specific reason]. We know this creates a disruption for you. Here is what we are offering: [specific offer]. [Name] will personally reach out to you within 48 hours to work through your specific situation."
Founders who execute this well lose almost no customers from the surviving product line. Founders who send a form email lose customers from both products.
The Signal vs. Noise Test
Before you commit to the wind-down, run one final check: are you killing this product because of a signal or because of noise?
Signal: Twelve consecutive months of declining conversion, multiple customers who said they would pay and then did not, gross margin below threshold despite cost optimization, your best salesperson stopped pitching it without being asked.
Noise: One bad month, a competitor launched something similar and you panicked, the team building it is frustrated, you personally find the market less interesting than you did twelve months ago.
A wind-down based on noise is a mistake. A wind-down based on signal, executed cleanly, is a strategic decision that frees up resources for the work that actually matters.
What I Got Wrong
In the 2022 case I mentioned at the start: we gave customers a 90-day notice period. That sounds reasonable. In practice, it meant 90 days of the team's energy going into wind-down operations rather than the surviving product. The product we were actually betting the company on lost four months of momentum during a period when we should have been accelerating.
The right notice period was 60 days with a generous migration offer and immediate reallocation of engineering resources. We should have made that decision at week one, not discovered it at week eight.
The second mistake was not writing the post-mortem. We closed the product and moved on. Twelve months later, the same pattern of reasoning that led us to build the product in the first place appeared in a different form. We would have caught it faster if we had written down clearly what signals we had missed and why we had stayed with the product too long.
Write the post-mortem. Not to assign blame. To give your future self a faster pattern-match.