导图社区 启示录—打造用户喜爱的产品
- 86
- 2
- 1
- 举报
启示录—打造用户喜爱的产品
为什么市场上那么多软件产品无人问津，成功的产品凤毛麟角？怎样发掘有价值的产品？拿什么说服开发团队接受你的产品设计？如何将敏捷方法融入产品开发？过 去 二十多年，Marty Cagan作为高级产品经理人为多家一流企业工作过，包括惠普、网景、美国在线、eBay。他亲历了个人电脑、互联网、电子商务的起落沉浮。
编辑于2022-11-09 21:14:02
- 时间管理-读书笔记
时间管理-读书笔记，通过学习和应用这些方法，读者可以更加高效地利用时间，重新掌控时间和工作量，实现更高效的工作和生活。
- 设计史理解理论与方法⭐️（谢尔提·法兰2016）
本书是法兰教授的最新作品之一，主要阐明了设计史的来源、设计史现在的状况以及设计史的未来发展可能等三个基本问题。通过对设计史学科理论与方法的讨论，本书旨在促进读者对什么是设计史以及如何写作一部好的设计史等问题的深入认识与反思。
- 计算机组成原理
《计算机组成原理》涵盖了计算机系统的基本组成、数据的表示与运算、存储系统、指令系统、中央处理器（CPU）、输入输出（I/O）系统以及外部设备等关键内容。通过这门课程的学习，学生可以深入了解计算机硬件系统的各个组成部分及其相互之间的连接方式，掌握计算机的基本工作原理。
启示录—打造用户喜爱的产品
社区模板帮助中心，点此进入>>
- 时间管理-读书笔记
时间管理-读书笔记，通过学习和应用这些方法，读者可以更加高效地利用时间，重新掌控时间和工作量，实现更高效的工作和生活。
- 设计史理解理论与方法⭐️（谢尔提·法兰2016）
本书是法兰教授的最新作品之一，主要阐明了设计史的来源、设计史现在的状况以及设计史的未来发展可能等三个基本问题。通过对设计史学科理论与方法的讨论，本书旨在促进读者对什么是设计史以及如何写作一部好的设计史等问题的深入认识与反思。
- 计算机组成原理
《计算机组成原理》涵盖了计算机系统的基本组成、数据的表示与运算、存储系统、指令系统、中央处理器（CPU）、输入输出（I/O）系统以及外部设备等关键内容。通过这门课程的学习，学生可以深入了解计算机硬件系统的各个组成部分及其相互之间的连接方式，掌握计算机的基本工作原理。
- 相似推荐
- 大纲
启示录—打造用户喜爱的产品
最终
个人读后感
产品大不易，也有大乐趣。不忘初心，保持纯粹，用户至上，克制谦逊，没有彼岸，砥砺前行
前面
好产品具备三个基本条件：价值、可用性、可行性，缺一不可。
成功产品遵循的十条规律
产品经理的任务：探索产品的价值、可用性、可行性
定义产品需要产品经理、交互设计师、软件架构师通力合作
开发团队不擅长用户体验设计，他们想的是实现模型，用户看中的是概念模型
用户体验设计就是交互设计、视觉设计（对于硬件则是工业设计）
功能（产品需求）和用户体验设计密不可分
产品创意必须尽早的、反复的接受目标用户的试用，以便获取有效的用户体验
为了验证产品的价值和可用性，必须尽早地，反复地请目标用户测试产品创意
采用高保真产品原型是全体团队成员了解用户需求和用户体验最有效的途径
产品经理的目标是在最短时间内把握复杂的市场/用户需求，确定产品基本要求——价值，可用性，可行性
一旦认定产品符合以上基本要求，他就是一个完整的概念，去掉任何因素，都不可能达到预期结果
正文
人员
关键角色及其职责——现代软件产品团队
产品经理
主要职责：评估产品机会（确定需求），定义要开发的产品（整合需求）
用户体验设计师
关键角色：交互设计师，UED
目标是确保产品同时具有可用性（用户明白如何使用产品）和价值（用户对产品的渴求程度）
项目管理人员
核心任务是制定计划和跟踪进度
开发团队
负责开发产品
IT团队通常指为内部员工提供技术支持的团队
开发团队指为外部客户开发和维护产品的团队
运维团队
负责保证服务正常运行，需要一系列专业技能
产品营销人员
对外发布信息、宣传产品，为拓展市场销售渠道、组织重点营销活动（如在线运营）、促进产品销售提供支持
团队成员构成比例
通常，每5-10位开发配备一位产品经理
一位交互设计师大约支持两位产品经理的工作
一位视觉设计师可以支持四位交互设计师的工作
凡超过十名开发人员参与的重大项目，就应该配备专职的项目经理
如采用火车模型发布模式（固定周期持续开发，既定功能未完成就挪到下个周期发布，这类产品一般由多个项目组成），必须为每次产品发布配备专职项目经理
产品管理与产品营销——两者不是一回事
产品经理的工作是从细节上定义开发团队开发什么产品，市场营销是对外宣传产品，两项工作天差地别
三种误区
由市场营销人员定义产品：忽略了收集详细产品需求的步骤，回避定义产品的艰难决策过程，绕开了用户体验设计
两人分担定义产品的工作：指营销人员负责收集高层业务需求，产品经理负责收集低层产品需求。这种模式基于错误的观点：认为可以脱离具体需求（尤其是脱离用户体验）来定义高层需求
一人兼任两项工作：管理产品与推广产品都对产品的成功至关重要，都需要专业技能，即便具有两种技能，也没精力打理好两边工作
出路
必须清晰定义产品经理和产品营销人员的职责
营销人员是产品经理获取产品需求的重要来源
产品经理是营销人员获取市场营销信息的重要来源
所有成功的产品背后都有一个全权负责定义产品的人
谨记，如果产品经理定义的产品没有价值，不具备可用性和可行性，那么无论开发团队多么出色也无济于事
产品管理与项目管理——互联网让两者变得不同
产品管理涵盖项目管理，适用零售软件产品但不太适合互联网服务类产品
火车模型发布模式与本书相关要点：每次发布都需要强有力的、有效的项目管理，不局限于具体项目，必须统筹全局。每次发布可能包含多位产品经理负责的功能，要协调发布管理、程序开发、网站运维、客户服务、产品管理各个方面。
对互联网公司而言，两种职责分开至关重要，必须不断推动项目，否则产品发布就会延期
怎样成为优秀的项目经理，优秀项目经理七个特点
工作紧迫感
善于捕捉问题：迅速、准确的指出问题及其要害
思路清晰
用数据说话：时间紧迫的情况下最容易凭直觉草率行事，项目经理务必坚持根据数据和事实制定决策
果断
判断力：以上特点都基于良好的判断力
态度：绝不为自己找借口，必须克服所有障碍，解决所有问题
产品管理与产品设计——理解用户体验设计
产品设计对产品的重要性，好产品必须提供舒适的用户体验
产品设计的分工与角色（一人可能承担多项）
用户研究：研究、分析用户，评估产品或原型是否符合用户使用习惯
交互设计：理解目标用户的基础上设计有价值的、可用的目标功能，用户导航和产品使用流程
视觉设计：根据交互设计的线框原型图设计用户界面，包括严格的布局、颜色和字体设置等。传达并唤起产品蕴含的情感（重要性往往被低估）
产品原型制作
对大型产品来说，四种角色缺一不可，小型产品可以让一位设计师身兼多职
用户体验设计外包，一定程度上是可行的，但交互设计不能外包
产品管理与软件开发——定义正确的产品与正确的开发产品
产品经理负责定义正确的产品，开发团队负责正确的开发产品，双方互相依赖
产品要求开发完成任务，必须先取得他们的认可，确信为了达到产品质量标准必须这么做
开发团队也要留给产品足够空间，设计有价值、可用的产品
双方相互促进，开发最清楚产品设计是否可行，可以帮产品经理完善产品定义
开发帮产品经理完善产品定义的方式
让开发直面用户，体会用户的困惑和疑问，了解问题重要性
向开发了解最新的技术发展方向，讨论哪些新技术可以用到产品里，头脑风暴
让开发在定义产品的初期阶段参与评估，协助策划方案
产品经理也应该配合开发人员的工作
产品经理只定义满足基本要求的产品，而不是最终产品
一旦进入开发阶段，要尽可能避免修改产品的需求和设计，千万不要在此时尝试突发奇想的点子
开发阶段出现问题时，如用例设计考虑不周全，产品经理应迅速采取行动，在维持产品基本功能、尽量避免修改的原则上，拿出解决方案
如何与异地开发人员沟通
借助高保真原型
必须有人在本地负责与异地团队的协调工作，明确异地团队只接受他的命令
每个季度，产品经理应至少前往异地与开发团队见面，工作一段时间
交换人员也是一种有效的方法（主程序与产品经理）
产品外包
外包不是为了节约成本，而是为了实现合理的人员配置。所以才要超越地理局限，雇佣其他地区国家的员工，实现最佳组合
业务外包的关键是要挑选有能力的员工
程序员想重构代码？
软件架构存在功能极限，迫使开发团队满负荷工作，一旦超过崩溃临界点，就会造成无法挽回的结局
在产品管理上为开发团队预留20%自主时间
如果已经身陷困境怎么解决
针对开发确定的产品修改目标制定切实可行的计划和时间表
尽可能把重写目标分为几大块，递增修改，让用户感受到产品的改进——对保持产品市场占有率至关重要
必须谨慎选择正确的产品特性，确保产品定义的正确性
招聘产品经理——寻找出色的产品经理
优秀产品经理的需求
个人素质和态度：技术可以学习，素质难以培养
对产品的热情：对产品有一种本能的热爱，把生活中一切都看成产品
用户立场：融入目标市场，换位思考，从用户的角度去思考
智力：勤奋是必须的，但远远不够，必须具备敏锐的头脑
职业操守：绝不适合贪图安逸的人担任，产品工作无法用时间衡量，付出多少都不为过
正直：必须通过行动影响说服身边同事，培养信任和尊重
信心
态度：为产品最终成败承担全部责任，绝不找借口
技能：可习得
运用技术的能力：必须有能力理解技术，发掘技术的应用潜力
注意力：足够强的自律性，遵守公司制度，并严格要求自己，保持专注
时间管理：合理规划安排时间
沟通技巧：产品经理只能以理服人，绝不能靠职位压制
商业技能：比如能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌等
去哪里招聘
最有效的途径是寻找具有上述特征潜力的人，通过培训课程和传帮带把他们训练成高素质的产品经理
行业经验是否重要
资深行业经验对产品经理的工作来说可能是不利的：容易盲目自信，自以为了解用户
但了解产品领域知识是绝对必要的
产品经理大约有80%的技能和天分可以用于不同类型的产品
最宝贵的经验不是行业知识或技术（都可能会过时），而是打造优秀产品的流程、领导产品团队的能力、应对产品扩张的经验、个人对自己的认知，以及自我激励的能力
高科技产品行业虽然要求快速学习新技术，但更重要的是预见如何应用技术合理地解决问题
年龄不是问题
管理产品经理——建设公司从建设团队开始
管理产品经理的人通常被冠以产品总监和产品副总裁的头衔
产品总监的关键职责
组建优秀的产品经理团队
规划公司的全局产品战略，对产品组合负责
建设产品管理团队
如果产品经理无法胜任工作，就要立即采取行动，有些人永远不可能成为称职的产品经理，确保每个团队成员都没有掉队
产品经理必须经过约三个月的刻苦学习才能开始管理产品，他要融入目标用户和客户群，学习相关技术，了解市场和竞争局势。管理者应该为新人创造学习条件，监督学习进度
设计一套培训计划
如果某位产品经理无法胜任，管理者应该重新寻找合适的人选，解雇别人并不容易，但这是你的职责所在
一旦找到有潜力，称职的人选，就应该放手让他们工作，尽情发挥其潜力
必须确信产品经理有足够的能力，才能授权
聪明的产品总监知道，团队成员的出色表现就是自己的出色表现，所以要雇佣比自己聪明的人，尽可能为他们创造宽松的工作条件
规划公司的产品战略
必须透彻理解公司最新的商业战略，确保产品战略直接支持商业战略
带领产品团队建立产品原则，坚持按产品原则研发产品
产品总监必须设法识别、解决内部产品优化需求间的冲突
产品总监要处理好与公司同事的关系，特别是得到高管（尤其是CEO）的信任
必须礼贤下士，集思广益，决策有理有据、公开透明
极具挑战的工作，该岗位上的人无一例外是公司最优秀的员工
怎样评估产品经理的工作
唯一正确的评价标准是看产品本身是否成功
用户净推荐值（net promoter score，NPS），反映了用户对产品的态度
用户是否愿意向他人推荐你的产品，满分10分
9-10为推荐者，7-8为中立者，0-6为贬损者
NPS=推荐者占比-贬损者占比
口碑营销是最有效，成本最低的营销方式
产品管理属于哪个部门
产品管理部门与开发、市场部门同级别
理想情况下应包含设计团队
巴顿将军的忠告——目标管理
永远不要告诉别人怎么做。告诉他们做什么，他们自然会发挥天赋，给你惊喜——乔治·史密斯·巴顿
产品经理收集需求时，常听用户建议”如何做“，而不是”做什么“
产品经理习惯告诉用户体验设计师如何设计产品，而不是告诉他们产品要“做什么”
留给UED和开发的空间越大，他们越有可能打造出用户喜爱的产品
产品副经理——办公室里最聪明的人
产品经理需要好点子，但仅靠自己，会严重限制创意的发挥
做产品要找公司最聪明的人合作，听取他们的意见，还可以向领导借力
如何发现他们
多和同事聊聊
走动式管理模式，花时间与员工相处
认真倾听与会者的对话和发言
敞开办公室大门，欢迎大家随时提产品建议
坦率的把你的烦恼告诉同事
一起泡吧，抽出时间与同事一起休息娱乐
记住，公司的目标是打造卓越的产品，所有可借用的力量都是可取的
管理上司
十条经验，缓解因上司问题造成的产品困难
为项目波动做好准备：提高警惕，记录工作进度，掌握项目波动规律，寻找对策。制定项目计划时，预留时间应对变化和调整，做好“无用功”的准备，也有助于挖掘待改善的细节
注意沟通的方式和频率：弄清上司喜好，对症下药
会前沟通：公司高管过多，可以在会议前找与会的高管沟通，提出观点，征询意见，确保会议召开前已经达成一致意见。正式会议的作用只是让与会人员认识到大家取得了一致意见
多提建议，少谈问题：最好根据问题重要性列举多种解决方案，并附上你的依据和建议
向上司借力
充分准备：管理者通常聪明过人，能立马发现你思维和计划上的漏洞，准备充分，找到问题所在，有备无患
缩短邮件篇幅
多用数据和事实说话：如果我们依照个人看法做决定，那就是臆断。多做准备工作，收集事实和数据，你的建议才有说服力
内部宣传：充分有效的宣传，可以大大降低与其他部门合作的成本
做让领导省心的员工：思考如何节省上司的时间
流程
评估产品机会——确定待解决的问题
评估产品机会的目的：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源
评估产品机会，产品经理需要回答十个问题
产品要解决什么问题？（产品价值）
为谁解决这个问题？（目标市场）
成功的机会有多大？（市场规模）
怎么判断产品成功与否？（度量指标或收益指标）
有哪些同类产品？（竞争格局）
为什么我们最适合做这个产品？（竞争优势）
时机合适么？（市场时机）
如何把产品推向市场？（营销组合策略）
成功的必要条件是什么？（解决方案要满足的条件）
根据以上问题，给出评估结论（继续或放弃）
评估结果出来后，呈报公司高管，讨论决定是否开发此产品
产品经理往往把待解决的问题和解决方案一起考虑，当具体解决方案遇到困难时，会放弃产品机会，这是典型的“把洗澡水和孩子一起泼掉”的做法
开发新产品还是维护旧产品
开发新产品能为老用户提供更多的选择，还能吸纳新用户
改善原有产品能提高老用户满意度，也能吸纳新用户
关键在于比较两者的机会，产品团队一视同仁的评估两者间的收益与成本，管理团队作出决策
钱花在哪儿
理解产品的盈利模式
结交财务部门的同事益处
帮你了解产品
帮你了解用户
确认商业上的可行性
产品探索——定义正确的产品
软件项目可分为两个阶段：弄清要开发什么产品（定义正确的产品）；开发该产品（正确的开发产品）。第一个阶段探索产品，第二个阶段强调执行
一旦进入开发阶段，产品团队就要切换工作重心。重心在于执行——开发，测试，发布
产品经理必须在执行阶段转换工作重心
流水线方式并行发产品：上版本进入开发阶段，就开始定义下个版本
探索产品的进度可控么？
软件产品行业存在一种根深蒂固的偏见，认为分析需求和设计产品的工作是可预测的、可控制的
定义产品本质上是创造性的工作，更像一门艺术而不是科学
两个观点
产品经理应该探索是否有用户需要产品，也就是说要寻找市场，让用户验证你的构思
产品经理要探索能解决问题的产品方案，它必须是有价值的、可用的、可行的。设计解决方案，请用户和开发团队来验证
用实际产品搭上全部开发时间来进行产品探索，开发的是一款非常昂贵的原型，且让不知情的用户掏钱参与测试，这种一般需要几个版本后（两年）才能实现盈利
应该重视产品探索流程，在确定有价值的、可用的、可行的产品解决方案后，再全面转入执行阶段
产品原则——确定什么最重要
产品原则是对团队信仰和价值观的总结，用来指导产品团队作出正确的决策和取舍。体现了产品团队的目标和愿景，是产品战略的重要组成部分。从形式上看，是一系列明确的、体现团队特色的产品价值准则。
制定产品原则容易出现的两类错误：
原则过于空泛，失去指导作用
把设计原则误当做产品原则
解决意见冲突——让大家在几个要点上达成共识：
究竟要解决什么问题
要为哪类人物角色解决这个问题
产品要达到什么目标
每项目标的优先级是什么
务必认真分析产品目标优先级，让团队达成共识。不可囫囵吞枣的把所有目标都贴上“关键”和“重要”的标签。一定要区分什么是第一重要，什么是第二重要
制定决策的过程和依据必须完全透明，不要让人觉得你只凭直觉判断。务必告诉大家决策的依据和理由，清楚的展示每一个决策环节
产品评审团——制定更及时、可靠的产品决策
产品评审团：让决策者和相关人员及时作出明智产品决策的机制
难点在于既要为高管制定产品决策、监督产品流程提供透明的信息，又要避免高管插手干预产品团队具体工作，比如亲自参与产品设计
产品评审团的工作目标
决定产品战略方向，从宏观上监督公司产品的研发流程，合理配置资源
不制定公司商业战略，而是在给定的商业战略下，提出与之相匹配的产品战略
产品评审团的决策直接影响企业的运营
产品评审团的成员组成
首席执行官/首席运营官/部门经理
产品管理总监/副总监
用户体验设计总监/副总监
市场总监/副总监
开发总监/副总监
网站运营总监/副总监
客户服务总监/副总监
确保每个关键部门都有代表参加产品评审团，且只选一人代表部门陈述观点
产品评审团的职责：根据研发产品的四个里程碑来评审产品，制定决策
评审产品战略的产品路线图，启动评估产品机会的工作。即选择值得投入精力的产品，请产品经理开始评估产品机会
根据评估产品机会的结果，决定是否开始定义产品的解决方案
评审产品原型、用户测试结果、成本估算明细，决定是否开发产品
评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品
注意事项
小公司的产品评审团通常负责评审公司所有的产品，大公司可能需要根据业务单位大小，设立若干产品评审团
产品评审团不负责评审对产品细节的更新或修正。这是为了加快对细节问题的处理，保证公司业务流畅运作
产品评审团不负责具体产品设计工作。如果产品存在缺陷，应该由产品团队着手处理，然后重新提交产品评审团评审
在2号里程碑处，由于产品解决方案尚未形成，不可凭直觉估算成本，至多只能估计大概项目规模；但在3号里程碑处，应该仔细估算开发时间和成本，让公司上下做好准备
尽量避免产品评审团讨论具体执行策略，讨论这些问题非常费时间。如果必须讨论，一定要控制好时间，不要影响监督产品流程的主要工作
产品评审团开会频率取决于具体产品进度，可以每月开一小时会议，也可以每周开两小时会议
产品评审团应该回顾、分析产品上市后表现，反思之前的决策是否明智，今后该如何调整
每次评审会议，最好由产品经理向产品评审团汇报产品进展情况。由产品经理的直接领导指导准备陈述的内容，确保产品经理准备充分。会议召开前，产品经理最好逐一向评审团成员简要汇报，存在疑问及时解决，避免在汇报过程中措手不及
何时估算项目成本
开始研发前，先评估产品机会，看产品创意宣称要解决的问题是否有价值。此时只能大致估算项目的规模，再根据规模粗略估算项目成本
确认产品机会有价值，粗略估算的成本可以接受，管理层才能允许项目组着手定义产品解决方案。理想情况下，方案包含可供用户测试的高保真原型
定义解决方案过程中，产品经理和交互设计师需要一位开发人员的协助来评估不同解决方案的成本。然后两者再根据评估结果进一步调整解决方案。形成完整的产品说明文档后，即可根据文档细节生成详细、可靠的成本估算结果
管理层决定是否开发产品
特约用户——产品开发伙伴
大众对无人问津的产品非常谨慎，要么怀疑其质量，要么认为还不成熟，谁都不愿意第一个吃螃蟹
用户希望看到他人使用的效果后再尝试
需要解决的两个问题和方法
深入洞察目标用户的需求
赢得用户对产品的推荐
方法：征集特约用户（也叫用户顾问委员会、用户评审团）协助完成产品研发
具体：项目开始阶段物色至少六位积极、活跃、乐于分享的的目标用户（可以先招募6-8人，再筛选），要求是他们在产品的目标用户中具有一定影响力。至于他们是否使用过公司原有产品并不重要，只要他们认为未来的产品可以解决他们手头亟待解决的问题就行
成为特约用户的好处
参与构思产品创意，解决他们手头的问题——他们最清楚产品要解决的问题，因为这些麻烦正困扰他们
提前使用产品，越早使用产品意味着越早解决麻烦
通常，提前试用产品还可以显著降低用户各种成本
产品经理的收获
聚拢一批积极用户，他们可以为定义产品和开发产品提供建议和协助
提供调研便利，便于产品经理去特约用户的工作场所调研，如果是平台产品，便于产品经理去开发人员的工作地点调研
可以定期组织特约用户进行小组讨论
特约用户第一时间试用、测试产品，迅速反馈意见
如果特约用户满意产品表现，会乐意公开推荐产品
组织特约用户的注意事项
不要向特约用户收取参与费用，否则合作关系会变味
特约用户的人数绝不能超过十个，否则产品经理不可能有时间和精力与每位用户深入沟通
如果寻找特约用户时遇到困难，很可能是因为产品要解决的问题不像产品经理想象的那么重要，产品经理应该重新考虑产品计划
确保特约用户是潜在目标用户
务必向特约用户说明，要开发的是面向大众的产品，不是为某家公司开发的定制产品。承诺产品不是昙花一现
产品经理应该把特约用户当成开发伙伴，视他们为同事，互相帮助
产品经理与特约用户的合作贯穿产品研发每个环节：向他们展示产品原型，请他们参加测试，向他们请教产品细节问题，让他们帮你部署、测试待发布产品的备选版本
正式发布前，一定要先请特约用户试用，确保每个人都满意
产品经理要和营销团队紧密合作，一方面营销团队可以帮助物色特约用户，另一方面可以协助提高特约用户受关注的程度
平台产品，特约用户的作用更为突出，不过用户要换成应用。产品经理要与特约应用开发者紧密合作，确保在平台上构建的应用让用户满意，最好鼓励应用开发者发展自己的特约用户
注意
互联网服务，特约用户人数应该增加到10-15人，不过要保证产品经理有足够精力充分了解每位特约用户，以及他们使用服务的环境
从营销角度，大众消费者更容易受媒体和网站评论影响
使用特约用户是确保产品不偏离用户需求最简单有效的办法，同时也是在向用户潜在用户宣传、推荐产品的最佳手段
该不该与用户交流
无法想象不深入理解用户需求，特别是禁止与用户面对面交流的情况下，产品经理怎样打造出让用户满意的产品
产品经理应该尽可能的亲自拜访用户，与用户交流
产品经理应该充分利用公司资源，请人协助工作，但唯有理解用户需求的工作，产品经理决不能推诿他人
与用户打交道的过程中，会发现一些富有洞察力，善于思考的用户，应该设法与他们建立长期联系，他们是特约用户的最佳候选人
关于用户研讨会
用户研讨会不可能讨论出成功的产品
用户不知道什么样的想法是可行的，多数用户对现有技术一无所知
用户不知道自己想要什么，没见到实际产品，用户很难凭空想象自己需要什么
用户研讨会的弊端
人群聚集容易冲动，相互影响，很难获取每个用户的真实想法，取而代之的是那些善于表达者的一家之言
除非让用户试用实际产品，否则他们不清楚自己想要什么，而通常组织用户研讨会时产品还没有眉目
组织用户研讨会也需要经验。主持人不但要熟悉组织技巧，能随机应变，还要掌握产品领域知识，擅长引导话题
比起了解目标用户的需求，用户研讨会更适合搞政治运动
如果必须要组织，务必让产品经理亲自参加，杂事可以外包，但收集信息和分析数据的工作绝不能
市场调研——理解市场调研的作用和局限性
市场调研的作用
市场调研的工具和方法
用户调查：一，设计调查问卷需要技巧和经验；二，调查结果为获得解决方案提供了一条途径，但不是解决方案本身
产品使用分析：记录用户使用产品的行为
数据挖掘
拜访用户：实地考察的作用无可替代，但出于对资金和时间成本的考虑，谨慎使用
人物角色：找出若干主要用户类型，深入了解他们
可用性测试：尽早、反复的进行可用性测试，观察用户使用现有产品的反应，收集反馈意见，了解他们真实的想法
同类产品分析：找出竞争对手的优势，学习对手的成功经验
可以回答以下几个关键问题
谁是目标用户
用户会怎样使用产品
用户能想明白怎样使用产品么，障碍在哪里
用户为什么选用你的产品
用户喜欢产品的哪些特点
用户希望如何改进产品，增加哪些功能
市场调研的局限性
不能直接回答最根本的产品问题：打造什么产品
市场调研的结果可以作为研发产品的依据和参考，但不能决定产品研发方向
定义产品的过程要回答以下问题
采用什么技术来更好的解决产品要解决的问题
设计什么样的用户体验
成功的产品基于以下两点认识
深入理解用户需求
明白什么样的解决方案在现阶段是可行的
市场调研可以用于完善现有产品，精益求精，但不能用来定义新产品
产品任务角色——理解目标用户
产品管理的核心在于制定决策：应该抓住哪些机会，解决什么问题，哪些功能最有价值，谁是主要用户
人物角色又称用户特征记录（user profile），指通过与用户沟通交流，确保典型的目标用户类型，在理解各类目标用户的特征基础上建立的人物原型。是合理地描述用户特征的人格化虚拟原型，重点关注用户的行为、态度、目标
产品经理必须深入参与创建人物角色的工作，尤其要亲自参与用户交流和用户调查。产品经理、交互设计师、用户研究团队之间必须密切合作
作为产品管理的工具（营销和交互人员使用的目的和功能不一样），人物角色主要功能如下
筛选重要产品功能。面面俱到的产品往往一无是处
避免产品团队把自己的需求当成用户需求
有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的地方
方便向团队描述产品的目标用户，他们怎样使用产品，关心产品的哪些方面
和产品原则一样，可以帮团队成员达成共识
注意事项
正视为产品挑选关键人物角色的难题，宣称产品老少皆宜是自欺欺人，每个版本应该强调针对一类目标用户，把产品的优势发挥到极致
与目标用户面对面交流是创建人物角色必不可少的环节
邀请多样化的用户参与产品原型测试（关键的人物角色之外的用户）
重新定义产品说明文档——安息吧，纸质说明文档
产品经理的核心责任是确保向开发团队交付具有成功潜力的产品说明文档
理想的产品说明文档应该满足以下要求
完整的描述用户体验——不只是用户需求，还包括交互设计和视觉设计
准确描述软件的行为
必须以直观的方式把产品信息和产品行为告诉所有人
可以修改
有一个主体来代表产品，避免混淆不清（撰写产品说明文档过程会出现许多衍生物，如需求列表、线框图、实体模型）
只有一种形式的产品说明文档可以满足以上所有要求——高保真产品原型
真实体现用户体验
尽可能体现产品细节，包括所有页面和主要用例
用例可以作为有效的补充，用来描述重要的产品行为
最突出的优势是可以用于测试
可以缩短产品上市时间
用户体验设计与实现——先定义用户体验再动手开发
用户体验设计和软件开发不能放在一起进行，原因如下
一旦产品进入开发阶段，再修改设计思路非常困难，越往后修改成本越高。事后修改软件架构，无异于推翻重来，非常打击开发人员斗志
用户体验设计要保证产品同时具备可用性和价值，必须尽早、反复验证设计思路，软件开发的迭代周期过久
验证设计思路必须用高保真原型。产品原型应该可以随意修改，完成其任务后应该被丢弃，而开发中的产品应该以固定原型为基础
产品开发可以分成多次迭代，用户体验设计却不能拆分。设计师必须全面的、连贯的看待用户体验。让用户放弃不可用的软件很容易，要他们放弃使用习惯很难
用户体验设计不一定是最费时间的工作，但至少需要一两周时间
如果两者同步展开，多半会出现设计师和开发人员一方赶工，一方无事可做的局面
需求调研和产品设计可以同步展开，产品开发和测试可以交互进行，但用户体验设计应该在软件开发前完成
第零次迭代（sprint zero）
只有在开发人员要开发大量后台基础软件情况下，两者才能并行展开
基本产品——削减功能还是延长工期
更合理的产品设计方式
产品经理与设计师设计产品的高保真原型，该原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力
邀请一位主要开发人员参与设计原型，检查原型，帮助估算各种功能的直接成本和间接成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能，这样开发团队心里也有底了
请真实用户验证（测试）产品原型至关重要
设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品
产品验证——证明产品的价值、可用性、可行性
在正式发布、部署产品前，验证产品说明文档描述的产品是否符合预期要求
产品经理向团队提供最终的产品说明文档前，需进行三项重要验证
可行性测试：明确现有技术条件下，能否成功开发出产品
可用性测试：交互设计师与产品经理密切合作，想方设法突出产品功能特性，让不同类型用户都能明白如何使用。最好规划多次迭代测试，确保实现最佳用户体验效果
价值测试：可以和可用性测试同时进行，不过一个重在观察用户如何设法完成必要的操作，而价值测试重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式
原型测试——把产品创意呈现给真实用户
使用产品原型主要原因：让用户验证产品创意，加深产品经理对产品的理解，避免开发团队浪费时间和精力开发没有把握的产品
物色测试者
如果有特约用户，可以邀请他们参加测试
如果是企业级产品，同类产品的展销会是寻找目标用户的好去处
可以在分类信息网站上发布广告，征集测试者
如果是大众产品，可以邀请自己的亲朋好友参加。但要避免过于亲密的人和科技行业的从业者，除非他们就是目标用户
如果手头有用户的电子邮件列表，可以从中筛选，营销团队可以帮助缩小名单范围
可以通过公司网站征集，但还是需要打电话联系筛选，避免全是尝鲜者
建议较大的公司定期开展原型测试活动，让所有产品经理自己申请时段
到街头巷尾，到用户聚集的地方去，可以送些礼物表示谢意，注意放低身段
如果邀请测试者上门测试，尤其是出于商业目的，应该补偿测试者为此损失的时间
测试前一天致电测试者，可以减少爽约情况
准备测试
事先拟定好测试内容
只有一次机会了解测试者未接触产品原型之前如何解决产品要解决的问题，在给原型之前要珍惜观察他们思考解决问题的方式的机会
测试原型前，观察测试者能否从原型首页看出产品要解决什么问题，哪些地方最吸引他们（对他们有价值）
完成测试后通过聊天进一步收集信息，沟通的目的是了解测试者对产品原型的评价
为每个问题的答案打分，或者干脆让测试者用数字回答问题，以此记录每个阶段产品原型的表现
不必等到完整原型完成后再测试，可以先测试主要项目
测试环境
正规的测试实验室通常会配备单向透明镜和闭路监视器，并配有多个摄像机同时拍摄用户和电脑显示屏幕
用户的办公室也是上佳测试场所
有些工具支持远程测试，但面对面的测试是不可替代的
产品经理应该亲自参加每次原型测试，尽可能多的与用户接触，观察他们使用原型的反应
优秀的产品经理和交互设计师必须克服忠言逆耳的心理障碍，客观对待测试，明白自己的产品设计不可能完美
测试主持人之外，还需要其他人记录，可以邀请开发、交互设计师 、甚至高管
测试原型
测试前不宜与测试者交谈过多，避免透露过多产品线索，测试结束后再深入交谈
寒暄后务必告诉测试者：这只是产品原型，不是正式产品，请说出真实看法，被测试的对象是原型，测试者不必担心测试失败，只有原型会通不过测试
测试时，尽量让测试者保持平和情绪，千万不要让他们陷入吹毛求疵的状态。多观察用户操作，少听他们的抱怨
测试时尽量保持安静，不要给测试者提示
一般有三种结果：测试者在没有任何提示的情况下顺利完成测试；测试者遇到麻烦，通过反复尝试最终完成项目；测试者受挫，放弃
尽量避免提示测试者，更不能引导他，当测试者迷茫时可以问问他们在找什么
测试主持人不妨向鹦鹉学习，使用自言自语的技巧，口述他们正在做的事，另外要避免带有主观情绪的用词
测试的作用是理解目标用户如何看待产品要解决的问题，发现原型与用户期望不一致或不相容的地方，也就是原型不符合用户直觉和习惯的地方
从测试者的肢体语言和语气里可以发现许多有用的信息
更新原型
只要两三个用户反映了同一个情况，就可以动手解决，没必要让所有测试者都完成测试后下结论
判断原型何时结束：如果有连续六位测试者理解和欣赏产品价值，而且能完成关键测试项目，就算完成了原型测试任务
如果没法让测试者对原型产生兴趣，或是无法让原型变得足够简单易用，让测试者理解其价值，应该立马收手，放弃这个产品创意
改进现有产品——不是一味的添加功能
改进产品不是简单的满足个别用户的要求，也不能对用户调查的结果照单全收。能提高指标的功能才是关注的重点，应该找准方向，分析关键指标，有针对性的改进
平滑部署——避免更新产品导致用户反感
毫无征兆的更新不必要的版本会令用户产生反感
事前没收到更新通知，用户觉得措手不及
用户没时间学习、适应新版本，产品公司也没有提供旧版本方便用户在过渡阶段使用
新版本无法正常运行
新旧版本不兼容（比如新版本无法访问旧版本数据）
用户认为添加的功能和特性毫无必要
应付接二连三的版本更新，用户感到疲惫不堪
新版本修改了用户已经习惯的使用方式和操作流程，用户不得不重新调整适应
矛盾
通常情况下用户不喜欢变化，他们希望产品更完善，功能更丰富，但前提是不改变已有的使用习惯，大多数人不愿意花时间学习、适应新的使用方式
我们的工作要不断地推陈出新
将版本更新带来的负面影响降到最低，可以采取的措施
通过公告、群发邮件、在线教程等方式提前通知用户，但效果有限
加倍做好测试工作，避免新版本存在影响正常使用的隐患
如果新版本会影响大规模用户，应该采取并行部署或者增量部署的方式来降低风险
平滑部署
并行部署：发布并行版本，让大部分用户习惯新版本后再将新版本设为默认版本，同时将旧版保留一段时间，公示为旧版本提供支持的最后期限
区域性逐步部署：在某个区域内部署新版本，逐步扩大
增量部署：将更新项分割为几个较小部分逐步发布
优秀的产品和服务可以赢得用户好感，这是宝贵的信任，应该小心保护。不要轻易试探用户耐心，让好感变成反感
快速响应阶段——产品出炉后切莫虎头蛇尾
发布产品不等于大获全胜，交付产品后依然需要保持高度警惕
产品发布后几天至一周内，所有项目成员应留出时间作为快速响应阶段。主要工作是快速响应、处理产品发布后的用户反馈意见
关键不在于是否会出现问题，而在于能多快解决问题
合理运用敏捷方法——十大敏捷方法
以下诀窍只适用于产品软件团队，不适用于定制软件团队
1，产品经理也担任产品负责人，需要与开发团队保持密切联系，协助督促开发进程，及时解决出现的问题
2，使用敏捷方法绝不等于省略产品规划。产品经理仍要明白产品方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境下，规划周期应该适度缩短，反复迭代，采用轻量级机会评估方法替代冗长市场需求文档
3，产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，始终让开发人员参与评估产品好产品原型，及时反馈关于可行性、成本、解决方案的建议
4，尽量将产品设计工作拆分成独立部分，分而治之，但也不能太细
5，产品经理主要任务是定义有价值、可用的产品原型和用户故事，作为开发基础。用产品原型和用户故事代替需求文档和功能说明文档有三个优势
可以请用户测试
强迫产品经理全面认真思考问题
向开发团队明确描述每次迭代周期需要完成的任务
6，让开发人员自主划分迭代周期。开发团队必须考虑产品质量、性能、扩展性，应该让他们自行决定如何划分迭代周期
7，产品经理和交互设计师必须出席每天晨会。晨会是一天沟通的开始，而不是结束。设计师向开发和测试展示产品功能，开发互相展示完成的代码，让测试测，让设计师和产品经理过目，测试和开发在制作原型阶段识别潜在问题，协助产品经理制定更合理的决策
8，除非达到产品经理的要求，否则不要轻易发新版本
9，每次迭代完成后，产品经理应向团队展示产品现状和下次迭代的产品原型，让大家看到工作成果，同时加深大家对产品理解增强团队对这种开发方式信心
10，在团队内展开敏捷培训。只有每位团队成员都真正理解敏捷方法，你才能把工作重心放在执行上
迭代初期的产品不能用作原型
用一个迭代周期来验证产品创意时间太长，效率过低
定义产品阶段，开发团队有许多重要工作要做，不应占用他们时间开发产品原型，会消耗开发正式产品的经理
一旦进入开发阶段，设计出软件架构，再想改变产品设计思路，成本和难度都太高了
敏捷开发起源于定制软件产品。要想成功转型为敏捷开发团队，选一位合格的敏捷教练相当重要，他必须理解产品软件和定制软件差别，了解产品软件特殊需求
合理运用瀑布式开发方法——扬长避短
瀑布式开发方法的基本原则
采用阶段式开发：开发过程事先被分成固定几个阶段：撰写书面需求文档、设计高层软件架构、设计低层细节、编写代码、测试、部署
采用阶段式评审：每个阶段结束后，对该阶段提交的成果评审，通过才能进入下一阶段
正式形式：参考美国国防部开发标准2167A和后来的标准498
非正式形式：更常见，市场人员收集市场需求，提交开发人员制订开发计划，设计软件架构，完善设计细节，然后进入开发测试阶段，完工后邀请用户测试，最后部署
经久不衰的原因
可预测性，深受管理层认同。只要能准确理解需求和技术，而且需求不再变更，开发团队就能为大规模、复杂的项目制订精确开发计划
每个阶段会提交书面材料，会让人觉得所有工作都是经过深思熟虑的，才能放心。这些材料一定程度上增强人们对项目信心。
让产品经理头疼的地方
产品验证严重滞后
变更计划代价不菲——任何对前期决策的修改都会打乱开发流程，大量工作需要从头来过
无法适应快速的市场变化——严重依赖文档和流程，一点点小小的改动都用大费周章
瀑布式开发需求预见所有问题，全面把握需求，实践证明除非是规模很小的项目，否则瀑布式开发很难顺利执行
如果不得不使用，应设法避免以上问题，在定义产品阶段，制作产品原型请目标用户试用，确保产品设计是有价值的、可用的、可行的
创业型公司的产品管理——关键在于产品探索
两个关键点
创建体现用户体验的高保真原型
邀请真实目标用户验证产品原型
确定产品原型后再招程序员进行开发
大公司如何创新——有困难，但值得一试
影响大公司创新氛围的两大因素：企业文化和老板的观念
尝试在公司实现创新的方法
20%法则：20%的工作时间可以用来进行创新研究。最好的创意大多来自普通员工，该法则可以鼓励员工自己尝试各种想法，发挥主观能动性
臭鼬工程：利用自己时间，低调进行创新研究
主动观察：创新不是发现新问题，而是用新方法解决已有的问题。观察实际用户对现有产品的反馈，是创新的最佳途径
改善用户体验：调出技术局限，完善用户体验，剔除多余功能。找到用户实物的地方，就找到了创新的机会，至少是改善产品的机会
收购小公司：收购是有效维持创新的手段，但要妥善安排收购的来的新员工，让他们继续发挥特长。创业公司在选择收购自己的东家是，并不只看重价格，往往会选择有过合作关系的公司
在大公司施展拳脚——十大秘诀
大公司的现状
大公司都遵循一条潜规则：尽量规避风险
大公司都采取矩阵式管理方式：核心部门（如设计、开发、测试、运维、市场）是共享资源，产品经理要确保争取到足够资源
十个方法
了解公司制定决策的方法：适应并善用
建立人脉网络：大公司必须与人合作，主动帮忙积累人脉
臭鼬工程：利用空余时间
自己顶上：有时需要自己顶上，一切为了推出产品，不计较个人得失
有选择的据理力争：与人辩论，小心措辞，对事不对人，除非对你极为重要，值得据理力争，撕破脸皮也在所不惜，否则不要随便发脾气
会前沟通，形成默契：重要决策会议前设法取得一致意见
合理分配时间：信任同事，专注自己本职工作
分享信息：有舍有得，分享信息会让你获得更多的朋友和资源
向上司借力
传播你的产品理念：不要低估内部宣传潜移默化的作用
大部分人游荡在黑暗里，他们只知道抱怨，却从不想办法寻找点灯开关
产品
苹果公司给我的启示——另类的硬件公司
硬件为软件服务
软件为用户体验服务——用户体验是产品立足根本
用户体验为情感服务——抓住用户的情感需求
产品为真正的需求服务
堤防有特殊要求的产品——避免陷入困境
特殊要求产品的问题：混淆客户需求和产品需求，使公司偏离正轨
产品需求不能用户说了算
用户很难知道自己需求什么
用户不知道什么样的产品是可行的
用户之间缺少沟通，需求很难统一
特例产品难以应变快速变化的市场和需求，会让公司不堪重负
回避特例产品可能带来的危害
公司根据企业文化树立自己的产品原则，关键时刻根据产品原则决定是否接受客户提出的特殊要求
产品经理协助CEO作出决策
与客户一起梳理需求，发现问题本质，提出更合理的解决方案
保持产品通用性的前提下，设法满足客户定制产品的要求
新瓶装老酒——新技术层出不穷
成功的产品往往不是什么新鲜事物，只是新瓶装老酒，之所以成功，是因为这个“新瓶”做的更好，更方便，更便宜，改变了消费者对“老酒”的印象
在成熟的市场抢占一席之地，至少需要两点
对目标市场了如指掌，对现有产品缺陷洞若观火
跟踪最新技术趋势，把最新技术融入产品
市场机遇无处不在，你要做的是挖掘需求，运用新技术解决用户的老问题
恐惧、贪婪、欲望——产品中情感的作用
消费者购买产品大多源于情感需求
只有从情感的角度重新观察市场上的产品和服务，你才能体会用户的真实感受
不同类型的用户有着不同的情感需求
每次开展原型测试，除了观察测试者能否顺利使用产品外，还应该趁机了解测试者的情感需求，思考怎样才能更好的满足他的情感需求
用户体验设计、可用性测试在满足用户情感需求、打造成功产品过程中起着至关重要的作用
明确目标用户的情感需求后，问问自己谁还能满足用户的这种需求，他们才是你真正的竞争对手。许多情况下，竞争对手不是创业型公司或大型门户网站，而是大众的线下生活方式
情感接纳曲线——与雅虎前副总裁Jeff Bonforte的对话
前言：Geoffrey Moore提出的技术接纳曲线，解释为什么很少有产品能越过鸿沟：获得尝鲜者以外消费者的青睐
提出情感接纳曲线以对技术接纳曲线作补充，以直观描述消费者对待产品的态度
关注用户不满情绪：愤怒的用户决定着产品未来的发展方向
驱动消费者的情感需求：根据消费者的情感特征，分为技术爱好者、非理性消费者、理性消费者、超理性消费者和观望着
技术爱好者（技术创新者）：仅仅因为产品用新技术而购买，需求与普通大众不一样，容易误导产品经理
非理性消费者（尝鲜者）：情感需求与大众一致，但更强烈。生活中，非理性消费者为满足情感需求，会付出大大超过解决问题本身所需要的精力和成本
理性消费者（早期消费大众）：只会购买他们认为实用、成熟的产品，更务实，只会购买性价比合适的产品
超理性消费者（后期消费大众，可能是核心用户群）：约占总人数的15%（雅虎用户群），情感需求更弱，产品有半点不合意都不会掏钱
观望着（跟随者）：有同样需求，但只会买公认好用的产品
非理性消费者最值得产品经理关注，技术爱好者最没有参考价值
非理性消费者能帮助产品经理发现产品内在价值：非理性消费是对不安情绪的过度反应，是放大后的情感需求在“作祟”。非理性消费者夸大了产品价值，产品经理如果深入了解他们的想法和感受，就能抓住这种情感需求
可用性和美感——两者缺一不可
视觉设计可以满足用户情感需求，非常重要
良好的用户体验是交互设计师和视觉设计师合作的结果，他们共同配合产品经理定义产品
大众网络服务产品——十大要点
可用性：产品性能是最重要的一条指标，页面加载缓慢让用户无法忍受，是糟糕的用户体验
人物角色：精确的用户画像和分类
扩展性：为系统扩展做好准备，以应对可能的用户激增对系统的巨大压力，永远留有余地，不到万不得已不要满负载运行
持续可用性
客户服务：除了尽量减少系统故障和缺陷外别无他法，最重要的是维持良好的用户体验
保护用户隐私
口碑营销：为用户提供便利的分享推广
全球化：易于各地区的本地化
平滑部署：用户数量达到一定量级，任何小小的变化都会影响大面积用户，要三思而后行，慎重再慎重
用户社区管理：多用类似“回馈用户”的活动表达对他们的重视，从行动上把用户当“上帝”
打造企业级产品的经验——十大要点
可用性
产品正常工作
特例产品：必须坚持产品原则
特约用户：邀请特约用户配合团队验证产品设计
重视销售渠道的需求
真正了解客户和用户的区别以及他们的需求
产品安装要简单易操作
产品的配置、自定义、集成做的更完善
简化产品升级技术和流程
充分利用利用互联网时代新的销售手段
打造平台产品的经验——最具挑战性的工作
需要满足三种不同客户截然不同的需求
应用软件供应商：选择你的平台创建解决方案的公司
关心平台开发商的生存能力，产品定价、认证情况、产品质量。技术支持能力，以及将产品国际化的难以程度
开发人员：应用软件供应商的雇员，他们在平台上开发应用软件
关系平台产品是否支持自己惯用的编程语言，开发工具、基础架构，他们更希望迅速、便利的开发出性能好，可靠性高的应用
终端用户：应用软件使用者，平台服务的真正使用者
只在意最终结果
终端用户的大量流失意味着平台失败
开发人员勤奋工作是理所应当的，只有让终端用户满意，产品才是成功的
总结
最佳实践经验——十大要点
产品管理的职责：专注产品经理本质工作，不要浪费时间在无关的工作上
用户体验：产品的生命
机会评估：开工前先明确定义产品
特约用户：打造优秀产品没有任何捷径，只能请用户反复试用，不断改进
产品原则：明确产品原则，树立价值标准，作出果断决策
人物角色：目标用户按特征分类，逐一分析、理解其情感和行为，以此作为决策依据
定义产品：除非产品经理确定产品有保持纯粹保持纯粹价值、可用，可行，否则同事的努力都将付之东流
使用原型：使用高保真原型是定义产品的关键步骤，原因有三
迫使产品经理深入定义解决方案
可用让真实的用户参与测试、验证产品创意
直观向团队展示产品的设计思路
用户参与原型测试：获取有效的用户反馈是产品经理最重要的工作
根据数据改进产品：根据产品实际应用情况，不断提升产品各项指标，逐步完善产品
产品经理的反省清单——十大问题
产品能吸引目标消费者的关注么？
产品的设计是否人性化，是否易于操作？
产品能在竞争中取胜么？即使面对未来风云变化的市场，依旧有取胜的把握么？
我了解目标用户吗？产品（不是理想的产品，而是实际开发出的产品）是否能得到他们的认可？
产品是否有别于市面上的其他产品？我能在两分钟内向公司高层阐述清楚这些差别吗？能在一分钟内向客户解释清楚吗？能在半分钟内向经验丰富的行业分析师解释清楚吗？
产品能正常运行吗？
产品是否完整？用户对产品的印象如何？销售业绩如何？销售任务能否顺利完成？
产品的特色是否与目标用户的需求一致？产品特色是否鲜明？
我了解其他团队成员对产品的看法吗？他们觉得产品好在哪里？他们的看法是否与我的观点一致？