上一篇我分享了一個初階產品經理所具備的“軟實力”，下面我為大家介紹下必備的“硬實力”是哪些？

之前有人比喻說，產品經理就是一個團隊的小CEO，需求怎么做，得由產品經理定。

其實這倒不是因為產品經理權利有多大，而是因為產品經理所代表的是業務的訴求，所以任何邏輯、功能點、權限的設計問題一定是要產品同學來（背）拍（鍋）板的。

研發同事們在開發過程中經常在群里艾特我：“是PM讓這么干的”“PM給個邏輯吧”“PM你們決定到底怎么做吧?！?/p>

每次遇到這種等著我拍板的情況，真讓我瑟瑟發抖……

俗話說的好，背不好鍋的PM不是一個優秀的PM，那作為一個優秀的初階PM，需要具備哪些的專業能力呢？要想回答這個問題，就得要知道，產品經理每天都在干些啥？

首先我們同步一個流程，產品同學要完成一個完整的功能迭代需要經過以下這些環節：

• 需求溝通 → 溝通能力
• PRD輸出&原型繪制 → 需求文檔撰寫能力、原型基本功
• 產品組內需求評審 → 溝通能力、抗壓能力
• 開發評審&排期 → 溝通能力、抗壓能力
• 測試用例評審 → 邏輯能力
• 開發&提測&測試 → 項目推動能力
• 驗收 → 細心
• 效果回歸 → 數據分析能力

這么總結下來，一目了然，一個小白產品所具備的核心硬實力大致分為四個模塊，即PRD撰寫能力、AXURE繪制能力、項目管理能力以及數據分析能力。

01 PRD撰寫的能力

PRD（Product Requirement Document）即產品需求文檔，要想了解，PRD到底是個什么東西，就要問問自己這幾個問題：

問：PRD給誰看？

答：PRD是產品提供給開發、測試同學看的

問：PRD用來干嘛

答：PRD是產品用來告訴開發這次需求是要實現什么功能、怎么實現、實現效果

問：PRD寫的時候有什么要求嗎？

答：沒有特殊的規定，本著“把話說清楚”的原則，把這次需求的背景、目前的現狀、以及實現的方案寫下來即可。

個人方法論分享

寫文檔的時候圍繞“誰要用”，“為什么要用”，“怎么實現”這三個維度去寫，這樣就確保這個需求的前因后果是清晰的了。

圍繞著系統去寫

在寫實現方案的時候，要通過在系統上觸發的場景去寫對應的交互過程或者后續的流程，必要的時候可以通過流程圖展示出來。B端的產品要注意需求中所涉及到的數據的流轉、存儲等；而C端的產品則要注意功能中涉及到的交互、跳轉邏輯等要描述清楚。

考慮界面、系統的關聯性

比如是一個很簡單的加字段的需求，也要考慮到這個字段是否支持刪、改、查等操作，包括他的輸入規則、取值邏輯以及對其他系統的影響，比如說，如果我是在訂單系統加了這個字段，那退費系統也需要展示嗎？等等等等

數據埋點需求

如果這個功能后需要進行效果評估的話，就需要在文檔里說明埋點的場景以及埋點的規則。

考慮各種邊界值以及異常情況

正向的流程我們每個人都能想得到，但是一旦流程中任何一個環節發生了問題，系統又該如何處理呢？

舉一個很簡單的例子，微信支付我們都使用過：用戶掃碼–手動輸入金額–輸入密碼–支付成功。

可是這其中幾乎每個節點都有可能終止操作：掃碼失敗、不展示二維碼怎么辦？金額輸入過大是否有限制？限制規則是什么？密碼校驗失敗后系統會怎么提示用戶呢？密碼輸入正常但是沒有調起微信的支付接口該怎么辦？接口響應延遲導致重復支付了怎么辦等等等等。

這些問題以及應對辦法，就是產品經理必須來做決策的，一個好的文檔一定是各種正向流程、逆向流程、每個邊界值都考慮周全，把開發安排的明明白白~

但是畢竟產品同學也沒有那么多時間去把每個正向、負向場景的用例梳理出來，如果之后在技術評審或者在開發的過程中被指出來的話，就用小本本記錄下來，之后再做類似的功能的時候不要再犯相同的錯誤就好啦。

