B 端产品更适合“抢滩登陆”

文章来自公号：产品晓思

文 / 李晓杰

编辑 / 小方

全文 6245 字

文章原标题“ 不玩虚的！深入 B 端 SaaS 产品设计核心理念【干货】 ”

---

笔者近 7 年一直在做 B 端大客户定制，方向侧重企业信息化和协同，涉及产品数量众多，单一产品持续深化时长有限。长时间处于传统软件定制领域，缺乏 SaaS 操盘经验，这是本文的局限性所在。

本文讨论“为什么采用 SaaS 模式”、“SaaS 产品有哪些”以及“如何做好 SaaS 产品设计”三个话题，核心是产品设计，主要从需求定义、方案设计和开发交付三方面，共计讨论 10 个问题点。

01

为什么采用 SaaS 模式

为什么要用 SaaS 模式，这个话题我们从 面向 B 端的传统软件厂商的痛点 来聊。

传统软件厂商通常的交付模式是，销售和售前根据线索参与招投标，中标后项目实施团队入驻客户现场，根据客户的实际需求开发或改造功能，完成软件部署交付并经客户业务验收后，核心团队离场由维护人员接手更新。这种模式的局限性总结来说是 “赚钱慢” ，具体说来如下：

1. 成本高。 主要包括三方面： 销售成本 、 部署人力成本 和 维护人力成本 。有多少项目，就必须配备多少人力。

2. 速度慢。 主要包括两方面： 交付慢 和 回款慢 。项目周期动辄半年，甚至一年、两年。

3. 可复制性低。 主要包括两方面： 人力依赖 和 定制化 。

项目的成交依赖售前的行业见解和对客户KP动机的洞察能力；项目的成功依赖于需求分析师对客户真实需求的挖掘和方案设计能力，以及项目经理对人、事的控制能力。

对特定能力人的需求，限制了传统软件厂商的扩张能力，同时，频繁出差也造成这个领域的优秀人才流失严重。产品化是降低成本、提高复制性的关键，然而，大客户另外 30% 的个性定制化需求，是无法跨越的鸿沟。

从客户角度，传统软件交付模式也存在着局限性，主要包括：价格贵、交付慢、升级难、失败风险高等。

如何破解传统软件交付模式的难题？按笔者的思路（只是其中一种角度），科学管理之父泰勒的“标准化”是一条可选路径，其表现形式即本文讨论的主题“SaaS 模式”。

B 端 SaaS 的核心是放弃一部分个性化需求，通过对通用功能标准化来满足企业 70% 的主要需求， 其基本假设是企业即使没有 B 端产品也照样能运行，B 端产品的价值在于比原有模式成本低、效率快、质量高，产品只要对原有模式有改善即可。

中小企业对价格敏感，相对容易接受不完美，这样 SaaS 模式便讲通了。所以， B 端 SaaS 的核心是标准化，标准化之后，成本、速度、可复制性的问题都迎刃而解。 理解这点，对 B 端 SaaS 产品设计至关重要。

02

SaaS 产品有哪些

SaaS 是一种软件交付模式，软件不需要安装，直接通过网络在线使用。SaaS 虽有 To B 与 To C 之分，但当下讨论 SaaS 多指 B 端。本文不讨论 SaaS 本身的形态和特征，更多从 SaaS 产品的分类和未来角度来理解。

在 SaaS 产品分类上，明道创始人任向晖老师曾提到，SaaS产品主要分为三类： 行业 SaaS、职能 SaaS 和 通用 SaaS 。

行业 SaaS 着眼于解决特定行业“一条线”的问题，甚至参与到行业交易处理环节，行业 Top 客户的标杆效应对产品竞争力至关重要，典型如二维火（餐饮）、别样红（酒店）。

职能 SaaS 面向企业特定职业人群解决业务“块”的问题，需要具备深厚的职业知识，产品竞争力源于对细分市场的选择、对领域知识的理解和服务耐心，典型如 Salesforce（CRM）、金蝶（ERP）、北森（HRM）。

通用 SaaS 不分行业和职能，市场空间巨大但同质化竞争也激烈，产品竞争力源于对特定类型企业的匹配度，典型如 Slack、Jira、钉钉（办公协同），Confluence、有道（知识管理）等。

在 SaaS 产品未来上，笔者更认同纷享销客前执行总裁吴昊老师的观点， SaaS 产品的未来发展主要有两个方向， 做 PaaS 平台 和 转型商业 SaaS 。

PaaS 平台 如钉钉和企业微信，在满足企业核心需求的同时，通过引进 ISV（独立软件商）满足企业个性化定制需求，实现方式包括无代码、低代码和全代码，走 PaaS 路线核心考虑的三个问题是， 用户范围是否扩大、客单价是否提高、与纯定制是否竞争力更强。

