對B端產(chǎn)品經(jīng)理來說，日常工作中的流程一般是什么呢？工作的時候又要注意哪些要點，避開哪些坑呢？筆者結(jié)合自己的實踐經(jīng)驗為大家分享以上問題的答案。

寫在前面

經(jīng)過了幾個月的產(chǎn)品實習，感慨萬千，十分想將自己的經(jīng)驗，或者說是經(jīng)歷分享給大家，一來想和廣大產(chǎn)品新人共同進步，二來也希望能夠從產(chǎn)品前輩處得到一些批評指正。

我進行的是面向B端的中臺產(chǎn)品實習生，所以需要在熟悉公司業(yè)務的基礎上，考慮產(chǎn)品實現(xiàn)的邏輯，產(chǎn)品的用戶也是公司內(nèi)部人員。所以我的經(jīng)驗分享也主要是從B端產(chǎn)品的角度來進行，當然我相信和C端產(chǎn)品也會有共通之處，比如在溝通、緊急事件處理等方面，是屬于在日后各類工作中可以進行復用的經(jīng)歷。

文章將按照產(chǎn)品經(jīng)理進行工作的大致流程進行敘述，架構(gòu)如下：

• 一、需求挖掘與分析
• 二、產(chǎn)品方案的思考與撰寫
• 三、產(chǎn)品方案評審
• 四、跟進開發(fā)進度直至驗收上線
• 五、用戶操作手冊撰寫
• 六、數(shù)據(jù)指標分析
• 七、復盤
• 八、其他Tips

一、需求挖掘與分析

關(guān)鍵詞：需求辨別

B端產(chǎn)品的需求大多數(shù)直接來自于業(yè)務方，少部分可能是產(chǎn)品經(jīng)理自主挖掘，尤其涉及到整體邏輯的重構(gòu)或是一個全新的項目開展，往往是產(chǎn)品提出的需求。C端產(chǎn)品的需求基本上都要產(chǎn)品經(jīng)理自主去挖掘，借助問卷調(diào)查、用戶評論、數(shù)據(jù)埋點分析、競品分析等方法。但無論是C端還是B端產(chǎn)品在遇到各類需求時，都需要具備需求辨別能力。良好的需求辨別能力能夠讓你迅速分辨出哪些是該做的需求，哪些是沒必要的需求；哪些需求優(yōu)先級更高，必須盡快實現(xiàn)，哪些需求可以暫放，后續(xù)慢慢實現(xiàn)等等。

在拿到一個需求時，至少要進行如下幾方面思考：

1. 需求的場景，為什么提出這樣的需求，解決什么問題？
2. 有多少用戶有這樣的需求，是否值得實現(xiàn)？
3. 實現(xiàn)后能帶來的什么樣的收益？比如用戶使用次數(shù)增多、人效提高等，并不僅僅指金錢收益。
4. 如何實現(xiàn)這一需求，如何既能滿足需求又能簡化實現(xiàn)方式與過程？
5. 這一需求是否對其他模塊造成影響，影響的評估？
6. 這一需求的優(yōu)先級，實現(xiàn)的緊迫性？

在整個需求分析過程中，我們都要多角度思考，既要站在用戶角度看問題，也要站在研發(fā)角度看問題，更要站在產(chǎn)品角度看問題。

要學會跳出來看問題，不能被用戶提出的需求受限，我們要考慮一個需求優(yōu)化的外延性和其他可能性，要比用戶考慮的更前一步，不能只看眼前優(yōu)化的點，要考慮前后變動，不同業(yè)務、產(chǎn)品之間的關(guān)聯(lián)，無論是系統(tǒng)和APP都要具有一定的靈活性與柔性，才能更好的支撐后續(xù)的優(yōu)化與改進。

產(chǎn)品經(jīng)理要摒棄一些想當然的想法，比如不能用戶希望實現(xiàn)的功能就一定實現(xiàn)，必須考慮必要性（合理性）、可行性、收益；比如不能開發(fā)說不能實現(xiàn)就不去嘗試，尤其對于不太懂技術(shù)的產(chǎn)品來說，千萬不要抱有這樣的想法，無論是否真的能實現(xiàn)，我們都要提出自己的看法，進行質(zhì)疑與溝通，不要害怕說錯話被嘲笑，永遠不說不表達，永遠也不會有成長。

另外我們還需要將所有的需求進行梳理，借助表格的形式，生成需求池，對需求進行分類、描述優(yōu)化內(nèi)容、優(yōu)先級判斷、目前的實現(xiàn)狀態(tài)記錄等等。

