KANO模型,一個能解決你工作中90%煩惱的需求分析神器
只要你在企業工作,你多少會碰到以下幾種情況
產品經理:使用者一直強烈要求加上他們想要的功能,根本不知道先解決哪個?
研發兄弟: 產品經理提出一大堆需求,我就算天天007也做不完!
使用者:我要的根本不是這個功能!產品經理是用屁股在思考吧,會改成這樣??
其實在實際工作中,出現這幾種情況是太正常不過的事
每個使用者都會有自己的個性化需求,所以會想加很多功能
但這些需求中,80%都是偽需求,只有剩下的20%才是真需求
況且研發的資源和人力是有限的,不能什麼需求都做
所以產品經理就需要從這些需求中分辨出哪些是真需求,哪些是偽需求
那怎麼才能撈出真正的使用者需求?給真正重要的需求高優先順序?
今天要介紹的KANO模型分析法就是用來解決此類問題的
它可以對使用者需求進行系統分類和優先排序,將需求分成4種需求型別
它們的優先順序排序為:必備型需求>期望型需求>興奮型需求>無差異需求
- 必備型需求(一定要有) :俗稱痛點。對於使用者,是核心需求,也是產品必做功能。如果沒有,使用者滿意度則會大幅度降低。
- 期望型需求(應該要有): 提供此需求,使用者滿意度會提升;不提供此需求,使用者滿意度會降低。通常作為競品之間比較的重點。
- 興奮型需求(可有可無): 驚喜型產品功能,超出使用者預期,能帶來即時的新鮮感。但如果不提供,也不會降低使用者滿意度。
- 無差異需求(儘量不做): 使用者根本不在意,對使用者體驗毫無影響。規避做此型別功能。
簡單介紹完KANO模型的四個分類後,我們來舉個例子,來加深對KANO模型的理解。
KANO分析實戰
某網際網路公司的A產品將於下個月更新,產品經理小B收集到了無數產品功能更新需求,為了確定哪些功能是真需求,小B決定透過KANO模型進行需求分析。
本次分析實戰工具為BI工具 FineBI資料分析工具。
1、設計調研問卷
在做KANO分析前,需要進行使用者調研。通常採用矩陣量表的形式讓使用者對功能進行評價,評價分為五個程度“我很喜歡”、“它理應如此”、“無所謂”、“勉強接受”、“我很不喜歡”。
調研後需要對資料進行清洗,本案例清洗後的資料我放在文末了,需要的自取。
2、處理資料
(1)將清洗好的資料上傳至FineBI。新增自助資料集並勾選「KANO原始資料」的所有欄位
(2)新增列「合併態度」,將「增加功能態度」與「不增加功能態度」進行合併
按照使用者對「增加功能態度」與「不增加功能態度」,最終我們可以透過下表定位某功能對於使用者來說是什麼需求。
(3)上一步驟我們已經知道如何定位需求型別,接下來要做的就是在分析表中定位判斷
(4)新增「分組彙總」,得到每個功能它們各種需求型別的人數
例如參與調研的人數中,認為「功能1」是無差異需求的人數有 48 人
(5)因為調研過程中有些使用者會跳題,所以參與每個功能調研的人數有所不同。新增列「參與調研人數」,選擇「組內所有值」,如下圖所示,求出參與每個功能調研的人數。
3.分析結果視覺化
小B進入儀表板中,新建元件選擇剛剛處理過的自助資料集。
(1)複製 5 個「佔比」欄位
(2)對複製的「佔比」欄位進行明細過濾,過濾條件為:型別屬於 A 。並將其重新命名為「A 佔比」。
(3)使用 better-worse 係數
- better-增加某功能後提升的滿意係數:better=(A佔比+O佔比)/(A佔比+O佔比+M佔比+I佔比),越接近 1,則表示使用者滿意度提升的效果會越強,滿意度上升的越快。
- worse-不增加某功能使用者的不滿意係數:worse=-1*(O佔比+M佔比)/(A佔比+O佔比+M佔比+I佔比),越接近 -1,則表示對使用者不滿意度的影響最大,滿意度降低的影響效果越強,下降的越快。
根據以上灰字中的better、worse 的公式,新建計算欄位「better」「worse絕對值」
(4)選擇「散點圖」,拖入「better」、「worse絕對值」欄位。並將「功能」欄位拖入圖形屬性的標籤欄和顏色欄。
(5)分別新增「橫向警戒線」和「縱向警戒線」,分別為 better平均值 和 worse平均值。
4.分析結果展示
最終,小B做出瞭如下better-worse四象限分佈圖,決定此次功能更新增加「功能2、功能3、功能5、功能8」。有了資料支撐,大家都很認同他的決定。
以上就是KANO分析的全部過程,在實際工作場景中,情況更加多變,因此需理解KANO模型分析邏輯,提高工作效率。
原始資料及工具獲取方式:評論+私信回覆KANO
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/21472864/viewspace-2841038/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- KANO模型:產品人必懂的需求分析法模型
- 騷爆了... Go 錯誤處理中再套個娃,能解決煩惱不?Go
- 解耦解的早,改需求沒煩惱解耦
- 何爹瀏陽蒸菜—解決你開店的煩惱
- AJAX 是否能解決這個業務需求
- 一個比較麻煩的限流需求
- 重磅出擊!介面測試利器,為解決你的煩惱而生
- 80埠的煩惱
- 你還在為元件文件煩惱嗎?元件
- 一個實用的ASP分頁函式,解決你重複寫分頁程式碼的煩惱 (轉)函式
- 煩惱是人生的一部分——《少年維特的煩惱》讀書筆記筆記
- 基本操作能解決的問題,不必勞煩機器學習機器學習
- KANO模型(轉載)模型
- 工程師如何解決穿衣搭配煩惱?工程師
- Oracle效能解決的一個案例Oracle
- 免費API介面集合, 讓你的開發無煩惱API
- 生成劉海、調整發際線,讓你告別頭禿煩惱的竟然是AI「生髮」神器AI
- 一個抽獎專案的需求分析與概念模型模型
- 用Kano模型輔助產品功能決策模型
- 不用費勁,這5款效率工具為你解決學習工作煩惱
- GoPro無人機墜機問題已解決 一張膠帶解決煩惱Go無人機
- 高階設計總監的設計方法論——5W1H需求分析法 KANO模型分析法模型
- 擺脫詳情頁設計的文案排版困難!解決你的設計煩惱!
- 推動企業高效發展,免費OA辦公系統解決你的煩惱!
- 聽說你在為天天寫業務程式碼而煩惱?
- 六位一體Serverless化應用,幫你擺脫伺服器的煩惱Server伺服器
- 產品工作中保持飢餓感,保持拒絕90%以上的偽需求你就不會錯過下一個微信
- 軟體測試人員的煩惱
- RAG能解決大模型的什麼問題?不能解決什麼問題?大模型
- 2010.03.16專題:一個開發人員的專案煩惱
- 一鍵解決Android專案圖片壓縮煩惱,為apk瘦身!AndroidAPK
- 如何用極低成本解決網站託管煩惱?網站
- 贈送天翼雲電腦,解決一點園子的商業化煩惱
- 小程式名片,讓你徹底告別伸手遞名片的煩惱!
- 網際網路產品經理的三大煩惱,你有嗎?
- UNIX下檔案的刪除與回收-“ rm”煩惱的解決(轉)
- 需求分析與Y模型模型
- 程式設計師的十大煩惱程式設計師