「產品經理和資料科學家合作學到的10件事」這個講題，是我的前同事 Anadem在Product Tank Taipei活動上的分享專題。因為內容實在太精彩，我聽過2次還意猶未盡，特別詳記其中關鍵內容，並加上一些個人的工作心得，提供對 AI產品經理 有興趣的朋友參考～
Anadem是位非常資深的產品經理，曾在 Yahoo!參與搜尋和全球新聞平台產品開發，也曾在 LINE 開發電子商務相關產品。這份內容是他之前任職於 KKBOX產品經理時，與資料科學家合作，打造個人化音樂串流體驗的工作經驗分享。Anadem目前為Yahoo電子商務部門的產品經理。
產品經理的專業面向有非常多種，有人強項在於市場產品規劃、有人專攻UX與使用者研究、有人擅長產品專案管理，其中一個領域是資料分析相關產品，其中可再細分成二種：
- BI（Business Intelligence）領域的合作，進行商業數據分析作為產品優化營運參考：
產品經理協助將企業內的各種營銷、業務、用戶（消費者）各種數據，例如互動、留存、興趣偏好、用戶分群，到營業端訂單、庫存、交易賬目、供應商等數據資料，匯集企業所處行業和競爭對手的數據，進行各項分析做為產品與市場決策參考。有興趣者可以看以下二篇文章：
2. AI領域與機器學習工程師合作，透過演算法實驗 / 調整，提供更佳的產品體驗：這就是本篇要談的。
首先，從演算法開始談起～
§ 演算法與機器學習
大致而言，演算法應用有以下幾個常見的面向：
- Ranking 資料產出結果排序：例如Google 搜尋結果頁，就是透過演算法來做最佳的結果排序，試圖幫助使用者很快的找到想找的內容。
- Classification 分類：如Google Photos，可針對相簿內不同照片主題自動分類。
- Clustering 分群：依照相近行為的用戶來分群，最常見的就是電商平台中「買了這樣商品的人也買這些…」
- Recommendation 推薦：如Netflix「因為你曾看了紙牌屋，所以我們推薦你這些影片」，和第3點不同的是，這是根據你的行為所做分析，而第3點則是比對與你相近族群的用戶行為來做分析。根據國外報告指出，Netflix的分析可以做到非常細膩。例如大部份做分類定義，只會粗分到「你喜歡中古世紀影片」，Netflix可細分到「你是喜歡中古世紀/浪漫/愛情/謀殺的影片」，這樣做出來的推薦就會更為細緻。
- Prediction 預測：例如訂購機票時，可依據你所需的出發日期、地點來預測何時買機票比較便宜。另外還有常見的應用包含股票投資交易預測等。
所以在KKBox有幾個主要的演算法應用：
- Serendipity： 「不期而遇的美好」，跳脫同溫層，推薦你沒聽過但可能喜歡的歌曲。
- Ranking (card) 歌單推薦排序：從上萬本歌單中優先推薦排序出你較有興趣的歌單。
- Clustering 歌單分群推薦：因為你聽過田馥甄的專輯，知道你喜歡她的歌，所以推薦給你其他類似歌單。
- Ranking (song) 歌單內的歌曲排序：讓歌單聽起來順暢好聽。
5. Recommendation 推薦藝人：除了推薦專輯 / 歌曲 / 歌單外，還可以推薦藝人歌手。
6. Clustering 專輯/歌單分群推薦：基於喜歡的曲風推薦相關專輯/歌單。
7. Content-based recommendation：依據歌曲的曲風、音訊特徵、樂器等推薦歌曲。
除此之外，還有其他考量可作為推薦的依據，例如不同收聽時間提供不同的推薦；甚至「共用帳號」的辨識與推薦問題，例如媽媽早晨在家放兒歌給小孩聽，但到了辦公室就不想聽兒歌了，演算法能辨識/預測是否是相同使用者但不同情境而調整推薦內容。
要讓機器學習能夠辨識出各種音樂曲風，產品經理和工程師需要外部專家音樂製作人合作，先將曲風做完整的定義。包含透過樂曲節奏、使用哪些樂器、音頻高低、有沒有人聲等音訊特徵分辨，甚至搭配主題等，產出音樂「特徵值」。團隊討論出各種「特徵值」，將歌曲匯進系統後，交由機器學習解析歌曲的訊號、並且透過特徵值來定義歌曲類型。
但這事說來容易做來難，例如光是「搖滾樂」就可分成重金屬、龐克搖滾、前衛搖滾、輕搖滾、硬式搖滾、民謠搖滾、爵士搖滾、英倫搖滾等等，這就需要音樂製作人的協助，一一釐清並具體闡述各個不同曲風定義，例如節奏上的差異、樂器使用偏好等，好讓工程師進一步調校演算法模型，優化分類預測結果。
喜好是一種很玄的東西～
你可以問使用者他喜歡聽什麼歌，但喜歡有時是很直覺/很潛意識的東西，用戶往往僅聽前5秒歌曲，就可以決定他要不要切歌。有時在特殊情境下，例如很煩躁的時候，從未接觸古典樂的人，突然聽到一首小提琴演奏，整個人就放鬆下來。
因此推薦是沒有標準答案的，若要做到非常細膩，就必須不斷進行A/B testing，實際去測試User對這樣的推薦「有沒有感」。
而為了有具體的量化標準，產品經理和團隊會定義「有感」的指標包括如用戶會不會重複播放、加入最愛、加入歌單、觀看歌詞、觀看MV等。
但即便定義「用戶重複播放」代表「喜愛這首歌/歌單」的指標，這項指標也會有要注意的地方，例如我們可能會在短時間高度重播某首歌，然後就膩了不想聽。所以推薦機制不能僅考慮滿足標準就得出結論，還需思考後續整個體驗的調控，才不會讓體驗太單一或太硬。
因此推薦的作法需有很多面向的觀察和想像力，產品經理必須多方面地理解人的思維、行為反應與使用情境。透過不斷與工程師、編輯、其他產品經理交流，以及用戶觀察/數據分析，才會激盪出不同的想法做出更好的推薦。
§ 何謂機器學習
產品經理要和演算法工程師合作，應對機器學習（Machine Learning）有基本的概念與理解。Anadem 推薦了這個網站，協助大家深入淺出快速瞭解機器學習的其中一種原理與應用。
§ 1 . 演算法的推薦功能，如何開需求
負責Machine Learning的產品經理和一般數位產品經理的工作方式相當不同。一般數位產品經理通常會透過wireframe、UI spec.、Flowchart等來具體闡述功能需求。
但當產品是與Machine Learning演算法相關，較少是UI介面上的調整，因此如何清楚和工程師溝通需求具有相當高的難度。
而一般程式語言是透過 rule-based規則，來做邏輯上的描述。Machine Learning並不提供這樣的規則，而是由ML自行去學習得知。因此Anadem建議透過回答這七個問題，來跟資料科學家提需求：
- 要解決的問題是什麼？(value proposition)
- 誰是目標對象？(TA)
- 衡量的標準是什麼？ (evaluation metrics / success metrics)
- 基於什麼觀察，我們為什麼可做得好？使用者為什麼會買單？(our differentiator)
- 為什麼是現在？(why now)
- 什麼是成功的關鍵因素？(solution requirement)
- 未來持續成長 / 優化的策略是什麼？(growth strategy)
工程師透過這7個問題的回覆，瞭解產品經理希望達到的目的以及短長期的目標。工程師著手training model，並且找到適合的使用者群體，並使用過去的歷史資料作為驗證。這樣可以知道這個model的成功機率多少（例如metrics希望能達到85%的成功機率）。
§ 2. 和一般數位產品Release 流程不太一樣
這邊講的數位產品，指的是網站 / APP / 穿戴裝置等，具有UI （使用介面）的產品。
圖的上方是一般UI設計類型的數位產品開發流程，下方是數據資料類型產品開發流程，可以看出二者有非常多的差異處。
§ 3. Eyeball test 的結果很重要
Eyeball test就是在工程師解析資料數據特徵值，並透過model訓練後，將初步歌曲推薦結果，找專家或內部人員來測試，請大家收聽，並逐一寫下他喜歡這樣的歌曲推薦或者想切歌的原因。
用戶切歌原因很多種，例如他就是討厭這個歌手、不喜歡某個樂器等等，非常個人主觀。
經驗上還遇到一種狀況是，Machine Learning推薦的歌曲，二首古典音樂中，突然出現人聲歌曲，用戶聽了就覺得很突兀，破壞聽歌的流暢性。因此團隊一起討論處理有人聲和沒有人聲的歌曲推薦順序問題。
另外即便是同一首歌，有的人只聽原唱，非常討厭翻唱。但如今有網路歌手翻唱曲相當多，很容易被推薦到。當這些不喜歡聽翻唱版的用戶聽到系統推薦了他喜歡的歌曲翻唱，就會立刻切歌。這也是透過人工eyeball test後才發現的使用者回饋，再讓推薦系統依據使用者偏好予以扣分。
喜好經驗感受一定要透過人的把關才能測出，因此上線前找不同類型的使用者前測和蒐集意見往往能有更多發現。
除此之外，Eyeball test還包含以下幾個關鍵點：
- 用戶質性行為現象，需給予量化的數字描述
- 從High-level去詮釋問題，避免單點描述：例如User說不要聽到某位老牌歌手的歌 →不要只針對那位歌手做排除，應觀察此現象並 歸類為「不要聽到老歌」的特徵行為。
- 搭配適當工具，簡化並加速Eyeball test流程
§ 4. A/B 測試 — 不優化就會退化
A/B testing 是個非常重要但高成本的測試方式。有時想要做A/B testing的需求很多，要列出優先次序，這些是數位產品經理基本的專業能力。
另外，明確定義哪些是A/B testing的重要成功指標（Success metrics）很重要。以常見的「搜尋結果演算法」為例，它的目標在於「幫助使用者儘快找到喜歡的商品」
因此產品經理分別就「儘快」和「喜歡」這二種質化說明，定義出量化可衡量的指標：
- 搜尋結果前 N 筆的點擊率 (per query CTR) → 表示是否達到「儘快」的目標
- 搜尋結果放棄率(Abandonment rate)：用戶看到搜尋結果頁，但未點任何連結就離開了 → 表示用戶不喜歡這些演算法建議的搜尋結果
- 搜尋結果重試率(Retry rate)：表示用戶找不到他需要的，所以必須重新搜尋。
§ 5. 資料型產品，要先有資料
好的推薦，來自對「使用者」及「內容」的細緻了解。
對使用者的瞭解，包含Persona 人物畫像、Demographic、偏好等等。對於內容- 歌曲的瞭解，包含明確定義特徵值「專輯、歌單、編歌單的人（Curators）、音訊解析、藝人歌手等」。而這些資料往往需由產品經理會同內外部專家，並與工程師討論打造出來。另外還可能遇到唱片公司所提供的曲風資料可能太「廣義」，例如中文歌曲通通定義成 C-pop 中文流行歌曲，這樣的資料是較難被細緻使用的。
§ 6.Data-driven vs. Non-data-driven
如果想轉型成資料數據型產品經理，要如何準備呢？重點就在這張圖～
當然，一般數位產品經理的基本專業能力，例如專案管理能力、排定優先次序（抓重點）能力、溝通力、主動積極發掘並解決問題、對使用者的深入好奇與瞭解分析力等等，也都是資料數據型產品經理需具備的專業能力。
§ 7.Product Strategy 要呼應 Business objectives
無論是不是資訊數據型產品經理，這個也是一般數位產品經理需具備的能力。
特別是當面對到喜歡各種新技術的Machine Learning工程師，產品經理一方面要讓工程師有空間去嘗試新的技術應用，另一方面也要跟工程主管討論/評估新技術產品落地的方向，確保資源的投入可以回收。
§ 8.先做 ROI 高的，且同步為重要功能打底
這個也是一般數位產品經理需具備的能力。只是面對Machine Learning技術開發以及大量的A/B testing測試成本，數據型產品經理需要更重視風險與成本效益。
因為Machine Learning做出來的推薦成效難以事先預估，演算法model開發下去才知道是否會有效，很有可能數月之後產出有限，A/B testing也並非能有每次都有 positive results，因此產品經理必須特別留意資源配置。在溝通方式上，產品經理不要問工程師能不能做得到，因為對能力強的工程師而言，程式很多都可以做得到；產品經理要問有沒有風險，風險多高等等來評估。
Anadem有提出上圖這個優先次序排列的基本原則，這個也是產品經理/專案經理必備的知識。
§ 9. 要讓每個推薦功能-定位清楚、具差異性
不同的演算法會產出不同的推薦功能成效。但若各種推薦功能的定位未能明確區分，可能使用者最後搞不清楚這個到底是推薦什麼；而對內跟工程師溝通時，工程師不會覺得怎麼都做同一個東西，產品經領要很清楚每個推薦功能的差異點以及比重濃度。
上圖Amazon的四種商品推薦，除了明確做出定位差異外，在UI使用者介面設計上，也要考慮購買流程動線「User Journey 使用者旅程和User Scenario使用情境」將推薦放在最適當的位置，才能產生成效。
§ 10.產品經理的價值
當產品經理在執行AI 機器學習專案時，PM不需要畫UI/Wireframe，機器學習又是個複雜的演算法，怎麼才能發揮產品經理的價值並獲得團隊的認可呢？
首先，要能問出好的問題！好的問題命中產品核心、刺激思考/討論，並找到有價值的執行方向。
AI 機器學習類型的資訊產品，最困難的部分往往不一定是技術本身，反而是如何針對不同場景使用情境，推出「棒的應用」。例如：工程師說他會做圖片自動偵測，產品經理就要去思考這樣的技術可以如何應用。
Netflix便是使用這樣的圖片技術來做影片推薦。演算法也許連續幾天都是推出同樣的10支影片，但透過Machine learning每天針對同一支影片更換不同的封面。也許前一天用戶看到的影片主圖並沒有觀賞意願，但隔天換了一張圖，可能就引發想看的興趣，這就是個很棒的應用。
而詮釋現象的能力，對於產品經理來講，更是一個具高度專業的要求。實務上常遇到，產出了數據和測試結果，然後呢？大家仍是不知道接下來該如何做！即便有了數據也無法對產品優化產生有價值的策略運作。「解析問題核心 → 提出洞見 →達成優化成效」這件事真的很難，也是值得產品經理不斷去思考學習的課題。
緊盯成功指標Success Metircs也是非常重要！這件事有許多層次需被落實執行：釐清何為成功指標、執行並依據指標檢核成效、排定優化優先順序等等。實務上對於許多公司而言，光是釐清哪些是應該追蹤的成功指標Metrics就相當有難度了。
成功指標是可以被調整的，產品經理不定期檢視哪些Metrics是時間/隨情境推移的，如果有更適合的Metrics，那就應該做適當的調整。
最後就是產品經理的策略思考能力！要能兼顧長期/短期目標、市場用戶需求反應、配合商務營運策略，來思考規劃產品，這樣的PM工作是不是很有挑戰性呢？
不管是哪一類型的產品經理，都不是只靠自己一個人就行了。所有的產出都是來自於團隊的合作與智慧。AI數據類型產品團隊，包含以下成員組成：
Machine Learning Researcher / Engineer
Data Scientist / Business Intelligence
Editor / Curator / Content Planner
User Experience Designer
Business Manager
Product Manager
Anadem特別提到，產品團隊要像個爵士樂團那樣大家共同合作，有主旋律演出、但也有隨興的一筆！接受並擁抱各種可能性與不確定發生，光芒不是只照在少數人身上，也 要讓成員每個人都有上台表演的機會！
歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團，一起參與我們在數位產品經理領域的工作交流與專業討論！
§ 產品經理系列文章
產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)
Google UX Playbook — 【給新手的練習題】金融財經手機版
※ 數位產品經理的一天 — 以美國大型證券商交易網站為例 ( 奶爸老喬的矽谷觀察 Silicon Valley Old Joe)