決勝B端：驅動數字化轉型的產品經理（第2版）

這是今年讀完的第31本書。因爲三年前讀過第一版，所以第二版讀得比較快，書中列舉的場景實例也沒有仔細分析，讀這本書的目標在於以現在的視角“查漏補缺” 整體來看，我覺得第二版已經可以作爲產品經理轉型、入門、初級到中級提升的標準化讀本，幾乎涵蓋了B端產品經理的方方面面 當然，正是因爲覆蓋面廣，也讓這本書在深度上略有欠缺。畢竟從產品視角來看，“大而全”和“小而精”本就是相互矛盾難以兼得的。即便作者讓書的厚度增加了近一倍，但很多方面也不能繼續深挖 所以，我以一位忠實讀者的角度希望楊老師後續能夠在某幾個細分領域寫出一系列的產品進階套餐 關於產品經理的工具書，我覺得值得多讀幾遍的有以下幾本： 《俞軍產品方法論》、《SaaS創業路線圖》、《SaaS產品經理從菜鳥到專家》、《幕後產品》，現在又增加了一本《決勝B端2.0》 書中的內容在此不多贅述，直觀感受是很厚、很全面、很經典、很用心、很易讀，也補充了我近些年產品工作的很多盲區 尤其是對於一些辯證性、博弈性的話題，作者能夠提煉出相對準確、多角度的總結，確實功力深厚 另外，讀完這本書之後最大的感受是：產品是產品、書是產品、人也是產品。我們都應該以產品思維不斷迭代 因爲經常圍觀作者的朋友圈，所以對於第二版的升級內容，作者的日常工作、生活狀態有些許瞭解，給我的感受就是楊老師在以“產品”定位不斷升級 隨着時間的發展，結合自己持續的工作總結，迭代輸出。這種狀態讓人既羨慕、又慚愧 我從去年開始對外輸出以來，雖然有一些產出，但都是聚焦於某幾個細節，並沒有從中觀維度體系化編排梳理，所以很多輸出缺乏連續性，對自己反向促進也很有限 因此，這本讓我“查漏補缺”的書讀完之後，我發現了自身工作經歷的盲區，比如商業視角、數據思維、更全面的架構能力，以及對於互聯網技術的瞭解 我相信大多數同行都有類似的問題，受限於自身團隊、公司的發展和視野，只能夠從局部出發瞭解產品，提升產品能力，猶如盲人摸象 所以能有一本更加全面的教材拓展認知邊界，真的要對楊老師說一聲感謝 希望書中所講，書中所學能夠運用到工作和生活中，也推薦不同層級的產品經理拿來一讀，從不同的視角吸取書中經驗，感知作者傳遞的理念 畢竟，每個產品經理也需要不斷迭代提升~

隨時保持空杯心態，放低姿態，願意打破舒適圈，突破自己，在職場中一切皆有可能 🌈刻意練習100次|N.91🌈 📖【閱讀書籍】：《決勝B端》 👩‍🌾【作者】：楊堃 🌟【閱讀感悟】： ☀🌳每天寫東西的時候，忽才發現這纔是最快樂的時刻。 ☀🌳停下來很久沒有讀這類數據，讀一本讓自己重新鞏固行業知識。 ☀🌳楊堃說，一個合格的產品經理，手機上一定裝成百上千個APP，仔細端詳每個產品的業務邏輯和實現邏輯。 ☀🌳讀完我最大的感受是，做好一個產品，從客戶角度出發，把每個業務流程用條線的方式展現出來，然後去細化每個條線設置的點，一點點去檢查條線中的邏輯點。 ☀🌳之前我領導最常說過的一句話是：你把業務場景羅列出來，每一個場景交互一次，走到的每個結束的節點，按照你的假設去看看到底能不能完成。 ☀🌳那個時候，並不懂這麼深刻的道理，今天讀完這本書，才恍然開悟。 ☀🌳才發現，之前寫的每個測試點是零散和毫無關聯，而他的思路是從頭開始交互一環扣一環，清楚並明確的清掃了每一個錯點。 ☀🌳領導所做到的，就如楊堃所說的，設計人員要完成業務梳理、問題診斷、產品定位、業務建模、界面設計、權限設計等一系列工作，既要有對宏觀的把控能力，又要對微觀細節的專注力。 ☀🌳我對行業的認知，遠不足他理解的一半，未來繼續從事的行業中，我始終看好這個行業，人才的領悟能力纔是這個行業最稀缺的部分。 ☀🌳讀完這本書，也積累了好幾本書，比如《計算機網絡》、《幕後產品》、《SaaS創業路線圖》、《俞軍產品方法論》等等口碑較好的數據，接下來就開始好好讀一把，然後分享給大家。 #推薦一本好書#推薦書單#自我提升

本書作爲一本入門書籍，整體上還是不錯的，知識面廣，涉及產品全流程，整個閱讀過程對於我自己也是一個知識梳理的過程，系統化構建個人產品知識架構。 工作範圍從商業洞察開始，到產品運營截止，覆蓋企業戰略運營全週期。 技術產品不是簡單的將線下工作投影到線上，投影過程只是實現了信息的線上化，產品設計要基於企業戰略，梳理企業流程，重構流程，然後才能線上化，因此產品構建是需要結合企業業務特性，平衡產品需要與業務需要，基於企業發展階段，產品經理需要不斷調整策略。產品本身並不解決問題，產品只是一種表現形式，若問題真的有價值，沒有產品，業務也會有替代方案，解決問題的是產品背後的業務模式，通過業務模式調整業務行爲。 產品工作主要需要商業能力，產品能力，技術能力，其中產品能力是作爲產品的基礎，產品設計是一個需要洞察人性的工作，因此經濟學、心理學是必不可少的基礎知識。除此之外，產品是一個複雜任務落地的過程，對於複雜任務統籌能力與管理能力也是必不可少的。

有收穫，一直邊讀邊對比我們的產品，貌似都沒有提到多租戶模式。 只要你能夠通過深耕積累成爲業務型產品專家，形成個人的競爭壁壘，不論在哪個賽道、哪個方向，都會在職場中非常搶手，取得良好的職業發展路徑。

楊老師職業生涯並沒做過 SaaS 和 PaaS 之類的 toB 商業化產品，真正做過只是公司內部用的後臺產品，很多東西都來自於諮詢反饋和邏輯歸納，可能也就對初中級產品經理有幫助吧。每個職能都有把自己弄得更專業的傾向，但這對實現業務目標並沒有完全正相關的幫助，只把自己當產品經理來發展的人很難有好的職業生涯

“謀定而後動”，做好需求調研是項目成功的關鍵，但在實際工作中卻常常被業務人員草草完成，所以一直以來都想對最薄弱的客戶需求調研工作總結出一套可落地的系統方法，不求拉高上限，但求對齊底限。近期有幸閱讀《決勝B端》《有效需求分析》《軟件需求最佳實踐》三書，再結合ToB工作實踐，今日終於整合完成，記錄如下，供後續工作時常參閱： 《客戶前期調研基本方法指南》（暫且這麼命名吧...遺憾表格格式無法複製，略微影響下文閱讀體驗） 一、目標 1.於項目立項前，更好地明確和挖掘客戶需求，確定項目價值及定位； 2.提升前期調研質量，減少後續客戶需求變更，避免增加不必要的項目成本，同時提升客戶滿意度； 3.提升產品及業務人員的調研能力，在客戶側建立更好的專業度形象。 二、適用範圍 1.適用於打造通用產品的客戶調研； 2.適用於項目制的客戶調研。 三、適用人員 建議所有產品經理、項目經理、業務負責人蔘考。 四、適用階段 以下調研工作屬於客戶前期調研，建議需在立項前完成。 五、具體調研方法 1.調研目的： 1.1挖掘客戶需求，明確產品/項目要解決的問題/機會； 1.2跟客戶確定解決方案思路，明確產品/項目定位； 1.3確定主要業務事件的流程，用於梳理對應業務架構及規劃應用架構設計。 2.調研前準備： 2.1儘可能提前收集客戶信息，爲後續調研溝通工作開展提前瞭解更多背景信息： 【可收集的信息】如：單位基本信息（單位業務範圍、人員數量、營收情況、商業模式等）、單位組織結構信息（部門、職責、負責人、負責人背景信息、部門人數、人員分工等）、各組織考覈目標、和所調研方向密切相關的管理辦法/制度/流程文檔、信息化建設現狀（已有系統建設情況、使用情況、優缺點）、網絡環境、設備情況等。 【收集方式】部分信息可通過上網/找業務負責人瞭解，其餘無法瞭解到的信息需提前發調研信息給到客戶單位對接負責人，由對接人進行信息收集匯總，或者由對接人安排對應單位人員進行遠程會議溝通。 備註：1）若對新業務領域缺少基本常識，建議提前閱讀相關論文、行業報告或專家訪談等方式提前進行學習瞭解； 2）對於爲什麼需要收集這些信息，需要跟客戶闡明價值出發點，以便引導客戶更有積極性來提供相關內容。 2.2競品、行業標杆案例信息整理： 【競品、行業標杆案例清單】競品選擇上儘量選擇該領域下市佔率高的Top3廠商，行業標杆案例上重點關注同行業下Top2單位的系統建設情況。 【競品調研關注點】除基本功能服務梳理外，重點分析其產品亮點、存在問題、商業模式、運營狀況、合作過的優秀客戶案例/失敗案例及原因分析。 【行業標杆案例關注點】關注其項目背景（現狀及目標）、解決方案（不止關注系統建設情況，也包括比如人員組織情況、項目建設節奏、運營推廣方案等）、解決效果（若能瞭解到量化數據更佳）、分析可借鑑點&待提升點等問題。 【整理競品、行業標杆案例信息】形式不限（如PPT、直接演示系統等），核心在於以合適的方式達到在後續調研中可跟客戶進行演示及引導挖掘客戶需求的目的。 備註：1）若對客戶關注需求已有初步解決方案（尤其已有產品亮點），建議可提前準備產品原型圖用於客戶展示，在缺少競品、行業標杆案例的情況下，這項工作則更爲重要； 2）客戶演示時，注意不要純羅列功能逐個講解，要以業務工作場景作爲線索，先把工作的業務步驟列出來，作爲整個串聯的情節，然後讓用戶帶着這樣的線索來審視系統的操作過程，看看是否合理、是否滿足需求。要讓用戶不僅僅關心用戶界面的樣子，更要關心流轉和交互過程，以減少後續主流程的需求變更。 2.3擬定調研提綱，並提前發給用戶： 調研計劃大綱可以包括如下內容： 【調研計劃大綱】（此前已整理成表格，上下對齊閱讀） 訪談主題： 訪談要點 期望部門 備註 訪談人 訪談時間 用簡短的話概述 抽取關鍵點 指定理想的訪談對象 訪談具體內容文件名信息 由客戶方聯絡人指定 由客戶方聯絡人指定 【各角色訪談具體內容】 需要考慮按訪談對象設計不同的訪談內容： 訪談對象 計劃要點 備註說明 高層管理人員 （1）羅列出部分問題/機會點（售前獲取一些信息） （2）備相關優秀實踐案例 （3）列舉潛在的解決方案 確認已列出的問題/機會點，探討潛在的問題/機會點，明確項目目標方向，標識出關鍵干係人 中層管理人員 （1）羅列出相關的業務事件列表 （2）收集與特定業務事件相關的資料 （3）準備一些業務事件的關鍵問題點、需求點 （4）準備一些相關的管理控制點 確定每個業務事件的流程，收集中層管理人員的問題點、需求點 操作層 （1）羅列出相關的業務活動 （2）收集與特定業務活動相關的資料 （3）針對業務活動的問題點、需求點 進一步確定每個業務事件/活動的流程，收集操作層人員的問題點、需求點 備註：1）在干係人關注點分析時，要從兩個角度出發：一是他們希望系統解決什麼問題、提供什麼業務支持；二是他們希望避免出現什麼樣的負面影響，這樣才能夠立體地完成干係人分析； 2）擬定調研提綱後，應將問題提前發給用戶，讓用戶打有準備之戰，發送時間建議提前2-7天，不宜太早，也不宜太遲。 3.調研過程： 3.1 溝通注意事項： 需求調研的過程是人和人打交道的過程，是各位展示自己溝通能力的地方，需要學會一些和人打交道的策略，有以下幾點經驗分享： 3.1.1 需求捕獲應該是主動的，需求分析人員在整個過程中應該充分發揮出主動性，要善於把握主動權，能夠根據每次訪談的對象制定相應的計劃。 3.2.2 需求捕獲應該是聚焦的，不要讓用戶發散地提需求，要幫助用戶梳理工作流程及痛點，從而將問題聚焦。 發散問法舉例：你對這個系統有什麼需求？（這種問法容易產生很多鍍金需求、非重要需求） 聚焦問法舉例：當XXX的時候，希望以什麼形式體現？收到後，你們一般會進行什麼樣的處理？在這個過程中需要做什麼配套工作？原來處理時存在什麼困難？有哪些問題是比較棘手的？ 3.3.3 要注意對變更需求的捕獲，以下問題有助於提前瞭解這類需求，便於後續考慮系統設計的靈活性。 - 你們上次組織結構調整是什麼時候？ - 這個流程以前也是這樣的嗎？如果不一樣，是什麼時候的事呢？ - 這些規則是來自外部法規，還是內部制定的？ - 如果是外部法規，這些法規通常幾年會更新一次？ - 如果是內部制定，是由哪個部門制定的？依據什麼會進行調整？ ... 3.3.4 要注意用戶說的是問題還是解決方案，通常越有經驗的用戶越喜歡直接說解決方案而不是問題，這時候一定要多問“why”，因爲用戶並不是最合適的解決方案專家。 3.3.5 從用戶的肢體語言、表情都會反饋出一些語言之外的信息，一個優秀的訪談人員應該能夠抓住這個異常現象，以便對問題建立更清晰、準確的理解。 現象 內涵 語速極快、描述過程邏輯性強 1.傳達的信息是用戶很熟悉的工作 2.描述的信息可能是理想化的制度 語速緩慢、中間有很多的停頓 1.用戶對講述的信息不夠熟悉 2.傳達的信息是平時考慮不多的 3.這些信息很容易產生變化，需要注意 突然改變語氣、臉色 1.所問的問題是對方很敏感的 2.涉及公司政治、有利益影響 3.傳遞的信息有明顯的誤解 回答某問題時眼睛經常向左上方轉動 對方可能在回憶，信息相對真實 回答某問題時眼睛經常向右上方轉動 對方可能在“創造”，真實性待確認 回答比較強勢，甚至有攻擊性 對信息系統的建設有反對意見或敵意 坐姿很隨意，諸如翹着二郎腿 對訪談內容重視度不高 3.3.6 訪談時一定要就預先計劃的問題逐一得到解答，因此在訪談過程中需要不斷地檢查，以確認沒有遺漏的問題。 備註：在實際的訪談過程中，預先計劃問題和即興問題有時並不需要截然分成兩個階段。具體來說，可以根據被訪談者的特點來決定。 - 思維比較發散：那麼就可能會把話題帶得過偏，從而導致佔用了大部分時間；這種情況下就應該儘量迴歸到預先計劃問題上，先保證不遺漏這些問題，再對即興問題進行處理。 - 思維比較聚焦：有些客戶是比較有控制力的，他們會控制話題，這時可以適當地穿插即興問題。 3.2 調研形式： 3.2.1 用戶訪談：這也是我們實際工作中最常見的形式。 【被訪談者】 最常見的被訪談者包括高層管理人員、中層管理人員、操作層3類（可根據目標及風險識別關鍵干係人，通過項目目標可識別出和哪些部門相關，通過風險可識別出如可能會帶來大量負面影響的基層員工、有一票否決權的評價者<財務、審計、法規等監管部門>等）。 通常對高層管理人員的訪談結果是訪談中層管理人員時的指導，同樣對中層管理人員的訪談結果是訪談操作層時的指導，也就是說，在不同階段應該訪談的人是不同類型的，而且對於不同類型的被訪談者的話題中心、訪談目標都是不相同的。 另外，被訪談者選擇需注重代表性：每個具體的干係人，在專業背景、職業經歷、個人價值觀、組織地位、工作經驗等方面都會存在一定的特殊性。因此，選擇出的一位或多位代表，應該能夠覆蓋各種差異的干係人。 【訪談時空安排】 時間：一般來說，一次用戶訪談的時間應該控制在1小時以內，如果時間不夠用可以考慮中場休息或者安排下一次訪談。 空間：爲了避免訪談過程中受到外界的干擾，應儘可能選擇諸如會客室、洽談室等相對封閉、不易受干擾和被打擾的地方進行訪談，特別應該儘可能避免辦公室。 【訪談中的記錄工作】 建議採用“自己做筆記+錄音”的組合方式。同時在訪談過程中，可採用及時反饋策略，每當被訪談者陳述完一段話之後，就用自己的話簡要複述一下，以保證雙方達成共識。 3.2.2 問卷調查：當存在大樣本用戶、跨地域用戶時，可能需要用到問卷調查。 【問卷設計】 （1）注意問題的篇幅與佈局 - 填寫問卷的時間不超過20分鐘。 - 問題應該按由易到難的順序排列。 - 問題排列應該注重邏輯相關性，否則會干擾被調查人的思路，從而降低問卷的填寫質量。 （2）注意問題類型的選擇 - 在需求調查問卷中應該儘可能避免使用封閉式問題，因爲這類問題很容易誘導被調查人，從而產生不準確的結論，而解決的方法，就是用半封閉性問題來代替。 - 儘量讓開放式問題跟隨在相關封閉式、半封閉式問題之後；因爲這時用戶在腦海中有一些答案，填寫出來的可能性就會大大增加。 舉例： 當你想了解被調查喜歡什麼樣的運動時，就應該採用如下所示的問卷設計方式： 你喜歡什麼運動？（可多選） □足球 □籃球 □圍棋 □器械 □其他（請寫出）_______ 當用戶沒找到可選項時，在其他的後面寫出他喜歡的運動的可能性就會大大加強，如果將這樣的開放性問題放在最後，就很可能收到白卷。 【問卷分析】 - 注意篩除無效問卷：調查問卷的填寫質量是良莠不齊的，因此在分析統計之前一定要把無效問卷先排除掉。有兩個線索能夠很好地標識出無效問卷：一種是存在大量的空白，第二種是連續出現相同的答案。 - 對問卷的填寫人進行分類：我們不僅需要對所有的問卷做統計，還應該將問卷的填寫人按職位、地域、年齡段、從業時間等方面進行分類，然後對每類填寫人的問卷進行統計，這樣就會發現這些差異是由什麼原因造成的。 3.2.3 現場觀摩：在對業務知識、業務場景不熟悉時、需要對複雜流程建立更深入的瞭解時、在對關鍵任務理解不清晰時、在很多東西用文字表述不清時，都是建議使用現場觀摩的時機。 【觀摩方式】 - 任務示範：也就是要求用戶示範如何執行特定的任務。 備註：不應大張旗鼓地進行，否則容易出現“觀摩”失真、“示範”失真的現象； 有條件的情況下，建立可重複觀摩的場景，也就是將觀摩的過程錄製下來。 - 做學徒：也就是和用戶坐在一起，通過觀察、問問題，並在用戶指導下完成一些工作來學習。 3.3 工作文檔收集： - 在對每個業務事件的流程進行分析時，標識出各個業務活動所要處理、傳遞的表單，形成一個表單列表，讓用戶根據這個列表來提供對應文檔。 - 收集文檔時，應該儘可能讓用戶提供帶有部分真實數據的樣本。 4.調研產出物： 4.1 訪談過程記錄：訪談錄音文件（如果有錄音）；訪談文字版記錄（含調研前信息收集+調研過程記錄）。 4.2問題定義：問題需要被清晰定義，對問題進行了正確的定義，意味着已經成功了一半，同時應將問題及發生問題的本源跟客戶達成一致。 備註：要注意分析問題背後的問題，也就是尋找問題的本源，可運用兩種工具，一種是定性分析的魚骨圖，另一種是定量分析的帕累託圖。 問題卡片模板（如果有多個問題，則對應產生多個問題卡片） 問題/機會 編號 爲每個問題場景設置一個編號，用於需求跟蹤 描述 客觀地從業務描述問題 影響了誰 如果有多個被影響人，則列出多個；請注意指代清晰、具體到人 產生的後果 與“影響了誰”對應起來；要確保視角匹配、推理合理 解決方案 要點 說明主要的策略 優點 當有多個可選解決方案時，在此說明爲什麼推薦本方案 4.3 干係人分析結果： 干係人分析卡片模板 類別 包括髮起人、使用者、評價者、其他四種類型：發起人爲項目發起人；使用者就是未來會直接、間接使用系統的用戶；評價者通常是財務、審計、法規、行業監管部門等會提出驗收標準的、通常擁有一票否決權的干係人；開發團隊、維護團隊、領域專家、技術專家等干係人就屬於其他類 代表 人員姓名+職位，如有多人則記錄多人 人員職責 管理及工作範圍、核心考覈績效 聯繫方式 便於後續聯繫 相關度 項目與他直接相關嗎？涉及他的利益或責任嗎？可以使用“高、低”兩級評估或“高、中、低”三級評估 影響度 他對項目的方向、驗收有很強的影響力嗎？可以使用“高、低”兩級評估或“高、中、低”三級評估 核心關注點 編號 內容 重要性 逐條寫出該關鍵干係人的關注點（正需求）、阻力點（負需求），還可以考慮寫出相應的功能需求 判斷重要度（可以使用“高、中、低”或“關鍵、重要、有用、一般”進行評估） 備註 記錄一些其他便於理解干係人的相關信息，如專業背景、職業發展過程等 4.4 已有系統建設情況： 系統名稱 系統說明 建設階段 客戶評價 和本項目關係 系統名稱 系統價值（用於解決什麼問題），核心包括哪些模塊/功能 待建設（預計什麼時候啓動建設）/建設中（預計什麼時候建設完成）/已完成建設（投入使用時間） 應用情況如何？ 1）系統優點： 2）系統問題： 系統集成/數據互通/替代關係（歷史數據是否要遷移）/其它等 4.5 文檔清單： 4.5.1 相關管理制度、辦法、流程等文檔； 4.5.2 相關工作表單清單； 4.5.3 重要問題記錄：如網絡環境、設備、硬件等情況； 4.5.4 其它相關業務文檔。 4.6 業務架構分析： 可參考《2-公司信息化總體架構設計方法論_v3.4》4.2.1章節內容（爲另一文檔...）。 4.7 應用架構規劃（初稿）： 可參考《2-公司信息化總體架構設計方法論_v3.4》4.2.2章節內容（爲另一文檔...）。

遇見這本書真的如獲至寶，不管是產品經理、開發人員、運營人員、部門管理者、企業管理者，甚至是新手小白，都是一本極其實用的書，既可以當做工具書使用，也可以作爲科普讀物，可以把讀者的視角，拉高到宏觀的層面去全面的理解掌握B端業務和產品體系，存在的價值，以及行業發展趨勢等等，深入淺出。其中不乏有很多真實和虛構的案例來幫助讀者理解所涉及的內容，通篇無廢話，語言精煉，陳述全面。

對於沒做過產品的同學可能會覺得內容很多很雜，感觸不深：對於經歷過完整項目週期但是經驗不是特別豐富的的產品來說是一個很適合查漏補缺的書，可以看到自己曾經在工作中忽略的很多細節，將理論和實踐結合做反思和覆盤；但是對於經歷過多個項目，經驗很豐富的產品來說可能有些缺乏深度，但是總體來說還是推薦的。

幫助蠻大的，前五章還有項目管理的章節，以及很多章後面的資源推薦，很有用，要學的東西好多，沉下心捋捋，一步步來

花了70多幣永久購買了本書，書幣有效期30天，攢夠70個也不容易。這本書算是個工具書，或者叫字典書，幫助構建知識體系，內容比較龐大，案例輔助對理解具體業務場景有些效果。這本書的內容本來應該是作爲從業的個人自主建構的，有此書的幫助個人建構知識體系會更容易些。還有一點很好的是，作者推薦的其他書籍也很有份量，這當然很好，但也要警示其他讀者，除非你下決心鑽研，不然讀推薦的其他書會非常佔用你寶貴的時間，任何一本推薦都值得花和本書同樣的精力去學習。綜合來說，這本書值得打四分。