常聽到有人講了幾十分鐘的理論，卻被一句：說人話！給嗆住。以前這個(gè)場景多是“技術(shù)-產(chǎn)品”，現(xiàn)在更多的是“產(chǎn)品-運(yùn)營”。原因如下：

1. 大部分的技術(shù)由產(chǎn)品對接，運(yùn)營更多的是面對產(chǎn)品
2. 邏輯思維的不同，產(chǎn)品思維是多個(gè)視角的出發(fā)，結(jié)合了產(chǎn)品邏輯、業(yè)務(wù)形態(tài)、商業(yè)前景等等。而運(yùn)營則是更多價(jià)值的聚焦，包括某個(gè)活動(dòng)、某個(gè)場景、人群、需求等。
3. 產(chǎn)品經(jīng)理是自負(fù)的，這在創(chuàng)業(yè)公司更常見，也是因?yàn)閷?yīng)的運(yùn)營還沒有足夠經(jīng)驗(yàn)。
4. 具象化視角的不同，這和邏輯思維又不一樣，比如：

喵：國慶節(jié)想要增加特殊化標(biāo)簽，增加用戶活躍度

狗：特殊化標(biāo)簽有哪些形態(tài)？應(yīng)用場景什么？預(yù)計(jì)會(huì)增加多少日活？時(shí)間點(diǎn)是什么？有沒有考慮過用普通標(biāo)簽滿足需求？那為什么不把普通標(biāo)簽一起優(yōu)化呢？

喵：。。。說人話

往往就沒有了然后！

這應(yīng)該是每個(gè)產(chǎn)品經(jīng)理都會(huì)遇到的問題，因?yàn)楫a(chǎn)品經(jīng)理本身賦予了更多的使命，去思考的更多、構(gòu)架的更多，且要擔(dān)任運(yùn)營與技術(shù)的需求潤滑劑。篩選需求、完成需求、計(jì)劃需求！

產(chǎn)品經(jīng)理如何講人話？

首先從產(chǎn)品的迭代講起，產(chǎn)品迭代涉及了需求收集、需求分析、產(chǎn)品定稿、需求評審、里程碑、測試驗(yàn)收、產(chǎn)品發(fā)布等等。發(fā)現(xiàn)其中運(yùn)營僅在第一步“需求收集”中占有角色，而需求的來源包括了：用戶、運(yùn)營、產(chǎn)品、BOSS等。

早期的創(chuàng)業(yè)公司總是產(chǎn)品先行，在發(fā)展到一個(gè)階段后再由運(yùn)營去驅(qū)動(dòng)，所以每次迭代通常是一個(gè)大功能+用戶小需求和優(yōu)化。

在技術(shù)、測試完成后，我們通常會(huì)召開內(nèi)部的“產(chǎn)品發(fā)布會(huì)”，在大號(hào)電視前演示迭代增加和優(yōu)化的功能，發(fā)布會(huì)總是很成功的順利舉行！??！

產(chǎn)品上線后，PM又開始了新一輪的需求收集，而喵們也開始運(yùn)營當(dāng)前的產(chǎn)品功能（產(chǎn)品運(yùn)營），但總發(fā)現(xiàn)運(yùn)營對產(chǎn)品的功能不了解，在運(yùn)營過程中還會(huì)反復(fù)的詢問產(chǎn)品！

當(dāng)時(shí)很無奈，應(yīng)對的措施是：針對每一版本迭代去更新“產(chǎn)品運(yùn)營規(guī)則說明文檔”，我記得當(dāng)時(shí)后臺(tái)的一份文足有8000字，之后發(fā)現(xiàn)效果還是不行，索性將需求文檔（PRD）也抄送給運(yùn)營。再之后我們開始邀請運(yùn)營一起參與到需求評審中！

直到。。。

“能不能說人話！”

什么是人話？

我自己也思考了很久，也和BOSS溝通后得出以下幾點(diǎn)：

1. 運(yùn)營需要背負(fù)自己的責(zé)任，產(chǎn)品不應(yīng)該處處領(lǐng)先運(yùn)營
2. 不把運(yùn)營當(dāng)baby，盡量的等量
3. 運(yùn)營是產(chǎn)品，產(chǎn)品即運(yùn)營

