早期阶段的SaaS产品，容易出现迭代速度快、产品变化大、稳定性差等问题，这些问题往往是抓不准需求导致的现象。那么，早期SaaS产品如何抓准客户需求，避免产品过早陷入复杂呢？本文作者对此进行了分析，一起来看一下吧。

最近想要把过去几年创业中积累的产品板块东西整理整理，虽然公司做得一塌糊涂一点也不成功，但在过程里还是收获了客户和创圈子里其他创始人对我们产研效率和做产品方法的不少肯定，内部讨论把这方面的小小成绩归因为 “需求抓得准，不浪费研发的每一分钟和每一行代码”，于是就有了这篇文章，试图总结一下，并分享给大家希望对产品经理和早期创业者有帮助。

后续我也计划连载一个专注在SaaS产品部分的文章系列。

希望读完这篇文章的你，可以收获一套行之有效可以落地在你产品中的方法，并使你在未来的产品迭代中能够用最少的资源精准输出解决问题的好产品。

我把这篇文章的内容只约束在早期SaaS产品阶段，因为不同阶段对产品的要求是不同的，早期SaaS产品的重点是找到产品PMF，以及找到PMF后的go to market 探索阶段产品发挥的作用，在往后就不算是早期了，企业也对产品和产品团队会提出全新的要求。

一、早期SaaS产品陷入复杂的危害

早期阶段的SaaS产品常见的几个问题：

1. 迭代速度快
2. 产品变化较大
3. 稳定性较差bug多
4. 功能快速堆砌，说不上对也不一定错拉低研发效能
5. ……

以上种种现象都是在早期SaaS产品阶段面临的常见问题，在和更多人沟通的过程里甚至不少人默认了这个阶段就是这样，这些问题是合理的。

其实上面类似问题并不合理，这些问题普遍存在，他们只是现象，是抓不准需求导致的现象，为什么这么说呢？比如，产品变化大是缺乏产品价值的定义，不断地更换客户群和价值点，导致产品无法定性。

BUG多更不是本质，是大概率因为一上来面铺得太散，有一堆功能，但每个功能都不成熟，到处救火，没有把时间花到核心业务的打磨上。更会出现因为好不容易拿到一个客户，但客户在你提供的价值A之外还要求B，我们因为害怕客户离开承诺B也要做接受了超出当前阶段的产品计划……

早期项目资源有限，资金紧张，如何能够让产品的每一个需求都精准无误，每一个上线都能被客户马上用起来，这样才能帮助企业争取更多的时间和试错机会，不然可能一次较大不准确的投入就耗尽了资金。

（这里我是说不准确的投入而不是说错误的投入，因为在早期产品的当下阶段里，不存在绝对的错误，只存在与当下阶段不匹配。）

那我们如何解决这个问题呢？

只需三个字概括 “快”“准”“稳”。

• 快：产品验证和试错快，在用户研究环节要高频和用户沟通，拿着产品原型和设计稿反复的去找客户沟通，在过程中判断抽丝剥茧找到产品核心。
• 准：需求精准度高，在高频的客户沟通中我们会发现大量的需求以及客户提出的问题，这时候就要求我们能够识别出在哪个是核心价值，哪个不是，从而缩小需求范围提高精准度。
• 稳：研发交付要稳，在保证客户价值正确、需求精准的情况下，研发交付要足够稳，交付一个无BUG的产品可以被客户拿来即用。（需求不够准工程维度就会变复杂，早期团队人数有限测试大概率不够充分会让产品稳定性下降）

我们在这个三个字基础上继续往下拆。

首先要搞清楚需求的本质是什么。

二、SaaS产品需求的本质/清晰定义需求边界

要了解SaaS产品的如何挖掘需求，就要先理解使用SaaS的企业客户是如何决定购买一个SaaS产品的。

如图所示，企业购买SaaS的起点是相关决策人明确洞察到当前业务中存在某一个明确的问题。从而产生了后续连串的解决方案探索过程。

那么产品需求也是无法脱离这个买方视角的，如果无法清晰的把产品定义在一个企业遇到的具体问题上，那么这个产品就无法满足企业的需求。

因此可见，SaaS产品的需求本质是客户自身要解决的业务问题，在企业解决这个问题的过程中，产生的解决解决方案就是SaaS产品的需求点。

为什么说企业自身的业务问题不是需求点，而解决这个业务问题的过程才是需求点呢？

因为企业需求的复杂性和C端产品不同，C端产品只要单点痛点出现就会出现需求，而企业需求是不存在单点痛点的，企业要解决一个业务问题是需要由多个达成目标的过程中涉及的业务环节决定的，达到一个业务目标所涉及的全环节构成了一个具体的SaaS产品的需求，SaaS产品就要解决这个过程里全环节面临的困难。

举个例子，一家面向个人的工具型SaaS产品希望为用户提供更好的使用体验从而提高新用户对产品核心功能的激活率，以此目标为中心，在过程里存在以下业务闭环：

• 产品团队调研提高激活率方式方法
• 产品与设计团队完成onboarding方案落地
• 研发团队开发相关功能逻辑
• 上线观测用户转化情况数据趋势
• 迭代onboarding

在这个案例中，企业希望通过onboarding完成提高核心功能激活率目标，并通过以上业务环节达到目标，但在每个环节中，企业会遇到不同程度的困难，这些困难这就构成了一个适合SaaS产品的需求。

困难：

