第一章? 寫給-1到3歲的產品經理

1.1 我們為什么要做產品經理？

我們生活中離不開產品，電腦、音箱、鼠標，臺燈等等，產品的好壞直接影響到我們生活體驗。好的產品使用起來給人以舒暢感，例如臺燈燈光的多亮度調節，而壞的產品給人生活帶來麻煩，比如沒寫推拉的一扇門。產品經理是不斷改進產品，給人們更好的產品體驗的人，比如垃圾桶分類從多一種顏色識別到直觀的標明易拉罐等東西是否可回收，簡化了人們使用該產品的思考深度，讓用戶更加省心。產品用戶分為新手、專家和中間用戶，因此產品設計者要考慮到用戶的層次，一個重要的設計準則就是無需閱讀說明書就能上手。

書籍推薦：《點石成金-訪客至上的網頁設計秘笈》

1.2 我們到底是不是產品經理

產品是用來解決某個問題的東西，其滿足的需求包括兩個：用戶需求和公司需求，產品經理要在用戶目標和公司目標之間尋找平衡。

產品經理源于寶潔，傳統產業的產品經理和互聯網軟件行業的產品經理有較大的區別：

1.傳統行業形態比較成熟，大多是實體產品，工作的重點在于營銷類創新；互聯網企業大多是虛擬產品，工作重點在產品的從無到有，偏重研發類創新，需要產品經理對市場發展趨勢有敏銳的洞察力，注重產品需求分析和設計細節。

2.傳統行業產品生命周期長，而互聯網產品生命周期端，推崇敏捷方法，經常需要在產品質量和目標完成度之間進行協調。

3.傳統行業大多靠賣產品盈利，互聯網產品大多免費，通過多元化的方式實現盈利。

4．傳統產品替代成本略高，包括用戶的時間成本等，而互聯網產品替代成本低，要求產品更注重用戶體驗。

書籍推薦：《產品經理的第一本書》和《產品經理的第二本書》

?1.3我真的想做，怎么入行？

產品經理重要的一點是思維模式，就打飛機游戲而言，用戶思維是如何快速升級和得分最高，而產品經理思維是如何控制飛機數量增加用戶粘性。

1.4 一個產品經理的-1到3歲

對初入職者，應保持好學的態度，主動去熟悉工作中需要的基本知識和技能，去了解產品的各個方面，包括功能、用戶、技術等，去與工作上有聯系的部門進行交流。

先跟著前輩學怎么做，再開始自己決定做不做，做多少。由于資源的有限性，不可能完成所有的需求，就要按照需求的優先程度進行取舍。

產品經理要接觸多方面的工作，不可能所有工作都親力親為，要保證產品離開產品經理同樣運行，應該把工作規劃法、流程化，使更多的工作可以讓團隊來完成。

圖1 全書結構圖

第二章? 一個需求的奮斗史

圖2? ?一個需求的奮斗史總布局

2.1 從用戶中來，到用戶中去

需求來源于理想和現實之間的差距，用戶大多時候會把需求描述成需求的解決方案，比如為了找到溫馨的感覺，他可能會管你要一幅畫，所以在確認用戶需求的時候一定要刨根問底。

產品應以用戶為中心（User-centered Design UCD ），然而很多產品的用能并不是來自于用戶，而是來自老板，因此產品經理不能只顧“造反”，而是要盡可能地幫助老板明確問題和需求價值，為其決定方向提出參考建議。

不要試圖滿足所有用戶，那會讓產品臃腫不堪，優先滿足哪些用戶要和產品的商業目標結合起來考慮.。

用戶在基層之中，所以要想真正了解用戶的需求，不能空想，必須真刀真槍的去研究他們。

描述用戶應該用人物角色（persona），來更深入的了解用戶的特征。

圖3 人物角色

用戶研究包括定兩個維度：說做和定性定量。

圖4 用戶研究的維度

橫向：怎么說表現了用戶的目標和觀點，怎么做反映了用戶行為。用戶怎么說和怎么做經常是不一致的，既要看用戶做了什么，又要通過說來尋找用戶行為的依據。

縱向：定性研究可以找出原因，偏向于了解；定量研究可以發現現象，偏向于證實。

推薦書籍：《贏在用戶：WEB人物角色創建和應用實踐指南》

