關于產品需求階段的思維公式,都在這兒了

0 評論 7868 瀏覽 45 收藏 34 分鐘

編輯導語:需求是一款產品在開發過程中始終需要面對的重要因素,那么需求從哪兒來?在對需求進行分析時又有哪些誤區?本文作者對以上問題進行了解答,并且推導出了“需求”環節的思維公式。

前段時間,我跟幾位產品新同學討論一個問題,產品經理的職責是什么?大家七嘴八舌說了很多,有的說項目管理、有的說功能設計、有的說用戶調研,當然,這些都是,其中有個同學回答說:“做需求”,產品經理就是一個做需求的。

我就問他,為什么是做需求呢,他說每一個需求,都是以上這些內容的總和,每一個需求,都包含了用戶調研、功能設計、項目管理、資源協調,所以說,產品經理就是做需求的,這沒毛病。

可是,做需求只是表象,再往深了想,做需求,其實也是為了解決用戶或者客戶的實際問題。因此,我覺得說產品經理的職責是「解決問題」,更準確一點?!敖鉀Q問題”是產品經理的職責,“做需求”是產品經理工作的主要內容。

那我們就說說“需求”。

需求這個話題聊的人太多了,不少前輩、大佬、專家,都深入闡述過,產品新人入門導師蘇杰、劉飛、王詩沐、俞軍幾位老師,在他們的著作中,也用了大量的篇幅來講需求。站在前人的肩膀上,結合自己的一些思考,我也想同讀者分享一下,我對于“需求”的理解。

本文從需求的概念、需求的科學理論,到需求的來源,結合做需求過程中的常見誤區,最后推導出“需求”環節的思維公式。全文萬字,可能是非常完善的“需求”通識文章了,收藏轉發再細看。

一、需求是什么?

生活中,我們經常會有一些行為,這些行為背后,是因為我們有相應的訴求。

  • 臨近夏天,天氣越來越熱,走在街上,忍不住買一根雪糕;
  • 買了一屋子盲盒;
  • 認識到學習的價值,購買了很多付費課程。

以上三個案例,都是最后表現出來的行為。這種行為,分別對應著各自的訴求:買雪糕是因為熱,想要獲得降溫快感的訴求;買盲盒是滿足收集欲和好奇心的訴求;買課程是為了滿足提升能力、緩解焦慮,然后找到更好工作,或者升值加薪的訴求。

這個“行為背后的訴求”,其實就是需求。所以我們可以給需求下一個定義:需求是行為背后的訴求。

基于這個定義,我們可以發現,任何行業,其實都有需求的概念,需求這件事,不僅僅存在于互聯網產品上,其他的建筑行業、汽車行業、紡織行業等等,都同樣通過挖掘用戶背后的需求,來實現產品的創新和進步。

對應到產品經理的職業上,我們這個“做需求”,做的是什么“需求”?

產品經理成長過程中,一套思考的全流程,應該是:歸納現象-發現問題-拆解問題-分類問題-提出解決方案-回歸分析-發現新問題。簡化來講,就是:發現問題——歸納核心痛點——解決方案。

這其中的“解決方案”,就成了產品經理工作中所要完成的需求。這是產品經理接觸最多的工作內容,也是產品工作的核心。只有通過優雅高效的解決方案,才能真正解決用戶痛點,實現產品經理存在的價值。

二、兩個需求理論

正因為“需求”是一個常悟常新的話題,在綿延的歷史長河中,也有很多經典的、歷久不衰的需求理論。對于產品經理,有兩個非常經典的需求理論,就是“馬斯洛需求層次理論”和“KANO模型”。

馬斯洛需求層次理論就不用多說了,初高中的時候課本里就提到過。馬斯洛把一個人的需求分為生理需求、安全需求、社交需求、尊重需求和自我實現的需求。

一般來說,這五個需求映射到產品上,則越是金字塔底部的需求,需求面越大,但ARPU可能越小,比如肚子不餓的生理需求,10塊錢的炒粉就可以滿足。

