《人人都是产品经理》 学习笔记1

说明： 本系列博文都是从《人人都是产品经理》（作者苏杰）读后摘取的部分。剩下内容都是自己的心得体会。      

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

产品究竟是什么？

  产品就是用来解决某个问题的东西。可以是有形的实物，也可以是无形的服务。

  在企业里，产品就是要同时解决用户的问题和公司的问题，一个都不能少。

产品经理这个职位中有“经理”二字，似乎多少就有点管理的味道。

管理大师德鲁克说： 管理并不是公司的管理层，如总裁、总监、经理们才需要掌握的技能，而是每个人必备的生存技能，只是每个人可以掌握的资源不同，所以需要管理的对象也不同。

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

研究几十家公司的产品经理招聘广告。我一直觉得把研究结果做成一份漂亮的调研报告，而后去应聘产品经理是个很靠谱的事。

哪些技能之外的基本修养对一个出色的产品经理很重要呢？ 爱生活，有理想，会思考，能沟通

                                             产品经理的生态系统

                                                    第二章     一个需求的奋斗史

2.1  从用户中来到用户中去

    2.1.1  用户是需求之源

人类为什么有需求？

理想与现实的差距，那么人类会很自然地产生“减少甚至消除这个差距“的愿望，这就产生了需求

理解用户，是产品经理最重要的素质之一

不同的用户有重要程度之分，我们必须、也只能有所偏重

“相比您的需求，我们可能更重视您的用户的需求”---优先满足产品使用者的需求，而不是付钱者的需求。

以用户为中心的思想

创业公司的老板一般兼任部分产品经理职责，这时产品经理绝对不能一开始就想着“造反“，而是要尽可能帮助老板明确问题和需求的价值。

以用户为中心的思想，以老板为中心的行动

不要试图满足所有用户

试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪，谁都不满意的四不像。

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

    2.1.2  你真正了解用户吗

体会真正的用户

用户是五花八门的，必须得真刀真枪地去研究他们

试着描述用户

聊聊用户研究

怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。

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

第一轮 ，听用户 定性地说，确定产品方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。

第二轮，听用户 定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级，先做什么? 投放了20万份调查问卷，确定了血气优先级的排序。

第三轮， 看用户 定性地做，要先做的那几个需求，应该怎么做？ 一边设计，一边陆续找了10个用户来验证，做可用性测试。

第四轮，看用户 定量地做，根据产品的用户使用情况做数据分析，不断改进产品。

当然，根据具体情况采取简化的方案。

2.2  需求采集的大生产运动

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

                                                  常用的需求采集方法

  2.2.1  定性地说：用户访谈

用户访谈的常见问题和策略

第一   说 和 做 不一致的问题

索尼游戏机

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

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

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

  2.2.2  定量地说：调查问卷

调查问卷的常见问题与对策

第一 ，样本的偏差，即样本与想了解的目标用户群里出现偏差

第二 样本过少的问题

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

  2.2.3  定性地做：可用性测试

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

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

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

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

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

产品改版的一次冒险

改版在客观上会挑战用户的现有习惯，所以必须慎之又慎。

2.2.4  定量地做：数据分析

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

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

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

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

日志分析的商业价值

  2.2.5  需求采集人人有责

生孩子与养孩子

一手需求    ---》生孩子

二手需求    ---》养孩子

单项需求卡片

尽可能多地采集

几个有特点的需求采集方法（大家灵活应用）：

1  现场调查

2  AB测试

3  日记研究

4  卡片分类法

5  自己提需求

2.3  听用户的但不要照着做

  2.3.1  明确我们存在的价值

用户需求 VS  产品需求

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

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

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

求的过程。

真实情况是，需求分析是“首先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程，所以说完整的需求分析是一个“分-总- 分”的过程。一方面不能漏掉提炼用户需求的这个过程，目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，
后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解成树枝、树叶。

满足需求的三种方式

提高现实

降低理想

