一個會“講人話”的產(chǎn)品經(jīng)理有多重要
常聽到有人講了幾十分鐘的理論,卻被一句:說人話!給嗆住。以前這個場景多是“技術(shù)-產(chǎn)品”,現(xiàn)在更多的是“產(chǎn)品-運營”。原因如下:
- 大部分的技術(shù)由產(chǎn)品對接,運營更多的是面對產(chǎn)品
- 邏輯思維的不同,產(chǎn)品思維是多個視角的出發(fā),結(jié)合了產(chǎn)品邏輯、業(yè)務(wù)形態(tài)、商業(yè)前景等等。而運營則是更多價值的聚焦,包括某個活動、某個場景、人群、需求等。
- 產(chǎn)品經(jīng)理是自負的,這在創(chuàng)業(yè)公司更常見,也是因為對應(yīng)的運營還沒有足夠經(jīng)驗。
- 具象化視角的不同,這和邏輯思維又不一樣,比如:
喵:國慶節(jié)想要增加特殊化標(biāo)簽,增加用戶活躍度
狗:特殊化標(biāo)簽有哪些形態(tài)?應(yīng)用場景什么?預(yù)計會增加多少日活?時間點是什么?有沒有考慮過用普通標(biāo)簽滿足需求?那為什么不把普通標(biāo)簽一起優(yōu)化呢?
喵:。。。說人話
往往就沒有了然后!
這應(yīng)該是每個產(chǎn)品經(jīng)理都會遇到的問題,因為產(chǎn)品經(jīng)理本身賦予了更多的使命,去思考的更多、構(gòu)架的更多,且要擔(dān)任運營與技術(shù)的需求潤滑劑。篩選需求、完成需求、計劃需求!
產(chǎn)品經(jīng)理如何講人話?
首先從產(chǎn)品的迭代講起,產(chǎn)品迭代涉及了需求收集、需求分析、產(chǎn)品定稿、需求評審、里程碑、測試驗收、產(chǎn)品發(fā)布等等。發(fā)現(xiàn)其中運營僅在第一步“需求收集”中占有角色,而需求的來源包括了:用戶、運營、產(chǎn)品、BOSS等。
早期的創(chuàng)業(yè)公司總是產(chǎn)品先行,在發(fā)展到一個階段后再由運營去驅(qū)動,所以每次迭代通常是一個大功能+用戶小需求和優(yōu)化。
在技術(shù)、測試完成后,我們通常會召開內(nèi)部的“產(chǎn)品發(fā)布會”,在大號電視前演示迭代增加和優(yōu)化的功能,發(fā)布會總是很成功的順利舉行?。?!
產(chǎn)品上線后,PM又開始了新一輪的需求收集,而喵們也開始運營當(dāng)前的產(chǎn)品功能(產(chǎn)品運營),但總發(fā)現(xiàn)運營對產(chǎn)品的功能不了解,在運營過程中還會反復(fù)的詢問產(chǎn)品!
當(dāng)時很無奈,應(yīng)對的措施是:針對每一版本迭代去更新“產(chǎn)品運營規(guī)則說明文檔”,我記得當(dāng)時后臺的一份文足有8000字,之后發(fā)現(xiàn)效果還是不行,索性將需求文檔(PRD)也抄送給運營。再之后我們開始邀請運營一起參與到需求評審中!
直到。。。
“能不能說人話!”
什么是人話?
我自己也思考了很久,也和BOSS溝通后得出以下幾點:
- 運營需要背負自己的責(zé)任,產(chǎn)品不應(yīng)該處處領(lǐng)先運營
- 不把運營當(dāng)baby,盡量的等量
- 運營是產(chǎn)品,產(chǎn)品即運營
我更換了和運營溝通的方式并做了更多的交流,舍棄“產(chǎ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)化
在事后做了進一步的溝通和對比,發(fā)現(xiàn)運營對這樣的操作接受度和興趣度更大,再加上驗收時邀請運營參與也會增加運營的興趣度和對功能的理解。
當(dāng)運營提出需求時
這些是針對非運營提出的需求對其的影響力,如果一個功能或bug類是由運營提出的,大情景有不相同!
這又會有兩種情況,區(qū)分點在于運營的關(guān)注度:
A類:關(guān)注度高,比如要配合某個活動或場景提出的功能,喵甚至?xí)炔患按膮⑴c到測試和驗收的環(huán)節(jié),以便有充足的時間做運營相關(guān)準(zhǔn)備
B類:主要是收集到的BUG和優(yōu)化類意見,說運營不關(guān)注也非,主要是喵們拋出各類問題后處于“記憶弱區(qū)”,在沒有遇到提出問題的相應(yīng)場景前,基本不會再次提出。
針對A類,給予運營更多的參與感,針對B類,我的應(yīng)對措施是:產(chǎn)品問題記憶表
這是我在12.23收集的部分需求,在N次需求表迭代后,將字段分為以下維度:日期、提交者、類型、緊急度、商業(yè)價值、描述、場景、可能原因、是否滿足、方案、完成時間、問題、狀態(tài)。
這些應(yīng)該根據(jù)每個公司不同的情況進行字段的增加或減少,很多公司這份表格是直接由需求提出者填寫的,有的是以卡片格式,有的則是通過郵件,方式不限,請找到最合適自己公司的操作方式。
做到記錄這一步還沒有結(jié)束,最重要的是跟蹤需求情況和反饋。若需求滿足,你就是這個需求的項目經(jīng)理,你需要負責(zé)跟蹤,需求因果后也需要通知喵們驗收和接受反饋意見(在一個階段后可增加“需求滿意度”)
若需求無法滿足,則需要給予對方不滿足的原因或者其他說明。
第三點,故事描述
故事描述起先是產(chǎn)品經(jīng)理針對技術(shù)的一種功能說明方式,因為思維方式的不同,普通的產(chǎn)品描述技術(shù)可能無法理解,那么就把他們帶入場景中,以用戶的視角去發(fā)現(xiàn)問題和提出解決方案。
這一點同樣適合 產(chǎn)品→運營
故事描述的接受度和理解度遠超其他的描述方式,因此PM需要成為一個“有故事的人”。
以上三點其實都是個人在實際場景中遇到的問題解決方式,由于在旅行,可能描述還不到位,觀點也更多的是針對小型或創(chuàng)業(yè)企業(yè),成熟企業(yè)已有了規(guī)范的流程,運營也具備能力和經(jīng)驗,所以不需要更多的擔(dān)憂,而我們更多的是需要靈活,我見過有公司為了敏捷開發(fā)甚至拋棄了產(chǎn)品原型和PRD文檔,除了團隊更多的都是產(chǎn)品經(jīng)理牽頭的溝通。
不同企業(yè)的問題也會有不同的放大縮小,千萬不要簡單的套用其他團隊的溝通方式。
講人話,沒那么玄乎!講的是人、情、理,PM除了做好產(chǎn)品設(shè)計者和負責(zé)人,更是整個企業(yè)組織的銜接者、驅(qū)動器。還需要更多的打開、放低,因為你是整個組織的中心。
記住,PM無處不在!
本文由 @青團社-強子 (微信GXQ22222)原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?,未經(jīng)許可,禁止轉(zhuǎn)載。
產(chǎn)品都是自己的101忠狗
人人都是自己的產(chǎn)品經(jīng)理~哈哈