编辑导语：在B端产品从0到1的设计中，产品经理需要进行合理规划，找准产品自身定位，洞察用户需求，以求更精准地解决用户痛点，并推动后续方案的迭代优化。本篇文章里，作者总结了B端产品从0到1的设计方案流程，一起来看一下。

上一篇，我们讲了从0到1设计B端产品的业务调研。今天，我们继续讲产品方案。限于篇幅，本文将重点阐述总体方案部分。

对B端业务调研感兴趣的朋友，可以阅读我的文章《没有这个能力，还是合格的中级产品经理吗？》。

一、产品方案的要点

一般情况下，从0到1的B端产品往往聚焦于企业少数几个痛点，同时具备很强的可落地性。如果是SaaS产品，还必须长远规划，以减少后期迭代的成本。因此，B端产品方案主要有以下三个要点。

1. 聚焦重点

从0到1的B端产品必须聚焦重点，以最小成本验证产品的价值。

聚焦重点的本质是“定位”，即面向哪一类客户，解决哪一个痛点。定位良好的产品，就像一把锥子，能够迅速切入市场，并且取得稳固的市场地位。

聚焦重点也是敬畏市场的表现。在互联网浪潮下，不管是创业公司、还是客户自己，往往都在一边探索一边调整。快速推出MVP版本，再根据用户反馈迅速迭代，是产品创新的最佳实践。

2. 究竟精神

永远相信用户，但是永远也不要相信用户。

所谓相信用户，是相信当用户提出一个需求，它确实反映了用户存在一个困扰；所谓不要相信用户，是不要指望用户会透彻分析自己的需求，而他们所提出的方案往往也是“头疼医头、脚疼医脚”。这并不能归罪于用户，毕竟，对他们来说，达成业务目标才是最重要的事，系统只是辅助手段，不值得花费太多时间深入思考。

关于要不要听用户的，海底捞创始人张勇有一段经典的阐述：“消费者说海底捞不好吃，其实可能是嫌价格贵。我老婆说我回家晚，可能是我对她关心不够。如果我信我老婆的话，每天都在家待着，我相信我老婆会更讨厌我。”

在制作产品方案时，我们必须洞察用户需求，找到需求背后的真相。而这种洞察能力，很大程度上依赖于我们的究竟精神。

比如，用户提出，希望能够增加一个订单付款状态，且当状态为“未付款”时，不允许发货。如果我们能够进一步提问，就会发现用户更深层次的需求。模拟对话如下：

产品经理：为什么订单没有付款，就不允许发货呢？

用户：因为和这些客户不是长期合作，为了控制风险，所以必须先款后货。

产品经理：那么长期合作的客户呢？是不是就可以不付款也允许发货呢？

用户：要分情况，有些客户可以付一部分款就发货，有些客户可以不付款先发货。

产品经理：什么样的客户可以付一部分款就发货，什么样的客户可以不付款先发货呢？

实际上，有经验的产品经理，会根据信用管理的框架，对客户类别、信用政策、应收款管理等方面进行全面梳理。因为从产品架构角度来看，这个需求无疑应该纳入信用管理模块。

如果一个方案没有经过严谨梳理，在落地过程中就可能出现问题。比如，在上述例子中，如果直接根据用户需求设计产品，在后期很可能就需要对方案进行大改。

值得一提的是，B端产品经理的工作非常依赖冷静思考。如果外界给产品经理施加了过大压力，就可能导致产品经理“动作变形”，从而做出错误决策。作为产品经理，我们要警惕过大的外部压力，时刻提醒自己：没有慎重思考过的产品，不值得浪费宝贵资源。

3. 长远规划

如果我们设计的是SaaS产品，则必须注重长远规划。

从0到1的SaaS，客群规模有一个从小到大的过程。当客户和功能数量都较少时，如果缺乏规划，产品就很容易野蛮生长。

比如，买赠是消费品行业常用的促销手段。在某些情况下，赠品需要关联到主品，比如买5瓶大可乐送1瓶小可乐。产品经理为了设计和操作方便，可能选择直接在订单行上新增两个字段，体现赠品名称和数量。

这样的设计在面对简单需求时，可能不会出现问题。但一旦遇到比较复杂的需求，就会出现问题，比如：

需要管理赠品发货；一种售卖品送多种赠品，比如买2瓶大可乐送1瓶小可乐和1个杯子；需要和ERP系统集成。

正确的做法是，主品和赠品都放在独立的订单行，拥有相同的字段，并且通过“赠品”字段来标识该订单行是否赠品（打勾即为赠品）。

因此，作为SaaS产品经理，不能够只盯着眼前的需求，而要放眼长远，做全面的考虑。

