《启示录》读书笔记
2021-02-26 08:08:19 1 举报AI智能生成
书籍详解
作者其他创作
大纲/内容
启示录
关键角色及其职责
1⃣️交互设计师与产品经理密切合作，将功能与设计相结合，满足用户的需求；2⃣️确保产品同时具有可用性和价值；
关键角色
产品经理
评估产品机会
产品创意来源
1⃣️市场需求文档2⃣️机会评估
公司高管的意见
用户的反馈
可用性测试的结果
产品团队和营销团队的点子
业内人士的分析
定义要开发的产品
探索产品的解决方案
产品需求文档（清晰的描述产品的功能和属性，避免讨论产品的实现方法）
基本的产品特征和功能
产品的用户体验
产品的发布标准
用户体验设计师（交互设计师）
深入了解目标用户
设计有价值的、可用的功能
用户导航和产品的使用流程
项目管理人员
制定计划和跟踪进度
专职的项目经理
开发经理
取决于公司文化和项目规模：规模较大的项目最好安排经验丰富非专职项目经理管理
开发团队
为外部客户开发和维护产品的团队
IT团队
为内部员工提供技术支持的团队
运维团队
用户通过web访问服务，运维团队负责保证服务正常运行
产品营销人员
对外发布信息、宣传产品
为拓展市场销售渠道、组织重点营销活动、促进产品销售提供支持
团队成员构成比例
5～10位开发 => 1位产品经理
用户体验设计师
1位交互设计师 => 2位产品经理
1位视觉设计师 => 4位交互设计师
超过10名开发参与的重大项目该配专职项目经理
火车模型发布模式（以固定周期持续发布的产品，若某既定功能未完成，就挪到下个周期的开发方法）必须位每次的产品发布（通常这类产品由多个项目组成）配专职的项目经理
产品管理与产品营销
职责界定
产品经理：从细节上顶级开发团队开发什么产品
产品营销：对外宣传产品
误区
由市场营销人员定义产品
忽略了手机详细产品需求的步骤，回避探索（定义）产品的艰难决策过程（也绕开了用户体验设计）
两人分担定义产品的工作
产品营销人员负责高层商业需求产品经理负责底层产品需求
两个人都不是真正的产品负责人，没人对最终的产品负责；错误的观点：可以脱离具体的需求（用户体验）来定义高层需求
一人兼职两项工作
产品营销人员兼任产品经理的工作
两者都需要专业的技能，但要求大相径庭
产品管理与项目管理
发布模式
并行开发
火车模型发布模式
每次发布都需要从有力的、有效的项目管理，不局限于具体项目，必须统筹全局
发布管理
网站运维
客户服务
产品管理
优秀的项目经理
工作的紧迫感
善于捕捉问题
思路清晰
用数据说话
果断
判断力
态度
产品管理与产品设计
理解用户体验设计
用户研究
专门研究、分析用户，评估产品或产品原型是否符合特定用户的使用习惯；拟定恰当的测试项目，监督测试，评估测试结果，提出改进方案；
交互设计
在理解目标用户的基础上设计有价值的、可用的目标功能、用户导航和产品使用流程；用线框绘制产品需求，然后交给视觉设计师；
不能外包
深入理解用户需求非常费时间，需要多个项目的经验积累
必须现场深度参与项目开发，从立项直到产品发布
产品的用户体验是公司的核心竞争力，必须在内部完成
视觉设计
根据线框设计可见的用户界面，包括严格的布局、颜色和字体设置
传达并唤起产品蕴含的情感
原型制作
迅速制作融合来产品经理和设计师创意的产品原型，让用户使用反馈并修正
产品管理与软件开发
开发人员帮助产品经理完善产品定义
让开发热暖直接面对用户或顾客，体会用户的困惑和疑虑：邀请一名开发参与产品原型测试
向开发人员了解最新的技术发展动向，讨论哪些新技术可以用到产品里
让开发人员在探索（定义）产品的初期阶段参与评估产品设计，协助策划方案
产品经理配合开发人员
产品经理只定义满足基本要求的铲皮
一旦产品进入开发阶段，要尽可能避免修改产品的需求和设计
开发阶段产生诸多问题：用例丢失i、用例设计考虑不周，产品经理应该迅速采取行动，在维持产品基本功能、尽量避免修改的原则上，拿出解决方案
如何与异地的开发人员沟通
无论是讨论产品文档的内容，还是讨论修改产品设计，一定要借助高保真原型进行交流
必须有人在本地负责与异地团队的协调工作
当面沟通不可替代，产品经理定期前往异地与开发团队见面，面对面交流有助于改善（合作关系），提高沟通效率or交换人员一段时间
业务外包
外包不是节约成本，而是为了实现合理的人员配置
mysql
选择业务外包的关键是要挑选有能力的员工
为产品团队寻找合适的人选，而不是仅仅为省钱
开发想重写代码
未雨绸缪，预留一定的技术能力（余量）
避免触及技术能力的上限
为用户数量的增长预留空间
为事务增长预留空间
为新增功能预留空间
保证产品的技术架构能够满足团队要求
在产品管理上为开发团队预留20%的自主时间
重写代码、完善架构、重构代码库中有缺陷的部分
更换数据库管理系统，提高系统性能
已经陷入重写代码的困境
针对开发团队确定的产品修改目标制定切实可行的计划和时间表
把重写目标分成几大块，实现递增修改，让用户感受到产品的改进
开发用户可见功能的资源有限，必须谨慎选择正确的产品特性，确保产品定义的正确性
招聘产品经理
个人素质和态度
对产品的热情
把生活中的一切事物都看成产品，怀揣对优秀产品的热爱和尊重
用户立场
必须融入产品目标市场，换位思考，尊重目标市场希望融入其中
智力
洞察力和判断力
职业操作
肩负产品的前途和命运，绝不适合贪图安逸的人担任
正直
最能提现公司和产品的价值观
信心
自信的人更有说服力，更容易成为人们愿意追随的领导者
虽然产品的实现离不开大家的协助，但产品应该对自己但产品创意负责
技能
掌握一些重要的技能是打造成功产品的关键
运用技术的能力
有能力理解技术、发掘技术的应用潜力
注意力
足够强的自律性，不但要遵守公司制度，还有严格要求自己
时间管理
熟练、迅速地区分重要任务和紧急任务，合理的规划和安排时间
沟通技能
口头表达&书面表达
商业技能
双语技能：和程序员讨论技术、管理者和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌
行业经验重要吗
最宝贵的经验不是行业知识或技术（都可能过时）而是打造优秀产品的流程、领导产品团队的能力、应对产品扩张的经验、个人对自己的认知
与行业知识密切相关的是技术专长
高科技产品行业虽然要求快速学习新技术，但更重要的是预见如何应用技术合理解决问题
必须善于快速学习新技术，解决新问题
年龄不是问题
经验虽然需要时间积累，但其他素质如智力与年龄无关
管理产品经理
建设产品管理团队
训练和培养产品管理团队的工作能力不但是产品经理的任务，更是产品总监的任务
规划公司的产品战略
决定公司经营什么产品，仔细评审每款产品的产品战略和研发流程
透彻理解公司最新的商业战略，确保产品战略直接支持商业战略
制定展品组合路线图，兼顾用户需求和商业目标，从全局出发制定产品发布计划
怎样评估产品经理的工作
看产品本身是否成功
用户净推荐值（NPS）：www.netpromoter.com
调查用户是否愿意向他人推荐你的产品
产品管理属于哪个部门
产品管理部门 => 与开发部门和市场部门相等的级别
理想情况下，产品管理部门应该包含设计团队
巴顿将军的忠告
永远不要告诉别人怎么做。告诉她们做什么，她们自然会发挥天赋，给你惊喜。
产品副经理
打听，多问同事，肯定会有收获
采用走动式管理模式（管理者走出自己的办公室和圈子）
认真倾听与会者的对话与发言
敞开办公室的门，让大家直到你随时欢迎她们向你提出产品建议
坦率把烦恼告诉同事，大家会热情帮助
一起泡吧，抽出时间与普通员工一起休息、娱乐
管理上司
为项目波动做好准备
返工、计划变更
注意沟通的方式与频率
千人千面
会前沟通
确保会议召开前已经达成一致意见
多提建议，少谈问题
根据问题的重要性列举多种解决方案，附上依据与建议
向上司借力
把想法告诉上司，请他帮助转达建议
准备充分
弄清问题所在，做到有备无患
缩短邮件篇幅
用简明扼要的方式进行交流，收件人级别越高，邮件篇幅越短，可添加附件
多用数据和事实说话
多做准备工作，收集事实和数据，建议才有说服力
内部宣传
向公司同事宣传产品，让大家任何你的工作，乐于帮助你
做让领导省心的员工
抱腰劳烦上司所导师，可以在直接管理层外另寻导师
目的
淘汰馊主意，避免浪费时间和金钱
挑选合适的产品机会，团结团队，理解产品，整合资源
十问
1⃣️产品要解决什么问题（产品价值）
2⃣️为谁解决这个问题（目标市场）
3⃣️成功的机会有多大（市场规模）
4⃣️怎样判断产品成功与否（度量指标或收益指标）
5⃣️有哪些同类产品（竞争格局）
6⃣️为什么我们最适合做这个产品（竞争优势）
7⃣️时机合适吗（市场时机）
8⃣️如何把产品推向市场（营销组合策略）
9⃣️成功的必要条件是什么（解决方案要满足的条件）
🔟根据以上问题，给出评估结论（继续或放弃）
开发新产品还是维护旧产品
开发新产品能为老用户提供更多选择，还能吸纳新用户；改善原有产品能提高老用户的满意度，也能吸纳新用户；
产品团队一视同仁地评估两者的收益与成本，然后由管理团队做出决策
钱花在哪儿
帮助你了解产品
帮助你了解用户
确认商业上的可行性
产品探索
产品经理的职责是保证开发团队开发有价值、可用的产品
定义正确的产品
两个阶段弄清楚要开发什么产品（定义正确的产品）
开发该产品（正确的开发产品）
产品经理必须在执行阶段转换工作中心，采用流水线方式并行开发产品=> 一旦1.0斑斑进入项目执行阶段，就开始定义2.0版本的产品（不要让这种歌做法敢于正在执行的项目）
探索产品的进度可控吗
产品经理应该探索是否有用户需要产品，要寻找市场，让用户验证你的构思
产品经理要探索有价值的、可用的、可行的产品方案，设计解决方案，请用户和开发团队来验证
管理层坚持给产品探索设定期限
探索产品的过程不可预测
开发人员是紧缺资源
产品原则
对团队信仰和价值观的总结：直到产品团队做出正确的决策和取舍
是整个产品线的战略指南，是公司的价值宣言
是一套价值判断的框架，帮助公司做出正确的决策
是否公开因公司而异
可以用作团队内部的指导工具，产品战略文档
也可以公开给客户、合作伙伴、投资人，用于向公众宣传公司的理念
团结产品团队，让产品经理、产品设计师、开发团队和营销团队形成共同的价值观，在认识上保持一致性
解决意见冲突
无议程无结果的会议
每位同事对公司的产品都有自己的看法
大家都非常在乎产品，明白公司盈利得看用户
许多人以为自己比其他人了解目标用户，事实并非如此
做产品决策之前，先达成共识
究竟要解决什么问题
要为哪类人物角色解决这个问题
产品要达到什么目标
每项目标的优先级是什么
产品评审团
确保每个关键部门都有代表参加产品评审团，人数控制在10人以内
评估产品机会时做粗略估算；根据最终的产品说明文档做详细估算
产品评审团的工作目标
决定产品战略方向，宏观上监督公司产品的研发流程，合理配置资源
产品评审团的成员组成
首席执行官/首席运营官/部门总经理
产品管理总监/副总监
用户体验设计总监/副总监
市场总监/副总监
开发总监/副总监
网站运营总监/副总监
客户服务总监/副总监
产品评审团的职责
评审产品战略和产品路线图，启动评估产品机会的工作
根据评估产品机会的结果，决定是否开始定义产品的解决方案
评审产品原型、用户测试结果、成本估算明细，决定是否开发产品
评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品
注意事项
小公司评审团负责评审公司所有的产品，大公司根据业务单位大小设立若干哥产品评审团
产品评审团不负责评审对产品细节对更新或修正
产品评审团不负责具体的产品设计工作
在2号里程碑处，至多只能估计大致的项目规模；在3号里程碑处，自己估算开发时间和成本，让公司上下做好准备
尽量避免产品评审团讨论具体的执行策略
产品评审团开会取决与具体产品的进度：每月1h或每周2h
产品评审团应该回顾、分析产品上市后的表现，反思之前的决策是否明智
每次评审会议，由产品经理向产品评审团汇报产品进展情况
何时估算项目成本
研发产品前，评估产品机会
大致估算项目规模：小型、中型、大型
确认产品机会有价值，粗略估算的成本也可以接受
管理层允许项目组着手定义解决方案（高保真原型）
定义解决方案过程中，产品经理&交互设计时&开发人员评估不同解决方案的成本
根据文档细节生成详细、可靠的成本估算结果
根据详细的产品说明文档、可信的成本估算结果，管理层可以很方便的决定是否开始开发产品
特约用户
产品开发伙伴
产品经理要深入了解目标用户，明确产品需要解决的问题，定义出满足用户需求的产品
既深入洞察目标用户的需求，又赢得用户对产品的推荐
征集特约用户（用户顾问委员会、用户评审团）
在项目的开发阶段物色至少6位积极、活跃、乐于分享的目标用户
在产品的目标用户中具有一定的影响力
成为特约用户的好处
参与构思产品创意，解决他们手头的问题
提前使用产品，越早使用产品意味着越早解决麻烦
提前试用产品还可以显著降低用户的各种成本
产品经理的收获
聚拢一批积极的用户，为定义产品和开发产品提供建议和协助
提供调研比那里，便于产品经理去特约用户的工作场所调研
可以定期组织特约用户进行小组讨论
特约用户第一时间试用、测试产品，迅速反馈意见
如果特约用户满意产品的表现，会乐意公开推荐产品
组织特约用户的注意事项
不要向特约用户收取参与费用，否则合作关系将变味
为满足大批心急的用户，公司可以先发布预览版产品，特约用户人数不能超过10个
保证产品经理有精力充分了解每位特约用户
如果在寻找特约用户时遇到困难，重新考虑产品计划
需要确保特约用户是产品的潜在目标用户
务必向特约用户说明，我们要开发的是面向大众的通用产品，不是为了某家开发的定制产品，承诺产品不会昙花一现
把特约用户当成开发伙伴对待，视他们为同事，互相帮助
产品经理与特约用户的合作贯穿产品开发的每个环节：向他们展示产品原型，请他们参与测试，向他们请教产品的细节问题
正式产品发布之前，一定要先请特约用户试用，确保每个人都满意
产品经理还要和产品营销团队紧密合作
如果是平台产品，6个特约用户换成6个应用，与特约应用的开发者紧密合作
该不该与用户交流
产品经理必须与用户充分沟通，挖掘每个人的潜在需求，捕捉产品创意
产品经理还应该充分利用公司的可用资源
用户研究部门：协助分析用户行为
营销人员：协助确定产品定位和宣传计划
主程序员：提前考虑产品开发的细节问题
与用户打交道的过程中，与一些富有洞察力、善于思考的用户，建立长期联系，是特约用户的最佳候选人
市场调研
市场调研的作用
市场调研工具和方法
1⃣️谁是目标用户；2⃣️用户会怎样使用产品；3⃣️用户能想明白怎样使用产品、障碍在哪；4⃣️用户为什么选用你的产品；5⃣️用户喜欢产品的哪些特点；6⃣️用户希望如何改进产品，增加哪些功能；
用户调查
设计调查问卷需要技巧和经验，要结合具体情景，仔细设置问题
调查结果为获得解决方案提供了一条途径，但不是解决方案本身
产品使用分析
明确告知用户分析公虎的用途，申明只收集统计数据，不涉及用户隐私
数据挖掘
产品使用分析、用户的账单信息、账户信息、产品数据等
拜访用户
拜访用户很有效，但资金和时间成本高，谨慎使用
务必找出若干主要用户类型，深入了解他们，弄清当前用户和潜在用户
可用性测试
尽早、反复进行可用性测试，观察用户使用现有产品对反应，收集反馈意见，了解用户真实想法
同类产品分析
有必要找出竞争对手的优势，学习对手的成功经验
市场调研的局限性
探索（定义）产品的过程需回答
采用什么技术来更好的解决产品要解决的问题
设计什么样的用户体验
关于用户研讨会
用户研讨会上不可能讨论出成功的产品
用户不知道什么样的想法是可行的，多数用户对现有技术一无所知
用户不知道自己想要什么，没见到实际产品，很难凭空想象自己需要什么
其他弊端
人群聚集时容易冲动，相互影响，难以获取每个用户的真实想法
除非让用户试用实际产品，否则他们不清楚自己想要什么
与用户调查一样，组织用户研讨会也需要经验：熟悉组织技巧、随机应变、掌握产品领域的知识、擅长引导话题
产品人物角色
用户特征记录，通过与用户沟通交流，确定典型的目标用户类型，在理解各类目标用户的特征的基础上建立的人物原型
主要用途
人物角色可以用来筛选重要的产品功能
产品团队常常把自己的需求当成用户需求，使用人物角色可以避免犯这类错误
许多产品的用户类型不止一种
有了人物角色可以方便的向团队描述产品的目标用户
和产品原则一样，人物角色可以帮助团队成员达成共识
每个发布周期应该针对一类目标用户，把产品的优势发挥到极致
与目标用户面对面交流是创建人物角色必不可少的环节
邀请多样化的用户参与产品原型测试
重新定义产品说明文档
高保真原型图
功能需求
信息架构
用户体验
理想的产品说明文档
完整的描述用户体验：不仅是用户需求，还包括交互设计和视觉设计
必须准确的描述软件行为
受众较广，必须以某种直观的方式把产品信息和产品行为告诉所有人
进入开发阶段后，应该支持修改以适应新情况
衍生物：按优先级排列的需求列表、线框图、实体模型（有一个主体来代表产品）
用户体验设计与实现
先定义用户体验再动手开发
开发团队必须根据确定的用户需求和产品定义设计软件架构，然后进行开发
用户体验设计要保证产品同时具备可用性和价值，必须尽早、反复验证设计思路
验证设计思路必须使用高保真原型
产品开发可以分成多次迭代（降低风险、提高质量、便于产品集成），用户体验设计却不能拆分
用户体验设计不一定是最费时间的工作
基本产品
设计方式
产品经理与设计师合作设计产品高保真原型（指具备实现商业目标的最基本功能要求以及良好的用户体验和吸引力）
邀请一位开发人员（架构师or主程序员）参与设计原型，指出设计上的误区，并分析、评估尚不确定是否可行的功能
请真实用户验证（测试）产品原型，一旦通过就不能再削减任何功能
产品验证
可行性测试
现有技术条件下，能否开发出产品
请真实用户来试用可用性原型
价值测试
可与可用性测试同时进行，重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式
原型测试
物色测试者
邀请特约用户参加测试
企业级产品，同类产品的展销会会是寻找目标用户的好去处
在分类信息网站上发布广告，征集测试者
大众产品，邀请亲朋好友参与测试
从用户的电子邮件列表筛选测试者
通过公司的网站征集志愿者
定期开展原型测试活动，每次邀请10～20位参加
离开公司到街头巷尾去，到用户聚集的地方去
邀请测试者上门参加测试，补偿测试者为此损失的时间
在约定的测试时间前一天致电测试者，避免忘记时间
准备测试
实现拟定好测试内容
只有一次机会了解测试者未接触产品原型之前如何解决产品要解决的问题
观察测试者能否从原型首页看出产品要解决什么问题，哪些地方最能吸引他们（有价值）
待测试者完成测试任务，了解产品用途后，通过聊天进一步了解测试者对产品原型的评价
让测试者为每个问题的回答打分，以此记录每个阶段产品原型的表现，为完善产品设计提供参考
不惜等到完整原型完成后再测试，可以先测试主要项目
测试环境
正规的测试实验室：单向透明玻璃和闭路监视器，配多个摄像机同时拍摄用户和电脑显示屏幕
用户的办公室也是上佳的测试场所
有些工具支持远程测试，可以看到用户的鼠标动作和点击内容，无法观察用户的表情和肢体动作
产品经理亲自参与每次原型测试，尽可能多与用户接触，观察他们使用原型的反应
产品经理亲自参与测试的益处远大于可能无法客观测试带来的风险
理想情况：一人主持测试，一人记录
测试原型
测试前不宜与测试者交谈过多（交谈越多，透露的产品线索越多）
务必告诉测试者这只是产品原型，是初步的产品创意，不是正是产品
测试时尽量让测试者保持平和的情绪，不要陷入吹毛求疵的状态
测试是尽量保持安静，不要给测试者提示
没有提示的情况下，测试受挫鼓励他们继续尝试
测试主持人使用自言自语的技巧，避免引导用户
测试的作用是理解目标用户如何看待产品要解决 的问题
通过测试者的表情和语气很容易判断原型的问题所在，哪些设计合理，哪些不靠谱
更新原型
只要对测试反馈迅速做出相应，就能显著加快完善产品的速度，如两三个用户反应同一个情况，就立刻解决
没法让测试者对原型产生兴趣，或无法让原型变得足够简单易用让测试者理解其价值，立刻收手放弃这个产品创意
改进现有产品
不是一味的添加功能
先考虑可以从哪些方面改善用户体验
产品经理与交互设计师、用户研究人员、主程序员密切合作，分析改善产品的可能性
进行网站分析，请用户测试产品，向客服人员、享受人员了解情况
做盈亏分析，估算净推荐值
平滑部署
避免更新产品导致用户反感
事前没有收到更新通知，用户觉得措手不及
用户没有时间学习、适应新版本，产品公司也没有提供旧版本方便用户在过渡阶段使用
新版本无法正常运行
旧版本不兼容（如新版本无法访问旧版本的数据）
虽然新版本可以正常运行，但用户认为添加的功能和特性毫无必要
应付接二连三的版本更新，用户感到疲惫不堪
新版本修改来用户已经习惯的使用方式和操作流程，用户不得不重新调整适应
概要
产品工作需要不断推陈出新，需求在更迭，技术在进步，市场在变化，软件也要与时俱进，不能因噎废食，因为用户可能反感就放弃更新产品，但是更新时必须谨慎、理智。
降低版本更新带来负面影响的措施
通过公告、群发邮件、在线教程等方式提前通知用户
加倍做好测试工作，避免新版本存在影响正常使用的隐患，如可靠性问题、扩展性问题、性能问题
如果更新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式来降低风险
区域性逐步部署
首先在某个区域内部署新版本，然后逐步扩大部署
增量部署
将更新项分割成几个较小的部分逐步发布
快速相应阶段
产品发布后的几天至一周内，所有项目成员应该留出时间作为快速相应阶段
主要工作是快速相应、处理产品发布后的用户反馈意见
一旦问题反馈回来，产品团队应该至少每天召开一次简短会议，讨论问题的轻重缓急，确定最佳解决方案
合理运用敏捷方法
十大方法
产品经理即是产品负责人
使用敏捷方法绝不等于省略产品规划
产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保又足够时间攻克难题
尽量把产品设计工作拆分成独立的部分，分而治之，但也不能拆得太细
产品经理的主要任务是定义有价值、可用的产品原型和用户故事，作为开发的基础
让开发人员自主划分迭代周期
产品经理和交互设计师必须出席每天的晨会，晨会是一天沟通过程的开始，而不是结束
除非达到了产品经理的要求，否则不要轻易发布新版本
在每次迭代完成后，产品经理英爱向团队展示产品现状，以及下次迭代的产品原型
在团队内展开敏捷培训
迭代初期开发的产品能用做原型吗
用一个迭代周期来验证产品创意（通常存在缺陷）时间太长，花几个月时间验证生产中的产品与用几天时间验证可更改的产品原型相比，后者效率更高
在探索（定义）产品的阶段，开发团队还有组多重要的工作要完成，此时占用他们时间开发产品原型会小号正式开发产品的精力
尽管敏捷方法鼓励开发团队不断学习，快速反应，但一旦进入开发阶段设计出软件架构后，再想改变产品设计思路，于开发团队不论成本还是难度都太高
敏捷方法可以用来开发产品软件吗
scrum起源于定制软件领域，而不是产品软件领域
产品软件必须在各方面都尽量都做到完美
产品经理收起广大用户的需求
用户体验设计师创造完美都用户体验
测试人员测试产品，保证软件正常运行
敏捷方法极大地提高来开发定制软件的效率
增进客户和开发人员之间的交流
通过更频繁的迭代来大幅度降低风险
引进现在软件测试的理念
省去撰写累牍连篇的产品说明文档的麻烦
同样适用于产品软件的开发，但应用时应该做出相应的调整
合理运用瀑布式开发方法
在探索（定义）产品阶段，制作产品原型，请目标用户试用，确保产品设计是有价值的、可用的、可行的
基本原则
采用阶段式开发：软件开发过程被事先分成固定的几个阶段
撰写书面的需求说明文档
设计高层软件架构
设计底层细节
编写代码、测试、部署
采用阶段式评审：每个阶段结束后，对该阶段提交的成果进行评审，评审后才能进入下一阶段
形式
正式：美国国防部软件开发标准2167A，498
非正式：市场人员收集市场需求，提交给开发人员->开发人员制定开发计划，设计软件架构，进一步完善设计细节->开发测试，完工后邀请用户测试产品->部署
经久不衰的原因
具有可预测性
每个阶段结束时都会提交书面材料，翔实的文档和设计图标
局限性
产品验证严重滞后
在投入大量人力和资金之前，软件的可用性无法得到验证
变更计划代价不菲
任何对前期决策的修改都会打乱开发流程
无法适应快速的市场变化
严重依赖文档和流程，这方面开销很大
创业型公司的产品管理
可以获得通过市场检验的产品设计；用现货的产品原型代替死板的产品说明文档作为开发产品的基础；加深团队对产品需求和后续工作的理解
关键在于产品探索
创建提现用户体验的高保真原型
邀请真实的目标用户验证产品原型
大公司如何创新
20%法则
谷歌的程序员有20%的工作时间可以用来从事创新研究
臭鼬工程
受限制的条件下，利用自己的时间低调的进行创新研究
主动观察
仔细观察用户使用公司产品和同类产品的一举一动，留心他们欣喜和失望的表情
改善用户体验
跳出技术局限，完善用户体验
收购小公司
引入新技术、创新型人才，为公司注入新鲜血液
在大公司施展拳脚
十大秘诀（尽量规避风险）
了解公司制定决策的方式
了解领导制定决策的方式
建立人脉网络
主动帮助他人，积累人脉关系
找三五个志趣相投的同时在工作之余做出产品原型来
自己顶上
为了推出产品，不计较个人得失
有选择的据理力争
与人争辩，要小心对事不对人，不要把对方逼到死角
会前沟通，形成默契
设法在会前达成一致意见，如有不同意见，及时化解
合理分配时间
划掉无关紧要的会议，留下时间完成自己的本职工作
分享信息
充分共享信息对自己和公司都有好处
若需要上司出面说服公司高管，事先做好准备，为他提供翔实可靠的资料信息，用实力取得其信任
传播你的产品理念
向大家描绘产品愿景，介绍产品策略，掩饰产品原型，分享用户反馈信息，内部宣传有潜移默化的作用
苹果公司给我的启示
硬件为软件服务
软件为用户体验服务
用户体验为情感服务
产品为真正的需求服务
提防有特殊要求的产品
混淆来客户需求和产品需求，必然会使公司偏离正轨
产品需求不能用户说了算
在看到具体的产品之前，用户很难知道自己需要什么
用户不知道什么样的产品是可行的（当前技术条件下可实现）
用户之间缺少沟通，需求很难统一
每个产品版本都要历经开发、测试、维护、撰写文档、技术支持，特例产品会让公司不堪重负
新瓶装老酒
在成熟的市场抢占一席之地
对目标市场了如指掌，对现有产品的缺陷洞若观火
跟踪最新的技术趋势
需求管理软件有用吗
帮助产品经理和市场营销人员收集、追踪、筛选、汇报用户需求
这类工具的初衷虽好，却极易导致人们把用户需求和产品需求混为一谈
恐惧、贪婪、欲望
产品中情感的作用
消费者购买产品大多源于情感需求
创新结束了吗
只要市场上还有蹩脚的产品，就有机会
技术不断发展，今天难以置信的创意，明天也许就能实现
现有的应用程序为将来的发展打下了基础
情感接纳曲线
产品经理关注日常生活里那些让大众烦恼不堪，又不得不应付的事情
关注失望、不满、愤怒等一切负面的情绪
技术接纳曲线模型从技术角度描述消费者对待产品的态度
技术爱好者：技术创新者
最没有参考价值
非理性消费者：尝鲜者
注意研究此类：其情感需求是推动产品跨越鸿沟的动力
理性消费者：早期消费大众
超理性消费者：后期消费大众
观望者：跟随者
如何评估这些情感需求
新生测试：带着新生的感觉去发掘每天这么大众的情感
可用性与美感
两者缺一不可
大众网络服务产品
十大要点
可用性：必须具备良好的用户体验
人物角色：按典型特征将用户分类，抽象出有具体代表性的用户类型（人物角色）加以分析
扩展性：为系统扩展做好准备，永远留有余地，不要满负载运行
持续可用性：一刻也不能停歇，在系统设计上保证持续可用性与规划扩展性一样重要
客户服务：减少系统故障和缺陷，维持良好的用户体验
保护用户隐私：树立保护用户隐私的意识，设置用户资料保护机制
口碑营销：用户若喜欢产品，就会主动向亲朋好友推荐
全球化：易于本地化的产品设计可以大大节省开发成本和时间，避免因文化差异大量改写程序
平滑部署：部署前要仔细测试，逐步过渡，为用户留出足够的时间来适应变化
用户社区管理：让公司上下认识到用户的重要性（所有的商业公司都依靠用户生存）
打造企业级产品的经验
可用性
产品正常工作
特例产品
销售渠道的需求
客户和用户需求
产品安装
产品的配置、自定义、集成
产品升级
销售策略
关于专用解决方案
产品具有价值，用户愿意掏钱购买产品
产品能在多种环境下运行，不是定制软件
只要提供必要的销售工作和销售培训，产品就可以通过销售渠道顺利销售出去
产品公司能够为该产品提供支持，不断完善产品
经销商、服务合作伙伴、客户明白如何安装、配置、使用产品
其他特征
软件能帮助企业解决业务问题，通常是特定（垂直）行业的问题
产品可能由一个或多个组建整合而成，可能是你的公司开发的也可能是合作方开发的，但他们是预先集成好的
必要时，产品应该获得合作方的产品认证
不是专用解决方案
一组重新设计的、用于指导使用现有产品的说明，客户是不会为这样的"产品"掏钱的
从网上搜到的或由技术支持团队提供的一套自定义的脚本
打造平台产品的经验
最具挑战性的工作
定义成功的平台产品（基础软件，应用开发者能在其基础上开发应用程序）
三种客户
应用软件供应商：选择你的平台创建解决方案的公司
关心平台开发商的生存能力
开发人员：应用软件供应商的雇员，由他们在平台上开发应用软件
关心平台产品是否支持自己惯用的编程语言、开发工具、基础架构
终端用户：应用软件的使用者，也是平台服务的真正使用者
只在以最终结果
最佳实践经验
产品管理的职责
机会评估
人物角色
探索（定义）产品
使用原型
用户参与原型测试
根据数据改进产品
产品经理的反省清单
十大问题
产品能吸引目标消费者的关注吗
产品设计是否人性化，是否易于操作
产品能在竞争中取胜吗？即使是面对未来风云变化的市场，依旧有取胜的把握吗
我了解目标用户吗？产品（不是理想的产品，而是实际开发出来的产品）能否能得到他们的认可
产品是否有别于市面上的其他产品？我能在两分钟内向公司告诉俺清楚的阐明这些差别吗？能在一分钟内向客户解释清楚吗？能在半分钟内向经验丰富的行业分析师解释清楚吗
产品能正常运行吗
产品是否完善？用户对产品的印象如何？销售业绩如何？销售人物能否顺利完成
产品的特色是否与目标用户的需求一致？产品特色是否鲜明
产品值钱吗？值多少钱？为什么值这么多钱？用户会选择更便宜的产品吗
我了解其他团队成员对产品的看法吗？他们觉得产品好在哪里？他们的看法是否与我的观点一致
产品经理和产品营销人员应该经常沟通，展开合作：1⃣️营销人员是产品经理获取产品需求的重要来源；2⃣️产品经理是营销人员获取市场营销信息的重要来源
改进产品不是简单的满足个别用户的要求，不也不能对用户调查的结果照单全收。能提高指标的功能才是应该关注的重点。
机会永远不会消失殆尽
收藏
收藏
0 条评论
回复 删除
下一页
