如果一個產(chǎn)品經(jīng)理只關(guān)注創(chuàng)造需求而忽視需求實現(xiàn)的過程，那么這個產(chǎn)品也很難說會成功，因為執(zhí)行落地才是最重要的。

上篇文章《互聯(lián)網(wǎng)產(chǎn)品運營體系總結(jié)之產(chǎn)品設(shè)計》簡單從四個方面進行了總結(jié)：

1. 確定產(chǎn)品定位——發(fā)展方向
2. 確定商業(yè)模式——經(jīng)營策略
3. 確定產(chǎn)品架構(gòu)——產(chǎn)品形態(tài)
4. 確定產(chǎn)品賣點——運營重點

很多人說這個流程更適合初創(chuàng)產(chǎn)品，對于發(fā)展中特別是成熟期的產(chǎn)品，是不是就不需要考慮這么多了，其實我感覺不管是初創(chuàng)期的產(chǎn)品，還是迭代過程的產(chǎn)品，都可以用該流程去思考，這也是產(chǎn)品經(jīng)理培養(yǎng)高階思維的一種訓練過程。當然對于每一部分，需要掌握的知識和技能也是非常多的，后續(xù)有機會我們會逐一總結(jié)。

好的產(chǎn)品策劃設(shè)計是成功的一半，但當我們滿懷希望憧憬產(chǎn)品上線的樣子的時候，卻經(jīng)常發(fā)現(xiàn)，產(chǎn)品無法按期上線，開發(fā)出的功能和期望很大，過程中產(chǎn)品和技術(shù)打架，產(chǎn)品和運營相互吐槽，終究原因就是產(chǎn)品開發(fā)管理過程是混亂的，所以產(chǎn)品管理也是我們產(chǎn)品運營體系的一個重要環(huán)節(jié)，一個好的產(chǎn)品經(jīng)理，不僅要具備創(chuàng)造性的思維和業(yè)務能力，也要具備工程思維和管理能力，所以產(chǎn)品管理體系我們從產(chǎn)品經(jīng)理的主要職責作為梳理。

產(chǎn)品經(jīng)理（負責人）要管理全周期

我們經(jīng)?；煜a(chǎn)品管理和項目管理的概念，簡單的說，產(chǎn)品管理重需求（管理），強調(diào)產(chǎn)品實現(xiàn)的持續(xù)過程；項目管理重任務（管理），強調(diào)任務完成的整體協(xié)調(diào)。從管理周期上來看的話，產(chǎn)品管理過程中包含了項目管理，而且一個產(chǎn)品管理過程可能包含了多個項目管理。我們通過下圖來了解產(chǎn)品管理的主要過程：

一個產(chǎn)品功能的開發(fā)要從需求探查開始找業(yè)務機會，產(chǎn)品經(jīng)理要負責召開需求評審，確定產(chǎn)品可行性。一旦產(chǎn)品確定開發(fā)，產(chǎn)品和技術(shù)將并行進行方案的設(shè)計，特別對于技術(shù)要求比較高的產(chǎn)品，技術(shù)的可行性調(diào)研和架構(gòu)就要開始，同時產(chǎn)品團隊將需求和業(yè)務場景結(jié)合，設(shè)計最終的產(chǎn)品形態(tài)。這幾個過程就是我們在第一篇文章中所涉及的部分。接下來進入開發(fā)測試過程，在這個過程中很多產(chǎn)品經(jīng)理會犯的一個錯誤就是認為這個管理過程屬于技術(shù)團隊，就和自己沒關(guān)系了。這種想法是不對的，產(chǎn)品經(jīng)理要對產(chǎn)品最終的結(jié)果負責，為了保證自己想要的結(jié)果，需要和技術(shù)團隊進行密切的協(xié)作，監(jiān)控整個開發(fā)過程，協(xié)調(diào)相關(guān)資源，共同保證產(chǎn)品交付。

一個項目目標的實現(xiàn)就代表項目過程的結(jié)束，而產(chǎn)品管理過程卻是一個不斷迭代的過程，因為一旦一個版本的產(chǎn)品投入市場，也就意味著通過市場和運營的反饋將產(chǎn)生新的需求和調(diào)整，一個新的過程又開始了。

所以，產(chǎn)品經(jīng)理不僅僅和技術(shù)團隊協(xié)作生產(chǎn)，同時要和市場、運營甚至是用戶等各種角色的人進行協(xié)作，來保證產(chǎn)品持續(xù)的生命力。我們常說，產(chǎn)品經(jīng)理是沒有權(quán)利的小CEO，這話一點沒錯，他需要非常全面的能力和協(xié)作，正如下圖一樣：

