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

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