我更換了和運(yùn)營溝通的方式并做了更多的交流，舍棄“產(chǎn)品運(yùn)營規(guī)則說明文檔”和PRD文檔的“死人式”交流，盡量的做到face to face，溝通的基礎(chǔ)上再輔以功能更新說明（用最簡單的方式陳述功能）。如：

XXX APP2.3版本更新內(nèi)容：

• 增加了IM（在線聊天），支持商家對用戶，不支持群聊（原因已做說明）
• 我的-頁面 優(yōu)化，增加我的權(quán)限（權(quán)限展示）
• xxx、xxx bug修復(fù)
• xxx頁面-xxx UI優(yōu)化

在事后做了進(jìn)一步的溝通和對比，發(fā)現(xiàn)運(yùn)營對這樣的操作接受度和興趣度更大，再加上驗(yàn)收時(shí)邀請運(yùn)營參與也會(huì)增加運(yùn)營的興趣度和對功能的理解。

當(dāng)運(yùn)營提出需求時(shí)

這些是針對非運(yùn)營提出的需求對其的影響力，如果一個(gè)功能或bug類是由運(yùn)營提出的，大情景有不相同！

這又會(huì)有兩種情況，區(qū)分點(diǎn)在于運(yùn)營的關(guān)注度：

A類：關(guān)注度高，比如要配合某個(gè)活動(dòng)或場景提出的功能，喵甚至?xí)炔患按膮⑴c到測試和驗(yàn)收的環(huán)節(jié)，以便有充足的時(shí)間做運(yùn)營相關(guān)準(zhǔn)備

B類：主要是收集到的BUG和優(yōu)化類意見，說運(yùn)營不關(guān)注也非，主要是喵們拋出各類問題后處于“記憶弱區(qū)”，在沒有遇到提出問題的相應(yīng)場景前，基本不會(huì)再次提出。

針對A類，給予運(yùn)營更多的參與感，針對B類，我的應(yīng)對措施是：產(chǎn)品問題記憶表

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

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

做到記錄這一步還沒有結(jié)束，最重要的是跟蹤需求情況和反饋。若需求滿足，你就是這個(gè)需求的項(xiàng)目經(jīng)理，你需要負(fù)責(zé)跟蹤，需求因果后也需要通知喵們驗(yàn)收和接受反饋意見（在一個(gè)階段后可增加“需求滿意度”）

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

第三點(diǎn)，故事描述

故事描述起先是產(chǎn)品經(jīng)理針對技術(shù)的一種功能說明方式，因?yàn)樗季S方式的不同，普通的產(chǎn)品描述技術(shù)可能無法理解，那么就把他們帶入場景中，以用戶的視角去發(fā)現(xiàn)問題和提出解決方案。

這一點(diǎn)同樣適合 產(chǎn)品→運(yùn)營

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

以上三點(diǎn)其實(shí)都是個(gè)人在實(shí)際場景中遇到的問題解決方式，由于在旅行，可能描述還不到位，觀點(diǎn)也更多的是針對小型或創(chuàng)業(yè)企業(yè)，成熟企業(yè)已有了規(guī)范的流程，運(yùn)營也具備能力和經(jīng)驗(yàn)，所以不需要更多的擔(dān)憂，而我們更多的是需要靈活，我見過有公司為了敏捷開發(fā)甚至拋棄了產(chǎn)品原型和PRD文檔，除了團(tuán)隊(duì)更多的都是產(chǎn)品經(jīng)理牽頭的溝通。

不同企業(yè)的問題也會(huì)有不同的放大縮小，千萬不要簡單的套用其他團(tuán)隊(duì)的溝通方式。

講人話，沒那么玄乎！講的是人、情、理，PM除了做好產(chǎn)品設(shè)計(jì)者和負(fù)責(zé)人，更是整個(gè)企業(yè)組織的銜接者、驅(qū)動(dòng)器。還需要更多的打開、放低，因?yàn)槟闶钦麄€(gè)組織的中心。

記住，PM無處不在！

本文由 @青團(tuán)社-強(qiáng)子 （微信GXQ22222）原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。