转移需求

  2.3.2  给需求做一次DNA检测

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

确定需求的基本属性

需求种类知多少

分析需求的商业价值

初评需求的实现难度

绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。怎么办，先做性价比高的！！！

性价比=商业价值/实现难度（开发量）                          （  开发量：需求的开发工作量，表征实现难度）

2.4  能活下来的永远是少数

  2.4.1  永远忘不掉的那场战争

准备出发：把需求打个包

做项目，终极目标就是：多快好省，即范围大、时间短、品质高、资源省。

第一  “需求打包"最好打包类似的功能点。  第二，需求依赖，功能互相之间有依赖关系。第三，需求的粒度大小问题

战场：产品会议 

武器：商业需求文档 BRD

BRD包含：项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策

下面通过一个BRD实例，给大家一个直观的认识：

  2.4.2  别灰心，少做就是多做

情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子

2.5  心急吃不了热豆腐

一个需求的生老病死

一个需求的DNA  表格2-9  P104

下图：  需求的生老病死

一个需求的奋斗史

                                                         第三章  项目的坎坷一生

3.1 从产品到项目

做产品 VS  做项目

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

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

第三  从产出物的角度来看

产品经理  VS  项目经理

产品经理--靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润

项目经理--靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标

为什么让产品经理管项目

3.2 一切从kick off开始

帅哥美女，我们需要你

别忘了最初的约定

沟通从头开始

不可或缺的誓师大会

项目背景

项目意义、目的与目标

需求、功能点概述

项目组织架构

项目计划

任何时候都要做到心中有“树”

做项目的本质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡

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

3.3.1  真的要写很多文档

BRD: Business Requirement Document, 商业需求文档

MRD： Market Requirement Document,市场需求文档

PRD:  Produment Requirement Document，产品需求文档

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

产品需求设计，PRD

学一点UML：类图、用例图、状态图

用例文档 ， UC

再学一点UML： 时序图、活动图及其他

   

Demo也要我们做吗

  

概要设计与详细设计

3.3.2 需求活在项目中

评审：一个头两个大

需求评审

设计评审

测试评审

再看需求的生老病死

项目开始之前

项目中的需求阶段

项目中的需求阶段之后

3.4  成长，一步一个脚印 

开发阶段，旁观者说
开发阶段的工作内容：设计--》设计评审--》编码--》单元测试

测试阶段，大家一起上

测试阶段的工作内容：TC编码--》TC评审--》冒烟测试--》功能评审--》测试

Bug眼中的项目

那一夜，项目发布

发布阶段的工作内容：发布评审--》预发布--》发布--》线上验证

以终为始，项目小结

“人人都是产品经理”的写作周报

怕什么来什么，只能拥抱变化

3.5 山寨级项目管理   

3.5.1 文档只是手段

建立自己的文档规范

模板的作用知多少

多人协作与版本管理

wiki  SVN

玩转office足矣

3.5.2  流程也是手段

项目 VS .流程

流程的本质目的   ---》团队的核心竞争力

那么多评审，可以省吗

产品会议   kick off会议   需求评审   设计评审   TC评审 功能评审 发布评审

3.5.3  敏捷更是手段

从本书到实践

有计划，更要“拥抱变化”

迭代周期内尽量不加任务

集中工作，小步快跑

持续细化需求，强调测试

项目中的敏捷沟通

与外包团队的敏捷尝试

3.6 物竞天择适者生存

3.6.1 亲经历过的特色项目

如何做好“老板项目”

做项目通常要在保证品质的前提下，在时间要求T、人财务话费R、项目范围Q三点上做平衡

秘密行动，封闭开发

开发外包，项目外包

3.6.2 一路坎坷，你我同行

三边六拍

几个项目的成败

一次只有7天的战斗

第四章  我的产品，我的团队

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

4.1.1 产品之大

时间之大：产品生命周期

创新者    早期追随者     早期主流用户    晚期主流用户    落伍者

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

