為什麼他們成功你失敗？科技大廠的產品開發祕技
「INSPIRED — How to Create Tech Products Customers Love」讀書筆記（1）
多數科技公司失敗的原因
很多公司花了很多資源、時間打造使用者不買單的產品。產品能不能成功重點不在你的工程團隊有多優秀，而是你有沒有給他們值得打造的產品。作者覺得產品前期的探索階段，非常重要。產品開發流程的差異，也導致最終結果的不同。作者在書中提出一般公司的做法，以及他們為何失敗，也提出一流公司的做法，作為比較和建議。
Chapter 1 Behind Every Great Product
作者認為每個好產品的背後，都有一位推手。他不分晝夜的工作，一週工作可能超過六十小時。領導產品團隊結合科技和設計，去解決顧客實際的問題，同時也滿足公司本身的商業需求。這個推手，就是「產品經理」。
他也指出，多數小公司一開始都是由 CEO 或創辦人擔任這個角色，而「產品經理」和其他行銷、設計、工程人員等工作不同，亦和「專案經理」有差異，後面會再詳述。
Chapter 2 Technology-Powered Products and Services
這本書主要針對科技相關的產品和服務之產業議題，包含客戶服務產品（電子商務：Netflix, Airbnb, Etsy）、社群媒體（如：Facebook, LinkedIn, Twitter）、B2B 的企業服務（如：Salesforce, Workday, Workiva）、消費裝置（如：Apple, Sonos, Tesla）、手機軟體（Uber, Audible, Instagram）。
Chapter 3 Startups: Getting to Product/Marketing Fit
公司發展總共分成三個階段：草創期、成長擴張期、成熟穩定期。不同的階段有不同的挑戰。
公司新創初期，主要還在尋找「產品/市場契合」（Product/Marketing Fit），通常由創辦人當產品經理。創業初期通常資金有限，所以公司目標就是在資金燒完之前，找到產品/市場契合。公司工程師大約不超過 25 人。
在時間和金錢都非常緊縮的情況下，公司探索出最佳學習並快速向前動的方法，努力找出可以符合先期市場需求的產品。多半新創公司其實都沒能活到最後。所以在新創公司工作的，壓力大、風險高，但如果產品成功的話，高成就感與金錢報酬也會隨之而來。
Chapter 4 Growth-Stage Companies: Scaling to Success
公司如果成功找到找到產品/市場契合，下一個挑戰就是「如何有效率地成長和擴充」。除了要招募聘用新員工外，還要想著怎樣複製之前成功的經驗到之後衍生的相關產品、服務上。公司工程師從 25 人到上百人。
產品團隊常有的抱怨是，沒有更完整的視野，看見自己的工作怎樣幫助到公司目標，也不知道有自主權的團隊該是怎麼樣子。銷售和行銷團隊則是常抱怨原先的進入市場策略（go-to-market stragies）不適用於某些新產品。為早期產品所生的科技基礎架構，也逐漸難以擴充使用，也開始累積了許多「技術債」。在領導層，原先適用於公司初期的領導風格和機制，公司規模擴大後，沒辦法適用，領導層需要改變他們的角色和行為。
但是公司對於克服這些挑戰的動機是非常強烈的。因為公司想要公開募股（IPO）或被大企業併購，亦或是想要為這個世界帶來正面重要的貢獻。
Chapter 5 Enterprise Companies: Consistent Product Innovation
公司順利擴張之後，下一個目標即是「企業永續經營」。
科技產品公司首要任務就是確保「產品持續創新」。這代表公司必須持續提供新的價值給他們的顧客和商業，不僅僅只是稍微修改或是最佳化現有產品，而是必須讓每個產品達到它全面的潛能。
但是成熟的公司，除了內部意見外，還有許多外部的股東的意見。可惜的是，這些意見往往阻礙新的冒險或提案，喪失企業再造的機會。或是築起了很多障礙，導致少數人有意願帶領公司進入新的方向。
當公司到達大企業的階段時，公司很大一部分已經實現了最初的願景，結果員工反而失去方向，不知道下一步路該怎麼走。產品團隊也會抱怨公司缺乏願景和授權，做個決定都要經過層層關卡，或是設計要經過公司委員會決定。
領導層其實也卡住了，覺得好像成立個「創新中心」，就能有源源不絕的產品創新，但是實際上，往往很少達到他們所渴望的創新。
而科技業諸如 Adobe、Amazon、Apple、Facebook、Google 和 Netflix 都試著避免這樣的命運。這些公司做產品的方式，就是作者想要在這本書分享給大家的。
Chapter 6 The Root Causes of Failed Product Efforts
作者接著介紹大部分公司的工作流程以及缺失。目前多數公司的工作流程偏線性的瀑布流。
流程始於一些概念想法，可能來自公司內部人員例如：老闆、其他利害關係人，或是外部顧客。然後公司想要把這些點子可以排入產品開發的 Roadmap 中，做這件事有兩個原因：
- 想要確保大家先做重要的事。
- 可以預測什麼東西什麼時候會完成。
所以就會公司就會有季度或年度計畫，把這些開發納入計劃，但要擬定這些計畫、排優先順序，就必須先知道商業企劃分析（ business case）。
商業企劃分析主要著重兩點：
- 這個計劃能賺多少錢或增加多少價值？
- 這個計畫會花多錢和時間？
當產品開發計畫完成之後，通常產品經理就會和利害關係人聊一聊，知道大家的想法，然後有些初步的想法，開始寫需求（Requirement）。需求文件主要是拿來和設計師和工程師溝通，讓他們知道要做什麼。接下來設計師就會開始設計流程、視覺等，然後設計師會再交付設計圖檔給工程師。然後工程師開始跑 Sprint，進行一到三輪的迭代開發，最後產生東西之後，給 QA 做測試，測試如果通過，就會發佈給實際使用者。整個流程通常會拖很久，其實也缺乏創新。
作者列出 10 個這個流程的最大的問題：
- 先說說點子的來源，在這個模式底下，產品點子往往都是銷售導向，或是利害關係人導向，而非我們能想出的最佳產品。工程師往往只能聽命行事，傻傻地把產品做出來，沒有機會發聲，也缺乏授權團隊。
- 其實在這階段就討論商業企劃分析（business case）是空談，我們根本不知道會賺多少錢，也不知道這案子會花多少時間和金錢，都不知道要做什麼，工程師也根本無法預估時程。
- 產品路線圖（Roadmap）往往只是一些功能和專案優先級的排序而已，可能是行銷部門需要這個功能做宣傳，銷售部門需要這個吸引新客戶。但其實無法帶來創新。我們要認知到兩個事實：1) 我們一半以上的點子根本沒用，顧客根本就不會喜歡、或是可以客戶帶來價值，但產品太難用，顧客覺得不值得花這麼多心力、不然就是這個點子會花太多資源，公司根本負擔不起。 2) 即便點子是有潛力的，但通常都要經過好幾次反覆迭代之後，才會達成商業價值，讓公司變現（time to money）。
- 「產品經理」這個角色在這個流程模式內，完全變成了「專案經理」，只負責收集和撰寫需求文檔，然後轉給工程團隊。
- 同樣的，設計師進入得太晚，無法發揮設計師的價值，什麼都已經定好了，設計師無力回天，再怎麼修改也只是「徒勞無功（lipstick on the pig）」。
- 工程師也參與得太晚，只用他們來寫程式，太可惜。因為工程師往往有很多創新的想法。
- 然後敏捷方法（Agile）也用得太晚，敏捷只在工程師開發的時候才使用，只用了它百分之二十的價值，浪費的它的原則和可以帶來的利益。
- 整個流程非常「專案導向」，比較在乎功能有沒有在時程內完成，在乎產出（output），但「產品導向」則是重視成果（outcome），產出品需實際有真的幫助到客戶和公司。
- 「顧客驗證」發生得太晚。等把產品送到顧客手中之後，才發現他們根本不愛。瀑布流的開發流程，把開發的風險留在最後一次爆發，浪費了先前投入的設計、開發、測試等資源。其過程昂貴且緩慢。
- 除了浪費的時間和金錢外，更重要的，我們也付出了「機會成本」，在投入開發的同一時間，沒有去做其他真正正確的事。
Chapter 7 Beyond Lean and Agile
作者發現有些人會說他們公司在使用「精益開發」或是「敏捷開發」，但其實他們做的事並沒有照著原則執行，其實產品開發也沒有什麼一次到位的捷徑，因為產品開發本來就是很難的事。
作者把「精益開發」和「敏捷開發」的概念重疊的地方，提出了三項重點原則：
- 最早開始處理風險越好：風險可以分成三種：1) 價值風險（顧客認為這產品能不能幫她解決問題、帶來價值）、2) 易用性風險（產品有沒有讓使用者輕易上手）、3) 產品可行性風險（我們有沒有這樣的時間、技術、科技可以做出來）、4) 商業可行性風險（產品是否符合公司銷售、行銷、財務狀況和法律規範等）
- 定義和設計產品時，應該是眾人同時合力，而沒有先後順序：不是產品經理定義需求、然後交給設計師設計、工程師開發… 而是要讓產品、設計、工程師坐在一起，一起合作找出最佳方案。
- 產品重點在於「解決問題」，而不是產出功能：確保產品可以解決顧客根本問題，而不是做出功能就好，以達成公司的商業成果。
Chapter 8 Key Concepts
接著作者在這裡闡述一些重要概念，之後比較細節的做法，會在其他章節詳述。
1. 「產品」更完整的定義
產品的定義包含一些「功能性」，然後有「科技技術」能實現這個功能、然後透過「使用者經驗設計」展現這個功能。然後我們也試這用這個功能「變現盈利」，想著如何「吸引和獲得使用者和顧客」，也包含一些「線下體驗」，去傳達產品的價值。
2. 持續地探索及發布產品
我們必須探索我們想要開發的產品，同時間，我們也必須把產品推向市場。探索產品不僅只是產品經理的工作，設計師和工程師都可以加入。而發佈產品，同樣也需要三人每天合作。
3. 產品探索
產品探索的產出，就是已驗證的產品清單。要做的功能已經回答四個產品重要的問題：
- 使用者會不會購買或使用？
- 使用者知不知道要怎麼使用？
- 我們的工程師有辦法做出來嗎？
- 我們的利害關係人願意支持這個產品嗎？
4. 原型測試
原型可以在不花費太多金錢和資源的情況下，快速實驗想法是否可行。作者建議盡可能每一週都能規律地測試至少 10 到 20 個點子。
5. 產品發佈
在發佈產品時，我們必須確保產品擴充性、效能、穩定度、容錯度、安全性、隱私性、全球化和在地化都能運作正常，像廣告說的那樣，確保產品的品質。
6. 產品和產品市場契合
透過最小可行性產品，看看能不能滿足部分市場的顧客需求。這個階段就是再看看產品發佈的成果，真實驗證，之後幫助我們決定哪些是產品的必要功能。
7. 產品願景
產品願景即是產品 2–10 年的長期目標，這個產品怎樣可以達成公司的願景。我們用原型在產品探索階段快速實驗，然後再發佈產品，希望這個產品市場能買單，並最終可以達成公司的產品願景。
後語
這本書作者的廢話很少，每句都是直接打到重點，推薦大家如果對產品開發有興趣的，可以買來看。
看到講述失敗的原因時，覺得以前公司也掉入類似的坑。特別在概念來源這邊，想到以前確實有從銷售部門來的點子，要求什麼功能一定要放入，之後把產品推給經銷商的時候，比較好賣。雖然對有些功能有點質疑，但是公司的顧客消費習慣，喜歡 CP 值高，所以會喜歡塞越多東西越好，殊不知，可能這些功能你從來都用不到，但在銷售時，卻可以成為賣點，也是蠻有趣的現象。
但另一方面，其實當初在開發產品時，行銷部門、銷售、產品專案經理、設計師、工程師都已加入討論，所有係害關係人的看法，也都被討論。產品或專案經理背負最終產品成敗時，他或許就是最終要下決定的那個人吧？
真心覺得產品經理這個角色不簡單。而這個角色也是非常吃力不討好的工作，很容易就被工程師和設計師兩邊夾擊。除了溝通的軟實力之外，還要瞭解商業機會、科技技術、設計體驗等各方面硬實力。難怪一個成功的產品經理，如果能找到投資者，其實是最具創業潛能的人。
難怪本書一開始就先把醜話說前頭，沒有熱情，不要隨意入坑，畢竟工時和壓力是很可觀的。
如果你（妳）喜歡這篇文章，請給予鼓勵
拍手👏10下代表你喜歡這篇文章
拍手👏20下代表這篇文章對你非常有幫助
拍手👏50下代表這篇文章實在太棒了！！！有任何問題，也歡迎留言給我：）
