人人都是产品经理（入行版）

自序

互联网产品设计的五个层次——战略、范围、结构、框架、表现

用什么产品，解决什么人的什么问题？

写在正文之前

为什么会有这本书

做产品的要有想法

第1章 写给1-3岁的产品经理

1.1 为什么要做产品经理

坏产品：无处不在的危险

Don't Make me Think[7]一书中说，网页的设计“不要让用户思考

好产品：从垃圾桶到洗手间

不同作用的垃圾桶只有颜色区分

桶身正中区分了可回收与不可回收的标志，并且下方附有一行文字说明

桶身有了文字说明，把专家才能看懂的标志换成普通人一眼就能看明白的图案

产品功能的持续改进过程是以“让用户更加省心”为目标

1.2 产品经理是什么

产品究竟是什么

产品的狭义概念：被生产出的物品。产品的广义概念：可以满足人们需求的载体。

产品就是用来解决某个问题的东西

产品可以是有形的实物，也可以是无形的服务

产品就是要同时解决用户的问题和公司的问题

产品经理概念的进化

第一，行业形态不同：成熟行业VS新兴行业。

第二，产品形态与成本结构不同：实物VS虚拟物品。

第三，生命周期不同：几年VS几个月。

第四，盈利模式不同，单一卖产品赚钱VS多元盈利。

第五，用户心态不同：花钱买VS免费用。

管理的能力，其实就是“在资源不足的情况下把事情做成”的能力

1.3 我真的想做，怎么入行

产品经理的招聘广告

用户会去想怎么用这个产品才能带给自己更大的好处、产生更大的效用

产品经理则习惯于绕过表象看问题的本质，思考怎么设计这个产品才能更好地平衡用户目标与商业目标

1.4 一个产品经理的-1到3岁

业内有句话叫“产品经理是CEO的学前班

专业就是找了一个特定的领域来练习思考的能力而已

把触角渗透到产品周边的各个团队，从原来的有事才去找人帮忙，转变为尽量去了解周边团队都在做什么并施加影响

对于一款产品来说，早期的决策无比重要

找到产品的“灵魂”很重要

第2章 一个需求的奋斗史

用户是需求之源

需求采集人人有责

听用户的但不要照着做

把用户需求转化为产品需求

判断需求的性价比

资源总是有限的

少做就是多做

2.1 用户研究：从用户中来到用户中去

以用户为中心的思想”，但也“不要试图满足所有的用户

2.1.1　用户是需求之源

需求的本质是什么？

人类为什么有需求

理想与现实的差距

减少甚至消除这个差距

产生了需求

需求的本质就是“问题

用户VS客户

用户是User，有时也叫作终端用户（End User），是使用产品的人；而客户是Customer，是购买产品、为产品付钱的人。

用户”这个词来代表“广义用户”，它指的是所有和产品有关的人，或者叫产品干系人，除了终端用户、各种客户，还包括你所在的公司里与这款产品有关的老板、销售人员、服务人员、技术人员等

以用户为中心的思想

中小型公司需求的主要来源不是终端用户，而是老板

尽可能帮助老板明确问题和需求的价值

在老板决定方向时提出参考建议，或协助他实现目标

“以用户为中心的思想”和“以老板为中心的行动

不要试图满足所有用户

优先满足哪些用户需要和产品的商业目标结合起来考虑

2.1.2　你真的了解用户吗

了解真正的用户

试着描述用户

聊聊用户研究

“说”表现了目标和观点，”做”反映了行为

用户“怎么说”和“怎么做”经常是不一致的

定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实

2.2 需求采集：产品源头的大生产运动

需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，最后进入下一步的需求分析阶段

2.2.1　定性地说：用户访谈

用户访谈的常见问题与对策

第一，“说”和“做”不一致的问题。

一个经典的索尼游戏机的故事

索尼找了一些用户，问他们喜欢黄色的还是黑色的游戏机，结果发现说喜欢黄色的用户比较多

有部分用户说喜欢黄色却带走了黑色的游戏机。

第二，样本少，以偏概全的问题。

第三，用户过于强势，把我们往沟里带。

第四，我们过于强势，把用户往沟里带。

定量地说：调查问卷

