核销怎么做pos(To B 产品团队如何实现可持续发展？)

ToB产品团队想要达到可持续发展，首先要确保产品能朝着正确的规划方向发展，同时也需要团队共同的配合，建立合理的工作流程，树立起团队的方法论体系。

最近在人人都是产品经理看到一篇文章《2B产品的隐藏陷阱：销售驱动》，文章受到许多同行的热议，大家都表现出强烈的感同身受，于是我想要借着这篇文章作为引子，探讨一下 to B 产品团队要怎么可持续发展？

在此就不再赘述为何导致的销售驱动，我想直接从以下几个方面讨论一下如何帮助团队避免销售驱动。

一、清晰的产品范围

导致销售驱动的最致命的原因并非销售拥有太多话语权，而是团队没有一个清晰、具体的产品范围。

在工作中经常发生的事：客户提出需求时，团队成员（包括销售也包括产品）无法准确辨别客户需求是否偏离了产品范围，才出现各种被认为是“市场通用“的客户需求挤爆了开发计划。

产品范围包括「需求范围」和「功能范围」。「功能范围」通常的产出为 PRD 文档，目的是对最终产品中包含的具体功能和特征的描述。通常团队成员对于「功能范围」极为重视，但对「需求范围」的定义往往流于表面，正因如此导致了「功能范围」经常变化，“计划赶不上变化”。

指挥官意图

「指挥官意图」是由美国陆军在20世纪80年代提出的概念，原因是在战场上常常会碰上意想不到的事情——天气变化、关键资源被毁和敌方突出奇兵，导致计划本身在战场上全然排不上用场。

「指挥官意图」是位于每道命令最前面的一种直白陈述，能清晰的说明计划目标，明确指出该任务所期望达成的最终结果。「指挥官意图」可以在各个层面指挥士兵的行动，无需上级长官下达每项行动的详细命令，只要知道了预期目标，大家就可以伺机行事，想方设法达成目标。

——《让创意更有黏性》

如同战场，做产品同样依靠的是团队中每位成员（产品、交互、UI、开发、市场、销售）在自己所擅长的专业上做出其最优决策所汇聚成的结果。当面对外界的噪声（客户的抱怨、行业趋势报告等）时，团队成员应该如何决策，当然不能任由个人的心情而定。

「需求范围」如同战场中的“指挥官意图”，目的是阐明产品的核心——产品满足了哪方面的业务需求？帮助企业实现什么价值？产品自身要达成怎样的核心竞争力？

范围要具体

就拿目前在 CRM 产品中的某热门口号为例——“全渠道客户体验”。

仅「全渠道」的范围就存在着不同的解释：

在产品的眼里，「全渠道」是所有的互联网主流渠道；在开发的眼里，「全渠道」是提供了开放接口的那些渠道，于是像淘宝、京东这些开放接口并不能轻易获取的渠道就只能搁置了；在销售眼里，「全渠道」是客户认为的全渠道，于是不仅仅是互联网渠道、经销商、零售门店、导购都是渠道。因此，若不将产品范围具体化，团队的工作就无法完全协调。

二、产品初期，由产品团队做“销售”

先把产品和服务做好让自己能帮助客户成功，接着把销售做好让自己获得更多客户，再引入更多人一起做产品做服务做销售形成一个小生态，最后才有资格谈“增值业务”。

—— 有赞白鸦：SaaS业务的价值评估

如同所有产品在各生命周期中应依循的策略，to B 产品的初期阶段重点在不断增加功能、做MVP、快速验证、快速迭代，以求满足所有核心场景需求，此时过早的引入专业的销售团队未必有利于产品规划，毕竟在产品还未成熟之前又有谁能比产品团队更了解产品呢？

产品开发过程中，产品团队容易沉溺于复杂花哨的功能无法自拔，而忘了做产品的初衷是给客户带来怎样的价值。产品初期阶段，由产品团队亲自做销售和客户支持有几点好处：

通过客户调研验证产品可行性；找到第一批关键客户，共同探索产品解决方案；以客户的视角审视产品价值。

通过客户调研验证产品可行性

产品验证除了要验证产品方向是否契合市场需求，还需要验证产品的整体规划与客户需求的紧急程度是否相契合。

比如，提高客户忠诚度是客户关系管理不变的目标，但多数企业仍处于极力获取新客户的阶段。又比如，用户体验上考虑如何减少用户操作路径自然没错，但企业对用户操作出现错误导致重大事故更加零容忍。

尽早让产品团队接触客户，验证产品可行性，帮助团队合理分配资源以及产品规划。

找到第一批关键客户，共同探索产品解决方案

在确保产品已通过市场的验证并确实与市场需求相契合的大前提下，接下来应该由产品团队来寻找“能与产品一同探索解决方案的关键客户”。产品团队需明确产品的目标客户是谁？所处行业、企业属性、企业规模。

