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

为什么要做产品经理

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

我们到底是不是产品经理

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

入行

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

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

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

2 一个需求的奋斗史

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

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

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

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

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

正确地理解用户，是产品经理最重要的基本素质之一。
发现一个问题，然后设法将其转化为一个任务来解决。
###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 产品经理的自我修养

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

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

提需求用户的分析思路

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

解决问题的通用思路

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

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

产品读书《人人都是产品经理 1.0》相关推荐

产品读书《麦肯锡工作法：麦肯锡精英的39个工作习惯》
目录前言麦肯锡解决问题的流程: "解决问题"的习惯 "精英部下"的习惯 "善于安排工作过程"的习惯 "抓住顾客心理" ...
麦肯锡精英的39个工作习惯
公众号回复:干货,领取价值58元/套IT管理体系文档公众号回复:ITIL教材,领取最新ITIL4中文教材麦肯锡公司(McKinsey&Company)是由美国芝加哥大学商学院教授詹姆斯·麦 ...
《麦肯锡工作法——麦肯锡精英的39个工作习惯》——职场工作守则
文章目录保持"从零开始" 解决问题流程分析和解决问题主动总没错,重视沟通重视效率紧急-重要模型做人 30秒快速汇报寻找良师这里只谈我印象深一点的习惯和自己的理解. ...
麦肯锡精英的48个工作习惯~书摘
麦肯锡精英的48个工作习惯~书摘序言1 世界上的杰出人物为什么会重视这些成功经验? 本书工作经验分享包括两个方面: 一是大家都知道的常识性并且在工作中发挥重要作用的事二是虽然大家都知道,但是想要继 ...
《麦肯锡精英的48个工作习惯》书评
<麦肯锡精英的48个工作习惯>的作者是在高盛和麦肯锡都工作过的一位日本人,总结商业精英的一些工作习惯.书中的内容最大的特点就是可操作性高,非常高,如果辅以反思,必将能给自己带来很大的提高. ...
《麦肯锡工作法》麦肯锡精英的39个习惯
关于作者: 大岛祥誉,Senju Human Design Works董事长.毕业于上智大学外国语学院,后取得美国杜克大学福库商学院MBA学位.芝加哥大学人文科学硕士学位.在麦肯锡公司从事新事业开拓战 ...
产品读书《麦肯锡工作法：个人竞争力提升50%的7堂课》
麦肯锡公司(McKinsey&Company)是由美国芝加哥大学商学院教授詹姆斯·麦肯锡(James O'McKinsey)于1926年在美国创建,现在麦肯锡公司已经成为全球最著名的管理咨询公 ...
麦肯锡三部曲_《学会提问：麦肯锡工作法》—读书笔记导图分享
本文字数4194,预计阅读时间3分钟. 阅读使人充实,分享使人愉悦.文章结尾附有思维导图,帮你梳理文中脉络精华.欢迎阅读,你离知识又近一步. 今天分享的书籍是<学会提问:麦肯锡工作法>. ...
读《学会提问：麦肯锡工作法》
本书的目标,是让读者意识到,学会提问的重要性.高质量的提问,甚至决定高质量的人生.书很薄.每章用浅显的语言快速阐述要点,其实对于介绍软技能的书籍,短篇幅足矣.关键是给读者植入一个idea,意识到无论是 ...
pdf 卖肯锡_麦肯锡工作法
很不错的工作习惯分享,慢慢养起来.很薄一本小书,希望对工作的调整有帮助,本书的内容非常实用,对我受益匪浅.值得推荐的一本好书,全面提升个人能力,适合专业人士,都没有来得及看,深入的评论谈不上,只能评价 ...

产品读书《人人都是产品经理 1.0》