编辑导读：随着B端行业的日益普及，相关的讨论度也在上升。一些产品经理想进入B端行业，但他们对此知之甚少。笔者根据自己的工作经验，分享了自己对B端SaaS产品的方法论，希望对大家有所帮助。
最近B端产品的人气慢慢提升，笔者开始收到同行的一些建议。我在toB领域摸索了好几年，积累了一些经验，就整理出来分享一下。
首先问一个问题。B端产品和C端产品最大的区别是什么？
这个问题我也问过一些同事，答案多种多样。有人说设计风格，有人说行业垂直深度，有人说迭代速度。
我的结论是，最大的区别在于付款人。因为B端产品是卖给企业的，面向企业的产品性质决定了它的一系列特性，这些特性来自于谁在付费。
第一，产品的立足点在于帮助企业增长。
既然企业的目标是利润最大化，那么其愿意购买产品的动机就是产品可以帮助赚钱或者省钱。与C端不同，C端用户的支付动机可以是用酷、用习惯、用感受。因此，从这个角度来看，产品经理必须了解行业和企业的基本商业模式。这也是为什么做B端产品需要更大的行业深度，这就源于此。
第二，产品的买单人是高层及以上，统称决策者。
由于产品应用于企业，B端产品的客户单价相对较高，基本上企业的支付都是通过公共账户支付的，这意味着这不是个人行为，而且有一个漫长的过程和多个角色的审批，所以需要一个有决策能力的人来做决定。那么一个产品能不能卖，就要考虑如何打动决策者。
我们通常把决策者分为两类，主管级和老板级。
主管级的特点是他承担了一个部门/业务单元的KPI，他必须确保自己花费的成本得到回报，所以他会计算ROI来决定是否使用某个产品。
老板的特点是，除了希望公司能多赚钱，还需要监督员工的工作。而且他很忙，希望能定期看到产品使用情况的数据报告。所以，给导演留下深刻印象的是让他的产量更高。摸老板是帮他赚钱，还是通过管理内部来省钱，而不是增加他的工作成本。当然，对于小B公司来说，决策者可能只是一个人，购买流程会缩短很多，但同时他们也会更加注重成本，增加一些价格纠缠的时间，所以最终也是一样的(
:3 )
如果这种方法落入产品经理的工作中，我们会发现与销售同事保持良好的沟通非常重要，因为他们非常清楚客户的需求、客户的组织结构和客户的工作环境。
第三，产品的使用者往往不是决策者。
或者老板级角色付费后，一般交给下面的执行者实际操作产品。两种角色的区别在于，决策者关心的是收益，而不关心用户体验。高管们关心用户体验，因为他们不想增加工作量，但他们不太关心收入，他们也没有要求他们支付任何费用。所以在做B端产品的时候，有一点要明白，那就是用户体验没有那么重要。它不能直接决定用户是否会留下，甚至间接效果也很弱。往往高管只能使用购买的产品，没有那么多竞争产品可以挑剔。但体验并不是完全无动于衷，也要达到及格线，否则高管的大量投诉依然会阻碍产品的使用。
第四，产品的设计是基于实际场景出发的，绝不可以玩空中楼阁。
在为企业中的用户设计你的产品流程和体验时，你要明白对方已经形成了一些内在的机制和方式，所以你要先去了解它们，而不是关起门来想对方可能会这样使用。作为B端的产品经理，我们可以优化他们的流程，不能反对他们的流程。虽然说产品要有创意，但要分场合，基本功能要先有。在这里，复习一下上面的知识点：和销售同事保持良好的沟通，因为他们了解客户。最好和用户面对面聊天，收集第一手资料，记录整理对方的实际工作场景，然后设身处地为对方着想，了解他们的需求。
我自己叫这种思维方式为“顺应”。CUE解释了其中一个产品原则：要做好产品，首先要成为用户。
说了区别，下一个问题B和C最大的共同点是什么？
对于一个盈利的产品，无论toB还是toC，本质的答案都是：用户是谁，你通过产品给用户提供了什么，用户为什么要付费？
因此，结合这一点和上面提到的B端通用的几个规则，我总结了一个用于产品设计的自检表。
使用方法是先填(……好像是废话)。如果你发现你不能填满所有的空间，对不起，你可能…只是一个原型画家。完成后，从后往前推。你的回答有效吗？如果没有，很好，你也可以在正式开发之前修正你的产品路线。填充和推回可能是一个重复的过程，会有点痛苦。好处是它迫使产品经理检查他们的需求是否真的有用，并提高需求的质量。
>插播一个小技巧：有个快速准确的方法检验一个产品方案是否可行――带着方案去准客户面前讲，观察对方的反应。通常对方有两种反应，第一种是微笑点头表示挺好的，第二种问你多少钱。不要被第一种反应欺骗，他们的意思是这玩意儿挺好的但是自己用不上：）第二种反应出现的时候，恭喜，你的方案初步合格了。
接下来我们往SaaS聚焦一下。为什么是SaaS呢，原因很简单，风大的先讲呗 (=ω｀=)
这里我会分三部分来阐述，一是商业模式的确立，二是产品设计与落地，三是1-100的经营思维。
第一，关于商业模式。 假设你现在是一个创业者，你的目标是做某领域里的SaaS佼佼者。那么你要怎么确定做什么产品？
可以从回答以下几个问题开始。
* 行业背景：该领域的产业链是怎么运转的？囊括哪些角色？
* 市场空间：每种角色的总的市场空间？目前已有哪些公司（用户群体划分）？
* 竞品分析：已经有哪些竞品攻下了这些公司？他们提供了什么？用户购买了什么？
* 需求分析：用户的需求都有哪些？哪些被满足？哪些没有？
* 落地路径：如果选一个未被满足需求来做，能否实现？实现路径？营收天花板？（注，这里的实现路径不仅仅是指开发过程，而是从整个公司的角度出发，让哪些人配合来完成生产+售出+售后的过程。）如果选已有竞品的需求，那么你跟他们的区别是什么？
在做以上的推理过程中要注意前后顺序，逻辑应该扎实地一步一步盘点，而不要跳脱。做商业决策是个复杂的事情，每一个因素都可能影响到结果，因素越多，最后带来的波动越大且不可控。我们都知道这不是个容易的过程，所以更要谨慎，切勿因为有些问题太难就糊弄过去，比如回答4的时候直接用竞品已经做好的事情来回答，那么就会失去潜在市场了，也不可能完整地完成落地。
我画了一张图示意盘点市场过程中应该明确了解的内容之一：
比较粗糙，反正就这个意思吧(`) 。就是说动手之前心里要有底。做产品绝不可以糊里糊涂。一个做决策的岗位一旦开始糊弄，就是整条业务线的灾难。
另外真正决定要做什么的时候，除了上述理智的分析，其实还有一个感性的因素存在。就是决心。《智能商业》里把它称为信念之跃。（我很喜欢这个词，所以稍微提一下，本文不再展示描述。）
第二，产品设计与落地。 做设计之前请先温习一个知识点：确保你足够了解你的用户。
设计分为两个部分，流程设计与体验设计。
流程设计的重心，是保证用户的业务能够完成闭环。闭环包括操作上对于用户的指引，比如步骤一操作完成之后引导去往步骤二，比如确认用户完成整个流程，不要让其不清楚自己处在流程中哪一步。闭环也包括数据流转的过程，比如用户行为数据收集，比如用户业务数据应用，要考虑的问题类似于用户从个人中心上传个人信息之后数据怎么放，如何统计如何刷新，其他模块是否能够应用，如果用的话数据以什么频率什么方式传递。整体设计基于对业务、用户、技术、数据的了解，所以对于产品经理的要求比较高。当PM在其中任何一环薄弱，就会直接严重影响产品质量。
体验设计的重心，在于不要给用户创造阻碍――包括流程性阻碍与细节阻碍。细节阻碍主要体现在交互设计上。这方面就考验产品经理的基本功了――交互设计能力，同理心与责任心。为什么要讲责任心呢，因为要做好这件事其实需要大量的心力投入，反反复复去思考与尝试用户实操的场景，观察与分析每一个细节。没有足够的责任心就不会支撑这种投入。如果是这方面经验略少的话，推荐读《About
Face 4 交互设计精髓》，交互界的教科书之一。
第三，产品经营的1-100。
产品的经营分为两部分，单个产品的优化迭代，和整个产品线的规划。
对于单个产品来讲，迭代方式来自于两个方面，一是用户直接反馈，二是数据表现。优化的点也集中在两个方面，流程性问题，转化性问题。在思考具体做哪些优化需求时，可以参照下面两张图：
这个图的意思就是要对比最初做这款产品时候的预期与实际表现。对比的作用在于定位差异，然后寻找根因，分析之后尝试解决差异。这样能够保证产品路线不会走偏。这里也有一张自查表：
同理的，如果不知道怎么填，那么……就只是个画原型的。同理的，这个表格的填写也遵循反复推理的过程。不过这个比上次做的时候会简单点，毕竟聚焦到小颗粒的问题上了。
这个表填完后，最后一个格子“方案预期带来的”的内容将作为下次分析时候的基准线。
我在实操的过程中发现，以上这些问自己的问题，以及这些产出的文档，都是一环扣一环的关系。每一步踏出，都应该基于明确的信息，严谨的分析和推理。所以呢有必要存好一个产品的一生中的所有文档，这个思维我称之为“继承”。
单个产品的优化相对于整条产品线的规划来说是简单很多的。为什么产品线需要经营呢？因为每个产品都有它的周期，出生，兴盛，衰亡。产品依赖于用户，用户量是有限的，产品的增长就是有限的。但是一个公司的生意可以是无限的。所以一条产品线走到了天花板时，就需要第二条产品线。与前文做商业模式的确立时候不太一样的是，这次的规划是基于已有业务去考虑的。
这点可以参考许多SaaS的成熟玩家――金蝶明源广联达，他们都从一个点做起，比如说财务管理，然后延展其产品至整个业务线，这种方式叫做管道式发展，也可以称为纵向发展。当一条线的红利吃掉之后，开始开拓第二个点，然后再做一条管道。管道发展起来，就开始横向发展。这样慢慢地产品从一个点，扩到一条线，再到一个矩阵，一张网络。就慢慢建立起了业务积淀和规模效应，从而发展出护城河。
《智能商业》里提到一个点线面体的概念，类比于此。（cue了两次，着实喜欢这本书。）
以上，感谢阅读。
本文由 @一个圆圈儿 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