《长尾理论》里说到“沉默的大多数”：站出来的总是少数用户，而且往往是非典型的用户，不能保证其代表了目标用户的想法；而“骑墙的大多数”是指大多数人是没有明确观点的，尤其在一个匿名的网络环境下，最早表态的那几个人的观点常常引导了群体的观点，随机的初始值决定了结果

第一，样本用户与想了解的目标用户存在偏差。

第二，样本过少的问题。

第三，问卷内容的细节问题。

2.2.2　定性地做：可用性测试

可用性测试的常见问题与对策

第一，如果可用性测试做得太晚（比如在产品马上要上线的时候），这时发现问题也于事无补了。

第二，总觉得可用性测试很专业，所以干脆不做。

第三，明确是测试产品，而不是测试用户

第四，测试过程中，组织者该做的和不该做的。

产品改版的一次冒险

2007年底豆瓣为了庆祝注册用户过100万的改版

2009年百度贴吧的改版

2013年手机QQ向微信看齐的改版

都因为用户的反对声音太大而不得不道歉，甚至有的产品不得不重新改回原版

对于改版，除了“可用性测试”要在足够早的时候做，发布后还有一些方法可以改进。

首先，先从部分次级页面改起

其次，新旧版本并存一段时间，并允许用户自由选择

再次，小面积试验，选择一小批测试用户放出新版本，监测效果、做用户调研

最后，傍上一个用户已经习惯的风格

2.2.3　定量地做：数据分析

数据分析的常见问题与对策

第一，过于学术，沉迷于“科学研究”。

第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。

对一个人群，人们的身高用平均数来衡量是有意义的，我们知道身高属于典型的正态分布，中间多两边少

而对人们的收入，就不能用平均值来衡量了

总能找到数据来证明自己已有的想法，并

尽量不要“为了迎合一个观点而去找数据

第三，平时不烧香，临时抱佛脚。

日志分析的商业价值

用户研究的成本真的很高

小公司都能省则省

2.2.4　需求采集人人有责

尽可能多地采集

需求采集，并不是产品设计之前的工作，而是一个贯穿产品生命周期的过程

几个有特点的需求采集方法

现场调查

AB测试

日记研究

卡片分类法

自己提需求

2.3 需求分析：听用户的但不要照着做

2.3.1　明确我们存在的价值

用户跟福特要一匹更快的马，福特却给了用户一辆车。

一个是用户需求，一个是产品需求

用户需求VS产品需求

用户需求：用户自以为的需求，并且经常被用户表达为解决方案

产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案

需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程

需求分析是先“树叶—树枝—树干”，再“树干—树枝—树叶”的过程

是一个“分—总—分”的过程

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西

销售人员经常说：“用户为想要的东西买单，而不是需要的

其实是“用户为自己提出的解决方案买单，而不是我们的解决方案

为什么不直接做用户要我们做的呢？

其实这是短期利益和长期利益的权衡

如果是一锤子买卖，卖出以后又不用负责售后，那么不妨用户要什么就给他什么，这样用户掏钱最爽快。这种情况下追求的就是短期利益

我们的产品通常都是希望用户长期使用的，并且后续的服务也是我们来做，所以为了长期利益，我们就有必要找到用户的真实需求，然后给他真正合适的产品

满足需求的三种方式

需求来源于理想与现实的差距，那么减小这个差距就有三种方法：

►提高现实。我们最常用的方法，去开发某种产品，但也是最笨的方法。

►降低理想。“打预防针”“丑话说在前头”

►转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了

满足用户的需求，不一定要做新产品或者新功能

也谈创造需求

我们无法创造需求，但是可以创造性地满足用户的需求。

苹果公司的乔布斯，可以说是创造需求的大师

2.3.2　给需求做一次“DNA检测”

把用户需求转化为产品需求

举个例子，如果用户需求是“删除数据之前需要我确认，以免误删”，转化分析以后，我们给出的产品需求可能是“数据回收站：删除的数据进入回收站，如果是误删，用户可以去回收站找回数据”。

确定需求的基本属性

需求种类知多少

分类：可以分为新增功能、功能改进、体验提升、Bug修复、内部需求等。

还包括了很多非功能需求

