心中无运营，产品皆枉然——如何克服SaaS产品运营中项目交付式思维

编辑导读：产品商业逻辑、业务架构方向不对，设计的再卖力也是没有价值，且没有意义的。本文作者从产品设计师的角度，看SaaS产品在产品研发和运营阶段存在的问题，与你分享。

看个真实案例：

“朋友公司有一条开发者产品线，商业模式上相对传统，其产品基本都属于强销售驱动的合同订单和简单的分级（免费和VIP）定价模式，在产品运营上也是比较传统的项目交付式的线下运营。产品研发模式上，是用服务的投入模式在做一个很大的非标准化交割类产品，这样导致两边不沾。

这时候他们出现了两种的呼声，第一是服务商（平台自己）视角，即服务标准化，只有标准化才能降低边际成本，放大业务规模和提升商业化的灵活性。第二是客户视角，即产品服务。

什么是产品？什么又是服务？我的理解产品一般是指一次交易切割归属，服务是持续深入解决客户问题，需要什么作什么，用什么才买什么，用多少就花费多少，当信价比不高觉得不划算可以考虑升级成为整体更优惠的高级版，当不利于企业化协作时可以升级企业版（当然这里面是有一套健康的系统性定价策略的），到这里，大家会发现，产品服务化才是一个可以长期和客户需求共同生长迭代的养成生意。

所以，后来他们从老板这边得到了一个战略性方向指示：“我们的某某产品要做平台SaaS化转型，1234567吧啦吧啦……”，但这之后，产品需求方也没有给出全新的商业化设计方案，以及对于该产品的整体战略目标、阶段性目标、最小产品MVP边界等。

迫于项目工期压力，产品建议交互设计师可以尝试着手开撸，做一些方案探索，所以，他们的设计师又犯了一个业内很容易犯的错误，在没有确定产品目标和划定项目边界的情况下开始着手产品设计工作，就是边设计边思考。因为没有确定地基就开始建房子，虽然投入很多精力，但结果毫无悬念，和老板们的预期相差甚远，可能正式上线生产环境也会和客户需求相差甚远吧，不得而知。

再次印证了那句正确的废话：产品商业逻辑、业务架构方向不对，设计的再卖力也是没有价值，且没有意义的。

正是基于此，就有了整理这篇文章的想法。

一、前言

其实这篇文章很难写，因为我是产品体验设计师，文章主旨其实是想聊产品和运营力本身对产品体验设计价值的影响，有点行外人（实现方）来解构行内人（需求方）的能力分布和策略方法论，进而分析其对自己（实现方）的工作价值的影响，多少会有点拧巴。

且难免在业务细节和商业化视角上有所局限，但觉得应该还是能代表一定的客户价值和业务目标视角，希望能给同行小伙伴些许启发吧。

人类最早的商业化行为应该可以追述到一般等价物出现（斧子和羊），就是《资本论》里的描述的。但真正有意识且具规模化的商业行为，个人理解应该是货币产生后的社会化大生产+售卖现象出现后。

从这里可以解读出商业本身所包含了三个核心环节：需求（客户）、生产（产品）、售卖（销售），虽然各种品牌营销、商业化竞争，以及科技创新千奇百怪，但这个商业底层结构几千年来从来都没有变过，而且这三个环节从来就不能割裂来看。大道至简，映射到今天要聊的话题——企业级服务，也同样适用。

1. 什么是to b（企业级服务）

因为文章读者可能存在行业差异，这里啰嗦一点，拉一下常识吧，之前的文章讲的很多了，to b业务标准定义其实是企业级服务，但企业级服务是一个非常庞杂的业务门类，小到专业咨询服务和原材料供应链，大到产业互联和传统行业数字化转型，不难发现，这是一个偏客户角色的单一视角划分方式，比较粗放，几乎没有标准化能力和方法论的研究价值。

2. 什么是产品

与此同时，我们对产品的标准定义就更加无边界了。