商业

产品

技术

4.1.2 设计之大

产品设计的五个层次

设计的“现实与浪漫”

4.1.3 团队之大

想当年，一个比一个猛

从几个人到一家公司

接口人存在的价值

我身边的矩阵型组织

4.2 游走于商业与技术之间

4.2.1 心思缜密的规划师

从概念设计到信息架构

PD的出身及其优劣势

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 领导

产品经理应该是管理者吗

当管理者的优点：管理岗位有利于拥有话语权；管理岗位利于获取信息；管理岗位利于争取资源；

当管理者的缺点：管理岗位有很多行政工作；管理岗位脱离群众；

让优秀的产品经理在专业路线上拥有高级别：对于产品、业务的决策有充分的话语权；可以参与管理会议的业务讨论；可以拥有临时的资源支配权，并给管理层提供同事的考核建议；但不负责管理者的行政工作，而是继续和同事打成一片，用产品证明自己。

如何让团队更开心

送礼9条

跟着我走，有肉吃

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

5.1 触及产品的灵魂

以价值观为根基

战略是怎么炼成的

培养大局观

5.2 可行性分析三部曲

5.2.1 我们在哪儿

从市场扫描开始  PEST

真实的竞争对手分析

深刻的自我剖析  SWOT

5.2.2我们去哪儿

宏观上的用户需求

物流平台的案例

5.2.3我们怎么去

一次真实的产品预研

5.3 做吧，准备出发

5.3.1 敢问路在何方

产品路标规划

一切尽在掌握

5.3.2 低头走路，抬头看天

我们急需靠谱的会议：  大会决定小事，小会决定大事（大小指参会人数）   ；  民主集中制原则“所有人提供意见，少数人讨                          论，一个人拍板”

仰望战略会议：   高层定向，中层分解，基层执行

5.4 KPI，KPI，KPI

SMART，并不smart

多个目标间的权衡

达摩克利斯之剑

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

6.1 爱生活，才会爱产品

我总是跟门过不去

乱谈餐馆的菜单

用户创意无限

6.2 有理想，就不会变成咸鱼

成功在自己手中

个人品牌建设

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

个人名片设计实例

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

我的理想之路

6.3 会思考，活到老学到老

学校里没教的东西

第一  教知识不教思维

第二  教解题不教选题

第三  教努力不教取巧

第四  教受教不教施教

只有方法，没有答案

好好学习，天天向上

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

我的沟通理念

理论上严格意义的“充分沟通"是不存在的

有效的沟通最终是“合”，而不是谁战胜谁，每次沟通都是一个大家互相帮忙，共同提高对世界的认识的好机会。

职场中的点对点沟通

IM：成本最低，适合不紧急不重要的沟通

电话：成本适中，适合紧急不重要的沟通

面谈：成本最高，适合紧急且重要的沟通

E-mail: 成本适中，适合重要不紧急的沟通

职场中的群体沟通

IM群

电话会议或视频会议

会议

群体邮件

“土老板”破冰必杀技

6.5 产品经理主义

好电影是怎么做出来的

产品经理看“春晚”

无可救药的职业病

解决问题的通用思路

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

做某件事情“为了什么”是大前提，对应本书的第5章战略

“做什么事，解决什么人的什么问题？” 是事前需要考虑的，其中”什么问题“和”什么人”对应本书第2章讲到的用户需求和目标用户，“做什么事”则是从用户需求转化而来的产品需求。

“何时做、谁来做”是事中关注的重点，对应本书的第3、4章，项目和团队，着重讲的是计划、控制与执行

“效果如何”是事后需要讨论的，全书的各章里提到的总结、反馈一类的观点，都是对这个问题的回答，想清楚了才能持续改进，不断提高。

计划一次旅行，用思维导图

开一个网店要做哪些事，用流程图

举办一场婚礼，用甘特图

修改这本书里的图片，用列表

人人都是产品经理