KANO模型,是東京理工大學教授狩野紀昭(Noriaki Kano)發明的對用戶需求分類和優先排序的有用工具,以分析用戶需求對用戶滿意的影響為基礎,體現了產品性能和用戶滿意之間的非線性關系。

KANO模型把產品需求分成五類:

1. 基礎型需求

基礎性需求是一個產品最基礎的功能,這個需求不能夠被滿足,則產品就不能正常使用,比如IM軟件的打字聊天功能,美顏軟件的拍攝功能等等。

2. 期望型需求

期望型需求的效果,是讓用戶滿意度提升。比如微信聊天中的表情包,用戶期望有一種俏皮的、不局限于文字的聊天方式,表情包恰好滿足了用戶這一點。

3. 興奮(魅力)型需求

興奮型需求也稱為魅力型需求,是超出用戶預期的,讓用戶滿意度大幅提升的需求。比如微信的“拍一拍”和動態表情,用戶并沒有這個功能的預期,但微信做出來之后,大家也玩兒得不亦樂乎。

還有當年的微信紅包,用戶突然發現微信中就可以直接發紅包了,足不出戶,就能完成拜年互動,于是,一個春節,借著紅包的力量,微信支付一下子成為可以比肩支付寶的支付平臺。

值得注意的是,這五種需求類型,并不是一成不變的,隨著行業的進步,他們之間可能會發生轉變。比如微信紅包在剛推出時,屬于魅力型需求,但隨著紅包成為趨勢,用戶也要求其他社交產品做紅包功能,這就變成了期望型需求。

4. 無差異型需求

無差異性需求則是用戶并不在意的需求,無論有或沒有,用戶體驗都并不會產生較大的影響,用戶滿意度也并不會提高或降低。

做無差異性需求看似是一個雞肋的、無意義的行為,但在當下互聯網產品大幅度內卷的情況下,幾乎每個平臺類APP都在瘋狂堆砌這些功能,試圖搶占用戶時間——打車軟件做團購、團購軟件做打車、地圖軟件做購物、工具軟件做內容,這大抵就是做產品的岐路罷(當然,實際上也有公司戰略的考慮)。

5. 反向型需求

顧名思義,反向型需求就是做了之后,用戶體驗和用戶滿意度會下降的需求。在這里我忍不住要吐槽知乎,現在的知乎,充斥著各種小故事小短文,最關鍵的是,小故事讀著正爽,來了一句“最低0.3元/天開通會員,查看完整內容”,掐死知乎的心思都有了。

值得一說的是,現在的互聯網產品中,反向型需求一般是因為商業訴求同用戶體驗產生了矛盾,做產品是為了盈利,追求效益無可厚非,而產品經理,就要在商業訴求和用戶體驗中反復橫跳,做放縱與克制間的守夜人。

馬斯洛需求層次理論,說得是人性。KANO模型,對應著產品功能。這兩個理論經過多年的發展,其內涵已經足夠豐富,許多新的產品理論,也大多脫胎于類似的理念,異曲而同工。

這些“新產品理論”中,梁寧老師格外推崇的“痛點爽點癢點”理論,是非常熱門的概念。

  • 痛點是恐懼,上班馬上就遲到,遲到就要被扣工資,這時候地鐵口有一輛共享單車,非常及時地解決了即將遲到的恐懼,這就是痛點;
  • 爽點是即時滿足,周六的早晨一覺醒來已經是中午,依然不想起床,躺在床上動動手指,外賣就送到家門口,暫時的快樂得以滿足,這就是爽點;
  • 癢點是虛擬自我實現,看著直播里的小姐姐,甜甜地說giegie你好厲害,你立刻幻想到了迎娶白富美,馬上一個火箭送出去,這就是因為滿足了用戶對于自己的虛擬想象,最近特別流行的“頭上長攝像頭”短視頻,也是一樣的道理。

三、需求從哪兒來?

了解了需求是什么,也學習了關于需求的理論,作為一名產品經理,歸根結底還是要執行力。那落到操作層面,需求到底從哪兒來?

需求的來源有很多很多,我把它們先歸為兩類。一類是正經來源,另一類是不那么正經的來源。

1. 需求的正經來源