產(chǎn)品經(jīng)理要做好版本規(guī)劃

初級的產(chǎn)品經(jīng)理經(jīng)常犯的一個錯誤是太關(guān)注自己的創(chuàng)意和需求，而不關(guān)注需求實現(xiàn)的過程。我在工作中也經(jīng)常碰到產(chǎn)品和技術(shù)互掐，技術(shù)說按照領(lǐng)導期望的時間完成不了，希望產(chǎn)品減需求、分階段。而產(chǎn)品經(jīng)理就不想減需求，他希望自己的創(chuàng)意能全部實現(xiàn)出來。其實這就是我們?yōu)槭裁匆霎a(chǎn)品版本規(guī)劃的原因：資源和時間的沖突。資源總是不夠的，時間也總是不夠的，為了保證產(chǎn)品持續(xù)的成果，我們必須要控制自己的欲望，合理的安排產(chǎn)品需求實現(xiàn)路徑。

既然要做產(chǎn)品版本的規(guī)劃，那么我們應該去規(guī)劃版本呢？

1.0版本很重要，這是產(chǎn)品的起點

新產(chǎn)品上來第一個版本從開發(fā)到上線時間相對較長。按照我們前一篇文章介紹的，此版本的功能一定要緊扣定位，重點要解決用戶痛點，不要貪多，貪多反而淡化了定位和產(chǎn)品亮點。比如微信最開始就是定位的移動IM，解決人與人連接的問題，所以微信第一版上線就非常的簡單，就是基于手機移動端的即時通訊，甚至這個版本連發(fā)語音功能都沒有。

大版本的規(guī)劃考慮戰(zhàn)略需求

首先看看微信的大版本的核心功能：

• 微信1.0：移動IM，圖片分享，微信誕生；
• 微信2.0：語音消息，視頻消息，微信成功的基礎(chǔ)；
• 微信3.0：搖一搖，陌生人社交；騰訊新聞等外部插件，平臺化初試；
• 微信4.0：萬能的朋友圈來了；公眾平臺上線；平臺化戰(zhàn)略正式開始；
• 微信5.0：微信支付來了，內(nèi)容能搜索了，深入到人們?nèi)粘Ｉ?，商業(yè)化開始；
• 微信6.0：微信生態(tài)，鏈接一切。

大版本規(guī)劃基本上都是基于每一步的戰(zhàn)略需要來設(shè)計的，其實對應的是公司的整體戰(zhàn)略規(guī)劃，基本上以年為單位。產(chǎn)品經(jīng)理要深刻領(lǐng)會高層的戰(zhàn)略需求，并進行具體的產(chǎn)品功能的策劃設(shè)計，保證戰(zhàn)略的實現(xiàn)。

小版本的規(guī)劃考慮運營需求

大版本的周期很長，方向相對穩(wěn)定，即使戰(zhàn)略調(diào)整也并不是一早一夕就能完成，相對比較容易控制。大版本上線以后，接下來就是產(chǎn)品的小版本迭代了，如何來做產(chǎn)品的迭代呢？可以從以下角度考慮：

1. 確定你的產(chǎn)品架構(gòu)；
2. 拆分架構(gòu)實現(xiàn)的步驟；
3. 根據(jù)步驟，確定需要的支持功能；
4. 根據(jù)功能關(guān)聯(lián)耦合情況，拆分成需求story；
5. 根據(jù)數(shù)據(jù)表現(xiàn)、人力、運營計劃、市場資源配合情況，確定版本story。

所以，小版本的規(guī)劃既要契合大版本的戰(zhàn)略需要，而且又要和公司其他業(yè)務部門緊密的配合，通過市場、運營甚至客戶的推動，共同制定迭代的版本計劃。在版本的迭代計劃中，新功能的產(chǎn)生和比較重大的變更，一般采用0.x版本進行管理，周期根據(jù)各自自己情況，控制在一個月到一個季度。bug的修復和小功能更新，可以采用0.1.x版本進行管理，周期一般在一周到一個月。在這種快速的迭代過程中，更需要敏捷的產(chǎn)品開發(fā)過程：

產(chǎn)品經(jīng)理要管理好需求變更

上圖雖然很夸張，但是不得不說，產(chǎn)品和技術(shù)的戰(zhàn)爭很多時候都來自于需求的變更。雖然我們每次都做了版本規(guī)劃，但是很多時候計劃跟不上變化，所以需求的變更是不得不面對的，為了保證產(chǎn)品過程的有序，需要建立需求變更機制。

