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

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

本文插图

最近做的一个项目经过一年左右的迭代终于还是走到了项目生命的尽头，做完最后两个迭代后进入维护期不再做功能开发和推广。
成功的经验总被人谈起，失败的过程却很少有人再提。成功很多时候不可再复制，而失败却总是有相同的原因，把失败项目的复盘记录下来希望能在新的项目中少走弯路。
本文会从产品定位、需求把控、技术框架三个方面来复盘我是怎么把一款SaaS产品做死的。
一、背景
1. 公司业务公司有一个主营业务比较稳定，一个快销品线上活动代运营业务，最后是我负责的创新业务产品，主要为公司寻找一些新的增长机会。
在进入公司负责该产品之前，公司已经已经在新业务探索了一年左右的时间，做过3、4个小程序但一直没有能够赢利的产品，这次上马小程序SaaS产品对赢利期望较大。
2. 项目目标
在之前已经有一个购买的三方商城系统（10年前的产品），通过给品牌做商城系统及代运营服务拿到过订单。项目立项时的目的是通过将商城进行SaaS化改造，快速部署商城及代运营的能力。
此时BD号称手中已经有2笔商城系统订单，每笔总价在50W左右。
另一方面， CTO和产品总监看到市面上有可自由组合的小程序产品宣称能够覆盖大部分线下零售业务场景，期望在产品设计时也能够参考，方便产品后期进行业态拓展。
二、项目发展回顾
回顾项目发展大致可分为三个阶段：小程序化改造、框架完善、产品探索（框架完善同步进行）
1. 小程序化改造确定好短期目标，是完成销售手中的订单后开始全力进行商城SaaS化改造的工作，所有产研同学都被拉入到项目室进行闭门开发。
通过一个多月的时间，终于完成了原有商城系统的多端改造，使用原有商城系统业务逻辑砍掉多余功能。因为原有商城系统前后端不分离，对整个商城C端页面进行了重写后台重新梳理出对应接口。
本着MVP原则，第一个版本所有小程序配置项都需要开发在代码中配置。为支持多应用体系框架上增加了租户层，用来作为账号、权限、应用管理的平台。

后来应为这个租户端多应用体系还出过不少技术问题，暂且先不详细展开。
当项目组所有成员欢欣鼓舞的完成第一个版本上线后，销售那边却迟迟签不下来合同，经过1个月左右的销售跟进最终这两个项目还是给丢了。
其实后面被销售牵着鼻子走的事情还在一直发生，只是当时整个决策都是想着如何能够拿到钱向老板证明项目的赢利能力，没有体系化的去决定做什么。
2. 框架完善品牌自有商城项目未能接到订单，销售人员在品牌拿不到商城订单的情况下产品只能另谋出路。主要思路转为中小商家，希望借力各个平台推广自己平台小程序的机会，推出更多端的小程序商城产品。
为此，在近3个月的迭代中有一半需求围绕小程序版本和多端拓展的工作进行。
由于原有后台管理页面前后端不分离框架太老，新功能上线后都在新的系统框架中进行开发，新老框架来回跳转带来很多系统兼容问题，不得不再花一半的精力进行原有功能重构。
3. 产品探索市场层面，既然卖不动那是否可以尝试自己运营？

于是商务部门找来了几个进口品牌渠道商，开通对应的品牌商城小程序，尝试运营自己的私域流量卖货。由于品牌知名度不够，且商务对品牌运营经验不够，尝试社群推介和直播推荐都没有取得比较好的效果。
倒是运营人员一直在给商城提出营销需求，商城功能迁移的同时不断增加营销玩法（营销玩法多了后交易流程复杂性上升）。
自运营没起来，老板开始动用自己的关系拉客户，找了商超、烘焙和洗车行业的店作为种子用户；另一方面唯一的地推人员开始进行推广，由于没有行业限制，只要有小程序需求的商家都被销售找了过来（美业、餐饮、母婴）。
繁多的线下交易模式和原有线上商城的区别还是相对较大，在原有商城的基础上进行对应的改造复杂度进一步提升。
但可惜的是，对应种子用户在使用产品后由于缺乏流量运营手段，使用效果不佳对产品反馈不好，于是不断的切换行业希望找到一个竞争较小的行业作为切入点，但这个点一直没找到。
三、问题总结及反思
1. 战略层面：不清楚产品核心业务模式和优势在这个项目中，产品的目标客户和市场一直在变。

