完成启《启示录》的复习，这次有些匆忙，但是看第二遍比之前第一遍，感触更多，这是一本需要常看的书，在不断地实践中更新经验和认识。
《启示录》评估产品机会
原因：市场变数、竞争对手不断革新、新技术新创意不断涌现；
目的：淘汰馊主意、避免浪费时间、金钱；挑选合适的产品机会，团结团队，理解产品，整合资源
To-do-list：10问
产品价值，目标市场，市场规模，度量指标，竞争格局，竞争优势，市场时机，营销组合，解决方案，继续or放弃
产品价值：不是泛泛的产品功能和特色；
开发新产品还是维护旧产品？
钱花在哪里？产品经济学：了解产品、了解用户、了解商业可行性
产品探索
弄清楚要开发什么（定义正确的产品）-->强调产品
开发该产品（正确的开发产品）-->强调执行
不同阶段，工作重心转移！--流水线开发并行
产品探索可控吗？--艺术而非科学，不可控！重视。
探索是否有用户需要产品-->寻找市场，让用户验证你的构思
探索能够解决问题的产品方案-->有价值、可行性、可用性（设计方案）
产品原则
对团队信仰和价值观的总结，体现目标和愿景，用来指导产品团队做出正确的决策和取舍。
产品原则，不是产品功能清单，不依赖于任何单独产品，它是整个产品线的战略指南，市公司的价值宣言。激发设计产品的灵感。-->产品战略文档，团队内部指导工具、公开宣传公司的理念
产品原则的重要性排序-->误区：原则过于空泛；把设计原则误当产品原则
如何解决意见冲突？
产品评审团
制定更及时、更可靠的产品决策；
成员组成（各部门各岗位），职责-->监督产品研发流程，制定关键决策-->通过四个里程碑来评审产品。
产品评审团替代公司冗长决策会议，缩短决策时间，制定明智、及时、透明的产品决策。
特约用户
产品开发伙伴-->征集特约用户：用户顾问委员会，用户评审团8~10人
深入洞察目标用户的需要+赢得用户对产品的推荐
使用特约用户，是确保产品不偏离用户需求最简单有效的办法，同时也是向潜在用户宣传、推荐产品的最佳手段
成为特约用户的好处：解决棘手问题，提前试用，降低用户各种成本
PM的收获：聚拢积极用户，调研便利，定期组织小组讨论，迅速反馈试用测试产品，乐意公开推荐
注意事项
弊端：用户不知道什么样的想法可行，不了解现有技术；用户不知道自己想要什么，没见到实际产品，难以凭空想象
市场调研
作用：用户调查，产品使用分析，数据挖掘，拜访用户，人物角色，可用性测试，同类产品分析！
局限性
产品人物角色
又称，用户特征记录。理解目标用户，越早开始越好。
主要用途：zan!
人物角色用来筛选重要的产品功能
避免犯错：把自己的需求当成用户的需求
有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的地方
方便向团队描述产品的目标用户，他们如何使用产品，关心产品哪些方面
帮助团队人员达成共识，发布前许多细节问题要解决，解决问题高
重新定义产品说明文档
包含：原型，业务逻辑，发布要求，平台交付，用例；->建议高保真原型
满足以下要求：
完整描述用户体验
准确描述软件行为
受众较广->直观呈现信息
开发执行阶段避免修改
文档中的衍生物应该有一个主体来代表产品，避免混淆不清（优先级排列的产品需求，线框图，实体模型）
用户体验设计与实现
先定义用户体验再动手开发（而开发和测试可以交叉并行进行）
第零次迭代：在这段时间里，用户体验设计师和PM需要完成设计工作，然后交付给开发人员。还需要详细地定义待开发任务backlog（不会让开发不开心，并且产品也会更好）。
基本产品
基本产品：只满足基本要求（价值、可用性、可行性）
差例：pm制定完善的产品说明文档，详细标注各项产品功能的重要等级，然后开发人员剔除不能及的功能，但是进度还是会很慢，然后就会开发和产品去争论，缩减功能、缩小测试、外包等等
-->设计的高保真原型，只包含满足实现商业目标的最基本功能，以及良好的用户体验和吸引力！
要求一位开发去评估各种功能的直接成本和间接成本
请一位真实用户验证测试产品原型
产品验证
可行性测试：
现有技术，架构师，开发人员：可行性方案，克服的障碍，可行性风险
可用性测试：
交互设计师，真实用户：突出产品功能、不同类型用户理解如何使用，实际效果反馈
价值测试：
价值测试可与可用性可行性测试共同进行，用户：是否喜欢，会不会购买
越早发现问题越好，而不是等到产品公开测试，甚至正式发布才醒悟
原型测试
产品创意呈现给用户，用高保证原型作为描述产品的最基本方式
测试时的注意事项：！！！！
1，不宜在测试前交谈过多
2，只是产品原型不是最终产品，说出真实的看法，不要碍于情面
3，保持平和的状态，看他是否能顺利完成任务
4，测试时尽量保持安静，不要给测试者提示
5，避免提示测试者，更不能引导他！
6，使用自言自语的状态：如果测试者安静，你可以口述他们正在做的事；如果测试者向你求助，你可以重复他的问题，不可夸奖，而是说他达到了一个什么功能效果，避免了诱导性的价值判断，帮助记录员记下测试要点
7，测试者的肢体语言和语气中发现很多有用的东西
改进现有产品
不能一味加功能，误区：详细绘出产品路线图，列出要加的功能
------>功能加工厂，附带制作补丁，修补缺陷
第一步：明确目标（各种指标可供参考，用户数量注册等等信息）
第二步：考虑从哪些地方可以改善用户体验（用户放弃注册多半是不愿意信任你）
-->指标中反思：找准方向，分析关键指标，有针对性地改善产品
平滑部署
毫无征兆的更新不必要版本->用户反感 why
1，事前没通知，措手不及
2，没时间学习、适应新版本，没有过渡性阶段
3，新版本无法运行
4，新旧版本不兼容
5，新功能和特性没有必要
6，接二连三的版本更新，感到必备
7，新版本修改了用户已经习惯的使用方式和操作流程，不得不重新调整适应
因噎废食-->谨慎、理智
负面影响降到最低，do
1，通过通告，群发邮件，在线教程等方式提前通知，效果有限
2，加倍做好测试工作，避免隐患：可靠性、可扩展性、性能
3，并行部署、增量部署的方式来降低风险
平滑部署的方式：
方法一：发布两个并行的版本，邀请有兴趣有时间的用户体验，新版本运行正常并且习惯再将新版本设置为默认版本，公示旧版本的支持的最后期限。
方法二：区域性逐步部署，在某个区域部署版本，然后逐步扩大范围
方法三：增量部署，将更新项分割成几个较小的部分逐步发布。
优秀的产品和服务可以赢得用户的好感，这是宝贵的信任，应该小心保护，不要轻易试探用户的耐心，让好感变成反感。
快速响应阶段
产品出炉后切莫虎头蛇尾-->产品发布后不是急着转向下一个新产品，这时候是收集反馈信息、改进产品的最佳时期，急于“撤军”是项目管理和产品开发中的大忌！
评估产品表现，应该使用明确的、可量化的指标-->你关心产品哪些方面的表现？（页面访问量？用户注册量？广告收益？）给出指标的轻重缓急。追踪用户行为。实时数据。
合理运用敏捷开发
产品和设计师的工作进度应该比开发领先一两个迭代周期；
把产品设计工作拆分成独立的部分，分而治之
开发人员自信划分迭代周期
每次迭代之后，pm需向团队展示产品现状
团队内部展开敏捷培训，设计、开发、自己、团队都理解这个敏捷开发的方式
合理采用瀑布式开发
什么是瀑布式方法?
1，采用阶段式开发：分成固定几个阶段
2，采用阶段式评审：每个阶段结束后，审核后才能进入下一个阶段
优点：具有可预见性
目前大多团队采用瀑布式开发的方法（持续改进方法，里程碑式开发方法）
---->主要缺点：
产品验证严重滞后，
变更计划代价不菲，
无法适应快速市场变化（严重依赖文档和流程）
创业公司产品管理
秘密状态进行，由于产品需求合创意往往边做边变化，开发进度相对较慢
关键点：
创建体现用户体验的高保真原型
邀请真实的目标用户验证产品原型
误区：软件行业有非常强的技术导向性-->习惯从技术层面着手开发产品
大公司如何创新
企业文化和老板的观念
20%法则：谷歌程序猿有20%时间用来从事创新研究。人们误以为优秀的产品是战略规划的结果，或是来自公司高管的创意->而是普通员工
臭鼬工程：原指秘密军事活动，现指在限制条件下，利用自己世家你，低调地进行创新研究。
主动观察：观察和倾听；创新不是发现新问题，而是用新方法解决已有的问题，观察人们对现有产品的不满，是创新的最佳途径
改善用户体验
收购小公司
在大公司施展拳脚
大公司原则：
尽量规避风险
大多大公司采用矩阵式的管理方法->（设计开发测试运维测试等核心部门是共享资源）需争取资源
to-do
1，了解公司制定决策的方式：说服具体做决策的对象
2，建立人脉网络：合作，主动帮助他人积累人脉，不要等到有事索求
3，臭鼬工程：业余做高保证原型
4，自己顶上：真正需要帮手时找不到人资源不齐，一切为了推出产品不计较个人得失
5，有选择地据理力争：与人辩论小心措辞对事不对人给人留余地，多一个朋友而不是敌人
6，会前沟通，形成默契：如果在会议上被公开反对提议你会变得很被动，会前聊天及时化解
7，合理分配时间：合理安排信任同事完成自己本职工作->产品战略产品路线图原型分析竞争对手
8，分享信息：沟通难题！大家只想着获取不愿意支出，分享资源会让你收获人脉和资源，共赢
9，向上司借力：更好开展工作（利用他的人脉多请教）
10，传播你的产品理念：大家支持
网友评论