本文講解了三大工作技巧，適合0-2歲的初階產品經理，希望可以幫助到你們~
曾經一度錯誤認為，產品經理的日常就是連環撕：撕運營，撕完運營撕設計；撕設計，撕完設計撕開發，好像產品經理為了捍衛產品思路一直在做抗爭，永遠都是對方傻，對方沒明白，對方無理，對方太閒。
這一年半的產品工作，教會我學會理解不同角色的焦慮和怒點：頂著kpi壓力但不知道實際開發進度的運營喵，費神費腦把功能趕出來卻被告知需求又改了的程序猿，有交互和視覺追求和堅持的設計獅，還有八九份合同還沒看的法務兔……
很多溝通上的易燃易爆點，產品汪其實是可以把控的。產品經理的職責就是清晰表達需求，高效推進項目。讓各個崗位角色都順暢溝通舒暢幹活，最終達成目標。
對於0-2歲的初階產品經理，如果能做到以下三大工作技巧，會成長得很快：
一、PRD
網上有很多需求文檔模板，產品經理入門最快的手段就是從前輩實操過的PRD中學習表達需求。同時，為了加快輸出需求文檔效率，我常常會更新我的需求文檔模板，拿來就用。
小結一下就是：創建你自己的需求文檔模板，儘量讓下次的需求少一點會被diss的漏洞，更有條理更清晰明瞭。這裡提供我目前的模板，僅供參考：
1. 文檔基礎
（1）文檔性質
因為文檔輸出的時效性要求非常高，不能僅為了文檔的門面就耗費太多時間，所以PRD的格式不限，可以是doc、xls、rp等，只要能“清晰表達需求”即可。一個需求內容，我可能會根據實際情況用多格式文檔互為補充。
其實這裡用了“組件”的思維，完整的需求表達由很多個模塊組成，每次有更新，就更新該模塊即可，對接人按需使用。
（2）文檔命名
《【文檔性質】需求名稱（備註） 文檔版本號_需求人名字_更新日期》，當需求本身和文檔分別有版本號，兩個版本號又比較重要時，我會把文檔版本號放在最後。文檔版本號不是特別重要時可不寫。
（3）修訂記錄
這是非常容易忽略的細節位，很多人沒養成好的工作習慣，工作就會很混亂，效率很低。每一次修訂需求材料，就應該及時做相關標註。更新的頻率不定，只要需求有少許變動或者補充，我都會做一次文檔更新，作為留底。
（4）頁眉頁腳
當文檔某一頁被打印或截圖出來，你是否能快速知道這是哪一份文檔的第幾頁內容？
2. 文檔結構：
（1）需求概述
產品經理可能要對接多方需求，如果對方只是“一句話需求”的時候，就可以讓需求提出方先按以下格式梳理需求，然後你再輸出後續的方案。
這些內容都是重要鋪墊，需求文檔就是要讓每一個參與項目的人都能瞭解需求的全貌——需求是什麼以及它的目的和價值是什麼，避免讓參與人員僅僅成為需求的執行者，你需要讓划槳的每個人知道這條船究竟要駛向何方。
- 名詞解釋
- 需求背景（包括需求來源、需求目的、需求價值）
- 產品概述（包括產品簡介、基本原則、基本思路）
- 競品分析
- 投放渠道
- 性能要求（包括網絡連接、手機操作系統、消息推送系統、後臺數據庫、服務器操作系統、系統吞吐量等要求）
- 資源引入（包括資源提供方以及具體介紹）
（2）業務流
原型只是需求內容的一部分，不要讓自己掉入原型無法自拔，要關注需求的全貌。
- 需求清單（項目較小時，我會在文檔內簡單羅列；項目較大時，我會專門用一個表格文件來梳理。）
- 需求詳述（包括通用、細分的詳細說明，原型圖可在此處輔助理解需求。注意兼顧常規流程和異常流程，儘量讓設計、開發和測試沒法找茬~）
- 流程圖（當一個需求看似很簡單，一句話就表述完成時，那建議你先去畫畫流程圖，忽略的方面自然就會顯露出來。）
- 設計需求（包括風格取向、色系取向、形象標識、其他設計要點等，讓設計發揮之前，你需要先考慮你想要的是什麼，避免來回改動。）
（3）後臺支撐系統
需求寫到這裡，可能你也累了，但要堅持下去。
- 數據統計需求（具體內容我通常會放到數據模板的xls裡，數據模板包括數據字段名稱、定義、報表接收名單、修訂記錄等。）
- 配套的配置系統（視各平臺業務而定）
（4）安全基礎
- 壓力測試要求（視需求的影響範圍，參與壓力測試，保證整體鏈路的內部系統達到壓力測試要求。）
- 壓力測試流程（因為是我比較陌生的領域，所以做好相關備註，每次按流程來做。）
- 歷史壓測結果參考
（5）資金流
我通常會把信息流放到業務流一併梳理，資金流涉及實際的金錢流向會專門拎出來。
- 對賬範圍
- 對賬單
- 對賬數據規範
- 查錯處理
（6）技術對接
技術細節注意點會標註在這個板塊。開發中出現新的問題以及對應的解決方案也可以寫在這裡。
（7）運營規則
產品成型後，要制定運營策略。
- 法務規則（合法是基礎。平臺協議、產品紀律等有時會是產品盲區，特意留了這個板塊提醒自己要全面思考需求。）
- 產品運營規劃
- 運營工具
- 客服文檔（提供給客服人員閱讀的產品介紹文檔。）
（8）附錄
記錄需求材料中涉及到的文檔名稱。
以上是需求文檔內基本的要素，使用時因根據需求本身按需使用，確實不涉及的領域可以不填。
二、需求池管理
近一年我的工作範圍較廣，屬於多領域嘗試，所以需求來源非常廣泛，但並不影響我成為部門內高產出的代表。這非常依靠溝通、協調和需求管理能力。
我曾經是石墨的忠實粉絲，在管理UI設計和前端團隊的需求時，就開始有意識培養團隊共同完成排期管理表，到現在他們也一直在沿用。
後來騰訊文檔出現之後，屈服於企鵝家的社交關係網，我就轉用它來與對接方進行需求池的整理（雖然線上編輯功能還不是太完善，但滿足基本的編輯需要）。別看它是個簡單的表格，細節上的用處非常多：
- 每週發出此表的更新版，讓需求提出人、需求對接人（產品經理）、需求執行人（設計、開發等人員）可以自行查閱相關需求在整體中的進度、優先級等。
- 我在表格後面設了一列自用的“上線月份”，每次填月度考核時，就導出表格然後篩選考核月份完成的需求，就不怕自己記性不好會漏掉成果。
- “需求提出時間”就能知道項目拖延程度了，如果是個人原因，就要注意做好需求優先級的考量和需求清理工作。要記得，做到清晰表達需求也是為了高效推進項目。執行力是產品經理的必備技能。項目推不動，就是你的不作為。
三、不斷學習
雖然產品經理不用手把手敲每一行代碼，但需要補充程序思維。程序猿在面對一個問題，除了已有的經驗，可能更多地是依靠搜索解決問題。
一句“Hello world”開啟的是全球知識資源的互通，只要不故步自封，多主動去挖掘有效資源，網上有那麼多免費或者付費的知識內容（需自己篩選有價值的），個人增值的途徑還是有很多的。平時多逛逛技術的社區，培養對程序猿的崇拜感（哈哈哈哈哈哈）以及共同語言，對技術的敬畏可以讓你變得謙遜而不是趾高氣揚。
而培養自己的產品感，就要多體驗多思考：抖音與賭博之間的相似點是什麼，上傳在抖音和微博的視頻各有哪些編輯區別點，為什麼在支付寶付款碼頁要露出一個不可點擊跳轉的會員等級信息，為了用戶留存小程序們都做了哪些心機動作，還有好多類似於牛奶經濟學一樣的產品學問。
《人人都是產品經理2.0》中提到產品、開發、運營三者的關係：想清楚、做出來、推出去，在產品設計之初，就應該遠慮，產品誕生不是最終一環，被市場認可需要很多的運營手段。所以產品經理也需要學習社會新出的運營花樣，再結合到產品設計中。
我是以產品為核心，運營、開發為新觸角作為自己的發展方向，雖然離“全棧產品經理”還有很長一段路要走，但這個時代，屬於年輕人的機會太多太多了，加油~
本文由 @婉盈不是這個瑩 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels ，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