產品調研可以遵循以下步驟進行：1，聽用戶定性地說，確定產品方向，列出需求列表；2，聽用戶定量的說，大量發放問卷，確定需求優先級；3，看用戶定性的做，針對先做的需求進行可用性測試；4，看用戶定量的做，根據用戶使用產品反饋進行數據分析，不斷改進產品。

2.2 需求采集的大生產運動

1.定性的說：用戶訪談

用戶訪談對象較少，每個用戶身上的問題比較多，用戶訪談用來了解目標和觀點，對新產品的研究方向進行預判。

在用戶訪談過程中，要注意“說”和“做”不一致的問題，用戶可能因為各種因素造成心口不一；要防止樣本過少帶來的以偏概全的問題，應通過增加樣本數量來驗證先前結論；防止和用戶聊與訪談主題無關的問題，應平等的對待用戶，不要把訪談做成產品推介會。

2.定量的說：調查問卷

調查問卷可以更多的搜集用戶數據，但要注意“沉默的與騎墻的總是大多數”，防止后來者因為先前人員的引導而做出錯誤判斷。防止樣本偏差、樣本過少、問題帶有誘導性等問題的發生。

3.定性的做：可用性測試

可用性測試是指讓用戶實際使用產品或圓形方法來發現設計界面中的可用性問題，用戶參與數量較少，在用戶測試的過程中要觀察用戶操作的全過程，并記錄發現的問題。

可用性測試避免做的太晚，導致問題發生時已經無時間更改；可用性測試要5個左右的用戶進行測試才可能發現問題；測試過程中，用戶應采用“發生思維”，對自己的行為進行說明，而測試者不應給予任何引導性信息。

產品改版的幾種方式：修改次級頁面；新舊版本并存，用戶自主選擇；小面積試驗；沿用已有用戶習慣。

4.定量的做，數據分析

數據分析要注意時效性，不要過于學術化；多方面解讀數據，防止出現解讀誤差；平時應注意數據搜集，不要造成無數據可分析。

數據搜集應從多角度進行，既要一手數據，也要銷售等人員的二手數據，使用二手數據時要注意數據提供人員可能出于自身目的提供帶有偏差的數據。

采集數據會用到單項需求卡片，樣本如下：

圖 5 單項需求卡片

2.3 聽用戶的但不要照著做

用戶需求和產品需求是不一樣的，只有經過需求分析，才能將用戶需求轉變為產品需求。

用戶需求：用戶自以為的需求，并且經常表達為用戶的解決方案；

產品需求：經過我們的分析，找到的真實需求，并且表達為產品的解決方案。

需求分析：從用戶提出的需求出發，找到用戶內心真正的渴望，再轉化為產品需求的過程。

真正的需求分析師的價值就在于無視用戶想要的東西，去探究他內心真正的渴望，再提出更好的解決方案。如果注重短期利益，那么用戶想要什么就可以給什么，如果注重長期利益，那么最好給用戶真正想要的東西。

需求的DNA檢測：確定一個需求的屬性

圖6? 一個需求的DNA

需求DNA檢測過程為：需求轉化→確定基本屬性→分析商業價值→初評實現難度→計算性價比

需求轉化是將用戶需求轉化為產品需求。

確定需求屬性包括需求編號、提交人、提交時間、所屬模塊、名稱、描述、提出者、提出時間、bug編號。

需求可分為新增功能、功能改進、體驗提升、bug修復和內部需求等類別，包括基礎需求、拓展需求和增值需求三種（可參閱KANO模型）。

分析需求的商業價值包括三個維度：重要性、緊急度和持續時間，其中在持續時間上，有些產品壽命比較短，比如為國慶節而涉及的產品。商業價值（商業優先級）是對上述指標的綜合評判，是需求列表中最核心的部分。

初評實現難度：實現難度一般用工作量來表示，而在互聯網軟件行業，開發量往往成為項目進度的制約瓶頸，因此實現難度往往用開發量來表示。由于初始需求并不十分明確，因此初評開發量的時候可以有一定彈性。

性價比=商業價值/實現難度（簡化為開發量）

2.4 活下來的永遠是少數

