編輯導讀：當產品經理接手了一個已經成型的產品時，我們應該怎么做？應該注意什么？本文作者從六個方面展開分析，希望對你有幫助。

一個合格的產品經理應該如何快速接手一個新產品，這里的新產品往往會分成兩種情況，一種是正真意義上的新產品，以前沒有這個產品，由產品經理負責從0到1創造這個產品。

另一種是對產品經理而言的新產品，這個產品本身就有，現在由于人員調動、新員工入職、老員工離職等原因要找一個以前沒參與過這個產品的產品經理來接手，那對這個即將接手的產品經理來說，這也是一個新產品。

從0到1的產品能力就是完整的一套產品經理的工作流程，是每個產品經理的必修課，所用到的知識和技能也就是對一個合格產品經理的全面要求，如果聊這個今天這一篇文章可就放不下了。

我們今天要聊的是第二種情況，接手已經成型的產品時我們應該怎么做，在實際的工作中接手別人產品的場景事實上也是遠遠多過自己做一個新產品的，所以其實對大多數產品經理而言，接手已成型產品的經驗才是更常用的，下面我們就來聊聊它。

一、產品背景

千萬不要一上手就把自己扎根到細節中去，要了解一個產品一定是要先從整體認知上知道這個產品是做什么用的，是在什么情況下被發現需要有這樣一個產品的，它能夠幫用戶解決什么問題，在公司的整個產品架構中它充當的是一個什么樣的角色，它的價值主要體現在哪些方面等等，先要了解到這些比較宏觀的概念，對產品的整體情況有一個比較清晰的把控。

這一點是很重要的，你對產品整體把控的準確程度直接決定未來能否在產品發展的決策上做出正確的判斷。而且這種整體把控的事情，往往是經過原來產品團隊抽象過多次的，是可以幾段話就明確概括的，所以最先了解這個維度的事情，本身是不會占用產品經理太多時間的。耗時少作用大，最先做整體背景了解可以說是一件性價比非常高的事情。

二、產品框架

已經成型的產品正常情況下會有兩個維度的產品框架，一個是現有框架，是已經落實到當前產品功能上的框架；另一個是規劃框架，是產品創建初期做整體規劃時繪制的產品藍圖，正常情況下產品經理會根據這個產品藍圖來逐步完善產品功能。

這兩個框架都非常重要，了解現有框架可以幫助產品經理快速了解產品的功能結構，知道哪些功能點是被歸類到哪個模塊下的，以及各個功能模塊之間是如何配合的，或者各個功能模塊之間有哪些影響關系。了解了現有框架以后，產品經理就可以對產品有一個比較模糊的把握，基本可以做到別人提到一個功能點的時候，你知道該去哪個菜單下找到相應的內容。

而了解規劃框架，則是給未來升級改造這個產品所做的準備。既然這個產品還是需要新的產品經理來接手管理的，那大概率這個產品還是需要繼續迭代升級的，那產品經理怎么做后面的產品升級工作，就得看規劃框架、看產品藍圖了。產品要知道哪些規劃是現在已經實現的，哪些是未來要進一步去做的，就需要對兩種框架都有明確的把握。

三、了解業務

這是很多產品容易忽略的一點，尤其是在這種接手成型產品的情況下，因為已經不是產品的定義期，所以產品經理就很容易忽略真實的業務場景，而是更多關注用戶對產品的使用，這樣就很容易順理成章地進入前面產品經理所設定的產品使用路徑中，而不太容易發現產品可能存在的不合理之處。有些用戶在使用產品一段時間后就會被產品馴化，他們漸漸將一些不合理的地方理解成一種新的規則，自然而然跟著產品設定的路徑去執行，所以靠用戶使用其實是很難發現這些不合理的地方的。

這就要求新接手的產品經理在真正介入產品生產工作之前，最好能深入產品用戶的業務場景，了解一下當用戶在沒有產品提供支持的時候是如何完成相應的事項的。這就類似于在產品初期了解業務的原始需求一樣，每個產品經理對原始需求的解讀都可能不同，你只有自己真正了解用戶的真實訴求了，才能判斷現在的產品是不是真的符合用戶的預期，你才可能及時發現前面的產品經理有沒有給你留下一下潛在的隱患，及時發現這些問題并解決，而不是等到問題爆發的時候才推卸責任給前面的產品經理。

舉個不恰當的例子，你的繼子犯錯誤的時候警察也會來找你這個法定監護人，而不是去找他已經失蹤的親爹。我們做產品常常說把產品當成自己的孩子，那這種從別人手上接過來的產品不就是繼子嗎，那你現在既然已經被安排當這個爹了，就要負起責任來把兒子的方方面面都了解清楚，當好這個繼父。

四、熟悉功能

當你真正了解業務場景以后，再帶著業務的視角去了解產品的功能，這個時候你可以給自己定義一個角色，那就是一個懂產品的業務線同事，在了解產品的過程中可以給這個角色加一個特點，那就是愛找茬。一個產品經理在接手一個新產品的時候可能只有這一次機會能夠以這種視角和心態去面對這個產品，在這個對產品基本陌生的階段，是最有可能、最容易找到產品設計不合理之處的，所以各位一定要把握好這次機會。