广义的产品是只要满足特定群体需求且可售卖的标准化交付物都可以叫产品，最多在互联网行业还会再细分一下，满足个体数字化消费叫工具，生态属性容器化的叫平台，企业标准化产品的叫SaaS，非标的叫私有化定制或个性解决方案等，那么针对整个行业的产品经理或产品设计师的能力标准和方法论上来看，这下就要命了，之前很少有这么精细化的人才划分，或者能力的更新速度跟不上市场需求的快速迭代。

3. 什么是运营

广义的运营其实是指除产研和销售之外的所有经营性工作，甚至有可能是整个业务的全部，就是所谓经营的概念，显然，以我的能力没有办法讲的完整透彻。这篇文章主要还是聚焦在产品运营环节。

4. 什么是SaaS

既然讲到了SaaS化，就简单聊聊SaaS到底是什么吧。

广义的SaaS定义是软件即服务，这没毛病，就是有点不接地气，就像正统经济学对金融定义是是货币的流转一样，学术界总喜欢用一个可以无限扩展的定义最好能兼容一个领域的发展全历程，其实说人话金融无非就是借款+融资+贷款。

同样，每个人对SaaS都有自己的定义，当一个事物无法被准确定义的时候，那它一定还在长大和被定义过程中，我对SaaS简单定义就是互联网软件产品的服务化，三个关键词：产品、互联网、服务化。

标准化：

有明确的客户群、有完整交付物、可以规模化生产和售卖；

服务化：

互补传统标准化产品定义的缺失、不断满足客户长期发展动态需求、按需付费/用量付费等；

互联网化：

最小mvp快速验证、和客户高频互动长期共建、逐步积累庞大的基础用户规模、依托线上产品运营支撑客户长大体系、还有一条牛逼的销售和市场团队驱动起来的Marketing（营销转化体系）；

接着就引出了接下来要和大家聊的话题——企业服务SaaS化过程中，受传统企业软件服务行业能力和方法论的影响，产品运营力和策略方法的错位，以及产品人和设计师们在日常工作中容易犯的错误，对产品的客户价值（用户体验）和业务目标达成到底有多大影响，最后再分析一下应该如何克服和重新定义这一细分领域对产品人的能力及策略方法论的要求。

二、现状：to b和to c产品能力差异

SaaS产品绝大部分是服务于企业级的，基本都属于to b业态，互联网to b和to c这两个行业其实很有意思，是有各自的鄙视链的，做to c的产品设计人（包括设计师）素来瞧不起做to b的，觉得过度下沉，缺少横向发散及设计思维，创新能力差，只做产品不懂营销，也没什么个人影响力。

做to b的产品设计人觉得做to c的没有行业属性，不属于真正意义上的行业人才，极度缺乏严谨的系统性思维，天下竞品一大抄，没原创、路子野，没有职业化精神。且长久以来这两个领域一直缺少人员流动和能力渗透。但凭心而论，在国内to c行业互联网化的程度是要远高于to b的，这里我们先来对比一下传统的to b和to c产品人的能力差异吧。

以上是整个行业过去产品能力差异的一个基本盘，不完全准确，但应该能覆盖80%的情况。那么这两种皆然不同的能力差异到底有什么问题呢？？别急，后面会讲到。

三、传统企业级软件和企业SaaS产品差异——客户需求洞察

过去：

过去企业级服务的需求、产品、销售三个环节都是由独立且不同的专业角色及团队来承担的，市场或老板来洞察需求，产研来负责落地生产交付，销售来负责售卖，大家分工合作，发挥专业能力优势，一直相安无事很多年。

在产品交付后的维护和迭代过程中，主要也是由销售、技术支持等客服角色来承担售后和承接需求，然后研发响应并完成产品迭代上线，这个过程中，需求向产品功能及服务的转化过程基本是响应式+交付式的，产研很少会主动研究和思考客户的显性和潜在需求，以及具体业务场景差异和需求的标准化程度，当然对整个市场的敏感度也会相对比较低。

