產品經理如何評估項目上線後效果

① 產品經理如何評估需求價值

如果我最初問消費者他們想要什麼，他們會告訴我『要一匹更快的馬!』——亨利福特
每一個產品狗都應該很熟悉這句話，正如碼農喜歡將』對象』、』實例化』，』高內聚、低耦合』等掛在嘴邊一般，但熟悉的並不一定真正了解，而要在實踐中做到，知和行並不是天然一致的。
用戶需求是產品經理工作的基本出發點，不管是前期的行業調研、競品分析，還是產品研發過程的溝通傳達，還是產品上線後持續的迭代改進，頭腦里都需要圍繞用戶需求展開。
產品經理要挖掘出真實的用戶需求，是需要花些功夫的。用戶需求，字面上看，由用戶和需求兩個片語成。分解來看，
首先，你的產品不是氧氣，不是黃金，不可能所有人都需要，因此要確定具體的目標用戶，越精準越好，通過用戶研究來確定核心用戶。然後去了解這些用戶在現實生活中，或是在使用別的產品過程存在哪些問題，這些問題是用戶們需要被滿足，但尚未被滿足的，即所謂的痛點。
挖掘核心用戶的痛點，可以通過數據分析、用戶訪談、可用性測試、問卷調查等方式，另外，在研究競品的過程中，產品經理盡量讓自己變成小白，初步去感受競品的不足，並思考潛在的機會。
通過以上兩步，就能給出用戶畫像了。簡單的理解，用戶畫像就是真實用戶的虛擬化表達，但具備了真實用戶的典型特徵，以此為基礎，產品經理就要從用戶和需求的分析中加工出用戶需求了。

② 產品經理要怎麼做一個復盤總結

很多公司（包括我所在的公司），要求員工要按時提交：每日工作總結、每周工作總結、月度述職報告、季度述職報告、半年度述職報告、年度述職報告。所以，我們每個人，每天都在做著復盤。有些是我們意識到，但更多的是我們無法意識到的復盤。

一、 首先，什麼是復盤

一個項目，不管是0到1或者是版本迭代，基本都會包含以下幾個核心階段（見下圖）。產品復盤就是把每個階段中的具體工作進行分解，分析每一項工作的進展是否順利，問題點在哪、以及如何更好的優化。

二、 其次，為什麼要復盤

之前的文章中，我表述了一個觀點，「產品經理天然的路線就是走向管理」。而作為走向管理的第一步，就是要會總結得失。每一個項目從開始到結束，過程中或多或少都會出現計劃之外的突發狀況。而復盤就是是絕佳的反思的機會，產品上的得與失，通過一條一條的羅列，不斷深入思考，提升自己的總結能力。

產品經理核心的能力之一，就是總結能力，將收集到的需求建議、競品優勢等進行歸納整理，結合項目自身的差異點才能形成自己的需求思路。

三、 最後，怎麼做復盤

前文已經說過，復盤就是對具體工作進行分解，分析問題點和如何改進，以下就任務分解之後的復盤點，進行闡述。

1 項目目標復盤

1.1 項目進度復盤

• 1.1.1 是否按照原計劃交付時間交付？

• 1.1.2 原計劃的需求點實現了多少？哪些需求點沒有按計劃實現？每一個需求點延後原因分別是什麼？

• 1.1.3 哪些里程碑有延遲，延遲原因是什麼？

1.2 項目結果復盤

• 1.2.1 項目中出現了哪些意外？為什麼會出現這些意外？

• 1.2.2 用戶對新增功能點的接受程度和項目規劃中的是否一致？

2 需求階段復盤

2.1 需求定義復盤：

• 2.1.1 是否提供完整的需求輸出，包括：原型、MRD、PRD、UML等

• 2.1.2 設計師、交互師、開發人員分別對需求是否明確：如果出現需求不明確的情況，將會嚴重影響項目的進度和質量。

• 2.1.3 是否對典型用戶和使用場景有清晰的描述？

2.2 需求變更復盤

• 2.2.1 需求變更次數：敏捷開發已經將需求變更的影響降到最低，但是較少的需求變更仍然是項目進展順利的前提之一。

• 2.2.2 哪些需求變更影響了項目實際進度

• 2.2.3 每次變更的原因：領導干預？前期考慮欠缺？需求無法實現？分析每一次的變更原因，可以在後期項目中進行合理的避免。

• 2.2.4 每個項目成員是否都清晰的知道每一次的變更：只有每位項目成員清楚的了解每次需求變更，並做好充分的溝通，才能保證項目的進度和質量。