產品經理為爭奪企業開發資源，需要通過商業需求文檔向領導表明自身需求的重要性。商業需求文檔（business requirement document BRD）包括項目背景、商業價值、功能需求描述、非功能需求描述、資源評估、風險和對策幾個方面。其中商業價值和資源評估是最主要的方面，資源評估要評估PD（產品設計師）、UE（用戶體驗師）和開發工程師的工作量。

在確定項目的過程中很多需求會被砍掉，這是由于資源限制造成的。然而在確定需求的過程中，必須要經歷需求從少到多再到少的階段，這樣才能更好的從整體上把握產品的需求。情愿把一半的功能做到盡可能完美也不要把全部功能都做成半吊子。

2.5 心急吃不了熱豆腐

需求是有生命周期的，從一個需求的產生到最后被拋棄或者發布，都要進行記錄，稱之為需求管理。

需求管理還可以有附加價值，比如通過統計提交人、提交時間、發布時間、模塊等維度的需求數量，來發現不同時期需求數量的增減變化，進而分析為何發生這些變化，為產品制定策略提供依據。

圖7 需求的生老病死

?第三章 項目的坎坷一生

3.1 從產品到項目

產品和項目時不同的，產品注重創新，而項目注重計劃與控制，產品通常是可以批量生產的，而項目一般只執行一次。

產品經理靠想，重點要有創造能力，屬于內驅；項目經理靠做，要有執行能力，屬于外驅。

產品經理和開發經理都有可能成為項目經理，而二者的目標是有區別的，產品經理可能想要增加增多的功能來滿足用戶需求，而開發經理想盡可能地少做工作。良好的產品經理在做項目的時候注重產品功能和項目完成度之間的權衡。

3.2 一切從kick off 開始

Kick off指的是項目啟動大會，在項目結構中，項目經理并非是項目的頂端，而應該組織一個“項目督導委員會”，由項目的老板擔任，這樣一方面可以讓他們隨時了解項目進度，另一方面可以更方便的爭取資源。

項目進行中，除了需求搜集中BRD給出的工期之外，還要對工期進行細化，將工期細化到1人天，1人天約等于5-6人小時。工期的公式為：

工作量=（最樂觀+最悲觀+最可能）/3

或“工作量=（最樂觀+最悲觀+最可能*4）/6”

項目開始要制定好項目的溝通方式，比如溝通周期、溝通渠道、發起者和參與者。

KO會議包括項目背景、項目意義與目的、需求功能點概述、項目組織結構、項目計劃（項目的時間點與里程碑以及各時間段所需要的資源）以及溝通計劃。

做項目的目標是多快好?。悍秶?、時間短、品質高、資源省。也有TRQ之說，即時間、資源和質量/數量。

項目中應進行任務分解，即WBS（work breakdown structure），有經驗的項目可以自上而下，無經驗的項目可以自下而上，列出最小的任務點進行匯總。隨著項目越做越多，應該形成自己的wbs模板，以后再遇到相似項目時可以快速進行任務分解。

3.3 關鍵青春期，又見需求

產品經理要寫很多文檔，主要有：

BRD ：商業需求文檔，內容涉及市場分析、銷售策略、盈利預測等，給老板看。

MRD：市場需求文檔，有更細致的市場競對分析，包括可以通過哪些功能來實現商業目的，功能、非功能需求，功能優先級等。這是從商業目的到技術實現的關鍵轉化文檔。

PRD：產品需求文檔，是對產品功能的進一步細化，包含整體說明、用例文檔、產品demo等。

FSD 功能詳細說明，這里會有較多的技術內容，產品界面、業務邏輯細節等。

其中PRD是產品同學經常需要的文檔，樣板如下：

圖9 PRD模板

?修訂歷史：修訂的版本號及日期等信息；

項目概述：項目背景、意義、目的、目標等；

功能范圍：PRD的業務邏輯圖，重點描述系統中的角色與職責、與周邊系統的關系、全局的商業規則等。

用戶范圍：本PRD涉及的角色和系統；

詞匯表：本PRD專有的詞匯和術語；

非功能需求：數據監測等；

UC（user case）即用例，PRD要將各用例可視化表示，并說明各用例之間的關系，一般有類圖、用例圖、狀態圖幾種。用例的制作要用到UML（unified modeling language），即統一建模語言，用于規范圖形的制作（推薦書籍：UML基礎案例與應用）。

