导图社区 《人人都是产品经理2.0：写给泛产品经理》读书笔记
- 2.5k
- 242
- 29
- 举报
《人人都是产品经理2.0：写给泛产品经理》读书笔记
互联网产品经典入门书，主要面对-1到3岁的产品经理，详述产品的底层逻辑，产品经理领域的“知识地图”，产品经理的思维方式和做事方法。
编辑于2020-11-18 20:53:48
- 相似推荐
- 大纲
《人人都是产品经理2.0》笔记精华
第01 章 初识：大话产品经理／13
1.1 从一个小故事谈起／15
1.2 产品经理的前世今生／16
产品经理概念诞生
宝洁第一次提出了产品经理的概念。
上世纪二三十年代的现代企业时期
当时宝洁推出了一种佳美牌（Camay）香皂，但销售业绩较差。一个叫麦古利的年轻人在一次会议上提出：如果公司的销售经理把精力同时集中于Camay和Ivory（宝洁的一种老牌香皂）两款香皂，那么Camay的潜力就永远得不到充分发掘。幸运的麦古利赢得了宝洁高层的支持。之后，每一个宝洁品牌都当作一个独立的事业在经营，有专门的产品人员、销售人员给予支持，直接与其他宝洁品牌竞争。
麦古利
全世界第一位产品经理
负责Camay香皂的品牌建设、市场销售等几乎所有的事情。
项目经理和产品经理区别
项目经理：
靠做—执行+计划+控制—项目越做越小，越做越确定（立项和结项），是个封闭式命题
产品经理：
靠想—创造力—产品越做越大，是个开放式命题
1.3 思维方式与性格特点／22
思维方式
从学生到职场
从用户到产品经理
从现象到本质
性格加分项
热爱生活，保持好奇心
理想主义+完美主义
善于沟通，具有团队精神
抗压，自我激励，情绪调节
1.4 产品经理的日常／32
产品日常
第02 章 产品：关键词与分类／41
2.1 产品：解决某个问题的东西／43
【某个】
明确定位（所有人？明显定位不清）
【问题】用户、需求、场景
►用户： 这个问题是谁的问题。
更加多样
1）广义用户：
即产品干系人
2）用户类型多样且有主次之分
3）用户指“角色”，
而不是传统意义的“自然人”：例如客户和终端用户
►需求： 问题的核心是什么。
更加碎片
1）最浅需求
表象
“我要xxx功能”
2）第二层
背后目标和内部动机
2）最深一层
最后归结为人性（马斯洛需求层次理论、erg理论）
3）满足需求的三种方法：
提高现实：
自己努力、公司加薪、国家减税。
降低期望：
忆苦思甜、比下有余。
转移需求：
寻找新关注点、转移注意力。比如，和平年代用国与国对抗的体育赛事来激发集体主义、
►场景： 用户在什么情况，以及何时何地碰到这个问题。
更加多变
用户：
用户多样化、触达用户的渠道复杂化
需求：
更加丰富多样，也更加碎片
场景：
随时随地，在各种环境下
！移动时代对于产品经理的要求！
要掌握移动领域的基础知识：
比如安卓和iOS规范，新功能等
要熟悉各种更可利用的硬件：
比如重力感应器、NFC、加速感应器等
要理解互动方式的变化：
摇晃（摇一摇）、语音等
要明白产业链结构：
比如BSP硬件层[5] 和OS操作系统层、OS suite层（如MIUI等）及App层等都需要了解。最终产品需要考虑的适配情况复杂多变，比如iOS和安卓平台、多种屏幕分辨率、各种手机厂家对UI层面的改造，等等。
要懂得用简单逻辑完成任务：
流程能串行就不并行；减法+“单核思维”；强调任务简单，大任务拆分，单任务沉浸
要采用更灵活的实施过程：
敏捷开发
2.2 常见的产品分类维度／51
用户关系角度
1）单点：
计算器
1人使用
无网络效应
2）单边：
电话
1群人使用
可能有网络效应
3）多边：平台级产品
—群人使用
壁垒高，易垄断
双边：
三边：知乎（提问者+回答者+围观者）
用户需求角度
工具：
（初级产品形态）解决单点问题
优势：
容易启动，引流
劣势：
黏性弱
商业模式：
不强制留咨，采用个性化定制
内容：价值过滤器
商业模式：
逻辑思维：卖书/知乎：内容付费/微信：内容打赏等
发展原则：
有趣的表象+有价值的内核
社交：彼此互相吸引
优势：
用户黏性高
劣势：
变现困难
商业模式：
直播礼物/付费解锁用户信息/电商带货等
交易：做生意卖东西
形式：
电商/O2O
优势：
变现流
劣势：
业务流程复杂
平台：
复杂的综合体—“生态”
游戏：
打造平行世界
常见产品发展道路：
从一个小工具单点启动，快速获取用户，然后让这些用户彼此吸引，留下个人信息和用户关系，转社交，黏住他们；或者从内容转社交，建立互动探讨的机制；接着设法转交易，给他们卖一些符合调性的东西；继而引入各种合作方，成为平台……越往后想象空间越大。
用户类型角度
角度1：企业 vs 个人
角度2：群体 vs 个体
角度3：工作 vs 生活
角度4：男人 vs 女人
2B
► B2D ，
云储存、大数据等开发者服务，帮助开发者提升效率的基础设施。
► SaaS1.0，
通用管理型SaaS，是传统意义上的管理软件。
► B2B ，
垂直行业交易平台，是信息撮合+在线成交。
► SaaS2.0，
垂直行业 SaaS 工具+交易，是SaaS1.0和B2B的综合，2015年左右开始成为新趋势。
2C
产品形态角度
BS结构：
pc、h5
Browser-Server结构
CS结构：
客户端
Client-Server结构
软硬结合：
智能家居，手环，物联网
除了软件部分，还有硬件实体
大实体：
大型体系：汽车制造等产业链
有软硬件更有服务
一个APP功能形态选择——Native（Client模式）还是Web（Browser模式）更好呢？
►偏交互的用Native，偏浏览的用Web：
交互指复杂操作，包括输入、选择等，Web往往支持得不好。
►已稳定的用Native，试错中的用Web：
H5页面适配各种手机系统、浏览器简单，用来做低成本验证很方便。而已经固化的功能，用Native更节省手机本地资源，使用起来更流畅，而且因为不依赖网络，也会更稳定。
►访问硬件的用Native，信息展示的用Web：
硬件包括手机里的各种传感器等，Native的访问权限更高，安全性也更高。
►核心功能用Native，周边辅助用Web：
Native的工作量相对大，应该把时间多用在刀刃上。
►变化少的用Native，经常变的用Web：
比如电商的活动页面，经常需要变，做在Native应用里就会很被动。
行业角度
娱乐、金融、医疗健康、教育等
行业之下分类
►工具：
音频播放器、音乐制作软件。
►内容：
歌曲库，以及早年的百度MP3。
►社交：
音乐讨论社区。
►交易：
版权市场，以及供个人付费购买高品质音乐的产品，如QQ音乐。
►平台：
阿里音乐（阿里总是倾向于做整个生态）。
►游戏：
节奏大师、太鼓达人等。
盈利模式角度
卖货：
向前收费
包月付费，点播费，会员付费功能等
重点：货好
直接像用户要钱
卖人：
向后收费
广告发布、竞价排名、冠名赞助、企业会员等
重点：人多
2B的抽水模式，向企业单位或信息提供者收取费用
关键资源角度
►资本驱动 ，
对应着需要大笔资金做准入门槛的产品。比如金融行业的某些业务，没有足够多的钱，根本没法进场。再如拼价格战，补贴大战时，资金不够多的公司也会被迅速淘汰。
►技术驱动 ，
意味着拥有核心技术能力，成为别人无法模仿的壁垒。比如Google的搜索引擎算法。如今的人工智能领域，谁拥有最牛的算法、海量的数据、强大的计算能力，谁就能取得领先。
►产品体验 ，
产品本身要好，对互联网行业来说，就是用户体验很爽。比如很多社交应用，有漂亮的界面、流畅的交互、快速的响应、丰富的内容，用户用过之后会触发口碑传播，一传十，十传百。我们常说的“消费升级”，也要求产品本身升级。
►运营服务 ，
对应着需要很多“人肉”参与的产品，强调运营效率、服务体验等。比如在O2O类产品的早期市场争夺战中，大家都很强调“地推”，就是靠人海战术迅速获取商户、用户资源的手段，谁的人不够多、执行力不够强、速度不够快，谁就会被淘汰。
►垄断资源
，取决于获取资源的能力。拥有一座矿山、一个油田、一片土地，或者是专属经营权等。比如只有12306可以卖火车票，某某公司成为谁的独家合作伙伴等。
行业成熟度角度
初创期
爆发期
平台期
衰退期
第03 章 概念：提出与筛选／67
3.1 产品概念的提出／69
确定5个关键要素
核心用户
产品目标用户中最重要的用户是谁，表达为一个抽象的人群。
举个例子，校园社交App，目标用户是在校生，核心用户就是一批校花。
“洗粉”：
为讨好核心用户，而得罪其他不重要用户，即情愿选择让一部分人爱你爱得发疯，另一部分人恨你恨得要死，也不要让所有人都觉得你还OK。
刚性需求
Ta们碰到最痛的痛点是什么。
三个条件：真实、刚需、高频 。
真实：
辨别真伪
刚需：
强烈且不能忍受，例如停车—刚需是找到车位，弹性需求是省车费
高频：
发生频次
典型场景：
这些痛点最常出现在怎样的生活、工作情况下。
典型：有没有“唤起点”
唤起点：
在某种情景下、某时某刻，用户能想到，最好是能第一个想到你的产品。这个时刻就是产品的唤起点 。
产品概念：
用什么方案解决，用一个词、最多一句话概括你的解决方案。
举例：口碑网，大众点评
产品概念：
一个有餐厅列表、可以点评的网站。
竞争优势：
相对已有方案，有什么突出优势。
人无我有/人有我优
找到“竞争标的”
竞品分析
相似的产品→
只能带来一些功能层面上的优化，不会对产品方向带来什么新思路 。
能满足同样需求的不同产品（从表层到深层需求）→
所有消耗用户时间的产品
互联网/手机上的所有产品都是竞品，竞争的是用户仅有的那点 时间
3.2 概念提出的综合案例／76
智能长命锁/淘宝首页
用户分类方法
从目标用户中找到核心用户
全集—子集—MECE
（相互独立，完全穷尽）
角色划分：
适用于多边，买卖供应商、司机乘客、提问者/回答者/吃瓜者等
熟悉度划分：
适用于单边，新人、中间用户、专家（新老用户）
人口信息统计（年龄，职业，消费水平）：
信用卡级别，k12教育级别等，慎用
产品业务场景：
企业级服务（按融资阶段）；培训（按行业）
3.3 产品概念的筛选／82
筛选要素
【内部因素】能力
人：
团队是否与要做的事情匹配
财：
各种资本、资金的支持是不是到位
物：
行业资源与业务能力
【内部因素】意愿
使命感、愿景、价值观
使命
就是我们要解决一个什么问题，要做一件什么事情，比如“让天下没有难做的生意”；
愿景
是说我们希望成为什么，比如“让客户相会、工作和生活在阿里巴巴，并持续发展最少102年”；
价值观
就是我们认为什么是对的什么是错的。
【外部因素】价值
宏观：
行业天花板
潜在用户× 单用户可挖掘价值 = 行业天花板。
微观：身边人你需要这个产品吗
种子用户：
1）愿意配合
2）可以提供很多有价值的东西
3）可以忍受缺陷
4）可以成为义务推销员
受你要解决的那个问题困扰最深的一小群人
用户递进模型
潜在用户：
指向将来的想象空间与发展天花板（有闲暇时间可以代驾的司机，可以开顺风车的司机）；
目标用户：
指所有现在能跟产品发生关系的用户群体（专职司机+乘客）
核心用户：
指目标用户中最重要的那个群体（先搞定供给端：各城市出租车司机）
种子用户：
指核心用户中最早接触的那一小批用户，通常是一些具象的、我们认识的个体（嘀嘀打车：公司在机场摆摊时每天遇到的那几十个人）
【外部因素】成本
宏观：大环境
有一个模板，叫作PESTEL
►政治因素（Political）：
是指对组织经营活动具有实际与潜在影响的政治力量和有关的政策、规定等因素。
►经济因素（Economic）：
是指组织外部的经济结构、产业布局、资源状况、经济发展水平以及未来的经济走势等。
►社会因素（Social）：
是指组织所在社会中成员的历史发展、文化传统、价值观念、教育水平以及风俗习惯等因素。
►技术因素（Technological）：
不仅仅包括那些引起革命性变化的发明，也包括与企业生产有关的新技术、新工艺、新材料的出现，以及发展趋势、应用前景。
►环境因素（Environmental）：
一个组织的活动、产品或服务中能与环境发生相互作用的要素。
►法律因素（Legal）：
组织外部的法律、法规、司法状况和公民法律意识所组成的综合系统。
微观：行业环境
波特五力模型
►对于同行业内现有竞争者的能力，
其主要指标为市场成熟度和竞争激烈程度。对于不成熟的早期市场，竞争对手少，但用户教育成本高，要避免做“帮后来者教育用户”的事情，而竞争激烈时期，可以考虑的策略是往行业上游走。比如，几年前团购流行时上演了“千团大战”，你就可以考虑做团购网站的导航、做团购商品的供应商。
►潜在竞争者进入的能力，代表行业门槛高低。
一些依托“黑科技”创业的领域，门槛相对高，而商业模式创新则门槛相对低。
►替代品的替代能力，
对于这点，我们要保持对变化的敏感，与其被别人干掉，不如自己先拥抱变化。
►供应商的讨价还价能力，
其实是一个店大欺客的问题。如果你的上游供应商过于集中，就很可能对你强势，设法分散是个解决方案。
►购买者的讨价还价能力，
其实是一个客大欺店的问题。如果你只有一个客户，可想而知，他提任何条件，你都只能答应，所以也是要设法分摊风险。
第04 章 需求：采集与用户研究／97
4.1 需求采集方法的分类／99
直接采集与间接采集
直接采集：
一手需求
需求提出人是否是本人？
是原始需求，还是加工过的？
更加准确，但未经梳理，得出结论的效率低
间接采集：
二手需求
全员参与采集，
产品经理处理
说与做，定性与定量
说做不一致
定量数据发现 7月用户活跃降低5%，定性抽取6月活跃，但7越不活跃用户做访谈
是否在真实场景里
很多情况，做产品时是无法模拟的，需要培养“临场感”—亲自置身场景
是否和产品发生交互
新功能：
用户没用过，判断用户是否需要
1）用户以为自己需要，结果有了并不用
2）用户以为不需要，结果用了就离不开
解决方法
低成本验证
免费试用：
试吃，30天适用会员版，app核心功能h5化，不用下载也能用；
类似需求，
是否有别的产品和用户产生了互动，加以了解
旧功能优化：
用户用过，提出问题
采集方法：
Z字采集法
产品规划阶段：
听用户“定性地说”，确定产品方向（做什么）；随机抽样了40个用户做访谈，据此写出需求列表。
项目早期：
听用户“定量地说”，确定需求优先级（先做什么）；投放了20万份调查问卷，确定了需求优先级的排序。当然，这只是确定优先级的辅助手段，最终做什么，还是由产品经理决定。
项目实施过程：
看用户“定性地做”，确定要先实现的那几个需求应该怎么做；设计的同时完成可用性测试，其间陆续找了10个用户来验证。
上线后的优化阶段：
看用户“定量地做”，根据产品的用户使用情况做数据分析，不断地改进产品。
4.2 一些实用的采集方法／105
客服轮岗
用户批斗大会
百度搜索词联想
4.3 用户、需求的再理解／106
需求的三种深度
►第一种深度
观点和行为
表面能听到、能看到的东西，一般是通过用户怎么说、怎么做直接表现出来。如果只到这个层次，是做不好产品经理的。
►第二种深度
目标和动机
用户为什么这么说、这么做？如果能找到目标和动机，会稍微好一些。但相对第三层，这里还是要实在一些。比如，用户说希望开始每天健身、跑步，目标是减肥。再往深层挖，其价值观层面的需求可能是为了在朋友面前呈现出积极向上、健康的自己。
►第三种深度
人性和价值观
最底层的，最稳定的需求，人类社会诞生的千万年来，基本上没怎么变。如果能把需求挖掘到这个层次，就找到了产品最本质的用户价值。
如何应对战略需要？
（内部需求）
1）正面需求：
毕竟提出者都是广义用户，需要考虑他们的需求
2）判断主次
3）分清手段和目的
KPI是实现战略目的，商业价值的一种手段
用户：抽象到具象再到抽象
第一阶段，用户是抽象群体
在产品概念阶段，用户是假想的某一类人——目标用户、核心用户。（靠产品经验经历进行假设出来的）
第二阶段，用户是具象个体
1）根据具体角色，所处场景抽象出产品架构思维导图
2）根据该思维导图创建【用户故事】（“易停车app”思维架构中中开车的上班族”（人物角色）在“工作日上班”（需求场景）下的一个“用户故事”）
需求采集时，我们要去接触一个个真实的用户，见活人，听故事，找感觉，发现“用户故事”。
第三阶段，用户又是抽象群体 ：
【人物角色】—用户画像
整理采集到的需求时，把真实用户再合并特征，定义出“【人物角色】，并反向修正产品概念。
4.4 产品原则与初心／116
产品原则
是整个产品团队必须达成共识的准则，依赖于团队的价值观或者是产品的初心，相当于一个产品的宪法。
制定产品原则的前提
是一个产品做过需求采集且信息足够充分。
产品原则几要素
►目标用户分为哪几类，以及他们的优先级排序，整个团队必须达成共识。
►产品的市场切入点，最关键的用户需求场景是哪几个，一开始的最小可行产品MVP必须满足哪些。
►对一个社区而言，人和内容都很重要，到底哪个更重要？回答这个问题的共识是这个社区的产品原则。而且，往往对错都没有共识重要。有时候虽然是一条绕远的路，只要齐心协力说不定就走完了，就怕走走停停、不断争吵。
►一个产品，应该追求用户数量还是质量，追求流水还是追求利润？这些都是产品原则里面需要包含的内容。
第05 章 转化：需求分析与Y 模型／123
5.1 从问题到解决方案／125
需求分析—将问题转换为解决方案
5.2 Y 模型的基本概念／126
基本模型
核心价值观：
用心听，但不要照着做
发现更多用户目标：
我们没法创造需求，只能创造出用户没见过的解决方案，从而更好地满足需求。
抓住恒定人性：
1，2会变，但4会持久不变，定位要站在4的高度上
在成熟市场上寻找机会
微信中的“飞机大战”
单机—世界榜—好友榜（索要机会，邀请，赠送）
5.3 实战中如何深入浅出／136
深入：（1-2-4）如何挖掘人性
“攀梯术”：
主要出现在一对一深度访谈的场合，用来探究用户对产品功能/特性的态度背后的原因，也就是说，在产品属性（Product Attribute，A）与个人价值（Value，V）之间产生有意义的关联，从而知晓影响用户决策的因素。
基本手段：
通过一系列直接的探询式问句来洞察人性。典型的提问形式是“为什么那个东西对你来说很重要 ”和“那个东西对你意味着什么 ”
实操准备：
访谈前向用户说明
►回答没有对错，只需要表达自己的观点即可。
►如果过程中觉得有一些问题无法回答，可以直接说出来。
实操技巧
情景唤起：
通过让用户假想、回忆（使用产品的）情境，引起Ta的思考。
假设某物或某状态的缺失：
让用户思考，某物/状态如果缺失了会怎样。
反面攀梯：
用户无法说出做某事或想要某种感觉的原因时，可询问Ta不做某些事情或不想产生某种感觉的原因。
时间倒流对比：
让用户反思过去，并与现状对比。
重定向：
沉默或重述确认
用沉默或通过再次询问确认的方式来鼓励用户继续讲。
浅出：（4-2-3）如何设计功能
借力于用户
“糗事百科” —“提交→（活跃用户）审核→（普通用户看到）最新→（用户点赞量）推荐”的内容审核机制;
初期邀请注册
保证产品内容质量
向游戏学习
徽章、等级制：过往
经验、积分制：现在状态
排行榜：未来努力方向
等其他行业...
第06 章 功能：细化与打包／155
6.1 一个功能的DNA／157
功能描述列表
性价比 = 商业价值/成本（开发量）
商业价值判断
对某个功能判断价值的流程
►参照“产品原则”里“目标”部分的定义，明确当前产品最看重的指标是什么，可以是数字化的KPI，比如注册用户数达到10万，也可以是某些关键结果，比如“建立起线上自动化的专家入驻全流程”。如果有多个指标，则需要对这些指标加权合并[2] 。
►考察每个功能点实现后，对上述指标的帮助大不大。如果大，则这个功能的价值就大。因为每个产品不同时期的指标不同，所以评判各个功能价值的标准也各有差异。通常用半定量的方式来衡量，比如最简单的大、中、小，或者5.4.3 、2、1等评分标准。
广度：
潜在用户：
一个产品将来可能覆盖的用户群体；
单用户价值：
电商—客单价；游戏-APRPU；社交-用户活跃度度
潜在用户数 *单用户价值（大力推广阶段重点）
频度：
先利用高频低单价的需求抓用户
再用低频高单价的需求做利润
需求频次 *单次复杂度（产品瓶颈期重点）
强度：
不可替代：
早餐店卖包子——再做一个单品：馒头？豆浆——选择豆浆
紧急：
极个别的用户负面评论，但是引起大范围舆论；对手突然提高补贴力度等
持久：
3天活动？长期功能？
不可替代、紧急、持久（早期发展重点）
成本评估和性价比（初评）
成本：人天
性价比 = 商业价值/成本（开发量）
理论，性价比高，优先级高，但是，还要考虑功能分类和实际情况
功能分类：KANO模型
第一类：基础功能
第二类：亮点功能
亮点是忠诚度、口碑传播的基础。
第三类：期望功能
选择原则：先做性价比高的
第四类，无差别功能
用户不用；
为什么有这种功能：用来测试验证的，不做怎么知道用户不用
第五类，反向功能
用户不喜欢
比如：百度广告—为了满足商业需要—用户不喜欢，但是企业/广告商喜欢
6.2 功能打包，确定MVP／175
如何确定MVP？
尽可能多的放弃
不同功能类型的应对对策
►基础功能必做，要留足资源。
►在产品初创期，先实现个别低成本的亮点。
►对期望功能，先做性价比高的。
►无差别功能无须做，低成本验证出来即可。
►对反向功能，权衡各方利益后再决定。
考虑功能依赖关系
考虑功能相似性
考虑非功能需求
如何表达出MVP——产品架构图
《人人都是产品经理》架构图
当年天猫（淘宝商城）架构图
6.3 把需求和功能管起来／185
空间维度：功能列表
时间维度：需求流程
第07 章 执行：立项组队与研发生产／191
7.1 从“想清楚”到“做出来”／193
原型验证与NPS
（POC—产品概念测试）
产品立项前的验证：
验证用户需求是否准切
NPS：
净推荐值，是一种计量用户将会向其他人推荐某产品可能性的指数。
NPS =（推荐者数 – 批评者数）/总样本数×100%
►推荐者：
打分在9～10分之间，是具有狂热忠诚度的人，他们会继续使用产品并将其引荐给其他人，可以帮助产品成长。
►被动者：
打分在7～8分之间，总体满意但并不狂热，会用但不会传播，可能考虑其他竞争对手的产品。
►批评者：
打分在0～6分之间，使用后不满意，或者对你的产品没有忠诚度，可能有负面口碑，会阻碍产品成长。
NPS的得分值在50%以上就已经比较理想，如果达到70%～80%，则说明产品拥有一批忠实拥趸。
产品委员会与关键节点
产品委员会：
手握资源人，在每个关键节点一起参与产品会议
关键节点
1）概念筛选
根据各种背景信息，判断要不要对某个产品概念进行细化、展开。如果认为可行，就要启动全方位的需求采集工作。这是本书第03章讲的事情。
2）立项组队
对产品进行原型验证，评估需要投入多少研发生产资源，有多少风险及如何应对等。如果立项获批，就要启动项目、组队开干。这是本章前半部分的内容。
3）上线发布
产品完成开发后，千万不要因为怕浪费而仓促上线。这时还是要先用真实产品找种子用户验证，如果没有通过验证，就不要上线，以免浪费更多的客服、销售、运营维护资源。
4）营销推广
为提升用户量，上线之后马上就开始推广，也是常见的错误。应该先花一段时间考察用户是否活跃，是否会再次使用产品。当这些指标达到预期后，才可以大力推广，否则就是浪费资源。
7.2 立项：搞定各种资源／196
7.2.1 关于人：
团队、组织
权力：
强力组织，比如国家政府，用“枪杆子”保证“绳之以法”。
利益：
商业组织，比如公司企业，用“钱袋子”支撑“诱之以利”。
共识：
松散组织，比如公益社团，用“笔杆子”达成“晓之以理、动之以情”。
7.2.2 关于物：
政策、资金等
用MRD来获取资源
MRD：
Why：为什么要做这个产品
What：产品MVP包含哪些功能及要做什么—demo
How：项目计划及风险对策等
Market Requirements Document，市场需求文档，除了描述问题，解释为什么要做这个产品，还要给出解决方案。这个文档比较像产品规划和商业计划书（BP，Business Plan），是写给资源拥有方看的。
PRD：
Product Requirements Document，产品需求文档，是在项目过程中写给开发、测试、设计师看的，仔细描述产品功能要怎么做。
7.3 组队：聊聊初创团队／199
7.3.1如何快速知己知彼
► 为什么要来这个团队？
► 对一年后收获的底线预期。
► 个人对团队的帮助。
► 自己能做什么？
► 自己想做什么？
► 项目失败最可能的原因是什么？
上面这些话题看上去有些虚，但对提升早期核心团队的战斗力非常关键，问题的具体答案是什么其实不重要，重要的是共同参与。
7.3.2 小团队的沟通协作
“奥卡姆剃刀”原理
该原理称“如无必要，勿增实体”，即“简单有效原理”。
能解决需求的最简单方法
适合的才是最好的
7.3.3 小团队与大公司的区别
7.3.4 借助第三方力量做产品
众包：分享、座谈、咨询、外包
7.4 研发生产时，我们做什么／206
产品经理视角的项目流程
►立项环节：
在这个环节，产品经理要组建团队、设法获取各种资源，以及确定项目计划。
►需求环节：
这个环节主要做的是功能细化，也可以叫需求开发。产品经理要写PRD产品需求文档和UC用例，并和设计师配合做Demo原型。在这个过程中，可能会经历多次评审会议，还要和技术人员一起确定功能细节。
►开发环节：
同时，产品经理已经开始下一个迭代版本的项目前期准备。
►测试环节：
开发推进的同时，测试工程师要编写TC测试用例，通过TC评审，并且在系统可用的第一时间做冒烟测试[7] 。此环节中，产品经理要组织功能评审，在第一时间把新产品展示给所有的项目干系人，以确保做出来的东西是大家想要的。
►发布环节：
测试工作完成后，运维人员要组织发布评审，执行预发布、发布的动作，并且在发布完成后让产品经理到真实的线上环境去验证，以确保产品符合预期。
额外三件事的把控
文档管理：
输入/输出文档，模版，工具，如何让同步更新
流程管理：
每个流程的评审是否可删减，高效
敏捷方法：
日常沟通方法，监控进度
7.4.1 产品经理要不要懂技术
测试
功能测试
单元测试：
最小单元代码自测—开发
冒烟测试：
基本功能测试—测试
回归测试：
修改旧代码后，对相关功能重新测试以确保没有新错误引入
性能测试
压力测试
验收测试：产品经理
第08 章 成长：规划与迭代／219
8.1 好产品步步为营／221
8.2 规划：只看最短和最长／223
最短：
1-3月/最长：3-5年，10年后
产品规划
业务规划
► 一句话的业务定位：
这句话通常也会表现为产品的Slogan，比如小红书的“全世界的好东西”、微信的“一个生活方式”，以及陌陌的“总有新奇在身边”。
►一个业务模型：
包括这个业务内部分为哪些模块，彼此之间有什么关系，与产业链中的各个角色怎么配合，如何平衡各方的利益，自己如何赚钱等。
►三五个业务关键点：
接下来的一段时间，主攻的几个业务难点是什么。比如“入驻平台的卖家数在1个月内达到1.0.0 ”“3个月内把服务扩展到所有省会城市”或“半年内谈妥ABC几个战略合作伙伴”。
8.2.1 从规划向上看战略
长期规划=战略
8.2.2 通过提问把别人干翻
在大公司争取资源
1. 每次对方讲完PPT。
为什么要做这件事，不做的话会“死人”吗？
2. 看到对方从总体KPI分解出的目标。
这是用户的目标还是我们的目标，是不是老板的目标，老板换了怎么办？
3. 看到对方从用户需求出发，引用了一个观点。
这个用户有普遍性吗，能代表多少人，这类用户对我们的优先级是什么？
4. 看到对方引用一个数据来证明自己的观点。
数据来源是什么，什么时候获取的，是怎么采样的？
5. 看到对方的规划写得太实在，都是项目方案。
为什么没有看到这个产品线的大图，5年后这个产品是什么样子，你实现整个图景的路径是什么？
6. 看到对方写得太虚，都是画大饼。
未来的确很美好，但怎么实现？现在如果只做一件事，最重要的是什么？你打算怎么做？
7. 看到一个运营方案需要资金预算。
你能给出量化指标吗，ROI是多少，这笔钱真的能用在最看重的用户身上吗，会不会被不投钱就已经很活跃的用户花掉？
8. 看到要做的事情太多。
这么多事情，你打算组建多少人的团队，他们都需要什么能力，怎么分工？如果只给你两个人，怎么办？
9. 看到要做的东西真的很吸引人。
实现路上会碰到的最大问题是什么，你打算怎么解决？需要大家怎么配合你，你打算如何说服各个部门都来帮你？
10. 看到具体的项目。
你这些项目需要占用的开发资源有多少，如何给技术同学带来成长和成就感？
8.2.3 提升规划能力的实践
►让产品团队每个人做一份自己产品的规划，规划周期可以限定为3个月。重点是每个月要拿出1天时间，每个人轮流宣讲，听众是团队其他人。
►每个人讲完以后，听众轮流说一点“好”与一点“可以更好”（其实就是“不好”的委婉说法），不许重复。可以针对规划本身，也可以针对PPT制作、演讲技巧等。
►主讲人自己在白板上记录大家的发言，等所有人发言完毕后统一进行回复和讨论，会后优化产品规划PPT以供下次讨论。
一般半天时间（4小时计）可以讨论3个人的规划，假设是一个6个人的团队，一天时间正好全部讨论完。最终每份规划可以得到5点“好”与5点“可以更好”，全组就能得到30点“好”与30点“可以更好”。相信3到6个月下来，每个人的产品规划、PPT演示能力都会有显著的提升。
8.3 迭代：再理解敏捷／230
8.3.1 敏捷价值观、宣言与原则
敏捷的5个价值观：
沟通、简单、反馈、勇气、谦逊
敏捷宣言：
（目标结果为导向）
一、人与人的交互，重于过程和工具。
二、可用的软件，重于详细的文档。
三、与客户协作，重于合同谈判。
四、随时应对变化，重于循规蹈矩。
敏捷12条原则：
一、对于我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
二、拥抱变化，欢迎需求的变化，即使在开发后期。
三、敏捷过程能够驾驭变化，保持客户的竞争优势。
四、经常交付可以工作的软件，从几个星期到几个月，时间尺度越短越好。
五、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
六、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
七、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
八、可以工作的软件是进度的主要度量标准[4] 。
九、敏捷过程提倡可持续开发。
十、对卓越技术与良好设计的不断追求将有助于提高敏捷性。
十一、简单——尽可能减少工作量的艺术至关重要，最好的架构、需求和设计都源自自我组织的团队。
十二、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
8.3.2 敏捷项目管理的实践
Scrum关键概念的理解。
►团队角色
PO（Product Owner）
通常是产品经理，要对各种利益相关方负责。
SM（Scrum Master）
充当教练的角色，一般由对流程、方法论比较熟悉的人来担任，不建议这个角色和PO重叠。
►关键产出物
Product Backlog
指比较长期的产品任务表，即第06章提到的功能列表。
Sprint Backlog
在Scrum里指当前这个迭代里面的任务点。
Burndown Chart
是燃尽图，用来监控任务是不是在按期推进。
►重要的会议
首先是每个迭代的计划会 ，
经常和需求评审会 合并，主要目的是明确任务，以及评审这个迭代里需要做的功能。
每天的站立会议 ，
是重要的信息同步手段。
功能评审会
用来评估做出来的东西是不是想要的。
回顾会
目的是为了过程改进，因为Scrum和敏捷最核心的思想就是不断优化，以优化出一个最适合当前团队的方法论。
►日常管理工具
看板
是一个非常重要的实用工具，很多公司的办公区里都会有，在硅谷创新公司里也被广泛应用。比如，有一块写着当前迭代关键信息的白板，或者有一面用来粘贴任务卡片和便利贴的玻璃墙，如图8-2所示。
实例：创业公司的简化项目流程
角色的简化
流程的简化
►立项会议：
确定项目目的——为什么、做什么（时间控制在半小时以内）。
►需求评审：
确定项目怎么做（对相对较小的项目，可以和立项会议合并，总体时间控制在2小时以内）。
►功能评审：
简单地讲，就是在测试环境下演示一下产品，以确定做出来的是不是团队要的（1小时左右搞定）。
►发布上线：
确定产品是不是用户想要的，以及用户还要什么。通过获取用户反馈来让产品的优化形成一个螺旋上升的闭环。
►需求变更 ：
这在项目过程中不可避免，一开始可以简化成某个人拍板，决定是否接受变更。
►日常需求：
即零散、随机出现的小需求。开始只掌握一点，即所有需求必须经过产品经理，运营等角色不能直接找开发，确保产品经理知道所有的需求信息，以便统筹安排。
文档的简化：
PRD+设计稿+代码
看板实践
任务卡片
任务描述
工作评估
deadline
优先级
►左上角标：
表示此卡片的任务延期。少量的任务延期是正常的，也是允许的，但要进行监控。如果发现项目里有很多人出现大幅延期，则说明计划制订不合理，需要及时调整；如果只是个别人出现大幅延期，则更可能是个人问题，需要延期人自己加班赶上进度。团队要达成共识，让别人等、浪费别人时间是可耻的。
►右上角标：
表示突发任务。少量的突发任务也是正常且允许的，但如果有大量突发任务，则说明缺乏经验、计划不足，或者有“外力”经常干扰项目进程。
►左下角标：
表示持续任务，可以一直贴在看板的Doing（正在做的）任务列表里。比如，对产品经理来说，“处理用户反馈”就算一个持续任务。而非持续任务都应该从看板的Doing列表及早转移到Done（已完成的）任务列表。
►右下角标：
未定义的备用标记。团队在做项目的同时会不断优化项目流程，如有需要可以临时定义这个新的角标。
看板应用
其横坐标是Todo（未开始的任务列表）、Doing和Done，纵坐标是各种团队角色。当时，团队每天下班前，也就是18:00开站立会议，大约持续15分钟，会上每个人只说三句话。第一句“今天做了什么”，说某个任务的同时指着看板上对应的任务卡片，如果任务完成，则把卡片从Doing一列拿到Done一列，如果延期了就涂上左上角标；第二句“明天打算做什么”，同时指着Todo一列的相应任务卡片，并把它拿到Doing一列；第三句“碰到什么困难、需要什么帮助”，与大家一起讨论，但不展开，具体的细节可以约着会后私聊。
第09 章 运营：先验证再扩张／249
9.1 产品与运营的关系／251
9.1.3 给运营提需求的模板
9.2 运营工作的分类／256
9.3 大运营的其他职责／268
9.4 产品的生命周期／272
第10 章 案例：商业模式、创新与行业／277
10.1 聊聊商业模式／279
商业模式画布
►客户细分：
我们的目标用户是谁，其中最重要的又是谁。
►价值主张：
我们可以帮用户创造什么额外的价值。这里所说的价值必须是现有产品服务没有的，比如更高的性能、更低的价格、更小的风险。
►客户关系：
用户与我们、用户与用户之间的互动模式是什么，比如专人一对一服务、用户自助使用、用户彼此共建社区，等等。
►渠道通路：
如何与用户建立起高效联系，拉近现实与心理的距离。
►关键业务：
我们需要做什么产品来解决用户问题，创造价值。
►核心资源：
我们做这件事，和别人相比，有什么特别的优势因素。
►重要合作：
我们需要和哪些上下游、周边伙伴协作，以及如何协作。
►收入来源：
如何从用户那里获得收入，以维持业务可持续发展。
►成本结构：
做这件事，都在哪些环节需要花钱。
10.1.1 对比：商业、业务、盈利模式
►商业模式：
完整讲述了我们创造了什么价值，为什么有存在的意义，对应图10-1的全部。
►业务模式：
在解决方案层面做的是什么事，对应图10-1左上区域的关键业务、核心资源、重要合作。
►盈利模式：
怎么赚钱，怎么养活自己的团队，对应图10-1下方区域的成本结构与收入来源[1] 。
10.2 创新那点事儿／284
10.3 行业案例分析／294