在我看來,需求的正經來源,只有兩個:用戶和數據。

1)需求來源于用戶

這是一句每個產品經理都信口拈來的話。產品的存在,就是為了解決用戶的問題,用戶所面臨的這些問題,肯定都得從用戶當中去發現。而對于產品來說,需求階段是整個產品生命周期中的孕育期,需求能否準確命中,決定著一個功能乃至一個產品的生死。

2)需求同樣也來源于數據

在數據時代的今天,每一個人都是數據大網下的一個節點,最關鍵的是,通過用戶的數據,能夠更好地發現用戶的群體行為,從而找準大多數用戶的真正需求。某種意義上來講,數據中找到的用戶需求,比直接和用戶訪談、調研得到的數據更真實。

為什么需求要來源于數據?是因為,“用戶”是會騙人的呀。業內有一個非常經典的栗子:

索尼要為一款即將面市的游戲機做一個調研,請了很多目標用戶來公司,收集用戶對于樣品的反饋,其中一項就是詢問用戶希望這款游戲機是什么顏色(有黃色及黑色),很多人在被問及這個問題時,都答了黃色,索尼就認為,黃色的游戲機更收歡迎。但最后,訪談結束時,索尼公司提出,用戶可以從門口隨意挑選一個顏色的游戲機帶走,以感謝他們參加此次用戶訪談,結果時候統計數據卻發現,用戶們在實際挑選時,紛紛選擇了黑色的游戲機。

用戶調研的需求具體生動,但有可能因為樣本太小并不真實;數據分析得到的用戶行為,樣本足夠統計準確,卻略顯僵硬并不鮮活。其實,在做產品需求的過程中,用戶和數據,都是為了更好地滿足用戶需要,應當兩種來源結合使用、交叉驗證。

用戶是微觀,定性;數據是宏觀,定量。

2. 需求的不正經來源

雖然嚴格來說,用戶需求都來源于用戶和數據,但其實在真正的產品工作中,也有很多需求是來源于其他渠道,畢竟生活和工作不可能時時刻刻都處在理想狀態。

我之所以稱它們為“不正經來源”,倒也不是說這些來源不好,而是表示,它們不像用戶和數據這樣“掉書袋”“科班理論”。

1)競爭對手

實際工作中,確實很多需求,都來源于競爭對手?!拔覀優槭裁匆鲞@個功能?是因為競品這么做啦!這個功能為什么這樣做?是因為競品就是這么做噠!”這種想法當然不對,但也不是說,做需求不能看競品。

相反,持續進行競品的監控分析,能夠獲得很多需求靈感,而且,競品的新功能也是在付出成本幫助我們去做驗證,如果效果OK,那我們去借鑒參考,也不是什么壞事。所以,需求來源于競爭對手,核心在于思考競品為什么這么做,我們可以從中學習什么優點,辯證批判地看待競品的動作。

2)產品經理拍腦袋

不得不說,挺多需求確實是拍腦袋拍出來的……原因挺多的,但也要盡量避免。

3)協同部門

尤其是體量比較大的產品,產品經理距離客戶/用戶的距離,其實沒有那么近,一線的很多用戶反饋,往往并不能直接傳達給產品團隊,大多數情況下,是銷售、客服、市場等協同部門的同事去響應。所以,協同部門就會定期向產品團隊反饋需求。

協同部門提出的需求,一般分為兩類,一類是“用戶希望怎樣”,一類是“我們(協同部門)希望怎樣”。

前者,是一線協同部門把用戶反饋過來的問題,傳遞給產品團隊;后者,則是一線部門為了自身的KPI或者工作量,而提出的需求,比如銷售部門為了更好的售賣產品,就會不斷反饋要求獲得產品中更多的入口、更多的彈窗。

針對協同部門的需求,產品經理要做的,首先是要分類整理,判斷哪些需求是產品真實存在的問題,哪些是協同部門對于產品規則理解不深刻的問題。針對用戶真實存在的問題,又要往深層次思考,用戶的核心訴求是什么,進而根據優先級,提出產品方案。

4)客戶直接提出的功能需求