借助需求池，我們能大致知道一個產(chǎn)品在迭代過程中優(yōu)化了哪些需求，還有哪些需求沒有實現(xiàn)，哪些需要我們盡快實現(xiàn)。

關(guān)于優(yōu)先級的確認：

B端的需求優(yōu)先級不單單是由產(chǎn)品經(jīng)理來決定的，而是要根據(jù)當前的項目飽和狀態(tài)、具體使用時間等和業(yè)務方共同確認。

一般來說會影響當前使用、線上bug、時間緊急的需求必然優(yōu)先級會高一些，而單純的沒有影響使用并且只涉及到少部分人的需求，優(yōu)先級可能會低一些，但是還是要根據(jù)具體情況靈活判斷。

如果有些需求臨近使用，優(yōu)先級是可以自動提升的，這個也是需要相關(guān)的產(chǎn)品經(jīng)理自己注意這些時間節(jié)點，不能等到用戶提醒才想起這些需求，然后導致緊急開發(fā)上線或是只能再次擱置。

我們也可以借助時間管理中的四象限法則：重要且緊急、重要不緊急、緊急不重要、不緊急不重要，來對需求進行大致的分類，并確定優(yōu)先級。

關(guān)于競品分析：

做競品分析是屬于需求挖掘的一種，通過與競品的對比，優(yōu)勢繼續(xù)發(fā)揚，短板進行補足，互相競爭才有長足發(fā)展。

相較而言，C端產(chǎn)品進行競品分析會容易許多，因為可以直接獲取到要分析的競品產(chǎn)品，而B端產(chǎn)品往往很難接觸到競品公司的內(nèi)部業(yè)務，所以較難分析。

但是有一點就是B端用戶的用戶其實也是C端，所以也可以借助相關(guān)C端產(chǎn)品的分析，但是關(guān)注的點可能會比較不一樣，比如C端競品會考慮功能結(jié)構(gòu)、用戶體驗等等，但是B端產(chǎn)品在進行競品分析時，要透過現(xiàn)象看本質(zhì)，在體驗相關(guān)的C端產(chǎn)品時要更多的去考慮這個產(chǎn)品背后公司的業(yè)務構(gòu)成與邏輯。

二、產(chǎn)品方案的思考與撰寫

關(guān)鍵詞：全面、準確、無歧義、可讀、不要拖延

在對當前需要做的需求有了大致的想法后，就可以開始撰寫文檔了，記住千萬不要等全部都想好了才開始寫，而是有思路就要動筆，后面再逐步的完善細節(jié)。

在deadline橫行的時代，越來越多人選擇在最后一刻完成任務，其實這樣并不是最好的方式，并且很多情況下提交的東西也不會是我們自己特別滿意的東西。

所以其實最好的做法是，從最開始就記錄自己的想法，先將文檔整體的框架搭出來，對于一些不能夠確認的細節(jié)，或是暫時未發(fā)現(xiàn)的問題，再一步步的去解決優(yōu)化，可以借助腦圖的形式將考慮到的各種場景記錄下來，然后逐步判斷方案是否能夠滿足這些場景的需求。

不要妄想一口氣吃個胖子，也不要妄想一次完美的解決掉所有的問題，扔掉完美主義與拖延，完成比完美更重要。

一份文檔大致包含的內(nèi)容有相關(guān)的項目背景、存在的問題、項目的目標、相關(guān)的部門、產(chǎn)品方案的概述、具體的優(yōu)化需求描述等等，可能根據(jù)不同項目的特點與階段會結(jié)合進競品分析、項目風險、埋點需求等等，有時關(guān)于競品和數(shù)據(jù)分析的部分也會單獨抽離出來。

文檔書寫的一些Tips：

1. 文檔描述要全面，寫清楚哪些沒有變動，變動部分的如何變動
2. 文檔描述要準確無歧義
3. 靈活借助目錄、圖示、表格、文檔修訂記錄等來使文檔可讀性更高
4. 根據(jù)方案長短靈活添加產(chǎn)品方案概述，總結(jié)方案中優(yōu)化的點
5. 存在的問題與項目目標基本是相對的，分點進行闡述，對于每個點進行簡單總結(jié)，再具體描述，盡可能使用數(shù)據(jù)指標來衡量
6. 涉及較多界面與交互的方案，除了產(chǎn)品經(jīng)理自己制作原型外，最好也與專門的交互和UI設計師合作
7. 做原型時要盡可能保持風格一致，但不意味著交互必須完全相同，因為可能有些之前存在的交互方式就不是最優(yōu)的，要靈活判斷
8. 涉及邏輯、校驗較多的方案，一定要配上流程圖，會比文字更清晰易懂
9. 可以模仿公司其他產(chǎn)品前輩的文檔書寫模式，要多看，看得多了就知道原來這里這樣描述更好。接觸到的越好，成長的越快。這也是為什么大家都希望能夠進大廠實習，榜樣越強大，成長的越快。

