商业化|心中无运营，产品皆枉然——如何克服SaaS产品运营中项目交付式思维( 三 )

在线上需求洞察上，不同于以往企业级软件的全封闭式交付模式，企业SaaS产品在客户使用过程中是可以和平台侧有高频的交互的，用增长设计的运营思路和策略，在产品功能任务闭环中做好相应行为和事件埋点，以及适时反馈的互动通道。产品运营人员或体验设计师可以通过行为事件分析和适时反馈信息，判断和获取客户可能的显性需求或潜在需求，这是典型的互联网思路。
同样销售也需要非常强的专业产品化素养，因为B端产品的高客单价，单纯只会使用销售技巧来逼单的销售策略也不适用了，她们需要站在产品专业角度和标准化、结构化思维来洞察客户需求，对产研端提出更专业客户需求。
四、传统企业级软件和企业SaaS化产品差异——商业化设计过去：
以前的企业级软件服务商业化过程比较粗暴，老板和销售通过圈内人脉，在酒桌上吹水或者和业内同行聊天过程中获取到了原始需求信息（也可能是间接洞察到的），觉得能赚钱，回来后通过消化给产研下了一个需求，我们要干这个事情，你们研究研究可行性算算成本和收益，可行的话半个月内做个demo给我，我让销售拿出去给客户看看，如果发现有客户要，估个价格，能cover住成本且营利还不错，就开始标准化设计，然后销售大军集中售卖，能卖多少卖多少，多少销售卖多少产品。
现在：
其实严格的说，商业化不是一个固定环节，应该是一个全过程，就是SaaS产品的一生都在做商业化迭代，大部分商业化过程有两种方式，一种是从无到有全新产品商业化设计，另一种是现有业务生态中的客户需求（产品）的扩充或迁移过程中的商业化设计：
第一种：从无到有全新产品；
一张白纸，不仅没有客户，而且完全没有用户基数的情况下，大家通常会借鉴互联网to c模式，即：聚焦于快速市场调研和用户需求画像（这里叫用户，暂时还不叫客户），确定产品目标定位，再以最小商业化版本快速上线，借助市场营销和渠道运营，快速积累客户基数，有了基数在过程中就可以不断和用户高频互动共建（和小米的《参与感》类似），当培养用户习惯和构建迁移成本壁垒之后，逐步商业化（企业要赚钱嘛），大家看到很多互联网化程度比较高的新型saas产品都是这种商业化模式；
第二种：现有业务生态中的客户需求扩充或迁移；
已经具备了一定的业务规模和客户基数的产品生态在商业化迭代过程中最容易犯的错误其实就是拍脑袋，然后开始就搞大版本，特别是在一些传统模式起家的软件公司，因为其泾渭分明的分工模式有个注定避不开的风险就是整个业务压在了过程中的需求洞察和商业化判断上，产品方向不对就是决策者的决策失误，决策者背锅，如果因为验证不充分导致需求跑偏或市场规模化不及预期，最终商业化也会后劲不足；
正确的方式可能也要充分结合互联网的短平快验证模式，老板和销售骨干聚焦于洞察行业典型头部高ROI客户群的需求痛点（保证头部客户没跑偏，保生存），产研团队聚焦于快速市场调研和用户需求画像（保证未来市场规模和潜力，保发展），通过双向市场洞察找到交叉重叠部分，确定最典型用户价值目标。
同样，再以最小商业化版本快速上线，借助市场营销和渠道营销，以及场景化导流，快速双向（用户和客户）验证，随时关注客户结构化特征和商业化潜力，平衡成本投入，边迭代边逐步做商业化版本封装。

文章插图
五、传统企业级软件和企业SaaS化产品差异——产品运营迭代过去：
过去企业级产品的运营迭代方式同样也是交付式，什么意思呢？
就是传统软件产品是没有运营这么一说的，产品形态也基本都是完整交割物，交付之后其实离客户就比较远了，记得很清楚5年前我们的财物吐槽金蝶的财务软件难用，但也只能吐槽，因为to b产品的迁移成本很高，所以还是的咬牙用。
而且传统软件因为其服务模式的局限型，就算供应商服务意识很好，但产品服务响应周期也会比互联网产品要长很多，销售不断收集积压的客户需求，然后集中给到产研跟进落地，更新一个新的软件版本，并上线交付给客户使用。
如此周而复始，在以往其实这没啥问题，企业级软件行业基本都这么干，但现在行业步入SaaS化之后就暴露出很多客户体验问题就出现了：

业务体态臃肿导致产品更新维护成缓慢且成本高；
- 上一页
- 1
- 2
- 3
- 4
- 下一页