- 相關(guān)推薦
產(chǎn)品經(jīng)理如何講人話(huà)？
首先從產(chǎn)品的迭代講起，產(chǎn)品迭代涉及了需求收集、需求分析、產(chǎn)品定稿、需求評審、里程碑、測試驗收、產(chǎn)品發(fā)布等等。發(fā)現其中運營(yíng)僅在第一步“需求收集”中占有角色，而需求的來(lái)源包括了：用戶(hù)、運營(yíng)、產(chǎn)品、BOSS等。
早期的創(chuàng )業(yè)公司總是產(chǎn)品先行，在發(fā)展到一個(gè)階段后再由運營(yíng)去驅動(dòng)，所以每次迭代通常是一個(gè)大功能+用戶(hù)小需求和優(yōu)化。
在技術(shù)、測試完成后，我們通常會(huì )召開(kāi)內部的“產(chǎn)品發(fā)布會(huì )”，在大號電視前演示迭代增加和優(yōu)化的功能，發(fā)布會(huì )總是很成功的順利舉行!!!
產(chǎn)品上線(xiàn)后，PM又開(kāi)始了新一輪的需求收集，而喵們也開(kāi)始運營(yíng)當前的產(chǎn)品功能(產(chǎn)品運營(yíng))，但總發(fā)現運營(yíng)對產(chǎn)品的功能不了解，在運營(yíng)過(guò)程中還會(huì )反復的詢(xún)問(wèn)產(chǎn)品!
當時(shí)很無(wú)奈，應對的措施是：針對每一版本迭代去更新“產(chǎn)品運營(yíng)規則說(shuō)明文檔”，我記得當時(shí)后臺的一份文足有8000字，之后發(fā)現效果還是不行，索性將需求文檔(PRD)也抄送給運營(yíng)。再之后我們開(kāi)始邀請運營(yíng)一起參與到需求評審中!
直到。。。
“能不能說(shuō)人話(huà)!”
什么是人話(huà)，我自己也思考了很久，也和BOSS溝通后得出以下幾點(diǎn)：
1.運營(yíng)需要背負自己的責任，產(chǎn)品不應該處處領(lǐng)先運營(yíng)
2.不把運營(yíng)當baby，盡量的等量
3.運營(yíng)是產(chǎn)品，產(chǎn)品即運營(yíng)
我更換了和運營(yíng)溝通的方式并做了更多的交流，舍棄“產(chǎn)品運營(yíng)規則說(shuō)明文檔”和PRD文檔的“死人式”交流，盡量的做到face to face，溝通的基礎上再輔以功能更新說(shuō)明(用最簡(jiǎn)單的方式陳述功能)。如：
學(xué)生APP2.3版本更新內容：
·增加了IM(在線(xiàn)聊天)，支持商家對學(xué)生，不支持群聊(原因已做說(shuō)明)
·我的-頁(yè)面優(yōu)化，增加我的權限(權限展示)
·xxx、xxx bug修復
·xxx頁(yè)面-xxx UI優(yōu)化
在事后做了進(jìn)一步的溝通和對比，發(fā)現運營(yíng)對這樣的操作接受度和興趣度更大，再加上驗收時(shí)邀請運營(yíng)參與也會(huì )增加運營(yíng)的興趣度和對功能的理解。
這些是針對非運營(yíng)提出的需求對其的影響力，如果一個(gè)功能或bug類(lèi)是由運營(yíng)提出的，大情景有不相同!
這又會(huì )有兩種情況，區分點(diǎn)在于運營(yíng)的關(guān)注度：
A類(lèi)：關(guān)注度高，比如要配合某個(gè)活動(dòng)或場(chǎng)景提出的功能，喵甚至會(huì )迫不及待的參與到測試和驗收的環(huán)節，以便有充足的時(shí)間做運營(yíng)相關(guān)準備
B類(lèi)：主要是收集到的BUG和優(yōu)化類(lèi)意見(jiàn)，說(shuō)運營(yíng)不關(guān)注也非，主要是喵們拋出各類(lèi)問(wèn)題后處于“記憶弱區”，在沒(méi)有遇到提出問(wèn)題的相應場(chǎng)景前，基本不會(huì )再次提出。
針對A類(lèi)，給予運營(yíng)更多的參與感，針對B類(lèi)，我的應對措施是：產(chǎn)品問(wèn)題記憶表
“產(chǎn)品問(wèn)題記憶表”
這是我在12.23收集的部分需求，在N次需求表迭代后，將字段分為以下維度：日期、提交者、類(lèi)型、緊急度、商業(yè)價(jià)值、描述、場(chǎng)景、可能原因、是否滿(mǎn)足、方案、完成時(shí)間、問(wèn)題、狀態(tài)。
這些應該根據每個(gè)公司不同的情況進(jìn)行字段的增加或減少，很多公司這份表格是直接由需求提出者填寫(xiě)的，有的是以卡片格式，有的則是通過(guò)郵件，方式不限，請找到最合適自己公司的操作方式。
做到記錄這一步還沒(méi)有結束，最重要的是跟蹤需求情況和反饋。若需求滿(mǎn)足，你就是這個(gè)需求的項目經(jīng)理，你需要負責跟蹤，需求因果后也需要通知喵們驗收和接受反饋意見(jiàn)(在一個(gè)階段后可增加“需求滿(mǎn)意度”)
若需求無(wú)法滿(mǎn)足，則需要給予對方不滿(mǎn)足的原因或者其他說(shuō)明。
第三點(diǎn)，故事描述
故事描述起先是產(chǎn)品經(jīng)理針對技術(shù)的一種功能說(shuō)明方式，因為思維方式的不同，普通的產(chǎn)品描述技術(shù)可能無(wú)法理解，那么就把他們帶入場(chǎng)景中，以用戶(hù)的視角去發(fā)現問(wèn)題和提出解決方案。
這一點(diǎn)同樣適合產(chǎn)品→運營(yíng)
故事描述的接受度和理解度遠超其他的描述方式，因此PM需要成為一個(gè)“有故事的人”。
以上三點(diǎn)其實(shí)都是個(gè)人在實(shí)際場(chǎng)景中遇到的問(wèn)題解決方式，由于在旅行，可能描述還不到位，觀(guān)點(diǎn)也更多的是針對小型或創(chuàng )業(yè)企業(yè)，成熟企業(yè)已有了規范的流程，運營(yíng)也具備能力和經(jīng)驗，所以不需要更多的擔憂(yōu)，而我們更多的是需要靈活，我見(jiàn)過(guò)有公司為了敏捷開(kāi)發(fā)甚至拋棄了產(chǎn)品原型和PRD文檔，除了團隊更多的都是產(chǎn)品經(jīng)理牽頭的溝通。
不同企業(yè)的問(wèn)題也會(huì )有不同的放大縮小，千萬(wàn)不要簡(jiǎn)單的套用其他團隊的溝通方式。
講人話(huà)，沒(méi)那么玄乎!講的是人、情、理，PM除了做好產(chǎn)品設計者和負責人，更是整個(gè)企業(yè)組織的銜接者、驅動(dòng)器。還需要更多的打開(kāi)、放低，因為你是整個(gè)組織的中心。
【產(chǎn)品經(jīng)理如何講人話(huà)？】相關(guān)文章：
產(chǎn)品經(jīng)理如何面對成熟產(chǎn)品后團隊成員缺乏初始的激情？07-11
產(chǎn)品經(jīng)理總結范文06-29
產(chǎn)品經(jīng)理述職報告06-09
創(chuàng )業(yè)者如何找合適產(chǎn)品經(jīng)理和技術(shù)合伙人？07-11