初級產(chǎn)品經(jīng)理的職場復盤(二)專業(yè)能力篇

《初級產(chǎn)品經(jīng)理的職場復盤(二)專業(yè)能力篇》由會員分享，可在線閱讀，更多相關《初級產(chǎn)品經(jīng)理的職場復盤(二)專業(yè)能力篇（6頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、初級產(chǎn)品經(jīng)理的職場復盤（ 2）專業(yè)能力 上一篇我分享了一個初階產(chǎn)品經(jīng)理所具備的“軟實力”，上面我 為介紹大家介紹下必備的“硬實力”是哪些？ 之前有人比喻說，產(chǎn)品經(jīng)理就是一個團隊的小CEO需求怎么做， 得由產(chǎn)品經(jīng)理定。 其實這倒不是因為產(chǎn)品權(quán)利有多大，而是因為產(chǎn)品經(jīng)理所代表的 是訴求產(chǎn)品銷售的訴求，所以任何邏輯、功能點、權(quán)限的設計問題一 定是要產(chǎn)品關鍵問題同學來（背）拍（鍋）板的。 研發(fā)同事們在開發(fā)過程中經(jīng)常在群里艾特我：”是PM讓這么干 的” “PM給個邏輯吧” “ PM爾們決定是不是怎么做吧?！? 每次遇到這種等著我拍板的情況，真讓我瑟瑟發(fā)抖

2、…… 俗話說的好，背不好鍋的PM是一個優(yōu)秀的PM那作為一個優(yōu)秀 的初階PM需要具備哪些的專業(yè)能力呢？要想回答這個問題，就得要 知道，產(chǎn)品經(jīng)理每次都在干些啥？ 首先我們同步一個流程，產(chǎn)品同學經(jīng)過完成一個完整的功能迭代 需要有要以下這些環(huán)節(jié)： 這么總結(jié)下來，一目了然，一個小白產(chǎn)品所具備的核心硬實力大 致四個模塊，即PRD巽寫能力、AXUR繪制能力、運營管理能力以及數(shù) 據(jù)分析能力。 PRD （ ProductRequirementDocument ）即產(chǎn)品需求文檔，要想了解， PRD^底是個什么東西，就要問問自己這幾個問題： 問：PRD合誰看？ 答：PR虛產(chǎn)品提供貸款給開發(fā)、測試同學

3、看的 問：PRDi來干嘛 答：PR虛產(chǎn)品用來告訴開發(fā)這次需求是要實現(xiàn)什么功能、怎么實 現(xiàn)、實現(xiàn)效果 問：PR舊的時候有什么準許嗎？ 答：沒有特殊的規(guī)定，本著“把話說清楚”的原則，把這次需求 的背景、目前的現(xiàn)狀、以及實現(xiàn)的方案融資方案寫下來即可。 個人方法論分享 寫應用程序的時候圍繞“誰要用”，“為什么要用”，“怎么實 現(xiàn)”這三個維度去寫，這樣就確保這個需求的前因后果是清晰的了。 圍繞著系統(tǒng)去寫 在寫同時實現(xiàn)方案的時候，要通過在系統(tǒng)上觸發(fā)的情境去寫對應 的交互過程或者后續(xù)的流程，恰當?shù)臅r候流程圖可以通過流程圖展示 出來。B端的產(chǎn)品品類要注意需求中所涉及到的數(shù)據(jù)的流轉(zhuǎn)、存儲

4、等； 而 C 端的產(chǎn)品則要注意功能中涉及到的交互、跳轉(zhuǎn)邏輯等要描述清楚。 考慮界面、系統(tǒng)的關聯(lián)性 比如是一個很簡單的加字段的需求，也要考慮到這個字符串字段 是否支持刪、改、查等操作，涵蓋他的輸入規(guī)則、取值邏輯學以及對 其他系統(tǒng)的影響，比如說，如果我是在訂單系統(tǒng)加了這個字段，那退 費系統(tǒng)也需要展示嗎？等等等等 數(shù)據(jù)埋點需求 如果這個功能后需要進行效果評估的話，就需要在文檔里說明埋 點的場景以及埋點的規(guī)則。 考慮各種邊界值以及異常情況 正向的流程各個環(huán)節(jié)我們每個人都能想得到，但是一旦流程中任 何一個環(huán)節(jié)中曾發(fā)生了問題，系統(tǒng)又該如何處理呢？ 舉一個很簡單的表示法，微信支付我們都

5、使用過：用戶掃碼-手 動輸入金額-輸入密碼-支付成功。 可是這其中幾乎每個確實節(jié)點都有可能終止操作：掃碼失敗、不 展示二維碼怎么辦？金額輸入過大是否有限制？限制規(guī)則是什么？密 碼校驗失敗后會怎么提示用戶呢？密碼輸入正常但是沒有調(diào)起微信的 支付接口該怎么辦？接口響應延遲導致重復支付了怎么辦等等等等。 這些風險問題以及應對辦法，就是產(chǎn)品決策經(jīng)理必須來談決策的， 一個好的文檔一定是各種正向流程、逆向流程、每個邊界值都考慮周 全，把開發(fā)安排的明明白白 ~ 但是畢竟產(chǎn)品同學也沒有那么多時間去把每個正向、負向場景的 用例梳理過來，如果之后在技術(shù)評審或者在開發(fā)的過程中被指出來的 話，就