商业 SaaS 利用自身数据重度参与企业商业过程，如美团参与商家供应链等。笔者认为，虽然要了解 SaaS 产品的未来规划，但更重要的是在当下活下来，打造自己的拳头产品，找到 PMF 更重要。

03

如何做好 SaaS 产品设计

如何做好 B 端 SaaS 产品设计？

首先谈谈对 B 端与 C 端产品区别的理解，核心区别在于 C 端针对 Customer，面向个体；B端针对 Business，面向群体。

由此继续探索：

C 端侧重生活、讲究感性体验、重视人性与趣味，B 端侧重工作、讲究理性利益平衡、重视逻辑与效率；

C 端解决个体生活的单点需求，B 端解决群体多角色协同的链条需求；

C 端产品交互设计重视个体操作效率，B 端除了个体操作效率，更重视整体业务流程效率；

C 端产品经理重视把自己变成用户，B 端产品经理以为自己能变成用户就完蛋了！

对于 B 端 SaaS 产品设计，本文将从 需求定义、方案设计 和 开发交付 三方面，共计讨论 10 个问题点，但限于篇幅，本篇只谈核心点不做过多细化。

一、需求定义

1. 客户&角色画像

定位的客户不同，产品设计业务流程和功能的完备度、复杂度、侧重点等均不同。客户画像不只是在产品初期有用，它应该贯穿整个产品设计过程， 任何一个新业务、新功能，都需要回顾客户画像、角色画像。

笔者常提的一个比喻是，“一个小农想喷农药，不应该给他一架喷雾飞机，更应该给他一台手动喷雾器”，重要的不是我们的产品牛X程度，而应该是方案刚好匹配客户的需求。

客户画像的维度很多，比如行业、核心痛点、员工规模、员工构成（平均年龄、在岗时长、技能水平、新老比例等）等，其中 员工规模是个比较常用的维度 ，如定义小微企业（50人）、中小企业（500人）、大企业（1000人）。

员工规模这个维度之所以有用，是因为 小微企业和大企业的需求点差异性较大 ，以“协同”为例，小微企业和中小企业最核心的需求是以“最小阻力”实现“线上化”，但大企业则会要求功能完备、多系统贯通、数智化、合规等。

需要注意， 员工规模并非完全可定义客户需求，它只是一个参考因素 ，有很多 1000 人以上大企业，甚至互联网新兴独角兽，其协同“线上化”程度之低难以想象。

某些大厂主推的协同产品，可能需要考虑下自己是否陷入“知识诅咒”，你对产品的定位是中小企业，但你看下自己产品是适用中小企业，还是你自身所在的大厂！

角色画像对 B 端产品设计非常重要，但 C 端的用户画像并不适用 B 端，B 端角色画像在个体层面更看中技能水平、岗位稳定性等，在角色层面看重该角色存在价值、上下游角色、信息的接收处理和输出等。

2. 需求收集

B 端产品需求收集与 C 端差异性很大，总结下来，需求收集有四原则，分别是： 真实、全面、验证、善意 ，技巧是： 被动收集、深入一线、场景还原 。

“被动收集” 并非纯粹的被动等待需求反馈，而是构建好需求反馈的渠道，与种子客户、意见领袖打好关系，让用户更多、更快的反馈真实痛点，在 B 端问卷、主动访谈等手段收效不佳；

“深入一线” 是指我们在需求收集时，容易因转述造成理解偏差，此时找到需求的最原始提出人非常重要，另外，我们也需要面对面地观察需求“痛”的全过程，以真实、全面地理解需求；

“场景还原” 是通过理解需求产生的场景来理解需求，B 端我们经常会接到“功能需求”，此时，通过 5Why、究竟精神“挤牙膏式”探索“功能需求”背后的实际需求非常重要，5W1H 是场景还原时常用工具。

3. 产品规划

产品规划分远期和近期，远期规划更多为了产品架构，主要手段是分组和分层。近期规划更多是需求优先级排序，核心是衡量需求 ROI，这个职责并不一定是产品经理承担，应该让最懂 ROI 的人决定需求排序。

通常来讲， B 端优先级考量方法包括：权力影响分析、用户量频分析、拒绝影响分析等。

权力影响分析 是根据需求关注人的权力和对产品影响力的大小来决定需求优先级，有人调侃 To B 的全称是“To Boss”，这不无道理；

用户量频分析 是根据需求涉及的用户量及发生频率来决定需求优先级，B端不存在伪需求，只存在性价比不高的需求；

拒绝影响分析 是对 KANO 模型的解读，核心考量的点是，如果我们不做这个需求会产生多大影响，如果影响很小，则优先级就低。

二、方案设计

1. MVP

