Managing a Legacy CRM Through End-of-Life

PublicStuff, a legacy 311/CRM product, was approaching end-of-life. The engineering budget was fixed and had to cover three competing demands at once: retention-critical features for agencies deciding whether to stay, defect burn-down on an aging codebase, and support for customers migrating to the successor product.

Every agency's request was "critical" to that agency. Without a public prioritization logic, the program would run on whoever escalated loudest — the fastest route to churn.

I prioritized by churn risk times workflow criticality: for each agency, what actually blocked daily operations versus what was merely requested. Defects were sequenced by severity times customer exposure, not arrival order. And I published an explicit bar for what would not be fixed — which converted recurring arguments into policy and let support give honest answers.

I also kept incident management in my own hands rather than delegating it away. In an EOL program, incidents are the rawest signal you have about which reasons-to-leave are growing.

Sustaining products are easy to under-invest in and easy to over-invest in; the discipline is knowing what each unit of work buys. The framing that kept this program honest: measure reasons-to-leave removed per sprint, not features shipped.

That lens changed what got built. A small defect fix that removed a daily operational blocker for several agencies outranked a bigger feature that nobody would churn over. It also made the program legible to leadership: every sprint had an answer to what risk did we just retire.

The program delivered an orderly multi-year transition instead of a churn event, with customers moving to the successor product on planned timelines.

What I learned: end-of-life is a product discipline of its own. It runs on ruthless prioritization, visible policy, and personal presence in the incident stream — and it's where I learned that a clearly communicated "no" retains more customers than an unreliable "yes."