• 2.2.5 項目成員是否能接收需求變更：這就要求每次需求變更，都要和相關人員做好溝通。

3 設計階段復盤

• 3.1 是否確定視覺設計的最終審核人？

• 3.2 UI設計產出是否符合統一標准？

• 3.3 設計工作是否影響開發工作的進度？影響原因是什麼？

• 3.4 產品設計工作在什麼時候，由誰來完成的？

4 開發階段復盤

4.1 工期評估復盤

• 4.1.1 開發實施前，是否有充分的時間做工期預估：工期評估一方面是讓項目成員能夠對項目的整體進度有所准備，也是對項目需求進行詳細梳理的過程。

• 4.1.2 工期預估與實際開發時間是否有差異，及差異原因分析

4.2 開發文檔復盤

• 4.2.1 是否有提供開發文檔？

• 4.2.2 開發文檔是否符合規范

4.3 突發狀況復盤

• 4.3.1 是否出現需求無法實現的狀況？原因是什麼？

• 4.3.2 是否出現團隊成員變動情況？如何應對成員變動？後期如何避免？

• 4.3.3 是否出現功能模塊與需求不符的情況？出現原因是什麼？

4.4 Code Review復盤

• 4.4.1 是如何進行的：包括如何分工，如何復查等。

• 4.4.2 Code Review結果是什麼？

• 4.4.3 是否嚴格執行了代碼規范？對不規范的代碼如何處理？

5 測試階段復盤

5.1 測試計劃復盤

• 5.1.1 是否有完整、准確的測試用例？

• 5.1.2 是否有一個測試計劃？這樣的計劃是否有效？

• 5.1.3 團隊是如何測試並跟蹤產品開發效果的？

5.2 測試工具復盤

• 5.2.1 使用了哪些測試工具來幫助測試？是否可以持續使用？

• 5.2.2 測試的時間、人力和軟體/硬體資源是否足夠?

5.3 測試結果復盤

• 5.3.1 哪個功能模塊產生的Bug最多，為什麼？

• 5.3.2 哪些BUG出現回滾，原因是什麼？

6 上線階段復盤

6.1 驗收復盤

• 6.1.1 是否進行了正式的上線驗收？

• 6.1.2 在正式發布的過程中是否有出現狀況？後續如何避免？

• 6.1.3 上線前是否和運營、文案進行充分的溝通？

• 6.1.4 是否檢查了數據埋點，數據埋點是否滿足運營要求？

6.2 上線後效果復盤

• 6.2.1 在上線之後是否出現重大bug? 為什麼測試階段沒有發現？

• 6.2.2 產品上線後的問題反饋渠道是否流程？

• 6.2.3 產品上線後收集到哪些問題反饋？都是什麼類型？如何改進？

每次的項目復盤，都是對自己的一次拷問和錘煉，迭代型產品每逢3個版本進行一次復盤，一般情況下，發版的節奏是一個月一個版本，因此可以按照3個月的節奏進行復盤。

最後，每次的復盤結果都要形成文字記錄，這將是你成長路上的重要積累！

③ 產品經理如何判斷一個新功能是否應該添加

1. 最小化產品（不要一開始就把功能做得盡善盡美，而是先把必不可少的元素做上去，受用戶歡迎了再繼續迭代優化）

2. 靈活的入口（盡量不要把功能的入口給固定死了，否則該功能不受歡迎後撤下的話，顯得動靜比較大，就像剛裝上一隻手然後又被砍掉一樣，可以挑些可線上靈活配置的入口，比如說 banner 或運營位）

3. 灰度發布（可以選擇特定比例或特定類型的用戶展示新功能）

4. 功能開關（有些功能的入口考慮到用戶的操作場景，不得不將入口固定的時候，可以給它設置開關，如果不受歡迎的話把開關關掉，就可以恢復到之前的設計）

5. 數據校驗（發布前做好數據埋點，功能上線後將收集到的數據與自己的預期相比較，太糟糕的話分析原因是什麼，是功能不行還是設計不行，如果是功能不行則砍掉功能，如果是設計不行則優化設計，再次迭代上線）

④ 產品經理如何有效的進行項目管理

1.制定目標——明確目標

這個「目標」可以是項目測試通過封包的日期，也可以是上線發布日期，但一定要整個團隊達成一致，如果上線，可能需要負責市場的同事參與知曉。

2.制定計劃——明確計劃

根據第一點明確了目標，那麼項目成員可以開始制定計劃，也可以是產品經理制定計劃，一般包含幾個關鍵checkpoint：

需求文檔產出時間節點

交互文檔產出節點

視覺稿產出節點

