ProductTank Taipei #5 - 當產品經理遇到資料科學家
初次參加 ProductTank Taipei 的活動，是看了 Sharon 的訊息分享，再看到場地是在 Pic Collage 舉辦，可以跟久違的 Yen-Ting 碰面，於是興匆匆報名，幸運拿到了名額 ！於是坐在舒適的沙發區 key 筆記。
【噓，讓資料說話】 Dcard 產品經理 - 林懷宇
由 iOS 工程師轉戰產品經理的林懷宇，在 Dcard 擔任產品經理，秉持著產品精神 "Speak your mind" 推廣、設計、行銷著自家產品，透過匿名校園社群建構著自己的使用者。近幾年來資料的儲存與運用越來越普及，而 data science 也逐漸發展為熱門領域，做資料科學，需要有 hacking skills, math & statistics knowledge 以及 substantive expertise 的 domain knowledge，而這幾年來，「產品經理」的角色，需要同時發展 Business, User experience 以及 technology 幾個領域，而 data 在這幾個方面都可以有很顯著的應用與切入，林懷宇今天想從 UX 的角度來討論。
資料的運用在產品上，一般來說分為三步驟：「記錄行為 → 分析行為（例如社群交友的抽卡使用者性別比率）→ 預測行為」。
「預測行為」會是本日最主要的重點，透過資料分析預測使用者會做哪些行為，透過預測使用者行為，找出在預測使用者行為時的關鍵資料，則更可以設計出讓使用者滿意的產品，例如推薦符合使用者喜好的內容產品，或透過高度關聯性來增加判斷準確度（未來希望可以產生專屬使用者、符合個人喜好的熱門文章列表）。
分析工具一般來說會透過 GA、Facebook Analytics 等工具進行量化分析，甚至使用 SQL 從資料庫中直接撈取行為的 raw data 進行。
以完整組織來說，記錄行為一般來說是由 Data Engineer 負責，分析行為則是由 Data Analyst 處理，進一步預測行為則是由 Data Scientist 進行，但一般公司很難有這麼完整的組織，在 Dcard，Data scientist 會貫穿三個流程，每一步驟都參與到。
林懷宇說，想要特別討論「當產品經理遇上資料科學家時」會產生什麼樣的火花？事實上，產品經理不只是需要理解「公司以外的人（使用者）」，更重要的事理解「公司裡的人」，產品經理需要協調公司內的人，把產品順利打造出來，需要思考的是「為什麼團隊需要產品經理？」「對產品經理而言，最重要的事情是什麼？」「資料科學家需要什麼？為什麼需要你？」
產品經理很重要的任務就是「讓產品上市」，因為當產品沒有真正面對消費者，永遠都不會知道消費者真正要的是什麼。
以林懷宇跟資料科學家互動的經驗來說，資料科學家一般都是很重視邏輯的，因此需要很清楚的需求描述，不能有模糊地帶，溝通需要很有邏輯。同時產品經理也可以協助處理簡單的資料整理，讓資料科學家可以專注在最重要的任務上。
林懷宇問在場與會者：「若你是資料科學家，會希望產品經理怎麼跟你溝通？」事實上，與過去我們討論 UE 的設計傳達相同，就是「盡量掌握對方的用語、詞彙」，用對方懂的語言來溝通，因此產品經理需要盡量讓自己學習資料科學相關的基本知識，降低溝通門檻。
對產品經理來講，打造出一個資料型產品，最重要的就是定義出「核心需求」，資料型產品的開發流程可以分為八個步驟，前三項會是產品經理最主要的責任：
1. 定義核心目標
以 Dcard 為例，是「讓使用者更容易找到感興趣的文章」
2. 將目標轉為可觀測的指標（如何將目標轉換成指標？如何判斷結果是好是壞？如何衡量及取捨？）
轉化目標為指標會是最困難的部分，林懷宇舉 Dcard 的指標為例：每人每日使用論壇的時間、每人每次在首頁中的文章點擊次數、每人每日進入首頁幾次、前 1, 5, 15, 50 篇首頁文章的點擊率。
3. 定義欲收集的資料（應收集哪些資料？其他服務做過類似收集了哪些資料？哪些資料有助於分析以及模型改善？）
可以參考已經在做推薦系統的服務如何做，例如 Netflix, YouTube，這些服務商會把部分演算法以 open source 的方式公開在網路上，這些都可以當參考。簡單的例子，使用者資料，如年齡、性別、學校、系所等，甚至是在文章上停留的行為，包含閱讀、留言、收藏、喜歡等，另外包含文章的作者與內容、訂閱看板、常看的看板類型，都是可分類的標籤。
4. 定義收集資料的策略
使用者資料在註冊 Dcard 帳號時就已經收集了，是既有資料，在文章上的操作行為也是網頁開發時就開始搜集的資料，這些對 Dcard 都不是問題。
5. 分析資料
6 透過資料建立模型
合併來說，會是如何找出資料和行為之間的關聯性？如何預測使用者未來的行為？如何建立出預測行為的模型？而建立模型則牽涉到人工智慧的技術，如決策樹、機器學習等，但如果沒有資源可以建立這種技術平台時，也可以使用「工人智慧」來處理這些資料。
7. 檢驗模型是否有效（主要是資料科學家的部分，但需要協助資料科學家做 A/B testing，讓產品上線）
如何在推出前就先行測試 train 出的 model？如何確認是否有效？如何小量測試？驗證過後如何改良更新？
Dcard 以 model 產生的推薦內容來比對最新使用資料做驗證，若有信心，則可以做內部測試，再進一步就是推上線做 A/B testing。
8. 透過結果，決定下一步
以上八個步驟，林懷宇以自己的經驗來說，#2, #3 會建議資料科學家一起參與，可以協助產品經理更準確的定義需求。
總結自己的經眼，林懷宇提醒大家「完成比完美更重要」，讓產品上線永遠會是產品經理最重要的任務，同時「有些時候工人智慧不輸給人工智慧」，考量產品 Go to market 的時間，不要拘泥於技術，工人智慧也會小兵立大功。
林懷宇給希望切入資料型產品的 Product Manager 一些自我修煉建議：
1. 使用各種分析軟體：GA、Facebook Analytics
2. 學習解讀資料、拆解資料，挖掘資料背後揭露的事實
3. 試著學習 SQL，可以直接從資料庫挖掘資料
4. 學習機抽象的概念轉換成實體的數據
5. 挑一門 MOOC 課程資料科學
【產品經理和資料科學家合作學到的 10 件事】 KKBOX 產品經理 - Anadem Chung
KKBOX 內部在 Data science 上，分為兩種角色，Machine learning researcher 以及 Data scientist，今天 Anadem 主要分享 ML 的部分。
在 KKBOX 內部演算法處理的幾個資料面向包含 ranking, classification, clustering , recommendation, prediction。如推薦歌單、排行榜歌單、編輯歌單等的排序，會透過 ML 處理，讓使用者最快發現有興趣的歌單並開始播歌，另外也會透過同溫層（喜好歌曲）來擴展使用者的聽歌範圍，透過推薦歌曲/歌單、推薦藝人等功能，協助使用者認識更多歌曲，也擴增歌曲的點播率。另外也有 content-based 的曲風電台，使用者在聽電台時，也會透過 content-based 的算法來產生電台內容。
Cold start 的問題會是 ML 的挑戰，意即碰到「全新、沒有聆聽紀錄」的使用者時，要怎麼推薦？這時候會透過喜好的問答，以決策樹來產生推薦結果。
Anadem 以 圖解機器學習 網頁為例，機器學習一開始會以「直覺」做出發點，再「加一點常識」，進一步「劃分邊界線」、「尋找分界點」等，在 KKBOX 中會參照這些步驟去優化決策樹，訓練模型分類的準確度，同時透過與產品經理的交流確認特徵
Takeaway
演算法的推薦功能，如何開需求？
如果僅只按照規則（rule-based）來產生結果，就會很死板。KKBOX 的產品經理會透過這七個問題跟資料科學家提需求：
【噓，讓資料說話】 Dcard 產品經理 - 林懷宇
由 iOS 工程師轉戰產品經理的林懷宇，在 Dcard 擔任產品經理，秉持著產品精神 "Speak your mind" 推廣、設計、行銷著自家產品，透過匿名校園社群建構著自己的使用者。近幾年來資料的儲存與運用越來越普及，而 data science 也逐漸發展為熱門領域，做資料科學，需要有 hacking skills, math & statistics knowledge 以及 substantive expertise 的 domain knowledge，而這幾年來，「產品經理」的角色，需要同時發展 Business, User experience 以及 technology 幾個領域，而 data 在這幾個方面都可以有很顯著的應用與切入，林懷宇今天想從 UX 的角度來討論。
資料的運用在產品上，一般來說分為三步驟：「記錄行為 → 分析行為（例如社群交友的抽卡使用者性別比率）→ 預測行為」。
「預測行為」會是本日最主要的重點，透過資料分析預測使用者會做哪些行為，透過預測使用者行為，找出在預測使用者行為時的關鍵資料，則更可以設計出讓使用者滿意的產品，例如推薦符合使用者喜好的內容產品，或透過高度關聯性來增加判斷準確度（未來希望可以產生專屬使用者、符合個人喜好的熱門文章列表）。
分析工具一般來說會透過 GA、Facebook Analytics 等工具進行量化分析，甚至使用 SQL 從資料庫中直接撈取行為的 raw data 進行。
以完整組織來說，記錄行為一般來說是由 Data Engineer 負責，分析行為則是由 Data Analyst 處理，進一步預測行為則是由 Data Scientist 進行，但一般公司很難有這麼完整的組織，在 Dcard，Data scientist 會貫穿三個流程，每一步驟都參與到。
林懷宇說，想要特別討論「當產品經理遇上資料科學家時」會產生什麼樣的火花？事實上，產品經理不只是需要理解「公司以外的人（使用者）」，更重要的事理解「公司裡的人」，產品經理需要協調公司內的人，把產品順利打造出來，需要思考的是「為什麼團隊需要產品經理？」「對產品經理而言，最重要的事情是什麼？」「資料科學家需要什麼？為什麼需要你？」
產品經理很重要的任務就是「讓產品上市」，因為當產品沒有真正面對消費者，永遠都不會知道消費者真正要的是什麼。
以林懷宇跟資料科學家互動的經驗來說，資料科學家一般都是很重視邏輯的，因此需要很清楚的需求描述，不能有模糊地帶，溝通需要很有邏輯。同時產品經理也可以協助處理簡單的資料整理，讓資料科學家可以專注在最重要的任務上。
林懷宇問在場與會者：「若你是資料科學家，會希望產品經理怎麼跟你溝通？」事實上，與過去我們討論 UE 的設計傳達相同，就是「盡量掌握對方的用語、詞彙」，用對方懂的語言來溝通，因此產品經理需要盡量讓自己學習資料科學相關的基本知識，降低溝通門檻。
對產品經理來講，打造出一個資料型產品，最重要的就是定義出「核心需求」，資料型產品的開發流程可以分為八個步驟，前三項會是產品經理最主要的責任：
1. 定義核心目標
以 Dcard 為例，是「讓使用者更容易找到感興趣的文章」
2. 將目標轉為可觀測的指標（如何將目標轉換成指標？如何判斷結果是好是壞？如何衡量及取捨？）
轉化目標為指標會是最困難的部分，林懷宇舉 Dcard 的指標為例：每人每日使用論壇的時間、每人每次在首頁中的文章點擊次數、每人每日進入首頁幾次、前 1, 5, 15, 50 篇首頁文章的點擊率。
3. 定義欲收集的資料（應收集哪些資料？其他服務做過類似收集了哪些資料？哪些資料有助於分析以及模型改善？）
可以參考已經在做推薦系統的服務如何做，例如 Netflix, YouTube，這些服務商會把部分演算法以 open source 的方式公開在網路上，這些都可以當參考。簡單的例子，使用者資料，如年齡、性別、學校、系所等，甚至是在文章上停留的行為，包含閱讀、留言、收藏、喜歡等，另外包含文章的作者與內容、訂閱看板、常看的看板類型，都是可分類的標籤。
4. 定義收集資料的策略
使用者資料在註冊 Dcard 帳號時就已經收集了，是既有資料，在文章上的操作行為也是網頁開發時就開始搜集的資料，這些對 Dcard 都不是問題。
5. 分析資料
6 透過資料建立模型
合併來說，會是如何找出資料和行為之間的關聯性？如何預測使用者未來的行為？如何建立出預測行為的模型？而建立模型則牽涉到人工智慧的技術，如決策樹、機器學習等，但如果沒有資源可以建立這種技術平台時，也可以使用「工人智慧」來處理這些資料。
7. 檢驗模型是否有效（主要是資料科學家的部分，但需要協助資料科學家做 A/B testing，讓產品上線）
如何在推出前就先行測試 train 出的 model？如何確認是否有效？如何小量測試？驗證過後如何改良更新？
Dcard 以 model 產生的推薦內容來比對最新使用資料做驗證，若有信心，則可以做內部測試，再進一步就是推上線做 A/B testing。
8. 透過結果，決定下一步
以上八個步驟，林懷宇以自己的經驗來說，#2, #3 會建議資料科學家一起參與，可以協助產品經理更準確的定義需求。
總結自己的經眼，林懷宇提醒大家「完成比完美更重要」，讓產品上線永遠會是產品經理最重要的任務，同時「有些時候工人智慧不輸給人工智慧」，考量產品 Go to market 的時間，不要拘泥於技術，工人智慧也會小兵立大功。
林懷宇給希望切入資料型產品的 Product Manager 一些自我修煉建議：
1. 使用各種分析軟體：GA、Facebook Analytics
2. 學習解讀資料、拆解資料，挖掘資料背後揭露的事實
3. 試著學習 SQL，可以直接從資料庫挖掘資料
4. 學習機抽象的概念轉換成實體的數據
5. 挑一門 MOOC 課程資料科學
【產品經理和資料科學家合作學到的 10 件事】 KKBOX 產品經理 - Anadem Chung
KKBOX 內部在 Data science 上，分為兩種角色，Machine learning researcher 以及 Data scientist，今天 Anadem 主要分享 ML 的部分。
在 KKBOX 內部演算法處理的幾個資料面向包含 ranking, classification, clustering , recommendation, prediction。如推薦歌單、排行榜歌單、編輯歌單等的排序，會透過 ML 處理，讓使用者最快發現有興趣的歌單並開始播歌，另外也會透過同溫層（喜好歌曲）來擴展使用者的聽歌範圍，透過推薦歌曲/歌單、推薦藝人等功能，協助使用者認識更多歌曲，也擴增歌曲的點播率。另外也有 content-based 的曲風電台，使用者在聽電台時，也會透過 content-based 的算法來產生電台內容。
Cold start 的問題會是 ML 的挑戰，意即碰到「全新、沒有聆聽紀錄」的使用者時，要怎麼推薦？這時候會透過喜好的問答，以決策樹來產生推薦結果。
Anadem 以 圖解機器學習 網頁為例，機器學習一開始會以「直覺」做出發點，再「加一點常識」，進一步「劃分邊界線」、「尋找分界點」等，在 KKBOX 中會參照這些步驟去優化決策樹，訓練模型分類的準確度，同時透過與產品經理的交流確認特徵
Takeaway
演算法的推薦功能，如何開需求？
如果僅只按照規則（rule-based）來產生結果，就會很死板。KKBOX 的產品經理會透過這七個問題跟資料科學家提需求：
- 要解決的問題是什麼？（value proposition）
- 誰是目標對象？（TA）
- 衡量的標準是什麼？（evaluation metrics / success metrics）例如本週使用者的歌單是否有所擴展？
- 基於什麼觀察，我們為什麼可做得好？使用者為什麼會買單？（our differentiation）
- 為什麼是現在？（why now?）
- 什麼是成功的關鍵因素？（solution requirements）
- 未來持續成長/優化的策略是什麼？（growth strategy）
ML 的產品上線標準和一般產品不太一樣，需要透過「反覆不斷調校，直到信心水準達標才上線」，過程中會發現很多「邏輯以外的 insight」，再加入 model 訓練，才會進到 production 的 A/B testing 程序。
Eyeball test 的結果很重要，透過編輯的內部測試，會發現一些重要的問題，例如，在古典或沒人聲的推薦歌單中，突然出現一條 rap，但可能使用者本來就有在聽 rap，因此 model 會產生這種結果，但透過編輯的 feedback，產品經理可以轉譯為：「要如何在演奏曲風中排序穿插出現人聲曲風？」據此跟資料科學家溝通，產品經理需要優化 eyeball test 的流程與 feedback 的內容，以加速迭代的速度。
或是使用者並不認為自己是「老歌愛好者」，但使用者的 profile 明明就喜歡老歌，但他的喜好設定卻不是這樣，這時候該怎麼推薦？另外也會遇到「藝人喜好」問題，當使用者切掉這個藝人的歌時，背後是因為「不喜歡這個藝人」還是「這首歌聽過了」？
資料型產品一定要先有資料，而資料的背後其實有很多細緻的討論，包括對現象以及對使用者的理解，如「隨機播放並不隨機」的演算法問題，背後解讀可能是「播放次數少的歌曲，需要在隨機播放時被提升播放機率」。
沒有資料的時候怎麼辦呢？自己打造！
Golden set → Model training → Eyeball check → Model iteration (feedback to eyeball check) → Release
沒有資料的時候怎麼辦呢？自己打造！
Golden set → Model training → Eyeball check → Model iteration (feedback to eyeball check) → Release
質性的現象需要透過精準的描述，來和資料科學家溝通，最好可以佐以資料與數字的描述。Anadem 建議，產品經理最好可以「喜歡處理資料問題」，比較能樂在其中。例如思考 ranking 的微調，會是非常細微的變動幅度，因此如果不喜歡資料可能沒辦法得到明顯的成就感，同時喜歡資料的話，比較可以體會到資料科學家的貢獻，也能感覺到其中的變化。
Product Strategy 仍然需要呼應 Business strategy，而這是所有產品經理都應該謹記在心的。當然還有一些撇步，例如先做 ROI 高的功能，才能幫產品打好底。同時透過四個面向跟資料科學家討論：成本 cost /開發資源 resources、風險 risk、預期價值 success metrics、使用者有感度（coverage），需要透過這些問法旁敲側擊，才能更精準的評估出資源投入的方向。
Anadem 也提醒，遇到瓶頸的時候，可以「轉彎」，例如透過 UI 設計吸引使用者等，不一定要透過演算法解決所有問題，有很多種問題的解法。
產品上，記得要讓每個推薦功能「定位清楚、具差異性」，每個推薦功能，在不同面向也會有不同重心，KKBOX 分了八個方向：
Anadem 比喻產品經理和資料科學家的合作，是「像個爵士樂團」般：「有 pattern，但也允許隨興發揮，有主旋律但不受限、接受不確定性也擁抱不確定性、讓每個人都有 solo 的機會。」才能結合團隊智慧產生出有價值且可以上線的資料產品。
Product Strategy 仍然需要呼應 Business strategy，而這是所有產品經理都應該謹記在心的。當然還有一些撇步，例如先做 ROI 高的功能，才能幫產品打好底。同時透過四個面向跟資料科學家討論：成本 cost /開發資源 resources、風險 risk、預期價值 success metrics、使用者有感度（coverage），需要透過這些問法旁敲側擊，才能更精準的評估出資源投入的方向。
Anadem 也提醒，遇到瓶頸的時候，可以「轉彎」，例如透過 UI 設計吸引使用者等，不一定要透過演算法解決所有問題，有很多種問題的解法。
產品上，記得要讓每個推薦功能「定位清楚、具差異性」，每個推薦功能，在不同面向也會有不同重心，KKBOX 分了八個方向：
- Personal preference 個人偏好，例如曲風、語言、藝人、樂器...
- Relevance 相關度，例如在向量空間上的位置越接近
- Popularity 熱門程度，例如播放次數高的，被收藏次數高的
- Cold start 使用者的歷史資料少的時候，如何很快推薦可能感興趣的內容
- Serendipity / Novelty 新穎度，幫使用者跨出舒適圈的幅度
- Diversity 多樣性，要涵蓋的藝人獲曲風的廣度
- Trending 近期竄紅的內容
- Context 呼應情境或是互動式的介面，來回應使用者當下的意圖
Anadem 比喻產品經理和資料科學家的合作，是「像個爵士樂團」般：「有 pattern，但也允許隨興發揮，有主旋律但不受限、接受不確定性也擁抱不確定性、讓每個人都有 solo 的機會。」才能結合團隊智慧產生出有價值且可以上線的資料產品。
Comments
Post a Comment