有時候客戶或者用戶反饋問題時,會直接提出一些具體的功能建議:希望在XXX處做一個XXX功能。這個來源能夠收到的需求非常多,畢竟“人人都是產品經理”嘛,每個人都能對產品提點功能建議。

針對這種來源的需求,產品經理要做的,不是照單全收,而是得認真歸類分析,找到問題背后的真實來源,進而提出優雅的產品解決方案。用戶很熱,想買雪糕,但她正好在姨媽期,如果直接聽用戶的,就會導致她肚子疼,這個時候,產品經理可以帶她去吹空調,解決“熱”的問題。

“熱”是核心問題,“吃雪糕”和“吹空調”都是解決方案,選擇哪個解決方案,要結合具體的情況而定(風險提示:這里就是舉個例子,談戀愛不能太“產品思維”)。

你看,同樣是用戶提出的反饋,認真分析后找出需求,就叫用戶訪談,就是正經的需求來源;不加分析直接采用,就是不正經的需求來源,容易踩雷,你說有不有趣。

話說回來,這些不正經來源,其實深溯一下,很多也還是來源于用戶和數據。比如需求來源于競爭對手,其實只不過是競爭對手的產品經理完成了需求收集,這個需求,來源于競爭對手的用戶;需求來源于客戶的具體建議,那也是表達出客戶對于當前功能的不滿,這種不滿背后是什么樣的原因,這個原因就是真正的需求。

無論是需求來源于老板還是競爭對手,產品經理都應該想一想,這個需求到底是從何而來。老板提出了這個需求,那老板是出于什么樣的考量?看似降低了這一個小功能的體驗,但有沒有可能,是為了全公司戰略的聯動?競爭對手做了這個功能,有沒有可能這就是競爭對手的產品經理拍腦袋拍出來的,我們到底要不要跟進?

四、需求的誤區

既然明確了需求的來源,我們就可以推導出,一個需求的思維公式,從而快速準確地找到核心需求。但在歸納之前,我們不如先用一種逆向思維,來看看“需求”階段中的錯誤示范,五個常見的需求誤區,這能夠幫助我們更好的理解需求,避免走上彎路。

1. 誤區一:自己代表用戶

前段時間有一個問題討論得特別火,“產品經理要不要變成自己產品的用戶?”有正方認為產品經理只有是產品的核心用戶,才能更好地找到目標用戶的痛點;反方則認為,對于產品經理來說,冷峻理智地站在上帝視角,才是把產品做好的重要法門。

其實對于這個問題,往深層次思考其實是產品經理的同理心。

產品經理既需要客觀全面的看待整個產品,也需要瞬間把自己切換到用戶視角來提升體驗和發現漏洞,對用戶有同理心,能夠站在用戶的視角看待需求。產品經理本身就是這樣一個反復跳轉的角色,小白用戶、資深用戶、產品上帝、老板視角,等等等等,這些角色可能每天都要轉變幾十次。

用戶視角看產品,是發現產品問題的一個妙招,但過于依賴這個辦法,就會走火入魔。很多產品經理恰好是自己產品的受眾,這是一件非常幸運和幸福的事情,但這種情況下,就要格外注意,你要做的功能,是你自己的需求,還是用戶的需求?

在產品經理自認為自己是目標用戶后,往往會陷入“我自己就是用戶,我能代表目標用戶群體”這個死胡同當中。最后的結果當然是一場賭博,意外命中了群體需求,那就賺了;如果沒賭中,可能就是一個雞肋的功能,在后期做減法的時候痛不欲生。

這個誤區歸根結底還是需求調研不充分的問題,依賴主管臆斷,陷入經驗主義,導致需求偏向。

2. 誤區二:確定了產品強行找用戶

有人可能會覺得,這是一個很低級的問題,但就是這樣一個低級的問題,幾乎每時每刻都在發生。

理想主義的產品經理會以為,一個需求一定要來源于用戶痛點,但現實是,每天都有無數的產品或功能,是因為老板拍腦袋、公司要求強行創新、KPI壓力負重、業務戰略需要、圓之前融資畫得大餅,而匆匆上馬的。