三、產(chǎn)品方案評審

關(guān)鍵詞：?多次溝通反饋機制?

其實方案的撰寫與評審是交叉的關(guān)系，在不斷的溝通中，方案也會根據(jù)實現(xiàn)的難度、時間等原因進行調(diào)整，直至最終確定并進入開發(fā)。（方案評審-修改-評審-修改-評審-確定-開發(fā)）

撰寫一份嚴謹?shù)腜RD是產(chǎn)品經(jīng)理的必備技能，但是能夠清楚的向各方人員闡述自己的方案是更加重要的技能。

在進行方案評審時，一定要交代清楚這個方案涉及的項目背景、存在的問題，我們?yōu)槭裁匆鉀Q這樣的問題，解決了能帶來怎樣的收益，我們?nèi)绾谓鉀Q，涉及哪些模塊，進行了哪些改動，從什么改成什么等等。

在這一過程中，往往很容易出現(xiàn)各方人員對同一句話理解不一致的情況，這種時候最好的方式是能夠說出具體的場景，進行舉例。

我們要學會建立起一種多次溝通反饋機制，在每次方案評審后，要及時記錄會議紀要并同步給相關(guān)人員，包含需要修改的部分、存疑的部分等等，將確認修改的部分同步在文檔中，對于存疑的部分，在下次溝通時進行二次確認，因為有時一次評審可能研發(fā)老師還沒能徹底理解我們的方案，可能需要一點時間理解相關(guān)的業(yè)務場景，判斷代碼上實現(xiàn)的可行性。通過多次的溝通反饋，保證相關(guān)人員都能夠理解并確定下來最終方案。

四、跟進開發(fā)進度直至驗收上線

關(guān)鍵詞：提早介入、進度同步、仔細驗收、持續(xù)監(jiān)控、查明問題原因

在進行完方案評審并確定可以開發(fā)的情況下，首先需要前后端、測試人員給出具體排期、上線時間。根據(jù)排期時間，產(chǎn)品經(jīng)理要不斷地跟進和推動整個項目開發(fā)上線的進度。尤其對于比較大型、邏輯復雜的項目，更要提早介入開發(fā)與測試，定期詢問狀態(tài)，避免到最后驗收階段才爆發(fā)各種問題與風險。

有時產(chǎn)品經(jīng)理可能會遇到項目進度推動難或是bug修復進展慢的情況，對于這類情況，首先要辨別一下原因，是由于相關(guān)人員手中工作量過于飽和、其他更高優(yōu)先級項目搶占研發(fā)資源、項目實現(xiàn)起來比預期困難或是某方人員不夠重視該項目導致的等等。

根據(jù)不同的情況，靈活的處理與報備。如果發(fā)現(xiàn)以你的身份層級已經(jīng)推動得很艱難，一定要盡早借助leader的力量去推動，并且要及時同步相關(guān)人員目前的進度情況。

作為產(chǎn)品經(jīng)理要連接前后端、測試多方人員，必須協(xié)調(diào)和同步好時間，要確保各方均已知曉，不然就會出現(xiàn)信息不對稱，時間不統(tǒng)一的尷尬情況。

在正式上線前，產(chǎn)品經(jīng)理會進行驗收，驗收時切記不可馬虎大意，要針對文檔中相關(guān)優(yōu)化的點進行一一驗收，在測試環(huán)境無法完全驗收或是在線上不方便進行驗收的部分，正式上線后也要持續(xù)進行監(jiān)控。

也就是說上線并不意味著結(jié)束，因為有時到了真實環(huán)境，大量的數(shù)據(jù)運行起來，可能會爆發(fā)測試、驗收過程中沒有發(fā)現(xiàn)的問題。

這種時候首先要判斷這一問題的影響，是屬于方案漏洞還是研發(fā)處理上的bug，目前能夠采取什么應急方案先進行修補，并且要讓開發(fā)、測試人員及時進行bug的修復，或是緊急完善相關(guān)的方案，提高當前項目優(yōu)先級，協(xié)調(diào)開發(fā)、測試資源繼續(xù)支持，迅速迭代。

