a.确定待解决的问题
评估产品机会的目的：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源。
评估产品机会需要回答的问题（不涉及具体的解决方案，机会评估只讨论待解决的问题）：
产品要解决什么问题——产品价值
为谁解决这个问题——目标市场
成功的机会有多大——市场规模
怎样判断产品成功与否——度量指标或收益指标
有哪些同类产品——竞争格局
为什么我们最适合做这个产品
时机合适吗——市场时机
如何把产品推向市场——营销组合策略
成功的必要条件是什么——解决方案要满足的条件；指的是在调研过程中发现的特殊需求，不是要描述解决方案，而是搞清楚产品的依赖因素和约束条件，例如要通过系统集成商来销售产品，对方可能会对产品的扩展性、合作方式提出要求。
根据以上问题，给出评估结论——继续或放弃
b.开发新产品还是维护旧产品：评估两者的收益与成本，然后由管理团队做出决策。
c.钱花在哪儿：认识财务部门的同事
帮助你了解产品：了解产品经济学、产品的收益模式、产品的成本、产品的具体收益
帮助你了解用户：了解用户的交易记录、支付信息、客户数据与经营报表
确认商业上的可行性
a.定义正确的产品
软件项目分为两个阶段：弄清楚要开发什么产品，即定义正确的产品；开发该产品，即正确地开发产品
探索产品阶段——探索出兼具功能性与设计性的产品：分析各种创意，广泛收集用户需求，了解如何运用新技术，拿出产品原型并测试，从全局视角思考产品方向，兼顾短期需求和长期规划。
开发阶段：切换重心，重心在于开发、测试、发布。确保大家集中精力，捕捉软件开发不可避免的问题并迅速解决，不轻易修改产品定义。
采用流水线方式并行开发产品：一旦1.0版本进入项目执行阶段，就开始定义2.0版本。
b.探索产品的进度可控吗
首先，产品经理应该探索是否有用户需要产品，也就是寻找市场，让用户验证你的构思；其次，产品经理要探索能够解决问题的产品方案，设计有价值的、可用的、可行的解决方案，请用户和开发团队来验证。
定义产品本质上是创造性的工作。
确定方案后，才能全面进入执行阶段。
a.确定什么最重要
产品原则是对团队价值观和信仰的总结，用来指导产品团队做出正确的决策和取舍，是一系列明确的、体现团队特色的产品价值准则。例如，某电影网站的产品原则是相信社区用户比专业用户的影评更有价值。
仅仅罗列出产品原则还不够，还要按照重要性排序，例如易用性与可靠性哪个为先。
容易出现的两类错误：原则过于空泛，失去了指导作用；把设计原则误当为产品原则。
b.解决意见冲突
建设性的辩论和论证是定义优秀产品的必由之路。
作出产品决策前要达成的共识：
究竟要解决什么问题
要为哪类人物角色解决这个问题
产品要达到什么目标——易用性、响应速度、功能、成本、安全性、用户隐私等等
每项目标的优先级是什么
将共识在讨论前再次强调，作为评估方案和制定决策的确切依据；制定决策的过程必须完全透明，清楚展示决策的依据。
a.制定更及时、更可靠的产品决策：成立产品评审团是及时做出明智的产品决策的最好解决途径。
b.产品评审团的工作目标：决定产品战略方向，从宏观上监督产品研发流程，合理配置资源。在给定的商业战略的条件下，提出与之相匹配的产品战略。
c.产品评审团的人员组成
首席执行官/首席运营官/部门总经理
产品管理总监/副总监
用户体验设计总监/副总监
市场总监/副总监
开发总监/副总监
网站运营总监/副总监
客户服务总监/副总监
确保每个关键部门都有代表参加；人数控制在10人以内；选一个人代表其部门陈述观点
d.产品评审团的职责：监督产品研发流程，制定关键决策，根据研发产品的四个里程碑来评审产品。
评审产品战略和产品路线图，启动产品评估的工作，即选择值得投入精力的产品，请产品经理开始评估产品机会。
根据评估产品机会的结果，决定是否开始定义产品的解决方案。
评审产品原型、用户测试结果、成本估算明细，决定是否开始开发产品。
评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品。
e.注意事项
小公司的评审团通常负责评审公司所有产品；大公司则需要根据业务单位的大小，设立若干个产品评审团。
评审团不负责评审对产品细节的更新或修正。这是为了加快对细节问题的处理，保证业务运行流畅。
评审团不负责具体的产品设计工作。若产品存在缺陷，应由产品团队处理，再提交评审。
在2号里程碑处，不可凭直觉估算产品的成本，至多只能估计大致的项目规模（小型、中型、大型三级）；在3号里程碑处，应仔细估算开发时间和成本。
尽量避免评审团讨论具体执行策略。
开会频率取决于具体产品的进度。
评审团还应该回顾、分析产品上市后的表现，可在发布3-6个月后，请产品团队汇报产品的市场业绩表现，反思之前决策是否明智，今后如何调整。
最好由产品经理汇报产品的进展情况，需要准备充分、提前逐一向评审团成员做简要汇报。
f.何时估算项目成本
在评估产品机会时做粗略估算，根据最终的产品说明文档做详细估算。
在定义解决方案过程中，产品经理和交互设计师需要一位开发人员协助评估不同解决方案的成本，根据结果调整方案。完整的产品说明文档形成后，根据文档细节生成详细可靠的成本估算结果。
a.产品开发伙伴
产品经理既需要深入洞察目标用户的需求，又需要赢得用户对产品的推荐。建议征集特约用户（用户顾问委员会/用户评审团）协助完成产品研发。
在项目开始阶段物色8-10个用户，从中筛选出至少6位积极、活跃、乐于分享的目标用户。要求他们在产品的目标用户中具有一定影响力。
b.成为特约用户的好处
参与构思产品创意，解决他们手头的问题。
提前试用产品，显著降低用户的各种成本。
c.产品经理的收获
聚拢一批积极的用户，为定义产品和开发产品提供建议和协助。
提供调研便利。
可以定期组织特约用户进行小组讨论。
特约用户第一时间试用、测试产品，迅速反馈意见。
如果特约用户满意产品的表现，会乐意公开推荐产品。
d.组织特约用户的注意事项
不要收取参与费用。
人数要控制在10人以内，才能有时间与精力进行深入沟通。
如果寻找特约用户时遇到困难，很可能是因为产品要解决的问题并没有预想中那么重要。这可以初步验证产品创意是否有价值，应该重新考虑产品计划。
确保特约用户是产品潜在的目标用户，而非产品尝鲜者（early adopter），尝鲜者常常能忍受产品的不足和缺陷。
务必向特约用户说明，要开发的是面向大众的通用产品，而非针对某公司开发的定制产品。
应将特约用户当成开发伙伴对待。
合作贯穿每个环节：向他们展示产品原型、请他们参加测试、向他们请教产品的细节问题、让他们帮你部署、测试待发布产品的各种版本。
正式产品发布之前，一定要请特约用户先试用，确保每个人都满意。
产品经理要和产品营销人员合作。他们可以帮忙物色特约用户，协助你提高特约用户受关注的程度。
如果是平台产品，6个用户要换成6个应用。产品经理要与特约应用的开发者紧密合作，确保在平台上构建的应用让用户满意，最好鼓励应用开发者发展自己的特约用户。
e.该不该与用户交流
产品经理应该尽可能地亲自拜访用户，与用户交流，参加每一次的可用性测试和特约用户研讨会。
产品经理必须与用户充分沟通，挖掘每个人的潜在需求，捕捉产品创意。
产品经理应该充分利用公司的可用资源，如寻求用户研究部门、营销人员、主程序员的帮助。
与用户打交道的过程中，会发现一些富有洞察力、善于思考的用户，应设法与他们保持联系，他们是最佳候选人。
a.理解市场调研的作用与局限性
常用的市场调研工具和方法：
用户调查：设计调查问卷需要技巧和经验，要结合具体情景，仔细设置问题；调查结果为获得解决方案提供了一条途径，但不是解决方案本身。
产品使用分析：在产品中使用分析工具记录用户的行为。应该明确告知用户分析工具的用途，声明只收集统计数据，不涉及用户隐私。
数据挖掘：新的数据分析工具。
拜访用户：前往用户使用产品的场所实地考察。
人物角色：务必找出若干种用户类型，深入了解他们，弄清哪些是当前的用户，哪些是潜在的用户。
可用性测试：尽早、反复地进行可用性测试，观察用户使用现有产品的反应，收集反馈意见，了解他们的真实想法。从用户的视角重新审视产品，不光阅读反馈信息，更要记录用户的行为和反应（如兴奋、沮丧）。
同类产品分析：找出竞争对手的优势，学习对手的成功经验。
合理地利用市场调研工具和方法可以回答以下几个关键问题：
谁是目标用户？
用户会怎样使用产品？
用户能想明白怎样使用产品吗？障碍在哪里？
用户为什么选用你的产品？
用户喜欢产品的哪些特点？
用户希望如何改进产品？增加哪些功能？
市场调研的局限性：
市场调研不直接回答最根本的产品问题：打造什么产品。市场调研可以作为研发产品的依据和参考，但是不能决定产品研发的方向。探索产品的过程则要回答以下问题：采用什么技术来更好地解决产品要解决的问题；设计什么样的用户体验。
成功的产品基于以下两点认识：深入理解用户需求；明白什么样的解决方案在现阶段是可行的。
b.关于用户研讨会
虽然组织用户研讨会可以面对面了解目标用户对产品的看法，但不可能讨论出成功的产品。因为用户不知道什么样的想法是可行的，多数用户对技术一无所知；没见到实际产品，用户很难凭空想象自己需要什么。
用户研讨会的其他弊端：
人群聚集时容易冲动，相互影响。
除非让用户实际试用产品，否则他们不清楚自己想要什么。
需要主持人熟悉组织技巧，能随机应变，还得掌握产品领域的知识，擅长引导话题，才能获得预期的效果。
a.理解目标用户
人物角色又称为用户特征记录（user profile），是指通过与用户沟通交流，确定典型的目标用户类型，在理解各类目标用户的特征的基础上建立的人物原型。人物角色是合理地描述用户特征的人格化虚拟原型，重点关注用户的行为、态度、目标。
为了发掘潜在的人物角色，产品经理必须深入参与创建人物角色的工作，尤其要亲自参加用户交流、用户调查、产品可用性测试。与交互设计师、用户研究团队紧密合作，抓住一切机会与用户交流，深入了解目标用户。
人物角色的主要用途：
筛选重要的产品功能。人物角色既有助于决定谁是目标用户，也有助于决定谁不是目标用户。面面俱到的产品往往一无是处，使用人物角色可以避免犯这种错误。
避免产品团队将自己的需求当成用户需求。
许多产品的用户类型不止一种，使用人物类型有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的地方。
方便向团队描述产品的目标用户是谁，他们怎样使用产品，他们关心产品的哪些方面。
帮助团队成员达成共识。
人物角色的注意事项：
每个发布周期，可以集中精力关注一类关键人物角色，把产品的优势发挥到极致。
创建前需要花时间与用户面对面交流，不能基于凭空想象和刻板印象。
邀请用户参加产品原型测试，不仅仅要邀请关键人物角色，建议邀请多样化的用户参加。
a.安息吧，纸质说明文档
理想的产品说明文档应该满足以下要求：
产品说明文档应该完整地描述用户体验——不只是用户需求，还包括交互设计和视觉设计。
产品说明文档必须准确地描述软件的行为。
产品说明文档的受众较广：开发、测试、客服、市场营销、运维、销售、管理层等等。因此，产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。
产品说明文档应该可以修改。进入开发阶段后应该避免修改，但意想不到的情况出现时需要修改产品说明文档以适应新情况。
撰写产品说明文档的过程中会出现很多衍生物，比如按优先级排列的需求列表、线框图、实体模型，但应该有一个主体来代表产品，避免混淆不清，版本错乱。
只有一种形式的产品说明文档可以以上满足要求，即高保真产品原型。“高保真”的含义是原型应该真实地体现用户体验，尽可能地体现产品细节——包括所有的页面和主要的用例。如业务逻辑（税务表单和运费等）、发布要求（性能表现、可靠性、拓展性等）、平台交付要求（安装要求、浏览器兼容要求等）不容易用原型体现，可以使用用例作为有效的补充，描述重要的产品行为。
可以用wiki或网站实时更新展示的说明文档，文档的主体应该是高保真原型，由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。
高保真原型突出的优势是可以用来测试，让真实用户体验，观察他们是否清楚如何使用、是否渴望使用；高保真原型可以大大缩短产品上市时间。
a.先定义用户体验再动手开发
需求调研与产品设计可以同步展开、软件开发与产品测试也可以交叉进行，但用户体验设计与开发不能放一起进行，原因如下：
一旦产品进入开发阶段，再修改设计思路是非常困难的，越往后成本越高。因为开发团队必须根据确定的用户需求和产品定义设计软件架构，然后进行开发。前期的架构决策极大地制约着后期的开发工作。
用户体验设计要保证产品同时具有可行性和价值，必须尽早、反复地验证设计思路。验证设计思路必须使用高保真原型。
尽管开发可以分成多次迭代（降低风险、提高质量、便于产品集成），用户体验设计却不能拆分。设计师必须全面、连贯地看待用户体验，考虑以往用户的使用习惯。让用户放弃不可用的软件很容易，让他们放弃使用习惯却很难。
用户体验设计不一定是最费时间的工作（像软件开发一样，取决于具体的方法、特定的产品需求、从业者的技能和经验），但至少需要一两周的时间。
如果两者同步展开，一方面，开发人员等着设计师的结果无事可做；另一方面，设计师饱受压力，仓促了事。
敏捷方法里有个概念叫第零次迭代（sprint zero），产品经理和用户体验设计师利用这段时间先完成产品设计工作，然后交由开发人员开始迭代开发，这需要更详细地定义开发任务（backlog），但团队工作会更愉快，产品也会更好。
只有在开发人员需要开发大量后台基础软件的情况下，两者才能并行展开。
尽管需求调研和产品设计都要在软件开发前完成，但在此期间至少要邀请一位开发人员检查设计工作，协助评估设计的可行性和成本，做出更明智的决定。
a.削减功能还是延长工期？
老式的产品设计方式：产品经理制作了完善的产品说明文档，详细标注了各项产品功能的重要等级，然后开发部门根据这份文档估算开发成本和开发时间。估算得到的结果往往超过产品经理的预期，于是不得不削减功能、缩小测试范围、减少公开测试时间、雇佣额外的开发人员，最后开发出来的产品完全不是有机的整体。
建议采用另一种产品设计方式：
产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少。
邀请一位开发人员（比如架构师或者主程序员）参与设计原型。请他检查原型，帮助产品经理和设计师估算各种功能的直接成本和间接成本，指出设计上的误区，并分析、评估尚不确定可行的功能。等产品原型确定时，详细估算出产品功能的时间成本。这样一来，各项功能孰去孰留已经明了。
请真实用户验证、测试原型。一旦通过，就不再削减任何功能。如果还能削减，说明你定义的不是基本产品。
如果估算过于乐观，只能延长工期，不能再削减，因为你已经没有东西可以削减了。因此设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。
a.证明产品的价值、可用性、可行性：产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求。
b.可行性测试：首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。
c.可用性测试
交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用。
可用性测试往往能发现没能成功实现的产品需求，最好规划多次迭代测试，确保实现最佳的用户体验效果。
一定要请真实的用户来试用可用性原型，从目标用户那里可以得到宝贵的反馈信息。
为了测试可用性，即使是要模拟复杂的后台处理过程也是值得的，关键是要评估用户体验的实际效果。
d.价值测试
目的是要知道用户是否觉得你的产品有用，是否愿意购买，有多喜欢产品的设计。
可以和可用性测试同时进行，使用同样的原型。只不过可用性设计重在观察用户如何设法完成必要的操作，价值测试重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式。
a.把产品创意呈现给真实用户：让真实用户验证产品设计，是产品经理最为重要的工作。
b.物色测试者
如果已经拥有一批特约用户，可以邀请他们参与测试。
如果是企业级产品，同类产品的展销会会是寻找目标的好去处。
可以在分类信息网站发布广告征集测试者，征集要求不必太过具体。事后打电话给感兴趣的应征者，进一步筛选。
如果是大众产品，可以邀请自己的亲朋好友参加测试，但要避开过于亲密的人和科技行业的从业者，除非他们就是目标用户。测试者也不能只限于亲友。
如果手头有用户的电子邮件列表，可以从中筛选，营销团队可以帮你缩小名单范围。
可以通过公司网站征集志愿者，但还需要打电话联系筛选，避免参加测试的全是产品尝鲜者。
较大的公司可以定期开展原型测试活动（比如两周一次），每次邀请10-20位测试者参加。让所有产品经理自己申请时段，安排每位测试者参加测试一两个原型。
到街头巷尾、用户聚集的地方去。开发电子商务产品，应该去大的商品卖场寻找测试者；开发体育产品，就到体育酒吧。可以送些礼物表示谢意，注意放低身段。
如果邀请测试者上门参加测试，应该补偿测试者为此损失的时间。如印有公司标志的帽子、电子购物券等。
在测试前一天致电测试者再次确认约定的测试时间，防止测试者忘记这件事。
c.准备测试
事先拟定测试内容。比如产品是电子邮件客户端，用户必然要完成写邮件、读新邮件、归档邮件之类的操作。你应该着重测试主要项目——用户大部分时间执行的操作。还有一些不那么重要的项目，可以等到时间有富余再测试。
你只有一次机会了解测试者未接触产品原型之前如何解决产品要解决的问题。如果是点评餐馆服务的网站，先不要让测试者登录产品原型的界面，只提供空白的浏览器，看他们会访问哪些点评网站，习惯按地点、菜式还是价格来搜索。原型设计多少有些假设的内容，直接让测试者使用原型，就无法获取这些宝贵的信息了。
测试原型前还有一件事要做，就是观察测试者能否从原型首页看出产品要解决什么问题，哪些地方最能吸引他们。一旦他们进入测试任务，就不会再有首次访问的感觉。首页的设计极大地影响着实际使用效果与用户期望之间的差距。
待测试者完成测试任务、了解产品用途后，通过聊天进一步收集信息。比如，他是否使用过同类型产品，习惯借助网络解决这个问题还是另有方法，原型是否比他常用的产品好。也可以问一下净推荐值：他有多大可能性向朋友推荐这款产品。
为每个问题的答案打分（如0-10分），或者干脆让测试者用数字来回答问题，以此记录每个阶段产品原型的表现。用打分的方法便于跟踪记录产品原型的总体表现，为完善产品设计提供参考。
不必等到完整原型完成后再测试，可以先测试主要项目，即使某些功能空着也没关系。如果测试者遇到功能上的死胡同，问问他们，接下来希望发生什么。测试者试用已有功能前，也可以问这个问题，看看实现方式与测试者的期望是否一致，往往能获得宝贵的意见。
d.测试环境
配有单向透明镜和闭路监控以及多个摄像机同时拍摄用户和显示屏的正规测试实验室，或者简单的桌椅加电脑，都是可以的。
用户的办公室也是上佳的测试场所。熟悉的办公环境可以让他们充分展示日常工作中的使用习惯。另外还能观察用户的办公室：显示器多大、电脑处理能力如何、网速多快、如何与同事沟通等。
远程测试无法观察用户细微表情和肢体动作，不能替代面对面交流。
产品经理应该亲自参加每次原型测试，第三方的测试收集难免遗漏信息。
理想情况下，应该安排一人主持测试，一人记录。可以邀请用户研究人员、开发人员、交互设计师、视觉设计师甚至是高管一同参加原型测试。
e.测试原型
测试前不宜与测试者交谈过多，简单寒暄几句，递上一瓶水即可开始测试，告诉测试者等测试完再深入交谈。
寒暄之后务必告诉测试者，这只是初步的产品创意，不是正式产品；请说出真实看法；被测试的对象是原型而非测试者。
测试时，尽量让测试者保持平和的情绪，避免进入吹毛求疵的状态。测试的重点是测试者能否轻松完成产品任务，以及是否喜欢产品的功能。如果测试者提出页面的元素难看应该换掉，就跑题了。多观察他们的操作，少听他们的抱怨。
测试时尽量保持安静，不要给测试者提示。
通常有三种结果：在没有提示的情况下顺利完成测试项目；遇到麻烦，但通过反复尝试，最终完成了；受挫，最终放弃。
一般来说，尽量避免提示测试者，更不能引导他。如果他上下滚动页面，可以问问他想找什么，这类信息很管用。但不要让用户不停地说想做什么，这容易让他变得吹毛求疵，不是一种常态。
主持人不妨使用自言自语的技巧，这可以避免引导用户。如果测试者很安静，可以口述他们正在做的事，比如：我看见你正在浏览右侧的列表。测试者接着会告诉你他想做什么，诸如此类。
测试的作用是理解目标用户如何看待产品要解决的问题，发现原型和用户期望不一致或不相容的地方，也就是不符合用户直觉和习惯的地方。只要能发现这些问题，通常都不难解决，从而极大地完善产品。
肢体语言和语气可以透露许多有用的信息。
f.更新原型
要对测试反馈迅速做出响应，只要有两三个用户反映了同一个问题，就动手解决吧。如果有连续6位测试者欣赏和理解产品的价值，而且能完成关键的测试项目，就算完成了原型测试任务。
如果你发现没法让测试者对原型产生兴趣，或是无法让原型变得足够简单易用，让测试者理解其价值，应该立马收手，放弃这个产品创意。
推荐书目：《点石成金：访客至上的网页设计秘笈》（Steve Krug）
a.不是一味地添加功能
很多情况下，添加新功能不仅不会为产品增色，反而会让产品性能变得更糟糕。
开发新产品的第一步是要明确目标。例如投保网站关注注册率等指标，产品经理就应该时刻关注这些指标，与交互设计师、用户研究人员、主程序员密切合作，分析改善产品的可能性，还可以进行网站分析，请用户测试产品，向客服人员、销售人员了解情况，做盈亏分析，估算净推荐值。通过分析这些数据改进产品。
改进产品不是简单地满足个别用户的要求，也不能对用户调查的结果照单全收，能提高指标的功能才是你关注的重点。你应该找准方向，分析关键指标，有针对性地改进产品。
a.避免更新产品导致用户反感
毫无征兆地更新不必要的版本会令用户产生反感，不是所有用户都喜欢更新：
事前没收到更新通知，用户感到措手不及。
用户没时间学习、适应新版本，产品公司也没有提供旧版本供用户在过渡阶段使用。
新版本无法正常运行。
新旧版本不兼容，例如新版本无法访问旧版本的数据。
用户认为新版本添加的功能和特性毫无必要。
应付接二连三的版本更新，用户感到疲惫。
新版本修改了用户已经习惯的使用方式和操作流程，用户不得不重新调整适应。
不能因为用户可能反感就放弃更新产品，但是更新产品必须谨慎、理智：
通过公告、群邮、在线教程等方式提前通知用户，但很多人可能既没时间也没兴趣看，所以效果有限。
加倍做好测试工作，避免新版本存在影响正常使用的隐患，如可靠性问题、扩展性问题、性能问题。确保将来不会出现回退的窘境，为用户增加不必要的麻烦。
如果更新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式来降低风险。
平滑部署的方式很多。比如发布两个并行的版本，邀请有兴趣有时间的用户试用新版本，如果新版本运行正常，大部分用户习惯之后，再将新版本设置为默认版本，同时将旧版本保留一段时间，公示为旧版本提供支持的最后限期。另一种方式是区域性逐步部署，首先在某个区域内部署新版本，再逐步扩大范围。还有一种方式是增量部署，将更新分割为几个较小的部分逐步发布。
a.产品出炉后切莫虎头蛇尾
产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段，处理产品发布后的用户反馈意见。
评估产品表现应该用明确的、可量化的指标，如页面访问量、注册用户数、访问停留时间、会员转换率、订阅数、广告收益等。具体使用哪些指标取决于产品的商业目标，应该给指标分出等级并保持关注。此外，对于什么样的结果代表产品成功，什么样的结果代表失败，应该做到心中有数。
一旦问题反馈回来，产品团队、主程序员、客服人员、营销人员等应该至少每天召开一次简短会议，讨论问题的轻重缓急，确定最佳解决方案。如通过网站发布补丁、发表声明公示处理办法等。
a.十大秘诀
敏捷方法（scrum和极限编程）源自定制软件（custom software）领域，不完全适用于开发软件产品（product software）。
以下诀窍针对产品软件团队，不适用于定制软件团队：
产品经理即是产品负责人（product owner），他代表客户的需求，因而需要与产品开发团队保持密切联系，协助督促开发进程，及时解决出现的问题。
使用敏捷方法绝不等于省略产品规划。产品经理仍要明白产品的方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境里，规划周期应该适度缩短、反复迭代，采用轻量级的机会评估方法代替冗长的市场需求文档。
产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保你们有足够多的时间攻克难题，不能一边设计一边开发。另外，始终让开发人员参与评估产品设计和产品原型，及时反馈关于可行性、成本、解决方案的建议。
尽量把产品设计工作拆分成独立的部分，分而治之，但也不能拆得太细，目标是设计出符合基本要求的产品。另外，设计师采用迅速制作原型的方法更能适应敏捷环境。
产品经理的主要任务是定义有价值、可用的产品原型和用户故事（user story），作为开发的基础。用产品原型和用户故事替代厚厚的产品需求文档和功能说明文档有三个优势：可以请用户测试；强迫产品经理全面认真地思考问题；向开发团队明确地描述每次迭代周期需要完成的任务。请用户测试原型，根据反馈意见反复迭代修改原型设计，确保交给开发团队的是有价值的结果，避免任何浪费，哪怕只是一个迭代周期。
让开发人员自主划分迭代周期。有的产品功能可以在一个周期内完成，有的需要好几个周期。好的原型可以提高估算工作量和开发时间的精度。开发团队必须考虑产品的质量、性能、扩展性。
产品经理和交互设计师必须出席每天的晨会。设计师向开发和测试展示产品功能，开发相互展示完成的代码，让测试人员测试，请设计师和产品经理过目，测试和开发在制作原型的阶段识别潜在的问题，协助产品经理制定更合理的决策，解决产品设计、开发的问题。
除非达到了产品经理的要求，否则不要轻易发布新版本。
每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型。
在团队内开展敏捷培训。
b.迭代初期开发的产品能用做原型吗？
对定制软件或许可以，对产品软件行不通：
用一个迭代周期来验证产品创意时间太长。用几天时间验证可更改的产品原型效率更高。
在探索产品的阶段，开发团队还有许多重要的工作要完成，占用开发团队的时间开发产品原型，会消耗开发正式产品的经历。
一旦进入开发阶段，设计出软件架构后，再想改变产品设计思路，成本与难度都太高了。
c.敏捷方法可以用来开发产品软件吗？
敏捷方法同样适用于产品软件的开发，只要进行适当的调整即可。唯一不适合的地方是在架构设计方面，敏捷方法鼓励开发人员相信简单重构和快速重新设计架构的优势，对于产品软件并不是如此。
a.扬长避短
瀑布式开发方法也叫持续改进方法、里程碑式开发方法。
基本原则：
采用阶段式开发软件。开发过程被事先分成固定的几个阶段：撰写书面的需求说明文档、设计高层软件架构、设计低层细节、编写代码、测试、部署。
采用阶段式评审。每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才进入下一个阶段。
瀑布式开发方法让产品经理头痛的地方：
产品验证严重滞后：产品经理必须等到开发的尾声，才能看到可以运行的软件。所以在进入开发阶段之前，产品经理必须确保交给开发团队的产品设计是可行的、有价值的。
变更计划代价不菲：如果需求发生变化，或者前期设计有缺陷，修改起来成本与时间代价都很大。不过有问题要及时修改，早改肯定比晚改好。
无法适应快速的市场变化：一方面要确保产品设计的正确，另一方面要在发布后以最快的速度修补产品。
因此，使用瀑布式开发，交付时间通常会比预期的晚，而且用户常常发现产品存在缺陷，开发团队还要花费大量时间和资金修补、完善。
如果使用瀑布式开发方法，产品经理应该设法规避这些问题。首要的工作是在探索产品阶段，制作产品原型，请目标用户试用，确保产品设计是有价值的、可用的、可行的。只有这样才能提高产品成功的几率，同时节约开发团队的时间和成本。
a.关键在于产品探索
建议创业初期只设置三个职位：产品经理、交互设计师和原型开发人员，对应产品管理、交互设计、原型制作三项工作。
产品设计流程：
创建体现用户体验的高保真原型。
邀请真实的目标用户验证产品原型。
迭代设计产品原型
在迭代设计产品原型的过程中，通常会产生很多版本。随着迭代的深入，产品会趋于完善。确定产品原型后，再招聘程序员进行开发。
a.有困难，但值得一试
有两大因素影响着大公司的创新氛围：企业文化和老板的观念。
b.20%法则
让工作人员利用20%的时间从事创新研究。
若公司不同意在工作时间创新，那我们只好私下开展“臭鼬工程”了。
c.臭鼬工程
原指秘密军事行动，现在指在条件受限的情况下，利用自己的时间，低调地进行创新研究。
在大公司里，普通员工很难凭空获得允许从事创新研究。如果你能拿出阶段性的成果来，获得许可会容易许多，在这种情况下，只要不耽误本职工作，管理层通常会支持你的做法。
d.主动观察
观察和倾听是最简单的创新途径。仔细观察用户使用公司产品或同类产品的一举一动，留心观察他们欣喜和失望的表情，假以时日，你肯定能想出办法更好地满足他们的需求。注意，应该选择实际用户作为观察对象。
创新不是发现新问题，而是用新方法解决已有的问题。观察人们对现有产品的不满，是创新的最佳途径。
e.改善用户体验
另一种创新途径是跳出技术局限，完善用户体验。改善用户体验不仅要提高产品的工作效率，更要剔除多余的功能，明白哪些功能是用户必需的，哪些是设计和开发带来的衍生物。
每款产品都有特定的实现模型，但用户脑子里装的是概念模型，他们对产品要解决的问题，以及如何解决问题有自己的想法。如果实现模型与用户的概念模型不一致，用户就会感到失望。找到用户失望的地方，就找到了创新的机会，至少是改善产品的机会。
a.十大秘诀
大公司都遵循着一条潜规则：尽量规避风险。因此创新更容易发生在小公司里。在大公司工作，首先要面对的就是公司现有的流程、规定和条条框框。
多数大公司都采取矩阵式的管理方式，核心部门（如设计、开发、测试、运维、开发等部门）是共享资源，产品经理要确保争取到足够的资源才能研发出产品。采用这种组织结构不是因为它的效率高，而是为了节约公司运营的成本。
在大公司施展拳脚的方法：
了解公司制定决策的方式：知道决策权在谁手里，工作目标就更能明确。
建立人脉网络：主动向大家介绍你手头的项目；主动帮助他人，积累人脉关系。
臭鼬工程：找三五个志趣相投的同事在工作之余做出产品原型来。
自己顶上：一切为了推出产品，不要计较个人得失。
有选择地据理力争：多一个敌人不如多一个朋友。如果你不满意同事的工作、或者与他人意见不合，不要乱发脾气。与人辩论，要小心措辞，做到对事不对人。切记目标是完成产品。
会前沟通，形成默契：设法在重要的决策会议前达成一致意见，会议的主要作用是让与会者认识着大家取得了一致的意见。
合理分配时间：重新检查会议日程，划掉无关紧要的会议；学会充分信任同事，让他们自己拿主意。产品经理应该留下时间完成自己的本职工作：制定产品战略、构思产品路线图、研究产品原型、分析竞争对手。
分享信息：分享信息让你获得更多的朋友和资源，作为交换，别人也会分享信息给你。
向上司借力：学会利用上司的关系。利用他的人脉关系，传播你的理念，多向他请教，了解公司的文化和组织结构。如果需要上司出面说服公司高管，你一定要事前做好充分的准备，为他提供翔实可靠的资料和信息，用实力取得他的信任。
传播你的产品理念：多向同事传播你的产品理念，向大家描绘产品愿景，介绍产品策略，展示产品原型，分享用户反馈信息，为产品争取支持和资源。
——著作权归原作者所有——
