产品是什么:
<1 产品是一组将输入转化为输出的相互关联或相互作用的活动”的结果，即“过程”
的结果。
<2 在经济领域中，通常也可理解为组织制造的任何制品或制品的组合。产品的
狭义概念：被生产出的物品；产品的广义概念：可以满足人们需求的载体。
<3 产品就是用来解决某个问题的东西
全世界的第一位产品经理: 20世纪二三十年代 美国宝洁公司-麦古利
第一章
行业的进化典型的传统行业互联网,软件行业
行业形态成熟行业新兴行业
产品形态与成本结构实物虚拟物品
生命周期几年几个月
盈利模式单一卖产品赚钱多元盈利
用户心态花钱买免费用
在产品经理的工作中通常表现为以下几种形式：
第一，信息不足以决策。
第二，时间不足以安排周密的计划。
第三，人员不足以支持工作强度和难度。
第四，资金不足以自由调配。
这一段很有趣
<1 官方说法 需要全面负责产品的整体实现过程。
私下交流
因为产品经理这个职位比较新，所以具体要做哪些事情没有开发人员、测试人
员明确，于是，干多干少全凭自己决定。
事实真相
具体的职责不清楚，就意味着事情多起来没个谱，任何与产品有关的事情都可
以是你的，总是闲不下来。
<2 官方说法 需要能承受压力、自我调节、自我激励，综合素质要求高。
私下交流
看到这条就怕了吧，产品经理做的很多事情都是更看重质量而不是数量，所以
很难用工作量和工作时间来衡量绩效，经常好几天没什么产出也很正常。这时
候你可千万别崩溃了。
事实真相
可是，产品的任何方面、团队里其他人做的任何事情如果出了问题，产品经理
都很可能要背黑锅。
<3 官方说法 对市场发展趋势有敏锐的洞察力，辅助决策公司战略方向。
私下交流 你真的可以决定公司产品长什么样。
事实真相 产品当然是老板生的，你也就是给它化个妆。
<4 官方说法 需要很强的沟通能力，出色的团队合作精神。
私下交流
有很多机会展示你的想法，如果有兴趣的话，可以利用工作机会认识公司里几
乎每一个人。
事实真相
你总是某个产品的信息交换中心，也是各方共同挤压的对象，哪边都不得罪真
是一门艺术。
<5 官方说法 关注业界动态，对互联网产品兴趣浓厚。
私下交流
因为你要了解行业的最新资讯，做竞争对手分析，所以需要不断去各种网站注
册、试用，老板无法判断你是否在冲浪或瞎逛，全凭自觉。
事实真相
这样时间久了是很痛苦的，整天被那么多垃圾产品恶心，自己做的产品看太多
了更觉得恶心……
第二章
用户研究，需求采集的过程，都会有如下几步：
明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
定性
|
用户访谈|可用性测试
|
说----------------------------------做
|
调查问卷|数据分析
|
定量
<1 定性的说 用户访谈:
第一，“说”和“做”不一致的问题。
第二，样本少，以偏概全的问题。
第三，用户过于强势，把我们往沟里带。
第四，我们过于强势，把用户往沟里带。
《软件观念革命：交互设计精髓》书中说道
► 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准
备好问题清单，但清单只起一个引导作用，并不用照着读。
► 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用
户为什么这么做。
► 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、
片面。
► 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。
► 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。
<2 定量的说 调查问卷:
问卷调查一般不要超过10分钟! 太多的量,用户看到就不想继续进行下去了!
调查问卷的客观性、多份问卷之间的独立性，可以有效避免上述问题，但其容易
出现的问题在于：
第一，样本的偏差，即样本与想了解的目标用户群体出现偏差。
第二，样本过少的问题。
第三，问卷内容的细节问题。
<3 定性地做 可用性测试:
和用户访谈、调查问卷一样，可用性测试也有其特别需要注意的问题。
第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题
也于事无补了。
第二，总觉得可用性测试很专业，所以干脆不做。
第三，明确是测试产品，而不是测试用户。
第四，测试过程中，组织者该做的和不该做的
<4 定量地做：数据分析
数据分析的常见问题
第一，过于学术，沉迷于“科学研究”。
第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。
第三，平时不烧香，临时抱佛脚。
单项需求卡片的理念： 产品的需求工作不只是需求分析人员的事，而是涉及63页图
产品的每个干系人的义务，至少得参与“采集”的过程.
需求编号（可由需求人员填写） 需求类型（可由需求人员填写）
包含“采集时刻 + 采集者”信息 功能需求、非功能需求等
来源（ Who） （重要信息，方便追根溯源）
产生需求的用户：最好有该用户的联系方式等信息
用户背景资料：受教育程度、岗位经验，以及其他与本单项需求相关经验
场景（ Where、 When） （重要信息，用来理解需求发生的场景）
产生该需求的特定的时间、地理、环境等
描述（ What） （最重要的信息）
尽量用（主语+谓语+宾语）的语法结构，不要加入主观的修饰语句
原因（ Why） （需求人员要保持怀疑的心，很多时候理由是假想出来的）
为什么会有这样的需求，以及采集者的解释
验收标准（ How） 需求重要性权重（ How much）：
（如何确认这个需求被满足了）
1. 尽量用量化的语言
2. 无法量化的举例解释
满足后（“ 1：一般”到“ 5：非常高兴”）
未实现（“ 1：略感遗憾”到“ 5：非常懊恼”）
需求生命特征（ When） 需求关联（ Which）
1. 需求的紧急度
2. 时间持续性
1. 人：和此需求关联的任何人
2. 事：和此需求关联的用户业务与其他需求
3. 物：和此需求关联的用户系统、设备，以及其
他产品等
参考材料 竞争者对比
在需求采集活动中的输入材料，只要引用
一下，能找到即可
按照“ 1 分：差”到“ 10 分：好”进行评估：
1. 竞争者对该需求的满足方式
2. 用户、客户对竞争者及公司在该需求上的评价
AB 测试。基于大用户量比较合适，比如有一个按钮不知道是放页面的左边好，还
是右边好，而我们有 10 万用户，那就先随机挑选少量的用户发布这个按钮， 1000 人放
左边，另外 1000 人放右边，然后过一段时间分析结果，再决定剩下的 98%用户该怎么
办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同
学羡慕不已。
注意: 听用户的但不要照着做!!!
注意: 听用户的但不要照着做!!!
注意: 听用户的但不要照着做!!!
重要事情说三遍
明确我们存在的价值: 用户跟福特要一匹更快的马，福特却给了用户一辆车。
一个是用户需求，一个是产品需求。而这中间的转化过程，就是这节的主题——需求分析。
用户需求 VS.产品需求
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们存在的价值。
满足需求的三种方式 : 改变现状 降低理想 转移需求
确定需求的基本属性
需求属性 属性说明
编号:需求的顺序号，唯一性标识
提交人:需求的录入 PD，负责解释需求
提交时间: 需求的录入时间，辅助信息
模块:根据产品的模块划分(一般来说，根据人类记忆的特点，产品有 5±2 个模块比较合理，如果超过7 个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。)
名称:用简洁的短语描述需求
描述;需求描述：无歧义、完整性、一致性、可测试等
提出者:即需求的原始提出者，有疑惑时便于追溯
提出时间: 原始需求的获得时间，辅助信息(原始需求的提出时间，区别于提交时间，这是个辅助信息。)
Bug:编号 将一些 Bug 视为需求，统一管理
需求的种类:
分类： 可以分为“新增功能、功能改进、体验提升、 Bug 修复、内部需求”等。
层次： 把需求分成“基础、扩展（期望需求）、增值（兴奋需求） ” 三层。
我自己经常从“雪中送炭”还是“锦上添花”的角度去理解：雪中送炭是基本功能，对用户很有用，产品缺了这个功能根本跑不起来，比如 E-mail
系统里的“收发邮件”；锦上添花的功能是指非必须的，用户有时用得到，有的话会给用户的使用带来方便，比如在发 E-mail 填写收件人的时候，系统根据你输入的内容自
动提示你曾经发送过邮件的联系人
需求的商业价值:
需求属性 属性说明
重要性:重要程度，辅助确定商业价值
紧急度:紧急程度，辅助确定商业价值
持续时间: 持续时间，辅助确定商业价值
商业价值: 商业优先级，不考虑实现难度，群体决策
需求的实现难度:
工作量:
开发量:开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师
需求的性价比:绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。
性价比 = 商业价值÷实现难度（简化为开发量）“不要试图满足所有用户”， 一切皆看性价比。
公司部门的划分
<1 按产品线划分的团队对产品本身是有利的，产品经理权力更大，可以按照自己的想法做，资源有保证，产品规划不容易被动改变。
<2 按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。
资源战争两种组织结构，给我“一攻一守”的感觉，鲶鱼效应使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。
<鲶鱼效应>即采取一种手段或措施，刺激一些企业活跃起来投入到市场中积极参与竞争，从而激活市场中的同行业企业。其实质是一种负向激励，是激活员工队伍之奥秘。
<1 准备出发：把需求打个包
做项目，终极目标就是：多快好省 即范围大、时间短、品质高、资源省。
第一，“ 需求打包”最好打包类似的功能点。
第二， 需求依赖，功能互相之间有依赖关系。功能与人力资源之间的依赖关系。
第三， 需求的粒度大小问题。经验是，在需求列表里出现的任意一行，工作量最好不要超过“ 5 人天”。
<2 战场：产品会议
<3 武器：商业需求文档
BRD： Business Requirement Document，商业需求文档。
MRD： Market Requirement Document，市场需求文档。
PRD： Product Requirements Document，产品需求文档。
商业需求文档包含:
项目背景
商业价值
功能需求描述
非功能需求描述
资源评估
风险和对策
少做就是多做:情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。越来越觉得当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的选择：不做！现在我们可以自我安慰了——少做就是多做！
四两拨千斤:电扇吹空盒子故事
尽可能多地放弃