筛选关键客户需要甄别客户对产品的价值：客户是否存在产品所要解决的场景需求。例如产品定位为B2C的客户关系管理系统，却找 B2B（或奢侈品行业的 B2C ）客户做为第一批关键客户，虽然都是客户关系管理的业务，但业务活动的差异性却很大（具体差别不再详述，如有兴趣可自行了解），反而造成产品越是增加功能来满足客户需求就越是偏离产品核心。

筛选客户可以倒逼产品团队更加明确产品的目标市场及定位。

以客户的视角审视产品价值

to B 产品的特点是体量大、功能杂。产品团队每天思考功能用例、功能逻辑、功能实现等问题，到了要向客户介绍产品时，也摆脱不了照着产品功能表平铺直述，没有重点，让客户听的稀里糊涂不知所以。

产品团队亲自做销售，迫使产品团队从客户的视角，用“场景+解决方案”的表述方式向客户传递产品价值。迫使产品团队深入了解相关的业务知识、目标客户的公司特征以博取客户的信任。

在同客户介绍产品的过程中，必须经得住客户的各种质问，包括产品能帮助客户实现怎样的目标、产品同其他竞品的差别。由于 to B 产品的购买者与使用者往往不是同一批人，客户或许会告诉产品团队在真实的使用场景中可能遇到的阻力。

获取一手的客户反馈，可以帮助产品团队更深入的审视产品价值、产品的优势、与竞品的差异性以及接下来产品的发展方向。

三、制定需求审核制度真需求？伪需求？

面对真实客户的需求（无论是产品团队获得的一手需求或是由销售转述的需求），“以用户为中心”的思想让产品团队倾向于不假思索的全盘接受，因为我们总认为客户比我们清楚他们自己的业务需要，其实不然。

假如 to B 产品的客户提出一些功能层面上非常具体的需求，我们必须就该提高警惕了，因为这些需求通常来自以下来源：

1. 来自旧系统功能

当旧系统无法满足不断变化的业务需求，企业或许会选择更换新的系统供应商。然而企业又不愿意轻易改变原有的使用习惯，往往对新系统供应商提出各种具体的功能需求，意图是将旧系统功能照搬到新的系统中。

2. 追“热点”

拼多多引发的“拼团”热让各品牌都蠢蠢欲动的玩起拼团营销。“社群营销”的概念又刮起了新一轮的热议，似乎成了企业市场推广的标配。向来热点在哪里，客户需求就在哪里。

3. 使用痛点

这个来源比较特殊，一般来讲，客户在产品使用过程中遇到痛点应该是产品团队打磨产品的好机会，怎么还需要警惕呢？其一，因为客户通常没有专业的产品思维，不能清楚阐述痛点，他们往往通过提出具体功能优化方案替代真正的痛点。

其二，痛点产生的原因是什么？如前文提到的痛点来自于不习惯旧系统和新系统的差异性，还有其他诸如此类的“个体的痛点”，如若产品团队盯着不放，反而会失去真正的机会。

准确判断出真需求可以让产品少走弯路，这需要团队成员有足够的业务知识以及敏感度，需要团队成员由足够的主动意识去了解真正的业务价值。

对于团队而言，需要形成完整的需求审核分析流程及方法论，才能减少成员个体差异造成的影响，保证产品良性发展。

标准功能？定制项目？

应对客户需求，如果团队没有一套完整的需求审核流程来决定什么需求该走标准产品，什么流程该走定制项目，产品便会在不知不觉中发展成销售驱动的研发模式。

1. 留出足够的需求审核时间

合理的审核流程应该给需求审核工作留下足够的时间，组建需求审核小组，验证客户需求是真需求或是伪需求，是否偏离标准产品所定义的业务范围。如果决定走标准功能，就应该按照研发产品的思路去规划，快速迭代，快速验证。

对于团队的组织架构，理想的方式是区分标准产品团队和项目实施团队，将定制项目从标准产品团队的工作中剥离出来，给标准产品足够的时间专心在核心业务价值。

2. 做 SWOT 分析

面对每个“诱人”的真需求是否应该做为标准功能模块，团队应该从团队自身的角度梳理出 SWOT （ Strengths 优势、Weaknesses 劣势、 Opportunities 机会、Threats 威胁），并在此基础上做出决策。

产品团队是否能实现产品功能的业务闭环是其中一个考量因素。

要实现优惠券功能，则必须考虑如何满足不同企业的核销需求，甚至线下POS系统的对接；除此之外，团队可投入的时间和资源当然也在考虑的范围内，在有限的资源下需要给功能价值排个优先级。

总结

无论是纯粹的产品驱动或是纯粹的销售驱动，最基本的原则都是实现业务闭环，但以销售驱动做着标准产品却很难保证产品的完整性。

要确保产品能朝着正确的规划方向发展，需要团队共同的配合包括：清晰的产品方向、合理的工作流程，以及树立起团队的方法论体系。

本文由 @圆圈圈圈圈圆 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议