MVP 本应在开发交付时谈，但 MVP 的核心是 “验证” ，基于这个理解，在需求收集时就已经开始有 MVP 了，而方案设计过程更是一个 MVP 验证的过程。

作为产品经理，之所以要做方案设计的原因是： 思考、验证 与 传达 。

思考 是通过设计，让业务过程与软件设计相互契合，业务方缺乏对软件的基本理解，而开发团队出于自身立场容易曲解业务，产品经理则是要站在双方共同的立场上思考。

验证 是通过不断与业务方确认设计交付物探索真实需求，以尽量减少开发中、交付后的变更，设计交付物应追求最小成本收集反馈，在能确认需求的最大 ROI 手段上停止，成本由低到高依次是：口头核心业务确认、Xmind 核心功能确认、Visio 核心业务流程确认、纸面线框图、低保真原型、高保真原型、需求说明书；

传达 是为了确保开发团队能够理解需求，交付出能解决业务问题的功能，设计交付物是一种手段，更重要的是频繁面对面沟通。

2. 产品设计原则

对于 B 端产品设计，笔者总结的四原则是 有用、灵活、简单、美 。其中最核心的是 有用 ，即能从整体上能解决业务问题。

但在跟 BAT 大厂的产品经理交流中冲突较大，笔者聊业务背景、痛点、角色特征、核心功能，对方认为太虚；对方聊特定功能点的交互设计技巧，笔者基于“好懂”、“少动”的交互设计原则直接找竞品抄（借鉴）。

这种冲突可能源于 BAT 大厂产品经理多、专业化分工细，实际工作更需要专注把自己负责的模块和功能点做精，笔者不确定谁对谁错，但这种做法并不适用笔者服务的领域。在此不细谈 B 端产品平面设计、交互设计、简化设计技巧，此处着重强调 B 端产品设计的第一原则是有用。

3. 差异化优势

有人取笑产品经理的核心能力是“抄袭”，没头脑的 1:1 模仿一个竞品确实是抄袭。但如果对比多个竞品，甚至从非竞品的产品中寻找灵感。同时，结合自身业务痛点深入思考取舍，作为读书人，我们姑且称这种行为是“借鉴”吧。

天下产品一大抄，我们该如何确定自身产品的差异化优势？

首先，要明确自己公司的优势所在；

其次，差异化有三个小技巧： 简单、细分、理念 。

拿协同工具领域举例，工具型产品最大的问题应该是先解决用户使用意愿问题，而解决用户使用意愿除了对多角色利益的考量，尽量把功能做简单也同样重要，因为 越简单的功能，越容易在最短时间让用户感知到改变带来的价值。

细分 是进入一个特定的细分行业、特定的细分企业类型，因为细分领域有很多特定的业务逻辑，懂这些更容易与客户产生亲近感。

理念 是基于我们对行业新趋势的理解，渐进式引领客户做新尝试，客户容易深陷在旧有的知识体系内，我们由于变不成客户，恰恰更容易接受新理念。

比如在推广协同工具“电子看板”时，可以解释自己的理念是由传统的自上而下时间资源管理式甘特图，升级为当下更适用的扁平化网状沟通协同的看板，再结合精益思想、敏捷交付精神等为客户洗脑，让客户对我们的定位从“纯粹的效率协同工具”转变为“引领企业变革的新力量”。

4. 功能广与精

有些人倾向于把产品功能做全做广，拿“端到端全链路”当产品竞争力，对于这种想法笔者不太认同。

B 端产品更适合“抢滩登陆战略”，通过核心功能建立滩头阵地，再以此为基础扩大范围。

主要原因有三点： 增加用户认知负担、延缓用户体验满足感、造成用户对产品定位混乱 。另外， 在资源有限的情况下，做精比做广更容易提升产品竞争力。

相比而言，大客户才需要整体解决方案，中小客户更需要有问题时解决问题。即便大厂，也建议在产品组合中集中资源打造拳头产品，其他相关产品拆分成子产品，各自定位自身亮点，又可相互对接。

三、开发交付

1. MVP

B 端产品做 MVP 是件很难的事，功能不上，用户不买账；功能要上，资源精力不够。缺乏业务闭环的功能对客户无意义，常规功能组合又很难吸引用户。如果想着先上个功能应付，需要警醒， “B 端产品上功能容易，下功能难”。 如何做 B 端产品 MVP？这个问题笔者暂时无解，但提供三种思路：

1）把大业务拆小，基于特定小业务做最小功能组合；

2）产品缺失功能，允许用户通过线下操作弥补；

3）跟可以忍受产品不完美的种子客户建立关系。

2. 标准化与灵活

SaaS 模式的核心是标准化，但如果你真拿一个绝对标准化的产品，客户可能并不容易买单。

SaaS 产品需要灵活，主要原因有：