产品人要玩转儿的流程
流程篇一流互联网公司的流程及技术与普通公司相比有很多不同之处，第二部分讨论探索及开发富有创意的产品时反复应用的流程和成功的实践经验。
1、评估产品机会
确定待解决的问题：产品经理必须用他灵敏的”嗅觉”，从纷至沓来的机遇中迅速评估、挑选出有市场潜力、可行的创意，过滤那些没有价值或时机尚不成熟的点子。
正常情况下：业务人员会撰写一份论证产品可行性的市场需求文档，描述待解决的问题。
理论上：市场需求文档只描述产品机会，不涉及具体解决方案。评估产品机会是产品经理的重要职责。
评估产品机会的目的在于：淘汰馊主意、避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源。
为了评估产品机会，我要求产品经理回答如下10个问题：
◆ 产品要解决什么问题？-产品价值。
最难回答的第一个问题——产品价值。问问产品经理要解决什么问题，你会发现多数人答非所问，只能泛泛地说出产品的功能和特色。
◆ 为谁解决这个问题？-目标市场。
◆ 成功的机会有多大？-市场规模。
可以求助于行业分析师、贸易协会、公司财务，再综合自己的分析作出判断。评估务必谨慎，避免浮夸。
◆ 怎样判断产品成功与否？-度量指标或收益指标。
◆ 有哪些同类产品？-竞争格局。
◆ 为什么我们最适合做这个产品-竞争优势。
◆ 时机合适吗？-市场时机。
◆ 如何把产品推向市场？-营销组织策略。
它描述具体销售方式，甚至会影响产品需求。
◆ 成功的必要条件是什么？-解决方案要满足的条件。
在调研过程中发现的特殊需求。确定必要条件的任务不是描述解决方案，而是搞清楚产品的依赖因素和约束条件。比如：如果要通过系统集成商来销售产品，对方可能会对产品的扩展性、合作方式提出要求。
◆ 根据以上问题，给出评估结论——继续或放弃。
如果CEO告诉你不管愿不愿意都要继续开发，怎么办？
迅速进行机会评估，明确产品需求也是必要的。你得到的结论可能会改变CEO的看法，即使不能，至少你能明确产品目标，大大提高产品成功的可能性。
开发新产品还是维护旧产品？
换个角度来说，所有项目，不管是开发新产品还是改善原有产品，都属于产品机会，与新旧无关，我们要考虑的是哪个机会更好。
开发新产品能为用户提供更多选择，还能吸纳新用户；改善原有产品能提高老用户的满意度，也能吸纳新用户。关键在于比较两者的机会。产品团队一视同仁地评估两者的收益与陈本，然后由管理团队作出决策。
钱花在哪儿？
多数产品经理对产品或公司的盈利模式理解非常有限，结交一位懂财务的朋友能让产品经理受益匪浅。
◆ 帮准了解产品---让他们帮你分析财务方面的问题，问问他们前面提到的这些问题。请他们帮你评估产品，看看公司的投入是否划算，他们对产品的预测如何。
◆ 帮助你了解客户---财务部门掌握着交易记录、支付信息、客户数据和经管报表。要注意哪些信息是你有权获取的，以及应该怎样利用这些信息。
◆ 确认商业上的可行性---你有一个绝好的主意，但你不知道这种商业模式是否行得通，怎么办？财务部门的朋友能帮忙，你提供信息，他们帮你分析整合。当你与高管讨论产品的可行性时，能得到财务部门的支持真是再妙不过了。
2、产品探索
定义正确的产品。软件项目可以划分为两个阶段：弄清楚要开发什么产品，定义正确的产品，探索产品；开发该产品，正确的开发产品，强调执行。
在探索产品的阶段，产品经理负责分析各种创意，广泛收集用户需求，了解如何运用新技术，拿出产品原型加以测试，从全局视角思考产品方向，兼顾短期需求和长期规划。探索出兼具功能性与设计性的产品。
进入开发阶段，产品团队切换工作重心：执行---开发、测试、发布。产品经理必须在执行阶段切换工作重心，否则产品经理自己可能成为产品上市的最大障碍。
探索产品的进度可控吗？
若只有四周时间探索新产品，理想状态下：第一周---评估产品机会，尝试理解待解决的问题，拜访潜在用户、收集基本需求；第二周---与交互设计师一起制作产品原型；第三周---利用产品原型展开用户测试；第四周---完成产品用例，与开发团队一起评审产品原型和说明文档。
我喜欢把定义产品的过程称为“产品探索”而不是“需求和设计”，为了强调两点：产品经理应该探索是否有用户需要产品；产品经理要探索能够解决问题的产品方案。
软件行业，尽管大部分产品没能完成既定目标但是也为探索产品设定期限，管理层坚持给产品探索设定期限，原因如下：
1、探索产品过程不可预测，管理层担心花几个月研究解决方案最后却做不出产品。按计划进入开发阶段，至少有事可做。
2、开发人员是紧缺资源，开发团队无事可做，导致开发资源被浪费。
3、产品原则
确定什么最重要。产品原则是对团队信仰和价值观的总结。用来指导团队作出正确的决策和取舍。体现了产品团队的目标和愿景，是产品战略的重要组成部分。从形式上看是一系列明确的、体现团队特色的产品价值标准。是一套价值判断的框架，帮助公司作出正确的决策。
制定产品原则时容易出现两类错误：
1、原则过于空泛，失去指导作用。
2、把设计原则当成产品原则。比如为用户提供清晰的导航路径方便用户完成下一步操作，这属于常见的设计原则而不是产品原则。
解决意见冲突
冲突原因：
1、每位同事对公司产品都有自己的看法。
2、大家都非常在乎产品，明白公司营利得靠用户，只有产品才能吸引用户。
3、许多人以为自己比其他人了解目标用户，其实不然。
需要在以下几点达成共识：
◆ 究竟要解决什么问题？
◆ 要为哪类人物角色解决这个问题？
◆ 产品要达到什么目标？
◆ 每项目标的优先级是什么？
4、产品评审团
制定更及时、更可靠的产品决策。
产品公司需要一套机制让决策者和相关人员及时作出明智的产品决策。成立产品评审团是做好的解决途径。
产品评审团的工作目标：决定产品战方向，从宏观上监督公司产品的研发流程，合理地配合资源。不制订公司的商业战略，而是在给定商业战略的条件下，提出与之相匹配的产品战略。产品评审团的决策直接影企业的运营。
产品评审团的成员组成：
◆ 首席执行官/首席运营官/部门总经理
◆ 产品管理总监/副总监
◆ 用户体验设计总监/副总监
◆ 市场总监/副总监
◆ 开发总监/副总监
◆ 网站运营总监/副总监
◆ 客户服务总监/副总监
产品评审团的职责：
1、评审产品战略和产品路线图，启动评估产品机会的工作。
2、根据评估产品机会的结果，决定是否开始定义产品的解决方案。
3、评审产品原型、用户测试结果、成本估算明细，决定是否开始开发产品。
4、评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品。
注意事项：
1、小公司的产品评审团通常负责评审公司所有产品；大公司可能需要根据业务单位的大小，设立若干个产品评审团。
2、不负责对产品细节的更新或修正。
3、不负责具体的产品设计工作。
4、产品解决方案尚未形成时，不可凭直觉估算产品的陈本。
5、尽量避免产品评审团讨论具体执行策略。
6、开会的频率取决于具体产品的进度。
7、还应该回顾、分析产品上市后的表现。
8、每次评审会议最好由产品经理向产品评审团汇报产品进展情况。
5、特约用户
产品开发伙伴。
项目开始阶段物色至少6位积极、活跃、乐于分享的目标用户，要求是他们在产品的目标用户中具有一定影响力。
成为特约用户的好处：
1、参与构思产品创意，解决他们手头的问题---他们最清楚产品要解决的问题。
2、提前试用产品，越早使用产品意味着越早解决麻烦。
3、通常，提前试用产品还可以显著降低用户的各种成本。
产品经理的收获：
1、聚拢一批积极的用户，他们可以为定义产品和开发产品提供建议和协助。
2、提供调研便利。
3、定期组织特约用户进行小组讨论。
4、特约用户第一时间试用、测试产品，迅速反馈意见。
5、如果特约用户满意产品的表现，会乐意公开推荐产品。
组织特约用户的注意事项：
1、不要收取参与费用，否则合作关系将会变味。
2、人数不能超过10个。
3、如果在寻找中遇到困难时，产品经理应该重新考虑产品计划。
4、产品经理需要确保特约用户是产品的潜在目标用户。
5、产品经理务必向特约用户说明我们要开发的是面向大众的通用产品，不是为某家公司定制的产品。
6、产品经理应该把特约用户当成开发伙伴对待。
7、产品经理与特约用户的合作贯穿产品研发的每个环节。
8、正式产品发布之前，一定要先请特约用户试用。
9、产品经理还要和产品营销团队紧密合作。一方面帮你物色特约用户，一方面协助你提高特约用户受关注的程度。
10、如果是平台产品，特约用户的作用就更突出了，只不过六个特约用户要换成六个应用。
6、市场调研
理解市场调研的作用与局限性。
市场调研工具和方法：
1、用户调研
2、产品使用分析
3、数据挖掘
4、拜访用户
5、人物角色
6、可用性测试
7、同类产品分析
合理地利用这些工具和方法可以回答以下几个关键词：
◆ 谁是目标用户？
◆ 用户会怎样使用产品？
◆ 用户能想明白怎样使用产品吗？障碍在哪里？
◆ 用户为什么选用你的产品？
◆ 用户喜欢产品的哪些特点？
◆ 用户希望如何改进产品，增加哪些功能？
市场调研的局限性：不能仅仅通过市场调研就成功定义产品，这些只能用来修补现有产品的不足之处，不能用来定义新产品。
用户研讨会
用户研讨会上不可能讨论出成功的产品。
原因：
1、用户不知道什么样的想法是可行的，多数用户对现有技术一无所知。
2、用户不知道自己想要什么，没见到实际产品，用户很难凭空想象自己需要什么。
3、人群聚集时容易冲动，相互影响。
4、组织用户也需要经验，正确引导话题，才能获得预期效果。
7、产品任务角色
理解目标用户。
产品管理的核心在于制定决策。人物角色又称为用户特诊记录，指通过与用户沟通交流确定典型的目标用户类型，在理解各类目标用户的特征的基础上建立的人物原型。
作为产品管理的工具，人物角色的主要用途：
1、筛选重要的产品功能。
2、避免把产品团队的需求当成用户需求。
3、有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的对方。
4、方便地向团队描述产品的目标用户是谁，他们怎样使用产品，他们关心产品的哪些方面。
5、帮助团队成员达成共识。
注意事项：
1、创建人物角色后就束之高阁，回避产品挑选关键人物角色的难题。
2、不花时间与用户交流，只是基于想象和刻板的印象创建人物角色。
3、邀请用户参加产品原型测试，邀请多样化的用户参与产品原型测试。
8、重新定义产品说明文档
安息吧~纸质说明文档。
理想的产品说明文档应满足以下需求：
1、完整地描述用户体验——还包括交互设计和视觉设计。
2、准确地描述软件的行为。
3、受众较广。
4、应该可以修改。
5、撰写过程中会出现许多衍生物：需求列表、线框图、实体模型。
9、用户体验设计与实现
先定义用户体验再动手开发。
多数软件开发团队已经尝到了开发与测试交叉进行的甜头。
但把用户体验设计和软件开发放在一起进行，是行不通的：
1、一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高。
2、用户体验设计要保证产品同时具备可用性和价值，任务很重。优秀的用户体验设计师一两天内要尝试几十个点子，哪怕只是2~4周的迭代周期都会慢的让人无法忍受。
3、验证设计思路必须使用高保真原型，为了验证各种设计思路，产品原型应该可以随意修改，完成其任务后应该丢弃。而开发中的产品应该以固定的原型为基础。
4、产品开发可以分成多次迭代，但用户体验设计却不能拆分。
5、用户体验设计不一定是最浪费时间的工作，所需时间取决于具体的方法、特定的产品需求，以及从业者的技能和经验。
会出现的情况：
1、开发人员等着设计师的时间结果无事可做。
2、设计师饱受压力，要在几天内完成原本需要几周完成的工作。
这个问题解决的方法是确定先后顺序，虽然需求调研和产品设计可以同步展开，产品开发和测试可以交叉进行，但是用户体验设计应该在软件开发前完成。
地零次迭代
产品经理和用户体验师利用这段时间先完成产品设计工作，然后交由开发人员开始迭代开发。
10、基本产品
削减功能还是延长工期？
一种情况：
产品经理制作了完善的产品说明文档，详细标注了各项产品功能的重要等级。然后，开发部门根据这份文档估算开发成本和开发时间。虽然提出了开发团队力不能及的功能，但得到的进度表还是比产品经理设想的多几个月时间。于是双方开始协商，先是争论估算是否准确，然后不得不削减功能，缩小测试范围，减少公开测试时间，要求雇佣额外的开发人员。。。不知不觉时间已经流逝。
建议采用另一种产品设计方式：
1、产品经理与设计师合作设计产品的高保真原型，只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。
2、邀请一位开发人员参与设计原型。
3、请真实用户验证/测试产品原型，这一点至关重要。