再多說一句：寫完文檔之后自己要review一遍，把自己想象成一個門外漢，看下能不能讀懂，文檔的邏輯有沒有漏洞，這個方法親測很有效哦。

02 Axure繪制的能力

Axure是畫原型的一個工具，也有很多人用Sketch。原型就是指你所做的功能的一個設計demo。

如果是B端產品的話，對原型能力要求沒那么高，基本就是一個打輔助的作用，來解釋需求文檔（以前我都是畫個demo后直接找UI小姐姐~）；C端的產品更重交互，所有對原型能力要求高一些，有的公司會要求產品畫高保真設計圖。

個人方法論分享

現在網上也有很多教程，我最早看的是小樓寫的，比較顯而易懂。當時還作死用了Axure全英版，查單詞就要花好久……（答應我一定要漢化好嗎）

入門的話可以先模仿下畫Baidu首頁，這個時候一般自己是沒啥設計思路的，可以畫畫喜歡的APP/PC界面，或者可以參考下antdesign的設計，現在還蠻多的互聯網公司用的都是螞蟻那一套，提前熟悉了的話正式工作以后也有幫助。

（畫外音：Axure也可以用來簡單的P圖，我前幾天還用Axure把同事的照片和易烊千璽的P在一起了你敢信嗎）

03 項目管理能力

項目管理能力=跟進+推動力。

推動力，從字面上解釋就是推著走，工作中也就是把這個項目逐步推的上線，一般在遇到瓶頸或者由于臨時的問題而影響進度的時候，產品同學就要通過不斷地溝通、解決問題去推動項目上線。

跟進則主要是在開發、測試階段，通過跟進開發進度、解決開發過程中的問題點，或者提前暴露風險從而避免項目delay等等。

個人方法論分享

說話一定要tough！不要不好意思扭扭捏捏，這點對于剛入行的小白同學十分重要，要有底氣把自己的需求點、期望結果和同事講明白，不要隨便講一句話就臉紅（去年我實習的時候第一次評審時聲音都在顫，更別提推動了），組織會議的時候、評審的時候、其他一切場合都不要方，你要記住你是這個項目的owner，要適當的硬氣一些。（悄悄告訴你，這個也是面試官會考察的一個能力點噢）。

和開發也好、業務也好，雙方確認完某個事情后，一定要在對應的時間的節點下再去跟進確認，每個階段都要保證是在自己的可控范圍內的、無風險的。寫到這里的時候突然想到我之前的mentor和我說：產品經理做的就是一個操心的活?，F在想想，真是深有體會。

04 數據分析能力

你以為需求上線了這個項目就算結束了嗎？too young too simple！

功能是給業務做了，那業務用的好不好，有沒有解決他們的問題，他們的反饋如何？這些產品同學也要關注呀！

工作以后最大的一個感悟就是：一切都要以數據說話。

上學的時候那種主觀的說辭“我覺得不錯”“挺有用的”“確實提高了效率”，在職場上完全是行不通的。

如果你說這個功能解決了你的問題，那你得靠數據去證明：做這個功能前，人均耗時多久，撲多少人力，上了這個功能后，人均耗時多少，大約提高了多少工效？等等等等。

個人方法論分享

帶著目的去做需求，比如：我這次這個功能就是想要把某某部門的工效提升20%，那在PRD中就要把涉及到工效的觸發點進行埋點處理，上線后請開發小哥哥跑一下數據自己算一下，看看有沒有達到期望指標，沒有達成的話，就要考慮功能上哪些地方還有不足。用這次的分析結果作為下個功能迭代的依據，逐步優化。

最重要的是，在這個過程中你十分清晰自己在這個過程中做了什么事，取得了什么效果，解決了什么問題。誒？等下，這些問題聽著好熟悉，對啦！這就是你下次跳槽的時候面試官會問的問題呀~ 如果這些你都了然于胸，那offer不就是你的了嗎？

作者：小仙貝；公眾號：閆秀兒

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

題圖來自Unsplash，基于CC0協議