前言
本文采用故事的叙事方式，从研发、产品、运营、销售、售后、财务等视角，轻描了一家转型做SaaS的创业公司，在开局阶段会遇到的种种问题，文中观点亦能代表我的个人观点，包括偏见。
本文大致分为五小部分：
一、产品吹风（水）会：老板开会沟通转型做SaaS，核心人物挨个登场亮相。
二、MVP与CVP：小张提出，MVP中应该表达CVP（客户价值主张），这是个什么概念呢？
三、技术债的形成：研发在抢时间时总会留下技术债，小张提出需要作记录，以后再还债。
四、空降的“客户成功”：老板指出“SaaS的核心在于续费”，而新成立的客户成功部门（CSM）要背这个KPI。
五、业务、数据与产品迭代：老板否定“免费”策略，也暂时否定“定制化”。他认可COO列出的LTV（客户生命周期价值）、ARR/MRR（年度/月度经常性收入）、ARPA（账户平均收入）等经营管理指标和计算口径，希望从最初就做好数字化经营。
一、产品吹风（水）会
那是个普通的凌晨，小张听到一阵急促的钉钉电话铃声，心想：莫不是系统出问题了？原来是老板打过来的。小张看看时间，2点，只能苦笑着接通电话。
“张工，我们高管层打算转型做SaaS了，明天早点来，我和你讲讲我的构思。。。”
嘟。。。
小张是公司的CTO&技术合伙人，按照职级，应该属高管序列，为啥每次都成为被“通知”的对象？小张嘟囔了几句，很快意识到：老板这么晚打电话通知我要转型，要么在头脑风暴，要么在头脑发热，搞不好明天就忘了。
第二天，小张刚走进公司，就被运营老大拉近会议室，各位公司大佬早已围坐在椭圆桌，老板开始画饼。。。额，不，开始画构思图。
在座的大佬有运营老大（COO）、销售VP、财务总监、风控总监，以及一大堆不知道分别管什么的合伙人，3小时过去，这些高管们听的津津有味，踊跃发言，一扫之前业务停滞的阴霾，貌似抓住这次SaaS转型，就能彻底翻身。但小张听的云里雾里，只记得大概要做一个To B的广告营销SaaS产品，这种佛系“听”会状态，显得让他与其他高管格格不入。越是如此，大家的焦点就越是集中到他的身上，有那么一刻，小张突然觉得如芒在背，耳边终于响起一句熟悉的台词：
“张总，你觉得开发这个产品要多久？”这句台词，来自COO，一位作风强势、行事干练的office lady。
然后，销售VP开始搭腔，“张总，你们开发要快点啊，不然我们销售团队只能干等着，耗不起”，说罢看看老板。
小张涨红着脸，额上的青筋条条绽出，欲辩而不能。
接着，那些平时隐身的合伙人，突然七嘴八舌，开始热闹起来，办公室甚至出现了快活的气氛。（此处感谢先贤鲁迅）
小张四周看了看，貌似只有风控老总不说话，也对，一旦转型做To B，风控可以发挥的空间并不大，他可能想要跑路了吧，都不容易。小张收了收尴尬的情绪，一字字儿的说道：“先做完需求调研、产品设计，我才能排期”，这是个所有人无法反驳的标准答案。
二、MVP与CVP
公司的CTO线包含了产品团队，所以小张得马上安排产品经理与业务部门一起完成前期的调研与产品设计工作，在此期间，小张只负责协调工作，毕竟，一个写代码出身的工程师，对业务领域并没有太大兴趣。随着工作的逐步推进，小张发现自己对产品的把控力越来越弱，而产品与运营部门的合作反而有声有色，多次在会议上联手对研发团队发起挑战，以至于老板认为，产品团队应该放在运营部门，随后适时调整了该组织架构。
从长远来看，假如CTO对业务的敏感度不够，这个组织架构调整无疑是正确的，但让当时的小张产生一些微妙情绪，他倒并不是因为丢了“部分地盘”而气馁，而是让他认识到：技术人假如能懂业务，会对未来发展更有利，至少拥有更多话语权。所以为了能主动把控产品研发的走向，他利用业余时间学习了众多SaaS相关的业务知识。
COO这边在接管了产品部门后，加大需求调研的力度，他们的调研手段略显原始：线上问卷、微信投票。调研的对象，大部分来自自有的人脉关系。COO很快发现，这些人脉碍于情面，大多能给予礼貌回复，但却无法有效反馈真实需求，COO和产品经理小李果断把方向转到竞对分析，他们认为，公司团队大多没有做过类似产品，我们不妨先学习下竞争对手是怎么做的，所以他们做了下面这个表：
不得不说，该表非常不错，按照这个框架来做竞对分析，可以逼迫自己从中找到差异化，提炼自家产品的价值，这对两眼一抹黑的产研团队来说，是有很大帮助的。很快，产品经理小李很快做出来第一版PRD，准备给老板做汇报。
同样的椭圆桌上，小李自信且有节奏的阐述着产品主线流程，COO适时在旁边补充说明，老板边听边点头，很显然，他非常满意。小张也听完了整个PRD汇报，他基本认可运营和产品给出的这版设计，但作为CTO，他那种特有的技术神经开始涌动，他突然想提出PRD中隐藏的逻辑问题，以及技术可行性难题，没等他开口，老板和其他高管们开始发表自己的意见，毕竟对着PRD，大家总能提出更多需求，这就好比大家对着白纸，想象力有限，只能胡诌，而对着一张半成品的画作，总能让人有欲望涂抹各种颜色。最终，原本一个垂直营销产品，变成了一个大而全的通用型产品，大家都很满意，除了小张。
但此时他不得不硬着头皮回答那个该死的deadline：“目前看来，开发需要半年。。。” 老板差点没从老板椅上掉下来。你们懂的，解释已经不重要了。
此时产品经理小李提出：咱们可以在最初做一个MVP（最小化可行性）版本，一边收集客户反馈，一边不断迭代升级。小张表示非常正确，但问题是，MVP只是一种策略，而不是目的，这个产品的核心价值应该是怎样的？毕竟这与MVP的定版息息相关。假如无法在最初抓住核心价值，B端客户是不会给你机会继续迭代的。我们经常听到“满足需求”、“抓住痛点”等说法，实际上，这是句正确的废话，而且对于B端客户，他可能已经有一条谋生之道，这条道虽然行得慢，但能持续前进，他并不觉得会有痛点，此时给他谈“痛点”，无异于隔靴搔痒。小张之前的业务知识没有白学，他了解到一个词，叫做【客户价值主张】。
客户价值主张（Customer Value Proposition），简称CVP，简单来讲就是说，产品的价值要与客户的目标产生联系。客户可以没有直接的痛点需求，但一定有他的目标，比如：让广告转化率提升30%。而要实现这个目标，需要打造哪些流程、使用哪种工具。按照这个大方向来思考问题，更有助于打造更符合客户需要的产品。
就这样，小张和COO、小李（产品经理）主动沟通了自己的想法，小李心里顿时觉得，原来张总还是懂点产品思维的，不再是个只会写代码的张工。一旦产品技术达成共识，后面的事情就好办了。就这样，他们和业务部门一起搞定了MVP版本的设计。
三、技术债的形成
小张作为公司技术一把手，始终参与一线技术选型、架构设计，这是一位35+岁“老人”给他的忠告：小张，虽然你当管理了，但千万别丢了技术，否则到我这个年龄，只能混成替代成本极低的中层。小张基本认同，但经历了之前的产品组织架构调整，他发现，这位“老人”仅仅说对了一半儿，因为：既然已经作为技术管理者，随着公司的发展，以后肯定会越来越偏向管理，假如只是埋头做技术，实际上是无法有更大发展的。所以，自己应该在不脱离一线技术的前提下，多提升商业与管理能力。
无论如何，小张觉得自己需要深度参与这个产品的整个研发流程。很快，小张和几个核心工程师遇到了一些困扰：目前这个版本的产品，是满足最小可用的MVP版，那么在架构选型上，到底该采取保守的单体老方案还是先进的服务化新方案？所谓单体方案，就是指使用最易上手、开发速度快、但由于不怎么考虑功能模块拆分、数据拆分&隔离，导致扩展性极低的方案。服务化方案，就是指前期尽可能考虑上述要点，但是需要花更多开发时间的方案。假如选单体方案，开发团队绝对能完成开发任务，但后续迭代升级会比较坑爹，甚至只能完全重构，所谓“一直保守一直爽，迭代掉进火葬场”；假如选服务化方案。。。额，开发时间足以让老板再次从老板椅上掉下来。
小张敏锐的指出：服务化方案不仅是开发时间较长，而且由于我们的业务模式还未定型，业务抽象还远远不够，那么分模块服务化实际上不一定能达到想要的效果，说简单点，服务化的划分可能在最初就会分错。其他工程师纷纷点头。他接着指出：我们可以在整体架构上选择单体模式，但是仍然遵循前后端分离开发，并且一些可能不会有较大变化但又很重要的模块，先做单体内的模块化，数据那一层做好隔离，并且减少使用进程内的锁机制，从最初就引入分布式锁和消息中间件，这并不复杂，并且，能用云服务就尽量用云服务，以后假如做升级改造，就相对容易点。说罢，小张内心一阵傲娇，自信的看了看各位，觉得再也找不到比刚才更好的方案了，做CTO的感觉真特么爽，此时，一个声音打破了短暂的宁静：
“虽然有开发规范，但实际开发过程中，由于要抢时间，大部分工程师只会选择更快方案，而不是更优方案，如何处理？”
小张稳了稳身体，说道：“抢时间，允许留下一定的技术债，但必须文档记录下来这些债，以后再还。”
就这样，在小张和核心工程师的努力下，完成了MVP版本的开发。
四、空降的 “客户成功”
就在研发部门如火如荼的996时，COO这边也没歇着。COO线目前下辖品宣部、客服部、数据分析部等，算上新划过来的产品部，COO目前算是大权在握，但是，她目前遇到几个问题：
- 公司的老业务是做C端电商的，整个运营组织架构是根据C端业务来建立的，现在要转成B端SaaS，得重构整个团队；
- 销售团队在过去是做C端线下代理起家的，而在老业务中，营收主要靠线上，线下销售团队成果寥寥，COO线的实际工作并不和销售团队牵连太深，而目前转做B端，长远来看，必须依赖线下更多，COO必须和销售团队加强合作，销售团队本身也需要给力一点，否则自己可能会被拖下水。
鲁迅说过（没有），要建团队，先定KPI。C端运营和B端运营体系不同，KPI自然不同，对团队的要求也就不同。而运营团队的KPI，又和运营目标息息相关，所以COO打算找老板来做一轮汇报，谈谈自己对运营目标的看法。当然，为了能得到销售团队的支持，她也拉上了销售VP老陈。而老板也带了一位陌生面孔参会，从其穿着来看，像是一位职场精英。
会上，COO对老板指出：B端产品的营销和销售策略和之前老业务会有较大区别，以往C端产品可以直接线上成交，现在得线上线下一起来完成，线上提供线索和售前咨询，线下跟进成单交付。销售VP老陈表示赞同，他感觉到自己的销售团队将会成为新业务最重要的一环，以前做C端产品，他没啥表现的机会，但这次不同，ToB端几乎不可能纯线上成交，最重要还是靠线下销售。老板对此也心知肚明，他问了两位一个问题：
“我们现在最重要的是规划一个可执行落地的推进方案，包括团队搭建/重构、KPI、工作流、部门协调等，你们有什么建议？”
老陈指出：销售这边建议走渠道&代理商的路线，在最初多让利一点，方便快速打开局面，也减小初期销售团队搭建成本，另外，代理商可做售后。至于KPI，一是看成交，二是看售后。
COO表示：运营这边会让原来品宣部逐渐承担线上线索管理，在清洗后交给销售这边，他们的KPI也可以跟成交挂钩，也就是说，老陈这边既可以自开拓，也可以用我们这边的线索。至于售后方面，我们客服团队也可以继续支持。
老板顿了顿，提醒到：我们这次转型做SaaS，一定要先搞清楚它和以往产品的核心区别。首先，To B的客户相对具有稀缺性，获客成本高，假如在最初不能很好的打动客户，丢单风险大。所以我建议在最初，我们搭建自己的直销团队，这样可以在最大程度上保证服务质量，并且可以将服务过程中掌握的客户真实需求，以最短路径反馈给我们的产品团队。等产品打磨的差不多了，我们跑顺了这条路，再搭建渠道代理，并将经验复制给他们。另外，我认为，SaaS的核心在于续费，而不仅仅是最初成交，因为只有真正的产生了续费，才说明你的产品是成功的。说的更现实点，从长远看，我们的赢利主要看续费，所以我觉得，这块应该要单独组建一个部门，叫作【客户成功部】。
客户成功管理（Customer Success Management），简称CSM，是近几年新流行的概念，从字面意思上来看，它是指“帮助客户成功”，但这只是其目的之一。真正的客户成功，是指在产品交付后，通过对客户的长期维护与服务，来实现客户留存、续费。
COO提出：过去的客服部门承担了售后的工作，那么现在经过培训一下，可以直接改组成客户成功部。
但老板表示：客服部门过去仅服务C端用户，对B端企业并无太多经验，而且客服工作过去都是“被动式”的服务。但客户成功团队，必须对B端企业非常了解，他们应该是一个主动式的服务团队，另外客户成功部必须是个盈利部门，他们须背负续约&续费的KPI。目前我决定亲自组建客户成功部，该团队负责人已有人选，他将直接向我汇报，大家欢迎一下田总。他面带微笑，眼神瞄了瞄身边的这位“陌生人”。
...鼓掌，papapa...
两位高管这才明白，原来老板其实是有备而来。最终，他们决定：
1.COO改组原品宣部，设独立线索团队，负责寻找、清洗目标线索，然后交给销售团队， 线索团队与成交挂钩。
2.老陈重新设计KPI（去掉售后KPI）、话术。直招团队既可以采用线索团队给予的目标客户，也可以自拓展。其中线索质量可以通过系统反馈给线索团队（与KPI有关）。
- 田总负责客户成功部的组建，并将原COO线的客服部接管过来，作为客户成功部的辅助子部门。CSM的KPI与续费相关。
五、业务、数据与产品迭代
MVP版上线后，各部门按照事先定好的流程展开工作，由于前期工作太过重要，老板身先士卒，也参与了获客、调研、甚至销售的各个环节，他从中发现了一些问题，准备拉高管们开会做个沟通与分享。
会上，老板先让各位负责人汇报下目前的情况。
销售VP老陈指出：目前我们进展比较缓慢，为了迅速打开局面，前期是不是应该考虑实行免费策略，尽可能多获客，另外，有一些客户反应，咱们的功能点还是不够个性化，他们希望做一些定制化开发。
COO说道：目前销售这边是找过我们产品团队，我们也收集了一些新的功能需求，然后和张总（CTO）沟通了下，他表示目前需要看下研发排期。另外，目前我们遇到的一个最重要的问题是数据指标问题，之前一直忽略，但我认为有必要确认一下这些指标，最近财务那边也在和我做一些沟通。
财务总监接着这话，说道：没错，最近我们发现成本严重超支，大部分应该是用于获客上了，另外我们财务这边的一些收入上的算法，可能和业务团队的理解是有差异的。
老板起身打开电子白板，分别写下：免费、定制、成本、指标，看来是想要一一解决这些问题。
首先，他指出：免费早期是C端产品的玩法，这类产品用户群体广、客单价低、决策快，免费策略可以快速吸引大波流量，然后在留存的用户上做增值服务。但在To B这端，免费可能会导致以下几个问题：
- 获客质量不高。这类用户假如是因为免费采用，那么说明他们可能并不是目标客户。而且没花钱买的东西，更容易放弃。
- 目前是我们产品的打磨阶段，假如放掉了难啃的骨头，会失去收集真实需求/反馈的良机，不利于产品迭代
- 销售人员可能会刷单，浪费公司成本。
另外，即使我们免费，但对于客户来说，他仍然是有很多成本的，比如：决策成本、培训成本、使用过程中的配合成本等，客户的成本本身不可能为零。所以，我们选择不免费。
接着，他指着“定制”二字，提到：我通过一些人脉接触到了一些大客户，他们内部业务复杂，并非通用系统能搞定。他们的负责人确实跟我多次提过做定制化开发的需求，而且钱不是问题，只要能做，就能保证我们能盈利，但不知道我们研发团队这边是否能承接的住？他望向CTO小张。
小张回道：能做是能做，但问题是一旦开了这个口子，以后定制化的需求可能会越来越多，那么这势必会影响我们核心产品的进一步迭代。假如真的决定做定制化，我们也需要有一些策略。比如，定制化过程中的核心功能，可以适时的合并进入主线产品，丰富我们主打的核心产品；而对于比较大的定制化功能，可以做成不同行业版，丰富我们的产品线。假如要两条腿一起走路，老板，我们得加人啊。。。
小张的这番表态，既点出了核心问题，也给出一定的解法，还顺便提了人员需求，这让同时参会的产品同事暗暗佩服：以前你可不是这样的。
老板点了点头，他意识到，现在当务之急仍然是我们的主线产品，假如强行同时开辟两条战线，耗费了资源和精力不说，可能还耽误战机，最后啥都做不好，所以他决定，仍然全力开发主线产品，定制化的事情先放放。
接着，老板望向财务总监：成本及测算方面，你有没有什么建议？
财务总监指出：目前我是凭直观感受，认为最近成本偏高，实际上我理解是因为最近要推市场和重构团队才导致的。但是我希望业务侧能对成本有个基本的规划和控制，比如说，你们可以告诉我，大概获客成本在什么区间内算是比较正常。
此时COO表示：目前来说，业界的一个推荐算法是，客户终身价值（LTV）：获客成本（CAC）>=3，是比较正常的，低于这个范围，应该就属于偏高了。
客户生命周期价值（Life Time Value），简称LTV，就是指客户在使用产品的完整期间所花的费用。获客成本（Customer Acquisition Cost），简称CAC，就是指获取一个新客户锁需要的成本。
财务总监继续提到：我们的SaaS产品，在收费及服务模式上和之前有很大区别，比如说过去用户在发生购买后，一次性交易的总额就可以算作收入，后续服务可以忽略不计。但现在是，销售和客户签约，合同总额还不能算成是真实收入。比如我们产品年费是12000，平摊到月份上，即1000/月，客户使用的月份数1000，才是我们的【确认收入】，而（12-已使用月份数）1000实际上算是【递延收益】，在我们财务上应该算在负债里，因为还未提供真正服务。那么，在提成设计上，是否应该考虑到这个问题？当然，我是从财务上提供个思路，具体还要看业务侧。老板点头表示同意，他希望销售部门这边后续能给他一个更好的提成和考核方案，反正目前仍在战斗前期，纠偏纠错都比较容易。
老板继续指着“指标”说道：其实刚才大家或多或少都聊到与数据、指标相关的话题了，这也充分说明了它们的重要性，我们要想持续发展，从最初就要做好数据&指标的统一口径，否则以后会很乱，现在我们重新梳理一些重要的指标，让它们逐渐成为我们的决策依据，后续可以让研发团队体现在后台DashBoard里。由于COO之前是做业务分析出身的，她对运营指标比其他高管更熟稔，加上她自己本身也需要背负运营指标，所以指标问题由她来主导。
COO拿出已经整理好的运营指标，再辅以讲解说明：
- LTV刚才已经给大家解释过了，我们最重要的目标，实际上就是提高客户LTV，为了以后做客群分析，我们现在需要对客户进行分类&分级；
- 年度经常性收入（Annual Recurring Revenue），简称ARR，就是指客户（账号）每年订阅所产生的持续性收入，假如是多年合同，就分摊到每年做计算；
3.月度经常性收入（Month Recurring Revenue），简称MRR，就是指客户（账号）每月订阅所产生的持续性收入，假如是年合同，就分摊到每月做计算；
- 账户平均收入（Average Revenue Per Account），简称ARPA，指每个账户（客户）每月或每年产生的平均收入，我们统一按月做计算；
- 客户流失率=流失的客户数÷客户总数*100%
- 年客户流失率=[1-（1-月流失率）*12]×100%
- 收入流失=SUM（流失客户的MRR）
- 收入流失率=期间流失MRR÷期初MRR×100%
- 总MRR流失率=[（降级MRR+取消MRR）÷（期初总MRR）]×100%
- 净MRR流失率=（损失MRR-扩张MRR）÷期初总MRR×100%
...新交付客户本月活跃率...CSM平均服务客户的ARR...
就这样，大家在COO的主导下，彻底统一了各项指标，另外，她还希望下面这个客户流失队列分析图能在后台系统有所展示，以便可以看出客户在哪个周期流失率最高：
队列分析图，来源《SaaS攻略：入门、实战与进阶》
总体来看，老板非常满意，他明确指出：ARR/MRR这两项指标可以说是SaaS的重中之重，我之前提到的“SaaS的核心在于续费”，实际上就和这两个指标息息相关。另外，我也了解到，投资机构对我们SaaS公司的估值，也基本与ARR有关，甚至简化成 【估值】=【ARR】*【倍数】。
会后，大家各司其责，投入到繁忙的破局之战中。
后记
虽然这家公司的高管们逐渐摸清了SaaS创业之路，但可以想象，随着执行工作的展开，他们将会遇到更多困难，比如管理、技术债、指标压力，也可能会遇到更多诱惑，比如定制化、平台化等等，在这个过程中，他们又会有哪些故事呢？
我暂无能力写其终局，只希望未来可期，以及，
未完待续。