做B端大客户定制，方向侧重企业信息化和协同，涉及产品数量众多

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

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

一、Why

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

传统软件厂商通常的交付模式是，销售和售前根据线索参与招投标，中标后项目实施团队入驻客户现场；根据客户的实际需求开发或改造功能，完成软件部署交付并经客户业务验收后，核心团队离场由维护人员接手更新。

这种模式的局限性总结来说是“赚钱慢”，具体说来如下：

1）成本高

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

2）速度慢

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

3）可复制性低

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

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

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

如何破解传统软件交付模式的难题？

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

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

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

（P.S.但SaaS真的是万灵药吗？这个话题不在本文讨论范围内，留待以后文章。）

二、What

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

在SaaS产品分类上，笔者更认同明道创始人任向晖老师的观点，SaaS产品主要分为3类，行业SaaS、职能SaaS和通用SaaS。

• 行业SaaS着眼于解决特定行业“一条线”的问题，甚至参与到行业交易处理环节，行业Top客户的标杆效应对产品竞争力至关重要，典型如二维火（餐饮）、别样红（酒店）；
• 职能SaaS面向企业特定职业人群解决业务“块”的问题，需要具备深厚的职业知识，产品竞争力源于对细分市场的选择、对领域知识的理解和服务耐心，典型如SalesForce（CRM）、金蝶（ERP）、北森（HRM）；
• 通用SaaS不分行业和职能，市场空间巨大但同质化竞争也激烈，产品竞争力源于对特定类型企业的匹配度，典型如Slack、Jira、钉钉（办公协同），Confluence、有道（知识管理）等。

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

PaaS平台如钉钉和企业微信，在满足企业核心需求的同时，通过引进ISV（独立软件商）满足企业个性化定制需求，实现方式包括无代码、低代码和全代码；走PaaS路线核心考虑的3个问题是，用户范围是否扩大、客单价是否提高、与纯定制是否竞争力更强；商业SaaS利用自身数据重度参与企业商业过程，如美团参与商家供应链等。

笔者认为，虽然要了解SaaS产品的未来规划，但更重要的是在当下活下来，打造自己的拳头产品，找到PMF更重要。

三、How

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

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

由此继续探索：C端侧重生活、讲究感性体验、重视人性与趣味，B端侧重工作、讲究理性利益平衡、重视逻辑与效率；C端解决个体生活的单点需求，B端解决群体多角色协同的链条需求；C端产品交互设计重视个体操作效率，B端除了个体操作效率，更重视整体业务流程效率；C端产品经理重视把自己变成用户，B端产品经理以为自己能变成用户就完蛋了！

对于B端SaaS产品设计，笔者主要从需求定义、方案设计和开发交付3方面，共计讨论10个问题点；以下任意一个问题点，都可以拿出来细化为一篇文章，但限于篇幅，本篇只谈核心点不做过多细化（若后面有时间，笔者会花时间总结细化）。

1. 需求定义

1）客户&角色画像

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

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

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

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

需要注意，员工规模并非完全可定义客户需求，它只是一个参考因素，笔者接触了很多1000人以上大企业，甚至互联网新兴独角兽，其协同“线上化”程度之低难以想象！某些大厂主推的协同产品，可能需要考虑下自己是否陷入“知识诅咒”，你对产品的定位是中小企业，但你看下自己产品是适用中小企业，还是你自身所在的大厂！

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

2）需求收集

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

• “被动收集”并非纯粹的被动等待需求反馈，而是构建好需求反馈的渠道，与种子客户、意见领袖打好关系，让用户更多、更快的反馈真实痛点，在B端问卷、主动访谈等手段收效不佳；
• “深入一线”是指我们在需求收集时，容易因转述造成理解偏差，此时找到需求的最原始提出人非常重要，另外，我们也需要面对面的观察需求“痛”的全过程，以真实、全面的理解需求；
• “场景还原”是通过理解需求产生的场景来理解需求，B端我们经常会接到“功能需求”；此时，通过5Why、究竟精神“挤牙膏式”探索“功能需求”背后的实际需求非常重要，5W1H是场景还原时常用工具。

3）产品规划

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