起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理是否該考慮算法？
算法是不是產品經理該考慮的？作者答曰：是。
知乎上有個問題如下：
經常被研發同事問倒，這個功能應該怎么做呢？算法問題應該是實現層面的問題了，不知道各位在實際過程中的經驗是怎么樣的。其實職能本來沒有一個特別清晰的界定，但是一定有最效率的方式。這么說太虛了，舉個例子，比如，產品需要根據用戶添加“喜歡”的內容向用戶推送用戶喜歡的內容，就是一個“猜”的功能，那么這個猜出來的內容是怎么算出來的，這個算法。
我的回答是：
去年在點我達，我接手了調度模塊的設計，有幾個月時間一直在搭建產品框架和協作流程。在此之前，調度的產品、算法以及除了開發的方方面面，都只由一個同事負責。
與此同時，公司成立了算法研究院，請來了機器學習相關的博士，負責以調度為主的各項算法的設計。
于是原本從接受需求、設計功能，到研究算法、跟進實施的步驟，拆分成了兩塊：我帶的調度產品組負責調度產品，而研究員團隊負責調度算法。
現在的協作流程大概是這樣的：
1. 需求方提出需求
例如，運營的同事認為，鮮花訂單的派單形式要有新的產品和算法支撐。這里講一下背景。我們的即時物流平臺會有外賣、商超、快遞、鮮花等一系列類型的訂單，其中外賣訂單是比較核心的，我們做的也比較久，因此很多產品模塊包括調度的設計，都是適應外賣場景的。當時鮮花則是相對新的業務。
2. 產品經理承接需求，并抽象
我們小組的同事小 C 接到了這個需求，于是跟運營的同事多次溝通討論需求背景，以及跟相關的其他同事（比如銷售、商務的同事，以及騎手）確認實際場景。最終，抽象出算法問題。
比如，以下就是典型的算法問題描述：
在時效要求不高（以天為單位，而外賣是 1 小時內送達）、起點集聚終點分散（外賣的起點終點都是分散的）、每個騎手可攜帶鮮花訂單數量為 n （外賣的上限 m < n）的前提下，應該如何基于外賣調度邏輯來設計鮮花調度邏輯。
3. 算法研究員承接算法需求，解決算法課題
算法研究員常博接受了算法需求，于是會把產品經理的描述再抽象一層，變成約束條件下的最優派單策略。以這些可量化的指標，就可以搭建起算法模型，依據已有的歷史數據，來跑出最合理的算法策略以及相關的參數設置。當然，在此過程中，不免會與小 C 和運營的同事持續溝通，有許多策略涉及的因素，比如在產品邏輯中的耦合性、比如在具體業務場景中的合理性，都要做大量探討。
像下圖就是典型的算法描述（是我們已棄用的一個算法）：
4. 產品經理整合算法模型成為產品功能
此后，小 C 會考慮模型的細節，然后就跟把引擎裝入發動機一樣，設計出模型相關的配套產品功能。真正的需求文檔會是算法文檔長度的幾倍甚至十幾倍。后續就會跟技術協作，跟進研發。過程中也是會跟常博經常溝通，但在此階段負責人始終是小 C。
這種協作模式可以算是一種可參考的模板。我們運行了半年多，一直沒有問題，而且雙方的協作極少有模糊地帶。
那么回到題主的問題?？赡墁F在沒有專職的算法研究員，那么產品和研發直接協作該怎么辦？
就推送喜歡的內容這個需求來說，首先，需求的目的、背景是產品經理要搞清楚的。推薦這些內容，是為了什么？淺顯的目的是為了讓用戶點擊，那背后相關的需求是什么？是現在用戶活躍度比較低、是用戶發掘優質內容的路徑過長，還是并不清楚老板說好像大家都有那就做吧？
其次，最關鍵的，需求的實現方式是產品經理要搞清楚的。需求和算法是兩個層面的事情，作為產品經理不能丟給研發說「做個推薦」就行了。顯然，推薦不是一種具體的算法課題。就好像告訴研發說「做個個人中心頁面」一樣不具體，這個頁面應該有什么、要達到什么效果，跟其他功能的邏輯關系……都是產品經理要考慮的。
就推薦來說，是基于什么數據做推薦呢？用戶的歷史瀏覽、用戶的已有關注、用戶的資料畫像，還是用戶的社交關系？即使作為產品經理，你不清楚基于規則、基于內容和協同過濾都是什么概念，你也要知道推薦不是憑空做的，是要根據具體的數據做分析的。
一個合理的梳理結果就像前文提到的，應該是類似于：「基于用戶已有關注對象的類型和這些對象發布內容的特征，來推薦更多同類的關注」或者「基于用戶目前的社交關系和相關的互動情況，推薦更多他可能喜歡的用戶」。
再之后，是跟研發搞清楚，所給出數據的意義（比如相關因素的權重），以及溝通邏輯上的合理性。比如，拿基于社交關系的推薦來說，用戶 A 給用戶 B 經常點贊意味著什么？用戶 A 跟用戶 C 每周有 15 次互動意味著什么？用戶 A 拉黑了用戶 D 意味著什么？這些不是算法課題！這些是產品經理應該以自己對用戶或主觀或客觀的感知，得出的功能判斷。
然后是建模。在這里確實有一個模糊地帶，如果是非常懶的研發，不愿意自己研究算法課題、自己建模，是有點尷尬。在職責劃分上，坦率地說有計算機背景的研發做建模和算法研究會更合理一些。但如果是我，我會很開心有往前多走一步的機會。如果把這件事做好，就相當于多了一項不錯的核心競爭力（可以想象未來懂算法、懂機器學習的產品經理會越來越吃香），也許會大大有利于你在公司甚至未來市場上的競爭力。
即使是你并不想有這項核心競爭力，在爭執不下的場景中，我也建議你暫時把這個任務做起來。畢竟產品經理是要為產品的方方面面負（tian）責（keng）的，產品因為任何問題沒有如期完成，產品經理都跑不了。
接下來就是根據建模的結果，梳理功能了。推薦當然不是簡單的建模而已，具體什么時間節點收集用戶信息？在什么功能模塊下推送給用戶？推送的數量有沒有限制？展示交互和界面都是怎樣的？這也都是產品經理要整理好的。
最后，具體用什么樣的代碼、什么樣的系統框架來實現，那就是研發的事情了。
大致來看，就是這樣的：
從題主的描述看，其實有點像省掉了「需求抽象」和「功能設計」的步驟，認為這純粹是個算法課題，需求來了就硬生生扔給研發，等待產品出爐了。我覺得這是不太合理的。
前文提到了，在點我達初期，實際上所有實現之前的步驟，都是由我一位同事完成的。這也是我推薦的方式。
歇歇。
#專欄作家#
劉飛，微信公眾號：劉言飛語，人人都是產品經理專欄作家?；ヂ摼W產品經理，先后在錘子科技、嘟嘟美甲和點我吧任產品經理，知乎產品經理領域最佳回答者之一。豆瓣閱讀《最好的時代》作者。
本文原創發布于人人都是產品經理，未經許可，不得轉載。
- 目前還沒評論，等你發揮！
