人人都是产品经理笔记

空间之大：商业、产品、技术
技术
由开发、测试、运维等部门考虑， 他们决定了产品的未定型、性能、 Bug数量等特性。
商业
由市场、销售、服务等部门考虑，他们决定 产品的销售渠道、价格策略、促销策略、服 务方式等
产品
此处是狭义的，由产品设计、用 户体验、产品运营等部门来考虑， 决定了产品的功能范围、交互流 程、视觉标示线、运营手段等
用户体验部 门
交互设计与敏 捷开发的权衡
信息的呈现 方式
文案
阴险狡诈的运营师
01 负责把产品“卖出去”，让产品从“叫好”到“叫座”，获取更多用户 做裂变，病毒营销
文档
MRD市场需求文档
获得老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场与竞争对 手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优 先级等。实际工作中，PD在这个阶段常见的产出物有产品的Feature List、业务逻辑图 等，这是从商业目标到技术实现的关键转化文档
我们到底 是不是产 品经理
一个产品 经理的-1 到3岁
02
需求：一个需求的奋斗史
需求：一个需求的奋斗史
从用户中来到 用户中去
需求采集的大 生产运动
活下来的永远 是少数
心急吃不了热 豆腐
听用户的但不 要照着做
一个需求的奋 斗史
用户访 谈
调查问 卷
可用性 测试
数据分 析
需求：一个需求的奋斗史
需求采集的大生产运动
调查问卷的常见问题和对策
样本偏差：调查到的用户与想要调 查的用户群不一致
会做问卷的人，即是一种筛选，这 种隐性筛选实际上很多
对策：将目标人群的特征定义成一 系列问题，在回收问卷后进行筛选
样本过少
样本过少时不要用百分比
避免诱导性问题
可用性测试
主流程
01
02
测试过程中让用户去 完成测试任务，观察
其中的问题
3
端），最后无法发布
2 对需求的理解不一致
项目管理方法
WBS
项目：项目的坎坷一生
又见需求
文档 需求活在项目中
文档
BRD商 A 业需求
文档
FSD功 D 能详细
说明
MRD市 B 场需求
文档
UM E L图
PRD产 C 品需求
文档
交互 F图
文档
概要设计与详细设计
文档
BRD商业需求文档
产品生命周期中最早的文档，其内容涉及市场分析、销售策略、盈利预测等，通常是给 大老板演示的ppt，比较短小精练，没有产品细节，有点像创业者给投资人看的商业计 划，主要是为了获得认可，争取资源
招募测试用户
03
04
准备测试任务
测试结束后询问用户 的主观感受和看法
可用性测试的常见问题和对策
测试过程中组织者该做 和不该做的
觉得太专业所以不做
做的太晚，发现问题也 来不及改
mvp，原型图时就可 以用纸笔去让用户做
实际上可用性测试发 现问题的效率很高
测试过程中让用户边做 边说出来自己的思路 不要有任何引导
物竞天择适者生存
A
项目案例
一路坎坷，你 我同行
B
老板布置的项目
time resource quality中的T已 经定了
Q即项目范围一般是有一定灵活 性的，越上面的老板给出的要求
越抽象
R因为是老板要求，一定给够， 要狮子大开口
把Q搞大合理算出巨大的R，让老板自己 去砍，同时一定要提供优先级让老板知 道往哪里砍
产品 B 需求
需求 C 分析
满足需 D 求的方
式
用户需求vs产品需求
用户需求
用户自以为的需求，经常表达为用户提供的解决方案
用户需求vs产品需求
产品需求
经过分析，找到的真实需求，并且表达为产品的解决方案
用户需求vs产品需求
需求分析
从用户提出的需求出发，找到用户内心真正的渴望，并转化为产品需求的过程 是一个分总分的结构
产品改版的一次冒险
改版时不及早做用户测试且预留时间解决问题的话，万一用户不满意是会出现必须把版本回滚的灾 难性事件的 对策
新旧版本并存 小面积试用
数据分析
通常数据分析只能发现一些现象，之后需要通过用户访 谈寻找原因
数据分析的常见问题 和对策
误读数据
为了证明某个预设好 的观点去找数据
要取平均值是有前提的， 比如一个超级富豪和 1000个0收入者就不行
需求采集卡片
需求采集方法
现场调查
和客户一起工作一段时间
AB测试
日记研究
同行对产品的分析
卡片分类
粉丝级用户自己提需求
需求：一个需求的奋斗史
原因
明确我们存 在的价值
听用户的但不要照着做
原因
壹
用户提的需 求是站在他 个体的立场 上
贰
即使合理， 也要深挖本 质需求，参 见福特
用户需求vs产品需求
用户 A 需求
备注：强势的老板会把Q也定了， R还是不足的。
备注：与老板产生分歧，只要不 违背自己的价值观，就尽心尽力
完成任务
项目案例
封闭开发
集中到会议室开发
一路坎坷，你我同 行
三边六拍
A
三边：边计划、 边行动、边修改
六拍：脑门、肩膀、 胸脯、桌子、屁股、
大腿
B
01 02 03 04 05
几个项目的成败
过不了压力测试 需求阶段叫停，转移给别的团队 市场调研阶段认为不值得做
文档管理
建立自己的文档规范
分支主题
最适合开始做文档规范的时机是在 产品1.0版本发布，进入1.1,1.2版的 升级阶段，但尚未开始研发2.0的时 间当口
多人协作与版本管理 wiki
流程管理
叁
评 审 会 议 可 以 省 吗
贰
了不 流
事对 程
还个 的
能人 做产
生
本 质
依目
赖的
，
人
走
壹
出类项 项
来似目 的的只 东项做
用户需求vs产品需求
满足需求的方式
提高现实 降低期待 转移需求
需求分析方法论
分支 A 主题
需求的 D 种类
产品需
B
求列表 需求的 E 价值
需求的 C 基本属
性
需求的 F 成本
需求分析方法论
产品需求列表
分支主题
需求分析方法论
需求的基本属性
分支主题
需求分析方法论
需求的种类
分支主题
需求分析方法论
早一步是先驱，再早一步是先烈
成功发布，之后不断升级运营维护，项目上线后也有很多事情需要做
外包，延期半年发布
一路坎坷， 你我同行
一个只有七天的项目
项目：项目的坎坷一生
项目的坎坷一生总结图
分支主题
04
团队：我的产品，我的团队
团队：我的产品，我的团队
团队图
产品团队，游走于 商业与技术之间
大产品，大设计， 大团队
需求的价值
分支主题
需求分析方法论
需求的成本
分支主题 工期和工作量的区别，举例，生孩子要10人月
需求：一个需求的 奋斗史
活下来的永远是少数
需求pk 少做就是多做
组织架构
以产品线组织的组织架构 由产品经理直接对手上的产品负责，
有直接对接的技术、测试资源 优点：适合创业期
以职能线组织的组织架构 所有产品一个部门，所有技术一个
部门，所以需求pk变多 优点：适合成熟期，逼迫内部鲶鱼 效应
需求pk
BRD与PRD
少做就是多做
壹
情愿把一半的功能做到尽可能完美 也不要把全部功能都做成半吊子。
贰
四两拨千斤，小改动带来大效 果
需求：一个需求 的奋斗史
心急吃不了热豆腐
01
02
03
01 需 求 D N A
02
需求的生命周 期
03 需 求 简 报
示项目生命周期就算完成了。
从具体要 做的事情 来看
产品 有更多的探索
项目 基本是在执行预设的任务
从产出物 的角度来 看
产品 通用的
项目 个性化的定制的
产品经理vs项目经理
壹
产品经理 靠想，做 正确的事
贰
项目经理 靠做，把 事做正确
项目：项目的坎坷一生
一切从kick off开始
01 项目计 划
阴险狡诈的运 营师
狭义产品团队
01
产品 经理和产品规划师
02
产品设计师
功能级的设计
03
需求分析师RA
从概念设计到信息架 构
概念设计 需求采集之后，
需求筛选之前 产出：产品概念图 信息架构
《web信息架构》
激情四射的设计师
用户研究员 交互设计师 视觉设计师 前端工程师
字不如表， 表不如图
统一语言风 格
需求采 集人人 有责
用户访谈
开放式问题，用于 找产品方向
用户访谈的常见问题和对策
说和做不一致
1.讨好访谈者心理，说访谈者希望听到的答案 2.没想过这个问题，现场编 对策：结合“说”和“做”。比如把“你喜欢哪个颜色 的游戏机”改成“挑一个颜色的游戏机送给你”
避免诱导性问题，例如“如果有这个功能你会使用吗”
样本少，以偏概全
1.愿意做访谈的用户已经与普通用户有差异了 2.区域性 策略：增量方式，先根据5个用户的访谈得出结论，再 做5个观察结论是否有变化直至趋于稳定
“沉默的大多数”容易被初始发表观点的人引导
调查问卷
作答时间不超过5分钟，开篇放无需思考的问题，中间 放关键问题，个人信息放最后
调查问卷
封闭式问题
02 沟通从 头开始
03 项目管 理方法
项目计划
工作量评估 brd初评->项目经理初评->细化到个人自己评估
工作量=（最乐观+最悲观+最可能*4）/6 1人天=5~6人时 风险点
沟通从头开始
干系人权责不明确，出 工不出力 1
遗漏了利益相关方（业
务方，各bu，或者以为 只需要前端修改漏了后
C
做产品VS做项 目
产品经理vs项 目经理
B
从产品到项目
项目的定义
只会进行一次，包含多项互相关联的任务，并且有绩效、 时间、成本和范围限制的一项工作。
从生命周期的角度来看
1. 产品 2. 生命周期较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整
个过程。
3. 项目 4. 生命周期较短，在项目开始以前就有明确的起始和结束时间，通过验收则表
笔人
人
都
演 讲
人
是
产
2020-09-03
品
经
记理
目录
01. 写给-1到3岁的产品经理
02. 需求：一个需求的奋斗史
03. 项目：项目的坎坷一生
04. 团队：我的产品，我的团 队
05. 战略：别让灵魂跟不上脚 步
06. 产品经理的自我修养
01
写给-1到3岁的产品经理
写给-1到3岁的产品经理
为什么 要做产 品经理
需要数据的时候没有
平时打好点
数据分析
日志分析的商业价值
在对产品足够熟悉的基础上，先做出方向性假设，再提取相关数据并分析，得到一些现 象，最好是之前没发现过的，然后尝试解释，之后通过用户调研调整修正解释，最终指 导产品发展方向
需求
一手需求 通过前四种用研方式发现的需求
二手需求 由销售，客服，老板等提过来的需求
文档
PRD产品需求文档
PRD是对产品功能的进一步细化，文档主要包含整体说明、用例文 档、产品Demo等，会对产品功能做具体描述
文档
FSD功能详细说明
Functional Specifications Document比较像用例文档，经常包含在 PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节 都要确定，比如网页上的某个表格中的数字，应该左中右对齐？保留几位 小数等，有点像“概要设计”。与此同时，硬件系统的设计、数据库设计、 表结构设计等工作，也开始由架构师、系统分析师们编写了。
商业团队，冲锋陷 阵
技术团队，坚强后 盾
容易被遗忘的角落
团队：我的产品，我的团队
大家好才是真的好
团队：我的产品，我的团队
大产品，大设计，大团队
01 产品之 大
02 设计之 大
03 团队之 大
时间之大：产品生命周期
五种用户
分支主题 创新者 早期追随者 早期主流用户 晚期主流用户 落伍者
设计之大
任正非“先 僵化，后优 化，再固化”
《用户 体验要 素》
《设计心理 学》《情感 化设计》
团队之大
接口人
组织结构
职能型
相同职责的人划分在一个部门
矩阵型
两种的结合
项目型
各种职责的人组成一个个的项目组
心思缜密的规 划师
激情四射的设 计师
团队：我的产品，我的团队
产品团队，游走于商业与技术之间
文档
UML图
流程图
时序图
用例图
泳道图
axure
文档
交互图
文档
A
业务方面由产品定 （输入字数限制等）
技术方面由技术定 （在数据库如何存
储）
B
概要设计与详细设计
需求活在项目中
需求评审 PRD评审
设计评审 测试评审 分支主题
项目：项目的坎坷一生
山寨级项目管理
01 文档管 理
02 流程管 理
03 敏捷方 法
目 v
西目一 s
一次 直， 做流
流 程
，程
总就
结是
敏捷方法
拥抱变化
一开始的计划中间要留有一些弹性
迭代周期内尽量不加任务
集中工作，小步快跑
团队小，迭代周期短，每日站立晨会
持续细化需求，强调测试
测试驱动项目，用于补充和细化需求，比如业务逻辑的限制条件、异 常流程等
不断发布，尽早交付
大问题分而治之
项目：项目的坎坷 一生
需求DNA
分支主 题
分支主 题
需求的生命周期
分支主题
需求简报
分支主题
需求：一个需求的奋斗史
一个需求的奋斗史
分支主题
03
项目：项目的坎坷一生
项目：项目的坎坷一生
从产品到项目
一切从kick off开始
山寨级项目管 理
物Βιβλιοθήκη Baidu天择适者 生存
又见需求
项目的坎坷一 生总结图
项目：项目的坎坷一生
A
项目的定义