讀《跳脫建構陷阱｜產品管理如何有效創造價值 (Escaping the Build Trap: How Effective Product Management Creates Real Value)》（下）
前幾天發了一篇〈讀《跳脫建構陷阱｜產品管理如何有效創造價值 (Escaping the Build Trap: How Effective Product Management Creates Real Value)》（上）〉，這個是下集。
上集提過本書介紹、作者介紹與前兩個章節的內容，這邊就不贅述，直接接著講後兩個章節的內容。
chapter 3：產品策略
談完 PM 自身的需具備能力後，再來就是把它應用在產品管理上，所以接下來的章節，作者就講到 strategy（策略）。
剛開始做 PM 時，我就是那種不斷在 build trap 裡掙扎的人，時常覺得「為什麼要做這種沒意義的事」，但又因為老闆命令而不得不做。但諷刺的是，當被賦予權力可以去做想做的東西時，我仍在 build trap 裡面 — — 雖然知道為什麼要做這個功能、這個功能對誰有幫助，但卻沒有更全面地去思考「這個功能是否符合產品 / 公司的整體發展方向」，也沒有好好地進行後續追蹤成效，詳細地去了解這些功能到底為團隊帶來什麼價值。
讀起這個章節時，也忍不住想起這些不成熟的經驗與現在工作上的卡關點，所以記了蠻多東西。
首先，先來看看作者對於產品策略的定義：
- Strategy isn’t a plan. It’s a framework that helps you make decisions.
- Thinking of strategy as a plan gets us into the build trap. We keep adding new features to the list but have no way to evaluate whether they are the right features in the holistic context of our company.
- Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, contained by current capabilities, and coherently aligned to the existing context.
- Strategy is about how to take the organization from where it currently is and reach the vision.
- Strategies are interconnecting stories told throughout the organizations that explain the objective and outcomes, tailored to a specific time frame.
我看完這段的想法是：strategy is the answer to this kind of question — “how do you know that this is the right thing to build?”
在 <creating a good strategic framework> 的小章節裡，也看到好幾個看了很有感觸的情境，都是自己誤踩過的坑……
- No one can answer “why you are working on certain things?”. no goals, no direction. they are just reactively building requests from customers.
- Teams prioritize the work based on what they thought was right to build rather than on feedback from customers. It was reacting to the customers that screamed the loudest instead of evaluating whether those requests matched the strategy objectives.
- Companies that are busy creating new visions and strategies every year often are thinking too much in the short term and aren’t planning enough for the future.
之前在組內月會時，看到一個詞彙叫做 “code monkey”，中國則是用「碼農」（「就我自己跟中國同事的相處，「碼農」可以用於貶義或自嘲，但也可以比較中性地稱呼「工程師」這個職業，主要還是看語境吧），意思就是只顧著寫程式代碼、沒有去思考為什麼而寫、為什麼要這樣寫的人。
如果整個組織都這樣 — — 所有人都忙著建造功能，都沒人好奇或者沒人能說明那個核心的 why，那真的蠻可怕的，無法想像一整天都得這樣毫無靈魂地工作……。
如何落實產品策略
定義完策略後，再來的小章節就是談到 strategy deployment，也就是如何落實這些策略。
- At different levels of organizations, we tell stories with different scales of time (timespans), about our work and why we are doing it. In order for people to act on the stories they hear, the stories can’t have significantly different time scales than they are accustomed to.
- For example, Agile teams are really good at telling two- to four-week stories. that’s what they deal with on a daily basis. As you go up in the organizations, you tell stories with longer timespans. Executives are really good at telling five-year stories, but a team cannot act on a five-year story when they are used to thinking in two to four weeks. There’s too much space to explore.
- Strategy deployment is about setting the right level of goals and objectives throughout the organization to narrow the playing field so that teams can act.
之前常聽到很多經理人或高階主管要求基層員工要「拉高兩個位階思考」，在某些時候，確實這樣有助於讓第一線人員的想法更周全、更有戰略性，但有些團隊的日常工作就是處理第一線事務，比如某個產品的迭代就是以兩週或四週為單位，如果這時 PM 是用三、五年的時間軸在談論產品策略，對團隊來說就太難想像了，因為時空差太多、能被解釋的空間也太大，反而會讓團隊不知道該怎麼把這些想法落實到第一線執行。
有些公司會鼓勵團隊成員可以多提供想法、主動提議要做什麼事，但這都應該是要建立在某個大前提之下，比如公司的主軸是 shape the future of community，那大家就知道要往社群主題思考。反之，如果公司沒有一個發展重點，員工哪知道該怎麼做呢？正如書中寫到的：
When teams are not sufficiently constrained, they become stuck.
They feel like they cannot make decisions because there are too many options. Appropriately constrained teams, ones who have a direction set to the right level for them, feel safe to make decisions because they can see how their stories align with the goals and structure of the organization.
作者進一步列出在落實產品策略時，主要可以分成 4 種層級。也就是說，不要想用一套公司願景或產品策略就打到底，而是要根據對方的位階與日常工作類型做出對應的溝通：
就我個人閱讀後的理解，這本書沒有特別詳細地說明該如何發想產品策略，不過倒是有在一個小章節 <a model to think about business value> 提出一個思考產品價值的角度。
一般來說，大家可能會著重於「我要建立怎樣的產品策略，才能為公司帶來價值」或者「要怎麼改善功能，才能帶來更多價值」。但其實「帶來價值」可以被轉換成很多意思：
- increase revenue：真正的「賺到更多 $$」，比如想到新的商業模式
- protect revenue：守住原本的定位或價值，雖然不會賺到錢，但也不會產生額外損失或花費
- reduce costs：雖然沒賺到錢，但至少可以減少開支，也就是不開源，但可節流。通常內部產品團隊的衡量指標都跟此類有關
- avoid costs：比節流還更激進，而是要直接避免任何開支
chapter 4：產品流程
講完了 PM 角色與產品策略，再來就是把它落實到日常的產品管理流程中。作者以 “the product kata” 一詞來稱呼他的這套流程。“kata” 是借名於 “toyota kata”，也就是 toyota 內部奉行的一套方法。總之，可以把下面這個流程想像成作者在管理產品時會參照的一套 SOP：
- understand the direction 了解大方向（如公司願景、產品策略）
- analyze the current state 了解現況（目前產品遇到什麼問題）
- set the next goal 設定目標
- choose step of product process 開始面對現況，然後找到解決方法，進而達到當初設定的目標
- problem exploration
- solution exploration
- solution optimization
之前有寫過一系列關於產品管理的流程，不過內容都跟產品本身很相關的（也就是比較沒談到團隊合作、人際溝通這塊），比較像是要優化產品的手把手指南，有興趣可參考：
回到此書，上面的步驟四裡面有一個 “solution exploration “ 是當時讀起來比較有感的，所以想特別提出來分享。
作者認為在找到潛在的解法時，重要的是先驗證、實驗此做法是否可行。一般來說，產品上會觸碰的做法有兩種：build to learn vs. build to earn。前者是一個學習的「歷程」，想確認什麼可行、什麼不可行，後者是有明確的營利方向，或者至少是很確切知道做完這件事後，想得到的是什麼「結果」。
而所謂的產品實驗則是屬於前者。產品實驗應該是：
- It is all about building to learn
- It allows you to understand your customers better
- It proves whether there is value in solving a problem
- It should not be designed to last for a long time
- It is important to think of how you will end it — to close the loop
至於產品實驗也有很多種，作者舉了這 3 大類：
1st kind of experiment: concierge
- It delivers the end result to the customer manually, but they are not the final solution
- Take on the work for the customers and then later automate it
- It doesn’t scale, given that it’s labor-intensive. conduct the experiments with just enough users so that you can stay in regular contact with them, get plenty of feedback, and use the information to iterate
全手動實驗：團隊全手動執行整套流程，目的是先驗證此流程是否有效。確認有效後才投入自動化的人力。
2nd kind of experiment: Wizard of Oz
- It looks and feels like a real, finished product while on the backend it’s all manual
原型實驗：團隊純手動或者半自動執行流程，主要目的是搭建高仿真的原型，驗證想法是否可行。
3rd kind of experiment: concept testing
- Pitch the solution idea in the fastest, highest way possible to convey the message. e.g., make a video, wireframe, or prototype
- In many early-stage companies, concept testing is the way they get early sales or capital
概念驗證：有很多種驗證方法（比如錄個影片、做個簡報、做出 wireframe 或 prototype），重點是要確認某個想法是否可行。
chapter 5：產品驅動的組織
講了這麼多，終於來到最後一章。
最前面有提到，即使萬事具備 — — PM 本身已對自身角色有足夠認知、團隊已擬定策略，也知道該怎麼將策略落實到產品流程中，但仍需要有個夠罩的老闆（公司）在背後撐腰，對作者來說，所謂「夠罩的公司」就是 product-led organization，定義如下：
- The product-led organization is characterized by a culture that understands and organizes around outcomes over outputs, including a company cadence that revolves around evaluating its strategy in accordance with meeting outcomes.
- In product-led organizations, people are rewarded for learning and achieving goals. Management encourages product teams to get close to their customers, and product management is seen as a critical function that furthers the business.
如果想知道自己所處的團隊或公司是否為產品驅動，作者也在附錄 <6 questions to determine whether a company is product-led> 列出了這 6 個自我檢測的問題：
- who came up with the last feature or product idea you built?
- what was the last product you decide to kill?
- when was the last time you talked with your customers?
- what is your goal?
- what are you currently working on?
- what are your product managers like?
如果所處的團隊讓人能夠很完整地回答這些問題，那麼大致上可以說這是一個具有產品思維的團隊，反之，就可以再回溯到前四個章節談到的主題，一一去思考該如何改善現況。
結尾
除了上面說的這些基本概念，作者也有搭配一個虛構案例（雖說是虛構，但我覺得真實無比）貫穿全文——作者擔任一個新創教育平台的產品顧問，陪著他們從一連串的災難中重生，第一步先建立大家對於 PM 角色的認知，包括 PM 該做什麼、不需要做什麼、該怎麼跟其他部門協作，再來則是跟公司高層與產品主審慎思考公司目標、產品願景與策略，再把這些方向落地到一個個可執行的計畫，接著則是帶著產品團隊開始建立流程，一一執行並驗證假設，進而完成這些計畫。
可能因為曾在線上學習平台當過 PM，所以作者給的案例讓我特別有感，很多情境甚至會覺得似曾相似。大概也是這樣，就會更能理解該怎麼應用這本書提到的一些框架。
不過，即使不是有相關產業經驗的人，應該也能從中看到一些「影子」，比如模糊的產品指標、高層常給一些發散的目標、需求常常來得又急又亂、部門之間沒有好好合作……等。
但作者會一一拆解這些情況，並且套用他在每一個章節提到的一些方法論或思維，然後告訴讀者該怎麼改善。讀完整本書後，也會覺得自己好像跟著這間虛擬的新創教育平台一起成長了，居然有種莫名感動……。
最後再寫一個個人覺得這本書不錯的點，是在於作者多次務實地談到，要把產品做好，責任並非只在 PM 一人或產品團隊，而是整間公司都得有產品思維，否則大家也沒有一致的前進方向。
不少產品相關的文章或書籍都會提到「從自身做起」，有的甚至相信 PM 或組織中的某一人可以憑一己之力推動新事物，規模小的組織或許可行，但在大公司或階層組織分明的團隊待過的人，應該都會覺得這樣的說明太過天真。
有時候不是不想改變，而是改變太難，而一個人的聲音太小、力量太微薄。當然作為 PM，能做的事情還是要盡量做，但如果組織本身無法提供足夠的資源和空間，進而阻礙到 PM 本身或是產品的成長，那就得思考自己在這個組織裡是否還有價值了。
上面大致上就是我對這本書的讀書筆記與心得。英文部分是直接抄錄自書籍原文，中文則是自己的解讀與心得。
不過這本書有 200 多頁，上面這些只是個人閱讀起來特別有共鳴或覺得有價值的部分，其他沒寫進來的不代表不重要，有興趣的人還是可以直接去找書來看，會有更全面的理解。