UC整體說明表述各用例之間的關系，不涉及用例的內部細節，常用的圖有類圖、用例圖和狀態圖。

類圖（class diagram）描述系統中出現的各對象之間的關系，以及和外部系統的關系，讓人明白此系統是做什么事的。下圖為小明與菜之間的聯系方式。

圖10 類圖

用例圖（use case diagram）描述用例之間的關系，下圖表明小明進飯館后可能進行的行為：

圖11 用例圖

狀態圖：（state diagram）表達系統里實體狀態的轉換，貫穿多個用例，下圖表明小明狀態的轉化：

圖12 狀態圖

UC正文講述單個uc的詳細狀況，是需求人員給開發人員的一種最基本的文檔，理想狀態下，一個UC代表了產品需求列表里的一行，但實際上并不絕對，也可能一個UC滿足一個產品需求，或者一個UC涉及多個產品需求。UC模板如下：

圖13 UC模板

其中：

前置條件表明觸發這個用例的前提是什么；

后置條件說明用例完成后續動作是什么？比如服務員接受訂單去廚房。

界面描述：通常給出截圖，界面上也種元素的說明，并且會和demo結合起來。

業務規則：表述整個用例的通用規則，比如限制小明不吃辣等，界面規則和流程規則不應放在這里。

流程描述：分主干、分支和一場三種，描述用例發生過程中有什么事件觸發，系統與用戶事件的交互步驟等。

UC一般只描述功能性需求，非功能性需求寫在PRD的總體說明里。UC對語言要求比較高，需要做到無歧義、完整、一致可測試等。

UC內部也許他用到UML，包括時序圖、活動圖和協作圖等，用于描述業務規則和流程。

時序圖（sequence diagram），描述事物變化在時間維度上的先后順序，表達對象的交互。

圖14 時序圖

活動圖（activity diagram）描述各種動作如何引起系統變化，善于表達泳道較多、分支較多的情況。

圖15? 活動圖

推薦UML的工具：Visio，當然，如果團隊里其他人看不懂UML，不要強推。

產品demo的制作在產品會議開始之前就可以開始了，有可能的話在BRD中展示出來，很可能成為爭取資源的加分因素。Demo最開始可以用紙畫一個簡單的，后面可以用Visio、PPT等制作，最后可以用Axure、Dreamweaver等軟件來制作出具有交互效果的頁面，當然，這可以與UE的同學一起做。

評審是項目中不可缺少的環節，包括需求評審、設計評審和測試評審三個階段。需求評審是對PRD、UC和demo評審的總稱，設計評審由開發工程師把對需求的理解以設計文檔的形式說給PD、測試聽。測試評審稱為TC，是在TC編寫完成、測試開始執行之前由測試工程師把對需求的理解說給PD、開發聽。

評審的原則是“改動較多的話必須再次評審，異議不大的可以通過”，在需求評審的過程中一定要叫能做決定的人和與此項目有關的產品接口人參與，防止與其他系統有沖突，導致后面來不及修改。

從項目中看一個需求的生老病死如下圖：

圖16? 項目中一個需求的生老病死

3.4 成長，一步一個腳印

在完成項目之后，要寫項目總結，說一下項目心得體會以及經驗教訓。項目總結并不非要等到項目結束后在寫，而是在項目進行過程中以日報和周報的形式來記錄。

3.5 山寨級項目管理

互聯網軟件項目中幾個關鍵問題：文檔管理、流程管理、敏捷方法

文檔是手段

項目管理人員應建立自己的文檔規范，并定期省級整理，PD常用的文檔范圍如下：

圖17 PD常用文檔模板

?其中WBS（工作結構分解）可以用WBS Chart PRO 軟件來制作。（本書模板已下載）

畫腦圖可能用到的工具有mindmanager、freemind 、xmind等，軟件推薦Visio（畫圖）、outlook（郵件管理）、project（安排計劃）。

流程也是手段

