不做沒有需求的產品經理

0 評論 506 瀏覽 6 收藏 12 分鐘

想要產出一份合格的PRD,我們需要經過發現問題、分析問題以及解決問題的三個階段。其中,發現問題可以理解為發現需求。如何收集需求?本文作者總結了3個方法。

不知從什么時候開始,“方法論”一詞開始給人一種假大空的感覺,許多人談到方法論,言必稱賦能、抓手、組合拳…但拋開這些略顯過時的互聯網大詞,“方法論”還是有其積極意義的。本質上說,方法論就是指導我們工作或解決問題的指導性原則,好的方法論能讓我們事半功倍。因此,在做了幾年產品經理之后,我也試圖總結出一套自己的產品工作方法論,并以此為綱,時時檢驗自己的行為是否脫綱越界。

產品經理的工作技能可以分為硬技能和軟技能。所謂硬技能,是指工作中有清晰的指標并可以被觀察和量化的技能,它可以帶來具體的產出。對于產品經理來說,這種產出通常是指一份合格的PRD。

想要產出一份合格的PRD,我們需要經過發現問題、分析問題以及解決問題的三個階段。這篇文章,我們先來談談如何發現問題。

發現問題可以理解為發現需求。產品經理的工作都是圍繞需求展開的,沒有需求的產品經理是岌岌可危的。因此,收集需求就是我們最先要做的事。如何收集需求,這里我總結了三個方法。

一、建立信息獲取渠道

最常規的信息獲取渠道就是收集用戶問題反饋的聊天群。對于B端產品經理來說,如果做的是企業內部系統,那么就需要針對在使用你所負責的系統的同事,建立一個問題反饋的聊天群。通過這個聊天群,你可以第一時間知道用戶遇到了哪些問題。

當然,也可以主動一點,詢問用戶對于某些功能的使用感受,引導他們說出內心的真實想法。如果做的是saas系統,則每個客戶都需要一個問題反饋群,這種聊天群一般會由實施團隊去建立,由他們將問題或需求反饋給產品經理。

另一個渠道就是在系統內上線一個問題反饋入口。這幾乎是所有的saas系統都會有的基礎功能,它可以在更大的范圍內收集到用戶遇到的問題或是訴求。在這個反饋平臺上,產品經理最好是能夠定期回復用戶的反饋,以避免用戶覺得反饋的問題石沉大海。這樣可以鼓勵用戶更積極的反饋問題,也可以讓我們更加直接的感受到用戶在碰到問題時的情緒,以便我們更好的理解某個具體的問題。

再來就是問卷調查。這是效率比較低的一種獲取信息的渠道,一般是新系統/功能上線一段時間后為了評估大部分用戶對于新系統/功能的整體使用感受時會采用這種方式。問卷設計最重要的一點就是對于問題的描述要采用中立的語言,避免引導用戶做出不夠客觀的答案。相對來說,用戶調查需要用戶付出的更多的時間成本,為了收集到更多的有效反饋,設置一個小獎勵給到完成問卷的用戶效果會更好。

最后就是客戶走訪。這是成本最大的一種方式,也是效果最好的一種方式??蛻糇咴L可以讓我們當面看到用戶是如何在使用系統,這很可能與我們的設想并不相同。完成相同的目的,你可能知道更便捷的操作,但是客戶往往還在使用更繁瑣的操作,為什么呢?也許是他不知道便捷操作;也許是他更熟悉老辦法,不愿做出改變;也許老辦法有額外的作用等等…這些問題的答案,往往只能在客戶走訪之后才能知道。

二、數據洞察

對于產品經理來說,我們除了要學會傾聽用戶,也要學會傾聽系統。系統的反饋就隱藏在數據之中,不同于用戶,系統從不說謊。

對于核心功能,我們需要每天觀察它的數據波動,一旦波動超出正常范圍(這個“正常范圍”需要通過過往的正常數據來測定),我們就需要去搞清楚發生了什么?通常一個指標出現了異常波動,我們可以先分析其上游功能的數據變化情況。

