大家好，我是策略產品經理夏唬人。
今天跟大家聊一聊策略產品化思維？
為什麼要聊這個話題？
起因是最近我發現一個現象，團隊的小夥伴在輸出策略方案的時候，很容易陷入一種的怪圈：優化策略直接去看邏輯是否有漏洞，而當優化邏輯的時候則複雜即正確，牛逼即效果好。
很奇怪。
這種思路已經脫離了一個做產品經理的的思考方式。
如果在面試的時候問大家怎麼去做一款產品？
相信每個產品經理腦海中都會浮現出一個相對完整的流程：規劃，調研，分析，方案，落地，到最終上線迭代。做產品需要看業務，看用戶，看場景等等。
但是，當讓他們做策略的時候，卻沒有了這樣的一個思路，不會做了。
其實，策略從形態上來講沒有固定的形式，但是策略的本質其實就是一個解決問題的方案，只不過相比C和B端產品來說，策略更多的時候是基於大量的數據去輸出方案，而最終他們都是為了解決業務問題，帶來業務指標收益。
所以，做策略也需要產品化的思維。一個策略從提出的落地，你之前做產品流程同樣不會少。下面我之前畫的一個做策略流程圖，目前看來基本還算適用：
什麼是策略產品化思維？簡單來說，就是做策略同樣需要產品化的思路去執行，要把一個策略當做一個完整的產品需求去做，哪怕是一個很小的優化。
如何去塑造這種產品思維？在我看來，你可以在工作和學習當中去刻意練習下面幾點：
一、做策略必做數據前置分析
通常情況下我們做產品調研主要集中在用戶，行業以及業務這三個方向上，但是，對於策略需求更重要的是需要進行數據調研。重點關注以下幾個方面：
1. 數據現狀以及預期提升值。了解當前指標現狀，明確策略上線後的ROI，制定核心指標用於後續迭代依據。同時通過影響流量大小及過往項目經驗判斷本次策略需求的預期提升值。同時，我也在訓練營多次提到預期提升值跟AB測試的關係。
2. 策略需求覆蓋範圍及影響面判斷。策略需求相比其他C和B的需求，他是比較難以直接進行定位到某些具體的場景的具體case。比如優化一個排序策略，你是很難判斷到底策略上線後的排序效果是什麼樣，但是你需要去預判策略影響的範圍並且進行提前測試。比如GSB。
3. 數據能夠支持策略落地。這是一個非常容易忽視的環節。有很多策略產品同學想到解決方案就可以需求推薦流程：寫方案，做評審，等到開發的時候發現這裡缺數據，哪裡缺數據，造成需求的延期。
在策略產品的實施過程中，我們一般主要關注用戶，物品，事件相關的數據是否都具備，且可進行分析處理。策略在具體的落地過程中實際就是一個數據工程化邏輯的實現，而保證數據質量的最主要的手段就是高質量的數據採集能力。
二、策略需要關注業務背景
策略是在某個業務場景下，來解決某個問題的方案，因此在產出策略要以解決業務問題為前提。這是最直接，也是最重要的一個環節。
但是，現實情況是，很多策略產品經理在輸出策略方案時候更關注這次策略優化了是什麼算法，增加了什麼邏輯，而不是解決了什麼問題，能解決多少。
在很多人的潛意識當中，覺得沒用算法的策略不會起到好的效果，所以，策略方案的輸出都以是否採用複雜的邏輯，牛逼的模型作為是否能產出效果的必要條件。
但是，好的策略不一定就等於高大上的算法。還是那句話：撇開業務談策略都是無源之水，好的策略一定是基於把當前的業務問題，用戶預期都定義清楚之後產出的。
在做一個策略之前重點思考以下幾個方面：
1.策略解決的業務問題是什麼？包括業務指標，業務需求等
2.當前場景下的用戶預期是什麼？也就是用戶在這個場景下想要看到的是什麼樣的結果
3.當前的方案產生的結果能夠滿足多大部分的情況。
三、策略需要關注影響面
在很多公司，尤其大廠，策略部門通常是以中台的形式存在，也就是意味着策略通常來說都是支持多種業務的，尤其類似搜索推薦這種，必然是一個綜合流量分發的場景。
所以，這個時候每當上線一個策略通常都需要考慮其影響面，一般需要關注如下幾個：
1. 業務範圍界定。做策略之前需要明確本次策略的業務生效範圍，很多時候我們的策略都是針對某個，或者某幾個策略生效的。假如範圍界定出現錯誤，那麼會導致策略上線後發生異常情況。
2. 關聯環節的影響。類似搜索，推薦系統涉及到的環節很多，而且都是環環相扣的，所以當你對其中某個環節的策略進行優化的時候，需要同時考量對其他環節的影響。比如你需要再意圖識別環節增加一些同義詞，那麼你需要考量新增的同義詞會不會對其他正在使用意圖接口的環節產生影響；同時，新增的排序特徵是否僅適合當前場景，但是其他場景不會使用。
3. 策略業務目標預估。如何估計一個策略能給當前的業務指標帶來多大的收益。可以按照下面的思路進行展開？
· 策略影響的流量範圍確定
· 當前策略核心指標現在確定
· 計算可能帶來的收益
以上，就是在做策略過程當中需要考慮的點，我把它叫做產品化思維的點在於：大家做策略的時候不要把它狹義的理解為就是做邏輯的優化，而是就像你在做一個完整的產品，這樣你的策略可能會是一個比較“好”的策略。