流程存在的好處是人走了，事兒還能做，減少特定的人的影響，當年的“英雄”把自己的個人經驗轉變成顯性知識表達出來，而對于經常做的事情，就可以用流程這種形式固化、傳承，后人在做這些事情的時候不會太無助，這點上，規范、模板的作用也類似，這就是團隊的核心競爭力。流程對產品有利，但對于個人成長或許不利，因為他只讓人接觸到工作的某個層面，缺少對大局的把握。

敏捷更是手段

敏捷的入門書籍有《敏捷迭代開發-管理者指南》和《敏捷估計與規劃》。敏捷模式的特點如下：

1.有計劃，更要擁抱變化，要在計劃中給予一些彈性；2.迭代周期內盡量不加任務，在一個迭代周期內如果需要增加東西，可以延伸到下一個迭代周期；3.集中工作，小步快跑，工作群體應少于十幾個人，推行站立晨會，加強交流溝通；4.持續細化需求，強調測試，需求要在測試過程中不斷細化，而不是一開始過分細化；5，不斷發布，盡早交付，讓需求方盡早的看到結果并給與反饋，先解決最核心、風險最大的部分。

敏捷溝通是敏捷方法里的重要部分，溝通方式可以是im群、郵件列表、項目看板等。

第四章 我的產品，我的團隊

圖18 我的產品 我的團隊

4.1 大產品，大設計，大團隊

產品之大可以從兩個維度分析：時間之大和空間之大

圖19 產品生命周期

產品的時間之大是從產品生命周期角度來講的，《公司進化論：偉大的企業如何持續創新》和《跨越鴻溝》兩本書對產品生命周期進行了介紹，產品生命周期主要包括五個部分：

創新者：新鮮感強，消費能力強，為了新技術而使用某產品，忠誠度較差，需要新鮮的東西不斷刺激。

早期追隨者：為了解決某種需求而使用某產品，會給產品提出很多意見，這些人可以發展成產品的種植永不，不斷給產品提出改進意見。他們可以自主的研究產品的用途，因而稱為專家用戶。

早期主流用戶：產品大規模產生商業價值的用戶群，實用主義者。他們不主動探索新產品的使用方法，因此產品應該做得簡單易用，為“中間用戶”和“新手服務”。

晚期主流用戶：對新產品心存抵觸，直到老產品不能滿足需求的時候才很不情愿地使用新產品。在此時不能僅靠產品的功能競爭來獲得用戶，而是市場營銷發力的時刻。

落伍者：附加值較低，產品逐漸退出市場。

從產品生命周期角度，我們應該清楚現在主打哪種類型的市場與用戶，他們的特點是怎么樣的，然后再決定產品的特點與功能。

產品的空間角度是指產品商業、產品和技術三個方面。

商業決定了產品的渠道、定價策略、促銷策略和服務方式等，包括市場、銷售和服務部門。

產品包括產品設計、用戶體驗、產品運營等部門，決定了產品的功能范圍、交互流程、視覺表現和運營手段。

技術主要包括開發、運維和測試，決定了產品的穩定性、性能和Bug數量。

在上述三方面中，公司可以維持其中一個作為強項，三方面都強范圍會造成公司內耗增加。

設計之大包括設計的五個層次，推薦書籍《用戶體驗要素》：

圖20 設計的五個層次

戰略層：明確商業目標和用戶需求，找準方向，平衡二者關系。

范圍層：明確“做多少”，軟件類產品應確定功能范圍，網站了產品應確定內容范圍，這時應做好產品的需求采集分析、篩選、管理和開發工作。

結構層：考慮產品各部分之間的關系。

框架層：這時用戶看到的東西，軟件類產品的主要工作是界面設計，網站類產品是導航設計。

表現層：包括視覺設計和內容的優化，表現了產品最終的氣質。

設計類的書籍推薦《設計心理學》和《情感化設計》，書中將設計水平分為三個階段：本能水平設計，也即純生理的視覺沖擊，看上去就好看；行為水平講的是產品的功能、用戶與產品交互層面的設計；反思水平的設計將純心理需求納入產品的涉及范圍。對于面向普通用戶的產品，本能水平、行為水平和凡是水平應逐個滿足：本能水平設計是基礎，產品要有用；行為水平的設計是保證，產品要能用；反思水平的設計是升華，產品要好用。

