前言
演講實錄youtube，沒時間的觀眾，前面product tank的介紹可以跳過
Marty演講正題開始（00:17:22）：https://www.youtube.com/watch?v=99go9sKp70I&feature=youtu.be&t=1042
FAQ開始（1:16:48）：https://www.youtube.com/watch?v=99go9sKp70I&feature=youtu.be&t=4608
後面我文章中有提到的段落，重要的有放影片節點
還是非常非常感謝product tank，這是我第二次參與他們的活動，如果有贊助需求真心可以聯繫我們家HR，感覺product tank的圈子有侷限在矽谷fu比較重的團隊中。
如果不是PM專職，聽這一個半小時就夠了，PM專職還是要把inspired這本書看完，而且一定要這個版本，第一版啟示錄深度較淺，這版也真的不好啃，看你入行的誠意了，應徵者面談時也可問他看了沒，VeryBuy的PM是強迫閱讀這本的。
以下照慣例用條列框架的方式(PRD-like)的寫法
什麼是Discovering? And Delivering?
Build the right product => discovering
- 真敏捷
交付給工程團隊之前，驗證出市場可能存在的風險 - 真PM
有在做discovering的才是product team，有在做discovering才是product manager - Airbnb: Build thing that don’t scale
這個觀念在lean enterprise一書也有提到，discovering不用考慮到效率，反正用沒效率的手段user也買單，stake holder一定會答應給你資源優化，後面就是要怎麼deliver出來的事情了。 - MVP的P
應該不是一個product 而是一個prototype
Build the product right => delivering
- 這是工程團隊需要做的事
- 這不是MVP，因為他必須要是一個product，要穩定，要能夠長久
- 純粹做delivering而完全沒有做discovering的是feature team
- 想把discovering 跟 delivering，兩件事在同一個流程中做完
- 花四個月打造MVP，對discovering 來說太長，對delivering 又太短
- 100% Discover to Deliver
Discover了十個產品（或功能），也deliver了十個，代表沒有做discovering，Microsoft 內部90%的discovering都被驗證不可行，若discovering的結果無ㄧ被捨棄，代表你做的是delivering
- Discovering*1*2*3*4*5*6*7*8*9*10
（首圖上：測試腳踏車是否可行） - 然後把這個idea交給工程師認認真真的Delivering
(首圖下：從輪子開始打造一台車子，使其可以規模化) - 然後趕快開始下一個問題的Discovering
Discovering 流程示例 （in EC business model）
部分我們從團隊經驗延伸
Marty提到的是：國際訂單的付款率太差了
- 1. 這時候CEO要你加入Paypal
- 如果你就做了Paypal的話那你就是feature team的project manager
- 如果你分析了一大堆為什麼Paypal對我們有幫助，那你就是個blocker不是一個problem solver - 2. 趕緊開始：想辦法去找其他solution，然後開始Discovering
- 3. 可以先看一下用戶的反饋，app store、fan page一則一則翻
- 4. 收斂出幾個解法：貨到付款、電信帳單付款、降低3D驗證門檻、增加Paypal
- 5. 第一次小量質化discovering: 針對國際訂單付款失敗的訂單user，撈出一定數量的名單，跟客服team一起打電話聯繫他，把收斂出的解法提供給user，看看他會選哪個，重新付款過程中有沒有遭遇到什麼困難，再收斂解法。
- 6. 第二次小量質化discovering: 再撈出更多付款失敗的訂單user，發簡訊給他們，看看是否可以自動化收回一些款項（看看有沒有traction）
- 1–6一週內要完成
- 中間有要串接的想辦法手動客製做，通常都可以只是麻煩
- 反正沒有要scale
- Marty有附帶提到Teresa Torres的opportunity solution tree，簡單來說是不要愛上你的solution，記得一直回頭重新思考問題是什麼，然後多想幾個solution
- 以例子來說是貨到付款、電信帳單付款、降低3D驗證門檻、增加Paypal
不要愛上他們，要一直記得回去想，現在的問題是國際付款率太差了，還有其他解法嗎？ - 不要因為沒有看到traction，就急著再Discovering階段去優化貨到付款的流程，試著去找其他的解法
稱職的PM
我實在沒辦法想像要做到以下四點，除了founder身份還有哪些PM願意花這麼多時間，PM就是產品的CEO這句話，意思是要做到這個等級，你也要花上這麼多時間，我不希望PM認為自己要先被授與有CEO的權力，然後才來提升自己。好像也沒有哪個公司的CEO是這樣當上的吧 XD
Marty也提到：PM需要無時無刻都做功課，才能取得CEO的信賴。
- 最重要：Deep knowledge of your customers （or users）.
- 次重要：Deep knowledge of your business.
影片這段 （1:08:17）：PM就是產品的CEO(a strong product manager of an empower product team is the CEO of the product)，這個Part我覺得需要知道的太多了，Marty只有帶過幾個層面像是成本結構、市場狀況、安全性等等，有空再來看看我是否寫得出來。 - Deep knowledge of data those customers generate.
Marty認為每天早上一小時要認真研究數據 - Deep knowledge of your industry.
關於Discovering，我常被問的問題
- Discovering聽起來像是一個全新產品才能適用的方法，如果我已經在一個產品大致成熟卻需要追求成長的團隊，該怎麼運用？
- 功能也可以做Discovering，重點是我們面對的問題是什麼？Discovering應該會連回一個問題。 - CEO以及我的主館（或創辦人）希望我不要浪費時間，他期望中的功能他認為沒什麼需要discover 的，你們做就對了 （影片這段 1:01:59）
- CEO不相信你理解user，所以他不相信你提出來的solution比他提出來的好，多數CEO（萬一他又是founder的話）真的花了很多時間在產品與產業上，加上他的視野跟他能接觸的人比一個PM多太多了，對於user的理解，PM要超越CEO可能需要花十倍以上的時間，但幸好，CEO不只比PM忙十倍，所以我覺得還是可以辦到的，證明給他看就對了。 - 很多迫切需要解決的問題，沒有時間做Discovering
- Marty的說法是：不做Discovering就直接下去解決，萬一解法錯了才是真的浪費時間。
- 以EC or O2O為例，有的時候是銀行或是倉庫出了問題（偏向offline環節），這個時候也是PM要去解決，在處理這樣的問題時，確實跟Discovering關係不大，但是跟成為一個稱職的PM關係很大，如果你是金流PM，銀行常見的問題都沒處理過，甚至不知道銀行會維護，信用卡收款行應該要有備援行，應該算不上是一個PM with “Deep knowledge of your industry”，有件事情我認為多數PM頭尾搞混，你需要是一個稱職的PM，主管或CEO才會授權你做Product Discovering, 主管不會拿自己的績效開玩笑。跟我說他沒時間做Discovering的PM，期許他多看看自己。
沒寫的部分
以上提供給我所愛的VeryBuy Product Team以及大研發的同學們參考，我只寫對VeryBuy重要的部分並且加以延伸，VeryBuy暫時沒有這類問題，就不多做整理。
- Marty還有提到但我沒整理的：
- 過多的Planning and analyzing 而不 Discovering（MBA problem）
- 太愛做Optimization小型優化的問題 （這段 00:55:10）
- 量化跟質化的價值
- 產品主管要注意的事情
- Q&A中一些B2B會遇到的問題
- 遠距團隊會遇到的問題
- 文件的區別與撰寫…
最後，一句話殘酷的話，送給PM
先算算自己做了多少功課！
by 一股
