Recent Posts
- A great SVPMA talk: “How To Get That Next PM Job”
- Market Facts, Judgment, Fallibility and Ownership
- New (old) role, new (old) site, new (old) city
- Review: “Adapting Configuration Management for Agile Teams”
- Site Licenses and Other Real-World Intrusions
Topical Index »
Search
Subscribe
EOL from the Customer’s POV
As seasoned product managers, most of us eventually have to phase out old versions and completely eliminate old products. This is called End of Life (EOL) or End of Service (EOS), and is important weed-clearing. It’s generally motivated by our internal economic needs: rebalancing resources in our product portfolio, reducing support costs, moving customers to the latest version, abandoning products that can’t pay for themselves.
EOL creates a migration problem, though, for customers who are still using our old products. They are not interested in our internal problems and resent the cost/effort/time they spend replacing EOL’d products. As part of our planning process, we should think this through from the customer’s side to reduce EOL cost and frustration. (For context, I’m thinking about commercial software for business customers—but this applies equally to consumer software and tech in general.)
Here are five issues as customers describe them, and suggestions for how to address them.
1. “The cost of an upgrade is much more than the cost of your product. We need to design a migration, test it, back up data, migrate, retest and recertify our applications, and have our auditors approve the process.”
- Good EOL planners will have a ‘cookbook’ that completely describes a migration from old to newer systems. Step by step, it will detail a recommended process and include tools or sample scripts.
- Strongly implied in a cookbook is that you actually know how to move customers forward, and you’ve fully tested each step in the process. Hope is not a migration strategy.
- Set your EOL dates accordingly. If software changes require approval by your customer’s systems auditor, assume at least a year to complete a migration.
2. “My computing environment is very stable, by choice. We never move to new software until early adopters have found the bugs. We’ll wait until the last possible moment.”
- Many smart customers will want to wait, letting early adopters discover EOL gotchas. You’ll need to plan a gentle reminder campaign to all remaining customers with dates, upgrade policies, pointers to resources, and some reassurance that early movers were successful. Create a scoreboard now that shows who’s moved, who’s remaining, and reference customers willing say that the process was smooth.
- It’s OK to push customers forward to supported platform (e.g. to XP from Windows 2000). Luke Hohmann calls these ripple upgrades.
- Watch the calendar. Customers who delay too long will miss your end-of-service date.
3. “Your replacement doesn’t do exactly what the old version does, or forces us to make software modifications.” This _may_ be intentional with wholesale product replacements, but IMO often results from poor decision-making. As product managers, we fail to demand 100% upward compatibility in our products and instead got “mostly compatible” versions that still force significant customer pain. That creates huge barriers to migration, plus dependency on each customer’s development timeline.
- If you’re already stuck here, you’ll need to allocate an integration engineer to work directly with customers. You’ll also need sample code that maps old to new features. This gets even stickier if your new product eliminates some functions that are actually in use.
- Consider sending technical resources out to do the work for your customers. That may look expensive, but could cut years off the process. In reality, incompatible upgrades mean you may never get everyone off the old stuff, since their more urgent projects always crowds out your EOL demands.
4. “I’ll use the old version, even if it’s not supported. I’ll replace your product with the competition when I need to upgrade.”
- Hard to tell if this is bluster or a real threat, but it happens. Any time you force customers to make a change, the competition has a new chance to slip in.
- Have a clear end-of-support policy that aligns with your license agreement. Decide in advance if customers can use your unsupported product for free, or if you’ll accept extended support contracts at triple the normal rate. What will you do when calls for discontinued products come into Tech Support from your largest customer?
- Consider “jump” upgrades from v1.0 to v4.0. Will you drag out-of-date customers through v2.0 and v3.0, or is it worth building a multi-step process?
- Listen for EOL announcements from your competition. There may be sales opportunities as their installed base suffers through this muck.
5. “You didn’t tell me about this EOL.”
- Don’t attempt an EOL without a decent list of historical customers. Send out repeated notifications and reminders, and track which were delivered. For your largest EOL customers, contact them directly (by phone or personal email) to verify that a relevant person has been notified. There’s turnover in every company and department, so assume that some messages went undelivered.
- Politely assume that most customers will ignore your requests and updates. Emails get deleted, paper letters filed, faxes misrouted – so keep your contact list handy.
- Start early, give your customers enough time to lose a few requests and still get their migrations done.
EOL planning isn’t as exciting as new product launches, but needs to be approached systematically. And typically needs technical resources that the company wants to assign elsewhere.
Dropping old products creates problems for your customers. Think about their technical and economic issues first, then design an EOL program that helps get them over the hump.