團隊之大包括產品制作過程中各種不同職位團隊的存在，包括職能型組織、項目型組織和矩陣組織。為加強團隊之間的交流，應該設計團隊接口人的存在，接口人應選擇資歷比較深的同學擔任，可以起到問題過濾的作用，解決大部分同學搞不定的問題，并對相似問題進行合并，提升交流效率。

4.2 游走于商業與技術之間

產品團隊是游走于商業與技術之間的團隊。

狹義的產品團隊指的是產品經理及其帶領的產品規劃師、產品設計師和需求分析師：產品設計師桂花茶農定位、發布時間等，聚焦于商業目標和用戶需求；產品設計師側重于功能級的設計，編寫需求文檔；需求分析師偏實現、技術，即UC，做系統設計。

產品概念設計是產品設計的起始，產出是產品概念圖。首先在搜集的需求的基礎上將需求分類，確定需求之間的關系，在思維導圖的基礎上畫出概念圖。產品概念圖有兩個重點：產品與外界的關系、產品內部模塊之間的關系。概念設計推薦書籍《Web信息架構》。

PD可以通過多種崗位轉化而來，PD成員組背景應該盡量豐富，實現優缺點互補。

產品規劃師更多的是“結構化思維”，保證產品有用，能滿足用戶的某些需求，讓產品從無到有；而設計師更多的是“形象化表達”，保證產品好用，用起來舒服，讓產品“從有到優”。

產品demo的制作應由PD和UE共同完成，保證大家對商業目標理解的一致，確保界面上每一個細節設計都有理有據，包括區域位置、長寬和字體、字號大小。

產品中文案設計并非長篇大論的宣傳文案，而是產品頁面上的說明文字，文案問題分為三個級別：

低級錯誤：錯別字、病句、錯誤標點。

中級階段：用詞不統一，不準確，如既有新建，又有創建。

高級階段：語言風格不統一，如既有賣萌的，又有嚴肅的錯誤提示等。

產品與運營之爭由來已久，運營只能把人帶來，而留住用戶則需要靠產品了，運營同學背負著更直接的商業指標，因此在一些活動中可能采取治標不治本的方式。

4.3 商業團隊，沖鋒陷陣

商業團隊包括銷售、服務和市場團隊，負責產品的定價與促銷，銷售與渠道等?；ヂ摼W軟件行業常用一種“炮灰版”的銷售策略，比如添加一些沒必要的功能做一個高價的“炮灰版”，或者刪掉核心功能做一個低價的“炮灰版”，其核心都在于利用心理學讓人們購買正常版。

產品與銷售應該相互配合。對產品來講，產品研發之前就已經確定了目標用戶，對銷售來講，為了增加銷量可能并沒有賣給產品最初的目標用戶。因此當一個產品制定出來，原有目標用戶并不買單的時候，可以通過銷售改變目標人群。

4.4 技術團隊，堅強后盾

技術團隊包括開發、運維和測試。

產品的需求是一直在變，因此產品與工程師交流時最大的障礙就在于“變”。

4.5 最容易被遺忘的角落

這部分圖團隊包括行政、財務法務和老板。

在公司中，老板是最好的資源，不要老板或者仇視老板，而應利用他們不斷成長，在自己發現問題并獲得良好的解決方法的情況下，請示老板獲得授權。

第五章 別讓靈魂跟不上腳步

5.1 觸及產品的靈魂

產品經理在成長過程中，要經過三個階段：第一層，產品幫我們，我們被動接受做產品的安排，從中學習。第二層，我們與產品相互幫助，共同提高。第三層，我們幫助產品，我們占據主導地位，幫助產品開拓局面，創造產品。

價值觀是創造產品的基礎，是產品的靈魂。產品經理很重要的觀念是“大局觀”，也即從整體上看待局勢的能力。如果我們感覺公司戰略有問題，不妨去問一下老板公司進行某種戰略的原因，找高手解惑本身就是一件對自己提升很大的事情，培養自己的大局觀可以以更廣闊的視野看待問題。

5.2 可行性分析三部曲

可行性分析包括我們在哪兒、我們去哪兒和我們怎么去三個階段。

