“策略產品”雖然有些神秘感，但並不是遙不可及。本文以識別好瓜為例，粗線條對策略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需要關心的是：
- 瞭解行業和公司內部普遍達標的標準，並以此標準作為參考對策略提出達標的要求。筆者工作的領域中使用是準召率，其中精準率用來判斷模型的準確性，召回率用來判斷模型覆蓋的情況，這兩者往往不可兼得、此消彼長。
- 通過過程數據瞭解模型最終落地的邏輯，在上線前確定無誤，一定程度上起到質量控制的作用。
第二層是模型的業務價值評估。在大公司，業務價值的評估往往結合著小流量測試來做。
假設咱的賣瓜公司在北上廣深都有業務，其中廣州的業務體量最小，最適合做小流量測試。在廣州分公司中有10幾個銷售組，那麼在下發測試時需要選出測試的實驗組和對照組。選分組也是有講究的，需要兩個組是同質的，而所謂的“同質”也沒有唯一的判定標準，需要根據不同的項目和業務進行舉一反三。我們假設這裡的“同質”的關鍵指標是客戶流失率（並且最好這兩個組的客戶數量、客戶體量、組內的銷售人員、維護人員等等都是相近的）。在以上都確定完畢之後，進行測試下發。測試結束後觀察實驗組相對對照組的數據提升情況，例如原來實驗組和對照組的30%客戶因為上面說的壞瓜問題而流失，而測試期間實驗組的該項數據降到了15%，那麼就可以初步判斷這個項目是有足夠價值的。
以上是做策略產品需要了解的基礎知識，要做好這份工作有諸多不易。在基本素質方面，對思維能力、項目管理能力、業務洞察能力、產品設計能力、溝通表達能力有較高要求；在專業素質方面，需要了解機器學習、統計學等。這裡只是冰山一角，後期有更多新認識時再分享。
題圖來自 Pexels，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
