“吃瓜”為例,淺談策略PM和模型搭建

2 評論 7246 瀏覽 48 收藏 13 分鐘

“策略產品”雖然有些神秘感,但并不是遙不可及。本文以識別好瓜為例,粗線條對策略PM的工作進行介紹,希望對想了解這個領域的朋友們有所幫助。

圈內有個神秘的職業,名曰“策略產品經理”。在前端產品經理/后端產品經理、社交產品經理/電商產品經理、APP產品經理/WEB產品經理……大行其道的時候,策略產品經理顯得格外低調,連論壇上都少有發聲。且不說關于策略的方法論、思維方式、職業進階相關的材料稀少,就連最基本的工作職責、工作流程和工作感想類的水文、雞湯文都沒幾篇。

在行業已經如此成熟的今天,這個現象本身就是一件耐人尋味的事情。作為一個喜歡沒事“拿耗子”的汪,筆者梳理近期的所見所聞及學習感受,跟讀者扒一扒這個職業的基本工作方法和流程。

一、什么是策略

首先需要明確的是,行業內有策略PM和策略RD對于“策略”的定義和理解是不同的。

對于PM來說,策略是以數據驅動產品解決方案的一種方式。即使在非互聯網行業,大家對于“策略”也是這么用的,所以才會有推廣促銷策略、渠道策略等說法。而在互聯網行業中,因為數據收集的完備性及便捷性,策略被發揮得更加淋漓盡致。各種基于數據分析的解決方案都會被冠以策略之名,如“訂單分發策略”、“搜索推薦策略”、“列表排序策略”等。

對于RD——特別是策略RD——來說,策略是評判模型優劣的標準。要說清楚這個表述,不得不說一下機器學習中的模型、算法、學習、樣本這幾個概念。此處不介紹復制的概念,就用筆者看到過的一個比喻來說明。吃貨版的機器學習是醬紫的:數據好比食材;大廚把食材做成水煮魚,還是做成西湖醋魚…這些是模型;具體用的是什么手法是算法選擇的問題;而機器學習就好比是整個做菜的過程;為了讓菜變得更好吃,廚師得多次對火候、調料等進行調整,這就是調參的過程。一道菜出鍋后,判斷做法是不是好的,就是策略。

二、為什么需要策略

在產品的用戶群和使用場景集中時,用功能的思維能夠解決多數問題。但是,當用戶增長到很大的量級、不同的用戶群體與不同的使用場景交織產生難以計數的訴求時,單純通過產品功能是不可能滿足用戶的需求的。

舉例來說,一款音樂播放器的主要功能就是播放音樂,這一點毫無毛病。但是,對于用戶而言,其根本需求是“聽喜歡的音樂”。那么問題來了:首先是用戶只想“聽音樂”并不想“找音樂”,即使找音樂是剛需,也是不得不承受之重。所以為了能減少用戶的搜尋成本,需要給用戶推薦音樂。其次是“喜歡”,一千個人眼中有一千個哈姆雷特,更有數不清的關于喜歡的標準,如何讓用戶滿意是個大問題。

這種情況,正是策略大顯身手的恰當時機。通過獲取用戶的興趣特征和音樂的特征,把用戶歷史上收聽的數據作為正負樣本對模型進行訓練,一旦有新的音樂出現時就能得出用戶是否會喜歡的標簽。用戶的收聽及行為數據越多,模型判斷的準確性越高,那么推薦的音樂受用戶喜歡的概率就越高。這就是策略的魅力所在

三、如何搭建策略模型

所謂模型是從數據當中發現的一個數學規律。那么,作為一個PM如何搭建策略模型呢?其實和功能PM的工作類似,同樣也是圍繞著問題的發現、分析、解決和效果評估4大階段。為了便于理解,就以如何挑選好瓜作為例子,權當是為吃瓜事業做貢獻了。

1. 發現和提出問題

假設我們是一家專門賣瓜的公司。產品經理在調研業務方時,對方抱怨用戶投訴西瓜不好的情況越來越多。通過后臺跑客戶的歷史數據,PM發現大約30%客戶因為買到壞瓜而流失。作為一家重視商譽和用戶體驗的公司,我們當然不希望出現這種情況??墒菃栴}在于:世界上的西瓜千千萬,品種、大小、顏色都不一樣,who knows哪個西瓜是好瓜???

以上其實包含了問題的發現和定位的過程——通過對業務和用戶的調研得到定性的判斷,再通過數據分析得到定量的論據。在倒推問題的根源時,需要對業務的全流程進行分析。假設通過對流程的分析,問題落在了如何識別出好瓜上,那么接下來就是如何解決問題了。

2. 拆解問題,制定解決方案