通常来说“产品功能需求+产品非功能需求=产品需求

层次：把需求分成基础、扩展（期望需求）、增值（兴奋需求）三层，理论依据参见KANO模型

分析需求的商业价值

一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的

重要性、紧急度、持续时间3个指标来衡量

重要性：可以参考时间管理里“重要与紧急”的概念

重要性又可细分为满足后“一般”到“非常高兴”；未实现时“略感遗憾”到“非常懊恼

紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为短期的、对产品长期影响不大的问题；或者是局部的、对大多数用户没有影响的问题

持续时间：需求是有生命周期的。迎合过年过节的运营活动需求的周期就比较短

商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判

通俗的理解，“商业价值”就是这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助

初评需求的实现难度

评估每个需求所需要的开发工程师工作量来表征其实现难度

以团队里的瓶颈资源为评估基准

初评时常用的方法是“三点估算法”，即评估出最乐观的工作量、最悲观的工作量、最可能的工作量

“工作量=（最乐观+最悲观+最可能）/3”

“工作量=（最乐观+最悲观+最可能×4）/6”

工期和工作量有很大的区别。比如生一个小孩需要1个女人9个月的时间，工作量可以说“9人月

工期都只能是9个月

判断需求的性价比

性价比=商业价值÷实现难度（简化为开发量）

2.4 需求筛选：活下来的永远是少数

需求PK

2.4.1　永远忘不掉的那场战争

更早的时候，阿里巴巴是按照产品线划分部门的

2008年年初

变成了按职能线划分团队

产品中心

研发中心

质控中心

两种组织结构，呈现“一攻一守”的不同面貌

在创业期，公司需要全速发展，必然是产品线结构，产品经理带头往前冲

当公司里有多个产品慢慢成熟之后，就可以用职能线来更充分地利用资源

实现资源共享

促进不同产品团队之间的互相学习

让员工的个人能力得到更多的提升

准备出发：把需求打个包

战场：产品会议

先回顾上一次产品会议

武器：商业需求文档

Business Requirement Document，简称BRD

BRD怎么写，都包含哪些内容

项目背景：“我们在哪里？”即为什么要做这个项目，这个项目解决什么问题，可以列出一些数据说明项目的必要性

商业价值：“我们去哪里？”这

功能需求描述：“我们怎么去？”即做哪些事情来达到目标

搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西

非功能需求描述

资源评估

风险和对策

2.4.2　别灰心，少做就是多做

淘宝为了防止一些没人打理的商品始终停留在搜索结果中，稀释了有效信息，所有商品会隔一段时间后自动下架，不能再被搜索到，这时就需要用户重新将商品上架

见山是山、见山不是山、见山还是山

第一阶段的无知

第三阶段的“少做

第二阶段“多做

用100%的质量去实现75%的数量

吸引用户的往往只是功能模块中的一两个点，我们一开始只要让这一两个闪光点拥有100%的质量其实就够了，这样留给用户的是对升级的期待

如果反过来，功能铺得很开，但每个点都不爽，反而喧宾夺主，把闪光的地方给掩埋了

最爽就是“四两拨千斤”

某跨国日化公司，肥皂生产线上存在包装时可能漏包肥皂的问题。

肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推出去

再说某乡镇肥皂企业也遇到类似问题

拿了一台电扇到生产线的末端对着传送带猛吹，那些没有装填肥皂的肥皂盒由于重量轻就都被风吹下去了

有一句话说得好：内部（指偏技术）的大改动往往是外部（指偏商业）的小改动，反之亦然，所以我们应该在动手前先找找有没有成本低、收效大的解决方案。

尽可能多地放弃

白鸦[55]写过的一段例子，说的是如果不放弃，最终会被自己折腾死

他是这么说的：比如，一个最简单的“评论”功能：既然可以发评论，那么……是不是需要改评论？删评论？发的权限是否要管理员设置？那么改的权限呢？删的权限呢？是否可以引用别人的评论？

“少做就是多做”，阿里巴巴的马云也说过。

2.5 需求管理：心急吃不了热豆腐

2.5.1　一个需求的生老病死

