我看《矽谷最夯．產品專案管理全書：專案管理大師教你用可實踐的流程打造人》：踏上產品經理之路

當我認識一個產品團隊的時候，我會觀察 3 件事，來判斷他們做產品的能力有多深。 第一件事，就是他們是否在進入交付階段前，就著手處理讓產品失敗的 4 大風險，這時候通常不需要寫任何一行程式碼。 第二件事，就是他們實際上用什麼方式解決問題。我期待他們結合了產品經理、設計師、工程師，讓彼此交互切磋，然後產生一個最好的方法。他們是用共同協作的模式來解決問題，還是用依序接力的方式來解決問題？在過去瀑布式 (Waterfall) 的模式下，產品經理會定義產品需求規格，然後丟給設計師來負責把畫面弄好看，然後再把一整包爛攤子丟給工程師。若是在衝刺規劃會議 (Sprint Planning) 上才第一次跟大家說「開始打造這一切」，雖然有 Scrum 裡面的衝刺規劃會議，且這些人說他們很敏捷 (agile)，但這根本不是敏捷，這只是瀑布式，因為人們就是在彼此接手各種工作而已。 第三件事，就是他們被賦予的目標。如果他們被賦予的是發佈功能，那只是個「產出」 (output)。如果他們被賦予的是解決問題，那正是個「成果」 (outcome)。我期待看到的是專注在成果 (outcome)，並以成果來衡量自己的團隊。 如果有發生這三件事，其他的議題也就不太重要，為此我就能判斷這是一個良好的團隊。 很多公司，也可說是大多數我在世界各地遇到的公司，大體上都知道做產品的基本知識。他們知道不只需要工程師，還需要產品經理、設計師，大多數都建立了跨專業跨領域的團隊。有些公司稱這樣的編制為「產品團隊」，這也是我常用的稱呼，而有些則喜歡用 Spotify 的方式稱呼為 Squad。這些都很好，但問題是要建立這樣的團隊編制並不難，困難的是要能在前面那 3 件事上面，落實的夠徹底、夠深遠。很多公司仍然只是制定產品路線圖，賦予給團隊的任務不是探索與交付，只是設計與開發。 有些公司甚至還聲稱有「探索階段」，但實質上我知道他們並沒有這麼做，因為我會用這個問題來探測：「你們在探索階段會測試多少原型？你們在交付階段又會打造多少？」如果他們說：「喔，上個月我們在探索階段測試了 10 個項目，然後這個月我們打造了 10 個項目。」這樣我就知道這不是探索，這只是設計，也許附帶一點點易用性測試，並不是真的在測試點子。如果他們很認真實施探索階段，很認真的測試 4 大風險，他們必然要拋棄非常多當初的點子，至少要拋棄一半。附帶一提，真正優良的產品公司甚至會拋棄 80% 到 90% 的原始點子。微軟最近在哈佛商業評論 (Harvard Business Review) 上公開地說，他們大概只有 10% 的點子真的可行。 如果他們沒有真正落實探索階段，儘管這些公司稱呼團隊為「產品團隊」 (Product Team) 或 Squad，他們實際上仍然只是個「功能團隊」 (Feature Team)，而且世界上大多數的公司都是這個樣子。他們有產品經理 (Product Manager)、有設計師和工程師，但他們的產品經理實際上只是個專案經理 (Project Manager)，這真的很常見。 我們回顧一下打造產品的 4 大風險： 價值 (Value)、易用性 (Usability) 、實行性 (Feasibility)、商業可行性 (Viability)。你可能知道設計師要負責易用性，當然他們大可以貢獻更多。你也知道工程師要負責實行性，當然他們也是大可以貢獻更多。 如果你只是一個被交付「路線圖」 (Roadmap) 的功能團隊 (Feature Team)，實際上有一個不那麼明顯的狀況正在發生： 若某個公司內的高管 (executives) 或利益相關人 (stakeholders)，只要他們要求把某個項目加到產品路線圖中，這個人其實就負責了該項目的價值風險 (value risk)。舉例來說，如果某個人說「我們必須加上 PayPal 這個支付方式」，不管是誰說的，這個人肯定是相信這件事有價值，他才這麼說，否則他就不會這樣說。同時間，這人其實也負責了這個項目的「商業可行性」 (business viability)。這時候，產品經理實際上要負責的是專案管理。 如果這是一個被授權的產品團隊 (Empowered Product Team)，他們被交付的是問題與目標，而不是產品路線圖。在真正的產品團隊中，產品經理則要負責的是這個解法能夠 (為用戶) ...