现在：

但自从有了互联网，整个世界就变了，互联网把整个世界都压扁平了，不分to b或to c，它不仅打破了信息的壁垒，而且打破了很多专业能力的壁垒，为了精准洞察的市场需求，无论是产研还是市场销售，很多岗位必须具有复合型交叉能力及知识储备，至少具备较强的T型能力分布，所以原来孤立的to b产品专业垂直能力已经不适应SaaS化的能力要求了，产研需要和c端互联网一样，主动下沉到行业，走出去见客户，下沉到客户端主动发掘和获取客户需求，先做行业专家（这很难，但必须要做），再考虑标准化。

在线上需求洞察上，不同于以往企业级软件的全封闭式交付模式，企业SaaS产品在客户使用过程中是可以和平台侧有高频的交互的，用增长设计的运营思路和策略，在产品功能任务闭环中做好相应行为和事件埋点，以及适时反馈的互动通道。产品运营人员或体验设计师可以通过行为事件分析和适时反馈信息，判断和获取客户可能的显性需求或潜在需求，这是典型的互联网思路。

同样销售也需要非常强的专业产品化素养，因为B端产品的高客单价，单纯只会使用销售技巧来逼单的销售策略也不适用了，她们需要站在产品专业角度和标准化、结构化思维来洞察客户需求，对产研端提出更专业客户需求。

四、传统企业级软件和企业SaaS化产品差异——商业化设计

过去：

以前的企业级软件服务商业化过程比较粗暴，老板和销售通过圈内人脉，在酒桌上吹水或者和业内同行聊天过程中获取到了原始需求信息（也可能是间接洞察到的），觉得能赚钱，回来后通过消化给产研下了一个需求，我们要干这个事情，你们研究研究可行性算算成本和收益，可行的话半个月内做个demo给我，我让销售拿出去给客户看看，如果发现有客户要，估个价格，能cover住成本且营利还不错，就开始标准化设计，然后销售大军集中售卖，能卖多少卖多少，多少销售卖多少产品。

现在：

其实严格的说，商业化不是一个固定环节，应该是一个全过程，就是SaaS产品的一生都在做商业化迭代，大部分商业化过程有两种方式，一种是从无到有全新产品商业化设计，另一种是现有业务生态中的客户需求（产品）的扩充或迁移过程中的商业化设计：

第一种：从无到有全新产品；

一张白纸，不仅没有客户，而且完全没有用户基数的情况下，大家通常会借鉴互联网to c模式，即：聚焦于快速市场调研和用户需求画像（这里叫用户，暂时还不叫客户），确定产品目标定位，再以最小商业化版本快速上线，借助市场营销和渠道运营，快速积累客户基数，有了基数在过程中就可以不断和用户高频互动共建（和小米的《参与感》类似），当培养用户习惯和构建迁移成本壁垒之后，逐步商业化（企业要赚钱嘛），大家看到很多互联网化程度比较高的新型saas产品都是这种商业化模式；

第二种：现有业务生态中的客户需求扩充或迁移；

已经具备了一定的业务规模和客户基数的产品生态在商业化迭代过程中最容易犯的错误其实就是拍脑袋，然后开始就搞大版本，特别是在一些传统模式起家的软件公司，因为其泾渭分明的分工模式有个注定避不开的风险就是整个业务压在了过程中的需求洞察和商业化判断上，产品方向不对就是决策者的决策失误，决策者背锅，如果因为验证不充分导致需求跑偏或市场规模化不及预期，最终商业化也会后劲不足；

正确的方式可能也要充分结合互联网的短平快验证模式，老板和销售骨干聚焦于洞察行业典型头部高ROI客户群的需求痛点（保证头部客户没跑偏，保生存），产研团队聚焦于快速市场调研和用户需求画像（保证未来市场规模和潜力，保发展），通过双向市场洞察找到交叉重叠部分，确定最典型用户价值目标。