我之前做過一個產品,是因為老板覺得小眾音樂在未來很有市場,應該做一個產品提前占位,就立項了一個創新項目。先定了小眾音樂這條賽道,才開始想滿足什么需求,甚至才開始為了這個已經定好了方向的項目招聘產品經理。

但現實情況是,產品的痛點和需求并非源自實際的用戶群體,只能根據競品先做了一些功能,然后開始想,哪些用戶可能喜歡這些功能,這樣倒推回來,確實能夠找到一個差不多的目標用戶群體寫在MRD、PRD里。但事實呢,這些“先有了功能后定下來的目標群體”本身沒有任何的動力使用產品。結局自然是可預料的,公司砸錢砸出來幾萬用戶,補貼一停用戶就流失,產品就這么不了了之,后來業務調整裁撤了。

需求還是一定要來源于用戶的,即使是來自老板的要求,也得在公司戰略和用戶痛點當中盡力周旋,先有需求后有產品,這個順序不能亂。

3. 誤區三:只抓住表象,不能深層次思考需求背后的動機

在拿到一個需求時,我們要思考,這個需求深層次的動機是什么。

我剛做產品的時候,經常會被用戶提得反饋牽著走,用戶經常會說,“這個功能有問題,應該這樣做那樣做”,我一聽還覺得挺有道理,就被帶跑了。但其實不應該這樣,用戶或者老板在提出一個需求的時候,我們要深層次地想一想,他們為什么提出這個需求,是有更多的期待沒有被滿足,還是這個功能的流程邏輯有漏洞。

用戶的需求反饋往往帶著主觀的影響,一些有想法的用戶在提反饋的時候,也會帶上一個設想的解決方案,畢竟“人人都是產品經理”,但作為職業的產品經理,還是要理智地思考思考,把需求背后的動機挖掘出來,才能解決更核心的問題,才能提高更多用戶的體驗。

之前在寫互聯網銷售的文章中,我引用過“賣鉆講孔”的故事,其實這個故事是從王詩沐老師的《幕后產品》中學到的。

客戶要買一個鉆頭,我們應該看到他買鉆頭是想打一個孔,他的真正需求是打孔,我們如果能夠給他提供一整套打孔的解決方案,是不是更加符合客戶的心意?這樣深挖需求動機的思考,是職業產品經理所不能繞開的。

4. 誤區四:以偏概全,以孤例代表整體,陷入小眾用戶的自我束縛

對于產品經理來說,因為產品要服務的用戶很多,即便都是同一類目標用戶,也會因為用戶的圈層而產生需求的差異。產品經理不可能面面俱到每一個用戶,因此就必然要在功能上予以取舍。

小眾用戶的需求是需求嗎?當然是,即使是小眾的需求,也應當納入產品經理的需求池當中。

但是否要做、什么時候做、怎么做,這三個問題還是要想清楚。相對于“自己代表用戶”這個誤區,小眾需求確實是命中了需求,但小眾需求無法與大眾市場相連接,從更宏觀的視角來看,性價比并不高。

做一些小眾需求,的確能夠產生比較不錯的口碑,但把過多的精力和資源放在小眾需求上,某種程度也是在傷害主流用戶的體驗。需求的把握同樣需要遵循二八法則,即優先滿足80%用戶的主流需求,優先考慮更大眾化的痛點,保證大多數用戶的體驗。

至于小眾需求怎么處理,有兩種思路。一種是先暫時延期,等到大眾需求基本滿足,產品主流用戶增量見頂,開始尋找額外增量的時候,通過滿足小眾群體的需要,來尋求產品突破點;另外一種則是找到小眾需求和大眾需求的相通之處,深入挖掘深層次需要,既提高了主流用戶的體驗,同時也用一種更加優雅的方式解決了這些小眾需求。

5. 誤區五:需求確實存在,但不符合產品整體目標

我們常說產品經理是CEO的預科班,做一家公司,必須要明確公司的目標、愿景,對于一個產品來說,思考它的整體目標是一件至關重要的事情。

正如前面所說,產品經理會面臨各種各樣的需求,有真需求、有偽需求,有大眾需求、有小眾需求,有商業需求、有性能需求,面對這么多需求,如何取舍如何排序就是一個關鍵的問題。

