你只會推進產品上線?那你懂產品下線嗎?
每個產品都有其所存在的生命周期,有的可能是注定出生后就要夭折,有的可能是輝煌過后總需要隕落。但不論如何,相對于推進產品上線而言,如何優(yōu)雅地處理產品的喪葬事宜,我覺得更加重要。
今天整理了下公司近幾年的相關項目,差不多三四年的時間吧,嘗試了大約五六十個業(yè)務項目(含合作平臺對接)。但幾年下來,真正意義上還在正常運轉的其實也就個位數,絕大多數項目最終都因為各種原因而停止了。在整理的過程中,寫了點備注關于項目停止運營的原因,然后在回家的路上,突然心血來潮想著說點什么。
一、產品建檔管理的優(yōu)點
整理了五六十個產品項目,其中很多項目因為是早期的項目,只知道其名稱,但整個項目的背景經歷乃至現狀幾乎找不到任何資料可以查看。
比較常見的是,出于審計或者其他原因,可能需要這種老古董項目的信息,然后就會出現一種現象—— 一個一個地去詢問可能知道的人,最后可能也是毫無結果。
因此,在做產品的過程中,其實學會進行產品(或者項目)的建檔管理其實很有必要,大致會有如下優(yōu)點:
1. 產品具有完整的時間脈絡,方便后期進行項目的回溯和查詢
人的記憶和口頭傳達實際上永遠不如文字記錄的承載,(扯遠點,所謂的詩書傳家,難道也是因為古人知道自己某一天掛菜了,可能就要靠這些文字傳播一下,讓后輩子孫知道“子曾經曰過”?)尤其是在產品功能不斷改版迭代,越來越復雜的情況下,有完整的書面記錄才能復現一個產品的完整發(fā)展歷程。當然,有完整的項目檔案,也方便項目審計等。
2. 便于進行工作上的交流和溝通,提高效率,讓其他人盡快了解業(yè)
當公司的發(fā)展到一定規(guī)模的時候,跨部門跨BD的合作會越來越頻繁,并且人員的流動也很頻繁。我們可能需要給新入職的同學進行相關業(yè)務的介紹,可能需要在開展跨部門合作的時候,對合作方介紹相關的改動內容。
如果沒有完整的文字承載和建檔,那么可能會一直陷入在重復性的溝通交流中,而如果有相關的材料,就可以先讓不熟悉的人通過這些沉淀歸檔的業(yè)務進行快速了解。
3. 便于進行項目的復盤總結,并能夠成為后續(xù)工作的經驗借鑒
“以史為鑒,可以知興替”,產品建檔在一個公司的發(fā)展中一樣存在著相同的知興替的作用。
我們如果認真記錄每個項目上下線過程中的問題,去總結和回顧其成敗的原因,就可以為后續(xù)進行深度的積累和準備;也可以讓其他人以此為鑒,在后續(xù)新項目的開展過中,能夠規(guī)避曾經遇到過的問題或者吸收其中的優(yōu)點。
二、好是好,但實現難呀
既然建立完整的產品檔案有這些優(yōu)點,但實際上卻很少有人這么做或者說做了但不夠好。想了想,可能有如下原因:
1. 從公司或者部門層面,沒有完整的流程指引或者規(guī)范
這種工作層面上的東西,如果從公司層面的角度以及從現實物質利益角度來看,其實沒什么太大的作用,沒有辦法直觀地看到可以量化的效果。
雖然現在一般互聯(lián)網采用協(xié)同辦公的方式,基于wiki等進行文檔的歸納管理,但在wiki的建立、維護和管理上,也是亂得一踏糊涂,基本上也就是作為日常的工作類文檔。這類文檔只在某一時刻有作用。
2.?在追求效率和快速迭代試錯的產品中,沒有時間進行完整的文檔建立和維護
這應該是最主要的原因,常見的比如產品需求文檔。
當文檔完成后,在經歷各種評審、以及開發(fā)過程中,對于原有的需求設定可能會經歷各種變化和調整;但文檔并沒有及時更新,或者直接不寫文檔,直接就開發(fā)了。因此也就容易出現文檔的斷檔(吐槽下,這我覺得也沒什么特別好的解決方法,因為我自己都有的時候懶得更新,所以難道是懶得原因?懶惰原罪?。。?/p>
3. 缺少及時的正向反饋
因為文檔的更新和維護,本質上其實不會太大特別直觀的效果,而且估計大多產品或者開發(fā)想吐槽的,你寫的東西給誰看?
沒人愿意看啊……久而久之,因為缺少積極正向的反饋,可能就不愿意把文檔寫得太詳細或及時更新了。最認真看相關產品需求文檔的只有測試了,可憐的測試作為產品開發(fā)過程中的最后一環(huán),背負了多少壓力……
三、產品建檔都需要啥
結合日常工作以及今天的一些思考,大致想了下,一個完整的產品檔案的建立需要什么。有這么一些不成熟的建議:
1. 項目相關背景
就是為什么要做,做這個是出于什么考慮,做了的話有哪些價值等,通常體現在MRD、BRD上。
雖然工作上其實不怎么寫這兩個文檔,但還是有必要簡要說明,如果是外部合作類的業(yè)務,其實對于合作方的相關介紹,也是很有必要的。
2. 項目相關人員
這個實際上在項目出現問題,需要快速排查的時候就會發(fā)現很有作用,便于直接找到核心人員。原則上在項目的人員更替變動最后也有記錄,最新的責任人,以及歷史相關責任人等。
3. 相關需求文檔及功能介紹
這個屬于產品需求文檔的一部分,本質上重點在于需求文檔的管理,最主要的其實不是需求文檔的編寫,而是需求文檔的變更維護,要保持與時俱進的更新。
4. 項目的復盤總結
這個屬于產品上線完成后,需要定期地進行跟蹤維護,并總結相關的數據,以及其中踩過的坑。
作用其實很大,但說實話就沒見過做得好的。
復盤本身是一個大的命題,可能短期我們會進行產品效果跟蹤,以及數據的回收分析,但卻缺乏長期持續(xù)的跟蹤和回顧。比較好的總結,在理論上是需要隨著時間的延續(xù),尤其是在長時間回顧后去驗證的,就好比經濟發(fā)展有其周期規(guī)律一樣。
比如A股,我們今天看,它莫名其妙地在2019年5月6號所有指數一篇綠油油,我們可能會認為是茅臺引起的或者是因為股神巴菲特剛開完股東大會(瞎扯的。。??葱侣劽┡_今天市值蒸發(fā)854億,開玩笑,A股第一股?。赡芤荒旰髞砜?,可能是經濟發(fā)展周期中其他因素導致。
5. 項目的死亡證明
今天我本來想聊的是關于產品下線的處理……這才是本文重點,我決定給它個大標題!
四、如何給死亡產品辦葬禮
人出生有出生證明,死了當然也有死亡證明。我們在項目中,產品上線通知基本都不會忘了寫,但對于產品停止運營下線了,基本都不會進行廣而告之,尤其是不會寫為什么下線?為什么下線?為什么下線?
所以我要說的是——作為產品,你懂怎么進行產品下線嗎?你知道怎么給你負責的產品辦葬禮嗎?
每個產品都有其所存在的生命周期,有的可能是注定出生后就要夭折,有的可能是輝煌過后總需要隕落。但不論如何,實際上相對于推進產品上線而言,如何優(yōu)雅地處理產品的喪葬事宜,我覺得更加重要。仔細想想,這個葬禮應該這么辦:
1. 準備好操辦白事所需的一切材料
既然產品已經死了,我們就要為它辦理身后事,需要進行相關的材料準備。產品在下線時,我們需要根據其狀態(tài),決定下線后的善后事宜。根據情況大致可以分為兩個方面:
- 對于用戶:停止新增用戶,安置存量用戶。如何處理保證不會有新增用戶,準備停止運營的相關用戶通過,引導存量用戶的遷移等,確定最終停止運營的產品下線時間等
- 對于公司關聯(lián)部門:如何同步各關聯(lián)方相關的下線事項,每個部門需要進行那些動作,如何培訓客服部門進行解答等。以及相關的無用的代碼、應用配置、服務器等是不是要進行處理。
整體而言,下線相關的準備以及處理,最好能形成文字落庫存檔,以便于后續(xù)可以追述。不過貌似有一定用戶量的產品停止運營,這部分大都會做得比較好,考慮得深入一些,還會思考以及規(guī)劃如何將這部分存量用戶進行留存以及向新的產品轉移等。
2. 雕刻墓志銘,悼念其一生
這個產品已經壽終正寢了,那么我們需要回顧它光輝的一生,給它寫墓志銘——X產品,生于X年X月X日,因XX原因于X年X月X日卒。
比較感觸的在于——很多歷史項目其實是什么時候開始停止運營的,幾乎都找不到任何的記錄,尤其經常不知道為什么原因而停止。
這本身需要和項目復盤相結合,每個產品停止運營的時候,其實最主要以及最有意義的一件事情,是開個“追悼會”緬懷一下這個產品的一生。我們去分析這個產品為什么要下線,它取得了哪些矚目的成就,以及有什么遺憾沒有完成。
但事實是,很多項目都死得毫無價值……因為我們壓根不去分析它為什么失敗。
回顧了下,我自己經歷過的產品,大部分九死一生,但從沒真正意義上去組織復盤思考會,去思考為什么會失敗,這其中是哪些事情做錯了。
我覺得對于一個公司而言,真正有意義的,其實應該是對于公司內部失敗的項目進行復盤整理,并能夠作為培訓材料(哎,感覺這就是商學院的案例分析啊,突然覺得每個成熟的互聯(lián)網公司都該進行產品失敗案例分析課程,這才是最大的資本?。?/p>
五、結語
核心感覺其實就一句話——對每個經歷過的失敗的項目組織復盤總結,分析整個項目的過程以及其失敗的原因,是最大的財富。
#專欄作家#
作者:可飛,公眾號:@可飛(ID:abckefei),非正規(guī)出身,野蠻生長的不入流產品經理。
本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協(xié)議
寫的什么玩意
平安自助保,平安產險獨立開發(fā)的車險在線投保展業(yè)APP,生于2014年7月25日;slogan:移動車險展業(yè)利器;曾坐擁平安產險30萬代理人,單天最高日活14.3萬人次,14年年底正式上線至2017年年底為平安產險貢獻簽單保費超44億元;17年7月6日保監(jiān)會174號文發(fā)布后成為犧牲品,17年7月25日,卒;享年3周歲。
你為何如此優(yōu)秀