第21章：产品验证
证明产品的价值、可用性、可行性
- 可行性：主要是技术可行性验证，评估技术成熟度，做技术预研，确保技术可行。比如当前最火的AI产品，语音、图像识别的技术日渐成熟。
- 可用性：建议拿产品原型给用户使用，发现用户体验的问题，有时候也发现新的需求。产品经理和交互设计师共同完成。
- 价值：三个方面，产品是否有用，即解决了用户问题/满足了用户需求；用户是否愿意付钱；用户是否喜欢。可以有很多种方法进行验证，比如原型。越提前越好。
第22章：原型测试
把产品创意呈现给真实用户
- 争取用户研究团队和可用性测试团队的支持很重要，目前很多公司有这样的角色。
- 产品可用性测试和价值测试同样重要
物色测试者
- 特约用户，不是早期尝鲜者
- 企业产品可以去同类产品展销会
- 分类信息网站发公告
- 亲朋好友，注意排除科技从业者、过于亲密的人，不能只是亲友
- 邮件列表，求助营销团队帮助筛选
- 公司官网，注意区分尝鲜者
- 大公司定期组织的测试
- 走出公司，到用户聚集的地方，比如卖场，注意准备礼物
- 邀请用户上门，注意赔偿用户时间损失
- 测试前提醒，注意电话、语音留言等
准备测试
- 准备测试内容，用户大部分时间做的操作
- 看用户未接触产品原型前是如何解决问题的
- 看用户是否能从首页看出产品要解决什么问题，哪些地方最吸引他们
- 完成测试后通过聊天进一步了解收集信息
- 给每个问题打分
- 不用所有功能开发完成才开始测试，了解测试者的期望和实际实现的差距
测试环境
- 准备一个可以让用户放松的环境，实验室，星巴克都可以
- 在用户的办公室也可以，可以更加接近用户使用场景，环境，比如显示器大小，网速等
- 面对面测试必不可少，因为可以观察用户表情和肢体动作
- 产品经理应亲自参加测试，可以获取很多第三方测试遗漏的细节
- 产品经理和交互设计师应该承认产品不完美
- 最好一个人主持测试一个记录
- 可以邀请交互设计师，技术开发，高层等其他角色共同完成测试
测试原型
- 测试前不要说太多话，避免透露太多细节，最好五分钟内就进入测试
- 告诉测试者这个只是原型不是正式产品。说出真实想法，不管好坏
- 让测试者保持平和心态，不要陷入吹毛求疵。不要引导测试者，比如你觉得界面上哪三个元素没用
- 保持安静，让测试者自己尝试，不要提示
- 通常有三种测试结果，顺利完成，受到挫折努力后完成，放弃，测试失败
- 避免提示，可以问测试者在想什么，但不要太多
- 向鹦鹉学习测试主持技巧，自言自语，重复测试者提问，描述他们做的
- 测试的目的是理解目标用户如何看待产品要解决的问题，发现产品原型不符合用户直觉和习惯的地方。
- 从测试者的表情和语气里可以发现很多有用的信息。
更新原型
- 如果两个测试者提出同样问题，即可快速完善原型。如果连续六个用户认可产品价值并完成关键测试，即可结束测试
- 如果发现无法让用户认可产品价值或者让产品足够简单用，放弃产品产品创意。
第23章 改进现有产品
不是一味的添加功能
- 开发产品的第一步是要明确目标，考虑产品的一些关键指标。
- 考虑从哪些方面改进用户体验
- 产品经理应该时刻关注指标，和各个角色一起通过各种分析来改善指标
- 改进产品不是满足个别人的需求，提高指标的功能才是好的改进。
第24章 平滑部署
避免更新产品导致用户反感
不是所有用户都喜欢更新，原因可能：
- 用户学习、更新成本高，更新频繁
- 新版本有问题、不兼容等
- 无用的新功能更新
- 用户习惯改变
降低版本更新影响的措施：
- 提前做好更新通知
- 做好质量管理
- 并行部署或者增量部署
--同时保持新旧两个版本，用户接受了新版本再全部更新
--分多次更新避免一次带来很大的冲击
--分地域部署
第25章 快速响应阶段
产品发布后切莫虎头蛇尾
- 产品发布后不要急于撤出资源进入下一个项目，保留一段时间快速解决用户反馈的问题和意见
- 评估产品表现，最好的方法是通过量化的指标，用什么指标取决于商业目标
- 可以通过网站分析工具、用户问卷调查、邮件组、现场测试等各种方式收集反馈。
第26章 合理运用敏捷
十大秘诀
定制软件（custom software）vs产品软件（product software）
- 产品经理就是产品负责人，敏捷不会让他更轻松
- 使用敏捷同样要做产品规划，明确方向和目标，只不过是短周期、迭代的、轻量级的
- 产品经理和设计师的工作领先一两个迭代，不能一边设计一边开发。让开发人员参与设计和原型评审，获取成本、可行性、解决方案相关意见。
- 设计工作也要拆分成独立的部分，加快速度配合敏捷节奏，但不能拆的太散
- 产品经理的主要任务是定义可行的、有价值的产品原型和用户故事。以此替代文档的好处：1）可以请用户测试原型；2）强迫产品经理全面认真的思考问题；3）明确描述每轮迭代内容，避免浪费
- 让开发人员自己划分迭代周期，有的需求一个迭代可以完成，有的要跨迭代，还要考虑产品的质量、可靠性、扩展性等。
- 产品经理和交互设计师必须参加每天的站会。关于产品的讨论会持续一天。
- 产品经理验收通过才能发布新版本，避免频繁更新
- 每次迭代后产品经理向整个团队展示成果，及下一轮迭代的原型。
- 开展敏捷培训，确保团队成员都理解敏捷方法。
迭代初期的产品能用作原型吗？
- 用一个迭代周期开发原型太浪费了
- 产品定义阶段还有很多重要工作，都来开发原型会影响其他投入
- 一旦进入开发，再调整产品设计就很难了
敏捷方法可以用来开发产品软件吗？
- "原始"的敏捷方法源于客户定制软件开发，认为客户了解自己的需求，不需要产品经理和用户体验设计。快速迭代让客户更早的看到自己定制的产品，也让开发团队更早获取反馈，省去了文档的麻烦，等等
- 产品软件必须尽量完美才能赢得市场，满足广大用户的需求、完整的用户体验设计等。
- 敏捷软件开发需要考虑产品的发布和部署、考虑用户体验设计，同样试用产品软件开发。很多敏捷方法里面并没有提到产品经理和用户体验设计师的工作。
- 敏捷里面的重构和快速调整产品架构对简单的客户定制软件可行，对复杂的产品软件不可行。
第27章 合理利用瀑布式开发方法
扬长避短
传统瀑布式开发理念：
- 采用阶段式开发：需求、高层设计、低层详细设计、编码、测试、部署。
- 采用阶段式评审
瀑布式方法为什么经久不衰 - 只要精确定义需求，项目就是可预期的
- 详细的文档让人安心
瀑布式方法让产品经理头痛的地方： - 验证严重滞后：应该尽可能做原型测试，确认用户需求。提前确定产品可行性。
- 变更计划代价不菲：及时跟踪需求，早变更比晚变更好
- 无法适应快速的市场变化
第28章 创业型公司的产品管理
关键是产品探索
前期只设置三个角色，产品经理（可以由创始人兼任）、交互设计师（可以由原型人员兼任）和原型开发人员
1） 创建体现用户体验的高保真原型
2） 邀请真实的目标用户验证产品原型
验证产品原型后，再招聘开发人员进行正式产品开发。
第29章 大公司如何创新
有困难，但值得一试
两大影响大公司创业氛围的因素：企业文化和老板的观念。
大公司创新方法：
- 20%法则：留出20%的工作时间
- 臭鼬工程：利用自己的时间，偷着干
- 仔细观察：观察用户使用产品的表现。创新是用新方法解决现有问题
- 改善用户体验
- 收购小公司
第30章 在大公司施展拳脚
十大秘诀
首先了解两大规则：尽量规避风险和矩阵管理
- 了解公司决策的方式，谁决策，他的习惯是什么，说服他
- 建立人脉网络，主动帮助别人
- 臭鼬工程：找三五同行
- 自己顶上：自己做，不要等
- 有选择的据理力争：对事不对人
- 会前沟通，形成默契
- 合理分配时间：产品经理流出构思产品路线图、分析产品原型、研究竞争对手的时间。
- 分享信息：共赢
- 向上司借力
- 传播你的产品理念
