核心技能： 沟通能力、无授权领导能力、学习能力、商业敏感度、热爱产品、注重细节，追求完美、日常产品管理能力
#1 写给－1到3岁的产品经理

为什么要做产品经理

• 坏产品无处不在：垃圾桶、路标、盲道、洗手间的门、
• 好产品能改变世界：马桶

我们到底是不是产品经理

• 产品：用来解决某个问题的东西。可以是无形的服务，也可以是有形的实物。
• 产品：同时解决用户的问题和公司的问题的东西。
  

入行

• 做产品的大前提是喜欢做产品（热爱产品）
• 找准自己现在的位置：有没有激情，是否够机灵、好学，逻辑思维是不是清晰，沟通表达是否顺畅等
• 入行切入点：现在本职工作上找到与产品有关的事情上做一些尝试，并考虑先从产品经理周边的职位做起。

一个产品经理的－1到3岁

• 入行半年后，学习“怎么做”
• 入行一年后，开始问“做多少，怎么做”
• 入行两年后，项目与团队
• 入行三年小结，战略与修养

---

2 一个需求的奋斗史

需求的奋斗史：从需求被发现到决定实现的过程。

需求采集的过程：明确目标、选择采集方法、制定采集计划、执行采集、资料整理。之后进入需求分析阶段。
需求分析：从用户提需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

2.1 从用户中来，到用户中去

2.1.1 “从用户中来，到用户中去”的含义：

1. 需求或直接或间接都是“从用户中来”，所以要“到用户中去”
2. 产品的设计过程是一个闭环，需求的源头是用户，产品发布之后，在整个产品的生命周期中，仍然要不断的“到用户中去”收集反馈，作为产品改进的依据。

正确地理解用户，是产品经理最重要的基本素质之一。
发现一个问题，然后设法将其转化为一个任务来解决。
###2.1.2 人类为什么有需求

因为生活中存在太多的问题，从而导致了不满意，而问题就是“理想和现实的差距”，于是，人类很自然地产生“减少甚至消除这个差距”的愿望，这就产生了需求。

2.1.3 用户vs客户

用户：user，有时也叫终端用户end user，是使用产品的人。
客户：customer，是购买产品的人，也是为产品付钱的人。

不同的用户有重要程度之分，我们必须、也只能有所偏重。
试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪、谁都不满意的四不像。
我们无法满足所有用户的需求。
优先满足哪些用户需要和产品的商业目标结合起来考虑。
###2.1.4 描述用户－人物角色persona

2.1.5 用户研究的方法

• 横向：用户的说与做
  a. 怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。
  b. 既要看用户怎么做，也要听用户怎么说，虽然他说的也不一定是真话。
• 纵向：定性与定量
  a. 定性研究可以找出原因，偏向于了解；
  b. 定量研究可以发现现象，偏向于证实。

案例：
第一轮，听用户定性地说，确定产品的方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。
第二轮，听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。
第三轮，看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续找了10个用户来验证，做可用性测试。
第四轮，看用户定量地做，根据产品的用户使用情况做数据分析，不断改进产品。
但是，一般公司是不会在用户研究上投入这么多时间与人力，更多会视情况采用简化方案。

要坚决杜绝“经组织研究决定，用户需要一个xx功能”这些事件的发生，要实实在在把用户当作需求之源。

2.2 需求采集

2.2.1 定性地说：用户访谈（开放式问题较多）

常见的问题和决策：
（1）“说”和“做”不一致的问题----->说+做
（2）样本少，以偏概全的问题---->增量的方式
（3）用户过于强势—>引导到主题或尽快结束对话
（4）我们过于强势—>牢记访谈的目的，管好自己的嘴

2.2.2 定量地说：调查问卷（封闭式问题较多）

时间<5min；（简单题、较为敏感的放中间、个人信息放最后）
常见问题和决策：
（1）样本偏差（样本与目标用户）
（2）样本过少
（3）问卷内容的细节（无引导性、）

2.2.3 定性地做：可用性测试

