ProductTank Taipei #14 — MTPCon Singapore 產品管理研討會經驗分享(聽者筆記二)
本文作者Criss (感謝作者分享)
Anne
分享到 Mind The Product Conference擔任志工的經驗
講者背景：Ex-Shopline product manager，共同經營部落格 @3PM Lab
產品三眼怪實驗室 3PM Lab: 會想參加是也是因為這個部落格有關，想去看這些跨國的團隊會碰到什麼樣的問題，如何運作。
會辦在新加坡是因為這裡的社群和產品活動很活躍，所以選擇在這邊辦這個會議，希望能夠和東南亞這邊的團隊交流。
參與志工動機：
會想參加是也是因為跟這個部落格有關，因為一起寫這個部落格的同伴都是做有跨國跨文化的產品，所以想趁這個機會去看看其他國家的團隊會碰到什麼樣的問題，以及如何運作。
會議重點：
1. Talks: 一個演講大概會是20–40 min，整場會議總共有9個session，內容包括像是從CEO看PM這個角色，東西方的PM的不同， PM leadership等等包羅萬象的題目。
2. Q&A Session: 是一個有很多互動的session，很多講者在休息時間時也會來參加並進行分享。
3. Sponsor: 有很多有名的公司像是Mixpanel, Amplitude會來推廣他們的產品來給PM使用。
4. Product People：既然來conference，那很大的一個原因也是能夠跟來自國家的PM來交流, networking。
志工的分工
－Registration
－information desk
－qa & demo stage
－sponsor
擔任志工的動機
1. 省門票
2. 測試自己的興趣
志工做的事情
1. Meet the Volunteers: 志工之間的社交活動，因為這些志工也都是PM，大家來分享
2. Work Hard: 我是負責帶領講者的部分，所以要帶領講者到對的舞台，幫忙負責，近距離接觸講者，大概花一半的時間在這
3. Join the Conference: 我這個負責的崗位有一半的時間能夠參加這個會議，吸收新知識
4. Party Time：志工可以參加全部的party & meet up
想分享的一些Insights
1. Being resourceful:
到底資源要用在什麼地方? 擁有一些資源，但是如何去聰明有效的分配這些資源，或是能夠自己去找到其他資源
Amanda — CEO of Rabbit 分享：一個產品團隊有很多面貌，最重要的是認知到這個團隊有什麼樣的資源，能夠如何去分配。
Junior -> 功能 -> workflow -> 產品線 -> 產品線所代表的使用者流程 (full customer exp)
2. Decision Making:
Sherif — Product Manager at Atlassian: 他從自己的經驗裡面整理出來大家對PM的誤解。
a. PM好像每天都在做決策，每天可能有各式各樣的人來問你 -> PM應該是來加速這個做決策的過程，讓整個團隊share 使用者的問題和產品的vision
Jeff Gothelf - Author of Lean UX: 最小可行性產品的想法，如何從團隊的角度來做最小可行性產品，來了解產品團隊的快速迭代 Who(user), What(solution) Why (vision)
這樣可以讓PM知道這個團隊目前的狀態是什麼，若像在哪裡，快速的去知道如何幫助團隊去align vision，或是solution來調配長期短期的團隊步調。
John Maeda: PM不一定是了解所有事情的人，但是他應該是知道誰會是某一個領域的專家，所以有一個問題來的時候，能夠找到對的人和團隊去解決問題。
3. Hard Skill & soft skill
工具很多，像是design thinking, agile, lean ux這些term大家都琅琅上口，但是更重要的是如何用你的soft skill來判定面對各種不同的情境的時候，能夠用哪些hard skill去解決問題。
Maggie: lean UX工作坊的經驗分享
Lean theory
Lean theory is composed by these three stages: Learn -> Build -> Measure
The key idea is to get through this cycle as quickly as possible. The author suggests the framework to think about what the things that you can test your MVP about for your specific business.
- Align your team: the hardest thing about MVP is to have everyone in the company agree on what MVP is. (The author defines it as the smallest amount of work to learn something)
- Think about the business problem (First step to implement the lean theory):
- Don’t think about any solution (features or products) in the business problem. You should focus on what kind of problems your product is trying to solve.
Exercise (小練習): reverse-engineer a problem statement from a product (Jira Cloud by Atlassian)
- Think about the business outcomes
- Impact Metrics (strategic goals)
- Tactical Outcomes ( Leading indicators)
- Tactical outcomes (secondary leading indicators)
Exercise (小練習): Mattress - One of the leading indicators for mattress is to have more people try to sleep on it in the store. Thus, one of the solution is to put a price tag on the ceiling so that when try to search for the price, they can lay on the mattress first.
- Users & Customers: what do the users want?
- customer value should equal to business value.
Case Study:
An instrument company v.s. A online music learning platform
- Hypothesis: how do you prioritize hypothesis to test
- Risk <-> Perceived value (two-axis metrics) to prioritize hypothesis
Case Study:
- Amazon Echo: instead of building the product itself, the team puts a box on the table, and they use google answer in the other room to feed the voice for the box when the user questions the box. That way, the team learn what kind of questions that the user would ask for an AI-assistant.
- Driverless Car: driver in the mask to pretend that there is no drive on the driving seat to see how the pedestrians would react to driverless car.
#### Connect all the tools together (design thinking, lean ux, agile development…)
10 principles
1. customer value == business value
*radical transparency*
i. scrum
ii. demos
iii. access to data
iiii. access to customers: data can tell you what happens but only the customer can tell you why that happens.
Jason: 5 Takeaways from Product Roadmapping
1. A roadmap is not a release plan, gantt chart, or backlog
產品路線圖（product roadmapy)不是產品發布計畫(release plan), 甘特圖，或是product backlog（敏捷開發），所以不管是把backlog直放橫放，他都不會變成一個產品路線圖
產品路線圖應該要有五個大的component:
a. product vision
b. business objectives
c. timeframes
d. themes
e. disclaimer
那所謂的產品路線圖和release plan最主要的差別在 C & D，timeframes和themes這兩個元素上。
在產品路線圖中，timeframe主要就只有分成三個階段：Now, Next, Later，這裡的Later有可能是幾個月，幾個季，也有可能是幾年的時間。
所以用一個比較綜觀的角度來看，產品路線圖和release/project plan主要的差異如下：
Roadmap vs Release Plan
- overall, broad view vs detailed realistic view
- Long timeframes vs Narrow timeboxes
- no specific dates vs specific dates
- Across all teams vs within product-dev
- Confirm strategic intent, objectives & directions vs Ensure resource allocation & execution
他們之間的關係可能比較像是，一個產品路線圖內可能會有很多個發布計畫(release plan)
常見的產品路線圖的錯誤有*Avoid common mistake*:
Make a roadmap by…
i. drawing a long-term release plan 把原本的發布計畫拉長
ii. stacking long & huge backlog 把backlog加更多東西進去
iii. and make broken promises 承諾一些可能之後無法遵守的約定
那這邊可能大家就會疑問，如果最後一點是不承諾之後可以能無法遵守的約定，那為什麼一開始要做產品路線圖？所以這就帶到我們的第二大點。
2. A roadmap is a prototype, bridge between start and finish.
產品路線圖應該是一個原型的概念，作為開始和結束之間的一個橋樑
i. Roadmap is how you will realize your product vision.
一個產品路線圖是描述你如何去實踐你的產品願景
ii. a product roadmap is a prototype of your product strategy.
一個產品路線圖是你的產品策略的原型
今天做一個產品，起點可能是發現一個使用者問題, 需求, 痛點，而當今天這個產品如果達到了他的目的，那他應該會達到顧客成功(Customer Success), 商業成功(Business Success)，和達成他的產品願景(Product Vision)。
而Roadmap代表的則是在眾多可能性當中，我們選擇的其中一條從start to finish的路線，而這也代表著roadmap本身就是一個原型測試，因此可能隨時改變，雖然這樣的概念聽起來很理想，但實際上應該要如何製作一個產品路線圖呢？
3. A roadmap is the key product of product managers
產品經理可能無法為每個人負責，但是產品經理一定要為roadmap負責，要製作一個產品路線圖基本上就是在考驗一個產品經理所有必須具備的軟硬實力，因此如果今天能夠做出一個成功的產品路線圖，那應該就算是一個產品經理的聖盃了。
製作產品路線圖的步驟:
1. Gather inputs: customers, stakeholders, competitors, market ecosystem
2. Build visions, strategy, objectives: company vision -> product vision -> objectives + key results
3. Make themes & prioritize
4. Map themes into timeframes：Now, Next, Later
5. Get alignment & buy-in
6. Present, share update & iterate
在這所有的步驟中 2（Strategy), 3 (Themes), 5 (Get alignment, buy-in)應該是屬於比較內步驟，主要是這在考量產品經理的軟硬實力，而其中最艱難的步驟又屬步驟5最難，原因是每間公司的溝通模式不一樣，其他步驟即使你換過公司後，你也可以多多少少帶著先前的經驗來彌補資訊，但是一個公司的溝通模式是每次換到新環境新公司都必須要重新開始摸索的一個過程，那一個小撇步是，當你在步驟一開始gather inputs時，其實就應該會步驟5來鋪路。
那由於今天沒有太多時間可以討論到產品策略，所以今天的演講主要聚焦在
a. 如何定義主題卡片（Theme)
b. 如何獲得團隊buy-in
4. A roadmap is optimized by how we write themes
一開始我們要先來定義什麼是主題卡片? *What are the temes?*
主題卡片應該是你想要造成改變的主要行動，舉個例子，他有可能是
- 顧客成功：解決使用者問題，達成需求
- 商業成功：實現願景，達成目的
然而即是是這樣定義主題卡片，他仍然還是一個很虛玄的東西，把它放在一個抽象與具體的維度上的話，他可以以不同的形式存在
Concrete <—————————————————————>abstract
Features - groups of features - initiatives (ideal form) - objectives
所以，如果一個主題卡片寫得越具體的話，他就會越變的像是一個功能，也就會越像一個發布計畫（release plan），可能一個理想的主題卡片應該是能夠介於Business Objectives和一群的功能之間。但由於主題卡片實在是太虛玄了，所以最好定義的方法是用兩個比較實體的目標去夾他，所以以下給了幾個邊際條件來去看看主題卡片能不在不同的條件下成立：
Visions/Objectives <- Themes -> Problems/Needs
Problems/Needs <- Themes -> Solutions/Features
Outcomes <- Themes -> Outputs
以下就用SpaceX來做範例實戰演練上面所演繹的概念
Example: SpaceX
SpaceX的公司願景是使人類成為能夠跨星球居住的物種，
要打到這樣的願景有很多種做做法，而SpaceX的公司目標是讓人類能夠在跨星球之間旅行，由此衍伸出來的SpaceX的產品願景就是如下
- To provide low-cost travel to Earth orbits (Falcon Rocket)
- To provide high-efficiency, low-cost, interplanetary transportation to Mars (Big Falcon Rocket)
那要這個產品願景達成，有幾項跳戰是這個產品必須要克服的，那這些挑戰就可以有他對應的主題卡片，包括：
i. high costs to orbit <> full reusability
ii. risky earth re-entry <> heat shield re-entry
iii.risky mars landing <> repulsive landing
IV.Not enough return fuel <> ???
Theme as Objective
所以如果拿第四個挑戰來做演示，如果太空船的燃料不夠，那他對應的主題卡片就會是要如何讓這個太空船在回程時還擁有一定的燃料並且能夠在有限的預算內達成這件事情，這時候可能就會有幾種對應的Solution: 像是在回程途中架設加油站點，在星球上自製燃料，或是載著更多的燃料在火箭上。
Theme as Initiative
可能經過了一陣討論後，公司認為在星球上自製燃料是最有可能在限制內達到的解法，這時候自製燃料就變成了另一個主題卡片，當然在這個情境底下還會有很多種可能性，比方說是要火箭上帶著元素自製燃料呢，還是火箭要到星球的南北極去找水，之後製成燃料，或是利用星球的大氣找元素作燃料？這些都是有可能可行的解法。
Theme as Feature
那又在經過了一番討論後，公司決定要用由火箭載運甲烷到星球上作燃料，所以這個背景又變成了另一個主題卡片，在這樣的條件下，用甲烷製成燃料的方程式有很多種，要做成哪種燃料也可能有很多種，但是最終公司選定了一種方程式作為最終解，就是所謂的功能（Feature）。
所以用上面SpaceX的例子可以看到，主題卡片可以以很多種形式存在，你可以寫的很抽象，也可以寫的很具體，這就需要一定的經驗練習，和每個團隊和組織應對當前的需求去做調整，當然寫得越抽象，就能將目標訂得更有企圖心，如果寫的越具體，就會讓產品路線圖越像是發布計畫。
5. A roadmap is a storytelling tool for negotiation and communication
一個產品路線圖很像是在做一部電影的預告片，因為每個部門都會有各種要求，然後每個部門都會想要你把他們的角色放在預告片的第一幕，作為PM，你要怎麼減少這樣溝通的成本？事實上就是如果這個預告片第一幕就把所有的角色，特效都呈現完了，那這一定不是一個好的預告片，所以roadmap應該是一個溝通和協商的道具，讓每個部門去了解這個故事會如何上演。
為了獲得到各個部門的buy-in，作為一個產品經理必須要做到以下這幾件任務：
- gather stakeholders’ inputs
- Prioritize & map to themes/timeframes
- Explain everything in strategic context
- Communicate priorities & negotiate adjustments
要做到以上幾件任務，你可以用產品路線圖來作為你說故事的道具和觸發點，有這樣的概念後，我們可以來看看在製作產品路線圖的時候可以有哪些策略：
- When creating a roadmap
build alignment from the beginning:
要和stakeholder時對談時，你可以問類似這樣的問題：
我們很想要開始做今年product roadmap，我可以跟你聊聊你的想法嗎？
我現在有一個產品路線圖的草稿，我可以請你看看給我你的feedback嗎？
因為這是專案的初期，所以這個幾段最需要做到的事情就是了解每個stakeholder對于產品策略有什麼樣的想法，產品路線圖可以做為一個觸發點讓你去探索每個人的想法。
- When talking to stakeholders
ask questions like we are interviewing our customers:
你也可以像是在訪談使用者一樣來訪談不同的部門：
你在下個年度會想要達成什麼樣的目標？
我們的產品如何能幫助你達到目標？
你覺得哪些東西比較重要？哪些東西必須放在產品路線圖上？
- When facing a rock from the sky
negotiate for roadmap adjustments by asking questions…
如果今天是突然碰到了一個突如其來的要求，這個要求可能不能馬上答應又不能馬上拒絕的情況的時候，你可以用以下的問題來讓對方了解你的立場
i. how does [a new request] meet the objectives?
ii. how does it fit into the roadmap?
iii. if resources are limited, what can be moved to later?
結論：作為一個PM，必須要用roadmap來講一個從現在到未來的故事，所以
- 每一個卡片主題都有意義
- 他們的先後緩急合理
- 可以在專案初期，就試探stakeholders的反應
