从产品定位、需求把控、技术框架复盘，一款SaaS产品怎么死掉的

经过一年左右的迭代，最近做的一个项目终于走到了项目生命的尽头。最后两次迭代完成后，进入维护期，不再进行功能开发和推广。人们总是谈论成功的经历，但很少有人提及失败的过程。成功往往无法复制，但失败的原因总是一样的。记录失败项目的复盘，希望在新项目中少走弯路。本文将从产品定位、需求控制和技术框架三个方面回顾我是如何杀死SaaS产品的。1、背景1。公司业务公司拥有稳定的主营业务和快速销售产品在线活动。最后，我负责创新业务产品，主要为公司寻找一些新的增长机会。在进入公司负责产品之前，公司已经探索了大约一年的新业务，做了3次、四个小程序但一直没有盈利的产品，这次推出的小程序SaaS产品对盈利的期望更大。2.项目目标之前已经购买了三方商城系统(10年前的产品)，通过为品牌制作商城系统和代理运营服务获得订单。项目立项的目的是通过SaaS改造商城，快速部署商城和代理运营的能力。此时BD声称手中已经有两个商城系统订单，每个总价在50W左右。另一方面，CTO和产品总监看到市场上可以自由组合的小程序产品声称可以覆盖大部分线下零售业务场景，希望在产品设计中也能参考，方便产品后期的业务拓展。2、项目开发回顾项目开发大致可分为三个阶段：小程序改造、框架改进、产品探索（框架改进同步进行）1。小程序改造确定了短期目标，即在完成销售订单后，开始全力开展商场SaaS改造，所有研究生都被拉进项目室进行闭门开发。经过一个多月的时间，原商城系统的多端改造终于完成，原商城系统的业务逻辑被用来切断多余的功能。由于原商城系统前后端不分离，整个商城C端页面被重写，后台被重新整理出相应的接口。本着MVP原则，所有小程序配置项的第一个版本都需要在代码中开发。在多应用系统框架上增加租户层作为账户、权限和应用管理的平台。后来租户端多应用系统出现了很多技术问题，暂时不详细。当项目组所有成员高兴地完成第一个版本上线时，销售方无法签订合同。经过大约一个月的销售跟进，这两个项目仍然丢失了。事实上，被销售人员牵着鼻子走的事情还在发生，但当时整个决定都在思考如何拿到钱向老板证明项目的盈利能力，没有系统地决定做什么。2.框架完善，品牌自有商城项目未收到订单，销售人员只能在品牌拿不到商城订单的情况下另谋出路。主要思路转向中小企业，希望借此机会推广自己的平台小程序，推出更多端的小程序商城产品。因此，在过去三个月的迭代中，有一半需要围绕小程序版本和多端扩展进行。由于原后台管理页面前后端不分离框架太老，新功能在新系统框架中开发，新旧框架来回跳转带来了许多系统兼容性问题，不得不花一半的精力重建原功能。3.产品探索市场层面。既然卖不出去，能不能试着自己操作？因此，商务部门找到了几家进口品牌渠道提供商，开通了相应的品牌商城小程序，试图运营自己的私域流量销售商品。由于品牌知名度不足，商业经验不足，尝试社区推广和直播推荐没有取得更好的效果。然而，运营商一直在向商场提出营销需求，商场功能迁移不断增加营销玩法（营销玩法增加后，交易流程的复杂性增加）。自从运营失败以来，老板开始利用自己的关系吸引顾客，在超市、烘焙和洗车行业找到商店作为种子用户；另一方面，唯一的推广人员开始推广。由于没有行业限制，只要有小项目需求的企业被销售人员（美容行业、餐饮、母婴）发现。各种线下交易模式与原有线上商城的区别还是比较大的，在原有商城的基础上进一步提高了相应的转型复杂性。不幸的是，相应的种子用户在使用产品后缺乏流量操作手段，使用效果差，产品反馈差，所以不断切换行业希望找到一个竞争较小的行业作为切入点，但这一点尚未找到。1.战略层面：不清楚该项目的核心业务模式和优势，产品的目标客户和市场一直在发生变化。造成这种情况的很大一部分原因是，从最初的品牌商城到自营商城，再到线下行业零售业态的尝试，都是这种模式。更多的需求来自销售驱动，销售说这样做可以卖钱，所以功能增加。每个功能都有，但每个功能都不能与竞争产品形成优势。同时，没有计划的增加功能最终会几何倍地增加系统的复杂性。综上所述，这个项目没有核心产品策略，遇到什么就做什么。SaaS产品的功能一定能卖吗？即使卖了，也能赚钱吗？如果是销售功能，就要找出产品的差异。如果没有差异，就要争取渠道资源和销售能力；如果不以支付为主要收入来源，就要考虑其他商业模式盈利的关键点(比如POS厂商靠佣金赚钱，CRM厂商靠短信和广告赚钱)。就本项目而言，常用的SWOT分析方法可用于产品策略。公司的优势在于，如果从品牌营销的角度构建营销平台项目，品牌资源更多，仍有可能生存。公司的弱点是技术能力，尤其是在开发商城的过程中。营销活动相对简单独立，相对容易开发。事实上，在与支付宝小二沟通时，我们也可以看到品牌对小B和C端用户数据的一些需求。结合这一点，营销能力也应该得到平台的更大支持。现在回顾过去，阿里整合了零售店的POS能力，利用小程序在中小型零售店分发品牌优惠券，逐步打开了品牌和中小型零售商的信息障碍。在这种模式下，当你有空的时候，你可以单独拿出来谈谈背后的逻辑。2.需求控制：由于方向不明确，需求优先取决于客户是否匆忙，因为没有明确的产品方向和产品方向来回切换。在建立需求优先级时，往往依赖于当时想要推动的行业种子客户的需求，需求增加。比如公司在经营商城的时候，提出需要一个分销功能，运营追产品，说只要上线就可以大卖，其实上线的时候没人在乎。原因是在确认需求之前没有有效地评估自己的资源。分销最重要的是要有分销渠道资源和激励机制。这不是一个简单的问题，老板可以通过将分销链接扔进小组来解决。对于商场来说，客户关心的是销量，所以更多的时候是营销需求。系统的一些基本功能，如配送和商品管理功能，优先考虑从旧系统迁移。结果是种子用户在多个系统中来回切换效率和体验都很差，经常会出现一些bug。然而，当我们回去迁移这些基本功能时，我们花费了大量精力与原有基本功能开发的营销功能相兼容。3.技术框架:不要贪大求全，适合的是项目初期的好，是中台概念大火的时候。整个系统采用微服务框架，基于保证后续多行业的可扩展性和对中台概念的着迷。经过半年多的迭代微服务，达到了20多个，在实践中遇到了两个无法很好地解决的问题。服务数量造成的混乱和资源紧张：一个功能通常涉及多个服务。当开发人员较多时，服务间信息往往不一致，后期开发资源面临开发人员维护多个服务，或多或少降低开发效率；服务抽象不清晰，设计不合理，需求需要改变服务。事实上，造成这一问题的部分原因也应归因于产品核心业务逻辑不明确。虽然新技术有其优势，但技术始终服务于业务。对于新产品来说，最重要的是运行业务，形成一个积极的循环，而不是寻求最新的技术。下图是当时的架构蓝图，规划仍然很好：4。总结一个新产品的核心是考虑自己的商业模式；在明确的商业模式和战略方向的情况下，拆除阶段性产品目标，指导需求优先规划；确定技术框架选择，不是大而完整的设计，不使用新技术。