编辑导读：做好一个产品需要多方协作，产品经理需要站在更宏观的角度，全面考虑问题，才能从各个方面做出决策。本文打算将 B2B SaaS 产品在决策过程应该考虑的维度拆解成5个要素，从不同的角度来了解它们，确保在产品设计的每个步骤中都把这些要素列入考虑范围内，以帮助我们作出更有效的决策。

产品经理是一个强调“综合性”的岗位，在产品经理的工作中避不开用户、商业、功能、迭代等关键词。产品经理需要对“产品增长”负责，为了赢得市场份额、应对那些“捷足先登”的竞品，产品经理不仅要对产品功能、用户体验负责，也该对销售模式、售价，甚至客户成功负责（现今，增长产品经理的崛起或许证明了上述趋势正在进行中）。本文并不打算扩大产品经理的职权范围，而是想探讨一下产品经理该如何认识除产品以外的要素，并应用到日常决策中。

实际上，做一款好的产品需要耗费许多时间和费用，产品经理经常要在各个方面做出决策和妥协，但这些决策或妥协不应该是随机决定的，产品经理需要从宏观上加深对产品的理解，更加全面的考虑整个问题，才能确保你控制了决策所造成的全部结果。

一款产品的诞生需要经历多个步骤，从idea的产生到立项、研发，再到推出市场，凝聚多个部门的思考与决策，决策与决策之间彼此依赖，影响到产品定位、用户体验、营销策略、销售模式等方方面面。产品经理或许无法经历所有的决策过程，但是，我们可以从不同维度对决策过程进行拆解，以帮助我们理解这些决策是如何做出来的。

本文打算将 B2B SaaS 产品在决策过程应该考虑的维度拆解成5个要素，从不同的角度来了解它们，确保在产品设计的每个步骤中都把这些要素列入考虑范围内，以帮助我们作出更有效的决策。

五个要素：

1. 客户需求 VS 用户需求
2. 内部生态 VS 外部生态
3. 成本 & 价格
4. 销售模式
5. 客户成功

一、“客户”需求 VS “用户”需求

To C 产品的购买者和使用者往往是同一人，但 To B 产品经常面对“两拨”不同的人：“客户”和“用户”，通常由该项业务的负责人或公司老板决策购买，最终用户则是他的下属。这意味着产品不仅要让老板买单肯定价值，也要让下属真正使用起来，如果老板发现下面的人根本用不起来，公司以后绝不会再续费。

决策者和使用者对产品的关注点是不同的，有时候甚至存在利益冲突。

「决策者」关注的首先是产品价值，然后才是功能范围。首先确定产品定位是否与企业的愿景和目标相匹配；接着决策者会考察产品的解决方案是如何实现目标的，并通过产品的过往客户成功案例考察这些解决方案的实际效果；最后才关心产品功能清单，以确保产品确实能实现这些解决方案。决策过程层层递进，每一个层面都是根据它的上面的层面来决定。

相反，「使用者」其实并不关心产品，通常他们只是被上级要求使用系统。使用者关注的是「任务」，能否通过产品顺利且顺畅的完成任务才是使用者关心的。如果在执行任务的过程中出现产品功能缺失，造成任务无法顺利完成，对用户的使用体验是致命的。

事实上，无论从决策者还是使用者的角度出发，其背后都是对「绩效」的需求。

对于管理层来说，所有绩效都是对企业战略目标的结果考量。对于基层员工而言，期望产品能帮助他们更好的达成绩效目标，更重要的是确保他们的工作结果可以被衡量。因此，基于绩效和功能两个需求维度做出的解决方案，才最能反映客户要用SaaS产品的真实意图。

To B 产品经理的困难在于大多数情况下自己不是核心用户，很难通过同理心去理解用户需求。很多时候，我们描述了太多的产品解决方案，其实还是对功能的解释，某个客户是怎么使用的。这种解决方案，其实还是对功能的解释。假如你也有类似的困扰，不妨从「绩效」和「任务」的角度切入，调整看问题的角度。

通常而言，企业使用 SaaS 产品期望解决两大类的绩效目标：

• 一是企业内部优化，比如流程优化、提升效率、企业内外监管、绩效可视化等，期望通过产品功能“替代”原有工作方式。比如，协同办公类产品取代了本地化的文档处理软件，提升协同效率，更重要的是对于管理层来说，可以有效沉淀所有工作信息和文档，实现员工工作内容的监管。
• 二是应对外部趋势，如新技术趋势、市场变化等出现的新机会，期望通过产品功能填补新任务的空缺。比如，SCRM的出现正是因为微博、微信等社交平台的火爆，缩短了品牌与消费者的距离，孕育出一种全新的营销模式。

