互聯網產品運營體系總結之產品管理

上篇文章《 》簡單從四個方面進行了總結:

1、確定產品定位--發展方向

2、確定商業模式--經營策略

3、確定產品架構--產品形態

4、確定產品賣點--運營重點

很多人說這個流程更適合初創產品,對於發展中特別是成熟期的產品,是不是就不需要考慮這麼多了,其實我感覺不管是初創期的產品,還是迭代過程的產品,都可以用該流程去思考,這也是產品經理培養高階思維的一種訓練過程。當然對於每一部分,需要掌握的知識和技能也是非常多的,後續有機會我們會逐一總結。

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

互聯網產品運營體系總結之產品管理

  • <strong>產品經理(負責人)要管理全週期

我們經常混淆產品管理和項目管理的概念,簡單的說,產品管理重需求(管理),強調產品實現的持續過程;項目管理重任務(管理),強調任務完成的整體協調。從管理週期上來看的話,產品管理過程中包含了項目管理,而且一個產品管理過程可能包含了多個項目管理。我們通過下圖來了解產品管理的主要過程:

互聯網產品運營體系總結之產品管理

一個產品功能的開發要從需求探查開始找業務機會,產品經理要負責召開需求評審,確定產品可行性。一旦產品確定開發,產品和技術將並行進行方案的設計,特別對於技術要求比較高的產品,技術的可行性調研和架構就要開始,同時產品團隊將需求和業務場景結合,設計最終的產品形態。這幾個過程就是我們在第一篇文章中所涉及的部分。接下來進入開發測試過程,在這個過程中很多產品經理會犯的一個錯誤就是認為這個管理過程屬於技術團隊,就和自己沒關係了。這種想法是不對的,產品經理要對產品最終的結果負責,為了保證自己想要的結果,需要和技術團隊進行密切的協作,監控整個開發過程,協調相關資源,共同保證產品交付。一個項目目標的實現就代表項目過程的結束,而產品管理過程卻是一個不斷迭代的過程,因為一旦一個版本的產品投入市場,也就意味著通過市場和運營的反饋將產生新的需求和調整,一個新的過程又開始了。所以產品經理不僅僅和技術團隊協作生產,同時要和市場、運營甚至是用戶等各種角色的人進行協作,來保證產品持續的生命力。我們常說,產品經理是沒有權利的小CEO,這話一點沒錯,他需要非常全面的能力和協作,正如下圖一樣:

互聯網產品運營體系總結之產品管理

  • <strong>產品經理要做好版本規劃

初級的產品經理經常犯的一個錯誤是太關注自己的創意和需求,而不關注需求實現的過程。我在工作中也經常碰到產品和技術互掐,技術說按照領導期望的時間完成不了,希望產品減需求、分階段。而產品經理就不想減需求,他希望自己的創意能全部實現出來。其實這就是我們為什麼要做產品版本規劃的原因:資源和時間的衝突。資源總是不夠的,時間也總是不夠的,為了保證產品持續的成果,我們必須要控制自己的慾望,合理的安排產品需求實現路徑。

既然要做產品版本的規劃,那麼我們應該去規劃版本呢?

<strong>1.0版本很重要,這是產品的起點

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

<strong>大版本的規劃考慮戰略需求

微信1.0:移動IM,圖片分享,微信誕生

微信2.0:語音消息,視頻消息,微信成功的基礎

微信3.0:搖一搖,陌生人社交;騰訊新聞等外部插件,平臺化初試

微信4.0:萬能的朋友圈來了;公眾平臺上線;平臺化戰略正式開始

微信5.0:微信支付來了,內容能搜索了,深入到人們日常生活,商業化開始

大版本規劃基本上都是基於每一步的戰略需要來設計的,其實對應的是公司的整體戰略規劃,基本上以年為單位。產品經理要深刻領會高層的戰略需求,並進行具體的產品功能的策劃設計,保證戰略的實現。

<strong>小版本的規劃考慮運營需求

大版本的週期很長,方向相對穩定,即使戰略調整也並不是一早一夕就能完成,相對比較容易控制。大版本上線以後,接下來就是產品的小版本迭代了,如何來做產品的迭代呢?可以從以下角度考慮:

1、確定你的產品架構

2、拆分架構實現的步驟

3、根據步驟,確定需要的支持功能

4、根據功能關聯耦合情況,拆分成需求story

5、根據數據表現、人力、運營計劃、市場資源配合情況,確定版本story

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

  • <strong>產品經理要管理好需求變更

互聯網產品運營體系總結之產品管理

上圖雖然很誇張,但是不得不說,產品和技術的戰爭很多時候都來自於需求的變更。雖然我們每次都做了版本規劃,但是很多時候計劃跟不上變化,所以需求的變更是不得不面對的,為了保證產品過程的有序,需要建立需求變更機制。

互聯網產品運營體系總結之產品管理

首先我們需要清晰的認識需求變化對項目的過程所產生的影響。如上圖所示的項目管理的鐵三角,直觀的反映了項目中各個變量元素的關係。所以,我們需要統一一下認識:

加/改需求,或者要延長項目時間;或者替換掉相等工作量的需求;如果又不想延長時間,也不想替換掉原有需求,只能找boss協調資源,增加成本,否則只能犧牲質量了。

除了思想意識的統一之外,做好需求變更管理我們還應該:

<strong>建立需求池機制

產品經理日常最需要關注的三個東西:當前版本、下個版本和需求池。需求池就是對於現在開發的版本的可量化的描述,就像水池一樣,水多了就溢了,水少了資源就沒充分利用,對於需求也是。既然可量化,產品經理應該對每個需求需要的開發人天和總週期人天要足夠明確,對於需求的優先級和重要級別有個排序。這是我們合理變更需求的基礎!

<strong>建立需求的評審機制

對於需求變更一定不要著急動手,因為需求變更後影響到後續的所有環節,存在著很大的風險,這個風險既不是產品團隊承擔,也不應該讓技術團隊承擔,而應該是和產品相關的整個團隊共同承擔,甚至包含老闆和客戶。所以需求的變更需要進行評審,評審的目的不僅僅是讓相關人都簽字確認,更多的還是讓大家再仔細的思考、討論,變更需求所帶來的風險,是不是要變更需求!所以需求的評審儘量各相關崗位的決策人都要參加。

<strong>統一需求的入口

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

<strong>可持續跟蹤的管理工具

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

最後說一句,一旦當前版本需求確定,儘量不要變更,少變更,而且變更一定要儘早。產品的開發節奏對一個產品經理是非常重要的,不要去破壞這種節奏!

  • <strong>產品經理要持續主動的進行產品優化

和項目經理不同,項目一旦結束,項目經理的職責也就完結,而產品是一個持續迭代發展的過程,產品的上線並不是工作的結束,而是新一輪工作的開始。產品經理如何做好產品優化,可以參考以下幾點:

1、關注運營數據,多做灰度測試、AB測試,用數據說話

2、及時收集市場、運營等相關業務部門的反饋和需求

3、保持和用戶的互動,獲取終端使用者的反饋,提升產品體驗

4、緊跟趨勢,不挑戰用戶習慣的基礎上,開拓創新

如果一個產品經理只關注創造需求而忽視需求實現的過程,那麼這個產品也很難說會成功,因為執行落地才是最重要的,所以產品經理要具備產品管理的能力,以上總結的產品管理體系希望能幫到大家。


分享到:


相關文章: