產品開發流程中最具藝術性的部分自然是產品設計了，作者把它拆分為繪模型、描需求、搭框架、定流程和摳細節。繪模型就是市場需求文件（market requirement document, mrd）的撰寫，為了抓市場的痛點，作者建議成為某類產品典型使用者深入體驗，不同於馬丁的蒐集和分析小資料來獲得不同於直覺的結論（來自《痛點：挖掘小資料滿足使用者需求》），不過也許殊途同歸，可能競品分析後也會導向不同於直覺的方向呢？
小資料：呈現真實內在的個人化的習慣、喜好、情緒等資訊「需求」，是橫在客戶與pm，pm與工程師之間的最難理解的鴻溝，因此作者將需求的確認劃分為前奏、收集、分析和篩選、優先順序排序以及輸出。通過目標使用者、使用場景和使用者目標3要素確認使用者需求，依仗使用者調研、競品分析、頭腦風暴、使用者反饋和資料分析5個需求**進行收集，回到3要素來進行分析並做減法，利用kano模型區分基本/期望/興奮型需求三象限，最後輸出模組、功能等文件，並定期整理。應該說需求調研手段千千萬萬，但是最終結果往往不可控，是看碟下菜還是看跌瞎猜，初創企業由於調研準備不足常常會用「拍腦袋」的mrd來描繪需求，結果交付就會面臨沉沒成本與回爐重造的抉擇。是因為自身技術壁壘把市場需求拒之門外，還是根據市場需求打破技術壁壘？
前文提到了pm的多重角色，其中作為「導演」的管理工作是必不可少的。與上述「拍腦袋」的快相仿，敏捷開發是產品開發中常用的精益手段，即小步快跑。pm輕量級的專案管理自然也不同於專案經理，如果說專案經理是專案矩陣下的領頭羊，那麼pm更像是職能矩陣裡的調配者，「光桿司令」更符合其管理定位。在專案啟動→計畫→執行監控→收尾階段，pm都需要參與，並時刻把握「做正確的事」的方針。作者在該板塊也提供了pace（product and cycle-time excellence，產品及週期優勝法）、過程跟蹤等理論方法，協助pm更有效率的完整全階段專案管理。
設計師：那用這種草綠色可以嗎？段子歸段子，pm的確需要掌握大量的常識和專業知識，包括藝術設計、技術知識、測試概念、運營知識、銷售知識以及與老闆交流生意計畫的能力。又要馬兒跑，馬兒還得自個兒找草，這可能就是pm的工作人生。pm：你們設計師也會用草綠色這種描述？綠色不是有很多種嗎？你們不是很專業的嘛？
設計師：（白眼）那#00ee00，#b3ee3a，#7ccd7c，你要哪種？
pm：……還是……那個草綠色吧。
獲取（acquisition）階段，關注使用者如何發現（並來到）你的產品？相較於《深入淺出資料分析_michael milton》這本純數學化的資料分析解讀，賴京露在《產品之旅》中推薦的工具模型更為實用，是非常容易上手的啟蒙指導書。啟用(activation)階段，關注使用者的第一次使用體驗如何？
留存(retention)階段，關注使用者是否還會回到產品（重複使用）？
收益(revenue)階段，關注產品怎樣（通過使用者）賺錢？
推薦(referral)階段，關注使用者是否願意告訴其他使用者？
《產品之旅：產品經理的方**與實戰高階_賴京露》以一種娓娓道來的舒緩文藝氣，講述了pm在0-3歲這個階段應當掌握的基礎知識、硬核技能和軟核技術。在茫茫多的工具中，根據作者自身經驗推薦了恰到好處的產品工具，讓pm小白很有認同感。感覺讀完這本書，不能說知道怎麼天胡了，但也對什麼「牌面」能胡有了大致理解。感謝賴京露！
資料產品經理電面經驗
1 投遞了阿里的資料產品崗位 投遞簡歷之後，下午面試官打來了 2 主要問題有幾個模組 1 對資料產品經理的理解 這裡我回答了資料產品經理，從資料源頭上有些分別。根據我的經驗，有業務類資料的產品經理 也有其他型別，如專門就是處理一類資料，如金融 醫療資料的 2 做了哪些資料產品經理的工作 講了現在事情...
產品經理群面討論技巧
下面是本節重點，即正式的群面解析。群試的步驟一般是 首先，接受問題，成員各自分別準備發言提綱 其次，小組成員輪流發言，闡述自己觀點 再次，成員交叉討論，彙總得出最佳方案 最後，解決方案總結並匯報討論結果。但整體流程並不固定，只要可以進行充分的討論並形成結果即可，所以其中有較多可以發揮的地方。因為群面...
產品經理12 4筆記
授課 張思鵬sunnysct 一 思考產品 三個方面出發 第乙個方面why？為什麼要做這個產品，那麼從這個角度出發，就會去思考使用者的畫像 包括使用者的特徵，使用者使用場景，使用者的痛點 定位出產品的思路。第二個方面how？如何把這個產品做出來，以及如何把產品做好做成功。首先考慮到使用者，主要包括的...