• 产品团队调研提高激活率方式方法 => 信息不够不知道什么方法是最有效的
• 产品与设计团队完成onboarding方案落地 => 从业者认知参差不齐不一定能做好方案
• 研发团队开发相关功能逻辑 => 研发团队专注在核心业务中无法投入资源在该模块
• 上线观测用户转化情况数据趋势 => 从业者认知参差不齐无法最大化数据价值 or 研发没有资源做数据系统

此时如果我们想做一款SaaS来解决这个问题帮助企业无代码生成onboarding该怎么做呢？是不是就非常清晰了，我们来模拟一下：

• 首先定义出onboarding的旅程包含什么内容：功能的操作引导+任务清单；
• 设计出可以无代码在系统内放置操作引导的产品方案；
• 然后设计出可以把多个引导连在一起形成一个任务清单的功能；
• 最后提供出能帮助企业迭代的数据系统，让企业知道每一个引导是否有效，以及每一步的转化率与流失率，帮助企业迭代onboarding的有效性。

好了，除了以上这几个功能之外，客户提出的所有需要都不应该去满足，至少现在不应该。

通过这样的对比，我们可以i清晰的认识到，SaaS产品需求的挖掘是客户要达到某个业务目标所需要的方法，在这个方法中什么产品可以满足，从而起到降本增效或增收开源的价值。

到这里我们就解决了最重要的一环，当我们能够清晰定义需求的边界后还面临另一个问题，也是导致一款SaaS产品变得越来越复杂的另一个原因。

三、产品过早提供多元化价值

什么是产品价值？产品价值和产品需求有什么区别？

开始这一模块之前，我们需要先搞清楚产品价值和产品需求的关系。

产品需求上面已经讲清楚了，是企业达到业务目标过程中所涉及的所有业务闭环中困难的集合，那什么是价值呢？

产品价值其实更偏营销领域，可以把产品价值等价于产品的价值包装。这个价值的包装不只是面向于市场，它同样面向于产品内的表达方式。

我们可以从产品价值包装的角度重新审视一下自己的产品，看看你的产品中的各个功能板块，如何把其价值传递给客户，一款SaaS产品要交付给客户的价值大概率是非常多维度的，不然产品就会相对较薄，谁不想让产品的价值变得更大也就是更厚呢，这当然没问题，但别忘了我们现在是处于早期产品阶段。

对于早期SaaS来说最重要的莫过于找到PMF，找PMF环节里最核心的一点就是对价值的抽象，要在同一类客户中，找到同一个可被用户接受的产品价值点，不能把同一个价值卖给不同的客户群，也不能在同一个客户群中卖不同的产品价值，这都是不利于PMF和早期产品的。

如果PMF还没到就被迫开始多元产品就会越来越大，越来越重，虽然可能因此拿下了订单，但最终产品的节奏会失控，永远在重复从0到1，无法真正开启规模化增长。

那么该如何抽象业务价值呢？

理论上一个产品需求点就应该对应一个业务价值，但有可能也会是两三个需求点共同服务于一个业务价值。

没有有人会一上来就关心产品功能（个人用户除外），卖过SaaS的同学可能会有一个感触，当我们去面对面销售一个SaaS产品给企业决策者的时候，更多是先认同你的产品价值，然后再让对应员工去验证产品功能是否与描述的产品价值存在gap。

从这个角度看，产品功能/需求，是产品价值定义清晰后才有的产物，产品经理就需要跟随着价值验证来做产品，早期SaaS产品经理很重要工作之一就是要离客户近一点，甚至要去做销售，去感受客户因什么价值而买单，这样才能更准的掌握好排期节奏，PMF阶段产品排期都应该围绕完善一个产品价值而存在，确定要做一个产品功能的时候，需要确定该功能所归属的价值点是哪个。

还是以上面那个企业想要提高新用户进入产品后核心功能激活这个案例举例。

上面我们提到要做一个无代码在产品中放置引导的功能+任务清单功能，此时客户说，你们把引导的形式换成一个小问号的tips我们就可以给产品内快速放置一个tips描述了，底层逻辑都一样，都是选择一个元素然后放上去一个内容。

Ok ，这个时候以功能为视角的“功能经理”就会答应，然后开搞。然后产品复杂度提高，产品交付的价值出现了第二个维度，进一步变得复杂。

我们可以把功能引导+任务清单 抽象为价值A：帮助企业无代码构建用户onboarding（用户入职），而无代码放置一个tips不属于这个价值，我们可以把它抽象为价值B：在产品内结合上下文打消产品使用阻碍。

很明显，这是两件事，但其实又不完全割裂，因为从客户的角度，购买这个SaaS产品就是为了解决新用户激活的问题，价值A和价值B 都是可以有效解决这个问题的。虽然是这样，但客户不是因为缺少价值B就拒绝为价值A付费。

所以这就是过早的让产品价值多元化。

你可能会问，多元化不也挺好，买的钱更多了，客户粘度更大了，all in one了，其实不然，在完成PMF前，过多的维度会阻碍PMF的验证，就好像我们手里抓着一把牌，一张一张出，直到客户说这个我要。这也是无法找到产品和某个具体市场之间的匹配关系的，也就无法开展后续的GTM。

最后

产品视角和其他业务角色视角有很大区别，产品视角更关注纵横全局的一个时间轴，上面有一个又一个里程碑，如果这个轴都是有问题的，里程碑就毫无意义。所以对于早期SaaS产品，要抓准一类客户中的具体需求，形成一个可承载交易的最小化完整产品。

就是这个轴，早期公司资源有限，大概率有且仅有这一个轴，而且无法接受多次试错，一次对，第二次可能就是最后一次，这就是为什么不能让早期产品陷入复杂的原因，它会在同样正确只是时间不对的事情上，把团队资源拖垮。