方法论|心中无运营，产品皆枉然——如何克服SaaS产品运营中项目交付式思维( 四 )_

第一种：从无到有全新产品；
一张白纸，不仅没有客户，而且完全没有用户基数的情况下，大家通常会借鉴互联网to c模式，即：聚焦于快速市场调研和用户需求画像（这里叫用户，暂时还不叫客户），确定产品目标定位，再以最小商业化版本快速上线，借助市场营销和渠道运营，快速积累客户基数，有了基数在过程中就可以不断和用户高频互动共建（和小米的《参与感》类似），当培养用户习惯和构建迁移成本壁垒之后，逐步商业化（企业要赚钱嘛），大家看到很多互联网化程度比较高的新型saas产品都是这种商业化模式；
第二种：现有业务生态中的客户需求扩充或迁移；
已经具备了一定的业务规模和客户基数的产品生态在商业化迭代过程中最容易犯的错误其实就是拍脑袋，然后开始就搞大版本，特别是在一些传统模式起家的软件公司，因为其泾渭分明的分工模式有个注定避不开的风险就是整个业务压在了过程中的需求洞察和商业化判断上，产品方向不对就是决策者的决策失误，决策者背锅，如果因为验证不充分导致需求跑偏或市场规模化不及预期，最终商业化也会后劲不足；
正确的方式可能也要充分结合互联网的短平快验证模式，老板和销售骨干聚焦于洞察行业典型头部高ROI客户群的需求痛点（保证头部客户没跑偏，保生存），产研团队聚焦于快速市场调研和用户需求画像（保证未来市场规模和潜力，保发展），通过双向市场洞察找到交叉重叠部分，确定最典型用户价值目标。
同样，再以最小商业化版本快速上线，借助市场营销和渠道营销，以及场景化导流，快速双向（用户和客户）验证，随时关注客户结构化特征和商业化潜力，平衡成本投入，边迭代边逐步做商业化版本封装。

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