產品經理在前一個步驟中首先對問題進行了定義——也就是如何從眾多西瓜中識別出好瓜,并且給好瓜打上標簽。但是好瓜不會自己蹦出來,所以得通過一系列的模型進行識別。而要做模型識別,PM和RD就得告訴機器好瓜有什么特征。

特征是業務和技術結合的產物,PM從對業務的角度提出有助于模型識別的關鍵特征,以及判斷特征好壞的標準;RD對這些特征進行技術落地。這里需要特別注意的是:

(1)PM在特征表述上一定要具體可衡量,將可能涉及到的范圍和標準都明確地定義出來。例如,色澤是判斷瓜好壞的一個特征,但是您不能僅僅告訴RD“青綠色的瓜就是好瓜”,這種模糊的需求只會讓RD懵逼,你得明確什么是“青綠色”;“瓜”的范圍是歷史上所有瓜,還是僅限夏天產的瓜/從供應商A采購的瓜等等。

(2)特征需要結構化。PM根據不同的業務目的將特征進行歸類并提煉出一個個子模型,但是對于RD來說很可能會將多個子模型合并成少量模型,甚至是就整合成一個模型。例如,在識別好瓜上,根據中國人民“望聞問切”的光榮傳統,可能會先問賣家這瓜是哪里產的,是沙地瓜還是山地瓜…然后是看看瓜的外觀,最后會輕敲兩下聽聽回聲如何。那么相對應的,在機器學習上可能存在準入模型、外觀辨別模型、回聲辨別模型共3個模型。其中,相同的特征可能會在不同的子模型中被使用;另外,每個子模型都有輸入和輸出,有些時候還會存在多個子模型共同給出一個輸出的情況。

3. 跟進策略模型的開發落地

功能產品經理在開發過程中需要做好開發答疑、項目推進、需求調整等工作,策略PM也是一樣的。不同的是在具體的操作的層面上。

(1)策略RD接到需求后會先確認和理解數據

對尚不存在的數據進行接入,對已有的數據則是明確口徑。然后是對數據進行融合和清洗,這個過程中可能就會產生很多問題,有些可以由RD同學自行解決,有些則需要PM進行確認。

(2)在完成數據清洗后,RD進行模型的構建

這個階段RD是主導,雖然模型和算法的選擇一般沒PM什么事兒,但是PM提供的特征以及特征之間的相互關系將會影響RD在開發時做的判斷。比如,如果PM能說清楚好瓜和壞瓜的根蒂、色澤、觸感…分別是怎樣的,那么RD可能會使用決策樹這種監督學習的模型;如果PM說不清楚,有可能RD就會改用聚類這樣的無監督算法了。有些特征和關系一開始不明確也不要緊,但是在開發過程中是需要給出明確的表述的。

4. 制定評估方案,完成效果評估

這里的評估包含兩層含義,第一層是模型本身質量的評估,第二層是模型在項目中的價值評估。先說第一層。

不同的模型和算法有不同的評估方法,專業的RD對這方面都了解,不需要PM操心。PM需要關心的是:

  1. 了解行業和公司內部普遍達標的標準,并以此標準作為參考對策略提出達標的要求。筆者工作的領域中使用是準召率,其中精準率用來判斷模型的準確性,召回率用來判斷模型覆蓋的情況,這兩者往往不可兼得、此消彼長。
  2. 通過過程數據了解模型最終落地的邏輯,在上線前確定無誤,一定程度上起到質量控制的作用。

第二層是模型的業務價值評估。在大公司,業務價值的評估往往結合著小流量測試來做。

假設咱的賣瓜公司在北上廣深都有業務,其中廣州的業務體量最小,最適合做小流量測試。在廣州分公司中有10幾個銷售組,那么在下發測試時需要選出測試的實驗組和對照組。選分組也是有講究的,需要兩個組是同質的,而所謂的“同質”也沒有唯一的判定標準,需要根據不同的項目和業務進行舉一反三。我們假設這里的“同質”的關鍵指標是客戶流失率(并且最好這兩個組的客戶數量、客戶體量、組內的銷售人員、維護人員等等都是相近的)。在以上都確定完畢之后,進行測試下發。測試結束后觀察實驗組相對對照組的數據提升情況,例如原來實驗組和對照組的30%客戶因為上面說的壞瓜問題而流失,而測試期間實驗組的該項數據降到了15%,那么就可以初步判斷這個項目是有足夠價值的。

以上是做策略產品需要了解的基礎知識,要做好這份工作有諸多不易。在基本素質方面,對思維能力、項目管理能力、業務洞察能力、產品設計能力、溝通表達能力有較高要求;在專業素質方面,需要了解機器學習、統計學等。這里只是冰山一角,后期有更多新認識時再分享。

 

作者:霹靂,微信公眾號:產品霹靂

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

題圖來自 Pexels,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 棒棒 期待后續

    來自北京 回復