這里更深一層的多說一點，一個產品經理在面對自己產品的時候，其實也可以嘗試用這樣的第三方視角去審視自己的產品，去挑自己產品的毛病，找它設計不合理的地方，不要擔心會對自己有什么不好的影響，要敢于質疑自己，要不斷去挑戰自己，這樣你的產品和你自己才能不斷的成長和進步。

說回了解新產品功能的部分，大多數人習慣使用的方法是直接把自己當成一個真實的用戶去使用該產品，從注冊登錄到賬號設定再到系統操作，所有的產品細節都來試用一次，去感受產品的特點和能力，這是最快了解產品能力的方法，也是最容易發現產品問題的方法。除此之外，產品經理還可以通過查詢前任產品經理需求文檔來了解產品的相關功能，這種方法則是能夠更深入了解產品設計之初的理念和想法，有些使用時覺得有問題的地方也可能會在需求文檔中找到當初這樣設計的原因。

最后產品經理還可以通過給產品寫操作手冊來進一步熟悉產品功能，可以在完全試用完一次產品以后來給產品寫一份現有功能的操作指導，盡可能詳細地描述產品的使用方法，并在其中標注需要注意的內容。完成上面這一整套操作以后基本就對產品現有功能基本掌握了。

五、梳理需求池

正常情況下一個產品都會有一個專屬的需求池，也就是需求管理清單，分門別類地記錄該產品已經做了哪些需求，用戶提了哪些需求，后面規劃還要做哪些需求等等，接手產品的時候找相關對接人員問一下看有沒有產品需求池，有的話一定要接手過來，并且找前任產品經理了解清楚里面涉及到的相關內容。

如果前任的產品經理沒有整理這樣的需求池，那我們就需要自行梳理了，還記得前面提到的規劃框架嗎，可以根據規劃框架和現有內容的對比梳理出下一步要做的需求，還有我們在熟悉產品功能時所記錄下來的問題，以及一些你認為產品需要改進的地方等等，這些都可以演變成需求內容匯總到該產品的需求池中。

當然，如果前任留了需求池，我們也還是要梳理自己的內容，可以把自己了解過程中梳理的內容跟前任留下的內容做一個整合，相同或相似的內容合并，不同的內容保留，最后形成一份屬于自己的需求管理清單。

六、產品升級&團隊磨合

前面的內容都完成以后就要考慮產品升級的事情了，接手新產品以后最好不要一直停留在運營產品的階段，接手以后這個產品就是你的了，你就要開始推動這個產品邁向新的臺階了。前面該了解的內容都了解了，需求池也已經準備好了，接下來就可以先選一些相對比較簡單的功能項，快速安排一次產品升級。

為什么要選相對比較簡單的功能來做升級呢，一方面簡單的功能各方的工作量都不會太大，適合速戰速決；另外產品經理這邊作為一個剛接手不久的新成員處理簡單功能的話也不會出現什么太大的失誤，算是把風險控制在可接受的范圍內；還有一個原因就是，這次小的升級是你跟這個產品團隊的第一次合作，拿一些簡單的功能來做不容易產生分歧。

這次產品升級是有兩個目的，一個就是讓產品快速打上屬于你的烙印，只要做這么一次簡單的小升級，你就真的在心理層面認同這個產品跟你的關系了，就跟游戲里面的寶藏兵器滴血認主一樣，這是一個很有儀式感的操作。

另一個其實就是為了快速融入團隊了，在公司大的產品生產制度之下，每一個產品團隊都有自己的工作習慣和配合方法，都有屬于自己小默契，這個默契是沒辦法通過產品交接來傳遞的，最好的辦法就是大家整刀真槍合作一次，拉幾次評審會，討論幾輪問題，大家基本上也就相互了解對方和做事風格了，這就是團隊磨合。用一次小的產品升級完成團隊磨合，后面打硬仗的時候大家配合起來自然就會順利很多了。

七、結語

以上就是接受一個新產品的時候核心要做的幾個事情了，這個過程基本包含了從認識一個產品到了解到熟知，最后再一步一步把這個產品真正變成自己的產品。企業人員變動產品交接真的是一件非常常見的事情，所以掌握這一整套快速接手新產品的技能應該是每個產品經理的必修課，說不定哪天你就被委以重任安排到哪個新產品上工作了。

當然我這里所能整理出來的基本是一些比較主線的任務，還有一些細節上的點這里并沒有展開描述，比如之前跟朋友聊這塊內容的時候他提到一個很重要的點是學習新領域的各種專業名詞，他的習慣是先去把這些可能會造成阻礙的東西先擺平，然后再去推進事情前進，而我的習慣則是先推進事情，過程中遇到什么事情再見招拆招解決事情，這兩種方法都可以，具體使用就看個人習慣了，你只要選擇你自己喜歡的方式就可以了。

最后，我這里所寫的東西都是我在日常工作中沉淀和積累的內容，并不一定可以完美適配所有人的工作場景，大家如果覺得有不合理的地方，或者有需要補充的地方可以在評論區給我留言，我們可以共同探討，一起進步。

作者：多云轉晴，公眾號：互聯網從業筆記

本文由 @多云轉晴 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。