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

之前有人比喻說，產(chǎn)品經(jīng)理就是一個團隊的小CEO，需求怎么做，得由產(chǎn)品經(jīng)理定。

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

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

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

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

首先我們同步一個流程，產(chǎn)品同學要完成一個完整的功能迭代需要經(jīng)過以下這些環(huán)節(jié)：

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

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

01 PRD撰寫的能力

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

問：PRD給誰看？

答：PRD是產(chǎn)品提供給開發(fā)、測試同學看的

問：PRD用來干嘛

答：PRD是產(chǎn)品用來告訴開發(fā)這次需求是要實現(xiàn)什么功能、怎么實現(xiàn)、實現(xiàn)效果

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

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

個人方法論分享

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

圍繞著系統(tǒng)去寫

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

考慮界面、系統(tǒng)的關聯(lián)性

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

數(shù)據(jù)埋點需求

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

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

正向的流程我們每個人都能想得到，但是一旦流程中任何一個環(huán)節(jié)發(fā)生了問題，系統(tǒng)又該如何處理呢？

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

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

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

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

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

02 Axure繪制的能力

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

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

個人方法論分享

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

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

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

03 項目管理能力

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

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

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

個人方法論分享

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

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

04 數(shù)據(jù)分析能力

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

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

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

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

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

個人方法論分享

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

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

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

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

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