二、产品方案的结构

如果只是针对一小块功能的迭代，产品方案要求相对简单。重点说清楚：

但如果是从0到1设计一款产品，特别是设计一款SaaS产品，则必须从更高、更全面的视角进行方案梳理。

我建议的产品方案结构如下：

总体方案；详细方案；管理报表方案；集成方案；用户期望满足。

在总体方案部分，需要对产品价值、整体方案和总体架构进行说明，一方面便于给公司和客户高层进行汇报；另一方面也便于产品经理们了解彼此的工作，提高沟通与协作效率。

在详细方案部分，需要对每个模块的需求进行分析，重点论证是否伪需求，并明确成功指标，然后通过文字说明和流程图对解决方案进行阐述，最后才是页面设计和相关逻辑说明。

对于B端产品，管理报表虽然功能相对简单，但反映了管理者的需求，需要和业务功能一并设计。否则，一旦后期发现产品不能支撑管理报表需求，就很可能导致返工。

对于针对大企业的B端产品，往往会涉及到系统集成。系统集成反映了上下游业务的需求，也需要尽早规划和设计。

最后，产品对用户期望的满足程度，往往决定了用户对产品的满意度。即便在MVP阶段无法满足所有需求，也需要纳入长期规划。

三、总体方案

总体方案是整个产品方案中最精华的部分。理论上，仅仅通过总体方案，高层就能够决策一个产品要不要研发。

总体方案又分为以下四个部分：

方案概要说明；总体流程图；应用架构图；多组织架构设计。

接下来，我们挨个进行阐述。

1. 方案概要说明

该部分内容主要说明产品的定位，以及MVP版本的范围。这也是B端产品从0到1，产品方案最核心的部分。

方案概要说明包含以下三部分内容。

1）产品定位

定位决定成败。大部分产品失败的原因，都是没有回答好以下三个问题：

比如，某位创业者希望做一款组织管理工具，但具体解决客户什么痛点，以及和钉钉、飞书这些成熟产品有什么区别，都不能清晰表述。这样的产品大概率会失败。

在这个部分，我建议产品经理可以畅想一下：如果客户写来一封感谢信，诉说使用产品后给他们带来的改变，那么这封信的内容应该是怎样的呢？

比如，对于一款针对养生服务连锁门店的SaaS软件，产品定位如下：

① 客户是谁？

会员制的养生服务连锁门店，根据XX咨询报告，2020年全国约有700万家养生服务连锁门店。

② 痛点是什么？

痛点主要是两个。一是门店获客差，二是门店运营管理效率低。

③ 为什么选择我们？

我们的产品是针对养生服务连锁门店的SCRM，能够针对性解决他们的痛点。更重要的是，我们的核心团队有丰富的养生服务连锁门店运营经验，在门店数字化运营方面也有成功经验。

客户感谢信示例如下：

你好小李，

自从使用你们的产品后，我们的获客成本大大降低，特别是省去了1000元/客的地推成本。同时，潜客进店成交率提升了20%，这得益于互联网裂变带来的更高质量的线索。

另外，使用了你们的产品后，由于运营数据都自动生成，门店行政人员的工作量大大减轻。更重要的是，由于可以在手机端实时查看运营数据，公司的决策效率大大提升。以前月初才能分析上月运营情况，现在每天都可以开运营分析会议。感谢你们设计出这么优秀的产品！

2）产品功能模块

在明确用户痛点和产品价值后，我们还需要明确产品的功能模块。

首先需要明确MVP版本的功能模块。

MVP其实包含了两个要点。一是“最小化”，即只做最核心的功能；二是“可行”，即用户能够使用起来，并且满足他们最核心的需求。

曾经有创业者问我，如何判断一个产品已经完成MVP阶段？我个人认为就是客户是否愿意续约。之所以用“续约”而不是用“付费”，是因为担心客户付费以后，发现产品并不能很好的解决业务问题。

如果是SaaS产品，还建议区分标准化功能和定制化功能。如果是定制化功能，建议与标准化功能区隔开，避免对标准化功能造成干扰。比如，客户希望在订单上增加一个特殊逻辑，根据自定义公式自动生成商品价格。如果我们还没有计划对其进行标准化，就可以为这个公式设计单独的页面，并且默认商品价格计算不使用这个公式。

除了MVP版本的功能，我们还可以规划后续版本的功能。

长远考虑有利于提前设计好产品架构，降低后续迭代的成本。比如，如果未来计划建设财务模块，或者对接成熟的财务系统，那么就可以提前考虑“关账”的概念：对于财务核算来说，本月是不允许随意调整上月出库订单等业务数据的，否则会影响已经出具的上月财务报表。

