复盘：我是怎么把一个SaaS产品做死掉的

编辑导语：我们经常能看到很多产品做成功的经验，失败了的产品经验却很少能够看到。然而，光有成功的经验是远远不够的，失败的经验也能给我们带来警醒。本文作者复盘了自己一年左右的项目经历，从三个方面回顾了她是如何将一款SaaS产品做死的。

最近做的一个项目经过一年左右的迭代终于还是走到了项目生命的尽头，做完最后两个迭代后进入维护期不再做功能开发和推广。

成功的经验总被人谈起，失败的过程却很少有人再提。成功很多时候不可再复制，而失败却总是有相同的原因，把失败项目的复盘记录下来希望能在新的项目中少走弯路。

本文会从产品定位、需求把控、技术框架三个方面来复盘我是怎么把一款SaaS产品做死的。

一、背景 1. 公司业务

公司有一个主营业务比较稳定，一个快销品线上活动代运营业务，最后是我负责的创新业务产品，主要为公司寻找一些新的增长机会。

在进入公司负责该产品之前，公司已经已经在新业务探索了一年左右的时间，做过3、4个小程序但一直没有能够赢利的产品，这次上马小程序SaaS产品对赢利期望较大。

2. 项目目标

在之前已经有一个购买的三方商城系统（10年前的产品），通过给品牌做商城系统及代运营服务拿到过订单。项目立项时的目的是通过将商城进行SaaS化改造，快速部署商城及代运营的能力。

此时BD号称手中已经有2笔商城系统订单，每笔总价在50W左右。

另一方面，CTO和产品总监看到市面上有可自由组合的小程序产品宣称能够覆盖大部分线下零售业务场景，期望在产品设计时也能够参考，方便产品后期进行业态拓展。

二、项目发展回顾

回顾项目发展大致可分为三个阶段：小程序化改造、框架完善、产品探索（框架完善同步进行）

1. 小程序化改造

确定好短期目标，是完成销售手中的订单后开始全力进行商城SaaS化改造的工作，所有产研同学都被拉入到项目室进行闭门开发。

通过一个多月的时间，终于完成了原有商城系统的多端改造，使用原有商城系统业务逻辑砍掉多余功能。因为原有商城系统前后端不分离，对整个商城C端页面进行了重写后台重新梳理出对应接口。

本着MVP原则，第一个版本所有小程序配置项都需要开发在代码中配置。为支持多应用体系框架上增加了租户层，用来作为账号、权限、应用管理的平台。

后来应为这个租户端多应用体系还出过不少技术问题，暂且先不详细展开。

当项目组所有成员欢欣鼓舞的完成第一个版本上线后，销售那边却迟迟签不下来合同，经过1个月左右的销售跟进最终这两个项目还是给丢了。

其实后面被销售牵着鼻子走的事情还在一直发生，只是当时整个决策都是想着如何能够拿到钱向老板证明项目的赢利能力，没有体系化的去决定做什么。

2. 框架完善

品牌自有商城项目未能接到订单，销售人员在品牌拿不到商城订单的情况下产品只能另谋出路。主要思路转为中小商家，希望借力各个平台推广自己平台小程序的机会，推出更多端的小程序商城产品。

为此，在近3个月的迭代中有一半需求围绕小程序版本和多端拓展的工作进行。

由于原有后台管理页面前后端不分离框架太老，新功能上线后都在新的系统框架中进行开发，新老框架来回跳转带来很多系统兼容问题，不得不再花一半的精力进行原有功能重构。

3. 产品探索

市场层面，既然卖不动那是否可以尝试自己运营？

于是商务部门找来了几个进口品牌渠道商，开通对应的品牌商城小程序，尝试运营自己的私域流量卖货。由于品牌知名度不够，且商务对品牌运营经验不够，尝试社群推介和直播推荐都没有取得比较好的效果。

倒是运营人员一直在给商城提出营销需求，商城功能迁移的同时不断增加营销玩法（营销玩法多了后交易流程复杂性上升）。

自运营没起来，老板开始动用自己的关系拉客户，找了商超、烘焙和洗车行业的店作为种子用户；另一方面唯一的地推人员开始进行推广，由于没有行业限制，只要有小程序需求的商家都被销售找了过来（美业、餐饮、母婴）。

繁多的线下交易模式和原有线上商城的区别还是相对较大，在原有商城的基础上进行对应的改造复杂度进一步提升。

但可惜的是，对应种子用户在使用产品后由于缺乏流量运营手段，使用效果不佳对产品反馈不好，于是不断的切换行业希望找到一个竞争较小的行业作为切入点，但这个点一直没找到。

三、问题总结及反思 1. 战略层面：不清楚产品核心业务模式和优势

在这个项目中，产品的目标客户和市场一直在变。

造成这个局面的很大一部分原因是觉得哪里能看到钱就去做什么，从最开始的品牌商商城到自营商城再到线下各行业零售业态的尝试都是这个模式。