編輯導語：每一個產品都是從初級階段迭代發展而來，從一個輕量級簡化版的產品投入市場不斷升級從而演變爲一個炙手可熱的國民品牌，除了要選對路，更重要的是選對人。本文作者提出接到MVP產品後的幾點必做建議。

之前天下網商有做過TIMI行業員工司齡的數據調查，互聯網人平均司齡沒有超過三年的，行業員工離職率從2016年的11.5%上升到了2018年的15.8%。

這說明不是所有的產品經理都可能陪自己產品從0到1再到2，大概率的情況是：一個產品經理從一個產品的構思，到產品的設計規劃，再到原型文檔輸出；累死累活好不容易MVP產品上線了，他就離職或者各種原因轉到其他的部門了，再由其他人來接手他現在的工作。

其實這個時候最考驗的就是接手工作的產品人，在本應該快速迭代的時期，她現在應該還在熟悉行業熟悉產品；如果她對行業本身已經很熟悉對市場需求很瞭解，那她會輕鬆一點。

不過有些事情，必不可少一定要做：

一、理解前任產品經理的構思規劃

可以通過前任產品經理輸出的產品規劃文檔或思維導圖來了解，如果時間緊迫，前任經理沒有任何規劃類文檔輸出，那麼你一定要把握工作交接的機會——討論產品定義規劃的思路，過程中一定要注意瞭解這個人的性格，來分析她的工作方式。

比如如果你瞭解她，不用問你就知道她爲什麼會在icon旁放一個文字類的解釋說明； 她一定擔心的是使用者是中老年人，對中老年人來說，一個確切的告知的文字，比任何表現形式都來的重要。

那你就可以根據他的原因判斷，這個對於你目前的發展方向以及面向客戶來說是否應該保留。

很多時候通過問答的形式，瞭解到前任產品經理每一個功能定義的原因是非常有限的，這時你已經對她的產品有了初步的分析， 但有些地方你很難理解的時候，去諮詢是非常有用的。

但通過問答，去了解一個人相對來說會輕鬆很多，你也可以根據她的習慣思維去判斷，哪些功能對她來說價值在哪裏，對你是否有用。

二、瞭解當前公司態勢

當前公司的態勢，對產品的影響是十分巨大的，當然也只有兩種結果，做還是不做。

但其中的灰色地帶會告訴你你該怎麼做。

比如在大公司，這個目前是公司的創新型項目，那對這個項目可能不會有過多投入，如果沒有外界因素影響，你能利用的資源會非常有限，大概率會應用到你自身積累的人脈或者資源才能將這件事完成。

如果資源都向你所在的項目傾斜， 那你更要注意了，每一步都要經過謹慎思考，要合理利用現有的資源，以最終目的爲目標力求把所有事情做到最好。

因爲你的一舉一動可都在被人關注着，但求成功不過也別怕失敗（心裏狀態一定要調節好，不然會直接影響到後面的工作，好的有意義的失敗大公司也是可以接受的，怕的就是尋死覓活一蹶不振）。

不過不管公司如何，既然給你分配這項任務了，肯定是想做這件事的，無論態度是否明確，只要你感興趣，願意接手，最好都要打起十二分的精神把這件事做好。

即便沒有給你合理的資源，但你依舊把這件事完成的很好，這個漂亮仗一定有機會讓你翻身做主人的。

三、近距離接觸客戶

你要做一個產品， 最基礎的就是場景、對象、目的。

你可以參考前任產品經理的整理資料，但一手資料，才能讓你更深刻的認識問題。

你得貼近客戶，瞭解客戶的業務流程、操作習慣、工作環境、他們經常會面臨哪些問題、他們遇到最討厭最害怕最生氣的問題分別是什麼。

設計產品的時候千萬不要把自己剝離開，覺得客戶可能會遇到什麼問題，自以爲然閉門造車；而是充分了解客戶以後帶入自我，我在這樣一個工作環境中最希望有一個什麼樣的產品幫我解決問題。

通常前期準備資料的文檔裏會覆蓋一些這部分內容，但肯定不全面，如果有機會近距離接觸客戶，參與一線，人家工作裏的一個動作，就可以透露出很多信息解答你設計中的疑惑。

產品設計是爲了解決現實工作生活中遇到的問題，或提供一些新方式新思路，千萬先不要考慮技術實現。

技術是可以配合產品的，除非是絕對的技術產品，大部分產品只要定義明確了，實現就是沒有問題的，有問題也是可以討論攻克的。

產品設計一開始就考慮技術實現問題只會禁錮你的思維，讓你偏離目標航線越走越偏；結果本來是一個可以充分獲得用戶滿意的產品或功能需求，最後只能讓客戶勉勉強強接受，就不值當了。

四、要不要留着當前的MVP產品。

這是我們把前期瞭解好以後面臨的第一個問題，當前的MVP產品是否符合發展規劃。

一般情況下，MVP的產品都是緊急倉促下定義的，但直接廢棄不用的概率還不高，一般都是留到後面；待原有的架構滿足不了業務流程最後進行架構重構，架構重構複雜性到了一定地步的時候就需要從頭重新開始了。

如果現階段就可以考慮到未來最大情況的發展規劃，對後面的業務發展肯定是利大於弊的，這樣在代碼中儘量低耦合高內聚、 靈活性高、可靠性高就可以滿足擴展大部分的業務場景了。

不過如果發現不合理的地方，甚至會直接影響產品的未來，那麼一定要做好判斷。

長遠評估來看，現階段重新開始比已經發展一個階段獲得了一批穩定用戶、發展了定向穩定業務以後再重新開始的成本可小多了。

五、會偷懶

最不應該由偷懶現象存在的除了防控安全的職業人， 就是產品經理了，所以我指的偷懶也不是指不經過思考的決策。

我本意想指知道權重會省事兒，知道什麼該省、什麼不該省、哪些需要多花心思、哪些地方可以暫且忽略不計，這也是一門學問。

首先方向上一定不能省，需要經過我們反覆縝密的思考。

我們走路都是奔着目的地去的，目的地決定着我行走的路線，直走還是拐彎；行走的方式，我是開車還是公交，騎行還是步行。目標一旦有問題，那你出行的基礎就不成立了，很容易返工哦。

細節上可以省，這個細節是指在你的綜合判斷中不確定且未經過實踐驗證無法明確知道結果的細節。

比如彈窗的關閉icon應該放上邊還是下邊，logo是放在上邊還是下邊，這個遵從一般的系統現狀就可以了，或者也可以先吸取重要相關方的意見；在迭代反饋中有收到相關意見或者有一定的原因理論基礎需要放在其他地方，調整起來難度也不大。

六、總結

其實接手一個在迭代過程中的產品難度是比初創的難度要低一點的，因爲前期已經有例子可以參考，但成長的速度是非常快的，基本都是你在掌握着這個產品的命脈成敗。

假設只是一個demo，MVP不足以讓產品活下來；假設產品迭代的比較穩重成熟了，產品的作用就無非是錦上添花，做的稍微沒有那麼好，也不會大範圍的直接給產品造成負面影響（我說的是產品人哈，是有重重評審的，代碼那個刪庫的不要算在內）。

一個產品，打下基業固然重要，更重要的就是迭代發展， 把人家的MVP完善發展成一個巨無霸可是一個漫長的過程，一環都不能錯。

本文由 @何所有 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議