塵歸塵，土歸土
所有的產(chǎn)品都有自己的生命周期，高強度的競爭也使得，移動應用的死亡率越來越高。根據(jù)艾媒咨詢《2015年中國手機App市場研究》的數(shù)據(jù)：
移動應用的生命周期平均只有10個月的時間
作為一個產(chǎn)品經(jīng)理，有時「如何告別」是一個不得不面對的問題。
這段時間太動蕩，好久沒有寫東西了，就著這段時間剛好孵化的產(chǎn)品下線了。本文算是自己對移動應用下線的過程的簡單總結吧。
*不哭，好歹在我手上已經(jīng)終結了3、4款應用了， _(:3」∠)_ *
既然無法繼續(xù)，那就好好道別
國內大多數(shù)稍有規(guī)模的公司，關于產(chǎn)品上線都是有一系列的流程規(guī)范的。相反，產(chǎn)品下線，大多都是草草收尾，甚至有些就和慈禧老佛爺面對八國聯(lián)軍出逃至西安一般，神色慌慌，七零八落。
其實，作為產(chǎn)品經(jīng)理，在能力范圍之內，至少我們還可以，好好向用戶道別。
1. 確定下線影響與時間點
產(chǎn)品上線需要有計劃，自然下線有應當如此。起目的主要是為了同步各項工作的時間點，保證一些工作的順利交接，比如計劃可以包括以下主要事項：
確定影響范圍
產(chǎn)品下線不僅會影響用戶，同時很有可能會影響其他如渠道、PR、BD，以及一些其他支援團隊。確定影響程度
影響程度，主要針對的是用戶端，相當多的應用不僅存儲了用戶數(shù)據(jù)，甚至還有一定的儲值或者增值服務。產(chǎn)品在線時，這些都是寶貴的財富，產(chǎn)品下線后，這些就都是「債」了。確定時間點
當然不同類型的產(chǎn)品，涉及的點會有所不同，但大致會包括：發(fā)布通告、應用下架、用戶賠償、服務關停、資源回收等步驟。
大致步驟確認之后，應當跟進之前確認的影響范圍和程度，開展工作。
2. 確定彌補方案
產(chǎn)品下線，勢必對用戶造成影響，一個用戶也是用戶，盡可能不要造成太大的傷害。傷害的來源，主要是兩大塊：
-
用戶數(shù)據(jù)
一般來說在下線產(chǎn)品前，應該盡量保證產(chǎn)品中已經(jīng)有了數(shù)據(jù)備份和導出的能力，這樣，可以盡可能減少用戶數(shù)據(jù)的損失。比如如果哪天「簡書」倒閉了，就應該保證能夠有備份或者導出文章的能力。
當然，UGC產(chǎn)品來說，用戶數(shù)據(jù)的備份和導出能力應該是一個基礎能力，再比如很多圖片社區(qū)，在生成并發(fā)布圖片的過程中，已經(jīng)將圖片同事保存到了系統(tǒng)相冊。
-
用戶財產(chǎn)
對于大廠應用來說，財產(chǎn)彌補一般來說方案還是可以有很多的，很多時候都是自己資源置換（比如給你充個鉆），甚至，直接現(xiàn)金賠付都是可能的。這個時候，就必須設計一個較為完整的賠付流程，如果涉及金額較大，最好有安全團隊的支持。對于小廠應用來說，都下線了，很多就意味著破產(chǎn)了，財產(chǎn)彌補的什么，可能是心有余而力不足了。不過可以的話，盡量保持自己的節(jié)操。
3. 好好寫一則通告
公告的內容不外乎抒發(fā)情懷，闡述原因，確定流程，替代方案等內容。
一般通告的渠道包括：應用內的通告渠道、PR公關、社交媒體等。對于很多小產(chǎn)品來說，先在應用內好好寫一則通告吧，可以如圖所示。
什么，你的產(chǎn)品內不能發(fā)布通告？好吧，那請忽略吧。不過，目前的移動App，一般一開始就需要設計一套內容分發(fā)模塊，不然運營起來真的很累
4. 資源結算與回收
外部資源包括：一些應用市場的下架、渠道或者置換資源的結算、外部云服務的結算（比如阿里云、七牛、AWS服務等），能開的發(fā)票都開好。
當然如果是一些純本地工具應用，其實也可以一直放在應用市場上，能服務多少用戶就服務多少用戶吧。
內部資源包括服務器與域名資源的回收（服務已經(jīng)停止）、數(shù)據(jù)與代碼的備份、財務結算。
PS：關鍵的合同一定要交給法務、財務來處理！(如果有的話，233)
5. 收尾
到這個階段，其實下線工作已經(jīng)基本完成，從產(chǎn)品經(jīng)理角度，可能還需要做一些工作：
整理產(chǎn)品文檔與設計稿，并歸檔。
產(chǎn)品文檔與設計稿，就是這個產(chǎn)品的化石 。總結產(chǎn)品失敗原因。
嗯，失敗是成功他媽。維護核心用戶。
可以將優(yōu)質用戶轉移到其他自家產(chǎn)品中。如果有能力也可以保持用戶群的運營，把用戶當朋友來看時，反而有一種親切感。甚至，說不定下一個產(chǎn)品的種子用戶就來源于此。
不要忘了自己
和團隊里的朋友們好好吃一頓，謝謝大家辛苦付出
然后，流著眼淚，帶著微笑，向過去道別，向未來進發(fā)
