聊一聊“产品实现漏斗”
相信做过产品的人都有同感，一个预期的产品，最后到上线往往回失真，离想象中的总有差距。
虽说产品经理可以是完美主义者，但如果在产品临近上线再发现问题，发飙，揪住不放都有些为时已晚，尤其对上线有严格要求的项目，这种问题是致命的。
所以，我总结了一个叫“产品实现漏斗”的概念：
第一层漏斗：业务需求-产品理解
这里的业务需求一般是最原始的诉求，可以来自终端用户或者客户，可以来自一线业务人员或者是老板，产品经理在这个阶段要足够的开放和敏感，用开放的心态全面的收集信息，用敏感的嗅觉去捕捉最细微的信号，不要担心冗余，能细则细，客观真实。千万不要想当然。这个过程如果掺杂了一些个人的假设，也需要及时的和用户进行假设确认，避免一厢情愿。
接下来对原始信息进行清洗过滤，合并去重和抽象，输出一个叫“产品概念”的东西，和用户再次进行确认，这时候沟通技巧和期望管理就很重要，因为并不是所有的诉求都要去满足，但能不能和用户解释清楚是产品经理的问题，能做的，不能做的，为什么不能做，双方要达成一致，减少后期交付阶段的不买账和返工。
这部分的损耗根据我的经验，要占到30%
第二层漏斗：产品理解-需求输出
需求和产品功能之间的转换是抽象的过程，编程就是对现实的抽象，抽象成类，对象，方法，变量等。而功能则把原始诉求抽象出每一次点击，页面展示，输入-输出，排序和反馈等。产品经理在这块应该有扎实的基本功，尽量减少转换过程中的损耗，并优化路径。需求输出的呈现就是PRD和保真产品原型，这块是有规范可以遵循的，需要参考另外一篇文章：PRD的标准结构。
这部分的损耗10%左右
第三层漏斗：需求输出-工程理解
很多产品经理把需求评审会搞的很重，会议拖沓冗长，大家听的昏昏欲睡。产品在上面慷慨激昂，开发一声不吭是很多评审会议的常态。在一番体力的较量后，效果并没有想象中的好，没听懂的依然需要会后再去问，当时听懂了会后可能还要去问。有些评审会就开成了全武行，火药味十足，直接互怼。所以我个人的体会是，需求评审并不是一次评审会就能解决的，核心目标是工程团队对需求的理解。如何做好这个理解，我个人有几个心得：
1， 评审需求之前做好预演，把开发团队可能要问的问题想清楚，并做好应答准备
2， 彻底扫除需求当中含糊和不明确的东西
3， 提前让工程团队了解需求，早点消化和发现问题
4， 拆成多个小评审会
5， 多次确认机制，重要功能会后和研发团队反复确认，不要嫌麻烦，
6， 需求背景和业务场景要铺垫好，不要一上来就直接讲功能，多给一些背景信息，不要硬着陆。
这里其实希望产品经理多少要懂些技术，对前端后端数据库的知识都要有个浅显的认知，不懂技术知识首先很难得到研发同事的尊重，其次沟通起来障碍很多，再腹黑一点，被蒙了都不知道。
这部分的损耗，20%左右
第四层漏斗：工程理解-工程实现
如果是技术中台架构的公司，工程团队和产品经理的讨价还价是常态。这里有个人主观的原因，也有客观因素，比如排期，资源和实现成本，尤其在研发对需求重要性理解还不够的情况下，一些实现成本高的功能很容易被排斥，这个时候要考验产品经理的沟通技巧，强势但不强硬，强势是因为你对产品有把握，这个功能必须上，且要在这一期上，原因你能说清楚，有理有据。一味的强硬只会造成合作的不愉快。
资源不够和排期的问题，产品如果兼着项目的职责，那么就要自己去协调，资源挤挤总会有的，但如果沟通不到位，协调的不灵活，情商不够高，那这块就会吃亏。
开发进度的控制不能完全依赖职能经理，因为上线日期是固定的，如果进度出现了拖沓，有些功能就要临时砍掉，这块的风险是高频的。所以每天或者固定周期的进度review，出现延期风险的及时补救需要做到位。
这部分的损耗40%
总之，在需求产生-产品上线的生命周期中，产品经理是第一责任人，绝对的一号位，直接影响到这个漏斗的最终形态。100分的客户期望，60分的交付一定证明某些环节出了问题，要把问题精准归因，并不断地优化过程。
