复盘复盘:我是怎么把一个SaaS产品做死掉的( 二 )


倒是运营人员一直在给商城提出营销需求 , 商城功能迁移的同时不断增加营销玩法(营销玩法多了后交易流程复杂性上升) 。
自运营没起来 , 老板开始动用自己的关系拉客户 , 找了商超、烘焙和洗车行业的店作为种子用户;另一方面唯一的地推人员开始进行推广 , 由于没有行业限制 , 只要有小程序需求的商家都被销售找了过来(美业、餐饮、母婴) 。
繁多的线下交易模式和原有线上商城的区别还是相对较大 , 在原有商城的基础上进行对应的改造复杂度进一步提升 。
但可惜的是 , 对应种子用户在使用产品后由于缺乏流量运营手段 , 使用效果不佳对产品反馈不好 , 于是不断的切换行业希望找到一个竞争较小的行业作为切入点 , 但这个点一直没找到 。
三、问题总结及反思
1. 战略层面:不清楚产品核心业务模式和优势在这个项目中 , 产品的目标客户和市场一直在变 。
造成这个局面的很大一部分原因是觉得哪里能看到钱就去做什么 , 从最开始的品牌商商城到自营商城再到线下各行业零售业态的尝试都是这个模式 。
更多的需求来源于销售驱动 , 销售说这个做了就能卖钱 , 于是功能就往上加 。 每一项功能都有但每项功能都不能同竞品形成优势 。 同时没有规划的增加功能到最终会使系统复杂程度几何倍的增加 。
总结下来这个项目是没有核心产品战略的 , 碰到什么做什么 。
SaaS产品功能做出来一定能卖出去吗?即使卖出去那一定能赚钱吗?
如果是卖功能就要找准产品的差异点 , 如果没有差异点那就要拼渠道资源和销售能力;如果不是靠付费作为主要收入来源 , 那就要想好其他商业模式赢利的关键点(例如:POS产商靠抽佣赚钱 , CRM产商靠短信和广告投放赚钱) 。
就这个项目来说产品战略可使用常用的SWOT分析方法 , 公司的优势是有较多的品牌商资源如果从品牌方营销的角度出发打造营销平台项目还是有可能存活下来的 。
公司弱势是技术能力 , 尤其在开发商城的过程中表现比较明显 。 营销活动相对较简单和独立 , 开发起来相对容易 。 在和支付宝小二沟通时其实也看到品牌对小B和C端用户数据的一些诉求 , 结合这点去做营销能力应该也能获得平台更大的支持 。
现在回头去看 , 阿里已经整合了零售通门店POS能力 , 使用小程序在中小零售店内进行品牌券的派发 , 逐步打通了品牌和中小零售商的信息壁垒 。
这个模式 , 有空再单独拿出来讲背后的逻辑 。
2. 需求把控:因为方向不明确带来的需求优先级看客户催的急不急因为没有明确的产品方向和产品方向的来回切换在确立需求优先级的时候 , 往往靠当时想要推的那个行业的种子客户提了什么需求 , 有需求就往上加 。
例如:公司自运营商城的时候提出需要一个分销功能 , 运营追着产品说上线前只要上线就能大卖 , 实际上线无人问津的情况 。
究其原因 , 还是在确认需求前没有对自身资源进行有效评估 , 做分销最重要的是要有分销渠道资源和激励机制 , 并不是简单的老板有人脉往群里扔一个分销链接就能解决的问题 。
应为对商城来说 , 客户关心的是销量所以更多的时候都是营销需求 , 系统一些基础功能如配送、商品管理功能从旧有系统迁移反而优先级被调低 。
导致的后果是种子用户在使用时来回在多个系统切换效率和体验都非常差 , 还经常会出一些bug 。 但我们回头去迁移这些基础功能的时候 , 又花了大量精力去兼容在原有基础功能上开发的营销功能 。
3. 技术框架:切忌贪大求全 , 适合的才是好的
在项目初期 , 正是中台概念大火之时 。
基于保证后续多行业的可拓展性和对中台概念的着迷 , 整个系统采用了微服务的框架 。 经过大半年的迭代微服务数量达到了20多个 , 实践中遇到两个一直无法很好解决的问题 。


推荐阅读