AI Contact Center: When to Kill a Product
Introduced data-driven survival metrics to guide the difficult sunset decision on an underperforming SaaS product caught in political gridlock.
Overview
In 2022, I inherited an “AI Contact Center in a Box” SaaS product that had failed to gain traction despite significant investment. Originally 2018 demoware, it was productized in 2020 with heavy investment and deployed to FedRamp-ready cloud with hopes of capitalizing on the suddenly remote call center market.
Two years after go-live, the result was stark: zero customers. Leadership asked me to assess viability.
The Challenge
The product was trapped in political gridlock:
- Sky-high pricing: Driven by “best of breed” COTS components including ServiceNow, Oracle Process Automation suite, Google CCAI, Okta SSO, and numerous telephony integrations
- Slow development cycle: MVP took a full year to build, missing the market window
- Emotional investment: The sponsoring Managing Director was deeply committed to the product
- Internal pushback: Her peers continuously challenged its viability
The fundamental question loomed: pivot or kill? But without an objective framework, the decision was being fought on political terrain rather than business logic. The product could have languished indefinitely, bleeding resources while stakeholders debated.
The Solution
I realized we needed to remove emotion from the equation. I proposed a “survival metric” framework:
Define a clear success threshold: Acquire a minimum number of new clients within a specific period (e.g., 6 months).
Make it binding: If the threshold is missed, the product would be sunsetted—not reconsidered, not reprieved, but cleanly shutdown.
This approach achieved three things:
- Created an objective, data-driven decision trigger
- Set clear expectations with all stakeholders upfront
- Prevented the product from languishing in political limbo
I aligned both the sponsoring MD and her skeptical peers on this framework. The survival metric became a stage gate—either we hit it and reinvest, or we miss it and move on.
Results
In 2023, we missed the threshold. The decision was made—not by debate, but by data we had all agreed upon.
We executed a planned, orderly shutdown:
- Communicated transparently with the small internal user base
- Architected data migration paths for affected teams
- Reassigned engineering resources to higher-impact initiatives
Rather than continuing to bleed resources on a failing product, we shut it down cleanly and redirected the team to work that would actually generate value.
Key Takeaways
1. Validate product-market fit before scaling
Talk to real customers early. Don’t assume a product will succeed because it addresses a hypothetical market. The “remote call center” wave came and went while we were still building the MVP.
2. Aggressive MVP prioritization is non-negotiable
Don’t miss the market window. Our MVP took a year because we chased “best of breed” integrations rather than shipping a minimal viable solution. Speed is a feature.
3. Align stakeholders early and frequently
Use agreed survival metrics as stage gates, not debate fodder. When stakeholders agree on the success criteria upfront, the pivot-or-kill decision becomes data-driven rather than political.
Data-driven decisions beat politics. Every product—especially struggling ones—should have a clear survival metric. If you can’t define what success looks like, you shouldn’t be building.