造成这个局面的很大一部分原因是觉得哪里能看到钱就去做什么，从最开始的品牌商商城到自营商城再到线下各行业零售业态的尝试都是这个模式。
更多的需求来源于销售驱动，销售说这个做了就能卖钱，于是功能就往上加。每一项功能都有但每项功能都不能同竞品形成优势。同时没有规划的增加功能到最终会使系统复杂程度几何倍的增加。
总结下来这个项目是没有核心产品战略的，碰到什么做什么。
SaaS产品功能做出来一定能卖出去吗？即使卖出去那一定能赚钱吗？
如果是卖功能就要找准产品的差异点，如果没有差异点那就要拼渠道资源和销售能力；如果不是靠付费作为主要收入来源，那就要想好其他商业模式赢利的关键点（例如：POS产商靠抽佣赚钱， CRM产商靠短信和广告投放赚钱）。
就这个项目来说产品战略可使用常用的SWOT分析方法，公司的优势是有较多的品牌商资源如果从品牌方营销的角度出发打造营销平台项目还是有可能存活下来的。
公司弱势是技术能力，尤其在开发商城的过程中表现比较明显。营销活动相对较简单和独立，开发起来相对容易。在和支付宝小二沟通时其实也看到品牌对小B和C端用户数据的一些诉求，结合这点去做营销能力应该也能获得平台更大的支持。

现在回头去看，阿里已经整合了零售通门店POS能力，使用小程序在中小零售店内进行品牌券的派发，逐步打通了品牌和中小零售商的信息壁垒。
这个模式，有空再单独拿出来讲背后的逻辑。
2. 需求把控：因为方向不明确带来的需求优先级看客户催的急不急因为没有明确的产品方向和产品方向的来回切换在确立需求优先级的时候，往往靠当时想要推的那个行业的种子客户提了什么需求，有需求就往上加。
例如：公司自运营商城的时候提出需要一个分销功能，运营追着产品说上线前只要上线就能大卖，实际上线无人问津的情况。
究其原因，还是在确认需求前没有对自身资源进行有效评估，做分销最重要的是要有分销渠道资源和激励机制，并不是简单的老板有人脉往群里扔一个分销链接就能解决的问题。
应为对商城来说，客户关心的是销量所以更多的时候都是营销需求，系统一些基础功能如配送、商品管理功能从旧有系统迁移反而优先级被调低。
导致的后果是种子用户在使用时来回在多个系统切换效率和体验都非常差，还经常会出一些bug 。但我们回头去迁移这些基础功能的时候，又花了大量精力去兼容在原有基础功能上开发的营销功能。
3. 技术框架：切忌贪大求全，适合的才是好的
在项目初期，正是中台概念大火之时。
基于保证后续多行业的可拓展性和对中台概念的着迷，整个系统采用了微服务的框架。经过大半年的迭代微服务数量达到了20多个，实践中遇到两个一直无法很好解决的问题。

服务数量导致的混乱和资源紧张：一个功能往往会涉及到多个服务，刚开始开发人员多的时候经常出现服务间信息不一致，后期开发资源减少又面临一个开发人员维护多个服务，人多人少都或多或少的降低开发效率；
服务抽象不清晰，设计不合理，一个需求都需要大改服务。其实这个问题，有一部分原因也应该归结于产品核心业务逻辑不明确。

新的技术固然有它的好处，但技术始终是服务于业务。对于新产品来说最重要的是要把业务跑起来能够形成正向的循环而不是为了最求最新的技术。
下图是当时做的架构蓝图，规划还是很美好的：