人人都是产品经理1.0 读书笔记
2023-06-26 14:38:43 0 举报读书笔记，持续更新至阅读结束
作者其他创作
大纲/内容
写在正文之前 / 1
为什么会有这本书? / 1
本书的产品定位 / 2
本书的风格与特色 / 5
本书的目录与内容 / 6
我与本书的局限性 / 8
第1章写给-1到3岁的产品经理 / 11
1.1 为什么要做产品经理 / 13
坏产品：无处不在的危险
好产品：从垃圾桶到洗手间
1.2 我们到底是不是产品经理 / 20
产品究竟是什么?
产品是一组将输入转化为输出的相互关联或相互作用的活动”的结果，即“过程”的结果。在经济领域中，通常也可理解为组织制造的任何制品或制品的组合。
产品的狭义概念:被生产出的物品
产品的广义概念:可以满足人们需求的载体
产品就是用来解决某个问题的东西
本书的概念：产品就是要同时解决用户问题和公司问题
他们真是产品经理么
侧重产品本身“从无到有”、“从有到优”的过程
更多地涉及“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容
产品经理横空出世——传统意义下的产品经理
为了适应公司发展的需要而出现
职责：规划产品的生命周期，负责产品的上市策略、定价策略、整合营销策略、销售与分销策略
偏重于市场、商业端
产品经理概念的进化——互联网、软件行业
偏重研发类创新——更重视产品功能本身的规划
重点资源会投入在产品本身——更重视需求分析、设计的细节
生命周期短而快————产品经理需要兼顾项目管理，在项目完成度和产品质量之间做平衡
盈利模式的差异——更重视用户研究、数据分析工作
免费用——更重视用户体验
非典型产品经理
产品管理团队
事业单位经理的任用
更专业取向
一线员工眼中的管理
管理的能力，其实就是“在资源不足的情况下把事情做成”的能力
信息不足以决策
时间不足以安排周密的计划
人员不足以支持工作强度和难度
资金不足以自由调配
——目标：学会分配资源、管理资源
你已经是产品经理
1.3 我真的想做,怎么入行 / 29
产品经理的招聘广告
真的想？你确定？
找到自己的位置
几个可能的入行切入点
1.4 一个产品经理的-1到3岁 /34
第2章 一个需求的奋斗史 / 41
2.1从用户中来到用户中去 / 44
2.1.1用户是需求之源 / 44
人类为什么有需求? / 45
问题是理想与现实的差距，减少甚至消除这个差距的愿望产生了需求
理解用户，是产品经理最重要的素质之一
需求的本质是问题，问题的本质是理想与现实的差距
用户VS.客户 / 46
用户：User (使用产品的人=终端用户 End User)
客户：Customer——购买产品的人，为产品付钱的人
用户：广义，指所有和产品有关的人
不同的用户有重要程度之分
广义用户是需求之源
以用户为中心的思想 / 47
以老板为中心的行动
不要试图满足所有用户 / 47
区别对待广义用户
优先级评估、需求管理
关心核心用户的需求还是满足大量一般用户的需求
优先满足哪些用户需要和产品的商业目标结合起来考虑
2.1.2你真的了解用户么? / 49
体会真正的用户 / 49
试着描述用户 / 50
创建人物角色（Persona）
聊聊用户研究 / 53
《赢在用户: WEB人物角色创建和应用实践指南)》
横向：用户的说和做
怎么说表现了目标和观点
怎么做反映了行为
纵向：定性与定量
定性研究找出原因，偏向于了解
定量研究发现现象，偏向于证实
听用户定性说——确定产品方向，做什么
听用户定量说——确定需求优先级，先做什么？
看用户定性做——先做的需求应该怎么做？用户做可用性测试
看用户定量做——根据用户使用情况做数据分析，不断改进产品
2.2需求采集的大生产运动 / 55（步骤：明确目标、选择采集方法、制定采集计划、执行采集、资料整理——>需求分析）
2.2.1定性地说:用户访谈 / 56
用户访谈的常见问题与对策 / 56
用户访谈——可以了解用户怎么说，即他们的目标和观点；通常用在新产品预研工作或者通过数据分析发现现象以后，探索原因
说和做不一致问题
样本少，以偏概全问题
用户过于强势，把我们往沟里带
我们过于强势，把用户往沟里带
记一次用户大会 / 59
明确目的
资源确定：时间、地点、任务、材料、各项备用方案的准备
现场执行：辅助工作、主流程
结束以后：资料整理、运营、整个活动资料的整理归档
2.2.2定量地说:调查问卷 / 60
调查问卷的常见问题与对策 / 61
调查文件设计要点：
作答时间不要超过10分钟；
开篇——简单不需要思考的问题；
中间——很想知道的、需要思考的、或者敏感的问题
最后——被访者个人信息
调查问卷的常见问题与对策
优点：客观，一人一份，独立作答
缺点
样本的偏差，即样本与想了解的目标用户群体出现偏差——按照目标用户鼻涕设置调查样本选择比例；将目标群体的特征定义成问题，放入问卷中
样本过少的问题
问卷内容的细节问题
问题表述应无引导性
准备几种形式的问卷，减少顺序偏差
先进行小范围试答，根据反馈修改后，在打面积投放
设计一份实际的问卷 / 62
清楚目的；明确样本对象，调查渠道，时间计划；设计问卷内容
2.2.3定性地做:可用性测试 / 64
可用性测试过程
招募测试用户
原则：尽可能地代表将来真实的用户
准备测试任务
原则：实际使用中的典型任务
测试过程
用户通过使用产品完成所要求的任务
组织者观察用户操作的全过程，并记录发现的问题
测试结束后
组织者询问用户对于产品整体的主观看法或感觉
询问用户当时的想法，为什么做那些操作？
研究分析
分析记录并产出一份产品可用性问题列表
对问题的严重程度进行分级
可用性测试的常见问题与对策 / 65
可用性测试不可做得太晚，在产品的任何阶段都可以做
可用性测试很重要，，简化做也比不做好
是测试产品，目的是发现软件产品中的问题
测试开始，要告知用户大概时间以及要做哪些事情，让用户心中有数
测试过程中，让用户说出自己的思考过程
测试过程中，不要有任何的引导与暗示，只做观察和记录
测试结束后，可送个小礼品，尽快总结，并发给用户
产品改版的一次冒险 / 66（把暴力革命变成温柔的和平演变）
先从次级页面改起
新旧版本并存一段时间，并允许用户自由选择
小面积试验，选择一小批用户放出新版本，做用户调研
傍上一个用户已经习惯的风格
2.2.4定量地做:数据分析 / 68
数据分析操作
数据来源：用户使用产品的日志，客户管理系统里的信息，网页访问情况的统计信息等
数据分析方法：Excel、统计软件、数据库软件或自己写程序
数据分析结果解读：+用户访谈
数据分析的常见问题与对策 / 69
过于学术，沉迷于科学研究——注重综合的性价比
虽然数据不会主动骗人，但我们经常无意或有意地误读数据
无意误读：学习统计学知识，努力提高自己的水平
有意误读：对数据保持中立的态度，减少利益牵扯
平时不烧香，临时抱佛脚
在从产品设计的时候就把数据分析的需求加进去
日志分析的商业价值 / 70
再对从产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向
2.2.5需求采集人人有责 / 73
生孩子与养孩子/ 73
生孩子：采集一手需求，直接从用户那里得到需求——新产品诞生之前，从无到有
养孩子：采集二手需求——产品已经运行一段时间后
单项需求卡片 / 74
产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与采集的过程
单项需求卡描述用户需求到底包含哪些内容，重点是描述用户场景，谁在什么时间、地点产生了何种需求
单项需求卡设计内容
需求编号
需求类型
需求来源
场景
描述
原因
验收标准
需求重要性权重
需求生命特征
需求关联
参考材料
竞争者对比
尽可能多地采集 / 77
特点：贯穿始终，所有人的责任，没有特定的方法，怕遗漏合理的需求
需求采集方法
现场调查：和客户一起工作一段时间，深度了解需求
AB测试：大用户量比较合适
日记研究：互联网新兴的个人应用比较适合
卡片分类法：把产品的各种需求写在便利贴上，，让用户一起讨论并完成分类
自己提需求：
2.3听用户的但不要照着做 / 78
2.3.1明确我们存在的价值 / 78
用户需求VS.产品需求 / 79
用户需求：用户自以为的需求，并且经常表达为用户的解决方案
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，，再转化为产品需求的过程。
技术分析：树干——树枝——树叶：任务分解过程
需求分析：分-总-分的分析过程
首先：树叶——树枝——树干
其次：树干——树枝——树叶
满足需求的三种方式 / 80
需求来源于立项与显示的差距。减少差距的方式
改变现状
降低立项
转移需求
也谈创造需求 / 81
2.3.2给需求做一次DNA检测 / 82
把用户需求转化为产品需求 / 82
确定需求的基本属性 / 84
编号，方便随时查找
提交人，必填，提交人要负责今后的任何时候解释需求的来源，有义务充分理解原始的用户需求
提交时间，辅助信息
模块，影响到网站的导航结构
名称，用简洁的语言描述，要给客户提供什么功能
描述，具体解释名称里说的功能是什么意思，只要说明此功能要做什么，无需解释怎么做。要求语言无意义性、完整性、一致性和可测试性
提出者，用户需求的提出者，方便进一步追溯
提出时间，辅助信息，原始需求的提出时间
Bug编号，非必填，有必要的时候，一些产品bug也是需求
需求种类知多少 / 86
分类：新增功能、功能改进、体验提升、Bug修复、内部需求……
层次：基础、扩展（期望需求）、增值（兴奋需求）——KANO模型
产品功能需求+产品非功能需求=产品需求
产品需求+市场需求+开发需求+测试需求+服务需求+……=产品包需求
雪中送炭：基本功能，对用户很有用，产品缺了这个功能跑不起来
锦上添花：非必须功能，有时候用得到，有的话会给用户的使用带来便利
分析需求的商业价值 / 88——最关键的内容
重要性
满足后“一般”到“高兴”
未实现“略感遗憾”到“非常懊恼”
紧急度：在时间维度上判断这个需求是否迫切
紧急不重要的需求：解决了短期问题，如果熬过去没做，对长期影响不大
解决了局部的问题，如果不做对大多数用户没有影响
持续时间
商业价值（商业优先级）是对上述集中商业价值指标的综合评判。这个判断直接影响着产品未来的方向
实现方法：在需求讨论会上由产品团队集体讨论，包含所有有必要的干系人
最终定指标（高中低）：群体打分，老大拍脑袋
初评需求的实现难度 / 89
简化为人力成本，即工作量
把工作量再简化为开发量
必须评估，允许误差
性价比啊性价比/ 90
一切皆看性价比：用于决定先做哪个
性价比=商业价值÷实现难度(简化为开发量)
实现难度小的先做还是商业价值高的先做，这是一个平衡问题
2.4活下来的永远是少数 / 92——需求筛选
2.4.1永远忘不掉的那场战争 / 93
准备出发:把需求打个包 / 94
项目时间固定（迭代周期），团队相对固定，变量即为项目范围
计算可用工作量，按照性价比从高到低取数，计算纳入项目的需求点，完成需求打包
相对来说可以超出可用工作量，方便砍需求后随时补充
需求打包最好打包类似的功能点，打包后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解
需求依赖，功能互相之间有依赖关系
需求的粒度大小问题——需求粒度尽量细与细化引起的管理成本上升在可接受范围内（需求列表中的任意一行，工作量最好不要超过5人天）
战场:产品会议 / 96
一般流程：先回顾上一次产品会议通过的项目进展如何，是否需要调整时间进度，是否需要追加资源，是否有重大需求变更，已经发布的项目有什么问题
武器:商业需求文档 / 96
BRD包含内容
项目背景
我们在哪里？
为什么要做这个项目？
解决什么问题？
列出一些数据说明项目的必要性
商业价值
我们去哪里？
有什么价值
预测一下相关数字的变化
提出项目的商业目标
功能需求描述
我们怎么去？
通过做哪些事情达到目标
列出功能列表
画出业务逻辑关系
非功能需求描述
资源评估
风险和对策
2.4.2别灰心，少做就是多做 / 100
最爽就是“四两拨千斤” / 100
做得少不如做得巧
从目的出发，在动手前找找有没有成本低、收效大的解决方案
尽可能多地放弃 / 101
2.5心急吃不了热豆腐 / 103
一个需求的生老病死 / 103
需求状态：待讨论、拒绝、暂缓、开发中、测试中、已完成
负责PD：在需求状态变为“需求中”时指定需求的主人，需要从头到尾跟进
开发工程师：在需求状态变为开发中时指定，负责需求的技术实现以及将来可能的故障解决
项目名称：在需求进入开发中时确定，用来筛选某个项目的需求
发布时间：在需求变为已发布时填写，用来查看某段时间发布的需求
备注：其他任何信息都可以，例如被拒接的理由，被暂缓的理由和重启条件
需求管理的附加值 / 106
需求简报
统计每个提交人的需求数量——侧面反应某段时间每个人的工作情况
统计提交时间、发布时间等信息——侧面展示产品发展是在增速还是减速
统计每个模块的需求数量——展示用户对哪些模块感兴趣，指导产品发展的方向
统计每个分类的需求数量——了解新功能多还是老功能优化多，了解产品是在成长期还是成熟期
统计需求的商业价值、性价比变化——了解产品的发展空间还有多大
和需求一起奋斗 / 107
第3章项目的坎坷一生 / 111
3.1从产品到项目 / 114
做产品VS.做项目 / 114
从生命周期的角度来看
产品的生命周期相对较长，关注整个产品从规划到制造，再到最终维护和消亡的整个过程
项目有特定的目标，生命周期较短，通常在项目开始以前就有明确的起始和结束时间，通过验收则表示项目生命周期完成
从具体要做的事情来看
做产品的过程会有更多的探索，产品负责人需要不断地修正自己的判断，给出适宜的创新
项目在开始时有明确的目标，更注重计划于控制，更像是执行一个任务
从产出物的角度来看
产品可以批量生产或提供给大量用户，相对通用，通常考虑用有限的资源去满足更多的、有更多回报的需求，产出物比较个性化
项目要满足特定的需求
项目——产品——产品线
产品经理VS.项目经理 / 115
产品经理——靠想。产品经理关注做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润
关注做正确的事
关注产品生命周期
关注产品能否赚钱以及能否持续赚钱
——产品经理需要规划整个产品的架构和发展路线，确定产品的定位和受众，预计产品真正的价值和效益
内部驱动，最重要的是判断力与创造力，决定做不做，做什么，做多少，保证方向正确
项目经理——靠做。项目经理关注把事情做正确、完美；在时间、成本和资源约束的条件下完成目标
关注项目能否按照既定的目标顺利完成
外部驱动，最重要的是执行力与控制力，决定怎么做，谁来做，何时做，保证方法得当
为什么让产品经理管项目 / 116
3.2一切从Kick Off开始 / 118
帅哥美女,我们需要你 / 118
团队组建
项目督导委员会：背黑锅+买单
项目经理
PD：负责项目需求，可兼任项目经理
开发经理：负责开发时间计划与任务分配，全程掌控设计编码直至上线的过程
开发工程师：开发团队负责开发相关的任务
测试经理：测试时间计划于任务分配
测试工程师：测试团队负责测试相关的任务
UE（用户体验团队）：负责产品给用户的展现，比如交互效果、视觉效果等
服务团队：负责产品帮助的编写，以及上线后的服务工作
设置各种职能的接口人：牵涉其他产品时负责协同工作
关键到位即可开始项目：项目经理、PD、开发经理
别忘了最初的约定 / 120
项目计划：再次评估工作量并推算出工期
开发经理根据团队开发工程师的能力特点、擅长领域把各项开发任务分配到最合适的人
开发工程师自己评估工作量
三点估算法：最乐观的工作量，最悲观的工作量，最可能的工作量
工期：转化到日历上，说明这件事从何时开始到何时结束，需要考虑各项任务的依赖关系以及项目成员的其他工作，并保留适当机动时间
项目经理需要把开发计划、测试计划、发不计划等合并成为项目计划，并确定项目的里程碑
沟通从头开始 / 122
周期：以日或周为单位，主要取决于项目时间的长短及变化的频率
渠道：会议、邮件等，需要在成本和效率之间取得平衡
发起者：一般由项目经理、开发经理、测试经理主导相应的沟通
参与者：发起者确定参与者，不要遗漏项目边缘的同事
常用的沟通方法
项目晨会：子项目进入开发阶段至发布日止，开发经理每日召集PD、开发、测试参加
项目日报：自项目启动至发布日止，项目经理每日发给所有项目干系人，测试开始后以测试日报为主
评审会：相应PD召集需求评审；相应开发召集设计评审；相应测试召集测试用例评审；产品可用之后，项目经理尽快召集功能评审
项目变更申请
发布预告及公告：
不可或缺的暫师大会 / 123
KO：Kick Off会议
内容：
项目背景
项目意义、目的与目标
需求、功能点概述
项目组织架构
项目计划
沟通计划
任何时候都要心中有“树” / 125
在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡
分解任务（WBS）：重视完整性
对每个具体的项目评估处每项任务的工作量
安排人力资源，把工作量转化为工期
生成项目时间计划
3.3关键的青春期,又见需求 / 127
3.3.1真的要写很多文档 / 127
要写的文档
BRD： Bussiness Requirement Document，商业需求文档
产品生命周期中最早的文档
内容涉及市场分析、销售策略、盈利预测等
产出物：通常是给大老板演示的PPT
MRD： Market Requirement Document，市场需求文档
产品实施阶段编写，从商业目标到技术实现的关键转化文档
更细致的市场与竞争对手分析
包括可通过哪些功能实现商业目的，功能、非功能需求分哪几块，功能的优先级等等
产出物：产品的Feature List ，业务逻辑图等
PRD：Product Requirement Document，产品需求文档
对产品功能的进一步细化，对产品功能做具体描述
主要包含整体说明、用例文档、产品Demo等
产出物：主要是给技术人员看的PRD文档
FSD：Functional Specifications Document，功能详细说明
经常包含在PRD中，有点像概要设计
包含很多技术内容，产品洁面、业务逻辑的细节都要确定
产出物：主要是给技术人员看的文档
产品需求文档，PRD / 128
PRD目录
修订历史 写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。
项目概述 简单描述项目的背景、意义、目的、目标等，描述业务领城知识，让文档读者明白这个项目是为什么而做。
功能范围 给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规则等。
用户范围 对本PRD涉及的角色、系统做出简单的说明。
词汇表 对本PRD涉及的专有词汇、术语、缩写等做出说明。
非功能需求 如性能需求、数据监控的需求等。
其他说明 其他任何需要说明的内容都可以写在这里。
学一点UML:类图、用例图、状态图 / 129
类图：Class Diagram
用例文档, UC / 131
再学一点UML:时序图、活动图及其他 / 135
Demo也要我们做么 / 136
概要设计与详细设计 / 139
3.3.2需求活在项目中 / 140
评审:一个头两个大 / 140
再看需求的生老病死 / 142
3.4成长，一步一个脚印 / 143
开发阶段,旁观者说 / 144
测试阶段,大家一起上 / 145
Bug眼中的项目 / 146
那一-夜,项目发布 / 149
以终为始,项目小结 / 151
怕什么来什么，只能拥抱变化模板作用知多少 / 154
3.5山寨级项目管理 / 155
3.5.1 文档只是手段 / 155
建立自己的文档规范 / 155
模板作用知多少 / 158
多人协作与版本管理 / 159
玩转Office足矣 / 160
3.5.2 流程也是手段 / 162
项目VS.流程 / 162
流程的本质目的 / 163
那么多评审,可以省么 / 165
商业评审与技术评审 / 166
3.5.3敏捷更是手段 / 167
从书本到实践 / 167
项目中的敏捷沟通 / 169
与外包团队的敏捷尝试 / 171
3.6物竞天择适者生存 / 172
3.6.1亲历过的特色项目 / 173
如何做好“老板项目” / 173
秘密行动,封闭开发 / 175
开发外包?项目外包? / 175
3.6.2 一路坎坷， 你我同行 / 176
几个项目的成败 / 177
一次只有七天的战斗 / 178
第4章我的产品，我的团队/183
4.1大产品，大设计，大团队/ 186
4.1.1产品之大1 186
4.1.2设计之大/ 190
4.1.3团队之大1 196
4.2游走于商业与技术之间/ 201
4.2.1心思缜密的规划师/ 202
4.2.2激情四射的设计师/ 205
4.2.3“阴险狡诈” 的运营师/ 215
4.3商业团队，冲锋陷阵/ 221
4.3.1好产品还需市场化/222
4.3.2我们还能做什么/ 229
4.4技术团队，坚强后盾/ 234
4.5容易被遗忘的角落/ 237
4.6大家好才是真的好/ 240
4.6.1所谓团队文化/ 240
4.6.2虚无的无授权领导/ 242
第5章别让灵魂跟不上脚步/ 249
5.1触及产品的灵魂/ 251
5.2可行性分析三步曲/ 256
5.2.1我们在哪儿/ 256
5.2.2我们去哪儿/ 259
5.2.3我们怎么去/ 263
5.3做吧，准备出发! / 265
5.3.1敢问路在何方/ 265
5.3.2低头走路,抬头看天/ 268
5.4 KPI, KPI, KPI! / 272
5.5本书的源头活水/ 278
第6章产品经理的自我修养/ 279
6.1爱生活，才会爱产品/ 282
6.2有理想,就不会变咸鱼/ 286
6.3会思考,活到老学到老/ 291
6.4能沟通，在什么山头唱什么歌/ 296
6.5产品经理主义/ 302
附录:它山之石可以攻玉/ 313
别人眼中的产品经理/ 313
各种有用的信息/ 318
0 条评论
下一页