We are all learning how to manage product in the internet age. There have been many successes and failures, and there are still lots more to come. Marty Cagan has worked at plenty of internet successes and failures, including eBay, Netscape and HP. He now heads up Silicon Valley Product Group, where he works with [...]Read More...

在打造產品的時候，通常我們就只會在意如何打造與交付，也就是 Delivery；包含用什麼樣的技術、規格有哪些、多少人花多少時間等等。但是，我們有真正去思考過，為什麼要做這個產品嗎? 所以，在開始動工之前，應該要先去思考想要解決的是什麼問題，也就是 Discovery。例如愛因斯坦的名言，「如果我有一小時可以拯救世界，那我會先花 55 分鐘去定義問題」。 如果沒有先確認要解決的是什麼問題，那可能就會做出一個沒有人買的產品、或者就只是做出一個跟大家一樣的產品，像是經典的「更快的馬與汽車」的案例。 而且，直接找出問題背後的問題，還可以讓你去思考是否有其他的解法。例如想要更快地到達目的地，可能需要的不是更快的馬、也不是汽車，因為背後要解決的問題是想要更快速吃到好吃的東西，那也許外送服務會是更適合的做法。 講者在這邊提到的最小可行性產品 (MVP, Minimal Viable Product) 其實指的是幾天、甚至幾小時就可以打造出來進行測試的 Prototype，而不是一個需要花幾個月打造的 Product。 例如下圖，要更快到達目的地有各種解法，當然滿足需求的程度也不同。而滿足使用者的程度、要花費的成本等等也都是需要在 Discovery 階段透過 Prototype 與各種驗證方式去評估的。最後決定方案後，才是進入 Delivery 階段，去把產品打造出來。 講者後來在 Q&A 時也有再帶到這段，所謂驗證不同的 Prototype，是去進行各種不同解法的驗證 (例如下圖的腳踏車、機車、汽車)，而不是同一個解法去做 Iterate、去疊加各種優化上去 (例如腳踏車、和競速用的流線型腳踏車)。 所謂 Feature Team 指的就是接到指令說要做什麼產品，然後就把它打造出來的團隊。講者也有提到其實絕大部分的公司都是使用這種團隊，單純為了做出那個產品而做；所以團隊裡面的 PM 其實是 Project Manager，想辦法讓產品準時交付。 而 Product Team 拿到的則是要解決的問題 (例如上面提到的更快到達目的地)，然後再去思考、評估要用什麼樣的方法解決問題。也就是加入了 Discovery 的部分，這種團隊中的 PM 才能夠稱為 Product Manager，這也才是 PM 應該要做的工作內容。 當然，團隊如何組成、以及團隊拿到的是功能需求、還是待解決的問題，其實也和公司的組織架構與管理階層有很大關係。講者也提供了三個判斷自己的團隊是否為 Product Team 的指標，如下，還特別提到如果無法回答或不太確定，那通常也是 Feature Team...

"Product is hard" 這題目也太精闢且血淚了，Marty Cagan 的引言是這樣講的： We'll talk about politics, culture and even (process) religion. We'll discuss prioritization and decision making, especially when we don't have as much data as we'd like; handling very difficult people especially senior executives; managing conflict on the team; dealing with low morale; changing company culture; regaining control of your time, and picking your battles.