《人人都是产品经理》的读书笔记Word文件下载.docx
《《人人都是产品经理》的读书笔记Word文件下载.docx》由会员分享，可在线阅读，更多相关《《人人都是产品经理》的读书笔记Word文件下载.docx（40页珍藏版）》请在冰豆网上搜索。
其他（比如对行业的熟悉）会次要。
对于工作几年的人，不管以前是做什么的，都可以转行做产品经理。
建议先在本质工作上找到产品有关的事情做些尝试，并且考虑从产品经理周边的职位做起。
原来做开发的,利用参与需求评审的机会，多思考，对需求提出合理建议。
以后做产品经理，可以从“需求分析师”切入。
1.4一个产品经理的-1到3岁
作者本身学生物
入行头半年，打杂：
不负责产品的任何模块，写框架已被别人搭好了的需求文档，但他好学，主动熟悉工作中的技能。
入行半年后，学习“怎么做”：
以productdesigner的身份负责网店版的某些模块，决定某个功能怎么做，比如写需求文档，配合做demo，跟进开发、测试、发布的过程。
但是很看重自己负责的模块，缺乏整个产品层面的权衡认识。
入行一年，开始问“做不做，做多少”：
在完全掌控需求采集、分析、筛选的过程中学会权衡取舍，砍功能也下得了手。
入行两年，项目与团队：
新项目企业邮局，学习到除产品需求以外的东西，比如项目管理、流畅、敏捷方法。
体验到操心的感觉，从接受别人的会议邀请，到给别人发会议邀请；
从有事才去找人帮忙，到尽量去了解周边团队在做啥，并施加影响；
从一个人做事，到做好自己本职工作，其他交给团队，再到主动定规范，把工作分出去。
入行三年小结，战略与修养：
参与产品的可行性研究；
思考产品经理的基本修养：
爱生活，有理想，会思考，能沟通；
立志做老师，完成“三个一工程”：
一个网站，一门课程，一本图书
Tips:
公司想做的产品很多，要从中挑出值得实施的，果断放弃很重要，放弃的原则与价值观、战略有关
2.一个需求的奋斗史
需求收集方法：
数据分析；
调查问卷；
访谈
需求采集过程：
明确目标→选择采集方法→制定采集计划→执行采集→资料整理→进入下一个需求分析阶段
相比较“接到一个任务，然后把它完成”，对于产品经理，更重要的是“发现一个问题，然后设法把其转化为一个任务来解决”。
2.1从用户中来到用户中去
2.1.1用户是需求之源
人的需求，根据马斯洛的需求层次理论，可划分为五个层次，由低到高，分别是：
生理需求、安全需求、社交需求、尊重需求、自我实现需求。
产生需求的原因是：
生活中存在“理想与现实的差距”，人类很自然地产生“减少甚至消除这个差距”的愿望。
通过研究需求，可以增强对用户的理解。
理解用户，是产品经理的重要素质之一。
小明要电钻->
要在墙上打洞->
要挂上画->
屋子太空旷，不温馨=>
安全需求和社交需求
用户与客户的区别：
用户，也叫终端用户，是使用产品的人；
客户是购买产品的人。
相对于客户的需求，我们更重视您的用户的需求=>
用户是需求之源。
UCD，以用户为中心的设计
UBD，以老板为中心的设计，适用于没太多精力做用户研究、公司老板最了解用户且能抓住商机的创业小团队。
试图满足所有用户的需求是一个灾难，会让产品变成一个臃肿不堪、谁都不满意的四不像。
我们应该优先照顾其中一部分用户的需求。
这种优先要考虑到产品的商业目标。
例如：
对于已经成熟且拥有市场霸主地位的产品，比如qq，应关注核心用户的需求；
对于刚刚起步的产品，先满足大量的一般用户的需求。
2.1.2你真的了解用户么？
许多用户对所有产品了解甚少。
先描述自己，创建人物角色persona是一种快速描述用户的方法。
persona的内容包括：
职业、预算、爱好、性格、行业信息（过去经历、当前状态、未来计划、痛处）、计算机和互联网使用情况、用户目标、商业目标
用户研究方法可用一张二维图表示：
横向是用户的说和做。
“眼见为实耳听为虚”，看到用户怎么做比听他们怎么说更真实，但只了解怎么做是不知道背后原因的。
纵向是定性与定量。
定性研究偏向于找出原因，定量研究偏向于证实。
做用户调查的目标是：
坚决杜绝“经组织决定，用户需要一个xx功能”，要是实在在地把用户当做需求之源。
2.2需求采集的大生产运动
要根据资源多少采用合适的用户研究方法。
若资源少，查二手资料后和同事讨论，猜测用户怎么想怎么做。
需求采集有以下步骤：
明确目标->
选择采集方法->
制定采集计划->
执行采集->
资料整理->
下一步的需求分析
2.2.1定性地说：
用户访谈
用户访谈的常见问题：
1.说与做不一致。
索尼做用户调查，发现用户更喜欢黄色游戏机。
当索尼让他们随意挑选游戏机时，更多用户挑的是黑色游戏机。
对策：
让用户可以和产品交互的情况下访谈；
要区分用户说的事实与观点。
“我做了啥，遇到啥问题”这种事实比“我认为”这种观点可信度高。
（边说边做）
2.样本少，以偏概全
只找本市的用户，优先拨打留了手机的用户，愿意来公司做访谈的用户
在访谈报告中注明可能引起偏差的因素；
增量访谈，即先少量调查，若结论有变，再加大样本量
3.用户过于强势，把我们往沟里带
漫无目的地侃
；
牢记访谈目的，若话题不对，赶紧往正道上掰
4.我们过于强势，把用户往沟里带
在访谈时指出用户哪里理解不对，说自己产品多么好
牢记访谈目的，管好自己的嘴
避免固定问题；
更关注为什么，而不是怎么做；
听用户说但不要照着做；
避免讨论技术；
鼓励讲故事；
避免诱导性问题（如果有xx功能，你会使用么？
）
记一次用户大会的提纲（用户大会是邀请用户到某一集中地点开会）
明确目的：
比如产品卖点确认，需求收集，用户体验改进。
这样在争取开用户大会的资源时有说服力
资源确定：
时间、地点、人物、材料、备用方案
现场执行：
辅助工作、主流程
结束以后：
资料整理、运营宣传
2.2.2定量地说：
调查问卷
调查问卷可以挖掘出用户中大多数的沉默与骑墙一派，并且他们还是典型用户。
调查问卷与用户访谈的区别：
前者是封闭式问题，后者是开放式问题
作答时间不超过10分钟；
问题顺序：
简单问题->
需要思考的、敏感的问题->
被访者个人信息
调查问卷的常见问题：
1.样本偏差
尽可能覆盖目标群体中的各种类型的用户，比如性别、年龄、行业、收入，并保证这个比例接近全体比例；
若无法做到样本合理性，在调查报告中要注明潜在的筛选条件。
2.样本过少
若样本个数少于100，列出人数，而不是百分比
3.问卷内容的细节问题
问题表述应无引导性，问“你是否喜欢某个产品”而不是“你喜欢某个产品吗”；
准备几种形式的问卷，减少答案的顺序偏差；
先小规模试答，反馈修改后再大面积投放。
记这本书的实际问卷
问卷目的：
收集读者反馈
样本对象：
本书读者、博客读者、对产品经理感兴趣的人
调查渠道：
网站、博客
时间计划：
收集3个月
问卷内容：
2.2.3定性地做：
可用性测试
步骤：
招募测试用户（尽可能代表真实用户，若主要用户是新手，则应选择对产品不熟悉的用户）->
准备测试任务（典型任务）->
测试过程，组织者应观察并记录->
询问用户的主观看法->
研究分析
可用性测试的常见问题：
1.做得太晚，发现问题也于事无补了。
在产品的各个阶段都做可用性测试。
对于无任何成型的产品，拿竞争对手的产品给用户做；
对于只有纸面原型的产品，拿手绘的产品给用户做。
2.觉得可用性测试太麻烦，干脆不做
只做一个用户，并简化步骤，也比不做好
3.明确是测试产品，而不是测试用户
不要用“可用性测试”的术语，而是说“来试用我们的新产品，提点意见”，减轻用户压力
4.测试过程中，组织者该做和不该做的
该做的：
告诉用户持续时间，做哪些事情；
让用户在使用产品时说出自己的思考过程；
送个小礼品
不该做的：
引导与暗示
产品改版的一次冒险
可用性测试做得太晚，想想后怕
对于改版，要和平演变，而不是暴力革命，要让用户逐渐适应：
从部分分级页面改起；
新旧版本并存；
小面积实验；
傍上用户已经习惯的风格
2.2.4定量地做：
数据分析
关键的是对数据的解读，数据分析只能发现现象，并不能了解原因。
所以数据分析常伴随用户访谈。
数据分析的常见问题：
1.过于学术，沉迷于“科学研究”
重视综合性价比，不需要“显著性检验”，要的是对数据的敏感。
2.虽然数据不会主动骗人，但我们经常无意或有意地误读数据
对于无意误读（例如不能用平均值来衡量收入水平），学习统计学只是；
对于主动误读（在提取数据前就有结论了），保持中立态度
3.平时不烧香，临时抱佛脚
在产品设计时就把数据分析的需求加进去，比如统计每个按钮的点击次数。
日志分析的商业价值
分析登陆次数
在对产品熟悉的基础上，做方向性假设。
这里假设有方法使某类用户更多地登录
->
提取相应数据并分析,得到一些现象，最好是之前没发现的现象。
这里做一张二维图，横轴时间，纵轴活跃情况。
趋势可分为四个阶段。
尝试解释。
这里发现可分为两类登录：
经销商登录和用户登录
用户调研修正解释。
这里是电话调研+登门拜访，发现有两个入口的登录。
指导产品的发展方向。
这里的商业价值在于：
1）考核每个经销商下面的用户活跃度，来让他们更好地服务用户；
2）有实际意义的是用户入口的登录，因此产品优化的重点应在用户入口
2.2.5需求采集人人有责
从用户那里直接得到的需求，是一手需求；
老板或销售人员的需求，是二手需求。
在新产品诞生前，没有用户、运营、销售时，要主动地去潜在的目标用户那里采集需求；
产品运行一段时间后，用户和相关工作人员都有了，与用户的直接接触变少，但会收到中间的工作人员反馈的需求和用户提的需求。
销售人员有时只重视眼前利益，提的需求不一定好，一手需求很重要。
二手需求的理解偏差可以用单项需求卡片这个工具来弥补。
需求分析卡片的理念是：
产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程。
一个需求分析卡片，至少得有需求编号、需求描述、来源（产生需求的用户）、场景（产生该需求的特定时间、地理、环境）
尽可能多地采集需求的一些方法：
现场调查，和客户一起工作；
AB测试，小规模地测试A和B的情况；
日记研究；
卡片分类法，把需求写在便利贴上，观察用户怎么给产品划分模块；
粉丝用户主动提需求
2.3听用户的但不要照着做
对于用户提的解决方案仅仅站在自己立场上考虑，对于用户提的存在明显逻辑矛盾的需求，要谨慎考虑。
2.3.1明确我们存在的价值
需求分析要做的是把用户需求转化为产品需求。
用户向福特要一匹快马，福特给了一辆车
对于“小明要电钻->
安全需求和社交需求”，我们可以给电钻+油画，也可以油画+强力胶，或者摆个书架，可能更省钱也更温馨。
用户需求VS产品需求
用户需求：
用户自以为的需求，并且经常表达为用户的解决方案
产品需求：
经过我们分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：
从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
需求分析是“首先：
树叶-树枝-树干，其次：
树干-树枝-树叶”的分析过程，既不能漏掉提炼用户需求的过程，透过需求看本质，也要让树干分解掉，好让执行人员知道要做什么东西。
这是短期利益与长期利益的权衡，只满足用户需求是短期利益，但为了长期需求，我们要找到用户的真实需求。
满足需求的三种方式
改变现状：
开发某个产品，最常用也最笨的方法。
降低理想：
“丑话说在前头”
转移需求：
寻找更强烈的需求展现给用户，让他不纠结于原来的需求。
电梯不够用
增加电梯个数
告诉用户，隔壁那个楼等的时间更长
鼓励用户爬楼梯锻炼身体；
电梯门口装镜子让等的人搔首弄姿不至于无聊
也谈创造需求
基于用户、产品、市场的充分理解的突发奇想有的会得到用户认可，但更多的是天马行空。
作为新人，先做用户提出的需求，而不要胡乱分析用户需求。
2.3.2给需求做一次DNA检测
需求DNA检测过程：
需求转化->
确定基本属性->
分析商业价值->
初评实现难度->
计算性价比
需求转化
采集单项需求卡片->
头脑风暴->
每人分一块，转化为产品需求->
整理记录成产品需求列表
用户需求与产品需求是多对多的关系
过滤掉不靠谱的用户需求
对于用户需求“删除之前需要确认”，产品需求可能是“数据回收站：
删除的数据进入回收站。
若误删，可以去回收站找回数据。
”
确定需求的基本属性
这些基本属性包括：
编号、提交人（针对产品需求）、提交时间、模块（5+-2）、名称（什么功能）、描述（功能具体什么意思）、提出者（针对用户需求）、提出时间、Bug编号
需求种类知多少
需求按分类分，可分为：
新增功能、功能改进、体验提升、Bug修复、内部需求（比如内部数据分析）
产品功能需求+产品非功能需求=产品需求
产品需求+市场需求+开发需求+测试需求+服务需求+...=产品包需求
需求按层次分，可分为：
基础、扩展（期望需求）、增值（兴奋需求）
雪中送炭要好于锦上添花
分析需求的商业价值
商业价值可用重要性、紧急性、持续时间来衡量。
这是需求列表中的最核心部分，甚至在列表中再增加一条“商业价值描述”，即卖点，说明对用户和公司会提供什么价值
对于商业价值，要在需求讨论会产品团队集体讨论，叫上干系人，比如销售、服务等
初评需求的实现难度
把技术人员代表拉进来参加讨论会，甚至让他们先自行讨论后再决定。
不考虑硬件成本，再加上在产品、开发、测试、服务中开发资源是瓶颈，开发量成为实现难度的指标。
由于需求未定，先做允许误差大的初评，在项目启动后再做更精确的评估。
性价比
性价比=商业价值/实现难度
在实际中，多跟工程师接触，实现难度会定得偏高，多跟销售运营的人开会，商业价值会定得偏高。
对于Firefox的网页显示问题，虽然很好解决，但是用的人极少，所以商业价值极低，导致这个需求性价比低。
2.4活下来的永远是少数
需求筛选的过程：
需求打包->
BRD制作->
产品会议->
..->
立项
2.4.1永远忘不掉的那场战争
以前没有战争的原因：
以前公司按产品线划分部门，对于某产品，有自己的产品设计师、开发与测试人员。
现在有战争的原因：
现在公司按职能划分团队，每个产品由原来的产品人员做，但是开发与测试人员是流动的，各个产品团队要竞争人力资源。
准备出发：
给需求打个包
做项目的终极目标是：
多快好省，即范围大、时间短、品质高、资源省。
需要在这4个因素中做平衡。
在产品需求列表上，按性价比大小，对每一行需求的工作量相加，看能做多少，这就是需求打包。
需要注意的几点：
1.需求打包最好打包类似的功能点
2.需求依赖，功能互相之间有依赖关系；
功能与人力资源之间有依赖关系，比如某功能只能由特定的人做
3.需求的粒度大小问题。
细化粒度，发现需求中价值相对低的部分，对于需求列表里的每一行，工作量最好不超过5人天
战场：
产品会议
参会人员：
各个部门的老板、各个产品的产品经理和设计师
时间：
一个月一次甚至更长
过程：
回顾上一次产品会议通过的项目进展如何->
用商业需求文档争取资源
武器：
商业需求文档
BRD：
BusinessRequirementDocument，商业需求文档
MRD：
MarketingRequirementDocument,，市场需求文档
PRD：
ProductRequirementDocument，产品需求文档
BRD包括的内容：
项目背景、商业价值（最关键）、功能需求描述（最好能画出业务逻辑关系、多加些让老板砍的需求）、非功能需求描述、资源评估（第二关键）、风险和对策
2.4.2别灰心，少做就是多做
“自动上架”需求的确定，一开始只是雏形，但越讨论加的功能越多，接着因为资源限制的原因，加的功能一个个砍掉，最后发现和最初方案是一样的。
这是一个“见山是山，见山不是山，见山还是山”的过程。
情愿吧一半的功能做到尽可能完美，也不要把全部功能都做成半吊子。
最爽就是“四两拨千斤”
肥皂生产时有漏包问题，请了一堆专家解决，最后拿着电扇对着生产线末端吹，把控肥皂盒吹掉。
技术上的大改动往往是商业上的小改动。
尽可能多地放弃
对于“评论”功能，若不放弃一些需求，要被自己折腾死。
这些需求比如：
“考虑评论翻页”、“考虑评论带图片”、“考虑被人引用后可否修改”。
有资源空出来，去做意义更大的功能或产品。
2.5心急吃不了热豆腐
一个需求的生老病死
1.需求采集，转2
2.待讨论，转3
3.需求讨论会，若暂缓，转6，若通过，则进入需求打包，转4，否则拒绝
4.需求打包通过的，转产品会议5，若不通过，转暂缓6
5.产品会议通过的，转开发，若不通过，转暂缓6
6.暂缓状态，满足重启条件后，转2
需求管理的附加值
统计每个“提交人”的需求数量=>
某个人的工作情况
统计“提交时间”、“发布时间”=>
产品发展是增速还是减速
统计每个模块的需求数量=>
用户对哪些模块感兴趣
统计每个分类的需求数量=>
产品是在成长期还是成熟期
统计需求的商业价值、性价比变化=>
看产品的发展空间有多大
有一些专业的需求管理方法和工具，比如RationalRequisitePro
和需求一起奋斗
产品经理的重要素质之一---热爱产品
3.项目的坎坷一生
3.1从产品到项目
做产品VS做项目
1.做产品时间周期长，从规划到制造到维护，没法确定合适结束；
做项目时间周期短，有明确的起始和结束时间。
2.做产品要不断修正判断，给出创新；
做项目目标明确，像执行任务
3.产品面向大量的通用用户；
项目相对个性化
找裁缝给自己做件衣服，是做项目，裁缝的设计被服装厂拿去生产，是做产品
某网站在国庆前要做一个专题，是做项目；
新闻频道持续更新，是做产品
做产品的过程，是通过一个又一个项目实现的
产品经理VS项目经理
产品经理靠想，做正确的事，看其所领导的产品是否符合市场需要，是否能给公司带来利润，内部驱动，最重要的是判断力与创造力。
项目经理靠做，把事情做正确，在时间、成本和资源约束的条件下完成目标，外部驱动，最重要的是执行力与控制力。
为什么让产品经理管项目
让项目经理管项目，他们会倾向于简化项目，尽量少做，但做出来的东西商业价值不足，用户体验不好。
让产品经理管项目，关于导致不断加需求导致项目无法按期完成，影响团队士气。
要有个平衡。
3.2一切从kickoff开始
立项过程：
需求筛选->
立项（团队组建->
计划确定->
kickoff）
帅哥美女，我们需要你
产品经理没有行政上的管理权，要向不同团队的主管要人
PD新人不适合做项目经理，因为和团队没混熟，沟通会不顺畅
项目督导委员会由项目成员的老板组成，他们负责承担责任，以及提供资源。
下面是项目经理。
项目经理下面是PD、开发经理、测试经理、UE（用户体验团队）、服务团队
别忘了最初的约定
立项阶段的项目计划，要再次评估工作量并推算出工期，除了更准确，还要考虑谁来做。
估算的工作量=（最乐观+最悲观+4*最可能）/6
按每人工作5-6小时算，留出余量时间，还要考虑任务间的依赖关系，尽量不加班。
沟通从头开始
常用沟通方法：
项目晨会、项目日报、评审会、项目变更申请、发布预告及公告
不可或缺的誓师大会
15分钟的kiffoff传达的内容包括：
BRD里的项目背景；
项目意义目的目标；
需求、功能点概述；
项目组织架构（让项目成员互相认识、关键人物要到场来确认方向正确）；
项目计划（项目的时间点与里程碑、每个人在各个阶段做什么事情）；
约定沟通计划
任何时候都要心里有“树”
做项目的本质是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡
WBS：
WorkingBreakdownStructure，工作分解结构
可套用WBS模板来方便项目管理。
WBS模板像一棵树，比如
--产品模块级项目
----项目准备
----过程管理
------立项
------时间计划
------项目总结
--------心得体会
--------数据分析报告
----需求
----实施
----测试
----服务
3.3关键的青春期，又见需求
新人可以先做一些执行层面的任务来熟悉产品和团队。
可以写文档来练手。
3.3.1真的要写很多文档
BRD、MRD是写给老板看的
PRD、FSD（功能详细说明，相当于概要分析），是写给技术人员看的
产品需求文档,PRD
PRD的模板目录：
1）总体说明
1.1）修订历史
1.2）项目概述，参考kickoff
1.3）功能范围，给出业务逻辑图，角色职责、与周边系统的关系，全局商业规则
1.4）用户范围
1.5）词汇表
1.6）非功能需求，如性能需求、数据监控的需求
1.7）其他说明
2）UC部分（用例文档）
包括视觉层面的描述（通过demo表达）,界面细节（如文字对齐），交互细节（出错提示），文案细节（提示文案）
学一点UML：
类图、用例图、状态图
略
用例文档：
UC
再学点UML：
时序图、活动图及其他
Demo也要我们做么
Demo最好由UE部门的人做，也就是美工。
De
升级会员 