ProductTank Taipei #12 - 大型組織的產品管理與協作
難得提早到現場，開了電腦正在準備，突然發現 Peter 正在遠端連線，抓圖時才發現，原來人在荷蘭的 Peter 今天是遠端分享，算是很特別的經驗。
Celine 「裸辭」上一份工作後，輾轉到了中國的攜程工作。直接破題的 Celine 以攜程旅遊網的首頁為例，告知頁面信息的排序，事實上並不只是考慮使用者的閱讀習慣與興趣，而是依據組織內部的角力，哪個組織收付的佣金夠多，排序就會提前，例如：酒店、機票、旅遊等區塊，就會有所上下排序調整。
Celine 的工作是後端的靜態信息組。攜程分為垂直式、水平式分工，垂直式分工意指從後端信息整合、API 接口到前台的 App UI 呈現和實作，水平式分工則指當重要功能需要整合時，便需要拉出平行橫跨並進的規劃作法。
在大公司工作讓 Celine 覺得任務非常複雜，例如做「需求調研」時，若功能橫跨各信息組或功能組，則一個需求便是牽一髮動全身，需要橫跨各組做繁複的溝通，甚至要召開【需求澄清會】，遭受各組的炮轟，最後再回去重寫。
若想要做一個扁平的東西，仍然需要跟開發努力爭取資源，並跟各部門 PK 優先，甚至談好資源之後，若開發部門有緊急事件，仍會不告知值接插隊延後需求實作，而為了功能，測試資源也是稀缺資源要透過血淋淋的爭取。
很多事情即使講很多次，還是會有人聽不懂！Celine 分享開發產品時的四個主要步驟：
- 需求調研
- 需求評審
- 開發測試
- 優化迭代
- 需求調研 - 開發、內部/外部訪談、PRD 撰寫
- 需求評審 - 內部評審、外部評審
- 開發測試 - 敏捷開發、測試
- 優化迭代 - 投訴處理、收集需求
現實中是這樣：
- 需求調研 - 查出接口的所有調用方、調研開發可行性、召開 N 遍需求澄清會、梳理業務流程
- 需求評審 - 到 N 個部門講 N 遍需求、跟各部門 PK 優先級、預先爭取測試資源
- 開發測試 - 講 N 遍需求、確認開發負責人、開發功能微調、跨部門溝通
- 優化迭代 - 跨部門講 N 遍需求、修 bug、運營流程優化、用戶反饋整理
- 盡量找到大部分的調用方（stakeholder）
- 項目管理工具（JIRA-cp4 + Teambetion, Lengoo, etc.）
但其實提完需求後，需求也只是被加入到「需求池」，進入漫長的排隊中。
在大公司中事情太多，沒辦法一次只做一件事情，每個人需要同時多工處理很多項目，因此很容易漏掉，產品經理需要努力跟緊開發，才能確保自己的需求被落地。
項目開始實作後，還要爭取難搶的測試資源，攜程有「測試聯調表」，紀錄了每一個部門對需求的改動點、時程、開發人和測試人的預估上線時間，並交代清楚彼此的依賴關係與進度，否則在跨部門的聯調中，需求很容易走上歪路或是無疾而終。
攜程是 2014 年開始從傳統旅遊網開始轉型為線上線下串接的互聯網公司，因此，Celine 遭遇了傳統公司的「踢皮球」和「打死不認」，主管對她不斷強調「用 email 紀錄需求啟動」的重要性。
主管說：「如果有人耍賴不承認，就把 email 甩在他/她臉上！」
攜程有個「統一郵箱管理」的做法，以 API 為單位將調用方的產品與開發建立一個統一的郵箱管理 (mail group)，借此管理問題排查與發佈通知（API 有任何改動便通知所有參與的需求依賴方），並作為類似 Wiki 的文件管理。
讓責任方無處可逃的統一郵箱管理
Celine 的產品是【點評】，「在我接手前，負責這個產品的產品經理都走光了，所以沒有人可以教我做什麼！」Celine 雖然披荊斬棘，還是歸納出點評這個產品的生態系，不僅只是歸納出 user journey 的接觸點，攜程還有超過 BI 的大數據、機器學習分析，透過對一億條以上的點評分析，挖掘出激勵用戶的有用接觸點。
同時，中國的作弊風氣非常嚴重，需要進行嚴格的風險控制、反作弊等機制。
由於點評產品與個人信息非常相關，需要做信息安全、敏感辭的審核，但為了讓資源平衡與最佳化分配，攜程導入了機器學習來判斷點評、機器判斷作弊圖片，結合點評組、美編組的人工審核。而在做這些功能開發時，都需要從公司成本與獲益的角度說服開發投入資源。
而由於攜程的產品牽涉到太多的評分與利益，「反作弊」的機制幾乎是諜對諜的一場戰鬥，為此甚至發展出一個「平台」的中立法官部門，結合反作弊處罰機制，試著對酒店做出懲處，並壓抑作弊風氣。
雖然到哪裡都會遇到恐龍法官，也只能努力吵架和堅持
做產品時，需要與「算法工程師」做各種的合作，包含點評分計算、內容挖掘，以及指標衡量。Celine 本日著重分享內容挖掘的作法，例如酒店提交的簡介和推介內容是否真實，需要透過算法來交叉比對，進行點評標籤（如：交通方便，就在地鐵站旁邊），以及信息糾錯（酒店位置很不好找，按照攜程的地圖找了半小時才發現地圖標錯了，而且酒店根本沒有會議室）。算法甚至要包含情感傾向值分析，才能評估用戶的點評是夾帶了多強烈真實的情感。
而這些著重參考點，都需要提出給算法工程師規劃訓練模型，才能做出機器學習的成果。「這些真的都是大公司才能有的資源，我以前根本碰不到這些。」
攜程不看 DAU、MAU 這種生存指標，因為這個龐然大物已經不需要考慮生存問題了，這些系列指標不適用單一小功能。反而是需要搭配公司整體 NPS 指標、公司當前戰略、產品優化目標，衡量定義各功能的細項指標，例如「點評指標」。
我們需要算很多指標，常常想破頭在定義指標公式，如果被老闆問倒，就默默趕快在回來改，最終定義出「多維度指標」
最終仍回到爭取資源。很多部門會計算 ROI，指標的訂定除了可評斷產品效益外，也能讓相關部門了解功能的意義，同時指標成果也能做為跨部門溝通的材料。「在跨部門溝通時，要常常換位思考，比產品更往上看一層，讓資源方了解，幫忙可以得到什麼好處。」
以前在台灣工作時，一切需求都以用戶的需求為主，但到了中國做了平台型產品經理才發現，用戶的利益往往會被壓縮，誰付的錢多，誰就是老大。
最後 Celine 分享了更多看不到，本日也來不及分享的秘密：
- 需求調研 - 老闆的需求、能妥協的保底方案、站在他人利益考量、證明價值/收益
- 需求評審 - 事先多交流、盡量當面溝通、開發 leader 打好關係
- 開發測試 - 測試也很重要、需求隨時會被 delay
- 優化迭代 - 業務流程事先溝通、申訴處理、端到端 & 閉環
Celine 的個人部落格：https://pmceline.wordpress.com/
Peter 本日的主軸是，How to Create a Product Roadmap?
同為旅遊類互聯網產品，「我想 Booking.com 的名字應該比攜（ㄒㄧㄝˊ）程不容易念錯。」
Have you ever communicate between Boss, members, colleagues?
作為民宿類產品的 Product owner，Peter 主要負責面對民宿主，期望創立「安全」的環境，意旨優化民宿主 host 端在 Booking.com 的 user journey。而種種的換位思考與使用者需求，在 Booking.com 這樣的大公司中 (hundred of products & service teams)，且處理的是國際化市場的需求，目標思維 Objective-orientied 的 Booking.com 運用了 Product roadmap 作為重要的目標溝通工具。
What is NOT a product roadmap?
- It is not a release plan.
- It is not a list of features and/or components.
- It is not a commitment.
Product roadmap 是個 high-level 的視覺化的 product strategy，透過 product roadmap 可以讓所有相關人員對目標有清晰的認知。
- Product Vision - What your product exists.
- Business Objectives - Identifying business objectives that tie to your vision is critical to making that vision a reality.
- Timeframe - What's important now and what can wait awhile.
- Themes - What would need to be true for our product to realize its vision and attain its business objectives.
- Disclaimer - Anything in the roadmap is subject to change.
Peter 舉例如下：
- Product Vision - Make casual hosts feel safe
- Business Objectives - Increase User Acquisition/ Increase Retention
- Timeframe - 2018 Q4/ 2019 H1/ 2019 H2
- Themes - Make hosts feel safer by enabling them to set the house rules and communicate them with guests. Make hosts feel safer by enabling them to specify who is able to book their homes.
- Disclaimer - Dependency on team X
Now what? How to create a product roadmap?
Roadmap 只是一個結果，不是用來討論產品需求的工具。因此要生成這個與 business 高度相關的結果，Peter 用 Outcome Driven Product Development 為例：
- Round 1: 定義 Product Vision (解決什麼問題？要帶給 user 什麼 benefit？)
- Round 2: Research > Problems > Solutions > Outcomes (Theme) > Business Objectives
- Round 3: Timeframes > Disclaimer
Peter 特別說，round 2 類似一個探討因果關係的過程，透過這些過程檢視，不斷確認產品方向以及 solution 的效益。
Booking.com 運用 OKR 作為目標管理多年，本日 Peter 沒有時間多述，建議大家找找最近出版的 OKR 書籍來了解此概念。
Theme - Outcome, not output
Outcome 與 Output 對 Product vision 的描述有極大的差異，例如寫出一個 output: HTML5 redesign，這樣完全感受不到產品目標和願景，但若寫成 Theme/ Outcome 的寫法：Make mobile experience as good as desktop 就非常明確也有感。
Object - Theme - Features 是 Booking.com 用來 breakdown 產品的做法。
Prioritization
- Business impact
- Outcomes
- Technical complexity of solutions
除了做出好的 Product roadmap 外，產品經理有個重要職責，Presnet your product roadmap，好好運用這個溝通工具。
Who should see your roadmap?
一般來說有四種不同的核心對象：
For Engineering
- Features & Solutions
- Stage of development
- Product area
- Scalability
- Technology & infrastructure
- Dependencies and Risks
Tips for Engineering: Why? Objectives?
For Sales and Marketing
- Features
- Target customers
- Confidence
- External Drivers
Tips for Sales and Marketing: Selling Points, Release date (Warnings)
For Executives
- Market Opportunity
- Profit and Loss
Tips for Executives: Links for product details
For Product Teams Collaboration
- Features & Solutions
- Stage of development
- Product area
- Scalability
- Technology & infrastructure
- Dependencies and Risk - 與跨部門合作時的分析和協作
Tips for Products Teams Collaboration: Consider the KPI for other teams
How roadmap works in the organization?
Roadmapping 有幾種交叉分析的元素，由於太喜愛這張表格，我再製成圖表如下：
Roadmap vs. Release Plan, release plan 上的 features 是 output, product roadmap 是為了 manage outcome/ objectives
在大型組織中，盡量用同一個格式管理 product roadmap，讓管理者一目了然，很容易得到重點。"Don't forget to update your product roadmap"，不能讓資訊過時，roadmap 會失去效用。
Roadmap 是結果，產品經理仍然要挖掘問題，尋找 solutions，最後讓 roadmap 與產品開發流程融合，從慣用流程中萃取出 roadmap 需要的元素，接著 breakdown 成 features, tasks 讓開發部門可以實際執行。
如果沒有先做 user research 就開需求，做任何事情都只是通靈而已
最後附上 Peter 提供的參考書籍：
- Product Roadmapping: https://www.books.com.tw/products/0010790213
- Product Leadership: https://amzn.to/2IA2Doc
Comments
Post a Comment