“以「绩效」为中心，以「任务」为用户场景”，或许才是 To B 产品的核心思维。产品经理可以考虑尝试一下字节跳动所始终用的产品管理方法，用一页ppt对一个产品或一个功能模块的核心价值做抽象，一页ppt只包含一个标题，2-4个简短说明，一张示例图，列出产品或功能模块的卖点，比如可达成的绩效目标有哪些。这样有助于提升产品经理看问题的高度。

二、内部生态 VS 外部生态

To B SaaS 产品通常聚焦于解决某一个企业的业务问题，但实际上，目前国内企业的数字化转型才刚起步，企业的大部分业务都在等待数字化，企业 IT 矩阵的不完善，导致业务数字化割裂，不能完全发挥出 SaaS 的价值。企业所有业务都迫不及待的需要数字化，最终倒逼着 SaaS 产品变得「大而全」。

以市场营销软件举例，不少 SaaS 产品在初始阶段都是围绕着一个核心场景进行迭代，比如广告投放、内容管理、在线客服等，提供了一堆工具给到客户，客户也用不起来，最后只能“丧心病狂”地做起了一体化营销云。

有时候，为了赶超竞争对手，产品还没来得及夯实核心场景就被迫扩大自己的边界范围。肆意扩大产品边界存在风险，首先是产品变得越来越臃肿，在有限的时间和资源下功能迭代不及时，每个功能都不够强大，用户用不起来；其次还可能浪费了大量时间金钱去实现一些没有价值的需求或者伪需求。因此，如何准确地判断产品边界在哪里，减少研发浪费，是产品经理最难掌握的技能之一。

正如上文一直强调的，客户需要的是整合的解决方案而非单一产品，但这并不意味着解决方案所需要的产品、技术以及其他组成部分都必须由自己解决，我们可以学会理解和控制两个概念：「内部生态」、「外部生态」。顾名思义，「内部生态」是由自己构建能带来竞争优势的组成部分，「外部生态」即可以与他人合作构建的部分。

哪些组成部分必须由自己构建，哪些部分可以和他人合作构建，在构建生态之初，几乎无法找到答案，需要在大量相互关联的因素中达到平衡，这些因素包括：用户体验和需求、具有竞争力的差异化特性、研发成本和研发速度、自有的技术和能力等。在权衡这些因素的过程中，可以使用一些分析工具辅助我们思考。

1. 用户旅程图

许多产品经理在描绘产品边界时习惯以产品所在行业和类别（比如营销有SCRM类、CRM类、客服类等）的方式来思考，这样的思考方式会限制业务的可能性，导致我们以狭隘的视角来看到竞争对手，使我们易于被新进者和混乱的状况所影响。要知道，客户并不是透过你的产品线，而是透过自己的需求来看待这个世界的。

想要清晰勾勒用户需求的完整面貌、明确自己的产品所专注的领域、判断是否需要同其他产品相整合，你可以尝试使用「用户旅程图」工具。

「用户旅程图」是用于描绘用户到底是谁，他们要达成什么样的目标，如何达成目标，并将用户完成目标的过程可视化的一种工具，可以帮助我们聚焦问题全景，从而得出功能性和体验性的需求。用户旅程图是由时间线上的一系列用户行为构成的，但如何从纷乱的用户行为中梳理出一条清晰的脉络是一个令人头疼的问题。对于 To B 行业而言，可以按照「绩效–>任务–>行为」的步骤来建立用户旅程图，相比碎片化的行为，绩效可简单明了的多了。

以市场营销为例，「AIPL 模型」是市场部最常使用的绩效仪表盘 ，在绘制用户旅程图时可以使用AIPL作为绩效目标拆解任务和行为。必须注意的是「绩效」应该贯穿于整个用户旅程图的组织、分解过程中。To B 业务里「绩效」是产品价值的度量标准，产品经理应该永远聚焦于成果，以成果为导向来决定系统内需要什么功能。

重要的是，绘制用户旅程图能让我们更容易看清业务全貌，从客户需求的视角（而不是以产品行业和类别的方式）清晰定义产品所在的领域。

2. SWOT 分析

解决用户需求的方式并不只有唯一的正确答案，同样的，适合其他公司的解决方案也不一定适合自己，我们需要对问题所处的环境有一个360°全方位的认识，包括企业内部以及外部的因素。而 「SWOT 分析」正是用于厘清环境因素的工具。