步骤：
（1）招募测试用户（尽可能代表用户群体）
（2）准备测试任务
（3）测试过程（观察用户操作过程）
（4）询问测试者的主观看法和感觉；
（5）研究和分析
常见问题和对策：
（1）可用性测试做的太晚—>（各个阶段都要做）
（2）一定要做可用性测试
（3）测试产品而不是用户
（4）用户“发声思维”，我们不做引导，只做观察和记录，

2.2.4 定量地做：数据分析

常用用户使用产品日志分析、客户管理系统里的信息、网页访问情况的统计信息等；
常见问题和对策：
（1）科研和实际生产的区别
（2）不要误读数据
（3）时刻准备做数据分析
需求：一手需求 > 二手需求
单项需求卡片：
一张单项需求卡片描述了一个用户的需求到底包含哪些内容，重点是描述用户场景，谁在什么时间，地点产生了何种需求。

需求采集

• 现场调查
• AB测试
• 日记研究
• 卡片分类法
• 自己提需求（需求驱动学习）

2.3 需求分析

用户需求 vs 产品需求（转化即需求分析）
Y理论
攀梯术
满足需求的三种方式

• 提高现实。常用的方法是开发某种产品，也是最笨的方法。
• 降低理想。不要忽视精神的力量。“打预防针”、“丑话说在前头”等。
• 转移需求。因为人的注意力是有限的，所以引导用户去关注其它事物
  
  1、需求转化（用户需求转化为产品需求–头脑风暴）
  产品需求列表（feature lists功能列表）
  
  每行是一个产品需求，每列是产品需求的一种属性
  用户需求和产品需求（多对多）
  2、确定需求基本属性
  
  需求种类：
  产品需求=产品功能需求+产品 非功能需求
• 分类：新增功能、功能改进、体验提升、Bug修复、内部需求等；
• 层次：基础、扩展（期望需求）、增值（兴奋需求）–KANO模型
  3、分析需求的商业价值：方法
  加权平均
• 重要性：
• 紧急度：
• 持续时间：
• 商业价值（上也有相机）
  4、初评实现难度
  工作量、开发量（人天）
• 绝不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。
• 绝不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度很大就不做。
• 一切皆看性价比（商业价值/实现难度（开发量））。
  备注：
  信息架构IA-为信息和用户认知之间搭建一座桥梁，实习直观表达的载体，是研究信息的表达和传递。
  “5±2模块”二级模块

2.4 需求筛选

做项目，终极目标时多快好省。即范围大、时间短、品质高、资源省。
2.4.1 需求打包

• 最好打包类似的功能点。
• 需求依赖，功能相互之间有依赖关系。
• 需求的粒度大小问题。
  2.4.2 BRD文档

BRD:business requirement document,商业需求文档
PRD:product requirement document 产品需求文档
MRD:market requirement document 市场需求文档

项目背景：我们在哪里为什么要做这个项目，解决什么问题，主要列出一些数据说明项目的必要性。
商业价值：我们去哪里？重点！老板最感兴趣的。做这个项目以后有什么价值，还可以预测一下相关数字的变化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打包好的需求描述一下，可以用功能列表来表达，最好能画出业务逻辑关系。
非功能需求描述：如果有，提一下重要的非功能需求。
资源评估：第二大重点！说清楚达成项目的目标需要多大的花费。
风险和对策：提出潜在风险，老板会给出对策。
老板关注性价比：商业价值&资源评估
马云：少做就是多做

2.5 产品迭代

需求的周期

2.5.2 需求管理的附加值
统计每个“提交人的”需求数量
统计“提交时间”、“发布时间”等信息
统计每个“模块”的需求数量
统计每个“分类”的需求数量
统计需求的“商业价值”、“性价比”变化

---

3 项目的坎坷一生

3.1 从产品到项目（维度1）

项目：只会进行一次，包含多项相互关联的任务，并且有绩效、时间、成本和范围限制的一项工作。

做项目 VS 做产品