依賴的外部介面提供節點

開發送測節點

功能測試完成節點

全回歸測試完成節點

這七個checkpoint可以根據時間情況有所增減，有人會問，明確這個計劃的作用是什麼呢？

3.評估風險

那麼在制定計劃後，項目每個成員根據計劃，來確定該做什麼、怎麼做、什麼時候完成。在多人跨團隊的項目里這一步尤其重要，可以說這一步走好了，後面項目進程會非常順暢。

咱們隨意的列舉一下曾經踩過的坑：A項目啟動時沒有交互文檔，而開發的ERD/測試的用例都依賴交互文檔；

依賴的介面（其他部門）直接說暫無排期，或者是3-4周後提供，那搞毛；

開發送測時間太晚導致測試時間不足。每個成員進行計劃評估後，項目可能亮起了黃燈，產品經理得做點什麼吧？

4.協調資源/修改計劃

根據項目緊急程度、上級重視程度，及時的協調各種資源，優化排期，修改計劃吧。

這時候可能會把123再來一遍，問題會越來越少，過程會越來越透明，進度會可視可控，是不是感覺嗨的不行。

溝通

與人打交道，第一靠情商，第二靠技巧，都不行，那就只能靠姿色了~好了，咱們言歸正傳。

1.溝通技巧

為何需要掌握溝通技巧？當團隊十幾人，幾十人的時候，可能你會碰到各種性格色彩的「同事」，所以得有備無患。

第一步：知己知彼，了解團隊里所有人的性格和工作習慣。

第二步：以其人之道還治其人之身，與性格張揚思維活躍的設計打交道、與寡言少語專注技術的程序員打交道、與一絲不苟非常嚴謹的測試打交道、與不太配合的其他部門同事打交道，用對方對容易接受的溝通方式以求迅速達成一致，good job！

2.溝通效率

何為效率，就是減少不必要的溝（fei）通（hua）。How？

能面對面，就別打電話；能打電話，就別QQ/RTX/LYNC。文字溝通難免會有理解不同，導致挖坑；面對面簡短的表述我的問題、我需要的支持、什麼時間，並及時得到反饋。

永遠別相信對方口頭承諾的，Never！線下電話or當面溝通完，一定出一封郵件，闡述清楚並得到對方確認，郵件在有些時候真的挺有用的。

會議之痛肯定有人懂，會議時間盡量選擇碎片化時間，比如9:30、13:30、5：00，這樣的話就不會總覺得「奧，我待會有個會」，時刻處於被會議影響的工作狀態。

會議中要避免問題大范圍的展開討論，可記下問題會後詳談；注意控制會議進展，當然偶爾閑聊，但是注意控制時長，盡量在計劃時間內搞定。

執行力

這里說的執行力，可以理解為提升團隊的執行力。

計劃再好，溝通再好，執行力不行，都是浮雲...至於方法，可以從以下幾個方面著手：

1.日常工作中能夠及時響應；

2.每件事都有一個節點，反饋進度；

3.高效的推動力，自己負責的事情能夠推動解決並跟進；

4.產出物的質量要高，包含各種文檔、送測質量、測試質量，這點很關鍵，以後單獨細細道來~

5.保持進步，項目不會只有一個，可能是一個接一個項目，產品經歷可以從0到1，進行有效的項目管理。

弘博創新產品經理精品課程

內容來源弘博創新管理咨詢

希望我們能為更多的人帶來有用的知識和信息

⑤ 如何做一個產品經理

了解產品。作為一名產品經理，對自己所管轄的產品有一定的了解是非常重要的，畢竟產品經理是貫穿整個產品製造以及銷售的人，所以，自己要先了解產品，才能更好的針對產品來做後面的工作。2/6指導產品生產。在整個生產環節，可以適當的指導產品生產，與技術人員取得密切的聯系與溝通，這樣才能在產品生產的過程中肩負起責任，畢竟像技術活之類的交給技術人員就可以了，但是產品經歷仍然可以針對其它方面提出建議額。3/6具有創新意識。一個產品想要在市場上取得一個好的銷售成果，想要獲得好的口碑，那麼在製造這個產品的時候就可以適當的融入一些創新意識，並且還要在之後的生產中不斷的創新，以便於更方便人們的生活。這也是做一個產品經理應該做的。4/6打造獨具特色的產品買點，作為產品經理，不僅要在產品製造的過程中嚴格的監制，更要在銷售的時候嚴格把關，要像產品的銷售好，那麼就必須把這個產品能拿出來的買點來進行更好的打造。5/6及時的調整策略，產品經理換句話說就相當於是一個舵手，在發現產品製造或者銷售過程中出現的問題的時候，要勇敢果斷一點，發現策略不多就要及時的調整。6/6和員工以及上級處理好關系。雖然說產品經理主要負責產品的製造生產和銷售，但是仍然需要和手裡面的員工以及上級處理好關系，這樣才能更好的得到一些消息，以及使整個部門更加的和諧團結。

