《启示录》流程篇：如何定义正确的产品？.jpg
一、产品探索——定义正确的产品
软件项目可以分为2个阶段：
step1：弄清楚要开发什么产品（定义正确的产品，强调探索产品）
目的：探索出兼具功能性与设计性的产品。
方法：
- 寻找市场，让用户验证你的构思。探索是否有用户需要产品（不难）。
- 探索能够解决问题的产品方案（难）。即设计解决方案，并请用户和开发团队来验证“有价值、可用、可行”。
- 需求调研和产品设计都要在软件开发前完成，在此期间至少邀请一名软开人员检查设计工作，协助评估产品设计和产品原型，及时反馈关于可行性、成本、解决方案的建议，以做出更明智的决策。
step2：开发该产品（正确地开发产品；强调执行——项目经理型）
捕捉问题迅速解决。保证团队不受干扰，专注完成项目，按时发布产品。
培养自己的宏观思考能力和设计能力。
二、探索（定义）产品的过程，要回答如下问题：
- 采用什么技术，来更好地解决产品要解决的问题？
- 设计什么样的用户体验？
成功的产品基于以下两点认识：
- 深入理解用户需求：
- 明白什么样的解决方案在现阶段是可行的。
注意：
- 产品需求不能由用户说了算，因为：在看到具体的产品之前，用户很难知道自己想要什么；用户不知道什么产品是可行的（在目前的技术条件下可实现）；用户之间缺少沟通，需求很难统一。
- 明确“探索/定义产品的进度不可控”，但也要设定deadlne。
三、常见错误：
- PM不时冒出新点子；——放到下一版本中定义与开发；用流水线方式（1.0开发和2.0定义）并行开发产品。注意不要干扰正在执行的项目。
- 高管提要求修改产品；
- 花大成本开发出实际产品后，才进入市场进行测试。这是很多创业公司失败的原因——不如用原型或MVP测试先探索产品，确定满足“三性”的解决方案后，再全面转入执行阶段。在此之前不需大量开发人员，他们可参与探索产品或准备基础软件设施搭建。
四、重新定义产品说明文档——产品高保真原型图（描述产品的最基本方式）（by PM+设计师）
现在的产品需求文档存在问题：
内容、质量、形式差别太大，没有提供必要细节、关键信息，不能解决问题，虽然花费大量时间撰写，但少有人阅读。
理想的产品说明文档应该满足要求：
- 完整描述用户体验（包括用户需求，交互设计，视觉设计）；
- 描述软件的行为；
- 受众广（开发、测试、客服、市场、运维、销售、管理层等），能直观传递产品信息和产品行为；
- 可以修改，适应新情况；（为了验证各种设计思路，产品原型应该可以随意修改，完成任务后应该被丢弃；而开发中的产品应该以固定的原型为基础）
- 撰写PRD过程中，有许多衍生物，比如按优先级排列的需求列表，线框图，实体模型。但应该有一个主体来代表产品，避免混淆，版本混乱。
满足以上需求的只有——高保真原型图
- 由它体现：产品功能需求，信息架构，用户体验，交互设计，视觉设计。
- 它包括：模拟后台处理流程和某些数据，关键的用户体验组件，产品页面和主要用例。
- 它最突出的优势：产品原型成本低，反馈高，可用于给团队检查，可让用户验证。
总结：
高保真原型图为主，补充用例（描述重要的产品行为）和说明文档（最理想的方式是在原型上增加注释）。
注意：开发中的产品与产品原型有很大区别，不能混用。
五、用户体验设计与实现——先定义用户体验再动手开发
- 应该并行的工作：需求调研和产品设计（即用户体验设计）；开发与测试。
- 不可并行的工作：用户体验设计和软件开发——用户体验设计应该在软件开发前完成（除非开发要开发大量后台基础软件）。
原因：一旦进入开发阶段，再修改设计思路非常困难，成本太高；且前期的架构极大制约后期的开发工作；打击开发的斗志，增加团队压力；用户体验设计的验证需要尽早、反复进行（一两天几十个点子）。
产品开发可以分成多次迭代，但用户体验设计却（需要连贯）不能拆分。设计师必须全面、连贯地看待用户体验，考虑用户使用习惯。用户体验设计至少需要一两周时间。
六、定义基本产品
不再试图定义最终产品（以免工期预期出错，后期不断削减功能或延长工期），而是定义只满足基本要求（价值，可用性，可行性）的产品。
流程：
- PM和设计师合作设计产品的高保真原型图（只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力）
- 邀请开发人员协助分析可行性，估算时间成本。
- 请真实用户验证产品原型，保证用户需求得到满足。
- 一旦基本产品确定，通过了目标用户的测试，就不可能再削减任何功能（如果还能削减，说明你定义的不是基本产品）；一旦进入软件开发环节，PM就不能再随意修改设计。
如果开发时间估计过短？
只能延长工期，不能削减功能。
行动：
设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可削减的产品。
