墓碑

作为经验丰富的产品经理,我们大多数人最终都必须淘汰旧版本并完全淘汰旧产品。这称为寿命终止(EOL)或服务终止(EOS),并且是清除杂草的重要方法。通常是由 我们的内部经济需求:重新平衡我们产品组合中的资源,降低支持成本,将客户转移到最新版本,放弃无法自给自足的产品。


但是,对于仍在使用我们的旧产品的客户,EOL会带来迁移问题。他们对我们的内部问题不感兴趣,并为更换EOL产品花费的成本/精力/时间感到不满。在规划过程中,我们应该从客户的角度考虑这一问题,以减少EOL成本和挫败感。 (就上下文而言,我正在考虑为商业客户提供商业软件,但这通常适用于一般消费者软件和技术。)

以下是客户描述它们的五个问题,以及如何解决这些问题的建议。

1.“升级的成本远远超过产品的成本。我们需要设计迁移,测试,备份数据,迁移,重新测试和重新认证我们的应用程序,并让我们的审核员批准该过程。”

  • 优秀的EOL计划者将拥有一本“食谱”,其中完全描述了从旧系统到新系统的迁移。它将逐步详细介绍建议的过程,并包括工具或示例脚本。
  • 食谱强烈暗示您实际上知道如何推动客户前进,并且已经对流程中的每个步骤进行了全面测试。希望不是迁移策略。
  • 相应地设置您的停产日期。如果软件变更需要您客户的系统审核员的批准,则至少需要一年的时间才能完成迁移。

2.“我的计算环境非常稳定,可以选择。在早期采用者发现错误之前,我们永远不会使用新软件。我们将等到最后一刻。”

  • 许多精明的客户希望等待,让早期采用者发现EOL陷阱。您需要为所有剩余客户计划一次温和的提醒活动,其中包括日期,升级政策,指向资源的信息,并能保证先行者成功。现在创建一个记分板,以显示谁移动了,剩下的谁,并且参考客户表示过程很顺利。
  • 可以将客户推向受支持的平台(例如,从Windows 2000升级到XP)。卢克·霍曼(Luke Hohmann)称这些连锁反应为升级。
  • 看日历。延迟时间过长的客户将错过您的服务终止日期。

3.“您的替代品无法完全替代旧版本,或迫使我们进行软件修改。” 这可能是批发产品替换的故意目的,但是IMO通常是由于决策不力所致。作为产品经理,我们无法要求产品100%向上兼容,而是获得了“大多数兼容”版本,仍然给客户带来很大痛苦。这给迁移带来了巨大的障碍,并且依赖于每个客户的开发时间表。

  • 如果您已经被困在这里,则需要分配一名集成工程师直接与客户合作。您还需要将旧功能映射到新功能的示例代码。如果您的新产品取消了某些实际使用的功能,则此功能会变得更加棘手。
  • 考虑发送技术资源为您的客户完成工作。这看起来可能很昂贵,但可能会使过程中断数年。实际上,不兼容的升级意味着您可能永远也无法摆脱所有人的烦恼,因为他们较紧急的项目总是排挤您的EOL要求。

4.“即使不支持,我也会使用旧版本。当我需要升级时,我会用竞争对手替换您的产品。”

  • 很难说这是b强还是真正的威胁,但它确实发生了。每当您强迫客户做出改变时,竞争就有新的机会溜进来。
  • 有明确的支持终止政策,以符合您的许可协议。预先确定客户是否可以免费使用不受支持的产品,或者您是否以正常价格的三倍接受扩展的支持合同。当您的最大客户要求停产的产品获得技术支持时,您将怎么办?
  • 考虑从v1.0到v4.0的“跳跃”升级。您是否会通过v2.0和v3.0来吸引过时的客户,还是值得建立一个多步骤的流程?
  • 聆听比赛中的停产声明。由于他们的已安装客户群受此影响,可能会有销售机会。

5.“您没有告诉我这个EOL。”

  • 如果没有大量的历史客户,请勿尝试EOL。发送重复的通知和提醒,并跟踪已交付的内容。对于您最大的EOL客户,请直接(通过电话或个人电子邮件)与他们联系以确认是否已通知相关人员。每个公司和部门都有营业额,因此请假设某些邮件没有发送。
  • 礼貌地假设大多数客户将忽略您的请求和更新。电子邮件将被删除,书面信件将被发送,传真发送将被错误发送-因此,请确保您的联系人列表随手可得。
  • 尽早开始,给您的客户足够的时间来丢失一些请求,然后仍然完成他们的迁移。

EOL计划不像新产品发布那样令人兴奋,但需要系统地进行。并且通常需要公司要分配给其他地方的技术资源。

SoundBytes

丢弃旧产品会给您的客户带来麻烦。想一想 首先是技术和经济问题,然后设计一个EOL程序,以帮助他们克服困难。