6、用小本本記錄下來，之后再做類似的功能的完全一致時候不要 再犯相同的錯誤就好啦。 再多說一句：寫完文檔之后自己要review 一遍，把自己比擬成一 個門外漢，看下能不能讀懂，文檔的邏輯有沒有漏洞，這個方法親測 很有效哦。 Axure 是畫原形的一個工具，也有很多人用 Sketch 。原型就是指 你所做的功能的一個設計demo。 如果是 B 端產(chǎn)品的話，對原型潛能要求沒那么高，基本就是一個 打輔助催化作用的作用，來解釋需求文檔（以前我都是畫個demo后直 接找UI小姐姐~） ; C端的產(chǎn)品更重交互，所有對原型生存能力要求高 改良版一些，有的公司會要求設計圖商品畫高保真設計圖。

7、個人方法論分享 現(xiàn)在網(wǎng)上也有很多教程，我最早看的是小樓寫的，比較顯而易懂。 當時還作死用了 Axure全英版，查單詞就要花好久……（答應我一定 要剛杰好嗎） 入門的話可以先模仿下畫 Baidu 首頁，這個時候一般自己是沒啥 設計思路的，可以畫畫喜歡的 APP/P嚼面，或者可以參考下 antdesign 的設計，現(xiàn)在還蠻多的互聯(lián)網(wǎng)公司用的都是螞蟻那一套，提 前熟悉按時了的話正式工作以后也有幫助。 （畫外音：Axure也可以用以簡單的P圖，我前幾天還用Axure把 同事的照片和易烽千璽的P在一起了你敢回信嗎） 項目管理能力=跟進+推動力。 推動力，從字面上解釋就是推著走，工作中也就

8、是把這個項目逐 步推的上線，一般在遇到瓶頸或者由于臨時的問題而影響進度的時候， 產(chǎn)品同學就要通過慢慢逐漸地溝通、解決問題去推動項目上線。 跟進則主要是在開發(fā)、測試階段，通過跟進開發(fā)進度、解決開發(fā) 過程中的風險問題點，或者提前暴露違約風險從而避免項目 delay 等 等。 個人方法論分享 說話一定要tough ！不要不好意思扭扭捏捏，這點對于剛?cè)胄械男? 白同學十分重要，要有底氣把自己的消費需求點、期望結(jié)果和同事講 明白，不要隨便講一句話就臉紅（去年我的時候第一次評審時聲音都 在顫，更別提推動了），組織會議的時候、評審的時候、其他一切場 合都不要方，你要記住你是這個項目的own

9、er,要適當?shù)挠矚庖恍? （悄悄告訴你，這個也是面試官會考察的一個點噢）。 和開發(fā)也好、業(yè)務也好，雙方確認完某個事情后，一定要在對應 的時間的節(jié)點下再去跟進確認，每個階段要保證是在自己的可控范圍 內(nèi)的、無風險的。寫到這里的時候突然想到我之前的 mentor 和我說： 產(chǎn)品活著經(jīng)理做的就是一個操心的活?，F(xiàn)在想想，真是深有體會。 你以為需求上線了這個就算結(jié)束了嗎？ tooyoungtoosimple ！ 功能是給管理業(yè)務做了，那管理業(yè)務用的好不好，有沒有解決他 們的結(jié)構(gòu)性問題，他們的反饋如何？這些產(chǎn)品同學也要高度關注呀！ 工作以后最大的之后一個感悟就是：一切都要以圖表說話。 上

10、學的讀書時候那種本質(zhì)的說辭“我覺得不錯”“挺有用 的”“確實提高了效率”，在職場上完全是行不通的。 如果你說道這個功能解決了你癥結(jié)的問題，那你得靠數(shù)據(jù)去證明： 做這個功能前，人均耗時多久，撲多少人力，上了這個功能后，人均 耗時多少，大約提高了多少工效？等等等等。 個人方法論分享 帶著本意去做需求，比如：我這次這個功能就是想要把某某部門 的工效提升20%那在PR計就要把涉及到工效的觸發(fā)點進行埋點處理, 上線后請開發(fā)小哥哥跑一下數(shù)據(jù)自己算一下，看看有沒有達到期望標 準，沒有達成的話，就要考慮功能功用上用哪些地方還有不足。用這 次的分析結(jié)果作為下個功能迭代的依據(jù)，逐步優(yōu)化。 最重要的是，在這個過程中你十分清晰自己在這個過程中做了做 做什么事，取得了什么效果，解決了什么問題。誒？等下，這些問題 聽完著好熟悉，對啦！這就是你下次跳槽的時候面試官會轉(zhuǎn)職問的問 題呀~如果這些你都堅信不疑，那offer 不就是你的了嗎？