需求状态：通常有“待讨论”“暂缓”“拒绝”“需求中”“开发中”“已完成”几个状态，可按照实际情况有所增减

还可以增加“测试中”。

负责PD：

从头到尾跟进，他是这个需求的主人。

开发工程师：

项目名称：

发布时间：

备注：

2.5.2　需求管理的附加值

2.5.3　和需求一起奋斗

第3章 项目的坎坷一生

3.1 从产品到项目

产品是解决某个问题的东西，而项目是一个过程

做产品VS做项目

第一，从生命周期的角度来看。

做产品”的生命周期相对较长

做项目”有特定的目标，所以生命周期较短

第二，从具体要做的事情来看

在“做产品”的过程中，会有更多的探索行为

“做项目”在开始时就已经有明确的目标，更注重计划与控制

第三，从产出物的角度来看。

产品是可以批量生产，并且提供给大量用户使用的，所以产出物最好能相对通用

项目只进行一次，意味着每次需求都是定制的、个性化的，通常为了满足这些特定的需求，产出物也比较个性化。

产品经理VS项目经理

产品经理——靠想

做正确的事

项目经理——靠做

把事情做正确

产品经理是内部驱动，项目经理是外部驱动。

为什么让产品经理管项目

3.2 立项：一切从Kick Off开始

“Kick Off”是足球比赛开球的意思，现在被广泛指代开始做某事

3.3 需求开发：关键的青春期，又见需求

3.3.1　真的要写很多文档

BRD：Business Requirements Document，商业需求文档

MRD：Market Requirements Document，市场需求文档

PRD：Product Requirements Document，产品需求文档

FSD：Functional Specifications Document，功能详细说明

概要设计与详细设计

3.3.2　需求活在项目中

作为重要监控点的需求评审

项目中，最重要的三种角色就是PD、开发人员、测试人员，所以这些项目往往有三次评审——需求评审、设计评审、测试评审。

3.5 山寨级项目管理

文档管理、流程管理、敏捷方法。 字→表→图

3.5.1　文档只是手段

PD常用的文档模板

3.5.2　流程也是手段

流程的本质目的

流程是产品在“快”和“稳”两大要求之间的平衡器。

经常做的事情可以用流程这种形式固化、传承

项目VS流程 项目只做一次，所以追求可行解即可；流程要反复做，所以要追求最优解. 结婚对新人是项目，对婚庆公司是流程；装修对个人是项目，对装修公司是流程。 中国是农耕文明，年复一年，数千年的积累，可能更擅长流程管理。

3.5.3　敏捷更是手段

3.6　我所亲历的特色项目

做项目通常要在保证品质的前提下，在项目时间、项目资源、项目范围三点上做平衡。

第4章 我的产品我的团队

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

4.1.1　产品之大

从时间和空间两个角度来说。 时间是指产品的生命周期 空间是指做产品需要考虑的三个大方面：商业、产品、技术

不同时期的产品与市场、用户都有其特点，而产品的最佳状态就是在不同时期让三者完美配合。 找工作的时候必须调查清楚自己的职位在公司里是不是最受重视的，是不是强势方，这很重要！

4.1.2　设计之大

1号线、2号线 1号线地铁口：3级台阶，防洪；有转弯，节省空调成本。

战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点。 范围层：明确“做多少”。 结构层：考虑产品的各个部分互相之间是什么关系。业务逻辑图 框架层：界面设计 表现层：视觉设计和内容的优化

对于错误的理解，我们要做到“用户没有错，所有的错都是设计的错”。

4.1.3　团队之大

目标不同导致手段不同。 修高速公路最难的是拆迁问题。

4.2　游走于商业与技术之间

4.2.1　心思缜密的规划师

4.2.2　激情四射的设计师

4.2.3　“阴险狡诈”的运营师

把“功能转化为卖点”。先要告诉用户产品“有什么用”，用户才有兴趣了解“怎么用”。

4.3　商业团队，冲锋陷阵

我们觉得某样东西虚只是因为对它不熟悉而已。

4.3.1　好产品需要市场化

产品版本细分策略：“炮灰”策略 水平营销来卖包子：市场、产品（中药包子、皇城包子、西式包子）

4.3.2　我们还能做什么

