數據產品經理如何避免成為需求傳聲筒?
對于從數據開發轉向數據產品經理的職場人士來說,需求挖掘和產品思維往往是他們的短板。本文將深入探討數據產品經理如何通過刻意訓練產品思維、優化項目管理流程和推動產品落地,避免成為簡單的需求傳聲筒,提升自身的產品能力。
最近給幾位數據開發轉數據產品經理的同學做相關輔導,發現研發轉產品在需求挖掘和產品思維方面普遍是短板。對于研發轉產品順利上岸后,如何才能提升產品能力呢?
一、首先是關于產品思維的刻意訓練
數據產品經理畢竟也是產品經理,所以不管數據基礎怎么樣,掌握產品的流程化思考方式,開展工作會更加順暢。雖然說產品思維這個詞非常老套了,但它的確是會指導你開展工作的通用方法。這里講的產品思維是作為產品經理的一種思考方式,工作流程和方法論。比如,初入職場,當你還沒徹底搞懂什么是指標和維度、數倉模型、字段時,就被安排去承接業務的數據報表需求了,你準備怎么去做呢?
1.學會用產品經理的思考方式去做需求
產品經理的主要職責就是每天對接和處理各種各樣的業務需求。拿到新需求,怎么做?
(1)為什么要做這個需求
充分了解已有的背景信息,有的老板常提一句話需求,因為自己不懂而不敢去問,吭哧吭哧做完了老板說不是自己想要的,耽誤了時間,出力不討好。
(2)用戶是誰?
每一個產品都有明確的用戶群體,數據產品也不例外,而且相較于C端產品的普適性,數據產品的用戶還要做個三六九等的劃分,誰是核心用戶,誰是覆蓋用戶,誰是潛在用戶?
(3)解決什么問題
作為新人肯定對業務了解不深,知道了用戶是誰了,結合有限的背景信息,這個時候就要充分發揮產品經理的溝通天賦了,找業務溝通調研其工作內容,遇到了哪些痛點和問題,期望這個數據產品解決什么問題。
(4)需要什么功能(指標和維度)?
對于偏工具類的數據產品,如CDP、大數據開發平臺等,一方面是結合對用戶的需求場景的調研確認目前他們的訴求,另一方面是結合競品分析,確定產品的功能規劃。很多新人往往只是按需實現需求,而在高階產品的成長道路中,產品規劃能力是明確要求的能力維度。所謂的產品規劃,主要就是結合產品的定位,確定產品要包含哪些功能要點,再根據當前業務痛點,確定各個功能的優先級,形成短中長期不同版本迭代的計劃或者roadmap。然后明確的告訴老板說,我們這個產品要包括ABCDEF的功能點,但是考慮開發資源和時間現狀,MVP版本優先做ABC功能。
關于需求分析的模型與方法論有非常的多,看些文章了解下四象限、ICE排序、KANO模型就可以了,重要的是要把需求處理的流程先固化下來,然后拿著工作中的具體的需求實踐總結,有人說產品經理能力的高低和悟性有很大關系,這個悟就來自于不斷的實踐和刻意的復盤總結。紙上得來終覺淺。
二、其次項目管理推動產品落地流程和方法
在敏捷項目管理理論當中,把70%項目失敗的問題歸結為流程的問題。經過多年的實踐發現的確是這樣。因為產品經理是依賴于他人完成產品方案的落地。協調和管理跨職能的項目團隊是日常工作的重點之一,否則設計的方案再好,上不了線也是尷尬,沒有業務價值的輸出。
在項目管理領域有專門的PMP或者敏捷開發的ACP認證。所以想要完全學習完所有內容還需要花很多時間的。但是掌握最核心的流程和要點就足夠日常使用,加上自身項目的實踐總結,沉淀出適合自己的項目管理方法。
1. 如何管理需求
面對各個業務部門的各種數據、產品需求,要避免忙成陀螺但還被業務吐槽。所以,要學會利用需求管理工具,把接收到的需求統一管理起來。很多項目管理軟件比如Trello、Ones、leangoo等,最次的就是自己用excel了,團隊共享不太方便而已,但自用足夠。目標是自己清楚地知道有多少需求待處理,優先級是什么,何時需要找業務溝通確認,已經排期或者上線的需求定期做好信息反饋,避免等著業務來問排期。出現延期更要做好溝通,這樣才會成為業務眼中靠譜的人。而不是提了需求石沉大海。
2. 怎么跟項目?
產品一旦排了開發資源后,就是日常的項目管理和開發跟進工作了。澄清需求幾乎是每天都會遇到的,除此之外。要學會在一些關鍵節點組織會議,并且利用透明的力量同步項目進度、問題及風險。
3. 項目啟動會
重大項目需要單獨召開啟動會,務虛為主。主要目標是獲取授權,搶占資源,有時需要打雞血,比如這個項目是公司戰略重點,多跟開發“洗洗腦”,做好了大家一起吃香喝辣。
4. 需求評審會
產品經理不得不開的會議包括:和業務的需求確認會,和開發的方案評審會,和團隊的需求排期會。很多產品經理最怕開需求評審會,因為怕被老板、被開發、被業務Diss。首先從心態上,要做好準備,評審會的目的就是要找出需求不明確和不合理的地方,在方案環節盡可能考慮周全,避免上線之后不滿足需求,如果評審會一團和氣,出事后甩鍋于事無補。其次,要在每一次被Diss之后做好總結,為什么我設計方案的時候沒有想到,沒有想清楚。下次要盡可能規避,就像高中時有些數學題經常有陷阱,有了錯題集不斷強化后,下次就不再犯同樣錯誤。此外,在產品方案設計環節,可以提前和業務溝通,和開發提前討論技術方案,問題前置化,減少評審會上的問題數量。最重要的一點,就是自己在設計產品方案和PRD時,要不斷問自己問什么需要這個功能,這個按鈕,為什么放到這里,而不是其他位置,自己先Diss自己,減少被別人Diss。知彼知己百戰不殆,還要吸收競品分析的結論,有的時候你的一句,這個方法競品是這樣做的,但是有123個問題和缺點,是不是比其他的解釋更有說服力呢。最后,能用數據量化分析的就要用數據說話,畢竟是搞數據的嘛。
5. 項目站會&周會
敏捷開發中,團隊成員會有每天的站會,主要目的是溝通和澄清問題,說下主要進展和計劃,提高團隊成員溝通的頻率,互通有無,及時發現和解決問題。切記不要淪為形式。
6. 項目匯報的頻率與技巧
常規匯報:對于重點項目(老板們都非常關心)尤其要做好向上的匯報和信息同步。如果周期2周內,可以每天匯報關鍵進展,IM群或者郵件均可。3周及以上的長周期項目至少要按周匯報。這樣老板就很放心,不管他關不關注,至少你主動溝通,不僅曝光度高,而且老板會覺得你非??孔V。
問題匯報:做項目有風險在所難免,尤其是項目初期不確定因素非常多,出了問題首先自己要快速搞清楚大致問題,初步判斷嚴不嚴重,如果覺得對項目進度、項目范圍有影響,就要及時向上反饋,老板最不喜歡的就是別人都知道出問題了,他卻是最后一個知道。提前溝通可以獲取相關的資源支持,哪怕是準許延期的許諾。
7. 需求變更管理
唯一不變的就是變化。作為產品經理不管是和業務還是和研發溝通,切記一句話的口頭需求和隨意的變更。尤其是開發過程中,涉及到業務流程等內容的變更一定要記錄存檔,對主流程和研發進度有影響的,嚴格遵循變更控制流程。否則,一旦項目失敗或者出了問題,產品和開發扯不清楚。研發說產品讓我這么改的,產品說我是讓你那么改的。
8. 產品上線運營及推廣
項目測試開發工作完成后,在正式上線之前,找核心用戶或需求方做好用戶接受度測試,避免上線后,用戶大面積吐槽,到時候就晚了。另外,產品上線前,需要考慮數據埋點,統計功能上線后的使用效果。一方面是證明你這次迭代的價值,用數據說話,另一方面就是用數據驅動產品迭代了。同時,要記得收集用戶的正向反饋,畢竟季度述職有的時候需要用戶視角說你做的好不好。
三、總結
想成為業務、研發眼中優秀的數據產品經理并不容易。不僅要產品素質優秀,還要有扎實的數據能力。具備其一,可以做數據產品經理,但只能稱之為靠譜或者技術能力比較強。而兩者都不具備時,不僅自己上班如上墳,還要飽受領導、對接研發、業務的各方吐槽和Diss。
本文由人人都是產品經理作者【數據干飯人】,微信公眾號:【數據干飯人】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議。
“需求傳聲筒”,誰被戳到痛處了,是我….真得改變一下了
需求評審會是產品的每一次考試
就建群了唄,有需求,有端口,直接在群里說,別把信息來回傳!