互联网的真正力量在于网络技术的开源特性。任何有兴趣的人都可以搭建网站，任何有创意的人都可以创造出下一个Facebook。技术无关性别、无关信仰、无关种族，但技术的延续是依靠代码编写以及创作热情支撑的。
这伟大的力量促使人们产生了了无限的热情，「下一个伟大的网站或应用」可能就在你身边的任何一个人的脑海里。但是在这前赴后继的热情背后，是海量产品不断失败的残酷现实。所以你可曾想过，如果你的产品失败了，你该做什么？你该怎样将自己的产品体面地下线，给你和你的用户留下最后的美好时光？
我不怕失败！
商业社会里，下线一个产品通常是没有惯例可循的。从《时代杂志》到《哈佛商业观察》都在不断提醒我们：不断评估风险与失败的可能性对于建立团队和设计产品是至关重要的。但他们很少置喙下线产品的行为代价为几何，该考虑什么，如何处理反馈。
我们中的大多数都会在职业生涯的某个时候服务于某个即将失败的产品（这令人悲伤）。其中有一些产品确实是陷入了几无用户的残酷境况，但仍有一些产品需要你主动站出来承认我们难以为继，并同时开始采取措施。
产品为何会失败是一个已经被讨论过千百万遍的老话题，但只要这个产品成为了你的负担，你就会想要让他后台运转或者直接停掉。
在这里列举一下，如果某产品在以下几个方面使你负担沉重，你可能就应该考虑关掉它：
你的产品正在盈利吗？所有产品在开发和维护时都有开销。即使你的开销只是一台服务器，也是笔不小的支出。如果产品入不敷出，毫无疑问是一个经济负担。
你是否有优秀的员工来保证良好的用户体验？用户会不停提问、反馈、寻求技术支持，这些都需要消耗资源。大部分资源以通过客服支撑用户的形式存在，同时仍然可能会消耗一部分开发力量。如果一个公司没有维持良好的用户支持服务的人力以及资源，那么产品的负担便体现在资源短缺上。
保证产品的在任何时候都稳定有效需要付出什么代价？大漏洞以及兼容性维护将会迫使你们通过排期来解决问题。但如果你的团队无法顶住技术水平有限，只能任由一些漏洞延续若干个大版本，技术压力就显得尤为棘手。
你的产品是否影响了你的其他业务？不同的产品经常会共享一些底层代码。如果一个产品的存在给其他产品制造了大量额外的工作量，那这个产品就是一个拖后腿的存在。
让产品在后台静默地运行下去，还是果断关掉？这一类的决定总是会带有一些个人色彩和主观倾向。
所以我就可以让产品自己运行着咯？
对，这是一种比较吸引人的做法，你可以停止开发和资源支持却保持产品运行。但这种方法只适用于用户量比较大的产品或者公司本身被收购的情况。
当Adobe宣布他们将不再更新Fireworks的时候，它在通告里明确指出Adobe公司将会在可能的情况下保持最低程度的对Firworks的支持。
（请注意，他们只是说“可能”会提供漏洞修复而不是保证会这么做。）
这样的做法看起来令人心安理得并且简单易行。你只需要告诉用户你们不再更新了，然后让产品静默运行。你默默祈祷用户不会因此找上麻烦（因为他们还在用啊），你甚至让自己可以免于解释为什么要停掉产品（多聪明啊）。
即使你不想再继续开发了，用户会不会仍然等着你去修补他们发现的漏洞？就好比AdobeFireworks，你能不能保证它在用户的新系统上运行良好？
如果无法提供这个级别的支持，失望的情绪就会在用户心里滋长，开始损坏你整个公司（团队）的品牌形象，影响产品。
请好好评估你做的每个决定，预估他们可能带来的麻烦。如果你无法承担产品后台运转的技术压力或资源压力，你最好直接关了它。
下线一个产品就好像一次分手
你已经决定了关掉你的产品了。它已经给你的你的团队带来了太多的麻烦，大家都觉得果断抛弃它今后会过得更好。那么接下来怎么做？
这过程和分手很相似。你要告诉用户就是：你将不再和他们保持联络，你们要分道扬镳了。
就像电影里被演烂了的桥段一样，分手的核心指导思想就是“你是个好人，都是我的问题。”好好想想，用户已经陪你走过了这么长的路，而你却选择离他们而去。假如你收到了负面的反馈（也许很负面也说不定呢），也请默念“这不是他们的错”三百遍。用户所表达的任何沮丧与愤怒都是因为他们失去了你的产品，所以一定要做好准备应对负面反馈，然后优雅地处理掉，谢谢。
一、制订“下线计划”
开始下线前准备得越充分约好。无论你的计划有多翔实，你都会在这条不归路上遇到不少不测，所以必须准备充分从而留有有变通余地。
下面的大纲是建议遵循的10个步骤。每个产品都是独一无二的，你肯定会有自己的附加要求，但这些步骤会让你更稳健，更从容。
下线前1-6个月
你可以做点什么来帮助用户离开得更舒畅？你会不会推荐竞品或者允许用户导出个人数据？请记住，虽然你的产品倒了，但可能其他人仍然有能力接管市场份额。
来，试着体会一下用户的心情，假如你最爱的产品要关了，你最想得到什么样的信息？你最想得到什么样的待遇？你可以开展一些抽样可用性测试来了解一下，怎么使这个过程无痛不痒。可用性测试在关闭产品的情境中很少被提及，但假使你的用户体验大局观还在的话，做这个测试是善始善终的体现。更何况到了这个阶段，是你欠了你的用户一大笔。
Readmill在关闭前列出了“Nextstepsforreaders”
一旦你发布了下线通告，就立刻停止一切新用户注册。在通告发布后流量可能会略有上升，但是新注册用户将会使沟通难度变大，而收益也不会显著增加。
如果你有自动发布的直邮推广，希望你也能照此来处理。
如果你提供了在线支持，你应该把这些内容更新为下线状态，提供一些用户用得到的迁移指导。用户可能仍然需要使用你的产品，需要得到你的帮助。你应该开始接受有关下线的各种问询，做好向他们提供建议的准备（参见Step2）。你可以直接和他们对话，监测数据迁移的成功率。通过知悉这些用户的内心想法，你可以帮助他们更好地度过这一时期，减少你自己的麻烦。
下线前1星期
下线前1天
这是你提醒用户下线的最后机会。一些人可能会回复你说：提醒的太多了，但是提醒过多总比让大家错过消息来得好。上一封可能被自动归为垃圾邮件了也说不定呢。
下线后
你有没有欠着用户的款项？产品下线后立刻偿还欠款。
如果用户购买的是按期支付的服务，那就要考虑一下继续向他们收款是否合理。是否应该从今开始免费提供取决于你的产品类型。
你是否想要保留服务器和网页版？也许你想要展示一些关于你们团队的历史和目前的状况，或者设置一个跳转链接来指引那些了旧网址的用户。
举个例子，如果你想要保留这个产品的微博账号，你会不会定期查看并然后回复反馈？一旦做不到会也许就会给人留下团队不靠谱的印象。所以千万不要仅仅保留账号却什么都不做，这么做也许轻松但弊大于利，监测舆情并处理反馈仍然是你的职责所在。如果你不能很好地运营这些账号，强烈建议还是注销的好。
以上这些步骤并不全面（你对你自己的产品应该有其他具体要求），但是如果你在下线前有针对性地实施了这些步骤，即使今后发生意外你也能不变应万变。
二、如何说再见
让用户知道你们即将下线是最重要的事。这需要你们对用户如实相告，毫无保留。而你们说了什么，是怎么说的，这两个问题将会使问题的关键。
为了帮助大家起草，下面列出文案中需要包含的关键点。每个关键点都会根据你们团队（或公司）与用户的关系不同而有所不同，但是总体来说它们需要向用户明确表达：即将发生什么，即将发生的意味着什么。
这份通告应该通过两种途径发布：电子邮件以及自己产品的推送通知。也许你们团队不情愿在公众视野内发布这样的信息，但是别指望所有用户都会看邮件。如果有必要甚至可以强迫用户点击一次推送通知。
你的用户肯定想知道到底怎么回事（你们要下线还是要被收购了？最后期限是怎么安排的？）。简单明了地阐述一下即将发生的事情和他们要面对的处境。
GoogleReader用弹窗来宣告他们将在何时关闭，并提供一个链接来说明更多细节
在每一段关系结束的时候，人们都想知道为什么会这样。请忍下你想要讲一个励志故事的冲动。这一切也许都是因为你们没能盈利，或者你们团队中出现个人问题。尽量和用户保持坦诚，无论你们产品是出于何种原因下线，自己的产品总归是自己的，没有理由让用户觉得是他们对你们支持得不够多。
你已经告诉了用户为什么你们要下线以及将会如何下线，你需要让他们知道这对他们来说意味着什么。他们是否会失去个人数据还是说他们有第二条路可走？他们需要进行一些操作还是你将会把一切都搞定？如果这是收费服务，那账单怎么结算？
假如你和用户坦白，很大程度上他们也会充分理解你们并表示同情。所以，有必要的话可以让他们了解一下团队状况，大家支持了你们的产品和团队，也可以让他们知道一下你们将何去何从。
最后，感谢一下你的用户，无论你的用户量有多大（多小），他们毕竟支持过你的梦想，陪你走过了同一段人生道路，从始至终都给予着你奋斗的激情。
下线是一个严肃的决定。你们承认了自己无法达到预期，即将不再和用户产生关系。所以请保持庄严和尊重，这不是一个适合开玩笑的时候。
如果我说了这么多让你觉得难以顾全，那是因为这确实不是一件小事。毫无疑问，你团队的所有人都要用好几个星期甚至好几个月来决定这个决定那个，但如何善待用户这件事和善待用户本身一样值得投入心血。
有些人会支持你，也有些人会生气、沮丧、歇斯底里，而无论如何你都必须开诚布公。即使有人指责你，认为你辜负了他们，你也必须记住，他们有权利这么认为。