對于這些數不清的待辦需求,產品經理要做到心中有數。需求池當中的這個需求,能否在產品長期目標的主線上發揮作用;如果需要開啟一個支線的產品目標,那這個支線的投入和產出又是如何。產品經理不僅要為用戶體驗負責,也需要對產品良性發展負責。

可能會有同學說,思考產品長期目標是產品總監的事情,新手期產品經理做好自己的事情就可以了。但其實,即使初級產品經理沒有權力做出產品目標的相關決策,至少也可以把自己放在更高的視野做做沙盤推演,學會用更大的視野思考整條業務線的宏觀目標,對于一個產品經理的成長,會非常有幫助。

五、需求的思維公式

我們根據需求的定義、來源、誤區,可以抽象出需求的思維要素。我給出這樣一個公式:需求=目標人群+場景+痛點/問題+解決方案

一個完整的需求,應當是有特定的目標人群,在特定的場景下,發現特定的問題,并提出針對這個問題的解決方案。

任何一個需求,都不能脫離這四個組成部分。

1. 目標人群

目標人群代表著“什么人”的問題。任何一個產品,都一定是面向某一個群體,而不是面向所有人,因為人和人的訴求,不可能完全一致,會因為性別、年齡、學歷、收入水平、從事行業等許多因素,產生差異。因此,一個需求面向的人群一定是有一個范圍的,比如“找互聯網工作的人”“騎行愛好者”等等。

2. 場景

即使是圈定了目標人群,也并不能說,這個目標人群的用戶群體在任何時刻都存在這個需求,場景就是“什么時候”有這個需求。就以打電話這個需求為例,打電話是“需要和他人遠程溝通”這個場景下的訴求,其他時候,用戶是不需要打電話這個功能的,我們不能苛求用戶所有時刻都在打電話。

場景還有一個重要特性,就是用戶具體怎么使用這個功能。比如用戶在支付時進行掃碼,就是在“支付”場景下,用了“掃一掃”的功能。

有時候,用戶天然產生的場景不夠多,那我們就可以創造場景,比如支付寶為了更多的使用場景,投資了哈羅單車,提供了支付寶直接掃碼就可以騎車的功能,于是,就創造出了一個新的使用支付寶掃一掃的場景。

3. 痛點/問題

明確了目標人群和場景,還要知道,這一些人 在 這個場景 下,遇到了什么問題,只有把問題找準了,才不會馬屁拍在馬蹄子上。

比如:西二旗上班的白領(目標人群),出了地鐵口距離公司還有一公里,馬上就要遲到了(場景),走路來不及,打車打不到(遇到的問題)。這個時候,幫助用戶快速到達公司不至于遲到,就是要解決的問題。

4. 解決方案

找到了問題,那就要提出需求中最核心的“解決方案”,產品終歸是要解決用戶問題的,要不然,找到了一堆問題,一個都不解決,那依然沒什么用。這一群人,在這個場景下,遇到了問題,你打算用什么方法解決。

值得注意的是,解決方案不一定有一個,而且大多數情況下,是有多個。產品經理就要在這多個解決方案中,找到最合適的那個。

還是白領遲到這個例子,最后一公里,走路來不及,打車打不到,我們可以給一個共享單車的解決方案,也可以給通勤擺渡車的解決方案。分析之后發現,上班高峰容易堵車,擺渡車依然有遲到風險,所以,最后給用戶提供了共享單車的解決方案,幫助用戶解決了問題。

一般情況下,大部分需求,都可以用這個思維公式進行提煉。但任何產品理論都是教科書式的知識,在實際工作中,還是要靈活應用,具體問題具體分析。

以上,就是關于“需求”模塊下,我的總結、分析和思考,逐漸形成的一點小體系。但依然不夠完善,我也會在后面的工作中,持續反思完善。

 

作者:亨哼,95后互聯網產品經理;微信公眾號:產品變量(ID:hengpaper)縱觀TMT風云,解構產品思維。

本文由 @亨哼 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Pexels,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!