人人都是產品經理
- 互聯網產品設計的五層架構——戰略、范圍、結構、框架、表現。
寫給-1到3歲的產品經理
為什么要做產品經理
- 對一個產品，用戶總是分為新手、專家和中間用戶。
- 壞產品，無處不在的危險
- 好產品，從垃圾桶到洗手間
我們到底是不是產品經理
- 產品就是用來解決某個問題的東西。
- 產品就是要同時解決用戶的問題和公司的問題。
- 涉及產品規劃、數據分析、用戶研究、需求分析、功能設計、項目管理、敏捷方法。
- 職位目的：想要更了解產品與它面臨的競爭情況，最終目的是要滿足顧客的需求。
- 管理的能力，其實就是在資源不足的情況下把事情做成。
我真的想做，怎么入行？
- 最在乎應聘者有沒有激情、是否夠機靈、好學，邏輯思維是否清晰，溝通表達是否順暢等。
- 先在本職工作上找到與產品有關的事情做一些嘗試，并且考慮先從產品經理周邊的職位做起。
- 練習一下BRD、PRD。
一個產品經理的-1到3歲
- 產品經理不僅僅是做需求
- 學過的知識可以不重要，重要的是練好思維方式，學會學習。
一個需求的奮斗史
一個需求的奮斗史
從用戶中來到用戶中去
- 用戶是需求之源
- 因為生活中存在太多的問題，從而產生了不滿意，而問題就是“理想與現實的差距”，那么人類會很自然地產生“減少甚至消除這個差距”的愿望。
理解用戶是產品經理最重要的素質之一。
- 用戶是使用產品的人，客戶是購買產品、為產品付錢的人。
- 不同的用戶有重要程度之分，我們必須、也只能有所偏重。
- 不要試圖滿足所有用戶。
- 優先滿足哪些用戶需要和產品的商業目標要結合起來考慮，簡單說就是看KPI是什么。
- 你真的了解用戶嘛
- 體會真正的用戶
- 試著描述用戶
- 怎么說表現了目標的觀點，怎么做反映了行為，用戶怎么說和怎么做經常是不一致的。
- 定性研究可以找出原因，偏向于了解；而定量研究可以發現現象，偏向于證實。
需求采集的大生產運動
- 需求采集過程：明確目標、選擇采集方法、指定采集計劃、執行采集、資料整理，然后進入下一步的需求分析階段。
- 定性地說：用戶訪談
- 注意點
- 避免一組固定的問題
- 首先關注目標，任務其次。比用戶行為更重要的是行為背后的原因。
- 避免讓用戶成為設計師。
- 避免討論技術。
- 鼓勵講故事。
- 避免誘導性問題。
- 定量地說：調查問卷
- 不要超過10分鐘，敏感問題放中間，個人信息問題放最后。
- 注意調查問卷的設計
- 定性地做：可用性測試
- 可用性測試在開發的任何階段都可以做
- 定量地做：數據分析
- 在對產品足夠熟悉的基礎上，先做出方向性的假設，再提取相應的數據并分析，得到一些現象，最好是之前沒發現的現象，然后嘗試解釋，接下來做用戶調研修正解釋，最終知道產品發展方向。
- 需求采集人人有責
- 關注一手需求，其實是二手需求。
- 需求采集方法：現場調查、AB測試、日記研究、卡片分類法、自己提需求
聽用戶的但不要照著做
- 明確我們存在的價值
- 用戶需求：用戶自以為的需求，并且經常表達為用戶的解決方案。
- 產品需求：經過我們的分析，找到真正的需求，并且表達為產品的解決方案。
- 需求分析：從用戶提出的需求出發，找到用戶內心正真的渴望，再轉化為產品需求的過程。
- 滿足需求的三種方式：改變現狀、降低理想，轉移需求。
- 產品設計的最高境界——創造需求。
- 給需求做一次DNA監測
- 把用戶需求轉化為產品需求
- 需求種類
- 分類：新增功能、功能改進、體驗提升、BUG修復、內部需求
- 層次：分為“基礎、擴展（期望需求）、增值（興奮需求）”，可參考KANO模型。
- 分析需求的商業價值
- 確定商業價值后，還要初評需求的實現難度（工作量、開發量）。
- 一切看性價比
- 性價比 = 商業價值 / 實現難度（簡化為開發量）
活下來的永遠是少數
- 永遠忘不掉的那場戰爭
- 做項目，終極目標就是：多快好省，即范圍大、時間段、品質高、資源省。
- 需求的粒度在可行的情況下盡量小。
- BRD（Business Requirement Document）、MRD（Market Requirement Document）、PRD（Product Requirement Document）
- BRD內容：項目背景、商業價值、功能需求描述、非功能需求描述、資源評估、風險和對策。
- 別灰心，少做就是多做
- 情愿把一半的功能做到盡可能完美也不要把全部功能都做成半吊子。
心急吃不了熱豆腐
產品經理最基本的素質之一——熱愛產品。
- 在高層決定公司戰略的前提下，好的產品對我們的幫助會遠遠大于我們對產品的幫助。所以，產品經理的前若干年，好的公司，好的產品，好的老板，很重要。
項目的坎坷一生
項目的坎坷一生
從產品到項目
- 會有一個已經“結項”的項目，但不可能有一個已經“完成”的產品。
- 項目的定義：只會進行一次，包含多項目互相關聯的任務，并且有績效、時間、成本和范圍限制的一項工作。
- 產品經理——靠想。產品經理是做正確的事，其所領導的產品是否符合市場的需求，是否能給公司帶來利潤。內部驅動。最重要的是判斷力和創造力。
- 項目經理——靠做。項目經理是把事情做正確，把事情做得完美，在時間、成本和資源約束的條件下完成目標。外部驅動。最重要的是執行力和控制力。
- 一個事物必然有它的兩面，如果你只看到了一面，說明你只看到了系統的一部分，這時你一定要跳出去，尋早另一面，之后再努力尋找“對立”背后的“統一”，正如黑格爾所說的“正反合”。
一切從KickOff開始
- 做項目的本質就是在保證品質的前提下，在時間要求、人財務花費、項目范圍三點上做平衡。
- 溝通從頭開始。
- 有自己的WBS（Work Breakdown Structure,工作分解結構）文檔。
關鍵的青春期，又見需求
- 真的要寫許多文檔
- BRD，商業需求文檔。這是產品生命周期中最早的文檔，其內容設計市場分析、銷售策略、贏利預測，短小精煉，通常給老板演示PPT，主要為了獲得認可，爭取資源。
- MRD，市場需求文檔。獲得老板支持后，進入實施階段，需要寫出MRD，需有更細致的市場與競爭對手分析，包括可通過哪些功能來實現商業目的，功能、非功能模塊，功能的優先級等。這是從商業目標到技術實現的轉化文檔。
- PRD，產品需求文檔。PRD是對產品功能的進一步細化。文檔主要包含整體說明、用例文檔、產品Demo等，會對產品功能做具體描述。
- FSD（Functional Specifications Document）,功能詳細說明，從這步開始會出現很多技術的內容，產品界面、業務邏輯的細節都要確定。與此同時，硬件系統的設計、數據庫設計、表結構設計等工作，也開始由架構師、系統分析師編寫了。
- 學一點UML（Unified Modeling Language，統一建模語言）：類圖、用例圖、狀態圖、時序圖、活動圖及其他。（用visio畫）
- 字不如表，表不如圖。
- 用例文檔，UC，是需求人員寫給開發人員看的一種最基本的文檔。
- 需求活在項目中
- 寫作 --> 評審 --> 修改 --> 評審
- 評審：需求評審、設計評審、測試評審
日常需求發布流程
成長，一步一個腳印
- 開發：設計 --> 設計評審 --> 編碼 --> 單元測試
- 測試：TC（Test Case）編寫 --> TC評審 --> 冒煙測試 --> 功能評審 --> 測試
- BUG
- 項目發布：發布評審 --> 預發布 --> 發布 --> 線上驗證
- 作為項目經理，應該時刻做到為團隊成員爭取各種精神、物質獎勵。
山寨級項目管理
- 計劃和控制，就是項目管理。
1.文檔只是手段 - 建立自己的文檔規范。
- 模版的作用
- 讓經常看同類文檔的人提高效率
- 讓寫文檔的信任可以盡快上手
- 讓寫作者不會遺漏考慮某些內容
- 只制訂卻不執行的規定，只會反過來降低已有規定的權威性。
- 多人協作與版本管理：Wiki
- 用版本號管理文檔
- 流程也是手段
- 長視者把目的當手段，短視者把手段當目的。
- 個人的核心競爭力是把顯性知識轉化為隱性知識的能力，而團隊的核心競爭力是把隱性知識轉化為顯性只是的能力。
- 商業評審的三個決定是：項目繼續、重新定向、項目終止。
- 技術評審的三個決定是: 項目繼續、有風險的繼續、必須解決某問題后再繼續。
- 敏捷更是手段
- 從書本到實踐
- 有計劃，更要“擁抱變化”。
- 迭代周期盡量不加任務。
- 集中工作，小不快跑。
- 持續細化需求，強調測試。
- 不斷發布，盡早支付。
- 敏捷溝通：項目看板、項目墻。
- 任何情況下，我們都要做好手頭的事情，確保“就算這事兒對公司來說又黃了，我也要通過做事有所收獲”
物競天擇適者生存
- 親歷過的項目特色
- 老板項目、封閉開發、項目外包
- 一路坎坷，你我同行
- 邊計劃、邊行動、邊修改。
- 80%以上的項目是不成功的。
我的產品，我的團隊。
我的產品、我的團隊
大產品，大設計，大團隊
- 產品之大
- 時間之大：產品生命周期
- 產品生命周期里的五種用戶：創新者、早期追隨者、早期主流用戶、晚期主流用戶、落伍者。
- 空間之大：商業、產品、技術
- 商業、產品、技術，任何一個公司必然有它的強項和弱項，它不可能也沒有必要在這三方面都很強，一是因為構建“性價比團隊”的考慮，二是因為都強的話互相壓不住反而造成內耗，所以更重要的是找到自己公司、或團隊、或產品的那個突出的刀尖，也就是所謂公司的DNA。
- 在找工作的時候必須調查清楚自己的職位在公司里是不是最受重視的，是不是強勢方，這很重要。
- 設計之大
- 產品設計的五個層次
- 戰略層：明確商業目標和用戶需求，找準方向，重點是解決兩者之間的沖突，找到平衡點。
- 范圍層：明確“做多少”。
- 結構層：考慮產品的各個部分互相之間是什么關系。
- 框架層：
- 表現層：視覺設計和優化。
- 設計的目標分為三個層次：本能水平設計是基礎，產品要有用；行為水平設計是保證，產品要能用；反思水平設計是升華，是難以琢磨的“用的爽”。
- 反饋：動作前的可預測、動作中的積極響應、動作后的可評估。
- 容錯：一些貌似多余的強制性設計，不可逆操作可以后悔。
- 簡化：利用用戶已有的知識。
- 團隊之大
- 偶爾為之的事情追求可行解，經常為止的事情最求最優解。
游走于商業與技術之間
- 心思縝密的規劃師
- 從概念設計到信息架構
- 畫概念圖，表達出產品與外界、內部的關系。
- 激情四射的設計師
- 規劃師更多的是“結構化思維”，保證產品有用，能滿足用戶的某些需求，讓產品“從無到有”；而設計師更多的是“形象化表達”，保證產品好用，能讓用戶用起來舒服，讓產品“從有到優”。
- 陰險狡詐的運營師
- 運營負責把產品賣出去，讓產品從“叫好”到“叫座”，讓更多的人愿意使用產品。
- 事件+病毒營銷
商業團隊，沖鋒陷陣
- 我們覺得某樣東西虛知識因為對它不熟悉而已。
- 銷售是增加新客戶，服務是穩住老客戶。
- 好產品還需市場化
- 當自己對某個領域不熟悉的時候，做起事來總會把問題想象得很復雜，把自己知道的所有知識都用上，而真正的高手，是可以一下子就找出問題的關鍵，然后用最最見到那的方法就搞定。
- “高價炮灰、低價炮灰”
- 開過視野的水平營銷
- 我們還能做什么
- 服務部門是為昨天的利潤工作，給已經購買產品的客戶提供承諾的價值；銷售部門是為今天的利潤工作，把產品變成利潤，爭取更多的客戶；開發部門是為明天的利潤工作，確保明天我們有優秀的產品可以賣；研究部門是為后天的利潤工作，了解趨勢、發展科技，保證永遠處于領先位置。
- 維護一個老客戶的成本大約是開發一個新客戶的成本的四分之一。
技術團隊，堅強后盾
- 超級理性的人很明白“沒有規矩，不成方圓”的道理，他們喜歡被規則管理而不是被人管理。
- 思路的變形：不再考慮產品怎么做更好，而是去想如何說服對方。
容易被遺忘的角落
- 最好的資源：老板
- 讓老板做問答題 --> 選擇題 --> 判斷題。
大家好才是真的好
- 所謂的團隊文化。
- 虛無的無授權領導
- 管理崗位的優勢：
- 管理崗位利于擁有話語權
- 管理崗位利于獲取信息
- 管理崗位利于爭取資源
- 管理崗位的劣勢：
- 管理崗位有很多行政工作
- 管理崗位會讓人脫離群眾
- 讓優秀的產品經理在專業線路上擁有高級別；對于產品、業務的決策有充分的話語權；可以參與管理會議的業務討論；可以擁有臨時的資源支配權，并給管理層提供同事的考核建議；但不負責管理者的行政工作，而是繼續和同事打成一片，用產品證明自己。
- 贈送禮物和激勵員工的藝術
- 大中之小不如小中之大。
- 有用的不如無用的。
- 需要的不如想要的。
- 有選擇不如無選擇。
- 晚說不如早說。
- 一次送不如兩次送。
- 公開不如不公開。
- 漲工資不如發獎金。
- 獎勵或送禮的目的并不是真正給對方最大的效用，而是要讓對方開心，并且感激和記住你。
別讓靈魂跟不上腳步
觸及產品的靈魂
- 產品的靈魂——戰略
- 以價值觀為根基
- 培養大局觀
可行性分析三部曲
- 我們在哪兒
- 確定公司的價值觀、使命、愿景，關于公司、市場、競爭對手現狀的各種背景信息的采集與分析。
- 市場掃描（PEST分析）、競品分析、自我分析（SWOT分析）
- 小的成功靠朋友，大的成功靠對手
- 我們去哪兒
- 宏觀上的客戶需求
- 我們怎么去
- 一次真正的產品預研
做吧，準備出發
1.敢問路在何方
- 產品路標計劃
- 低頭之路，抬頭看天
- 開會和做一個產品一樣，不要試圖在會議中解決很多問題。
- 會議要有明確的主持人和記錄人。
- 所有人提供意見，少數人討論，一個人拍板。
產品經理的自我修養
- 愛生活，才會愛產品
- 有理想，就不會變咸魚
- 會思考，活到老學到老
- 只有方法，沒有答案
- 能溝通，在什么山頭唱什么歌
- 理論上嚴格意義的“充分溝通”是不存在的。
- 溝通不是為了說服，而是為了更好地認識世界。
- 職場的點對點溝通
- IM：成本最低，適合不緊急不重要的溝通。
- 電話：成本適中，適合緊急不重要的溝通。
- 面談：成本最高，適合緊急且重要的溝通。
- E-mail：成本始終，適合重要不緊急的溝通。
- 盡快找出對方感興趣的、熟悉的、擅長的、自己也懂一點的話題，從而破冰成功。
- 產品經理主義
- 解決問題的通用思路：為了什么？做什么事，解決什么人的什么問題？何時做？誰來做？效果如何？
