人人都是产品经理的真谛
不是每个人都能以产品经理为业，但在我看来，产品经理是一类人，他们做事的思路与方法可以解决很多实际的生活问题。
只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么，你就是产品经理。
至少，你已经是自己的产品经理了。这才是“人人都是产品经理”的真谛。
写给-1到3岁的产品经理
产品就是用来解决某个问题的东西，产品可以是有形的实物，也可以是无形的服务
并不是所有的产品都会变成商品，公益性、非营利的产品随处可见。但我们生活中所做的产品，绝大多数都需要在用户目标和公司的商业目标之间寻找平衡。只考虑用户目标，公司无法盈利；只考虑商业目标却留不住用户，公司也无法发展
| 传统行业 | 互联网行业 | |
|---|---|---|
| 行业形态不同 | 成熟行业，市场已经成熟，产品基本定型，通常只能渐变式地进行创新，很难有重大突破。用户对产品也形成比较固定的使用习惯，较难改变。对于这样的市场和用户，公司会偏重营销类创新 | 新兴行业，产品需要推陈出新、占领用户、主导用户习惯。偏重研发类创新，以实现“从无到有、从有到优”的不断优化 |
| 产品形态与成本结构不同 | 多为实物，有采购、仓储、物流等分工。产品研发出来后还要面对制造成本，产品经理需要考虑如何打通整个供应链、怎样销售、分销、促销等 | 多为虚拟物品，公司相对较轻，团队经费和制作成本都更加集中花费在产品研发过程中，公司团队可能只有几十个人，面对的用户却可能有上百万个，这在传统行业不可想象 |
| 生命周期不同 | 产品研发周期一般是几年，需要较为复杂精细的流程来支撑 | 研发周期为几个月，研发管理过程会更精简，推崇敏捷方法 |
| 盈利模式不同 | 单一卖产品赚钱，很多情况下客户只是买产品的人不是用产品的人，也许搞定几个大客户就能维持业绩 | 多元盈利，比如广告等，产品大多为使用产品的终端用户所做 |
| 用户心态不同 | 花钱买，即使产品稍有缺陷也凑合着用 | 免费用，只要这个产品稍有瑕疵，用户可以很方便改用别的产品 |
资源充分时，正确地做事很重要；资源出现瓶颈，做正确的事很重要。管理的能力其实就是“在资源不足的情况下把事情做成”的能力，资源不足表现为几种形式：
- 信息不足以决策
- 时间不足以安排周密的计划
- 人员不足以支持工作强度和难度
- 资金不足以自由调配
用户是我们的云，提供水汽。通过需求管理过程的催化，水汽凝结成雨。项目为河流，来自云层的雨水汇聚成河，流过并滋润大地。我们的团队如同各种动植物在其中促进整个过程。战略就像阳光一样驱动着整个循环，而这个生态系统的根基就是大地，产品经理的自我修养。
谈需求：一个需求的奋斗史
在一个生态系统中，水是万物生命之源，而水之源又是天上的云，它们转化为雨，滴落并滋润大地
用户研究：从用户中来到用户中去
从用户中来到用户中去有两层意思：
- 需求或直接或间接都是“从用户中来”的，所以我们要“到用户中去”
- 产品设计的过程是一个闭环，需求的源头是用户，而产品发布以后，在整个生命周期中，仍然要不断地“到用户中去”收集反馈，作为产品改进的依据
用户是需求之源
人类为什么有需求
- “食色性也”，“食”是为了生存，保证个体延续，“色”是为了繁衍，保证种族延续，这是生物（包括人）的本性，即最基本的需求
- 1943年，由美国著名犹太裔人本主义心理学家亚伯拉罕·马斯洛提出了需要层次理论，此理论将人的需要划分为五个层次，由低到高，分别是：生理的需要、安全的需要、归属与爱的需要、尊重的需要、自我实现的需要
生活中存在太多的问题，让人感觉不满意，而这些问题归根究底就是“理想与现实的差距”，人类会很自然地产生“减少甚至消除这个差距”的愿望，这就产生了需求
需求的本质就是“问题”。作为产品经理，我们每天都在设法满足用户的需求，其实就是在解决各种各样的问题
用户VS客户
用户是使用产品的人，客户是购买产品、为产品付钱的人
用户与客户可以是同一个人，也可以不是同一个人
以用户为中心的思想
UCD：以用户为中心的设计
不要试图满足所有用户
试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪、谁都不满意的四不像
谁对我们重要就先满足谁，需要和产品的商业目标结合起来考虑，简单来说就是看KPI（关键业绩指标）是什么
你真的了解用户吗
了解真正的用户
想了解用户，光靠空想是不行的，他们是真实的、是五花八门的，必须得真刀真枪地去研究他们
试着描述用户
创建人物角色：是研究用户的系统化方法，它是产品经理、交互设计师了解用户目标和需求、与开发团队及相关人员交流、避免设计陷阱的重要工具
具象化人物角色可以帮助新人在刚进团队时迅速了解用户、理解产品，同时帮助忙碌的、无法关注细节的老板迅速进入状态，保证他们也能像创建者一样，心中时刻想着正确的用户形象
聊聊用户研究
用户研究的方法：
“说”表现了目标和观点，“做”反映了行为，用户“怎么说”和“怎么做”经常是不一致的。只了解“做”是没办法知道背后原因的，而不知道问题的原因也就意味着没办法从根本上解决问题。所以，我们既要看用户怎么做，也要听用户怎么说
定性研究可以找出原因，偏向于了解，而定量研究可以发现现象，偏向于证实。只进行定量研究会导致“以表代本”，我们只能看到问题但不知道原因，只进行定性研究会导致“以偏概全”，我们很可能被部分样本的特殊情况带入歧途
焦点小组：是由一个经过训练的主持人以一种无结构的自然形式与一个小组的被调查者交谈，可以视为一种一对多的用户访谈形式
需求采集：产品源头的大生产运动
用户研究，或者说需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，最后进入下一步的需求分析阶段
定性地说：用户访谈
用户访谈可以了解用户怎么说，即他们的目标和观点，用户访谈经常被用在新产品方向的预研工作中，或者通过数据分析发现现象以后，用来探索现象背后的原因
用户访谈的常见问题与对策
- “说”和“做”不一致的问题：尽量在用户可以和产品发生交互的场合下进行用户访谈，让用户在“说”的同时也“做”，以防止被“骗”；另外也要注意区分用户说的事实与观点
- 样本少，以偏概全的问题：选择样本的时候需要多加注意，尽量做到随机
- 用户过于强势，把我们往沟里带：时刻牢记访谈的目的
- 我们过于强势，把用户往沟里带：时刻牢记访谈的目的
- 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读
- 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做
- 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面
- 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式
- 鼓励讲故事：故事是最好的帮助设计师理解用户的方法
- 避免诱导性的问题：典型的诱导问题是“如果有xx功能，你会使用吗？”一般来说用户会给出毫无意义的肯定答复
用户大会
用户大会是邀请产品的用户到某一集中地点开会，人数一般在几十人到几百人不等，可以短时间内收集大量信息，是一种特别的用户访谈形式
- 明确目的
- 资源确定
- 现场执行
- 结束以后：资料整理、运营、资料归档
种子用户：是指对某产品忠诚度很高的用户，产品设计者与他们长期保持交流，让他们试用最新产品，可以经常从他们那里获得对产品的建议和意见
定量地说：调查问卷
调查问卷适合大量用户的信息收集，但不够深入，一般只能获得某些明确问题的答案。经常通过用户访谈的开放式问题为调查问卷收集具体的封闭式问题的素材
- 问卷目的
- 明确样本对象、调查渠道、时间计划
- 问卷内容
调查问卷的常见问题与对策
- 样本用户与想了解的目标用户存在偏差：尽可能覆盖目标群体中各种类型的用户；要保证各种类型用户的样本比例接近全体的比例
- 样本过少的问题
- 问卷内容的细节问题：问题表述应无引导性；被调查者选择的答案可能与该答案的排列位置有关
灰度发布：互联网产品发布上线的一种常用形式，先让少量用户看到新产品，利用他们的反馈进行修正，逐步把新产品展现给所有用户
定性地做：可用性测试
可用性测试即通过让实际用户使用产品或原型来发现界面设计中的可用性问题，它是UGC用户产生内容理念的一种很实用的实践
- 明确目的
- 招募测试用户，这些测试用户要能尽可能地代表将来真实的用户
- 准备测试任务
- 测试过程
- 测试结束后，组织者可以询问用户对产品的主观看法或感觉
- 研究和分析
可用性测试的常见问题与对策
- 如果可用性测试做得太晚，比如在产品马上要上线的时候，这时发现问题也于事无补了
- 总觉得可用性测试很专业，所以干脆不做
- 明确是测试产品，而不是测试用户
- 测试过程中，组织者该做的和不该做的
定量地做：数据分析
数据分析最关键的步骤就是对结果的解读，通常数据分析只能发现一些现象和问题，并不能了解原因，所以分析完成后我们通常会跟进举行一些用户访谈，听听用户怎么解释
数据分析的常见问题与对策
- 过于学术，沉迷于“科学研究”
- 虽然数据不会主动骗人，但我们经常无意或有意地误读数据
- 平时不烧香，临时抱佛脚
需求采集人人有责
一手需求与二手需求
二手需求采集工具：单项需求卡片
尽可能多地采集
需求采集，并不是产品设计之前的工作，而是一个贯穿产品生命周期的过程。它不只是产品人员的事情，而是所有人的责任，它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求
- 现场调查：和客户一起工作一段时间，深入了解需求，要特别小心被“非典型”用户带到沟里去
- AB测试：同时做方案A和方案B，并应用在不同的用户身上，然后根据反馈再做下一步决定，这个方法比较适合用户量大的产品
- 日记研究：去阅读分析用户写的关于产品的文章，要注意日记的作者往往是同行，而不是主流用户
- 卡片分类法：把产品的各种需求写在便利贴上，让用户一起讨论并完成分类，可以让最终的产品更加符合用户的心理模型
- 自己提需求
需求分析：听用户的但不要照着做
明确我们存在的价值
用户跟福特要一匹更快的马，福特却给了用户一辆车。这就是我们存在的价值
用户需求VS产品需求
用户需求：用户自以为的需求，并且经常被用户表达为解决方案
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程
满足需求的三种方式
- 提高现实：我们最常用的方法，去开发某种产品，但也是最笨的方法
- 降低理想：“打预防针”、“丑话说在前头”
- 转移需求：因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了
也谈创造需求
我们无法创造需求，但是可以创造性地满足用户的需求
给需求做一次“DNA检测”
把用户需求转化为产品需求
在这个阶段，团队经常举行头脑风暴，最终整理出一份Feature List功能列表。表格中每一行是一个产品需求，而每一列描述了产品需求的一种属性
确定需求的基本属性
| 需求属性 | 属性说明 |
|---|---|
| 编号 | 需求的顺序号，唯一性标识 |
| 提交人 | 需求的录入PD，负责解释用户需求和产品需求 |
| 提交时间 | 需求的录入时间，辅助信息 |
| 模块 | 根据产品的模块划分 |
| 名称 | 用简洁的短语描述需求 |
| 描述 | 需求描述无歧义性、完整性、一致性和可测试性等，简要描述原始需求 |
| 提出者 | 即需求的原始提出者，有疑惑时便于追溯 |
| 提出时间 | 原始需求的获得时间，辅助信息 |
| Bug编号 | 将一些Bug视为需求，统一管理 |
需求的种类
| 需求属性 | 属性说明 |
|---|---|
| 分类 | 新增功能、功能改进、体验提升、Bug修复、内部需求等 |
| 层次 | 基础、扩展（期望需求）、增值（兴奋需求），理论依据参考KANO模型 |
产品需求=产品功能需求+产品非功能需求
产品包需求=产品需求+市场需求+开发需求+测试需求+服务需求+…
当一个扩展/增值需求被普遍满足以后，它也就慢慢的变成基础需求了
分析需求的商业价值
通常在这个时候举行需求讨论会
| 需求属性 | 属性说明 |
|---|---|
| 重要性 | 重要程度，辅助确定商业价值 |
| 紧急度 | 紧急程度，辅助确定商业价值 |
| 持续时间 | 持续时间，辅助确定商业价值 |
| 商业价值 | 商业优先级，不考虑实现难度，群体决策 |
初评需求的实现难度
| 需求属性 | 属性说明 |
|---|---|
| 开发量 | 需求的开发工作量，表征实现难度 |
此时，需求往往不明确，开发人员无法评估开发量，产品人员又没那么多时间明确每个需求具体该怎么做，技术部门不评估每个需求的开发量，产品就不知道哪些值得进一步分析怎么做，而哪些又不值得。解决办法是找经验丰富的开发人员进行初评，开发量允许有误差，初评时采用三点估算法：
- 工作量=（最乐观+最悲观+最可能）/3
- 工作量=（最乐观+最悲观+最可能*4）/6
在项目启动之后，制定项目计划的时候还会有一次更精确的评估，那时候已经知道需求要怎么做、由哪位开发工程师来做，所以可以推算出相对准确的工期
判断需求的性价比
| 需求属性 | 属性说明 |
|---|---|
| 性价比 | 商业价值/开发量，用于决定先做哪个需求 |
需求筛选：活下来的永远是少数
需求筛选，也叫需求PK
永远忘不掉的那场战争
按产品线划分团队，某个产品有自己的产品设计师、开发与测试人员，这对产品本身是有利的。产品经理权力更大，可以按照自己的想法做。不但资源有保证，产品规划也不容易被改变。此外，各种职能的员工之间沟通顺畅，开发的领导、测试的领导等都对产品经理负责
按职能线划分团队，产品中心包括所有的产品经理和设计师，研发中心包括所有的开发工程师、架构师等，质控中心包括所有的测试工程师，这对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高。由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。但是，资源战争可以把鲶鱼效应从产品内部扩大到公司层面，使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事
在创业期需要产品线结构，而当公司里有多个产品慢慢成熟之后，就可以用职能线来更充分地利用资源，实现资源共享
准备出发：把需求打个包
- “需求打包”最好打包类似的功能点，打包以后通过业务逻辑图的方式可视化，可以更直观地给别人讲解
- 功能互相之间有依赖关系
- 需求的粒度大小问题
战场：产品会议
武器：商业需求文档
商业需求文档简称BRD，包括以下内容：
- 项目背景：我们在哪里？即为什么要做这个项目，这个项目解决什么问题，可以列出一些数据说明项目的必要性
- 商业价值：我们去哪里？这是最关键的重点，一般还会预测一下相关数字的变化，提出这个项目的商业目标
- 功能需求描述：我们怎么去？即做哪些事情来达到目标，通常用功能列表和业务逻辑图来描述，如果有简单的Demo更好
- 非功能需求描述
- 资源评估：这是第二个重点
- 风险和对策
商业价值和资源评估本质上是在追求性价比，大家都希望花费最少的资源获得最大的商业价值
别灰心，少做就是多做
最爽就是“四两拨千斤”
做得少不如做得巧，内部（指偏技术）的大改动往往是外部（指偏商业）的小改动
尽可能多地放弃
需求管理：心急吃不了热豆腐
一个需求的生老病死
需要再加几个属性来管理需求的生命周期
| 需求属性 | 属性说明 |
|---|---|
| 需求状态 | 需求生命周期：待讨论、暂缓、拒绝、需求中、开发中、已完成、测试中、已发布 |
| 负责PD | 状态进入“需求中”后确定 |
| 开发工程师 | 状态进入“开发中”后确定 |
| 项目名称 | 辅助信息，在需求进入“开发中”时确定，用来确定该需求属于哪个项目 |
| 发布时间 | 辅助信息，在需求状态变为“已发布”时填写，用来查看某段时间发布的需求 |
| 备注 | 其他任何信息：被拒绝的理由、被暂缓的理由和重启条件、其他相关文档 |
需求管理的附加值
- 统计每个“提交人”的需求数量，如果再加上时间段的条件，就可以从一个侧面反映出某段时间每个人的工作情况
- 统计“提交信息”“发布时间”等信息，按月统计可以从需求数量的侧面看出产品发展是在增速还是在减速
- 统计每个“模块”的需求数量，可以看出用户对产品的哪些模块感兴趣
- 统计每个“分类”的需求数量，可以了解产品是在成长期还是成熟期
- 统计需求的“商业价值”和“性价比”变化，可以看出这个产品的发展空间还有多大
谈项目：项目的坎坷一生
生态系统中，云变成雨落入河流，河流会把水运送到各地。河流中，有乱石、有浅滩，处处潜藏了危险
从产品到项目
项目：只进行一次且包含多项互相关联的任务，并有绩效、时间、成本和范围限制的一项工作
产品是解决某个问题的东西，而项目是一个过程
做产品VS做项目
- 从生命周期的角度来看，“做产品”的生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。而“做项目”有特定的目标，所以生命周期较短，通常在项目开始以前就有明确的起始和结束时间，通过验收就表示项目生命周期结束了
- 从具体要做的事情来看，在“做产品”的过程中，会有更多的探索行为。而“做项目”在开始时就已经有明确的目标，更注重计划与控制
- 从产出物的角度来看，产品是可以批量生产，并且提供给大量用户使用的，所以产出物最好能相对通用，通常会首先考虑用有限的资源去满足更多的、能有更多回报的需求。而项目只进行一次，意味着每次需求都是定制的、个性化的，通常为了满足这些特定的需求，产出物也比较个性化
“做产品”和“做项目”也是分不开的，“做产品”的过程，正是通过做一个又一个项目实现的，但产品并不是项目的简单累加。在产品渐渐满足目标用户群体的通用需求后，我们需要细分市场，这时候产品可能升级为“产品线”，按不同的细分市场，推出不同的产品，最终通过合理地安排项目来实现产品的规划
产品经理VS项目经理
产品经理：靠想，做正确的事，思考其领导的产品是否符合市场的需求、是否能给公司带来利润
项目经理：靠做，把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标
产品经理是内部驱动，最重要的是判断力与创造力；项目经理是外部驱动，最重要的是执行力与控制力
为什么让产品经理管项目
如果让开发人员做项目经理，会倾向于简化项目、尽量少做、做自己熟悉的功能，使得项目顺利完成，并且Bug很少，但是做出来的东西也许商业价值不足、用户体验不好
如果让产品人员来做项目经理，会不断地给项目增加新的需求，导致项目总是无法按期完成，影响了团队的士气
一个产品经理可能想要增加非常多的功能和特征以满足获取到的用户需求，但是项目经理却想要尽可能小地控制工作范围，以保证项目在规定时间与预算内完成。好的产品经理和好的项目经理能在冲突中找到平衡。好的项目经理明白，一个项目真正的成功并不是看它是否在规定的时间和预算内完成，而是它是否达到了拟定的目标。好的产品经理则明白，如果项目被不断延期并且从未投入市场，又或者因为大大超过预算而被结束，那么所有的产品功能特征都会变得毫无意义
立项：一切从Kick Off开始
在项目里，Kick Off指的是项目的启动大会
团队组建
如果要降低团队组建的难度，作为项目经理可以从以下几点入手：
- 启动的项目经过产品会议并得到了大老板们的认可，项目所需的基本资源有保证
- 经常合作的都是相对固定的人，沟通比较顺畅
组织一个项目督导委员会很有必要
项目计划确定
确定沟通方法
项目晨会、项目日报、评审会、项目变更申请、发布预告及公告
Kick Off会议
会议内容：
- 项目背景
- 项目意义、目的与目标
- 需求、功能点概述
- 项目组织架构：项目成员互相认识
- 项目计划：项目的时间点与里程碑；各个时段需要的资源，即每个人要在各个阶段做什么事情
- 沟通方式
任何时候都要心中有“树”
项目TRQ三要素：项目时间Time、项目资源Resource、项目品质+数量Quality，通常在这几个目标中寻找平衡
需求开发：关键的青春期，又见需求
真的要写很多文档
BRD：商业需求文档，这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、盈利预测等，没有产品细节，主要作用是为了获得认可、争取资源
MRD：市场需求文档，产品进入实施阶段要写，MRD中要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，确定功能、非功能需求分哪几块，功能的优先级等内容，Feature List和业务逻辑图等都属于MRD文档，它也是从商业目标到技术实现的关键转化文档
PRD：产品需求文档，主要包含整体说明、用例文档、产品Demo等
总体说明：
- 修订历史：每次修订的日期、版本号、说明、作者
- 项目概述：项目背景、意义、目的、目标等
- 功能范围：画出业务逻辑图
- 用户范围
- 词汇表：专有词汇、术语、缩写
- 非功能需求：性能需求、数据监控需求等
- 其他说明
用例文档Use Case：
- 对PRD中所有的用例进行说明，给出用例的可视化表示，说明各个用例之间的关系（类图、用例图、状态图）
- 用例的正文，由一个个的用例组成
- 对单个用例的一些注释
FSD：功能详细说明，经常包含在PRD中
UML统一建模语言/标准建模语言：时序图、活动图、协作图
时序图：也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达多个对象之间的交互，比如多个页面之间、多个角色之间
活动图：比较接近流程图，描述各种动作如何引起系统变化，善于表达泳道较多、分支较多的情况
协作图：表达不同对象之间是如何互相影响的
时序图关注交互在时间上的步骤，协作图关注交互过程中各个对象间的关系
产品Demo
产品Demo，也被称作产品原型、演示版、Mockup
手绘、线框图、高保真原型图
需求活在项目中
作为重要监控点的需求评审、设计评审、测试评审
需求评审：是PRD评审、UC评审、Demo评审的统称
设计评审在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解以设计文档的形式向PD、测试人员解释说明
测试评审：俗称TC评审，在TC编写完成后，测试开始之前进行，由测试工程师把对需求的理解以TC的形式向PD、开发人员解释说明
再看需求的生老病死
项目开发、测试、发布
开发阶段的工作内容：概要设计/详细设计、设计评审、编码、单元测试
测试阶段的工作内容：TC编写、TC评审、冒烟测试、功能测试、性能测试等（在测试人员正式开始测试的同时，PD将组织一次产品的功能评审/产品演示会，进一步确保做出来的东西就是大家想要的，之后会进行UAT用户接受度测试和验收测试）
Bug眼中的项目
缺陷级别：一般大于等于三级的Bug被认为是严重的问题
Bug级别定义标准：
所属产品、项目
Bug名称
Bug描述
Bug状态流转过程：
发布阶段
发布阶段的工作内容：发布评审、预发布、发布、线上验证
以终为始，项目小结
发送“项目发布公告”、“项目小结”（平常要有记项目日报和项目周报的习惯）
常见的项目变化：
- 项目范围内需求的变更，需要制定流程进行控制
- 项目范围的扩展，搭车事件
- 紧急事件，一般是高层自上而下推动的
山寨级项目管理
文档只是手段
建立自己的文档规范
模板作用
- 让经常看同类文档的人提高效率
- 让写文档的新人可以尽快上手
- 让写作者不会漏考虑某些内容
多人协作与版本管理
流程也是手段
项目VS流程
项目只做一次，所以追求可行解即可；流程要反复做，所以要追求最优解
流程的本质目的
设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”
总结一些评审
商业评审：决定做不做
- 立项之前的产品会议
- Kick Off会议
- 功能评审
技术评审：决定怎么做
- 需求评审（PRD评审、UC评审、Demo评审）
- 设计评审
- 代码评审
- TC评审
- 发布评审
敏捷更是手段
从瀑布模型发展到敏捷方法
敏捷方法的特点：
- 有计划，更要“拥抱变化”
- 迭代周期内尽量不加任务，每次迭代其实也可以看作一个小的瀑布模型
- 集中工作，小步快跑（推崇每日站立晨会）
- 持续细化需求，强调测试
- 不断发布，尽早交付
谈团队：我的产品，我的团队
如果生态系统里只有水汽的循环，它仍然不会有生机。有了各种各样的动植物，才能让这个系统灵动起来
大产品、大设计、大团队
产品之大
“产品之大”可以从时间和空间两个角度来说
时间之大：产品生命周期
产品生命周期里的五种用户群体：
创新者：新鲜感强、消费能力高，但是忠诚度不高，需要新鲜的东西不断刺激。这批人都有Geek气质，乐于探索。产品刚上市，甚至未上市的时候，主流用户往往是创新者。任何产品投放市场的第一批外部用户，基本上都是竞争对手的产品经理和业内人士，千万不要被他们带到沟里
早期追随者：观念比较新，但是需求目的性很强，需要产品能够迅速解决其问题。他们可能很早就知道产品了，但不会盲目试用，而是先从其他渠道主动了解这个产品是干什么的，再反复验证，确认对自己有用以后才会尝试。这批人会比第一种人忠诚度高很多
- 应该牢牢抓住，将来发展成种子用户
- 产品上市后的早期，主流用户通常是早期追随者
- 这时候产品可以偏向这类“专家用户”，因为产品的进化主要体现在功能的不断创新上
- 在他们和主流用户之间，还存在一个鸿沟。因为早期采纳者有可能饥不择食，而主流用户却是实用主义者，很看重性价比（用户从早期采纳者扩展到主流用户时，产品策略需要做一些调整）
早期主流用户：是产品大规模产生商业价值的用户群，他们是典型的实用主义者，也是生活中最常见的一批人。对他们来说，即使偶尔听说过某新产品，但只要正在使用的老产品也能解决问题，就不会轻易更换。不过，他们心中还是对新产品存在期待，希望有机会试一下
- 这时候产品需要面向主流的“中间用户”和“新手”，所以产品需要尽量做得简单易用
- 这时候开始，产品渐渐稳定
- 也是真正获得商业回报的开始
晚期主流用户：这部分主流用户和早期主流用户的区别在心态上。早期主流用户对新产品有尝试的愿望，而晚期主流用户对新产品心存抵触。直到老产品已经渐渐地出现明显的劣势，他们才会很不情愿地使用新产品
这个阶段产品已经定型，用户对产品也比较了解，市场竞争也相当激烈，仅仅通过功能竞争来获得用户是不够的
这个阶段是典型的市场营销发力的时刻，需要通过强大的心理攻势来赢得晚期主流用户的认可
此时如果做好营销的创新，可以一招鲜吃遍天，并且这一阶段与研发阶段相比投入比较少、产出快、可预期，是收割商业回报的大好时期
微笑曲线：
落伍者：附加值比较低，可以在不违背道德标准的前提下偏重眼前利益
- 此时产品渐渐退出，市场也渐渐萎缩或转移，会有新产品成长起来
空间之大：商业、产品、技术
商业、产品、技术的三角支撑：
- 商业：在公司里主要由市场、销售、服务等部门来考虑，他们决定了产品定位、定价与促销、渠道政策等
- 产品：此处指狭义的产品，由产品部门（产品设计、用户体验、产品运营等部门）来考虑，他们决定了产品的功能完成度、交互流程、视觉表现等
- 技术：主要由开发、测试、运维等部门来考虑，他们决定了产品的稳定性、基本性能、Bug数量等特性
设计之大
产品的设计之大，体现在产品设计的多个层次上
- 产品战略层面上的设计：做不做、做什么
- 具体工作中的产品设计：做多少、怎么做
- 产品实施层面上的设计：谁来做、何时做
产品设计的五个层次
- 战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点
- 范围层：明确“做多少”
- 结构层：考虑产品的各个部分互相之间是什么关系
- 框架层：这一步才出现用户真正能看到的东西
- 表现层：包含了视觉设计和内容的优化
设计的“现实与浪漫”
设计的目标有三个层次：
- 本能水平设计：纯生理的视觉冲击
- 是基础，产品要有用，能满足用户的某种需求
- 行为水平设计：产品功能、用户与产品交互层面的设计
- 是保证，产品要能用、好用，顺利地解决用户的问题
- 反思水平设计：纯心理需求/人性的设计
- 是升华，是难以捉摸的“用得爽”
团队之大
常见的组织结构有职能型组织、项目型组织和矩阵型组织
职能型组织是把相同职责的人划分在一个部门里，有利于同类资源共享，互相学习提高
- 缺点是只对“上面”负责，没有人对真正的客户负责
- 头儿是部门经理
- 比较适合防守型业务
项目型组织是把各种职责的人组成一个个的项目组或产品线，团队目标一致，有利于快速推进项目
- 缺点是会浪费资源
- 头儿是项目经理或产品经理
- 适合进攻型业务
矩阵型组织是上述两种组织结构的融合
适合全攻全守
缺点是“双头领导”（产品经理和部门经理可以通过兼任解决矛盾吗？不能，产品经理主要管事，有成就感，需要有攻城拔寨的能力；部门经理主要管人，有权力，有防守与后勤的感觉。如果部门经理兼任产品经理，就会用权力来寻求成就感，或者在产品KPI的重压下，主动或被动地忽视团队能力的提升。解决办法是由用人的产品经理提供建议，养人的部门经理决定对员工的考核，同时培养每个人对事负责的态度）
游走于商业与技术之间
产品团队：
心思缜密的规划师
包括产品经理、产品规划师、产品设计师、需求分析师等
从概念设计到信息架构
概念设计的产出物是产品概念图，本质是要用图形化的方式表达清楚这个产品是什么，比较像业务逻辑图，但比业务逻辑图更抽象。制作概念图应该在需求采集之后，需求筛选之前，它和需求分析属于同阶段的任务。在各种用户需求之中，我们需要通过概念图来理清思路，找出到底应该“做什么”，并将这些打算做的需求整合为一个合理的系统
概念图描述的是整个产品的内外关系：
- 产品与外界的关系：把产品整体看作一个系统，描述它与上下级系统、并列系统的关系，可能的话，勾勒出产品所处的产业链结构
- 产品内部的关系：描述产品有多少模块、模块之间的关系如何，此处不用涉及数据流等细节，重点描述清楚不同的角色在系统里的身份
概念设计是为内部而做的，为了让团队之间进行更好的沟通，以便于大家对产品达成共识
信息架构是为外部用户而做的
激情四射的设计师
指的是用户体验部门UE的同事们，包括用户研究员、交互设计师、视觉设计师、前端工程师、文案设计师、信息架构师等
规划师更多的是“结构化思维”，让产品从无到有；设计师需要更多的“形象化表达”，让产品从有到优
“阴险狡诈”的运营师
运营就是从事前“预谋”，到事中按计划执行，再到事后拿到结果并为下一次运营积累经验的过程
事件营销：制造具有新闻价值的事件，并设法让这一事件传播，从而达到广告的效果
病毒营销：指利用公众的积极性和人际网络，让营销信息像病毒一样传播和扩散
在产品的日常运营工作中，我们可以对各种热点事件保持关注，并不断总结各种用户群体愿意传播的信息元素，在发现机会时一定要抓住
商业团队，冲锋陷阵
包括市场、销售、服务等
如果说销售人员可以增加新客户，让客户对某个产品第一次付钱，那么服务人员就是要稳住老客户，让客户对某个产品不断付钱
好产品需要市场化
好的产品需要市场化，不然，产品就成了实验室里的样品
定价与促销
销售与渠道
销售有两大模式：
- 直接销售：由企业直接向最终消费者进行推销
- 分销：需要借助渠道，分销的渠道分为代理和经销，代理赚取企业的佣金，代理方没有产品所有权和库存风险；经销赚取产品的差价，产品所有权发生转移
渠道战术讲究“推拉并重”，所谓“推”是集中力量做渠道工作，用高额利润去刺激渠道主动推销产品，快速抢占市场；而“拉”是通过媒体关系、广告、传播等手段启动市场，刺激消费者，促使渠道来找厂商
- “推”适合企业规模小、技术含量高、销售过程复杂的产品，“拉”则反之
- 一般新产品主要靠“推”，老产品主要靠“拉”
另一种产品版本细分策略
产品版本细分有两类：
- 一种是做功能区分，分别应对每一个细分市场
- 另一种是为了促进销售，利用消费者心理，纯策略性地做出“炮灰”版本，这类产品版本本质上是为产品的市场化服务的
- 一种在原有版本的基础上添加一些“鸡肋”功能，做一个价格高出很多的“高价炮灰”
- 另一种是删掉核心功能做一个价格稍低的“低价炮灰”
开阔视界的水平营销
纵向营销是进化，其特点是渐变；水平营销是革命，其特点是突变，水平营销是一种创新思维的方法
我们还能做什么
产品部门一定是先确定目标用户再设计产品，市场销售等商业部门往往是先拿到产品，再考虑主打哪些市场与用户，他们并不在意产品部门原先定义的目标用户是怎样的，只会去寻找最容易的突破口。所以，产品与市场两边的配合很重要，需要互相调整来彼此适应
算出来的服务策略
服务部门是为昨天的利润工作，给已经购买产品的客户提供承诺的价值；销售部门是为今天的利润工作，把产品变成利润，争取更多的客户；开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖；研究部门是为后天的利润工作，了解趋势、发展科技，保证产品永远处于领先位置
维护一个老客户的成本大约是开发一个新客户成本的四分之一
技术团队，坚强后盾
技术团队：
容易被遗忘的角落
支撑团队：包括老板、法务、财务、行政等
让老板做问答题、让老板做选择题、让老板做判断题
大家好才是真的好
所谓团队文化
无授权领导
管理VS领导
- 管理更像科学，领导更像艺术
- 管理靠的是权力，领导靠的是魅力
- 管理者强调稳定，领导者喜欢冒险
- 管理者依法治人，领导者以德服人
- 管理的对象是行为，领导的对象是思维
- 管理管正确地做事，领导管做正确的事
- 管理是一步一个脚印，领导是不走寻常路
- 管理者注重短期目标，领导者注重长期发展
- 管理者是职业经理人，领导者是企业家和创业者
- 管理是汽车的制动系统，领导是汽车的驱动系统
- 管理是告诉团队怎么做，领导是告诉团队为什么做
- 管理对人的影响由外而内，领导给人的力量由内而外
- 管理让团队能完成这些事，领导让团队喜欢做这些事
产品经理应该拥有管理职位吗
优势：
- 管理岗位利于拥有话语权
- 管理岗位利于获取信息
- 管理岗位利于争取资源
劣势：
- 管理岗位有很多行政工作
- 管理岗位会让人脱离群众
如何让团队更开心
- 大中之小不如小中之大（比如送礼物）
- 有用的不如无用的（最好的礼物应该是吃不掉、用不掉、送不掉也扔不掉的东西）
- 需要的不如想要的
- 有选择不如无选择（否则会让人有一种“放弃了另外一种选择”的感觉）
- 小奖不如没奖（会让做事的人开始衡量投入产出的物质性价比，惩罚也是如此，小惩罚会让人心安理得）
- 晚说不如早说（让人有期待感）
- 一次送不如两次送（比如送两件礼物；好消息要分两次说，坏消息要一起说，大的好消息与小的坏消息一起说，小的好消息与大的坏消息分开说）
- 公开不如不公开（比如工资）
- 涨工资不如发奖金（从公司角度来说）
跟着我，有肉吃
谈战略：别让灵魂跟不上脚步
在动植物的帮助下，水汽通过云、雨、河流形成了循环，可是，它们的原动力其实是阳光，因为“万物生长靠太阳”
触及产品的灵魂：战略
产品经理的三层境界：
- 产品帮助我们
- 产品与我们互相帮助、共同提高
- 我们帮助产品
以价值观为根基
产品的灵魂或者企业的灵魂是什么，探到最深处，是由价值观决定的，而企业的价值观就是：企业决策者对企业性质、目标、经营方式的取向做出的选择，是员工所接受的共同观念，是长期积淀的产物
有了“应该做什么、不做什么”的根本指引，就有了一切讨论的根基
战略是怎么炼成的
有价值观作为企业做事的最基本指导原则之后，我们需要思考公司或产品的使命和愿景
- 使命是指“我们为什么而存在，要做什么事情”，它必须是一个持久的事实
- 愿景是说“我们希望成为什么”，它需要由组织内部成员来制定，借由团队讨论，获得组织一致的共识，并形成大家愿意全力以赴的未来方向
这些是我们做事的驱动力
在明确了上述概念之后，一家企业才可能清晰地确定公司战略。否则，徒有战略却没有价值观、使命和愿景的公司，是无法将战略落实到位的
之后，企业需要制定相应的流程规范、组织结构、IT系统、激励机制等保证战略的实施
有了公司战略之后，进一步就是产品战略
培养大局观
帕累托改进：在总资源不变的情况下，如果对某种资源配置状态进行调整，使一些人的境况得到改善，而其他人的状况至少不变坏，符合这一性质的调整被称为帕累托改进
绝大多数现实工作中的情形是“有得必有失”，如果你发现做一个改变只有好处没有坏处，那很可能是你站得低看得近，或者说你考虑到的“全部”只是更大系统里的一部分，“坏处”会在其他部分体现出来。这时候你应该找一个站得高看得远的人讨论，会比较容易发现问题
可行性分析三部曲
制订产品战略，在项目管理里叫做“可行性分析”，属于产品设计层次的“战略层”，在公司层面可能叫“战略规划”
我们在哪儿
从市场扫描开始：整个行业如何
市场扫描的过程一般也是新产品的“预研”阶段
常用的市场扫描方法：PEST分析，分别分析产品在政治法律环境、经济人口环境、社会文化环境、技术环境四个方面所面临的机会和威胁
PEST分析的细分因素：
我们只有通过宏观层面的PEST分析，发现涉足某个行业是可行的，才可以继续下去
真实的竞争对手分析：竞争对手如何
小的成功靠朋友，大的成功靠对手
竞争对手分析也叫竞品分析，一般以经典的$APPEALS分析法作为指导方针，来开展竞争对手分析：
- $：产品价格
- A：可获得性
- P：包装
- P：性能
- E：易用性
- A：保证程度
- L：生命周期成本
- S：社会接受程度
深刻的自我剖析：自己情况如何
常用方法是SWOT分析：对企业的优势、劣势、机会和威胁进行分析
我们去哪儿
对应问题：细分市场是什么？目标用户是谁？我们要解决他们的什么问题、满足他们的什么需求？
宏观上的用户需求：指某一个目标用户群体面临的问题是什么
通过对某一个目标用户群体进行划分，找到有机会切入的小市场
ERP：企业资源计划，指建立在信息技术基础上，以系统化的管理思想为企业决策层及员工提供决策运行手段的管理平台
- HRM：人力资源管理软件
- SCM：供应链管理软件
- OA：办公自动化软件
- CRM：客户关系管理软件
SEO：搜索引擎优化，为近年来较为流行的网络营销方式，主要目的是增加特定关键字的曝光率以增加网站的能见度，进而增加销售的机会
我们怎么去
对应问题：用什么产品满足需求？产品的核心竞争力是什么？
解决我们怎么去的问题，浓缩成两个字就是：策略，各种正确的策略保证了我们是在“做正确的事”
低头看路，抬头看天
抬头看天指的是：里程碑、检查点
我们急需靠谱的会议，大会决定小事，小会决定大事
KPI
KPI：关键业绩指标，它是在分解企业战略目标的基础上，分析各子目标与主要业务的联系之后提出的，KPI是企业目标的具体表现
SMART原则：
- S代表具体，指绩效考核要切中特定的工作指标，不能笼统
- M代表可度量，指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或信息是可以获得的
- A代表可实现，指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标
- R代表现实性，指绩效指标是实实在在的，可以证明和观察
- T代表有时限，完成绩效指标有特定的期限
你再怎么去客观地设计绩效体系，这个体系都无法真正地与你追求的目标画上等号，在这种情况下绩效体系越量化，越容易将团队成员带入追求绩效的数字游戏上，而忽视了真正的目标
远视者把目的当手段，近视者把手段当目的
KPI其实是在多个目标间做权衡
专业产品是做给专业用户的，更倾向于“让人适应产品”，比如各种乐器；设计给新手用的产品必须是产品适应用户
达摩克利斯之剑：用来表示时刻存在的危险
谈修养：产品经理的自我修养
一个生态系统，有了云和雨、河流、动植物、太阳之后，看似完整了，可我们忽略了它们的根基，那就是大地
爱生活让我们充满动力，有理想让我们目标明确，会思考让我们方法得当，能沟通让我们团结前进
爱生活，才会爱产品
UGC：用户产生内容
有理想，就不会变咸鱼
会思考，活到老学到老
“教”是为了“不教”，是为了激发其自我反思、自我管理的能力。当开启一个人的心智之后，他就可以自我发展，成为一个独立的人，我们所经历的教育，似乎缺少了“引出”的过程，而过多地赋予了“雕琢”的感觉。学校教育为了特定的目的，总想把一个人从石头雕刻成一件有用的工具
学校里没教的东西：
- 教知识不教思维
- 教解题不教选题（“选择”恰恰是产品经理常做的事，工作中追求“性价比”而不是“完美”）
- 教努力不教取巧
- 只教“受教”不教“施教”
能沟通，在什么山头唱什么歌
其实产品经理很大程度上就是销售，而且比销售还要难，销售卖的是已经有的东西，而产品经理卖的是自己的想法；销售只要把产品卖给客户，而产品经理要把想法卖给老板、同事、客户等：
- 第一卖：老板（需求、项目多得是，凭什么给你资源）
- 第二卖：其他PD（大家都很有想法，凭什么听你的）
- 第三卖：开发与测试（这样做很麻烦，值得吗）
- 第四卖：合作公司（凭什么帮你，给个双赢的理由）
- 第五卖：市场与销售（让我们振奋起来的产品，做起来才有动力）
- 第六卖：服务、财务、法务（我们一直在擦屁股）
- 第七卖：客户（搞清楚，钱都是我付的）
沟通理念：
- 理论上严格意义的“充分沟通”是不存在的
- 沟通不是为了说服，而是为了更好地认识世界
职场中的点对点沟通：
IM
电话
面谈
Email
职场中的群体沟通：
- IM群
- 电话会议或视频会议
- 线下会议
- 群发邮件
产品经理主义
解决问题的通用思路：
- 为了什么？
- 做什么事、解决什么人的什么问题？
- 何时做？谁来做？
- 效果如何？
甘特图：又叫横道图、条状图，它可以用图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间
人人都是产品经理，不是说团队里每个人都应该做产品经理的事情，而是每个人应该用产品经理式的态度和方法来做好自己相应的工作（在生活中也能用到产品经理式的态度和方法）
一个人真正成熟的标志之一，就是心中可以容纳互相矛盾的观点而无碍行事
产品经理的主要职责：
- 市场调研（最终会转化成商业机会、产品战略或商业需求文档BRD）
- 产品定义及设计
- 项目管理
- 产品宣介
- 产品市场推广
- 产品生命周期管理（概念化、发布、成熟、退出市场）
产品经理的核心技能：
- 沟通能力
- 无授权领导能力
- 学习能力
- 商业敏感度
- 热爱产品
- 注重细节，追求完美
- 日常产品管理能力