周末去药房给家里人买治关节炎的进口药，顺便网上搜了一下，这个药有两种规格，一种是大瓶装的120粒，140一瓶；如果是买一个疗程的两瓶装，是255，折合一瓶130不到；还有一种盒装的规格是20粒，卖50.

我虽然知道大小包装存在价格差异，但细算 一下，这个差价太大了。我再仔细对照了一下两种规格的成分含量，是一模一样的。

这就是山姆的生意经，用大包装来降低采购和管理成本，在终端销售上，价格也更有优势。

这个逻辑是没问题的，不过有意思的是，即使有大包装，小包装也有售卖的空间。

但这里我不想提所谓的价格锚点这种消费心理学，我想探讨另外一个问题。

大包装和小包装面向的用户都是谁？为什么要同时卖？

我的理解是，大包装更多是面向长期价值用户，这些用户是高粘性用户，他们对产品和品牌已经不存在质疑，更加追求的是长期复购的性价比；而小包装用户面向的试用用户，这些用户对产品和品牌并不是非常了解，要先买小包装做一些尝试。

那么从用户获取的角度，为什么不考虑将小包装用更有诱惑力的价格推向市场，来获取更多的新用户呢。

而比如这款进口药，反而把小包装做的性价比极低，这和一些快消品用便宜甚至免费的试用装来收获新用户的思路是完全不同的。

我不太懂药品，所以拿我了解的互联网用户带来的流量价值来说明这个问题

对于一款IAA产品，本质就是做短线，是需要短周期榨取用户价值的，这类产品对待新用户，就不会用所谓的养鱼策略，而且尽可能的对用户的流量价值进行收割，因为这个用户他很难形成粘性用户，这是产品的定位决定。

真正做长线价值，做留存的产品，一定懂得在先期让利给用户，培养用户的使用惯性，让获客成本逐步边际化。

而做买量-变现的产品，则要考虑的是回收周期和周期内产生成本，做的比较极端的就是，在某个周期内一次性获取用户，然后最大化的榨取用户的流量价值。

当然站在用户的角度，如果是药品，可能在前期愿意多花一些成本去尝试，会考虑买性价比很低的小包装；但对于广告来说，一个用户被广告引流到一个更大的广告场景，却可能是伤害double。

相信做过产品的人都有同感，一个预期的产品，最后到上线往往回失真，离想象中的总有差距。
虽说产品经理可以是完美主义者，但如果在产品临近上线再发现问题，发飙，揪住不放都有些为时已晚，尤其对上线有严格要求的项目，这种问题是致命的。
所以，我总结了一个叫“产品实现漏斗”的概念：

第一层漏斗：业务需求-产品理解

这里的业务需求一般是最原始的诉求，可以来自终端用户或者客户，可以来自一线业务人员或者是老板，产品经理在这个阶段要足够的开放和敏感，用开放的心态全面的收集信息，用敏感的嗅觉去捕捉最细微的信号，不要担心冗余，能细则细，客观真实。千万不要想当然。这个过程如果掺杂了一些个人的假设，也需要及时的和用户进行假设确认，避免一厢情愿。

接下来对原始信息进行清洗过滤，合并去重和抽象，输出一个叫“产品概念”的东西，和用户再次进行确认，这时候沟通技巧和期望管理就很重要，因为并不是所有的诉求都要去满足，但能不能和用户解释清楚是产品经理的问题，能做的，不能做的，为什么不能做，双方要达成一致，减少后期交付阶段的不买账和返工。

这部分的损耗根据我的经验，要占到30%

第二层漏斗：产品理解-需求输出

需求和产品功能之间的转换是抽象的过程，编程就是对现实的抽象，抽象成类，对象，方法，变量等。而功能则把原始诉求抽象出每一次点击，页面展示，输入-输出，排序和反馈等。产品经理在这块应该有扎实的基本功，尽量减少转换过程中的损耗，并优化路径。需求输出的呈现就是PRD和保真产品原型，这块是有规范可以遵循的，需要参考另外一篇文章：PRD的标准结构。

这部分的损耗10%左右

第三层漏斗：需求输出-工程理解