這種時候其實最重要的是不能慌亂。對于發(fā)現(xiàn)的問題，一定要查明原因并記錄下來，避免后續(xù)再出現(xiàn)同樣的問題。對于采取應急措施解決但實際沒能復現(xiàn)的bug，千萬不能忽視，一定要讓開發(fā)人員進行復盤，查明原因，避免留下隱患。

直到負責的項目穩(wěn)定運行一段時間后，這一版的優(yōu)化才算告一段落。而下一版優(yōu)化的需求梳理、方案撰寫等流程在這一版進入開發(fā)時，就已經(jīng)可以開始準備了。

五、用戶操作手冊撰寫

關(guān)鍵詞：用戶角度

在項目臨近上線前，產(chǎn)品經(jīng)理就可以開始撰寫用戶操作手冊了，撰寫的角度是從用戶操作使用的角度，一般借助PPT的形式。如果是面向公司內(nèi)部人員的產(chǎn)品，還要對相關(guān)用戶進行使用培訓。

六、數(shù)據(jù)指標分析

關(guān)鍵詞：核心數(shù)據(jù)指標確定、透過數(shù)據(jù)看本質(zhì)

一個項目完成的是否符合預期，是可以從數(shù)據(jù)層面來進行衡量的，也就是文檔中衡量項目目標的數(shù)據(jù)指標部分，數(shù)據(jù)指標提升得好，也是對產(chǎn)品經(jīng)理工作的肯定。

一方面我們可以在項目開始前，借助之前的數(shù)據(jù)，分析挖掘相關(guān)的需求，并以此衡量我們的項目目標，進行結(jié)果導向；另一方面在過程中也可以借助數(shù)據(jù)分析來查明一些問題的原因；在項目運行一段時間后，可以再次收集相關(guān)的數(shù)據(jù)進行分析，評判本次優(yōu)化的效果。

產(chǎn)品經(jīng)理要培養(yǎng)數(shù)據(jù)思維與數(shù)據(jù)感，確定核心數(shù)據(jù)指標，然后借助合理的工具與方法，進行數(shù)據(jù)采集與分析，并得出相關(guān)的結(jié)論，結(jié)論不應當僅僅是數(shù)據(jù)層面的占比，而是要透過數(shù)據(jù)看本質(zhì)，分析導致數(shù)據(jù)表象的真實原因。

七、復盤

關(guān)鍵詞：PDCA循環(huán)?

大大小小的項目都需要復盤，將做得好的部分整理成可以復用的經(jīng)驗，做得不好的部分分析原因，進行記錄，避免再犯。

其實犯錯誤、出問題不可怕，可怕的是一直犯同樣的錯誤、一直出同樣的問題。在這里有一種方法可以借鑒，叫做PDCA循環(huán)法：P是計劃，D是執(zhí)行，C是檢查，A是行動，在這里面最重要的是在每一輪循環(huán)中通過Check，采取一定的Action，好的進行“獎勵”，壞的進行“懲罰”，再復用進下次PDCA循環(huán)中。

八、其他Tips

1. 每句話都要說到位，謹言慎行，對自己所的每句話負責
2. 對于不同身份職位的人以什么口吻、從什么角度去溝通是值得不斷學習的事情
3. 建立多次溝通反饋機制，避免出現(xiàn)“知識的詛咒”
4. 所有變動和溝通及時記錄在文檔或是會議紀要中，不要用腦子，用文字
5. 提升自己的思維運轉(zhuǎn)，要保持質(zhì)疑與思考
6. 一定要熟悉你的業(yè)務、文檔，這樣出現(xiàn)問題時才能更快的定位
7. 學會目標拆分，最基本最核心的目標、其他有優(yōu)化余地的目標等等

寫在最后

其實上面闡述的流程是基于已有項目的優(yōu)化，因為實習生一般不太會直接負責一個新產(chǎn)品或是新項目的搭建。

如果一個項目是從0-1的話，要進行更多的工作，比如項目立項、更多層面的競品分析、產(chǎn)品框架與邊界確定、功能結(jié)構(gòu)圖等等。

作為產(chǎn)品新人，還有很多要學習的地方，也還有很大的成長空間。未來還有很多的“坑”需要我去踩，也希望我能分享出更多有價值的經(jīng)驗。

人人都是產(chǎn)品經(jīng)理，但不是人人都能夠理解產(chǎn)品經(jīng)理。曾經(jīng)有人對我說，產(chǎn)品經(jīng)理就是傳話的，但我想說如果沒有產(chǎn)品經(jīng)理在中間“傳話”，那么工作將無法順利進行。

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

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