我的產品方法論
我的產品方法論
產品階段區分
從0開始立項
已有完整產品,新需求開發
產品型別
C端:工具型、社交型、內容型、社群型(UGC)、電商類、預定類(酒店)
B端:各行業SaaS系統、ERP、WMS、PMS、DSP、OA、政務系統、企業建站、B2C、B2B
複合型
產品形態
純線上產品:在劃分行業的情況下是解決某個行業使用者的效率或改造的問題,不劃分行業的情況下是解決使用者普遍的痛點、社交或效率問題
線上+線下:判斷在該行業利用網際網路產品實現的是提升效率,還是通過網際網路創新改造商業模式
結構化思維的重要性
每個人做的產品不同,面對行業不同,接受的資訊不同,會形成不一樣的方法論,不能一概而全。所以不管是誰的方法論,對自己都不會完全適用,只有自己從0到1真正多次經歷,才會有自己成熟的思考方式。
方法論說到底,其實是結構化思維,方法論不能適合所有人,也不能適合所有產品,但結構化思維可以。
C端B端,抑或純線上還是線上+線下,這裡的組合再搭配行業,會有各種各樣的產品,沒有哪種方法論是適合所有產品,特別是情況特殊的B端,以及線上+線下的產品。結構化思維就能提煉一些需要重點思考的問題,放到整個產品流程中,確保產品的正確方向。
我自己的結構化思維會貫穿整個產品流程,比如接到新需求的時候,我第一個想法是什麼,接下來怎麼驗證,怎麼做,怎麼上線,都是一個個比較小的關鍵節點形成的結構。
我的結構化思維
定位
使用者的真實面貌
場景設計
回到原點,是否滿足了使用者需求
競品的戰略是什麼
開發具體的實現流程是怎樣
產品方法
調研階段
需求整理
競品分析
開發階段
一、調研階段
產品定位是什麼?
很多時候定位不是產品經理決定的,就算是立項的新專案,大多也是在原專案的基礎上做的改造、升級或矩陣式發展。
所以,從0開始立項的產品經理,需要理解產品定位,並有機會參與制定。理解之後對後面的工作都有方向的指導作用。
在已有產品的基礎上立項新需求的定位,則是要了解該需求在整個產品層面是什麼地位,什麼目的,以及整個產品層面的定位和戰略是什麼。知道大的方向,才能做好當前的需求。
市場情況如何?
首先從大的層面整體瞭解市場概況,從市場資料、使用者存量、需求場景、使用者感受、媒體分析及報道、競品功能瞭解、國外產品參考、頻次預估、收益預估的角度做整體瞭解
C端和B端,以及純線上或線上+線下的區分在於B端和線上+線下的形式,場景體驗方面做產品的人不太容易觸達,但通過使用者訪談和真實體驗也是能完整體會到的。
瞭解使用者
在定位和市場都準確把握後,對使用者的畫像也會逐漸清晰,但範圍也非常大,描述出來可能就是20-30歲,白領上班族,年輕女性居多之類籠統的關鍵詞。
需要用到側寫的方式,給使用者做詳細到行為習慣的關鍵詞概況。
這個方法適合對使用者心理把握極高的C端產品,不同產品功能和場景也需要把握不同的使用者心理。而且這個方法難度很大,需具備一定行為心理學和認知經濟學知識,和掌握大量資料後分析得出。
做不到這個程度的情況下,通過訪談、資料分析、評論反饋等途徑瞭解使用者心理。
B端產品不需要揣測使用者心理,但需要通過體驗使用者工作場景的方式,瞭解使用者在使用產品想要解決的問題。
二、需求整理
判斷需求存在的意義、價值和真偽
基礎概念資訊的把握如果沒做好,不能著急開始整理接到的需求,或者定義需求之前。
草紙手畫、墨刀、sketch、keynote等工具都能實現需求原型製作,動手之前還是得根據基礎資訊判斷需求的真偽,是否可以通過其他的創新方式從源頭解決這個問題。
判斷需求的真偽就必須基於對使用者的瞭解,使用者的背景、場景的因素、當下的動機,都會影響那一刻使用者做的決定。
大多數時候,B端產品因為存在的技術債務或歷史原因,不斷的通過新需求來修修補補,解決不了真實問題,時間越長越難改。
基於場景設想需求的設計
確定需求存在後,怎麼設計很自然的使用流程,必須基於場景來思考。給貨車司機用的產品,那必須坐在開在高速公路上的貨車上,在貨車司機休息站吃飯的場景下來思考,才能做出準確做出自然的功能設計。
不然都是坐在辦公室裡人的臆想。無論做任何產品任何設計,基於場景的設計非常重要。
三、競品分析
從0開始立項的產品如何做競品分析?
從0搭建,必然是連產品的商業模式,運營框架都還沒完全想清楚的階段。這時候的競品分析需要大而全,最終目的就是要從整個大的方面參考別人怎麼做,是否能賺錢。
這時候的競品分析可以從幾個點確定分析模型:商業模式、成本及收益預估、運營模式、使用者規模、市場概況、產品情況。
已有產品新需求的專案如何做競品分析?
弄清楚想從競品那分析出什麼,新需求是什麼目的?一個發私信的功能滿足使用者交流的慾望?一個使用者資料CRM管理後臺給運營做詳細分析?整體網站架構修改,以滿足SEO需求?
無論是什麼需求,競品分析無非就是參考功能做法、營銷方式、運營手段,目的是為了參考和減少試錯率。
這時候的分析模型就需要從想了解什麼內容的角度去確定,從而得到想要的東西。
四、開發階段
交付流程的確定
每個團隊都有不一樣的交付方式,工具也用的不同,這點因人而異。
工作流的確認主要是為了團隊內部形成快速的溝通效率,保持和技術團隊的持續溝通更為重要,畢竟所有交付的東西,都是為了給他們看懂,而不是為了形式而形式。
反覆檢視需求
很多人在交付後就懶得再管,就等測試階段在回來看。沒有人是毫無差錯的,只有經驗越豐富出錯越少,所以交付之後還需要經常檢視需求,和開發做必要的溝通。因為偶爾會出現某個需求定義,在開發做邏輯的時候發現這個方向好像行不通,產品經理就會發現好像確實是這樣,最終只好不做或改需求,在開發那的威信蕩然無存。