比如我們觀察的指標是gmv,那么gmv突然升高,我們可以往前看下單頁面的“訪問人數/人次”、“下單人數/人次”、“轉化率”等,不同數據的變化所反映出的事實是不一樣的。比如是訪問人數突然變多,那是不是因為開辟了新的獲客渠道?這可以通過對“訪問用戶”的來源做進一步的分析而知道。比如訪問人數不變,但是下單人數突然變多,那合理的猜測就是當前產品在做活動。

當然也不排除系統出現漏洞,有用戶在薅羊毛??傊?,盡快搞清楚發生了什么對于產品經理來說很重要,我們是產品的第一責任人,產品的任何異常我們都應該最先知道,以便及時作出應對之策。

數據洞察的另一個現象是“預期違背”,這通常在新功能上線之后發生。比如,我們給系統做了一個新首頁,同時也保留了進入舊首頁的入口,我們的預期是80%以上的用戶會使用新首頁。但是上線之后的數據告訴我們,只有50%的用戶選擇使用新首頁,這就是“預期違背”。通常出現這種狀況,我們需要行動起來,找到典型用戶聊一聊,問問他們為什么更喜歡老功能。而在這個過程中,往往是能夠挖掘出有價值的需求的。

三、戰略規劃

前兩種方法屬于自下而上推進需求落地的工作方式,更多依賴于產品經理個人的主觀能動性,而第三種方法則更多是自上而下的方式,更考驗產品經理對于業務的理解程度和對目標的拆解能力。

產品經理在接到戰略類需求時往往是公司在規劃年度OKR或季度OKR的時候。由于OKR是自頂向下層層傳導的,每一個產品經理都需要和自己的上級對齊年度或季度最重要的幾件事,上級也會向更上一級對齊,直到老板,這就有效保障了公司自上而下目標的一致性。

對于B端產品經理來說,不光要和自己的上級對齊目標,也要和自己關系最緊密的業務部門負責人對齊目標。因為向上看,產品和業務的目標必然是會交匯的。對齊目標是簡單的,但更重要的在于,如何將上級或業務部門的目標轉化為自己的todo。這里我經常用到的辦法是:先窮舉實現目標可以采用的辦法,再篩選出哪些辦法是在系統層面能實現的,最后再和業務部門溝通選出ROI比較高的1個或幾個作為接下來的todo。

這里我們以拆解業務目標來舉個例子,比如業務側第一季度的某一個目標是:激勵線下代理商,完成代理商側有效拉新同比去年一季度有30%的增長。

這個目標的關鍵信息是什么?是“激勵線下代理商”,驅動他們去做拉新。理解了目標之后,第一步,先窮舉出實現拉新增長的辦法:1、做拉新排行榜,并以排名結果給代理商激勵,刺激他們多做拉新動作。2、做輔助拉新的工具,用來增強代理商日常觸達用戶的能力,比如crm工具或者企微等。3、配合營銷節奏做一些拉新活動,幫助代理商更容易完成拉新。4、廣告投放,將更多的流量引導到線下。5、通過招商,引進更多代理商來達成這一目標。

第二步是篩選出哪些辦法是我們(產品經理)可以去做的,在這個例子中,很顯然前三個是合適的,后兩個辦法通常是業務側自己應該去做的嘗試。

最后,具體做什么,這需要產品經理和業務部門進行深入的溝通,決策的基礎就建立在對業務的足夠了解上。產品經理做出的系統需要業務部門的使用和推廣才能發揮作用,因此目標一致是產品成功的前提。

以上就是發現問題或者說收集需求的三個方法,通過建立信息獲取渠道、數據洞察和戰略規劃,相信每一個產品經理都能收集到足夠多的需求。

但是,光有需求是不夠的,哪些需求該做,哪些不該做,該做的需求應該什么時間去做,應該做到什么程度,這些對于產品經理來說,是更為重要的。美團的王慧文曾經說過,看一個產品經理是否入門,就看他知不知道哪些需求不該做。要做出這些判斷,依靠的是產品經理對于問題的分析能力,那么下一篇,我們就來聊聊如何分析問題。

本文由 @言歸鄭傳 原創發布于人人都是產品經理。未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!