SWOT 分析中，S代表strength（优势），W代表weakness（劣势），O代表opportunity（机会），T代表threat（威胁），S、W为内部因素，O、T为外部因素。业内有许多关于 SWOT 分析的详细介绍，在此就不再赘述了。简单来说，我们既要清楚知道团队自身的核心竞争力、技能、品牌效益、过往经验等，同时还需要分析外界的竞争对手、相似产品、补充产品、市场趋势、技术趋势等。总之，既要发挥自身优势，同时要避免和强大的竞争对手正面冲突，通过 SWOT 多维度的分析，为定义产品策略提供帮助。

为了加深理解 SWOT 分析的重要性，扯几句超出产品经理工作范畴的题外话：相比 To C 业务仅通过产品就能实现用户价值，To B 业务光做好产品还不行，还需要销售、服务、客户成功等多部门的协同配合，考验的是团队内部流程的执行力。因此，不光是产品的差异性，组织能力的差异也可能带来竞争优势。比如，针对银行或政府类客户，产品的私有化部署能力将成为企业竞争优势；再比如，零售行业每年需要举办各类营销活动，有些公司选择提供活动模板工具，帮助用户快速搭建线上活动；有些公司则选择为企业代运营活动，将产品作为内部运营工具，其差异化来自于公司在持续经营过程中获取的能力和过往经验。

3. MVP

通常，对内部生态边界的定义会随着对问题的深入了解而变化，也会随着用户需求和公司目标的变化而变化。产品经理常常抱怨产品战略变化太快、需求变化太快。事实上，唯一不变的就是变化，产品经理需要拥抱变化，在研发的过程中始终保持灵活性，而 “MVP（最小可行性方案）” 正是实现灵活性的一种方式。

对 MVP 的错误定义：“ MVP 是粗拙的产品”，MVP 并不是要发布用户只能在特定场景使用的产品，也不是只把产品发布给忍耐度非常高的用户。正是这样的错误观念造成一开头提到的问题：产品无限扩张，但每个功能用户都用不起来，慢慢陷入恶性循环。

事实上，每一次产品发布都可以看做对问题的肯定假设，这种假设可能部分甚至全部是错的，关于产品最可靠的反馈信息来自于产品进入市场之后的阶段，因此每次 MVP 都必须是一个完整的、最小可行性方案，其功能规划是可以产生预期成果的，我们通过发布 MVP 来验证假设并快速进行修正。

然而，To B 业务的 MVP 容易走入两个极端：“闭环过大”或“没有闭环”。“闭环过大”可能是一开始就把整个企业的业务闭环当成产品第一步就要实现的闭环，比如帮助企业一口气解决AIPL的完整闭环，闭环太大的 MVP 等同于形同虚设。

“闭环过大”也可能是过度追求满足业务上的完整闭环，没有对需求的价值度进行划分。比如举办一场营销活动需要经历计划、审批、活动设计与制作、渠道投放、活动举行、活动效果度量等等工作内容，如果一味地照搬业务场景，而不是找出最亟待解决的问题，可能导致研发精力分散。（下图中的KANO模型是对用户需求分类的工具）。

“没有闭环”则可能因为太过专注以「使用者」为单位的使用场景，而不是以「任务」为单位、以「绩效」为价值的使用场景。比如一款线上活动模板工具的使用场景，并不是以制作活动页面为任务，而是以举办一场线上活动为任务，以转化率或拉新数为绩效指标，用户需要的不仅是活动页面制作，还要考虑如何投放，活动过程中的运营，预防羊毛党、活动效果数据报告等。

三、总结

对于各位好学的产品经理而言，上文的各种理论也许早已耳熟能详，我也一样，但直到我在一家创业型公司从 0-1 的冷启动一款 SaaS 产品，才真正体会到产品设计代表的不仅仅是功能和用户体验，我们需要对周边的其他因素有更深刻的认识，这些因素包括客户、竞争对手、生态系统、内部组织能力等，这些因素环环相扣，共同影响着产品的设计决策。同时，产品经理都必须在模糊的情况下开始寻找解决方案，我们需要接受不确定并随时应对变化。无论任何职级的产品经理不要认为这些因素离我们的本职工作太远，或许那些理论的创造者同我们一样，踩过了无数的坑才得出的经验教训。

本文先介绍了SaaS 产品思维5个要素中的其中2个要素，我将在下一篇文章中继续总结其他3个要素以复盘过去这一阶段工作。

本文由 @圆圈圈圈圈圆 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议