首先我們需要清晰的認識需求變化對項目的過程所產(chǎn)生的影響。如上圖所示的項目管理的鐵三角，直觀的反映了項目中各個變量元素的關(guān)系。所以，我們需要統(tǒng)一一下認識：

加/改需求，或者要延長項目時間；或者替換掉相等工作量的需求；如果又不想延長時間，也不想替換掉原有需求，只能找boss協(xié)調(diào)資源，增加成本，否則只能犧牲質(zhì)量了。

除了思想意識的統(tǒng)一之外，做好需求變更管理我們還應該：

建立需求池機制

產(chǎn)品經(jīng)理日常最需要關(guān)注的三個東西：當前版本、下個版本和需求池。需求池就是對于現(xiàn)在開發(fā)的版本的可量化的描述，就像水池一樣，水多了就溢了，水少了資源就沒充分利用，對于需求也是。既然可量化，產(chǎn)品經(jīng)理應該對每個需求需要的開發(fā)人天和總周期人天要足夠明確，對于需求的優(yōu)先級和重要級別有個排序。這是我們合理變更需求的基礎(chǔ)！

建立需求的評審機制

對于需求變更一定不要著急動手，因為需求變更后影響到后續(xù)的所有環(huán)節(jié)，存在著很大的風險，這個風險既不是產(chǎn)品團隊承擔，也不應該讓技術(shù)團隊承擔，而應該是和產(chǎn)品相關(guān)的整個團隊共同承擔，甚至包含老板和客戶。所以需求的變更需要進行評審，評審的目的不僅僅是讓相關(guān)人都簽字確認，更多的還是讓大家再仔細的思考、討論，變更需求所帶來的風險，是不是要變更需求！所以需求的評審盡量各相關(guān)崗位的決策人都要參加。

統(tǒng)一需求的入口

當一個項目，失去統(tǒng)一的需求入口，當一個產(chǎn)品經(jīng)理失去對入口的控制，意味著項目的失控。任何一個需求都不是孤立存在的，只有當需求入口統(tǒng)一，才能夠整體的判斷需求的價值，明確當前的資源使用狀況，合理的安排需求的實現(xiàn)關(guān)系。過去我一直在糾正運營人員直接向技術(shù)提需求的問題，運營人員的需求（除非bug）必須要經(jīng)過產(chǎn)品經(jīng)理，由產(chǎn)品經(jīng)理統(tǒng)一提交給技術(shù)。

可持續(xù)跟蹤的管理工具

需求的變更不是口頭上交代就完事的，一定要記錄備案，甚至簽字畫押，正所謂口說無憑，立字為據(jù)。這也是避免后續(xù)出現(xiàn)問題，出現(xiàn)各方扯皮，踢皮球。

最后說一句，一旦當前版本需求確定，盡量不要變更，少變更，而且變更一定要盡早。產(chǎn)品的開發(fā)節(jié)奏對一個產(chǎn)品經(jīng)理是非常重要的，不要去破壞這種節(jié)奏！

產(chǎn)品經(jīng)理要持續(xù)主動的進行產(chǎn)品優(yōu)化

和項目經(jīng)理不同，項目一旦結(jié)束，項目經(jīng)理的職責也就完結(jié)，而產(chǎn)品是一個持續(xù)迭代發(fā)展的過程，產(chǎn)品的上線并不是工作的結(jié)束，而是新一輪工作的開始。產(chǎn)品經(jīng)理如何做好產(chǎn)品優(yōu)化，可以參考以下幾點：

1. 關(guān)注運營數(shù)據(jù)，多做灰度測試、AB測試，用數(shù)據(jù)說話；
2. 及時收集市場、運營等相關(guān)業(yè)務部門的反饋和需求；
3. 保持和用戶的互動，獲取終端使用者的反饋，提升產(chǎn)品體驗；
4. 緊跟趨勢，不挑戰(zhàn)用戶習慣的基礎(chǔ)上，開拓創(chuàng)新。

如果一個產(chǎn)品經(jīng)理只關(guān)注創(chuàng)造需求而忽視需求實現(xiàn)的過程，那么這個產(chǎn)品也很難說會成功，因為執(zhí)行落地才是最重要的，所以產(chǎn)品經(jīng)理要具備產(chǎn)品管理的能力，以上總結(jié)的產(chǎn)品管理體系希望能幫到大家。

相關(guān)閱讀

互聯(lián)網(wǎng)產(chǎn)品運營體系總結(jié)之產(chǎn)品設(shè)計

作者：亂譚君，掌上醫(yī)訊產(chǎn)品經(jīng)理，微信公眾號：菜根亂譚I（ID：CGLT_TAN）

本文由 @亂譚君 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議