很多产品经理把需求评审会搞的很重，会议拖沓冗长，大家听的昏昏欲睡。产品在上面慷慨激昂，开发一声不吭是很多评审会议的常态。在一番体力的较量后，效果并没有想象中的好，没听懂的依然需要会后再去问，当时听懂了会后可能还要去问。有些评审会就开成了全武行，火药味十足，直接互怼。所以我个人的体会是，需求评审并不是一次评审会就能解决的，核心目标是工程团队对需求的理解。如何做好这个理解，我个人有几个心得：
1， 评审需求之前做好预演，把开发团队可能要问的问题想清楚，并做好应答准备
2， 彻底扫除需求当中含糊和不明确的东西
3， 提前让工程团队了解需求，早点消化和发现问题
4， 拆成多个小评审会
5， 多次确认机制，重要功能会后和研发团队反复确认，不要嫌麻烦，
6， 需求背景和业务场景要铺垫好，不要一上来就直接讲功能，多给一些背景信息，不要硬着陆。

这里其实希望产品经理多少要懂些技术，对前端后端数据库的知识都要有个浅显的认知，不懂技术知识首先很难得到研发同事的尊重，其次沟通起来障碍很多，再腹黑一点，被蒙了都不知道。

这部分的损耗，20%左右

第四层漏斗：工程理解-工程实现

如果是技术中台架构的公司，工程团队和产品经理的讨价还价是常态。这里有个人主观的原因，也有客观因素，比如排期，资源和实现成本，尤其在研发对需求重要性理解还不够的情况下，一些实现成本高的功能很容易被排斥，这个时候要考验产品经理的沟通技巧，强势但不强硬，强势是因为你对产品有把握，这个功能必须上，且要在这一期上，原因你能说清楚，有理有据。一味的强硬只会造成合作的不愉快。

资源不够和排期的问题，产品如果兼着项目的职责，那么就要自己去协调，资源挤挤总会有的，但如果沟通不到位，协调的不灵活，情商不够高，那这块就会吃亏。

开发进度的控制不能完全依赖职能经理，因为上线日期是固定的，如果进度出现了拖沓，有些功能就要临时砍掉，这块的风险是高频的。所以每天或者固定周期的进度review，出现延期风险的及时补救需要做到位。

这部分的损耗40%

总之，在需求产生-产品上线的生命周期中，产品经理是第一责任人，绝对的一号位，直接影响到这个漏斗的最终形态。100分的客户期望，60分的交付一定证明某些环节出了问题，要把问题精准归因，并不断地优化过程。

设立一个参照物（竞品），然后层层拆解，过程有些繁冗，但逻辑清晰。

最简单的链路是这样的：概念形成-产品设计-产品开发-上线验证-迭代管理

可以拆解出下面的内容：

需求管理（收集、评估、筛选、排序）

概念设计（低保真的产品原型，帮助干系人建立起产品印象，收集早期的意见建议）

概念评审（和相关人员进行产品概念的宣讲）

产品设计（原型设计，产品规格说明书）

产品需求评审（产品经理和工程团队就“做什么”和“做成什么样”达成一致，最好和研发团队也说清楚“为什么做”，方便大家在目标上达成一致。有些公司产品经理强势，产品和研发有点类似甲乙方，这块往往会忽略，我个人觉得需要让工程团队有参与感和甲方意识，而不是产品说啥就干啥；当然，有些公司研发很有话语权，会经常battle产品，这块就更要说清楚。）

产品排期（工程团队确认“做多久”，产品经理有个预期的时间，也就是业务期望上线的时间，两者往往要做折中，抛开时间限制和资源，谈项目范围是耍流氓。）

产品开发设计文档（建议重要的产品和新产品，工程团队都要做详细的开发设计，包括接口约定，数据结构，开发线路图和技术栈等）

产品开发设计评审（开发设计也要让产品和测试一起参加，尤其有技术背景的产品经理，这个环节还能发挥一些作用。）

UI评审（UI设计师主导，产品经理和前端一定要参加）

测试用例评审（测试工程师根据产品需求准备测试用例，用例的是否详尽关系到最终的产品质量，全员参加）

产品开发（开发阶段，由项目经理或产品经理跟进进度，技术经理把控质量，解决开发过程中的技术问题）

产品测试（提交测试环境后，测试工程师根据用例测试，提交bug并跟进bug修复情况，最终提交测试报告）

产品验收（在开发环境验收，阿尔法测试，可以让普通用户参与，大部分是产品经理参与）

业务验收（可以是贝塔测试，或者验收测试，指定关键用户进行业务验收，产品经理收集问题，并发布验收报告。）

市场验证（就是验证之前的产品和需求假设，产品经理需要和营销人员明确产品铺开的节奏，在验证阶段，以接受反馈和答疑为主）

产品建议收集（要对用户的产品使用体验进行多维度的收集和管理）

版本迭代计划（根据市场和用户反馈，制定迭代计划）