同样，再以最小商业化版本快速上线，借助市场营销和渠道营销，以及场景化导流，快速双向（用户和客户）验证，随时关注客户结构化特征和商业化潜力，平衡成本投入，边迭代边逐步做商业化版本封装。

五、传统企业级软件和企业SaaS化产品差异——产品运营迭代

过去：

过去企业级产品的运营迭代方式同样也是交付式，什么意思呢？

就是传统软件产品是没有运营这么一说的，产品形态也基本都是完整交割物，交付之后其实离客户就比较远了，记得很清楚5年前我们的财物吐槽金蝶的财务软件难用，但也只能吐槽，因为to b产品的迁移成本很高，所以还是的咬牙用。

而且传统软件因为其服务模式的局限型，就算供应商服务意识很好，但产品服务响应周期也会比互联网产品要长很多，销售不断收集积压的客户需求，然后集中给到产研跟进落地，更新一个新的软件版本，并上线交付给客户使用。

如此周而复始，在以往其实这没啥问题，企业级软件行业基本都这么干，但现在行业步入SaaS化之后就暴露出很多客户体验问题就出现了：

现在：

我们先弄明白上面提到的种子客户的重要性，我也跟我的老板有建议过，我们的产品大部分是传统制造业的生产方式，要么是生产完了去找客户，要么找到一两个客户后就开始生产。

但作为一个SaaS平台，标准化产品形态其实是不可或缺的环节，我的职业生涯中大部分时间都在和互联网打交道，互联网有个特别重要得关键词，叫用户规模，用户规模是一个互联网产品未来商业化的底色，就算是一个垂直行业，也要尽可能做到兼容最大规模的基础用户标准化需求，不是要把所有用户都转化成客户，而是要尽可能的网络最大可能性进入你的产品生态，你嵌入的种子用户（客户）越多，未来可以商业化的空间就越大。

所以新产品初期，一定要充分洞察市场需求的基础上，提炼一个低嵌入门槛、且能快速解决用户某一个痛点的标准化产品，让大量的用户先主动用起来，边用边优化，这就叫共建。

在过程中逐步强化创新产品和其他矩阵产品的高协同性。当用户习惯了你的产品，且被协同进了你的产品网络，其实不出现特别糟糕的产品服务体验的情况下，商业化付费转化并不会太难。即便不会转化，也不需要庞大的销售成本维持这线索，只要用户在产品里面，就是资源池，有足够的商业化空间。

商业化运营也是SaaS产品的一个重要环节，放在互联网C端其实就是用户转化和付费转化的运营的过程，唯一的区别在于SaaS产品的客户运营过程其实就是一套完整的养成游戏，而且b端用户转化的最大门槛在于从免费到付费的转化节点，因为这是一种制度化习惯的转变，从免费到付费这个决策会比较难。但一旦养成付费习惯就具备了客户粘性，就开始了完整的长大游戏，如果产品功能符合客户业务需求，且能满足客户的成本与产出比，一般精细化运营效果都会比较好；

说到用户（客户）粘性，b端客户是要比c端客户高很多的，原因有两个，第一：b端业务决策是一个非常复杂和理性的过程，一旦购买使用了，一般不会轻易切换，除非业务黄了；第二天，b端产品一般是企业级使用，迁移成本比c端要高很多，所以在企业级SaaS一旦把业务场景协同进来了，付费转化、增值服务、定制私有化、专业解决方案商业转化都相对容易很多，最关键还有我们强大的销售维护着客情关系，为客户留存兜底；

六、结语

也许是受传统C端互联网的深刻影响，在我的认知体系中，没有互联网化的to b业务都不能叫SaaS，没有达到一定用户规模的to b产品也不能叫SaaS，所有非标产品矩阵都不完全叫SaaS，所有不能伴随客户长大周期提供一站式服务的产品也不是完整的SaaS。

SaaS产品服务化才是一个可以长期和客户需求共同生长迭代的养成生意，这整个养成过程就叫做产品运营。

本文由 @产品体验设计边界原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议