如果你已經做產品一段時間，沒遇到什麼困難，那表示你還做得不夠久。
做產品遇到困難是很正常的事情，這也讓我想跟大家談談這些困難。
我對「產品團隊」(Product Team) 總是非常感興趣，因為每一個偉大的產品總有一個偉大的團隊
但我花特別多時間跟大家談談產品管理、 PM ，因為已經有很多人在談論設計、工程，但幾乎沒什麼人談產品，我覺得這是一個很大的空缺。
我也不諱言地說，我們產業最大的問題就是「有足夠的設計和工程，但常常沒有足夠的 PM 」。也不是說誰比較聰明，就是沒有人好好地訓練這些人，沒人教他們如何做產品。
要學好做產品，目前多數人都仰賴一個「會做好產品的人」，跟他一起工作，且這人會花心力引導、訓練新人。理論上，只要能跟到這樣的人，任何背景的人都可以做好 PM ，不管你是工程、行銷、業務、客服。
接下來要分享的議題，都是做產品的常見問題，但他們彼此之間沒有先後順序，不過我敢說這是全世界都常見的問題。
一個很常見的問題，是對於「精實」 (Lean) 和「敏捷」 (Agile) 方法的挫敗感
為了避免這個情況，先來回顧精實和敏捷的核心原則
敏捷的核心原則:
去除所有外圍的東西，只剩兩個核心原則：
- 第一是「要頻繁的發佈」
- 頻繁是「至少每兩週發佈一次」
- 如果每月或每季才發佈一次，你其實沒有獲得任何敏捷的好處
- 好的產品團隊甚至每天發佈好幾次，就是所謂的「持續交付」 (Continuous Delivery)
- 頻繁是「至少每兩週發佈一次」
- 第二是「團隊要被賦權且被問責」
- 「交由團隊來找解決問題的最佳方法」
- 舉例來說，不是由管理層告知團隊「請串接日本當地 LN 公司的行動支付」
- 而是告訴團隊「我們眼前看到的問題，是太少日本當地人購買我們的產品，海外轉換率實在太低了，請你們解決這個問題」
- 如果串接了日本當地 LN 公司的行動支付，沒有解決這個問題，團隊就要繼續探索其他方案。
很多團隊被告知要更加敏捷，但其實管理層一直給團隊「待完成的功能清單」
- 這在任何意義上來說都不是敏捷。
- 這是敏捷遇到的很大問題，很多團隊沒被問責或沒被賦權。
就精實來說，背後也是只有兩個核心原則：
- 第一是「我們要快速學習才能創新」
- 創新源自於我們能夠嘗試多少點子
- 因為我們知道大部分的點子都行不通。
- 第二是「我們得要消除浪費」
- 所謂的浪費就是花了 4 個月才發現「這不是解決問題的好方法」，這就是浪費
- 常看見的浪費就是「我們正在做一個 MVP 」，他們說「正在做了，還要 4 個月」
- 這根本不是 MVP，只是個半成品、是不成熟的產品。
- 真正的 MVP 只需要 4 小時或 4 天，不是 4 個月。
這些是精實和敏捷的核心原則，千萬不能放棄。那麼，到底是什麼原因，造成精實與敏捷的挫敗和反撲呢？
為何「敏捷」還不足夠？
以做一台車子來比喻
- 瀑布式流程會花好幾個月來確認每一個汽車零件
- 敏捷會先做一個「可被測試」的東西。如果這個東西不管用，那就再做一個。
在一個產品公司裡面，做產品有兩個非常不一樣的目標與階段。任何一個科技產品公司，都會遇到這兩種挑戰。
- 「產品探索(探索該打造的產品)」(Product Discovery)。要找到一個產品方案，符合四個條件：
- 對用戶有價值 (valuable)：就是顧客會買單
- 易於使用 (usable)：意思就是顧客能自己搞懂如何使用
- 可被打造 (feasible)：是我們知道如何打造
- 商業上可行 (viable)：我們的事業能夠處理這個產品，包含宣傳、銷售、客服，也有收益
- 「產品交付」(Product Delivery)，交付工程師有自信的產品，讓我們的事業可以靠譜的營運這個產品。這個最終產品要符合的條件是：
- 穩定 (reliable)
- 可擴展 (scalable)
- 高效能 (performant)
- 可維護 (maintainable)
- 支援多國語言又在地化 (internationalized and localized)
「探索」和「交付」是非常不一樣的目標與挑戰
- 很多團隊遇到問題的情況，就是公司「要同一群人，在同一時間，處理這兩個挑戰」
- 例如，公司叫團隊「交付產品時，也要確保這是正確的產品」
但這並不合理，會造成很多浪費。
「探索與交付」的循環迭代
所以，在產品開發團隊中，我們會分離這兩種活動、這兩種風險
- 第一種，在探索階段，我們嘗試想出一個 valuable, usable, feasible, viable 的產品。
- 第二種，在交付階段，我們現在知道要打造什麼產品，我們有合理的信心去賣出這個產品、支持我們的事業，所以現在可以請工程團隊以可靠的方式打造這個產品。
這只是一個簡單的描述，不是完整的流程
舉例來說，現在已有很多交付階段的工作流程，2 個最有名的流程是 Scrum 和 Kanban
現在也有很多探索階段的工作流程，例如有多達 50 種探索階段的工作流程
想跟大家傳達的是： 我們要去解決問題，而不只是打造路線圖上的功能，我們被賦予的是解決問題的目標（而不是打造功能的目標）。
有人說探索階段就是 build the right thing，然後交付階段是 build the thing right
一個是在 Google 的例子，Google 他們會說探索是 fake it，而交付是 make it，串起來就是 “fake it before you make it”
在 Facebook 的例子，他們會說 “move fast, don’t break things” (在探索階段要 move fast，在交付階段要 don’t break things) AirBnB，這個描述方式對工程團隊來說是特別詭異，但他們刻意如此。他們描述探索階段是 build things that don’t scale，然後他們描述交付階段是 build things that do scale。
這就是大體上的工作模式，不管他們怎麼描述、不管有沒有精確的文字，我遇到的優良團隊都是這麼做產品。他們確保在最開始就面對產品失敗的 4 大風險，在探索階段知道應該打造什麼產品，然後才去交付產品。
Marty Cagan 在 INSPIRED 書中，介紹了產品失敗的 4 大風險，分別是
- 實行性風險 (Feasibility Risk)： 團隊確知需求，但手邊並沒有解決問題的技術，或技術尚未成熟，就是「知道要做什麼產品，但是做不出來」的狀況
- 易用性風險 (Usability Risk)： 顧客想用這個產品，但不知如何使用，或太少人克服使用門檻，就是「產品做出來了，但是好多顧客看不懂、不會用」的狀況
- 價值風險 (Value Risk)： 這個產品並沒有解決顧客需求，為顧客帶來價值，就是「產品做出來了，某些顧客也會用了，但後來都不繼續用，因為沒有滿足需求」的狀況
- 商業可行性風險 (Business Viability Risk)： 這個產品對公司沒有商業價值，或無法在市場競爭中存活，就是「產品做出來了，顧客也愛用，但是無法賺錢，或拿不到更多預算與資金，或無法贏過競爭者」的狀況
在探索階段只需要原型 (prototypes)，我總是在探索階段運用 prototypes，以免他人誤會。
- 如果你花 4 個月打造一個 MVP，這會是一個很大的問題
- 花 4 個月才打造一個 MVP，在探索階段來說實在是超級慢，但在交付階段可能又太快速了
- 所以沒有人會對此滿意。請記得，在探索階段打造 prototypes，在交付階段打造 products。
從三個方面來判斷 Product Team 的實力:
- Team 是否在進入交付階段前，就著手處理讓產品失敗的 4 大風險
- 這時候通常不需要寫任何一行程式碼。
- 他們實際上用什麼方式解決問題
- 我期待他們結合了 PM 、設計師、工程師，讓彼此交互切磋，然後產生一個最好的方法
- 他們是用共同協作的模式來解決問題，還是用依序接力的方式來解決問題？
- 在過去 Waterfall 模式下，PM 會定義產品需求規格，然後給設計師來負責把畫面弄好看，然後再把一整包爛攤子丟給工程師
- 若是在 Sprint Planning 上才第一次跟大家說「開始打造這一切」，這根本不是敏捷，這只是瀑布式，因為人們就是在彼此接手各種工作而已。
- 他們被賦予的目標
- 如果他們被賦予的是發佈功能，那只是個「產出」 (output)
- 如果他們被賦予的是解決問題，那正是個「成果」 (outcome)
我期待看到的是專注在成果 (outcome)，並以成果來衡量自己的團隊。
如果有發生這三件事，其他的議題也就不太重要，為此我就能判斷這是一個良好的團隊。
問題是要建立這樣的團隊編制並不難，困難的是要能在前面那 3 件事上面，落實的夠徹底、夠深遠
- 很多公司仍然只是制定產品路線圖，賦予給團隊的任務不是探索與交付，只是設計與開發。
有些公司甚至還聲稱有「探索階段」，但實質上並沒有這麼做，因為我會用這個問題來探測：
- 「你們在探索階段會測試多少原型？你們在交付階段又會打造多少？」
如果他們說：「上個月我們在探索階段測試了 10 個項目，然後這個月我們打造了 10 個項目。」
這樣我就知道這不是探索
- 這只是設計，也許附帶一點點易用性測試
- 並不是真的在測試點子
如果很認真實施探索階段，很認真的測試 4 大風險
- 他們必然要拋棄非常多當初的點子，至少要拋棄一半
- 真正優良的產品公司甚至會拋棄 80% 到 90% 的原始點子
沒有真正落實探索階段，他們實際上仍然只是個「功能團隊」 (Feature Team)。
回顧一下打造產品的 4 大風險：
- 價值 (Value)、易用性 (Usability) 、實行性 (Feasibility)、商業可行性 (Viability)
若某個公司內的 executives (executives) 或利益相關人 (stakeholders)，只要他們要求把某個項目加到產品路線圖中
- 這個人其實就負責了該項目的價值風險 (value risk)
舉例來說，如果某個人說「我們必須加上 PayPal 這個支付方式」
- 不管是誰說的，這個人肯定是相信這件事有價值，他才這麼說，否則他就不會這樣說
- 同時間，這人其實也負責了這個項目的「商業可行性」 (business viability)
- 這時候，PM 實際上要負責的是專案管理。
在產品團隊中
- PM 則要負責的是這個解法能夠 (為用戶) 帶來價值，在商業上也可行。
- 在產品團隊中工作的 PM，要承受更大的壓力、需要具備更多的技能、每天可能要睡得更少。這不是說專案管理不重要，這很重要，但這不是 PM 工作中的核心。
現在其實很容易讓產品團隊學到各種探索的技巧，迅速的測試，然後判斷一個產品概念是否可行
今天如果一個 executives 説「我們需要串接 PayPal 這個支付方法」，如果你學會了現代產品方法的探索技巧，只要幾天的時間，你就可以搞清楚它能否帶來效果，而且是在動工以前就搞清楚。
很多團隊擅長這些探索與測試的技巧，但仍然發生很不幸的情況。
- 當 executives 或利益相關人説「我們需要做這個、做那個」
- 而產品團隊幾天後回頭說「我們不打算做這些，因為測試後發現這些構想不可行，原因如下…」
問題是，經過幾次這樣的情況， executives 們開始覺得很挫敗
- 因為他們只聽到「這些不可行」，他們肯定會納悶「那你們到底要做什麼？」
我試著跟產品團隊説
- 你們的工作不只是告訴大家「為何這些不可行」
- 你們的工作還必須告訴大家「這些構想更能解決問題、更有機會成功」
如果今天的課題是「國際交易支付量過低」
- 產品團隊除了告訴大家「串接 PayPal 不是個好方法」
- 還必須告訴大家「PayPal 以外還有哪些方法」可以解決問題
- 優良的產品團隊知道，自己還必須提出可行的方案，而且這些方案要更有機會成功。
只要產品團隊開始展現這些能力
- executives 們開始認定這些團隊是「問題排除者 」 (Problem Solver)，而不是只會驗證點子 (validating ideas) 的團隊是阻礙者。
的確我們有很多思考問題、架構問題、規劃工作的技巧
- 但你必須非常注意時間，因為從你接下問題的那一刻，有個碼表就被啟動了
- 公司的 executives 們心裡就開始算時間，他們心裡會算「好，又過了一天…又過了一個月…」
就這個碼表在計時。如果你花了大部分的時間做規劃你就沒剩多少時間去提出一個可能成功的方案
- 然後，很快地你的老闆們就失去耐性。
因此
- 我時常告訴團隊，必須控制你的步調，不能做一大堆分析而已
- 做產品最困難的不是規劃，最困難的是「提出可能成功的方案」
- 「可能成功的方案」，意思要能「促使顧客轉換」到你的產品
- 不管先前他們用誰的產品。這做起來非常難。
很多新手產品人會用「功能均等」 (Feature Parity) 的策略
- 以為只要具備「頭號競爭對手提供的所有功能或服務」，就可以擁有很多客戶
- 但這不可能成功!!!
要讓顧客願意轉換到我們的新產品
- 顧客得相信新產品能提供比過去好上 10 倍的成果，顧客才會願意忍受所有轉換過程的痛苦
這就是為什麼做產品很困難
- 產品必須被認為是「顯著的好上很多」
- 而這不會從「產品規劃」 (Product Planning) 中達成
你可以做一堆規劃但產品也不怎麼樣，因為這要從「製作原型」 (prototyping) 來達成
- 這就是產品探索，嘗試各種點子、驗證哪些概念可行
- 持續在探索中迭代，直到找到有可能成功的方案。
所以我想強調的是
- 如果要解決一個困難的問題，的確需要花一點時間做規劃、做分析
- 但應該要花大部分的時間來做探索 (Discovery)、提出一個有可能成功的方案
- 如果你不這麼做，你不會有更多時間
有很多 PM 喜愛做規劃
- 他們很愛手上的試算表，他們就從中獲得很多樂趣
遇到這樣的人，恩，我會說「ok 很好，但這不是你的工作！」這也只是簡單的部分
- 困難的部分是當你把手弄髒的時候，你必須坐下來、找設計師和工程師，一起提出可行的方案
- 任何世界上的規劃技巧都不會帶你找到可行的方案
我想更清楚的指出
- 如果你是 PM 或產品設計師，你大部分的工作天都應該花在製作原型 (prototyping)
當然，是由產品設計師製作這些原型
- 然後由 PM 來親自試用、測試、從中學習
- 但你們也是一起透過製作原型 (prototyping) 來迭代 (iterate)
- PM 與設計師運用原型，工程師運用程式碼，這就說明了我們如何一起工作
基本上這就是你大部分的工作
- 你將展示 prototypes 給不同類型的用戶、顧客、利益關係人
- 你將會在團隊中測試它們，這才是 PM 與設計師的真正工作
- 這也是為什麼我們需要真正的 「產品設計師」(Product Designer)
- 今日設計師受訓練的方式也正是透過製作原型 (prototyping)，這對我們很關鍵。
再強調一次，所有的 prototypes 都是不是真正的、完整的產品。除此之外
- 有 4 種不同類型的 prototypes，所有優良的產品團隊都要善用 4 種 prototypes
- 實際上也需要 4 種 prototypes 來面對不同的工作、處理不同的風險
- 有些專門用來量化測試，有些則用來質化測試，所以優良團隊都需要做這些。
以上，就是為什麼我們要平衡 planning 與 prototyping。
關於 Marty Cagan 提到的 4 種原型，在 INSPIRED 的第 45 到 49 章，分別介紹了原型的原則，以及 4 種原型
• 實行性原型 (Feasibility Prototypes)
• 用戶原型 (User Prototypes, Low-Fidelity or High-Fidelity)
• 即時資料原型 (Live-Data Prototypes)
• 混合原型 (Hybrids)
也可在這篇文章，找到簡短介紹。
這個問題很常見。當我們被賦予一個問題
- 例如要改善國際的購買比例，或
- 要降低流失率，或
- 要增加營收，或
- 要找到新市場的第一個參考客戶
不管是什麼目標、要解決什麼問題
- 我們很自然的會立刻獲得一些點子，不管是自己想的或他人提供的。
- 然後，我們就決定嘗試這個點子，立刻開始製作原型
這很好，但問題是
- 如果這是我們唯一認真考慮的點子，而且這個原型其實最後不成功
那然後呢？該怎麼辦？
很多團隊接著採取的行動
- 就是繼續製作原型 (prototyping)、繼續 20、30、50 次迭代
- 直到他們用完所有的時間，或直到放棄
其實，你真正想要理解的是「總是有很多種解決問題的方法」
- 所以當在做少量規劃的時候，你要確保自己記得「這裡有 5 種解決問題的方法」
- 至少要把這件事記在心上。我們認為其中一個方法最好，所以從這裡開始
- 但如果我們沒獲得成果，我們就要嘗試下一個
舉例來說，有個 Teresa Torres 和我都呼籲的方法，叫做「機會與方案樹狀圖」 (Opportunity Solution Tree)
除 4 大風險之外，我常鼓勵團隊多考慮第 5 個風險，也就是道德風險 (Ethical Risk)
- 就是問自己：我們應該打造這個產品嗎？
- 就算用戶喜歡我們的產品，這對用戶來說真的是件好事嗎？
- 而且不只是對用戶，也要想這對社會是好的嗎？
- 對我們事業是好的嗎？這合法嗎？
如果你看到打造中的產品有什麼問題，你真的會想要提出這個議題
- 向你的主管提出討論
- 甚至向你的 CEO 提出
這是個很敏感的問題
- 你需要和緩地、輕巧地提出，你要確保自己做足功課，真正瞭解事業如何運作
有非常多做產品優化上很棒的工具，例如
Optimizely、Google Optimize
這裡講的「產品優化」 (optimization)，指的是
- 低風險、線上流量、即時資料的 AB Testing
我們基本上是微調各種元件，
- 哪一個成效更好，最常見的就是做在轉換漏斗 (funnel) 上
強烈建議每個團隊
- 只要你有正在線上的產品，獲得了真實的流量，就應該執行這些測試，沒有任何不這麼做的理由
但問題是，我看到很多公司
- 這就是他們做的「所有事情」了
- 如果這是你唯一做的事情，你正在一個緩慢死亡的道路上
因為這只是「捕捉價值」 (value capture)
- 就像提高價格一樣。這是件好事，沒什麼不對
- 但如果你只做這件事，你只是逐漸消耗價值而已
身為產品人的工作
- 要創造更多價值、大於我們捕捉到的價值
產品探索 (Product Discovery)
- 就為了「創造價值」 (value creation)
產品優化 (Product Optimization)
- 只為了捕捉價值 (value capture)。
所以，不要只做產品優化，要確保你創造更多價值。
你剛認識一間公司，他們的 CEO 非常相信量化驅動的決策
另一些公司的 CEO 極度相信她或他的直覺，這則是非常質化導向的文化
每一個優秀的產品公司
- 沒有例外，都必須擅長兩種方法，因為它們回答很不一樣的問題
量化測試告訴我們
- 「實際上發生哪些現象」
- 但它的限制和主要的問題，就是無法告訴我們為什麼
量化分析
- 能告訴我們「App 中 3% 的用戶使用此功能」
- 但沒法告訴我們「為何另外 97% 的用戶不使用」
- 質化測試就在此時派上用場
兩種都用，因為兩種都有偏誤，兩種很不一樣但都有用。
幾乎所有之前提到的議題，都有賴於具備核心能力的 PM
我們產業的一個大問題
- 產品負責人 (Product Owner) 還是 PM (Product Manager) 都欠缺足夠的訓練
- 他們還不具備足夠的核心能力。
這裡要清楚解釋一下
- PM 是工作上的職稱
- PO 是這些人在敏捷團隊中扮演的角色
如果你有一個 PO，其本身的工作職稱不是 PM
- 那是另一個問題，通常你要確保 PM 就是 PO
回到 PM 的核心能力，到底是什麼呢？
- 對用戶和顧客的深入知識
- 對用戶資料的深入知識
- 對事業的深入知識
- 對產業的深入知識
作為一個 PM
- 產品團隊有賴你提供以上知識
如果你是功能團隊 Feature Team 的 PM
- 你並不需要這些
- 你最需要的是足夠的專案管理能力
如果希望在被授權的產品團隊擔任 PM
- 那這些也就是你給自己的約定
- 和你一起工作的設計師和工程師也都有賴你為團隊提供這些知識
因為要是你沒有，那每一個決定都要提報給 CEO 或某個 executives (executive)，或者你要召集很多利益相關人會議 (stakeholder meeting)，在會議中要大家對每一個決定投票，這些都是惡夢。
(1) 對用戶和顧客的深入知識
- 對用戶和顧客的深入知識，這通常要 PM 花上 3 到 4 個月來養成
我時常收到 PM 的抱怨
- 會抱怨 CEO 持續地推翻自己的決定。遇到這種狀況
我會問這些 PM
- 「好，那請告訴我，上次你遇到客戶是什麼時候？」
- 通常答案是上個月或上一季
然後我接著問
- 「好，那上次你的 CEO 遇到客戶是什麼時候？」
- 通常答案是「幾乎每一天」
因為 CEO 會頻繁地拜訪客戶、或客戶會自己找上門。如果是這樣
- 那我就會說：「聽著，如果我是你的 CEO ，我也不會信任你的決定。為何世上會有 CEO ，讓不瞭解客戶的 PM (Product Manager) 做決定呢？」
- 期待發生這種事，並不實際。
PM 最基本的知識
- 就是要真的非常了解用戶或客戶
- 你必須被認為是最了解用戶或顧客的一位專家
- 對大眾 2C 產品來說這可能不會太難，但對企業 2B 軟體來說這需要很多工作
- 因為 B2B 產品可以很複雜
- 要各種不同的用戶，包含負責評估採購、負責批審預算的人， PM 要了解這裡面的動態關係。
(2) 對用戶資料的深入知識
- 要對顧客使用產品所產生的實際資料，有深入的知識
- 今天的 PM ，每天早上剛開始時，應該要花 1 到 1.5 小時在數據工具上
- 至少有 3 種看數據的角度與工具
- 第一種是看用戶如何在各種裝置上使用產品
- 第二種是看長期的數據變化
- 第三種是看銷售數據和銷售行銷活動的表現
團隊有賴 PM 具備這些知識，所以當我們每週做即時數據測試的時候，團隊希望知道我們的產品表現如何。這是另一種了解用戶的方式， PM 必須帶給團隊。
(3) 對事業的深入知識
- 誠實的說，很多 PM 最不喜歡的工作就是第三個
- 但這也是 4 個核心能力中第二重要的部分
在被授權的產品團隊
- 一位厲害的 PM 就如同這個產品的 CEO
所謂的瞭解事業，就是說你要很了解
- 「哪些營收支付了這個產品的開發與營運？經費從哪來？成本結構是如何？」
- 還必須了解產品如何被行銷、如何被銷售、如何進入市場、如何抵達顧客面前
- 還必須了解過程中的各種限制，例如政府法規、隱私、商業合約等所有的限制
- 甚至還有如何做售後服務、如何異業合作
必須了解這個事業的各種面向
- 因為必須確保團隊打造的產品能夠成功抵達顧客面前、為公司創造營收
- 支付相關的成本
這就是第三個核心能力。
(4) 對產業的深入知識
- 譬如說，目前的競爭格局、重大趨勢
- 機器學習對我們的產品重要嗎？
你必須有個看法
- 做產品很大的挑戰是要一直往未來思考
所以，這些就是 PM 被期待的標準，這就是夠格的 PM 的內涵。如果你是 PM ，你主管的職責就是確保達到標準，否則你不能為團隊做任何決定。
我可以跟你保證，如果 PM 的主管們真的落實這件事，今天將是很不一樣的世界
- 很可惜的是他們沒有做到
- 因為他們多數人也不知道這是怎麼一回事、他們自己從沒做過
- 他們從沒看其他人做好過、或他們從沒待過這樣運作的公司，所以對他們來說這也很困難
但總之，就我的底線來說，每當我遇到不夠格的 PM ，通常都是他們沒被好好的訓練、沒被好好的輔導，所以我的挫折感不是針對這位 PM ，是針對他們的主管，因為我們要對主管問責，確保他們帶好 PM 。 我時常跟主管們說
- 你頂多就和你最弱的那個 PM 一樣強，所以你真的要好好花時間輔導和提升 PM 們
- 這是產品領導者最重要的職責
Marty Cagan 對輔導 PM 有多重視？，至少寫了 11 篇關於「如何輔導 PM 」的文章
- https://svpg.com/the-coaching-series/
- Coaching Tools – The Assessment
- Coaching Tools – The Plan
- Coaching Tools – The One on One
如果你不確定自己的團隊是「被授權的產品團隊」或「功能團隊」 (Feature Team) ？
- 首先呢，如果你有這個困惑，你們很可能就是個功能團隊
有簡單的 3 個測驗，表示這是一家有「被授權的產品團隊」的良好公司。
- 有真正的跨專業跨領域團隊嗎？對產品來說，要做好這個產品，需要哪些專業技能？通常來說
- 是需要 PM 和產品設計師。產品設計師，指的是一位精通服務設計 (Service Design)、交互設計 (Interaction Design)、視覺設計 (Visual Design)、甚至通常是受過用戶研究 (User Research) 訓練的人，這是一個典型的「產品與用戶體驗設計師」 (Product / UX Designer) 的技能組合
- 更直白的說，我們真正仰賴的技能是交互設計 (Interaction Design)，這比視覺設計 (Visual Design) 的要求還更多
- 真的被授權嗎？
- 他們有被賦予要解決的問題嗎，而不是被賦予要交付的功能？
- 要被解決的問題，可能是商業的問題、用戶的問題，總之就是一個待解決的問題
- 而不是要交付的功能，或要完成的專案
- 而且，團隊被允許使用最佳的方式來解決問題嗎？這些是備授權的團隊的主要概念。
- 他們被問責和被衡量的方式
- 是根據解決問題了嗎？換句話說，是衡量他們的成果 (outcome)
- 而不是他們的產出 (output)？
「變現時間」 (Time to Money)
- 變現時間的重點是「真正解決問題的時刻」 (time to actually solving the problem)
- 如果問題是流失率是毫無永續性的 12%，我們知道我們的商業模式將會崩解，除非我們把流失率降低到 6%
- 在降到 6% 之前都不能慶祝。這就是我們說的變現時間
所有我認識的世上最好的團隊，都很真實的落實這三件事
- 這裡面沒什麼神奇的魔法，你沒有什麼做不到這三件事的理由
- 你沒有這麼做的主要理由，通常主要原因是 CEO 還不信任這個產品團隊
- 為了獲得這樣的信任，我們要回到有能力展現核心能力的 PM 身上，就是先前我談的那些能力，就是這些讓我們贏得 CEO 的信任。
其實當我坐下來訓練團隊的時候
- 我會列 5 個核心能力，而這就是第 5 個
我仍會遇到產品人真的不太了解他們的產品
- 而這很荒謬。你能夠想像這樣的事嗎？當一個 PM ，居然不了解他負責的產品？
- 這在面向「消費者的產品」很罕見
- 因為這些產品通常很直白、很直觀
- 但對面向企業客戶的產品來說，有些產品真的很複雜。
負責這些產品的 PM
- 若不是該項產品的專家，就有很大的問題了
- 是非常嚴重的問題，我不認為任何人，包含工程師，對這樣的 PM 還有任何尊重。
問： 關於「贏得信任的被授權團隊」，我們公司曾經嘗試要做到
- 但你如何讓工程師和設計師也一起找到適合的方案？
- 如果工程師不夠瞭解使用者、客戶，工程師還沒有這樣的觀念
- 他們只想完成這個功能 (feature)、只想把任務搞定，他們只想完成他們的工作
那這樣的話，我們如何能夠促使他們一起找到更好的方案，而不僅是讓他們做完工程和設計的工作而已？
我用兩個面向來講，因為這兩項都很重要。你的問題基本上是在說
- 「如果你有個工程師，他就只想被告知要打造的功能，而不想幫大家一起找到更好的方案」
問： 也許他們想幫助，但他們也需要知道更多 (顧客或市場的) 資訊？
- M： 很好，如果他們有意願，我們就快要成功了
不想參與探索的工程師
- 需要資深的模範
如果是他們不想幫忙的情況，那我也要給你很務實的建議。其實你需要的不多
- 就只需要一個願意幫忙資深工程師，這樣你就可以成功了
如果你連一個願意幫忙的資深工程師都沒有
- 那你就有一個棘手的問題。這時你需要去找上技術長，告訴他你至少需要一位這樣的人
在大部分良好的產品公司裡面
- 你不可能從資深工程師晉身到技術主管，除非你展現了「幫助探索產品方案」的意願與能力。
換句話說
- 良好的工程師不會只想寫程式，他們想要發明與創造
- 特別是那些優秀的產品公司，幾乎所有的工程師都想參與產品探索
- 這些人都不想打造一些沒人要用的東西
想參與探索工程師，是最佳的創新來源
- 假設工程師願意幫忙，但你也知道他們主要的工作是開發軟體，他們很可能沒太多時間，或他們沒有相關的知識，這是個比較大的議題
這時候，你得體認一個產品的小秘密，一個沒講太多、但其實非常重要的小秘密：
- 只有一個創新的最佳來源，不是來自我們的顧客、不是高層主管、不是 PM 、不是設計師，而是來自工程師。
這個現象的原因
- 是因為工程師每天都和技術為伍，這讓他們處於一個絕佳的位置，去看到「此刻的可能性」 (what’s just now possible)，這就是卓越產品的來源
我也要說
- 只有很少數的事情，可以比「 PM 與設計師，帶著工程師一起見客戶」來得更有用
很多 PM 告訴我，他們懼怕做這件事，因為
- 他們不想以「給你們見見這位不爽的顧客」來打擊工程師的士氣
我就會搖頭，告訴他們
- 「你們把整個因果關係搞反了！對工程師最佳的心理動力，就是看見正在受苦的顧客！看他們多麽想要矯正這個情況！」他們真的想這個做
- 我沒在跟你開玩笑。這是很真實的情況
- 這是卓越創新的來源。所以說，「帶著工程師去見客戶」是神奇的魔法
接觸用戶的最低要求
- 如果你負責面向「消費者的產品」
- 你至少每週要有 3 次與用戶互動的時間，每次 1 小時，這是最低期待
- 如果你正在推動大改版
- 可能要提高成 5 到 10 小時
但這真的是偉大產品的來源
- 透過向工程師展示、分享各種問題，來啟發工程師的動力與靈感
- PM 提供問題的背景與情境
- 設計師瞭解用戶的心理模式、用戶期待的體驗
- 然後當然由工程師來瞭解哪些在技術上有可能性
當我們把這些人擺在一起，雖然沒保證，但理想上我們能獲得特別的成果。
- 這是個很棒的問題，因為這帶到了「我們必須怎樣做產品探索」的核心
- 而一個很常見的錯誤就是 PM 和設計師每週去和顧客互動，但他們沒有帶上工程師。你很難在這樣的情況下，獲得任何創新
問： 你提到我們有「功能團隊」 (Feature Team) 和「產品團隊」 (Product Team) ，那為什麼我們有那麼多的功能團隊？只因為他們沒有相關的知識嗎，還是只是不願意？
- 不信任產品團隊
當我和 CEO 聊到「為什麼你們要 (像功能團隊) 這樣運作？」
- 最基本的答案就是，不信任產品團隊
- 最主要是，他們並不信任 PM
- 通常他們也是對的，不要信任 PM，因為 PM 們還沒有做足功課
- 他們還沒做到我前面所說的
當他們向我指出這點的時候，我就會問
- 「那當初是誰聘請了這些 PM ？人不是我的啊，是你找的，對吧！所以也是你的錯。」
- 我就會進一步說「聽著，你得確保他們接受訓練。然後，你得給他們一個機會表現。
做好你的功課，如果你是一個功能團隊的 PM ，而你真的很想嘗試成為一個真正的 PM
- 認真的找設計師和工程師一起做我們談到的事情
- 你可以做的、最重要的事情，就是「做好你的功課」
- 也就是我列出來的「 PM 的 4 大核心能力」
- 你最重要的就是做好這些事
當你能夠做到這些，接著你就去找你的主管或 CEO
- 和他們說「可以給我們一個機會，嘗試用這樣的方式工作嗎？只要幾個月就好，讓我們嘗試。」
這時候
- 他們很可能會測試你，因為他們想知道你是否真的了解顧客、了解事業嗎？
- 如果他們認為你還沒有，他們當然不會信任你。同樣的，他們也不應該信任你。
如果他們相信你懂，那真的是一大進步。從那一刻開始，當 PM 贏得了 executives 們 (executives) 的信任
有好幾位 CEO 明白的告訴我
- 這就是他們遭遇的問題。他們相信那些 PM 真心想為客戶做出厲害的產品
- 他們也知道做產品的人都想這麼做，但是他們說「這些人對我們的事業如何運作，卻毫無概念」。
他們會説
- 這人很天真，或這人對財務、對績效指標一無所知
- 這些對他們好像是外星語言。怎麼會這樣呢？
我當然希望這些很簡單
- 我們只要打造顧客喜歡的產品就好了
- 但很不巧，產品也必須對我們的事業有益
所以說
- 做好功課當中的第 3 點，就是要有「對事業的深入知識」
- 對一個 PM 來說，要熟悉所有的 4 點功課，通常需要 3 個月，才能從新進人員到足以勝任的階段
- 花 3 月，其實不算太困難，但這同時需要 2 件事－願意做好功課的 PM ，以及願意幫助他們的主管。
問： 問題，和產品開發 (product development) 以及文件紀錄 (documentation) 有關
- 隨時間發展，產品變得越來越大，擁有很多的功能、錯誤處理、邏輯驗證，等等等。不僅如此
- 追蹤過去對產品做了些什麼，也變得越來越困難，因此必須做很多文件紀錄
但是，這其實和原型製作的概念有衝突。因為，當我們製作文件紀錄，都需要時間
- 但原型製作，如果僅為了測試一些點子，其實並不需要文件紀錄。所以，怎麼應對這樣的衝突問題？
M: 我把它拆分成 2 個問題，因為你描述的文件紀錄其實有 2 個目的
第一個目的，你必須和工程師和 QA 溝通「該打造什麼、應測試什麼」，
- 如果你有 QA 和你分工的話，要溝通商業邏輯是什麼、期待的結果是什麼
關於這部分的答案，其實很大程度地取決於
- 這是個共處一地的團隊 (co-located team) 或遠端的團隊 (remote team)？
共處一地的產品團隊 (co-located product team) 是大家的最愛，
- PM 、設計師、技術主管、還有幾位工程師，通常都坐得很靠近
- 產品原型就是他們彼此溝通的方式，你也就只需要非常少的文件紀錄
如果工程師在遠端，這就困難很多了
- 不只在遠端，還講不同語言、有不同文化
- 那現在你就有非常多的(文件紀錄) 工作要做
- 如果是這情況，會讓前進速度變慢很多
- 而且同時也不能取得工程師的高度參與
就是前面問題談到的
- 你急切需要的那種高度參與
- 所以，在那樣的模式之下，你會需要更多的文件紀錄
- 同時，我強烈努力讓至少保留一位資深工程師，坐在 PM 與設計師的旁邊
- 當他們都在同一地的時候，我們還是有一些文件紀錄的工作，但沒有那麼多。不過這在將來必定產生代價，等待償還。
第二種，文件紀錄(不曾管用的「產品編年史」)
- 就像我們繼承了一個產品，這產品大概有 5 年或 7 年那麼老了，已經存在好一段時間
- 所有當初設計產品的人都走光了，所以你根本不知道這東西可以幹嘛，沒有人知道
- 我們產業一直在找一個良好的方式，去紀錄我們做過的每一個 (產品設計或開發) 決策的背後思路
任何人唯一信任的東西
- 就是原始程式碼
- 多數的公司真的已經放棄了「文件紀錄我們為什麼這樣做」的目標
- 就算真的嘗試去文件紀錄它，人們也不相信，因為他們連「確認這是最新資訊」的方法都沒有
所以說，這是一個非常非常困難的問題
- 這也是為什麼多數人會直接走向技術主管，然後說「你可以看一下程式碼，這裡現在實際上發生什麼事嗎？」
這就是為什麼
- 我不會擔心第二個問題，但專注在第一個問題
- 並非常努力的嘗試擁有共處一地的產品團隊，在任何你還可以的時候。
依循不同的流程，假設有不同的目標
- 那怎麼轉變加入團隊的人？
- 你實際上會保持某些人一直都在探索活動中嗎？
- 還是說，你會讓探索團隊同時也扮演交付團隊？
很多人傾向於
- 把「探索」想成一個階段
- 把「交付」也想成一個階段
你不會想把它想成一個階段
- 其實就好比我們每一天、每一週，持續地做這些事。對探索也是一樣的
- 有時候你產生幾個產品待辦事項 (Product Backlog Items)，有時候你產生一大堆
- 這些不是許多階段，而是持續發生
事實上，我喜歡完整的描述為
- 「持續探索」 (continuous discovery)
- 「持續交付」 (continuous delivery)
如果現在看待成有兩種活動正在發生，你觀察的和提問的核心，其實是關於工作崗位的本質
- PM 和產品設計師的工作，和工程師的工作，有那麼一點不同
- 工程師主要的工作是完成交付、打造正式產品品質的程式碼
- 而 PM 和設計師主要的工作是搞清楚應該要打造什麼產品
接下來，我用比較長的方式，來描述我們如何管理這一切
- 我們會請工程師每天空出 30 分鐘，去參與探索活動。這真正的內涵是指「每天都要試用、把玩產品原型」
- 然後要尋找 2 件事
- 第一，你可以想出達成目標的更好方式嗎？
- 第二，在這個產品原型中，有任何事情使你感到緊張嗎？
- 如果答案是肯定的，就表示我們有很多種方式可以達成目標
事實上，工程師最常見的抱怨嗎？
- 不是我沒有時間參與探索，而是完全相反的
- 抱怨是「若 PM 曾在這點子最初產生的時候，就先和我聊聊，就算只花 2 分鐘也好，我們搞不好早就省下了好幾個月的工作！」
- 特別是跟技術債有關的議題、或決定
轉變成對團隊很具體的描述
- 如果工程師第一次看到一個產品點子的時機，就是衝刺規劃會議 (Sprint Planning)
- 那你就完全搞砸了
- 這正是多數公司採取的方式，因為他們不是用今天講的模式運作（沒有分成兩類活動－探索與交付）
- 在這樣的模式中，衝刺規劃會議只不過是個「選擇的時機」
- 這個會議只是關於「我們在下段衝刺要做什麼」的選擇而已
另一部分，PM 與產品設計師最主要的工作是探索
- 但我們仍要求他們每天花 1 小時，來回答交付過程中出現的問題
- 因為，不管你多麼在行，當工程師開始編寫程式時，永遠會冒出問題。就好像是「任何你沒想透徹的事情」
- 在這時候就會變得很明顯，而工程師現在就需要一個答案。
如果你夠幸運，能夠被設定在我前面提到的團隊，真正共處一地的產品團隊 (co-located product team)
- 有一個很不錯的事情會發生
- 就是每天 30 分鐘的互動會自動的發生
- 因為大家都在那裡，你就在我旁邊，你是工程師、我是設計師，你就成天看著我的產品原型
- 但如果我們不是坐在一起，那麼我們就需要那樣特定的時間，但那真的是關鍵
問： 在 B2B Product 的情境中，這有點難進行
- 因為要維持對客戶的系統穩定性
- 而且，每幾天就釋出一個新版，也有可能會嚇到我們的客戶
M：在這問題背後的真實對比是
- 在 B2C 的環境中，這些顧客也沒付錢使用這產品
這是個免費的服務
- 我們常常弄壞它，反正他們也沒付錢，我們修好它就是了
當然這是個誇飾，不是真實的，但就是類似這樣的看法
- 對於 B2B 產品，我們必須對改動更加敏感
- 關於這個，其實有一個叫做「衝擊分析」 (Impact Analysis) 的主題
- 以及一個 Gentle Deployment Technique。
關於這個問題真正的困難在於，當我們需要做產品更動
- 如果你們做的是需要內部部署的方案 (On-Premise Solution)，要在客戶那邊安裝伺服器與軟體
- 這大概是此問題最極端的型態
你可能希望每季釋出某些新東西
- 而你客戶的反應卻是「喔天啊，又是一個新版發佈！我們又給去驗證它、安裝它，我們還要確認所有東西都能動，還要重新訓練。」
- 經過了一年，他們可能會說「我們受夠這些了，我們每年只接收一次新版本。」
- 就算你可以每季釋出新版，這對你和你的客戶都不好，更別說一年一次。
- 客戶們的疑慮也是真實存在的
我們最主要的挑戰是
- 客戶們不應該重新測試、重新訓練，這些都不需要
- Firefox 和 Chrome 都這麼做，這些都是部署在你的手機和筆電上的軟體，也是內部部署的軟體 (On-Premise Software)
- 但他們無時無刻在更新，你只是不知道而已，這叫做靜默更新 (Silent Update)
他們知道
- 如果所有人每次都要為了瀏覽器而重新訓練，誰會願意這樣做啊？沒有人想要這樣！
- 所以他們知道要自動地更新，這就是 Gentle Deployment Technique 的例子
高端的 B2B 軟體
- 他們持續的在更新，但他們刻意設計這些更動，所以使用者不用重新訓練
有一整個關於這些的主題，
- google 搜尋 Gentle Deployment Technique
- 如果這是一個重大變更，叫做 Parallel Deployment，讓用戶可以依照自己的步調，選擇何時從舊版升級到新版
所以，我們有非常多的方式可以做到，但對一個現代公司
- 我最關注的要求就是「不應強制顧客重頭驗證」
- 他們正在這樣做，只因為你做為一個供應商，還沒做到你該做的事情
問： 可以請你多談談目標 (Objectives) 嗎？
- 在一個面對消費者個事業，我們如何知道這是一個比較重要的目標，我們想要解決它？
- 在產品團隊之外，我們如何分解目標，然後設定成產品團隊的目標？
M： 這是個很大的問題。針對問題，我重述這個問題
- 為何 OKR (Objectives and Key Results 目標和關鍵成果) 是這麼痛苦？
「功能團隊」並不適用 OKR
- 很多實施 OKR 的公司，他們擁有的只是「功能團隊」 (Feature Team)
- 但在功能團隊上實施 OKR，概念上本身就很荒謬
- 一邊我們告訴你「這裡有個等待被解決的問題」，然後又說「喔不過，順帶一提，這是你的功能路線圖」
那種情況根本不合理。當然，這不是你確切的問題，不過某種程度上這在問題的背後。
如果已經是被授權團隊的模式 (Empowered Team Model)
- 那 OKR 本身並不是困難的事情
- 但如果你不是被授權的產品團隊，我根本不會推薦使用 OKR
- 他們互相不適合。這也是為什麼，有那麼多公司在 OKR 上遇到了那麼多混亂。
你同時也問了，目標 (Objectives) 從哪裡來？
- 「設定目標」是管理者的工作
因為我告訴你們「被授權團隊的模式」，這只是事情的一半，我並沒有提到另一半
- 當我提到 Empowered Product Team，這個團隊會被賦予一個目標 (Objective)
- 而這個團隊有能力產生解決問題的最佳方式，但我沒說的就是「目標從哪來」
這矛盾的來由，其實是因為「目標不應該來自團隊」
- 這其實是管理者的工作!!
我們談到，如何從功能團隊轉型，從功能路線圖轉變成目標？
- 當我們請求主管們給團隊一個機會，試試看，你並不是從他們身上拿走所有的事情
- 你仍然要讓他們告訴你「哪些是現在最重要、最需被解決的問題」
主管們說「最重要、需被解決的問題是留存率，這現在很糟糕，我們必須解決」
- 這是他們的工作，就是告訴你「什麼是最重要的問題」
- 然後，找出最好的解決辦法，就是我們身為團隊的工作
所以說，當一間公司想轉換成 OKR 時
- 一個很常見的錯誤就是，讓每個團隊自己決定 OKR
- 這樣事情該如何結束，每季或每年結束時，該如何達成商業目標？
應該是
- 目標來自主管們
- 關鍵成果來自團隊，這是 OKR 背後的基本想法
再說一次，真正搗亂這些的因素
- 是很多公司只是運作功能團隊 (Feature Team) 所以總之他們並不真的有導入 OKR 的環境
問： 在很多談話中，會假定足夠的工程資源就在那邊。那如果一個 PM 沒有足夠的資源，以我的狀況，我要和另一個專案共享同一個工程師，你會如何應對這樣的情況？
M： 我在這邊談到的產品團隊，或小隊 (Squads)，這些都是專責的團隊
你和許多 PM 共用工程師，這叫做共享池模式 (Pool Model)
- 這是個很糟糕的模式，我知道有些老牌的技術長、資訊長會認為這比較有效率，但當然這其實更加沒效率
- 因為這些工程師並不是棋盤上的棋子，可以隨時被移動到不同的遊戲中，這些是需要花時間深入事情並創新的人。所以，這是個不同的模式。
我們先假設你不是這樣運作，且你有專責團隊
- 你可能會遇到一個普遍的情況，就是一個 PM 身邊沒有產品設計師
- 如果你是做面對大眾的產品，沒有設計師，會是很困難的挑戰
通常會發生的一個不太好的現象
- 就是 PM 嘗試著扮演設計師。這是相當棘手的事情
- 學習使用設計工具非常簡單，但這不會讓你成為一個設計師，所以你會獲得很多可預期的糟糕設計。
我常常必須和 CEO 有這樣的對話
- 和他說「如果你有這麼多工程師，你正在浪費很多錢，除非你有足夠數量的設計師」
- 如果你有 50 位工程師，你不需要 50 位設計師，但你很可能需要 5 位
- 如果你沒有這 5 位，就從工程那邊釋出 5 個位子，轉移到設計上，你將會完成更多事情，而且是更好的成果
所以，我們必須調整
- 才能確保每個團隊都在做他們必須做的事情
- 最低的限度，如果你做的是面對消費者的產品，至少是 1 位 PM 和 1 位設計師，搭配至少 2 位工程師
- 最多 10 到 12 位工程師，大概就是這個區間，取決於這個軟體產品的性質。
問： 你經常談到原型製作，我想知道原型製作如何搭配產品路線圖？因為我的一些團隊成員很想考慮一致性和可擴展性，有時候我們運用敏捷的方法，他們會感到不自在，因為我們會不知道在下一個衝刺迭代 (Sprint) 將要做些什麼。
有一件很重要的事情，就是產品團隊上的每一個人，從 PM 開始，以及所有優良的工程師
- 他們不只是必須知道這個衝刺迭代 (Sprint) 正要做什麼
- 還要知道未來好幾個月正準備做些什麼
- 如果你是資深架構工程師、或技術主管，你必須要知道未來好幾年可能發生什麼事情。
這是什麼意思，提出一整年的路線圖嗎？當然不是
- 但這確實表示要提出產品願景
說到產品願景，要澄清這是另一個常見的問題
- 就是每個團隊都提出自己的產品願景，這和每個團隊提出自己的目標一樣瘋狂
- 產品願景的重點，就是那些我們所有團隊的共通點
- 不過，產品願景是大約介於 3 年到 10 年之後的未來
工程師、設計師那麼迫切的需要它的原因
- 就是因為他們必須確保他們擁有一個到位的架構，可以滿足事業上的需求
- 如果你只給他們一兩個衝刺迭代 (Sprint) 的能見度，他們沒有辦法做好他們的工作
- 那樣的能見度非常重要。
路線圖則是另一個問題，路線圖使我們陷入困境
- 因為，現在那邊有了各種細節，而這些細節將會改變
- Amazon Jeff Bezos 的名言，我覺得他完全抓到這個要點，他說「對願景要固執，對細節要彈性」
意思是説不要放棄你的願景
- 通常亞馬遜會提出一個 7 年的願景
- 路線圖就是細節
如果路線圖只是你們的點子清單，那不會有什麼問題，但路線圖從來不是這樣。我們之所以會陷入困境的原因
- 就是一旦你放了某些東西到一個稱之為「路線圖」的文件上，我跟你保證，你的 executives 們 (executives) 將會把它視為一個承諾
- 到了那個時刻，你就被困住了，那些不再是點子，是承諾。而且那就是我們陷入困境的地方
有沒有什麼探索上好用的技巧？
- 因為我們團隊花大多數的時間做產品優化 (optimization)，而就像你說過的
- 優化可以看到比較能預期的結果，探索有時候是很多的風險
所以，當我們有個目標，為了這個月或這一季的目標
- 我們容易傾向花更多時間做優化，而不是探索
事實上，我為此撰寫了一本書，剛好最近被翻譯
- INSPIRED: 產品專案管理全書
- 當我和一個產品團隊坐下來討論時，光要涵蓋最核心的技巧就需要兩天
- 不去冒險才最危險
- 就像你說的，探索就關於風險，全部都和冒險有關
- 探索就是很多的「製作原型」 (prototyping)
- 正如我說的有 4 種原型，而我們有 4 種風險：價值 (Value)、易用性 (Usability) 、實行性 (Feasibility)、商業可行性 (Viability)
所以
- 我們有不同的方式，去測試每一個風險
- 然後我們有質性的和量化的方法來做測試
這不是一個簡單的答案，但當然有真實的答案在那裡，我當然強烈的鼓勵你這麼做。
問： Marty 想問的是，當 executives 們給出的要求，實在是非常巨大的時候，產品團隊可以採取哪些途徑？譬如說
- 要產品團隊為這家公司找到「下一件大事」 (the next big thing)
- 找到下一個重大的產品
- 下一個新客群、下一個用戶會喜愛的產品、會賺錢的產品？
M：其實我正在寫一篇文章，「如何為了誠信而輔導」 (How to Coach for Integrity)？因為這正是你要面對的情況
- 特別是 PM ，很多時候會被要求一些他們完全不知道自己能不能辦到的事情
- 如果你給了承諾，但沒有做到，你大概很可能會傷害到你先前對主管們建立的信任
- 同時，附帶的，如果你的工程師和設計師認為你瘋了，他們也將會對你失去信心
- (可能是這篇 https://svpg.com/managing-commitments-in-an-agile-team/ )
所以，「你如何應對這樣的情況」是個很常見的問題。
這樣的情況和「設定期待」很有關係。我會建議，有一個技巧叫做「高誠信的承諾」 (high-integrity commitment)
- 好比「你如何給一個承諾，當這是一個超困難的問題，而且我們今天並不知道答案」
- 有一個好方式去應對這的情況，會多花掉一點時間，但結果是一個有更高信心度的承諾
我會 Google 去搜尋這個關鍵詞，「高誠信的承諾」 (high-integrity commitment)
- 這將會對你有幫助，不過我也覺得我正在寫的那邊文章，也能對此有所幫助
設定期待很關鍵，因為其實有兩種目標、兩種關鍵成果
- 一種叫進取型、挑戰型 (aspirational)
- 這就是 CEO 説「聽著，我們不是要求你小改善，去獲得 5% 或 10% 改進。我們要求的是，對我們的事業有 10 倍的進步」
- 想想看，10 倍，多麼的巨大，當他們說這些的時候，他們也會説「我們也知道這並不簡單，獲得 10 倍改善的機會並不高，但你知道的，我們想要請求我們的團隊去真的試試看。」
- 有些人把這些比喻成「射月」 (Moonshot) 和「射屋」 (Roofshot)。射向屋頂並不困難。但如果你射向月亮，就算沒有真的抵達月亮，仍然遠遠超出房子的範圍，就是這樣的想法
所以，挑戰型的關鍵成果 (aspirational key results)
- 而且團隊要被明確的告知，你們要追逐下一個大事件
- 你們不應該那邊做優化
- 所以「射月」才是我們希望你們追逐的目標
- 這是風險很高的事情，所以挑戰型的關鍵成果，這些並沒有「高誠信的承諾」
另一種關鍵成果
- 就是說，告訴我「什麼是你很確定這一季絕對能夠交付的事情」？
- 這叫做高誠信的承諾，你也可以把那當做「射屋」，是你知道你做得到的事情
這是一個很大的主題，但不一定是不好的事情，很多團隊喜歡處理這樣的事情