用户花几千块钱买了两串数字——账号和密码。到头来大家发现，还是要结合传统，搞点实在的东西。（光盘与包装）

4.4　技术团队，坚强后盾

技术痴迷者、实用主义者 清楚自己需要什么、公司需要什么、产品团队需要什么。 被规则管理而不是被人管理 当事情由人来控制的时候，总给人一种不安全、不稳定的感觉，而有流程可依的时候，心里就比较踏实。

4.5　容易被遗忘的角落

法务、财务、行政 最好的资源：老板 让老板做问答题、让老板做选择题、让老板做判断题

4.6　大家好才是真的好

4.6.1　所谓团队文化

如果一个团队里的每个人每天都能开开心心地工作，就是很好的团队文化。 老板老板着脸，总监总监视人，总裁总裁人

4.6.2　无授权领导

管理VS领导 管理的对象是行为，领导的对象是思维；

如何让团队更开心 《别做正常的傻瓜》 大中之小”不如“小中之大”：送礼的时候，在一个不太昂贵的礼物类别中选择一个比较贵的礼物，要比在一个比较昂贵的礼物类别里选一个比较便宜的礼物效果更好。 比如送一条1000块钱的围巾效果好于送一件1200块钱的衣服

第5章 别让灵魂跟不上脚步

5.1 触及产品的灵魂

做产品经理、PD，或者说产品设计师都有三层境界：

第一层，产品帮助我们

第二层，产品与我们互相帮助、共同提高

第三层，我们帮助产品

有些产品设计师经常脱离产品的战略来讨论设计的优劣，不去了解设计目的就评价用户体验的好坏，我认为这样是很没道理的。某些让你觉得很糟糕的设计，也许是设计者为了特定的目的故意为之，你得试着站在设计者角度多想一分钟，多问几个为什么。

以价值观为根基

产品的灵魂或者企业的灵魂是什么，探到最深处，是由价值观（Value）决定的

培养大局观

如果你发现做一个改变只有好处没有坏处，那很可能是你站得低看得近，或者说你考虑到的“全部”只是更大系统里的一部分，“坏处”会在其他部分体现出来

经常与高手讨论，更容易培养自己的大局观，可以用更广阔的视野看待问题

5.2　可行性分析三部曲

市场扫描：PEST分析，分别分析产品在政治法律环境（PoliticalFactor）、经济人口环境（Economic Factor）、社会文化环境（Social Factor）、技术环境（Technological Factor）四个方面所面临的机会和威胁。 竞争对手分析：以经典的$APPEALS分析法作为指导方针 自我剖析：SWOT分析，源自麦肯锡咨询

5.2.2　我们去哪儿

5.2.3　我们怎么去

5.2.4　低头走路，抬头看天

靠谱的会议 《罗伯特议事规则》 在会议结束后，尽量在24小时内发出会议总结邮件，收件人是所有与会者，抄送给所有与会者的老板，让老板们看到手下干的活儿，也让与会者知道老板们会关注。

5.3　KPI

人生很长，不要以百米冲刺的方式跑马拉松。 现实中很多不合理的KPI。知道这个KPI背后的目的，如果能绕过KPI直接达成目的，相信理智的老板是会做出让步的。

第6章 产品经理的自我修养

6.1　爱生活，才会爱产品

门把手与灯的开关联动 或 钥匙与灯的开关联动 不按照设计者的本意使用产品

6.2　有理想，就不会变咸鱼

你存在于世的价值就是世界有你和没你的区别 改变世界不一定要亲手去做，可以“尽可能地去了解世界，然后告诉更多的人“

就业保障会降低一个人的竞争力，职业保障可以提高竞争力

6.3　会思考，活到老学到老

问问题的时候，不妨自己先想想，这个问题有明确答案吗？ 如果有，那不妨去问Google、百度，不用问人；如果没有，那更不要去找别人要答案，而是用交流的心态和别人讨论方法吧。

6.4　能沟通，在什么山头唱什么歌

6.5　产品经理主义

“Don’t Make Me Think”原则，把用户需要的信息以最直接的形式展现出来。 解决问题的通用思路：为了什么？做什么事、解决什么人的什么问题？何时做？谁来做？效果如何？