《产品经理深入浅出》PART 3：产品经理专业技能
主要工具
1 Microsoft Office 2013
1）. Excel（数据统计，数据报表，数据分析，数据图例制作，进度控制，神器）
√ Excel文档结构（版式设计，逻辑结构表现，色彩）
√ 简单的函数计算（加、减、乘、除）
√ 数据组织（筛选、排序、）
√ 图标制作（饼状图，柱状图，条形图，折线图等）
2）. PowerPoint（演示利器）
3）. Word（文档）
2 Microsoft Visio 2013
–流程图利器
–信息结构图利器
3 Axure 8
–简易流程图
–原型利器
4 BalsamiqMockups
–原型图草图利器
.可以快速构建你想要的东西
.很好的支持移动性能
.元素丰富
.不容易干扰UI设计
5 Mind manager2012
–思维导图（Mind master）
–收集，归纳，整理想法与思路
6 最牛利器：2B
三大文档BRD/MRD/PRD
商业需求文档BRD （Business Requirement Document）
a) 文档的目的
-发现
•现有产品改进的可能（360安全卫士）
•一个创新产品（抖音）
–需要
•要权重
•要项目
•要资源
b）汇报对象
c）BRD内容结构
–1.方案形成背景
–2.方案价值
–3.产品规划
–4.盈利模式
–5.收益与成本评估
–6.风险和对策
1.方案形成背景
市场环境分析
我们要做什么
要解决什么问题这问题是迫切的问题吗？
这个问题是强烈的问题吗？
这个问题出现的频率高不高？如果要这么做，我们的优势在哪里？
•技术优势
•经验优势
•资源优势
•……–得到可行的结论
2.方案价值
a 好处：
非经济类：战略
经济类b 提出你的预测
目标
对于得到的好处
3.产品规划
产品结构（产品分块）
产品路线（未来规划）
注意：BRD不要扯太多产品形态细节的东西
4.盈利模式
5.收益与成本评估
收益预估
成本预估
6.风险和对策
风险的种类
•政策风险
•经济风险
•市场风险
•行业风险
•公司风险
•技术风险
•资本风险应对办法
•规避
•接受
•降低
•分担
•转移
d）优秀BRD
4.1 重点突出
❤商业价值
❤收入与成本
❤风险与对策
4.2 是不是产品就不重要？
❤BRD很多时候是定性的东西，不要过多的去扯产品细节（技术驱动产品要两看）
❤产品经理不要总是把目光定在产品上，要学会跳出来
❤集中火力，不扯淡
4.3 说服力
❤演讲技巧
❤对公司战略的理解
❤对汇报对象思维方式的理解
—->多沟通，或与其合作伙伴沟通
—->平时多观察行事风格
4.4 见人说人话，见鬼说鬼话
❤要变通
❤但要有逻辑，理论有支撑
4.5 言简意赅，点到即止
❤ 有的话不能说透
❤ 一图胜千言
❤ 一句能说清楚，不要说两句
❤ 不要过多的使用专业术语
❤ 客观评估，不要给自己埋地雷，但该点到的问题都要点到（困难，风险等）
4.6 BRD文档的内容结构
❤–1.方案形成背景
❤–2.方案价值
❤–3.产品规划
❤–4.盈利模式
❤–5.收益与成本评估
❤–6.风险和对策
市场需求文档MRD（Market Requirement Document）
a)目的
i.BRD明确了一件事值得做，这时候需要怎么做，为什么
ii. MRD拿出一套做某事的方法和指导
b)对象
i.未来参与产品的各个阶层的同事，包括自己
c)内容
i.文档说明
- 基本信息：公司名称，产品名称，文档创建日期，创建人，创建人联系方式，部门，职务
文档修改记录
文档目的：用于说明相关市场，用户，产品规划，核心目标，产品路线图，项目规划。（便于交接，也是新手做的东西，要写好）
文档概要：文档说明、市场说明、用户说明、产品说明4个方面的概括
ii.市场分析
摘要（可选）
现有市场存在的问题（这就是我们能努力的地方，从产品/技术/运营/用户/商业模式分析）
就互联网而言，可以从以下（但不限于）几方面来选择性表述：
–产品方面（例如：产品形态复杂，用户体验差）
–技术方面（语音压缩技术不成熟，外资搜索引擎对中文理解不够深刻）
–运营方面（产业链偏下游，重实体，轻线上，造成瓜分线下旅行社利润，形成对立）
–用户方面（用户需要可替代产品尚未出现，需求明显）
–商业模式方面（金山毒霸和360安全卫士的商业模式对比）目标市场分析（基于该机会点下的市场分析说明）
• 市场规模（多少钱，成功可能大不大，往往是正比，但不绝对是，具体问题具体分析）
• 市场特征（现有市场表现出的典型特征）
• 发展趋势（未来2-5年的发展评测，搜索市场的语音搜索，苹果的Siri，体感便携设备：谷歌眼镜，苹果iwatch）
• 时间边界（这个市场的持续时间预估）市场分析结论
一般来说，这里会得到一个比较有市场商业价值的结论（否则这个文档就没有存在的意义了，囧）
iii.用户分析
目标用户群体（找准）（通过年龄段，收入，学历，地区）
目标用户特征（要找到共性的特点和非共性特点）
建立虚拟用户角色（形象化）
即自己创造一个用户出来，他的名字，性格，收入，与产品关联的特征，他的期望）
用户角色卡片针对目标用户群体进行归类划分，抽取典型样本，数量不限，带需要能代表目标用户）
用户使用场景（用户放到实际场景去，此时是演示，不要在此时去说一堆自己的推理流程，说出时间地点人物事件即可）
动机总结（读懂表象）动机是方法，用户干啥了；
- 用户目标总结（明确实质）
目标是目的，用户通过干啥之后希望得到的东西 - 影响用户使用的主要因素（重要，分析）
–是否随身携带接入设备
–网络是否通畅
–查询速度
–设备对商品信息的获取是否会对用户造成不便
–等….
iv.产品说明
- 产品定位（推荐书《定位》，要准确，决定了之后整个产品的走向）
a)市场定位:我们对用户或者用户市场的选择,例如:手机发烧友,白领,或者移动通讯设备市场
b)产品定位:我们用什么样的产品满足用户或用户市场,例如:
.陌陌，一款基于地理位置的移动社交工具
.Chanpin100.com，为产品经理们提供学习交流的平台，并专注于此
.QQ空间，一个异步信息分享和交流的平台，是QQ这种同步通讯工具的补充。
c)用户定位的描述：.针对什么目标群体，做什么事情，用最本质的，无修饰的语言表述:
- 产品核心目标（产品要干啥达到什么要清晰，整个目标是最重要的，工作是围绕这个展开的，版本迭代和这个有关）
补充：去查微信的迭代记录，分析产品的核心目标和产品的路线规划，版本迭代就是有在有限时间对最高优先功能的完善
- 产品结构（不是功能结构，是产品的整体结构）
a)市场定位，产品定位，核心目标的直接表现
b)用图例，流程图去表现一个产品使用起来，整个流程，各个部门，可以用工具画出一个页面草图
c)产品结构是一桌菜，我们要上什么菜，有什么菜品，先规划；功能结构是如何做出上面的菜，需要炉子，需要厨师，需要菜，需要餐具等
产品路线图（几月份要做出什么东西，先做什么，核心的是要什么，是大的核心目标的分解。时间，任务-子任务辅助说明）
产品功能性需求：
产品非功能性需求：有效性，性能，扩展，安全性，健壮性，兼容性，可用性，运营，用户体验
d)优秀MRD
i.逻辑性强，有理有据，没有废话
ii.抽象具现化
iii.数据可靠，分析合理
iv.重视非功能需求
v.专业名词的辅助解释，即可读性
vi.有把握的事情要去主观取巧说明，没有把握的再去客观量数据（我觉得没经验这种事情还是不要做太多，会容易拍脑袋）
e)即找定位，设目标，订路线
产品需求文档PRD（Product Requirement Document）
a) 产品需求文档(Product Requirement Document，PRD)
–PRD文档向上是对MRD内容的继承与发展，向下则是要把MRD文档里面的各种理论要求技术化，向研发部门与设计部门说明产品的的功能和性能要求。
–PRD文档是产品文档中最底层最细致的文档，所以写作的时候，需要细致耐心。
b)对象
i.研发人员：功能的实现与性能
ii.设计人员：产品调性与原型图
c)表现方式
i.文字：word
ii.原型图：Axure（PRD换成Axure+说明，导出为WORD文档）
iii.图片
iv.影像模式
d)内容
i.文档说明
1.与MRD的文档说明相同，也有一样的创建日期，创建人等
2.产品版本号（各公司规则不同，这里举例1.26）
a)1是版本号：重大调整升级与产品功能机构调整
b)2是子版本号，在原有基础上局部功能的调整和升级
c)6是修正版本号，局部小范围优化与BUG修复和不动功能性的东西3.命名原则：归零原则（1.26变成1.30而不是1.36），收费原则（收费那么版本号要改）
4.历史修订
a)内容：编号，版本号，修订章节，修订原因，修订日期，修订人
b)作用：修改前后进行比较，维护管理PRD，追溯责任
5.名词术语表
a)不易理解的词汇，在开篇统一列表说明
ii.产品说明
1.内容：
a)信息结构图（研发人员，数据库参考，可以理解为需要用到数据库储存的功能）
b)产品结构图（产品思路，版面，区域，例如网站可以理解为DIV布局）
c)用户使用流程图（用户行为流程，可以理解为做程序流程图）
补充：不要为了20%的用户浪费你大量的资源
iii.全局功能说明（主要部分）
1.整体功能说明，如UI交互（例子，优先加载用户页面，我发现知乎没网的时候就是先加载用户页面。和微信朋友圈里的24小时前表示为为1天前）
iv.详细功能说明
a).各个板块的详细说明，不同人方法不用
- 按照功能逻辑来表述需求，产品100的例子，产品100下面是首页，喜欢，回复，再往下分
- 按照产品结构来表述(频道，页面，模块，元素的逻辑表述,相对比较适合产品经理的逻辑，产品经理喜欢）
–具体哪一个，看团队要求和默契程度 a)表述顺序：
* b) UML>用例文档>用例图和状态图*
i.统一建模语言unified modeling language
ii.面向对象的建模语言
* c)用例图*
i.描述功能需求的方法，参与者与系统之间的关系组成的示意图（可以理解为matlab里的simulink）
ii.元素：参与者，用例，关联线，方框
* d)用例说明*
i.对于上面的用例图的元素的详细说明，备注之类的
补充：这些东西都没有固定的东西，要看整个团队的风格
* e)原则与注意*
i.原则MECE：相互独立，完全穷尽，即重大问题不重叠不遗漏
ii.PRD一定要保证思考到位，产品结构本身短期内不会有重大改动，不然团队会很痛苦
iii.PRD是要不断修改，不断与团队协调出来的，不会一次搞定
f)优秀PRD文档特点
i.正确思路
ii.无歧义，易读
iii.完备，MECE
iv.一致，同一事物一致用词
v.具有优先级，分主次需求
vi.可验证，功能性描述不是那种效率高，交互完美的定性词，应该是量化的
vii.可修改，PRD有利于后期修改与升级
viii.可追踪，功能性需求来源清楚，知道怎么来的