⑥ 互聯網產品經理如何做產品的策劃和評估

據統計，高達80%的項目沒有經過市場調研和充分的市場評估便匆匆上馬，所以在這一部分產品中，失敗了不足為奇，成功的話，純粹是靠運氣。
下面提出幾點簡單的市場調研和互聯網產品項目的評估方法：
1 產品商業市場分析
分析潛在受眾對產品的依賴程度，以及該依賴程度能否達成產品的戰略目標;這一步非常關鍵。是決定一個產品是否上馬做的重要依據。這一步的實施，需要相關的調研手段配合。舉個例子，有個朋友想做一個B2C的電子商務網站「買菜網」，這個網站主要希望針對北京最大的居民社區回龍觀和天通苑地區的居民網上買菜。我建議他派出調查員，首先到該地區的5家大型超市門口對買菜者分時段做調查，調查只有2個很簡單的問題：
① 您是否願意在網上買菜，直接送到您家裡去? 是 否
② 接受一次買菜配送服務，您願意花的配送費為如果是5%，8%，10%請您填寫
5%時 A 沒問題; B 有些猶豫; 8%時 A 沒問題 B 有些猶豫;10%時 A沒問題 B 有些猶豫
通過這2項調查的基礎數據得出一些比例，然後綜合這2兩個地區居民的數量就可以完全計算出整個市場的容量，以及可能的贏利和支出情況;以及隨著業務量的增長，贏利和支出的增長比例，評估出網站未來是否能良性增長。只要采樣比例合理科學，這些數據是完全可以計算出來的。
產品經理自己需要知道，任何想法和產品是可以通過多種調研方法結合數學模型計算的，同時要用這個理念去影響公司領導和決策者。最終達到的效果就是公司上馬的項目盡管少，但成功率極高。
2 競爭分析
列出互聯網上相同產品和相近產品的列表，進行相關指標分析(主要是產品能達成目標的決定性指標)，在這個列表中，需要標明每個產品的特點和優勢(這個產品依然活著的理由)。坦率地講，互聯網發展到今天，你能夠想到的點子，大部分人家已經想到並實施了，或者是和你的想法比較相近。但只要做好市場佔有量及差異化分析，同樣存在成功的可能。
所以說，互聯網產品經理一定要具備相當高的市場調研能力，也必須具備良好的洞察力、分析力、策劃力;既要懂得市場和用戶，也需要懂得產品和內容，甚至還需要懂得公司的戰略和運營;正如Google中國的產品經理趙羽可所說的，「我希望和我們的產品經理一起推出用戶最喜歡的產品和服務，前提條件就是他必須深刻理解用戶，知道他們想要什麼，同時還要有一定的商業眼光」。
3 達成這個產品的戰略目標，是否還有其它的手段和方式。
再舉個例子，某IT網站設計開發了一個即時通訊產品，2個目標，第一希望達成該網站的經銷商戰略，也就是希望經銷商通過這個專門的IM工具能夠找到客戶，和客戶溝通，和媒體溝通。第二，滿足該公司內部及時通訊需要。盡管這個產品目前還在實施之中，還不能給出是否能成功或者最終失敗的結論。但我們分析這個產品，很容易發現要達成這2個戰略，其實有更為恰當、更加低成本的產品形式。桌面版的IM工具天下已定，除了目前主流的產品外，很少有成功的其它產品，所以做為產品經理應該反過來思考，從而選擇更加合適的產品形式來達成目標。比如，在經銷商頁面上開發基於web的溝通功能，就能夠避免桌面軟體安裝升級的巨大使用障礙。4 技術評估
技術因素在互聯網產品的成功與否中已經占據到了絕對重要的位置。產品經理必須懂得一些程序設計及軟體架構的方法，這樣才能判斷出，哪些功能用什麼技術實現能夠達到預期效果。粗略統計，在所有好的值得實施的想法中，又有大約80%的項目死於技術原因，這些因素包括：技術選型出現重大失誤，產品軟體架構不合適，技術實現沒有達到預先設計的效果等等。所以從這個角度而言，互聯網產品經理的人選最好是做技術出生的，比如，Google的互聯網產品經理多產品經理都是資深的工程師出。