目录
有效的交付过程，分成7个阶段：
1）确定正确的产品方向。
2）尽可能清晰详细地定义产品。
3）设计用户体验。
4）做一些基础的项目管理工作，不要太多也不要太少。
5）开始测试。
6）发布前建立一套衡量产品成败的指标。
7）正式发布产品。
一赢在使命和策略
使命：就是解决客户问题
策略：就是找到一种独特的方法来满足群体或细分市场的共同需求
1. 如何找到正确的需求
1）以客户为导向，而不是以竞争为导向
2）团队应该始终积极地去解决客户的问题，而不是紧盯竞争对手，被动地做出反应
3）立足客户，向外拓展
4）必须专注于解决真正的客户问题
5）不要只想着解决简单的问题，越困难的问题越值得去努力
6）确保很多客户都存在的大众问题
2. 如何构建卓越的使命
1）团队一定要有自己的使命
2）卓越的使命需要完全符合以下三点要求：能够唤起人们的兴趣、提供言之有物且能指明方向的原则、适合印在T恤上
3）需要一个能够反映代表性产品或服务的使命，而不是一个面面俱到的使命
3. 如何制订正确的策略
1）策略是指在竞争对手的压力下，利用公司独特的优势来争取目标用户的粗略计划
2）阐明三件事：客户、公司和竞争
3）讨论，获得大家认同与支持
二 赢在产品定义
产品定义过程主要分10步：
1）撰写新闻稿
- 新闻稿：一篇向市场宣布将要推出新产品的通告
- 六大要素：产品命名、发布时间、目标客户、解决了什么问题、如何解决、CEO的公开赞辞
2）创建并不断更新FAQ文档
- FAQ好处：节省回邮件时间，有价值资源
3）绘制线框图或流程图
- 流程图：准确解释用户工作流和系统交互
- 线框图：具象化产品各个环节的用户体验和用于汇报
4）撰写产品单页或10分钟的演示文稿
包含的5+1个要素
- 产品名称
- 目标客户 + 数量有多少
- 解决了什么问题 + 对目标客户有多大价值
- 解决方案 + 类似产品，为什么在长时间内无法模仿
- 何时交付 + 哪些里程碑
- 团队背景（仅针对VC）
最佳演示方式：
- 首先讲用户现状；
- 再延展五大要素，迅速讲完要点；
- 刨根问底。
5）在FAQ中添加API文档
- API文档说明团队如何与外部协作，明确系统边界
6）撰写功能规格文档
功能规格文档包括以下9个内容块：
- 1. 简介（使命和策略）
- 2. 目标与非目标
- 3. 用例或用户场景
- 4. 原型图或线框图
- 5. API
- 6. 负载规划
- 7. 依赖
- 8. FAQ和开放问题
- 9. 关键事件
7）要求设计团队和工程团队主管参与产品评审
- 找出边界情况并得到团队认可
- 寻找边界情况或者极端情况，确保工程和用户体验团队认可产品规划
8）找客户测试产品概念
- 客户测试、测试团队、单元测试
- 找一批现存的或潜在的客户，向他们介绍产品设想和原型，并听取反馈
- 焦点小组、试售、路线图演示
9）命名、定价以及预测收益
产品定价的三个基本方法：
- 按成本定价
- 按价值定价
- 对比定价
构建一个非常简洁的收益模型：
- 1. 估算买家总体市场规模。
- 2. 预估市场规模的增速。
- 3. 估算目标市场占总体市场的比率：估算针对细分市场占总体市场的比率；估算可触及的国家的市场规模占总体的比率；
- 4. 估算通过市场推广能触碰到的用户规模= 预估的市场预算 / 关键词的千人印象成本
- 5. 预估触碰产品的人中会有多少转化成产品用户
- 6. 找到其他新用户增长渠道并加入到模型
- 7. 产品定价 * 每个时期增长的用户数 = 收益
10）向管理层汇报
建议花点时间预售产品，”过路式“预售
向位高权重的人汇报产品方案时
-
确保你了解产品的所有信息。
-
他们想了解什么你就说什么。
-
了解并实践“综述单页”法。
三 赢在用户体验
1. 了解各种不同的设计角色
1）用户体验（UX）
- 关注用户如何完成任务以及该如何优化向用户展现信息的方式。
- 流程图、原型图
2）信息架构（IA）
- 研究该如何在用户界面中呈现
3）用户界面（UI）
- 关注单个页面或屏幕的设计，是用户体验的组成部分。
4）视觉设计（VisD）
- 通过一种既赏心锐目、夺人眼球又清晰明了的方式来展示内容。
5）用户体验研究（UXR）
- 专注于研究用户是如何看待你的产品的。
6）角色模型（Persona）
- 评估设计框架
2. 了解如何评估设计
6个用户体验问题：
1）该用户界面要求用户完成的最重要的任务是什么？
- 必须完成的；
- 要求主要角色完成的；
- 清晰地阐述业务目标以及他们之间的优先级；
- 面对一个新的设计时，先问自己三个问题：
1、谁是最重要的用户？
2、这类用户必须完成的最重要的任务是什么？
3、这个任务在用户界面中是最重要且最简洁的部分吗？
2）这是最简单的解决方案吗？
-
着眼于可用性的优化；
-
简化、隐藏、附加；
3）信息是否组织得当？
按收益能力排序；
遵循条件：
- 最重要的客户类型最关注的信息应该最突出。
- 信息的排列方式应该像报纸文章那样从标题到摘要一一排列。
- 信息应该尽可能个性化且实时，也应在合理的前提下尽可能详细。
- 最常用的控件出现在最容易找到的地方。
4）设计是否易用且一目了然？
可理解、可发现性
解决可发现性问题的三种常用方法：
- 定位：信息优先级从左上角向右下角递减
- 视觉设计
- 惯例：可用性测试、Google Analytics监控工具、部署A/B对比实验
5）标准是否一致？
-
惯例
6）能否减少用户点击次数？
- 默认设置；
- 减少键盘与鼠标之间的来回切换次数
3. 了解如何与设计师沟通
1）以用户的口吻说话
2）以提问的方式建立共识
3）反复讲述业务目标，如果有些目标相互冲突，则反复讲述它们之间的相对优先级；
- 帮助设计师了解他必须解决的问题是什么？
- 避免设置主观目标也能帮助你的团队。
4）用数据说话
5）提供一些竞争对手或类似体验中运作良好的案例
4. 学习如何借助图画进行沟通
灰度线框图、视觉稿、红线标注版、可点击原型
绘制线框图的基本原则：
- 1）只制作用户界面中相关部分的原型。
- 2）总是使用完整的、经过适当编辑的文本。
- 3）控制花在视觉设计上的时间。
- 4）使用灰度色，不要使用其他颜色。
- 5）预期你的线框图会发生很大改动。
- 6）当心视觉花招。
四 赢在项目管理
做好三项低成本工作，让你知道产品是否可以按时交互
1. 创建一张简单的计划表并持续维护。
1）包含任务列表和每个任务的工程评估量
2）如何拿到评估量
- 工程经理提供评估量
- 表面上接受评估结果，将任务分解
- 认识到你的权力
- 只跟踪剩余时间，只跟踪完成任务所剩余时间
- 要求不考虑余量的评估
- 每周一次在团队会议上评估各任务的剩余时间
2. 跟踪Bug，观察燃尽图，计算实现零Bug率的日期
1）Bug燃尽图是一张反映你的Bug数量随时间变化情况的图表
2）Bug下降比率，或曲线斜率，被称作发现 / 修复率
3. 谨慎管理你的依赖
将风险最小化的关键技术：
1）如果去除它也可以运转，那就去除它。少做少错。
2）如果内部能构建，那就内部构建。
3）如果必须添加一个依赖，那就趁早添加。风险最高的问题放在最前面去解决。
4）如果必须添加一些依赖，那就依靠它上一个已构建的版本。
5）如果交付得早，被依赖伤害的可能性就小。早点交付能降低风险。
五 赢在测试
对产品质量有着重大影响的8个主要步骤：
1. 坚持测试驱动开发
简要描述测试驱动开发的过程
- 1）将代码分成多个片段，每个片段负责执行一些简单的操作，片段称为单元
- 2）在写方法之前，先写一个单元测试
- 3）写方法
- 4）构建时，自动执行单元测试
2. 围绕优秀的测试主管组建测试团队
- 1）找到Bug的最佳策略就是雇用或者任命一位测试主管
- 2）减少妥协，追求完美
- 3）把测试和工程团队融合得很好
- 4）雇佣测试人员时所面临的特有问题
- 5）降低标准雇佣测试人员并聘请管理者去管理他们，或者按高标准雇佣外包团队
3. 亲自评审测试计划和测试用例
1）检查测试用例是否包含下列描述性要素
- 1、领域：哪部分被测试
- 2、严重性：BUG级别
- 3、前置条件：测试前必须做的事情
- 4、需执行的任务：多步骤
- 5、后置条件：任务执行完毕后所处的状态
2）时间不够，只执行高严重性的测试用例
3）评审测试用例，关注以下三块内容
- 1、用户体验
- 2、安全和隐私
- 3、依赖
4. 自动化测试
5. 虔诚地推行内部使用
1）欲买狗食，必先尝之
2）最佳实践
- 1、计划一次内部试用发布
- 2、使其他试用者能够方便地提交Bug报告
- 3、软件发布后应继续进行内部试用
- 4、让进行内部试用成为企业核心价值观
6. 开展找虫运动
有助于获得成功的四件事：
- 1）设立奖金，提供物质激励
- 2）在项目计划中增加找虫总动员这样一个关键事件
- 3）将找虫总动员排进你的开发和测试日程表中
- 4）感谢每一个Bug
7. 勤勉且有条理地处理Bug
三个步骤处理好Bug
1）基于频率、严重性和解决成本对Bug进行分级
- 1、频率：Bug出现的频繁度
- 2、严重性：Bug对用户体验的伤害有多大
- 3、修复成本
2）每天与开发主管和测试主管碰一次，评审新增的Bug
- 1、确定通用的Bug评判标准
- 2、先处理最严重的Bug
- 3、限定会议时长
- 4、只围绕频率、严重性和修复成本来讨论
- 5、讨论每个Bug的时间不要超过一分钟
3）不断施加压力以减少新的阻碍发布的Bug出现
- 调整Bug的评判标准
8. 任命可信测试者以构建最后一道防线
1）可信测试者：
- 在保密协议的约束下，在产品发布前使用产品内部试用版的用户。
2）最佳实践
- 1、让企业用户签署保密协议并提供正确的联系方式，保密协议保证你有权在产品中使用来自客户的改进建议
- 2、制作粗略的新手指南文档，其中包括已知问题的列表
- 3、创建一个包含整个工程团队的邮件组，工程团队应该尽可能接近用户
- 4、让这些用户使用和工程师同样版本的试用产品
- 5、调研可信测试者
- 6、当产品更新时通知可信测试者们
以新用户的方式来使用整个产品
1）抵达特性完成阶段后删掉所有数据和账号然后从零开始使用软件；
2）抵达编码完成阶段后再这样操作一次。
六 赢在量化
1. 优秀的量化指标应具备的5个关键特点：
1）测量成本低廉；
2）测量可靠且可重复检验；
3）能频繁地测量，最好能实时测量；
4）团队能够根据它做出明智的改变；
5）专注于客户
-
a）购买转化率反映客户的体验状况；
-
b）尽可能测量客户体验的末端；
2. “无法测量的东西也就无法提升。”——美国管理学大师爱德华兹•戴明
3.零Bug到达日期反映进度
4.三类发布后需要跟踪的关键指标：
1）目标进度：说明目标的完成进度
- 指标：“7天活跃用户数”、利润、注册量、下载量、安装量
- 应该：具体、可量化、可到达、合理、具备时效性
- 方法：精确增量表达法
2）经营绩效：说明产品的问题在哪里，如何提升用户体验
- 指标：从点击购买按钮到付款成功的转化率、用户参与度、7天活跃用户平均7天发帖量、7天活跃用户平均停留时间等
- 不推荐指标：：总是在增长的指标，虚荣指标。
- 避免虚荣指标方法：衡量应用中改动带来的影响，改动前和改动后横向对比测试。
3）系统性能：说明产品实时健康度
- 目标指标：99.9%平均延时、每秒请求数、并发用户数、每秒下单数、其他基于时间的指标
- 正常变化或Ⅰ型误差、异常变化或Ⅱ型误差，可以忽略正常误差或正常波动，标准误差
七 赢在发布
确保发布质量的主要的发布步骤：
1. 对改动说不
- 建立一个“发布后第一时间”修改的需求清单
- 代码移动
- 回归Bug
- 发布分支
2. 开启作战室
- 每日例会，不禁止与会者争论问题，解决问题
3. 营造紧迫的气氛
4. 核查发布清单
5. 撰写博文
6. 发布软件
7. 亲自验证软件
8. 应对发布带来的各种影响
五项发布后需要做的事情：
- 1）应对回滚：出现问题，回滚软件；只要成功回滚，发布就还没有失败；
- 2）处理产品危机
- 3）演示产品
- 4）应对媒体
- 5）庆祝发布
危机应对“剧本”：
0 ~ 5分钟
- 1. 不要惊慌
- 2. 检查这是不是一起突发事件并评估影响范围
- 3. 确定这个问题不止在你这里出现
- 4. 发起电话会议
- 5. 打开一个Bug
- 6. 知会危机扩大邮件组成员
5 ~ 30分钟
- 1. 问：“我们能回滚吗？”
- 2. 推迟任何公关计划
- 3. 知会相关方
- 4. 知会社区
- 5. 保持Bug的更新
- 6. 寻找并引入专家协助团队解决问题
- 7. 知会管理层
31分钟及以后
- 1. 定期发送状态更新，当有人请求时也可马上发送
- 2. 不要把客户晾在一边
- 3. 继续解决问题
- 4. 确保满足从事问题解决的人们的需求
- 5. 建立轮班制度，不要让一个开发者持续工作24小时
- 6. 采用变通或应急方案
收尾以及撰写事故调查报告
- 1. 检查修复情况
- 2. 发布博客对外发布危机
- 3. 在团队路线图中增加任务项并把他们的进展同步给老板或投资人
- 4. 撰写事故调查报告
八 胜在团队
1. 组建团队
1）团队组成
项目集经理、产品经理、项目经理、工程经理
2）如果雇佣
1. 雇佣比你聪明的人
2. 雇佣懂得自己不是来当老板的人
3. 雇佣表达清晰、言之有物的人
4. 雇佣用数据说话的人
5. 雇佣充满活力的人
2. 收购公司
1）知识产权
- 技术、内容和专利
2）人才
- 关键人才、好的雇员、多余人才
3）客户群
4）防御性
5）收购的陷进和最佳实践
- 1. 计划将你团队的部分人员调入他们团队
- 2. 计划整合产品
- 3. 了解之前所有的交易和负债
3. 与远程团队合作
- 1）不要租用工程师，应该组件一支工程师团队
- 2）充分沟通
- 3）尽量不要外包设计和PM角色
- 4）重视文化差异
- 5）构建清晰的需求
- 6）忍受时差
- 7）委任得力的主管
- 8）大量出差，或者完全不出差
- 9）与远程团队共饮
4. 加入新团队
- 1）弄清楚扮演的角色
- 2）下好第一步棋
九 胜在技术
需要了解的四个基本元素
1. Server 服务器
三层架构：展现层、业务逻辑、数据
2. Service 服务
面向服务的架构（SOA）
3. Speed 速度
封装、缓存
4. Scaling 扩容
虚拟IP、跨服务器存储数据、NoSQL、最终一致性、索引
5. 正确询问技术问题
十 胜在沟通
1 当不是必须要开会时，学会用邮件替代效率低下的会议
工作中有很多的事情，其实根本不必开会，一封好的邮件有时候可以替代好几场效率低下的会议。既然邮件如此重要，那么问题来了，产品经理要如何写好一封邮件？Chris在书中提到了以下几点：
写好邮件
1）清晰、简要
2）将想表达的最重要的事情放在文章开头
3）使用精确增量表达法
- 格式1：将某个变量增加或减少XXX（差值），即从XXX（开始值）增加或减少到XXX（结束值）。
- 格式2：在XXX（开始时间）到XXX（结束时间）这XXX（总持续时间）时间内，将某个变量增加或减少XXX（差值），即从XXX（开始值）到XXX（结束值）。
4）分点阐释原因：将逻辑依据从视觉上划分成多个点进行阐述
5）设法用建议取代质疑
6）考虑受众的感受
2 当不得不开会时，你需要学会有效应对五种不同类型的会议
1）团队会议
- 频率：一周一次，每次30-60分钟，提前发布议事日程，工程团队参加；
- 目的：促使团队坚守使命，并就当前一些悬而未决的问题达成共识；
- 切记：团队会议开比不开好，哪怕这个会议超级简短，因为它使得团队有机会以一种不同的方式聚集在一起，它还提供了喘息的时间。
2）站会
站会往往快捷、高效，因为每个人离开了他们的电脑，并没有那么舒服地站着，因此会议不得不尽快开完。每人汇报三件事：
- 昨天做了什么
- 今天要做什么
- 遇到的问题
开发主管就项目状态做30秒剪报
3）1对1会谈
- 适合主管们坦率地进行交流并公开问题
- 小而专注
- 每周或每两周安排与所有主管开一轮1对1的会议
4）产品 / 工程设计 / 用户体验评审会
有大老板参加的大规模会议
- 产品评审会：
目标：让老板们认可你的产品方向，提供给你反馈，或让他们知道你的最新进展
时间控制在30分钟内
-
用户体验评审会：
准备产品原型图
- 工程评审会：
目标：赋予开发主管权力，收集周围经验最丰富的工程师的专业反馈，以及尽量少花时间在演示上。
要求：提前审读材料
5）头脑风暴会
目标：收集尽可能多的想法
遵循4个基本规则：
1. 不要在头脑风暴过程中批评他人的想法
2. 说“是的，嗯......”
3. 通过结构化来促进讨论
4. 在头脑风暴结束时明确告知大家头脑风暴结束了
3. 当需要你来组织时，学会如何组织好会议
开会的三大目的：解决问题、收集信息、传递信息
四个最佳实践：
1）会后立即发出主题纪要
2）允许改变开会的目的
3）拒绝在团队会议中发泄负面情绪，但允许在1对1会议中发泄
4）使用鱼骨图等辅助工具解决问题
4. 当需要演示时，学会如何做好一场演示
1）将演示时间控制在15分钟内
即便你幸运地被安排了1个小时或更长的时间，也一定记住对于一贯忙碌的高管来说，每个会议他们只有15分钟专注于你所讲的内容。30分钟内完成一次陈述一般遵循如下时间线：
- 第0-5分钟：等待，似乎每个会议都有5分钟左右的延迟
- 第5-15分钟：进行演示
- 第15-25分钟：讨论、答疑
- 第25-30分钟：重述结论和重要反馈，并就后续计划达成共识
2）永远传达且只传达一个信息
每次会议只传递一个信息
- 试图传递两个信息可能会导致彼此混淆；
- 在讨论过程中，你的脑海中会有两个想法左右互博，兼顾两个信息的传递会让你难以掌控会议；
- 你只有15分钟进行演示，你没有时间传递更多的信息。
3）讲故事
故事有代入感，讲故事可以帮你实现五大效果：
- 将创意与个人生活关联起来，从而是听众产生代入感。
- 让观众跟着你的节奏走。
- 提供了一个人们都能理解的具体的例子。
- 描述了你将要解决的问题。
- 描述了你的解决方案将如何提升用户的生活品质。
4）制作“综述单页”
综述单页包含了你所要演示的关键因素，通常是演示文稿的第一页幻灯片，它应该包含四大块内容：
- 你想讨论的东西是什么(避免缩写词和新名词)
- 机会在哪里(将演示的核心数据压缩成1到2个重要数据点，必须会用数据说话)
- 提供的解决方案（用清爽的文字来阐述解决方案）
- 成本和实施时间表（承诺）
5）重点演示用户体验
重点演示原型图，为了从外部用户的角度来描述你的原型，请首先说明首要用户目标而非描述特性，然后你可以指出用户体验是如何满足这个目标的。
6）极度专注倾听
- 记录各种意见
- 将最重要的利益相关者的反馈记录下来
7）更多的演示技巧
- 一页幻灯片上不只是一副图加一句话时，把信息要点放在标题里。
- 没有模板，请使用蓝色背景，配上黄色和白色的字。
- 基本视觉设计原则：《写给大家看的设计书》。
- 不要担心留白。
- 不要使用“构件版本”这类字眼。
- 不要使用红色来代表除危险或糟糕之外的任何其他意思。
十一 胜在决策
1. 推后：“我们明天再完成”
- 1）将不属于绝对最小化可行特性集的所有特性放到V2。
- 2）检测方法：软件能否完成用于的基本任务？
2. 谈判：“行，再给你10分钟。”
- 1）谈判第一步：正确地认识到不管你是不是产品的负责人，你都不是老板。
- 2）一定要让团队成员参与决策，让他们与你共同拥有产品。
- 3）更好的团队决策制定过程是早期就让所有团队成员都参与进来。
- 4）将决策的理由透明，将决策的时间透明，将团队参与决策的途径透明。
- 5）回归正轨的方法：
1. 聚焦于促进；
2. 先寻求理解，再寻求被理解；
3. 如果已经有了侵向性的判断，不妨先说出来，然后让其他人继续发表观点。
- 6）财务谈判：讨价还价
3. 处理冲突
- 1）冲突管理
- 2）90%的情况下冲突的根源都是沟通不畅，9%是目标的方向错了，1%是人为原因。
- 3）两个关键且常见的背景元素：时间、假设。
- 4）确保项目名称在产品的整个生命周期中是一致的。
- 5）在白板上画图和列表能使事物变得清晰。
- 6）客观的交流是指只围绕软件、用户或问题进行讨论，而不把人牵扯进来。
- 7）三个客观化方法：
1. 不说“你”和“我”。
2. 聚焦在角色模型上，而不是人上。
3. 使用客观指标，可用性测试、决策矩阵（权重、优先级）。
十二 胜在从容
1. 如何平衡交付、质量和影响、团队三者的关系
在你设法完成交付过程的各个阶段以及本书所提到的各个具体事项时，切记这个平衡。
2. 如何应对随机情况
1）应对新的特性需求
- 创建简单的共享文档集中记录
2）应对来自管理层或投资人
- 要推迟发布版本X吗？
- 询问开发主管变动给工程造成的影响
- 从开发时间、系统设计、容量以及所依赖的部门等方面评估成本
- 在评审会议上认真倾听能避免某些随机情况
3）应对公司优先级变化
- 1. 弄清楚变化是不是真的
- 2. 更改产品的表达方式以迎合变化
- 3. 尽可能小地改动
- 4. 请求通融
- 5. 忍
3. 在交付过程中如何管理精力
1）为每个任务分配合理的时间
2）管理精力，而不是时间
3）管理精力的技巧是制定工作日程表
4）安排早上开始的一个半小时来攻坚最困难的任务
4. 如何把向上求援当成工具而非托词
向上求援的四种情况
- 1）你正设法为一个在某些方面比较愚蠢的管理层下达的命令辩护。
- 2）你真心不懂为什么你要做这些事情。
- 3）你不负责这个问题。
- 4）你需要与之打交道的高管不愿接见你。
5. 如何咽下狗屎三明治并生存下去
- 1）“这种事就是痛一会儿，然后就过去了。”
- 2）当收到一个三明治时，你应保持微笑，咽下三明治，然后继续前行。
- 3）生存下来才是重点。
十三 再度启航
1. 能交付的软件就是最好的软件。交付才是关键。
2. 对项目集经理来说有两个美好的时刻：拿到项目的时刻和项目交付的时刻。
3. 软件从来没有做完一说。
4. 只交付正确的软件。
5. 在软件行业中，过渡到一个新的项目通常是很有挑战性的。
十四 十大交付原则
1. 你不是来当老板的 —— 团队主管是仆人，他们存在的目的就是为了伺候工程团队。
2.从用户角度出发。
3. 用独特的方法解决很多人都有的大问题。
4 .坏的消息就是好的消息。—— 杰克 • 韦尔奇
5. 先寻求理解，再寻求被理解。—— 史蒂芬 • 柯维
6. 构建最简洁的可用的产品。
7. 交付手中有的，而非脑中想的。
8. 无法测量的东西也就无法提升。—— 开尔文勋爵
9. 你不可能做完所有工作，所以你应首先做那些只有你能做的工作。
10. 永远走在交付的康庄大道上。