產品經理如何講人話？

首先從產品的迭代講起，產品迭代涉及了需求收集、需求分析、產品定稿、需求評審、里程碑、測試驗收、產品發佈等等。發現其中運營僅在第一步“需求收集”中佔有角色，而需求的來源包括了：用户、運營、產品、BOSS等。

早期的創業公司總是產品先行，在發展到一個階段後再由運營去驅動，所以每次迭代通常是一個大功能+用户小需求和優化。

在技術、測試完成後，我們通常會召開內部的“產品發佈會”，在大號電視前演示迭代增加和優化的功能，發佈會總是很成功的順利舉行!!!

產品上線後，PM又開始了新一輪的需求收集，而喵們也開始運營當前的產品功能(產品運營)，但總髮現運營對產品的功能不瞭解，在運營過程中還會反覆的詢問產品!

當時很無奈，應對的措施是：針對每一版本迭代去更新“產品運營規則説明文檔”，我記得當時後台的一份文足有8000字，之後發現效果還是不行，索性將需求文檔(PRD)也抄送給運營。再之後我們開始邀請運營一起參與到需求評審中!

直到。。。

“能不能説人話!”

什麼是人話，我自己也思考了很久，也和BOSS溝通後得出以下幾點：

1.運營需要揹負自己的責任，產品不應該處處領先運營

2.不把運營當baby，儘量的等量

3.運營是產品，產品即運營

我更換了和運營溝通的方式並做了更多的'交流，捨棄“產品運營規則説明文檔”和PRD文檔的“死人式”交流，儘量的做到face to face，溝通的基礎上再輔以功能更新説明(用最簡單的方式陳述功能)。如：

學生APP2.3版本更新內容：

·增加了IM(在線聊天)，支持商家對學生，不支持羣聊(原因已做説明)

·我的-頁面優化，增加我的權限(權限展示)

·xxx、xxx bug修復

·xxx頁面-xxx UI優化

在事後做了進一步的溝通和對比，發現運營對這樣的操作接受度和興趣度更大，再加上驗收時邀請運營參與也會增加運營的興趣度和對功能的理解。

這些是針對非運營提出的需求對其的影響力，如果一個功能或bug類是由運營提出的，大情景有不相同!

這又會有兩種情況，區分點在於運營的關注度：

A類：關注度高，比如要配合某個活動或場景提出的功能，喵甚至會迫不及待的參與到測試和驗收的環節，以便有充足的時間做運營相關準備

B類：主要是收集到的BUG和優化類意見，説運營不關注也非，主要是喵們拋出各類問題後處於“記憶弱區”，在沒有遇到提出問題的相應場景前，基本不會再次提出。

針對A類，給予運營更多的參與感，針對B類，我的應對措施是：產品問題記憶表

“產品問題記憶表”

這是我在12.23收集的部分需求，在N次需求表迭代後，將字段分為以下維度：日期、提交者、類型、緊急度、商業價值、描述、場景、可能原因、是否滿足、方案、完成時間、問題、狀態。

這些應該根據每個公司不同的情況進行字段的增加或減少，很多公司這份表格是直接由需求提出者填寫的，有的是以卡片格式，有的則是通過郵件，方式不限，請找到最合適自己公司的操作方式。

做到記錄這一步還沒有結束，最重要的是跟蹤需求情況和反饋。若需求滿足，你就是這個需求的項目經理，你需要負責跟蹤，需求因果後也需要通知喵們驗收和接受反饋意見(在一個階段後可增加“需求滿意度”)

若需求無法滿足，則需要給予對方不滿足的原因或者其他説明。

第三點，故事描述

故事描述起先是產品經理針對技術的一種功能説明方式，因為思維方式的不同，普通的產品描述技術可能無法理解，那麼就把他們帶入場景中，以用户的視角去發現問題和提出解決方案。

這一點同樣適合產品→運營

故事描述的接受度和理解度遠超其他的描述方式，因此PM需要成為一個“有故事的人”。

以上三點其實都是個人在實際場景中遇到的問題解決方式，由於在旅行，可能描述還不到位，觀點也更多的是針對小型或創業企業，成熟企業已有了規範的流程，運營也具備能力和經驗，所以不需要更多的擔憂，而我們更多的是需要靈活，我見過有公司為了敏捷開發甚至拋棄了產品原型和PRD文檔，除了團隊更多的都是產品經理牽頭的溝通。

不同企業的問題也會有不同的放大縮小，千萬不要簡單的套用其他團隊的溝通方式。

講人話，沒那麼玄乎!講的是人、情、理，PM除了做好產品設計者和負責人，更是整個企業組織的銜接者、驅動器。還需要更多的打開、放低，因為你是整個組織的中心。