2016年至2019年我在某SaaS软件厂商工作，以产品经理身份入职，离开时是产品线的业务负责人。完整经历了从软件上线无人问津，到销售略有起色，再到完成千万级别的业务流水的整个过程。最近在与一些企业主交流软件厂商的销售工作，随即将交流过程整理成文章发出。
因为目前还在涉密阶段，简单分享一下过程，进结果来说还是能看的。
- 2016年4季度上线，万级别流水
- 2017年百万级别确认收入
- 2018年千万级别确认收入
产品经理参与销售
我是这个产品线的第一任产品经理。作为SaaS产品，收入是所有指标里最关键的指标之一。上线的三个月内无人问津这件事是非常尴尬的。所以我便拉着两个客服，一个运营，组成了一个4人工作小组开始销售推进工作。期间想了很多方法，但也趟出了一条路子。
当时的工作方式是这样的：
- 将客资分配给成员负责跟进；
- 与用户首次沟通，确认业务需求；
- 搜集用户所在行业及业务信息，基于我们的产品做全量的业务设计；
- 工作组进行案例讨论，完善方案；
- 与客户二次沟通进行提案引导付费；
- 记录每一条客资的进展情况并进行组内复盘。
在措辞上，我使用了「提案」这个词。以我有限的工作习惯来看，我认为在商业社会中双方合作最理想的合作方式就是基于对方的需要提出解决方案，然后决定是否付费。这个过程简称为提案。那么面试，争取资源，项目启动，升职答辩都是一场提案。而提案的核心就是认真搜集资料，提前做准备。
在充分准备下，双方的关注点会停留在「需求是否满足」「预算是否充足」这两件事上。合作会变得聚焦和专注，成果也会一目了然。当时我跟团队的要求是，一个客户最多就沟通三次，超出了就不再投入资源跟进，也不消耗客户的时间。
作为一名产品经理，销售过程也属于产品的一部分。用户是带着需求而来的，在销售过程中做好用户服务这部分的核心交付本身就是产品人的分内之事。
大多数时间，团队里的产品经理都是离用户比较远的。即便在boss的要求下，会有定期面谈客户，回复用户反馈等常态动作，我的亲身经历也是收效甚微（深层原因是立场上的割裂，改天再谈）所以让产品经理参与销售也是ToB企业里必要条件。
只有亲力亲为才能设身处地地了解客户成功的困境，销售的难处，用户的诉求，财务与法务的痛点。
什么叫用户？除了产品经理本人之外的所有人都属于你的用户。从用户角度出发不是一句空谈。
之前看过一个讨论“ToB业务的产品经理考核指标”我觉得答案太清晰了，ToB业务的产品经理不背业绩指标背什么指标?
像做产品一样做团队
四人工作组的模式运行效果还是比较可观的，转化率流水都呈现出健康的增长势头。在销售方法的探索上阶段性胜利了。
2017年初，在boss决定选择inbound marketing的增长方式。
科普一下Inbound Marketing，又叫集客营销， 是让顾客自己找上门的营销策略，是一种“关系营销”或是“许可营销”，营销者以自己的力量挣得顾客的青睐，而非传统广告方式去拉顾客。
记得那会儿boss安排市场团队开始高频次地在简书（现在还看得到）发布文章，希望市场团队把企业协作，企业软件的行业洞察整理成文，引导用户阅读并获得认可，然后进站注册使用。以此来增加获客效率。
我任职的这家企业风格偏向于保守和人文，追求体面的风格。所以思维惯性导致做出inbound marketing的营销决策也很正常。作为产品经理，处于业绩压力我只会更加激进地寻找有效的方法。
我当时有两则观察：
- 中小企业主职业化进程还很低
- 销售团队需要更理性的培养设计
中小企业主职业化进程还很低，有书写邮件，阅读博客习惯的企业主比例仍然不高。所以前文提到的inbound marketing确实孤掌难鸣。此时，大多数企业主在购买软件时的用户心智依然还是花钱买人的服务。
- 以往只能自己申请发票；在企业版里，我们要求销售主动询问是否寄出发票；
- 以往只能通过表单反馈提需求；在企业版里，我们让每个企业都有专职的销售经理服务；
- 以往只能自己阅读博客摸索使用；在企业版里，我们让销售主动给企业主的团队做培训。
我的判断是中国的SaaS业务依然处于初级阶段（需求侧），为了获得增长必须用双脚沾泥的方式解决SaaS模式下解决不了的问题。
在这一番拉扯之下，我的主张逐渐有了效果。我的团队开始拥有了第一个全职的销售人员，随后有更多的客服，客户成功逐渐转型成全职的销售。
销售团队需要更理性的培养设计。说到销售大家很容易联想到“游泳健身了解一下”。这是销售，但是这种销售方式应用在SaaS业务中大概率会水土不服。换言之，针对新的业务形式，传统的销售方法也要审时度势重新设计。我们当时的做法是：
- 所有销售都有三个月的试用期；
- 每个销售都有导师代教，导师要为新人的转正负责；
- 第一个月优先学习产品，不要求出单；
- 第二个月配合导师销售目标达成；
- 第三个月开始接触客户，独立完成销售。
除此之外：
- 将销售进行分组，考核指标团队化；
- 在销售团队也部署了站会机制；
- 同步销售进展时给予寻求支持的机会。
传统的销售在企业内属于变动成本，即只要叠加就能创造更多收入。但更多销售涌入，服务质量跟不上。销售赶鸭子上架给用户售卖自己都不相信的产品服务，这对用户来说是一种伤害。在我们销售线索有限的情况下，我们会先打磨好自己的销售团队。让产品的这部分竞争力提升再进行服务转化，会更加可靠。
我个人认为最理想的企业文化是工程师风格的，即企业内各个岗位都在当前范围内压榨出最大的性能。所以这种氛围下，我们的销售在遇见产品功能不满足的情况下，第一时间不是跑来找产品提需求。而是自己坐下来捣鼓研究半天，看这个方案有没有其他解法。
我曾经在面试产品运营时设计了一个动手作业「用我们的产品完成一份DICS问卷设计」
当时候选人的作业成绩都不够理想，但后来有个销售团队的同学兴冲冲跑来找我说自己完美实现了这个场景。我对着作业检查了一番，确实如她所说完全使用已有功能实现。虽然配置过程较长，但用户如果收到这个提案，付费意向一定是非常强烈的。
很多时候，软件开发企业中销售和研发团队之间总是会相处不那么愉快。大概率是销售团队中留存着日积月累的管理债务。但是提前从机制层面做好销售团队的设计，将会事半功倍。
如果没有坚定落实销售团队的搭建工作，后面的百万，千万级别流水的实现都是镜中花，水中月。
因地制宜调整管理机制
前文我们说过，很多时候产品研发团队和销售团队或多或少都会有冲突。屁股决定脑袋没办法的事，分歧是系统性的，无法被消灭的。针对这种系统性风险，我们当时是这样做的：
前文：
- 将产品线的相关的各个岗位合并统一管理；
- 以工作组的形式进行资源的统一调配。
一个组织，首要考虑的问题是谁是我们的敌人，谁是我们的朋友。但是团队独立的时候，立场导致的惯性很容易让我们用设置边界方式思考和决策。
举个栗子：产研团队会说“你们销售应该更认真地使用产品，这些功能都是正常运转的。“而销售团队会说“客户不会用，觉得不好用，你得优化下体验。”
事情还没进入讨论阶段，都已经开始上纲上线。对话还没开始，对立情绪就已经涌向心头了。在产品的任何时间段都是非常危险的。
我们当时调整了管理机制，将产研团队和销售团队合并，整个团队共享一个业务目标。即我们不是企业的两个职能部门，而是为了同一个目标一起奋斗的团队。
- 销售在前线，用产品给用户提供可靠的引导服务；
- 产研在后端，让产品快速迭代，让更多功能作为弹药。
销售知晓我要在什么阶段做哪些功能，这些功能上线他们将获得什么样的能力。销售也会很有底气地跟客户承诺。销售过程中也会带回第一手的情报，产品缺少xx功能有了就付费。动态调整产品研发计划，以获得付费。同时研发也很清楚知道自己开发的功能与商业目标达成之间的关系。
在掌握好颗粒度的情况下，产研和销售团队的工作氛围是非常高涨的。一个需求，从用户提出到最终付费，不超过3个工作日。
当团队中每个人能看到自己的工作与最终结果之间的关系，这本身就是一个奖励。
这些管理机制优势劣势都很明显，天花板也是显而易见的。集中力量办完大事，还是要回到常态的组织建设循环中。17年4季度，在销售团队配置完整之后，管理机制随之变更为按照部门划分的方式。
总结
说到增长的策略，仿佛身处这个时代的每个人都能夸夸其谈地讲出好好些道理。但我们依然缺少把每一项分内之事做好，做实的能力，也缺了一点保持冷静和智慧的耐心。
SaaS的增长是一套完整的系统工程，他不是你找几个growth hacker，做几次市场活动，投入多少广告预算就达成的目标。尤其面对中国复杂的商业环境，让SaaS业务存在更大的挑战。
天助自助者，做好准备等风来。
有人看的话，留个言或者点个在看。下篇写写搭建销售体系过程中的遗憾。
作者：马曦文，通过思考交换价值，继续相信善良、美好和未来；公众号：maxiwenfine
本文由 @ Lil_Sun 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