我們在哪兒是在明確公司愿景、使命和價值觀的基礎上，進行市場掃描、競品分析和自我分析。市場掃描指的是宏觀環境的分析，常用的方法PEST分析。競爭對手分析常用的是APPEALS分析法，主要的信息來源有網絡收集、研究報告（主要報告的客觀性）和請第三方公司調研，請公司有經驗的老板拍腦袋而定也不失為一種有效的方法。自我剖析常用的方法是swot分析。

我們去哪里是指考慮產品細分市場、目標用戶等問題，常用的分析方法有安索夫矩陣、波特五力模型，BCG矩陣、GE矩陣等。

我們怎么去說的是用什么產品怎么滿足用戶需求的問題，包括定價策略、推廣策略、渠道策略等。

5.3 做吧，準備出發

出發指的是通過制定產品計劃，向既定目標前進的過程。對產品來講，最大的計劃是產品路標規劃，是針對一個產品長時間的規劃，包括產品發展方向、時間點和里程碑等。最小的計劃是執行計劃，計劃最重要的作用是提前準備，以免出現緊急情況時我們手足無措。

會議是計劃過程中不可少的項目，有效地會議包括以下幾點：1.不要試圖在一個會議中解決很多問題；2.提前準備，確定所需資源和與會人員，提前給與會人員發出會議資料；3.會議主持人要把握均衡發言，控制會議進度，做好會議記錄；4會后要整理會議記錄，表明會議決定和遺留問題。

圖21 會議記錄

5.4 KPI

KPI的存在是將公司戰略分解為每個員工可衡量的指標，要符合SMART原則：S代表具體，不能籠統；M代表可度量;A代表可實現，避免目標過高或過低；R代表現實性，績效指標要實在，可證明和觀察;T代表時限，注重完成指標的特定期限。

KPI可能造成員工過分關注數字，而忘記了數字背后的目的，因此不要把KPI當成目的，它本身只是一種手段。

第六章 產品經理的自我修養

產品經理的自我修養包括愛生活、有理想、會思考和能溝通四個方面。

6.1 愛生活，才會愛產品

一個人只有有樂觀積極的生活態度，才會有愛，才會發現生活中的美，才會有好奇心和創造力，愿意研究生活中的產品。因此生活中要保持對產品及其背后設計邏輯的好奇心。用戶可能對產品開發出一些延伸功能，比如MSN的簽名做廣告牌等，關注用戶創意，可能對產品功能改進有很大的幫助。

6.2 有理想，就不會變咸魚

人與公司的成長應該共同進行，不能為了自身發展損害公司利益，也不能為了公司發展限制自身發展。在工作過程中應通過不斷積累經驗創造職業保障，增強自身的職業競爭力。

6.3 會思考，活到老學到老

產品經理是一個對思維能力、學習能力要求很高的角色，每個人都需要補課。我們的教育交給我們知識但沒有交給我們思考問題的方式；交給我們那些好而不告訴我們為什么另一些不好，產品經理是要在多種需求之中做出選擇的；交給我們努力而不教取巧，產品經理有時還要在資源很少的情況下完成任務，必須取巧；交給我們受教而不施教，而教別人的過程中可以學到更多的東西。

6.4 能溝通，在什么山頭唱什么歌

產品經理要和多種人溝通，然而由于信息的不對稱，并不存在完全的“充分溝通”，因此我們要明白溝通的意義不是在于說服別人，而是通過溝通交流更好的理解彼此的意見，達成一致的協議。

職場中溝通方式有IM、電話、面談和email等，根據重要程度和緊急程度可以做如下劃分：

適合IM溝通的事兒：兩三句話就可以說明白的事兒；不用討論只是告知的事情；不急的事情；上不了臺面的事。

面談最大的優勢是人們不喜歡當面拒絕。

Email最大的優勢是可以留下證據。

針對客戶，交談的時候可以事先搜集客戶資料，根據然后盡快找出對方感興趣的、熟悉的、擅長的并且自己也知道一點的事情開始聊天。

6.5 產品經理主義

?

產品經理的思路是：為了什么？做什么事，解決了什么人的什么問題？何時做？誰來做？效果如何？

“為了什么”是大前提，是公司的戰略層面；“做什么事，解決了什么人的什么問題”是用戶的目標和需求，以及轉化完成的產品需求；“何時做。誰來做”是項目和團隊，著重講計劃、執行和控制；“效果如何”是事后總結，是持續改進和提高的基礎。