「启示录」读书笔记之流程
评估产品机会
做产品前我们必须要先评估这个产品的市场是怎么样的，如果是一个特别小的市场，那就赶紧转方向吧。因此评估产品需要有一定的流程，不能全凭感觉。不要较真，jobs当年也评估过。
评估产品的机会基于2个目的：
- 淘汰馊主意，避免浪费时间和金钱。
- 挑选合适的产品机会，团结团队，理解团队，整合资源。
产品评估可以从如下十点进行：
- 产品要解决什么问题？（产品价值）是否有很大的痛点，或者能带来多大的便利呢？
- 为谁解决这个问题？（目标市场）目标客户是谁，这个几乎也决定了市场的规模。
- 成功的机会有多大？（市场规模）到底这是个几亿的市场，还是万亿的市场，这个需要科学的评估出来
- 怎样判断产品是否成功与否？（度量指标或收益指标）
- 有哪些同类商品？（竞争格局）
- 为什么我们最适合做这个产品？（竞争优势）
- 时机合适吗？（市场时机）有时候东西不错，但是时机太早了，有可能成为整个市场的先烈。
- 如何把产品推向市场？（营销组合策略）
- 成功的必要条件是什么？（解决方案要满足的条件）
- 根据以上结果，给出评估结论。（继续或放弃）
只讨论要解决的问题，不应设计具体的解决方案。现在应该要考虑解决什么问题的时候。最后需要将这些信息呈报给高管。
个人觉得这个部分是最重要的，这里要是错了，那后面的开发这些人力都是白费了。
不管是开发新产品，还是改善原有产品，都是属于产品机会。产品团队要评估两者的收益和成本。而一般软件公司很少会愿意改善原有产品。主要是由于过于自负，以为产品已经足够好，继续投入也不会有大的改进。要么就认为产品太复杂，根本无法改进。宁愿花钱做营销、投放广告；要么认为客户服务的支出是必不可少的。实际情况往往是产品缺乏竞争力，公司只能在其他方面寻找补救措施。
这个说的太对了，看看贵司的SDK，每个客户集成都需要投入一堆的人力去支持，研发团队也头疼，支持团队也头疼，客户还不满意。就差最后研发团队帮客户集成好了。
这不就是这个产品糟糕的设计和蹩脚的用户体验导致的结果吗？
让财务同事来帮助你：
- 帮助你了解产品。财务部门的同事有更精确的预测
- 帮助你了解用户。财务部门掌握了所有的交易记录和支付信息。
- 确认商业上的可行性。
产品探索
产品经理负责分析各种创意，广泛收集用户需求，了解如何运用新技术，拿出产品原型并加以测试，从全局视角思考产品方向，兼顾短期需求和长期发展。
当产品1.0版本进入到项目执行周期，就应该马上开始定义2.0版本的产品。这样就可以一直流水线的迭代下去。
探索产品本质上是一门艺术，而不是科学。
- 产品经理应该探索是否有用户需要产品，就是要要寻找市场让用户验证你的构思。
- 产品经理要探索能够解决问题的产品方案，它必须是有价值的、可用的、可行的。
产品原则
体现团队特色的产品价值准则。我觉得这个跟公司的价值观有很大的关系的。
产品原则是一套价值判断的框架，帮助公司做出正确的决策。不光要罗列出来，还要按原则的重要性进行排序。
指定产品原则容易出现2个错误：过于宽泛，失去了指导作用。将设计原则误当产品原则。
产品评审团
如果产品决策效率太低需要建立这个。
产品发布3~6个月后产品团队需要汇报产品的市场业绩表现。产品评审团反思之前的决策是否明智。
特约用户，市场调研，产品用户角色
这里主要是讲如何进行调研的，发现目标客户，以及及早确定用户角色。
重新定义产品说明文档
一个理想的产品说明文档应该满足如下要求：
- 产品说明文档应该完整地描述用户体验，用户需求，交互设计和视觉设计。
- 产品说明文档必须准确的描述软件的行为。文字和图片的表达能力不行。
- 产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。
- 产品说明文档必须可以修改。但应该尽量避免后期修改。
- 应该有一个主题来代表产品，避免混淆不清，版本错乱。
以上得出，满足这个要求的就是高保真产品原型。
相比图片和文字，这个可以大大缩短产品上市时间。
用户体验设计与实现
先定义用户体验再进行开发，一旦进入开发阶段，再修改就很难了，返工和波动会增加团队的压力。
尽管产品会分成很多期迭代，但是设计师必须全面地、连贯地看待用户体验，考虑用户国王的使用习惯。
基本产品
好的产品设计方式：
- 产品经理和设计师合作设计产品的高保真模型。这个模型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。
- 邀请主力开发人员参与设计原型。
- 请真实用户验证产品原型。
这个时候就不能再削减任何功能了。
产品验证
产品验证是指在正式开发，部署产品前，验证产品说明文档描述的产品是否符合预期的要求。
可行性测试
邀请开发人员深度参与技术调研，寻找可行的方案。
可用性测试
让不同类型的用户都能明白如何使用
价值测试
价值测试重在考察用户是否喜欢这些功能，是否满意功能具体的实现方式。
原型测试
产品原型可以让用户验证产品的创意，加深产品经理对产品的理解，避免开发团队浪费时间和经理开发没有把握的产品。
物色测试者
准备测试
测试环境
测试原型
更新原型
改进现有产品
不是一味地添加功能。
能提高指标的功能才是你关注的重点。你应该找准方向，分析关键指标，有针对性的改进产品。
平滑部署
避免更新产品导致用户反感。
- 通过公告，邮件等告知用户。
- 做好测试工作，避免存在影响正常使用的隐患。
- 更新版本影响大规模用户的时候，需要进行增量部署的方式。
快速响应阶段
在产品发布后的几天到一周内，所有项目成员应该流出时间作为快速响应阶段，处理用户反馈一键。关键不在于是否会出现问题，而是多快处理完成。
合理运用敏捷方法
每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型，让大家看到工作成果。
定制软件领域长期以来很难招聘留住顶级程序员。部分原因是顶级的程序员更喜欢为成千上万的用户开发产品软件。
合理运用瀑布式开发方法
基本没什么优点，而且产品验证的时间太晚了。
创业型公司的产品管理
关键在于产品探索
创业初期就只设3个职位：产品经理、交互设计师和原型开发人员。确定好产品原型后，再招聘程序员进行开发。
创业型公司应该认识到首要的任务是确定开发什么样的产品。
大公司如何创新
20%法则：最好的创意大多来自普通员工。20%法则顾虑普通员工自己尝试各种想法，发挥大家的主观能动性，让员工打心底愿意倾注更多的激情和汗水去创新。