当然，不能为了“确定性较低”的未来规划，给研发造成过大负担。这时候就比较考验产品经理的系统架构能力和业务洞察力。在这个方面，推荐大家阅读我的文章《成熟的B端产品经理，都有这个能力》。

2. 总体流程图

B端产品往往需要支持多部门、多角色协同，因此对于业务链条较长的产品，需要绘制总体流程图，以便于从整体上鸟瞰整个产品的业务流程，避免错漏。

在范围上，整体流程图需要覆盖所有关键流程和业务类型。在颗粒度上，整体流程图主要描述关键步骤，不需要细化到具体功能甚至页面。对于比较简单的业务流程，比如客户信息管理，可以跳过总体流程图，直接绘制详细流程图。

示例如下：

在上图中，现结和落地结算是XX制造企业的两种关键业务类型。

对于现结业务，出库即可确认商品所有权转移，因此根据实物出库数量冲减系统库存数量，并且生成财务结算单据即可。对于落地结算业务，出库只是实物转移到客户现场，到月底时，需要根据客户实际使用数量生成财务结算单据，并冲减系统库存数量。上述流程图正是描述了两种关键业务的整体流程。

3. 系统架构图

对于比较复杂的系统，我们还需要绘制系统架构图。

特别是SaaS产品，合理的系统架构可以有效减少功能重复、避免数据混乱和降低系统扩展难度。反之，一旦在不合理的系统架构上搭建起页面，特别是在拥有一定数量的企业客户后，修改的成本可能会很高。

相对来说，自研产品的纠错成本就低得多。毕竟只有一家企业在用，只要和业务部门协商好，推翻重建也是可行的。

系统架构设计的重点要做到低耦合、高复用。

所谓低耦合，是将功能按照业务相关性，分为多个系统应用。系统应用之间通过API进行交互。这样，单个应用的升级，对其他应用的影响就小很多，从而提高了系统的敏捷性。比如，销售订单管理、仓库管理和CRM就可以独立为多个应用，并且在必要的时候分配给不同的产品经理负责。

当然，对于同一类应用，有时候我们还需要进一步拆分。比如，针对大客户的销售订单管理，和针对小客户的销售订单管理，由于需求差异较大，为了避免彼此影响而增加系统复杂度，可以考虑划分为两个独立应用。毕竟，相对于研发成本，业务匹配程度和用户使用成本更为重要。

所谓高复用，即将各个模块所共用的功能抽离出来，单独形成一个系统应用。这样，一方面确保了信息来源的一致性，另一方面也简化了系统架构，避免了重复开发。比如，客户信息在销售订单管理、CRM、TMS（运输管理）等系统应用中都会用到，可以考虑合并成一个应用。

系统架构设计虽然没有标准答案，但实际上不管是传统的Oracle ERP系统，还是新兴的各大电商、SaaS系统，都有非常成熟的架构设计。多研究竞品，再结合实际情况进行适当的调整是系统架构设计的好方法。

示例如下：

在该示例中，品牌商系统主要面向年销售额50亿以上的品牌商，经销商系统主要面向年销售额2千万到1亿之间的经销商。

考虑到前端业务需求差异较大且相互排斥，同时用户对产品体验和效率要求较高。为降低系统复杂度，采取了首先按企业类型划分大版本，再按业务类型划分功能模块的系统架构策略。而对于客户信息管理、商品信息管理等基础模块，考虑到业务需求差异较小且相互包容，同时也不是高频操作，为了增加可复用性，采取了共用一套模块的系统架构策略。

4. 多组织架构设计

企业业务的开展，是基于多个部门的相互协同和相互监督的。当用户在使用B端系统时，流程流转、数据安全性都必须符合企业协同与管控的要求。这就需要我们设计好组织、角色和权限功能。

对于存在多事业部或分子公司的大企业，还可能需要设计多组织架构。

示例如下。

某电器公司为扩大销售规模，分别在A市和B市建立了分公司，各负责一个大区的销售工作。为便于管理和激励分公司团队，公司决定两个分公司独立核算利润，并根据实现的利润进行分红。

为支持两个分公司的独立核算，并防止数据泄露，该公司IT团队决定分别给两个分公司建立一个“利润中心组织”。在“利润中心组织”下面建立了相应的“角色”，并分配了相应的“功能”比如销售订单、发货功能等等。最后，将相应的“角色”分别分配给了两个分公司的员工。

四、结语

到这里，B端产品方案的总体方案部分，就告一段落了。下一篇，我们接着阐述以下部分：

#专栏作家#

王戴明，微信公众号：To B老人家，人人都是产品经理专栏作家，多年互联网产品与信息化管理经验。

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

题图来自 Unsplash，基于 CC0 协议