• 从生命周期的角度看
  产品(长）-项目（短）
• 从具体要做的事情看
  产品（不断修正自己的判断，给出适宜的创新）
  项目（有明确的目标，更注重计划与控制）
• 从产出物的角度看
  项目的产出物经过改造会成为通用的产品，有的产品经历个性化定制实际也是一个项目。
  产品经理VS 项目经理
• 产品经理product manager：内部驱动。做正确的事，靠想。
  项目经理project manager：外部驱动。把事情做正确，靠做。
  产品经理管项目

一个事物必然有它的两面。如果你只看到了一面，说明你只看到了一部分，这时你一定要跳出去，寻找另一面，之后再努力寻找“对立”背后的“统一”。
##立项
做项目的本质是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。
1 团队组建

• 项目督导委员会（买单背锅-获批准进行任务执行）
  • 项目经理
    • PD
    • 开发经理
    • 测试经理
    • UE
    • 服务团队
    • …

2 计划确定

• 评估“工作量”–“三点估算法”（最乐观、最悲观、最可能的工作量）
• 推出“工期”
  注：关键路径、里程碑（监控点）

3 沟通

• 周期：日、周（Eg：晨会、日报、评审会、项目变更申请、发布预告及公告）
• 渠道（考虑成本效益）：会议、邮件
• 发起者
• 参与者

项目启动大会

• 时间：<15min；
• 内容：
  - 项目背景
  - 项目意义、目的与目标
  - 需求、功能点概述
  - 项目组织架构
  - 项目计划（项目时间点、里程碑、资源【每个人每个阶段干什么事】）
  - 沟通计划

4 WBS（Work Breakdown Structure）:工作分解结构

需求

1 需求文档写作：

BRD 商业需求文档 最早期 PPT;老板、获得认可，争取资源；
MRD 市场需求文档（Feature Lists、业务逻辑图） ；老板、商业目标到技术实现
[PRD 产品需求文档，技术人员]（原型+各种图）(https://blog.csdn.net/Julialove102123/article/details/82597574)
FSD 功能详细说明，技术人员

2 评审

• 需求评审：PRD评审、UC评审、 Demo评审的统称。于需求的相应部分完成以后进行，评审会上pm把PRD和UC说给开发和测试听， Demo评审则由UE主讲。
• 设计评审：在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解以设计文档的形式说给pm、测试听。
• 测试评审：俗称TC评审，是在TC编写完成、测试开始执行之前进行，由测试工程师把对需求的理解以TC的形式说给PM、开发听。

需求评审会需要：一个能做决定的人；一个与此项目有关的产品接口人。
需求评审通过：里程碑

开发

测试

TC
TC的内容：测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

bug
1、bug级别的定义标准
2、bug状态流转图

发布

SVN管理员：代码版本管理员、负责项目的每日代码更新。
发布标准
发布过程
发布手续和各种表签字画押
项目发布公告！！！安慰一下众战士！！！
项目总结！！！

3.1 项目管理（维度2）－文档管理、流程管理、敏捷方法

计划与控制，就是项目管理。

PART1:文档管理

• 建立自己的文档规范
  

• 文档模版的作用
  1 让经常看同类文章的人提高效率
  2 让写文档的新手快速上手
  3 让写作者不会漏考虑某些内容

• 产生文档版本管理的本质需求是多人合作，协同办公。(SVN)

PART2:流程管理

流程的本质：
当年的英雄把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事情的时候起码不会太无助。在这点上，规范、模版的作用也类似，这也是团队核心竞争力的一种。
注：
UED:used.taobao.com
DCP (Decision Check Points）商业评审点
LMT(Life-Circle Mangement Team）生命周期管理团队
评审：
商业评审：产品会议、功能评审
技术评审：需求评审、设计评审、测试评审、发布评审

PART3：敏捷方法

• 有计划，更要“拥抱变化”
• 迭代周期内尽量不加任务
• 集中工作，小步快跑
• 持续细化需求，强调测试
• 不断发布，尽早交付

敏捷沟通：在任何情况下，我们都要做好手头的事情，确保“这事就算对公司来说黄了，我们也要通过这件事情有所收获。”

**注：**瀑布模型vs敏捷方法

物竞天择适者生存

1 老板项目(TRQ)

• 时间T是给死的。我们最常犯的错误就是把老板的偏好当成规则。老板只是一时说最好怎样，结果我们理解成必须怎样，那就亏大了。
• 数量Q（项目范围）是可变的。列出需要的功能、优先级、所需的资源，让老板选。
• 资源R是丰富的。项目优先级较高。

---

4 我的产品，我的团队

4.1 大产品，大设计，大团队

4.1.1 产品之大

• 时间之大：产品生命周期

  • 创新者innovators：新鲜感强，消费能力强，忠诚度不高，需要新鲜的东西不断刺激。
  • 早期追随者early adopters：观念比较新，需求目的性强，需要迅速能够解决问题的产品。信息达人，不盲目试用，忠诚度高。
  • 早期主流用户early majority：实用主义者，是产品大规模产生商业价值的用户群。
  • 晚期主流用户late majority：对新产品存在抵触。
  • 落伍者laggards：附加值较低的最后一批用户。
    

• 空间之大：商业、产品、技术

  • 商业：在公司里主要由市场、销售、服务等部门来考虑，他们决定产品的销售渠道、价格策略、促销策略、服务方式等。
  • 产品：包括产品设计、用户体验、产品运营部门等部门来考虑，他们决定了产品的功能范围、交互流程、视觉表现、运营手段等。
  • 技术：主要由开发、测试、运维等部门考虑，他们决定了产品的稳定性、性能、bug数量等特性。

4.1.2 设计之大

产品设计的五个层次

• 战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点。
• 范围层：明确“做多少”。对于软件类产品，确定功能范围。对于网站类产品，确定内容范围。
• 结构层：考虑产品的各个部分相互之间是什么关系。
• 框架层：用户可见的东西。对于软件类产品主要是界面设计，对于网站类产品主要是导航设计，两者都有的是信息设计。
• 表现层：视觉设计和内容的优化，比如页面配色、字体字号等。

设计的三个层次

• 第一个层次，本能水平的设计是基础，产品要有用。
• 第二个层次，行为水平的设计是保证，产品要能用。
• 第三个层次，反思水平的设计是升华，是难以捉摸的“用得爽”。

4.1.3 团队之大

• 如何设计各种职位，让各种人（职员）与各种事（职责）相互匹配。
• 接口人存在的价值
• 矩阵型组织

4.2 产品团队

规划师VS 设计师

• 规划师更多的是“结构化思维”，保证产品有用，能满足用户的某些需求，让产品“从无到有”。
• 设计师更多的是“形象化表达”，保证产品好用，能让用户用起来舒服，让产品“从有到优”。

用户体验部门

• 用户研究员user researcher：利用各种方法进行用户研究，给产品决策提供建议。
• 交互设计师interaction designer：负责人机交互页面、用户操作流程的设计，典型的工作有导航设计、信息设计，必须了解很多商业的内容，理解功能的商业价值。
• 视觉设计师visual designer：主要做视觉设计，即用户第一眼看到的效果，比如页面结构、配色方案、字体字号、按钮的形状、颜色、大小、质感等。
• 前端工程师web developer：运用前端技术进行web开发，实现产品体验的良好传达。

运营师

4.3 商业团队

团队组成：市场、服务、营销

4.3.1 好产品需要市场化

• 定价与促销：

当自己对某个领域不熟悉的时候，做起事来总会把问题想象得很复杂，把自己知道的所有知识都用上，而真正的高手，是可以一下子就找出问题的关键，然后用最简单的办法搞定。

• 销售与渠道：

销售：直销vs分销（通过渠道（代理or经销））
注：代理：赚佣金；经销：赚差价

• 产品的版本细分

• 做功能区分，打细分市场。
• 为了促进销售，利用消费者心理，纯策略性地作出“炮灰版”。

• 水平营销

纵向营销是进化，水平营销是革命；

• 需求维度
• 目标维度
• 地点与情景维度
• 时间维度
• 体验维度
• 有形的产品与服务
• 品牌特征
• 使用或购买
  ###4.3.2 我们还能做什么
  数据分析：
  提供支持，提供核心功能与卖点
  部门视角

• 服务部门是为昨天的利润工作，给已经购买产品的客户提供承诺的价值。
• 销售部门是为今天的利润工作，把产品变成利润，争取更多的客户。
• 开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖。
• 研究部门是为后天的利润工作，了解趋势、发展科技，保证永远处于领先的位置。

4.4 技术团队

• 开发团队：负有架构、编码等职责
• 测试团队：做功能、性能等各种测试等工作
• 运维团队：管理产品的数据库、服务器、软件配置

合作：超级理性的人很明白“没有规矩，不成方圆”的道理，他们喜欢被规则管而不是被人管。
##4.5 支撑团队
老板、财务、法务、行政

让老板做问答题➡️让老板做选择题➡️让老板做判断题。

5 产品的灵魂：战略

5.1 说战略

产品和产品经理（产品帮PM，互相帮助，PM帮产品）

战略如何炼出来

• 以价值观Value为根基
• 思考公司或产品的使命Mission和愿景Vision

培养大局观：站得高看得远

• 帕累托改进

5.2 制定战略：可行性分析

产品战略的具体制定，在项目管理里叫“可行性分析”，在产品设计层次的角度叫“战略层”，在公司层面可能叫“战略规划”。
完成“可行性分析”，也只是决定“做不做”，还完全没到“做多少”、“怎么做”的阶段。
###（1）我们在哪儿

• 价值观

• 使命

• 愿景

• 行业（市场扫描）

  PEST分析

• 竞争对手（竞品分析）

a $APPEALS分析法：太过冗杂
b 上网搜相似产品+看行业分析报告+咨询公司

• 自身情况（自我分析）：行业积累、技术积累、缺点

SWOT分析法

（2）我们去哪儿

• 细分市场是什么（需求场景）？

需求层次
战略管理和市场细分方法：安索夫矩阵、BCG矩阵、波特五力模型、GE矩阵、战略地图、SPAN战略定位分析、价值链分析法等
电子商务三流：信息流、资金流、物流

• 目标用户是谁？

• 解决他们的什么问题（需求）？

  注释：

  CRM 用户关系管理软件
  OA 办公自动化软件
  SCM 供应链管理软件
  HRM 人力资源管理软件
  ERP 企业资源计划

（3）我们怎么去（策略）

• 用什么产品满足需求？
• 产品的核心竞争力？

5.3 执行战略

1 产品路标规划Roadmap（指明方向）

2 靠谱的会议（修正方向）

• 开会和做产品是一样的，不要试图在一个会议中解决很多问题。
• 大会决定小事，小会决定大事。大小只参会人数。
• 要想让会议不流于形式，就要把会议本身变成形式。
• 所有人提供意见，少数人讨论，一个人拍板。《罗伯特议事规则》
• 会议记录
  

5.4 绩效考核

SMART原则

• 具体specific：绩效考核要切中特定的工作指标，不能笼统。
• 可度量measurable：绩效指标是数量化或者行为化的，验证这些绩效指标的数据或信息是可以获得的。
• 可实现attainable：绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标。
• 现实性realistic：绩效指标是实实在在的，可以证明和观察。
• 时限time bound：注重完成绩效指标的特定期限。
  产品设计的好坏是假的，用户体验的好坏也是假的，只有商业利益的多少才是真的！

多个目标间权衡：产品设计、用户体验都是假的，只有商业利益是真的！

6 产品经理的自我修养

就业保障会降低一个人的竞争力，职业保障可以提高竞争力。假设有一天，公司突然不需要你了，这时候你不用去找工作，而是有一堆公司马上排着队请你去，这才是真正的保障。

• 个人品牌建设
• 只有方法，没有答案。
• 会思考，活到老学到老
• 沟通不是为了说服，而是更好地认识世界。

提需求用户的分析思路

骂得人是不是典型用户？他的观点能代表多少人？他的影响力有多大？他是不是只是“嗓门大”的用户？他说的是不是解决方案？他的本质需求是什么？把他的需求加入需求列表里应该标什么级别？什么属性？…

解决问题的通用思路

为了什么？做什么事，解决什么人的什么问题？何时做？谁来做？效果如何？

• 为了什么？
  做某件事情“为了什么”，是大前提。
• 做什么事，解决什么人的什么问题？
  事前需要考虑的，其中“什么问题”和“什么人”是指用户需求和目标用户，“做什么事”是从用户需求转化而来的产品需求。
• 何时做？谁来做？
  事中关注的重点。项目和团队，重点是计划、控制和执行。
• 效果如何？
  事后需要讨论的。主要是总结、反馈一类的观点，都是对这个问题的回答，想清楚了才能持续改进，不断提高。