產品經理基本功：想清楚+講清楚

開始實習已逾一月，在段時間里我也大大小小的經歷了數十個需求。從最初對業務一無所知，只了解哪些書本上抽象的概念到后來能夠較為獨立的負責一個需求的生老病死。有許多的成長，也有許多的體會。

通勤

因為租金昂貴等各種原因，實習的公司離家很遠，每天單程的通勤時間超過1個小時，并且一種交通工具是不行的，下了地鐵還要趕到接駁點坐班車。

路上的時間很長，思考的時間也就多了不少。

站在上海嘈雜的地鐵里，人群擁擠的抬不起來手來。左手拎著飯盒，右手扶著扶桿，偶爾累了還要換換手，玩手機變成了一般人難以完成的高難度動作。于是人群很吵，心卻變得很靜，有許多的時間可以去思考工作中的那些對與錯。

在實習之前，我也寫過一些關于“產品思維”的一些文章，對于好的產品經理十分敬仰，覺得思維的廣度與深度令人著迷。當然，實習之后我也并沒有覺得那些是不重要的，但卻更多了一層腳踏實地。思維的廣度不能只靠資訊的積累，思維的深度也不能只靠天馬行空的想象與推測。

建立起自己的產品哲學觀前，先要能夠做好事情，這是產品經理的基本功，也是公司對于任職者的基本要求。相對于技術、設計，產品經理這一職位學校并無專業設置，也無技能訓練，好像人人都能走進門，好像人人都能做好事，但其實并非如此。

一個合格的產品經理，你至少要做好兩件事：第一，想清楚；第二：講清楚。

對于產品er來說，每天打交道最多的不是技術也不是設計，而是“需求”，這些需求可能從別的業務方處來，可能從老板處來，也有可能從產品er里的小腦瓜里冒出來。

公司里常常發生的一種情況是別的業務方來了一個需求，產品er覺得“emmm…好像還不錯，正好兩周一更版，加進去吧！”結果做出來的效果可能不盡如人意。

對于產品er來說，需求并不完全由自己控制的，無論是實現還是舍棄，到面前的需求就需要產品er認真對待，去思考：

本人在一個以視頻為核心產品的公司，前兩天直播頻道給我們部門提了個需求，希望我們可以在彈幕上給直播頻道的主播們進行引流，所以希望他們能夠導入彈幕，上面有主播信息以及跳轉到相應主播間的button。

在接到這個需求之后，我們首先需要去認真的思索這個需求：

（1）這個需求一定要做嗎？它的目的是什么？

這邊我們主要考慮的還是主播頻道那邊的目的：引流，同時希望優化用戶體驗或至少不對用戶體驗造成傷害。

（2）是否有可以替代的方案？

這里我們大概想了三種：

最后用了哪個方案這里不透露了，在確定做某一個需求之后，還有許多的事需要想清楚：

想清楚是講清楚的基礎。

一個需求的實現需要多方的配合，但人之常情的是，通常前端只想知道前端要做什么，后臺通常只想知道后臺要做什么，測試也只想知道測試要做什么。但你產品經理er，你需要知道所有人該干什么。

通常我拆解需求的方式是先用Xmind進行邏輯的拆分，再用Feature list進行整理總結。

（大致如上圖，由于保護公司利益有一些處理）

總之，無論是使用什么樣的工具輔助，最后的結果一定要是你在腦海里完整、清晰的勾畫出了一個需求的方方面面。

在腦海中建立起一個需求的每個細節點之后，你還需要把他事無巨細、毫無歧義的傳達給諸位實現者，通常的渠道有四個：PRD、UE/UI、需求評審會議以及日常聊天軟件。輔助的還包括原型圖、用例圖、流程圖等。

其中的起點就是PRD，一般PRD的組成部分是文檔信息、修訂記錄、目錄及正文內容，正文內容又包括引言、特性所包含的功能、功能性需求等。

由于設計師會按照你所撰寫的PRD去輸出UE和UI稿，所以PRD里的邏輯必須十分清晰、完整，盡量考慮好所有的邊界情況和邏輯漏洞，同時在PRD中用語需要規范，避免由于對于某一詞語理解不同而導致效率降低的情況。

PRD中的功能入口設置通常需要和UE共同商討，UE在輸出UE稿后需要交給產品經理去統一同步到各位技術手上，為了避免反復修正和需求變更引起矛盾，產品需要仔細的確認UE稿，防止出現UE稿和PRD矛盾或不同步的情況。

在輸出UE和UI后，會舉行一次需求評審會議，主要是產品經理主講，UE輔助，這是講清楚中最重要的部分，因為語言總是比文字有更強的說服力，在評審會上要明晰各方疑惑的問題并同步到PRD以及UE上。

產品er們也需要去有意識的對文字表達和語言表達能力進行訓練，以便更好的講清楚。

需求評審會議后，開發的老大一般會進行排期，這時候開發和測試童鞋可能會來與你核對或者確認一些需求的細節，這時候你就會明白：一份好的prd是提高工作效率的關鍵，那些prd留下來的坑都是需要產品er后期去填的，千萬不要偷懶~

在溝通時，需要注意當聊天軟件無法講清楚時，一定要積極的去找開發當面交流，以避免矛盾的產生，另外要注意用流程的規范降低交流成本。

比如：你確實需要變更或許補充一個需求，一定要和開發以及測試先事先確認，再進行prd和UE、UI稿的修改，修改后一定要通過郵件或其他方式同步到各方。

變更時的措辭也需要注意，剛實習的時候我就曾因同步時，措辭有歧義并且@錯了人而和開發產生了一點小矛盾。開發、測試、產品實在是太容易相互產生怨懟的職位，各盡其職，不拖后腿，才是解決這個問題的根本辦法。

想清楚+講清楚，我正在努力成為一名合格的產品經理，你呢？

本文為@運營喵原創，運營喵專欄作者。