在B端产品的设计和开发过程中，产品经理面临的挑战是如何从零开始构建一个既满足市场需求又具备可扩展性的产品。王戴明在其文章中深入探讨了B端产品方案的关键要点，包括聚焦重点、究极精神和长远规划，并提出了一个详尽的产品方案结构。这些宝贵的经验和策略对于任何希望在B端市场取得成功的产品经理来说都是必读的内容。
一般情况下，从0到1的B端产品往往聚焦于企业少数几个痛点，同时具备很强的可落地性。
如果是商业化产品，还必须长远规划，以减少后期迭代的成本。因此，B端产品方案主要有以下三个要点：
从0到1的B端产品必须聚焦重点，以最小成本验证产品的价值。
聚焦重点的本质是“定位”，即面向哪一类客户，解决哪一个痛点。定位良好的产品，就像一把锥子，能够迅速切入市场，并且取得稳固的市场地位。
聚焦重点也是敬畏市场的表现。在互联网浪潮下，不管是创业公司，还是客户自己，往往都在一边探索一边调整。快速推出MVP版本，再根据用户反馈迅速迭代，是产品创新的最佳实践。
永远相信用户，但是永远也不要相信用户。
所谓相信用户，是相信当用户提出一个需求，它确实反映了用户存在一个困扰；
所谓不要相信用户，是不要指望用户会透彻分析自己的需求，而他们所提出的方案往往也是“头疼医头、脚疼医脚”。
这并不能归罪于用户，毕竟，对他们来说，达成业务目标才是最重要的事，系统只是辅助手段，不值得花费太多时间深入思考。
关于要不要听用户的，海底捞创始人张勇有一段经典的阐述：“消费者说海底捞不好吃，其实可能是嫌价格贵。我老婆说我回家晚，可能是我对她关心不够。如果我信我老婆的话，每天都在家待着，我相信我老婆会更讨厌我。”
在制作产品方案时，我们必须洞察用户需求，找到需求背后的真相。而这种洞察能力，很大程度上依赖于我们的究竟精神。
比如，用户提出，希望能够增加一个订单付款状态，且当状态为“未付款”时，不允许发货。如果我们能够进一步提问，就会发现用户更深层次的需求。模拟对话如下：
产品经理：为什么订单没有付款，就不允许发货呢？
用户：因为和这些客户不是长期合作，为了控制风险，所以必须先款后货。
产品经理：那么长期合作的客户呢？是不是就可以不付款也允许发货呢？
用户：要分情况，有些客户可以付一部分款就发货，有些客户可以不付款先发货。
产品经理：什么样的客户可以付一部分款就发货，什么样的客户可以不付款先发货呢？
实际上，有经验的产品经理，会根据信用管理的框架，对客户类别、信用政策、应收款管理等方面进行全面梳理。因为从产品架构角度来看，这个需求无疑应该纳入信用管理模块。
如果一个方案没有经过严谨梳理，在落地过程中就可能出现问题。比如，在上述例子中，如果直接根据用户需求设计产品，在后期很可能就需要对方案进行大改。
值得一提的是，B端产品经理的工作非常依赖冷静思考。
如果外界给产品经理施加了过大压力，就可能导致产品经理“动作变形”，从而做出错误决策。
作为产品经理，我们要警惕过大的外部压力，时刻提醒自己：没有慎重思考过的产品，不值得浪费宝贵资源。
如果我们设计的是商业化产品，则必须注重长远规划。
从0到1的商业化产品，客群规模有一个从小到大的过程。当客户和功能数量都较少时，如果缺乏规划，产品就很容易野蛮生长。
比如，买赠是消费品行业常用的促销手段。在某些情况下，赠品需要关联到主品，比如买5瓶大可乐送1瓶小可乐。
产品经理为了设计和操作方便，可能选择直接在订单行上新增两个字段，体现赠品名称和数量。
这样的设计在面对简单需求时，可能不会出现问题。但一旦遇到比较复杂的需求，就会出现问题，比如：
1）需要管理赠品发货；
2）一种售卖品送多种赠品，比如买2瓶大可乐送1瓶小可乐和1个杯子；
3）需要和ERP系统集成。
正确的做法是，主品和赠品都放在独立的订单行，拥有相同的字段，并且通过“赠品”字段来标识该订单行是否赠品（打勾即为赠品）。
因此，作为商业化产品经理，不能够只盯着眼前的需求，而要放眼长远，做全面的考虑。
如果只是针对一小块功能的迭代，产品方案要求相对简单。重点说清楚1）解决什么问题；2）解决问题的方案；3）页面设计和逻辑即可。
但如果是从0到1设计一款产品，特别是设计一款SaaS产品，则必须从更高、更全面的视角进行方案梳理。
我建议的产品方案结构如下：
1、总体方案
2、详细方案
3、管理报表方案
4、集成方案
5、用户期望满足
在总体方案部分，需要对产品价值、整体方案和总体架构进行说明，一方面便于给公司和客户高层进行汇报；另一方面也便于产品经理们了解彼此的工作，提高沟通与协作效率。
在详细方案部分，需要对每个模块的需求进行分析，重点论证是否伪需求，并明确成功指标，然后通过文字说明和流程图对解决方案进行阐述，最后才是页面设计和相关逻辑说明。
对于B端产品，管理报表虽然功能相对简单，但反映了管理者的需求，需要和业务功能一并设计。否则，一旦后期发现产品不能支撑管理报表需求，就很可能导致返工。
对于针对大企业的B端产品，往往会涉及到系统集成。系统集成反映了上下游业务的需求，也需要尽早规划和设计。
最后，产品对用户期望的满足程度，往往决定了用户对产品的满意度。即便在MVP阶段无法满足所有需求，也需要纳入长期规划。
总体方案是整个产品方案中最精华的部分。理论上，仅仅通过总体方案，高层就能够决策一个产品要不要研发。
总体方案又分为以下四个部分：
1）方案概要说明
2）总体流程图
3）应用架构图
4）多组织架构设计
接下来，我们挨个进行阐述。
该部分内容主要说明产品的定位，以及MVP版本的范围。这也是B端产品从0到1，产品方案最核心的部分。
方案概要说明包含以下三部分内容：
1）产品定位：
定位决定成败。大部分产品失败的原因，都是没有回答好以下三个问题：
客户是谁？
痛点是什么？
客户为什么选择我们？
比如，某位创业者希望做一款组织管理工具，但具体解决客户什么痛点，以及和钉钉、飞书这些成熟产品有什么区别，都不能清晰表述。这样的产品大概率会失败。
在这个部分，我建议产品经理可以畅想一下：如果客户写来一封感谢信，诉说使用产品后给他们带来的改变，那么这封信的内容应该是怎样的呢？
比如，对于一款针对养生服务连锁门店的SaaS软件，产品定位如下：
客户是谁？会员制的养生服务连锁门店，根据XX咨询报告，2020年全国约有700万家养生服务连锁门店。
痛点是什么？
痛点主要是两个。一是门店获客差，二是门店运营管理效率低。
为什么选择我们？
我们的产品是针对养生服务连锁门店的SCRM，能够针对性解决他们的痛点。更重要的是，我们的核心团队有丰富的养生服务连锁门店运营经验，在门店数字化运营方面也有成功经验。
客户感谢信示例如下：
你好小李，自从使用你们的产品后，我们的获客成本大大降低，特别是省去了1000元/客的地推成本。同时，潜客进店成交率提升了20%，这得益于互联网裂变带来的更高质量的线索。
另外，使用了你们的产品后，由于运营数据都自动生成，门店行政人员的工作量大大减轻。更重要的是，由于可以在手机端实时查看运营数据，公司的决策效率大大提升。以前月初才能分析上月运营情况，现在每天都可以开运营分析会议。感谢你们设计出这么优秀的产品！
2）产品功能模块：
在明确用户痛点和产品价值后，我们还需要明确产品的功能模块。
首先需要明确MVP版本的功能模块。
MVP其实包含了两个要点。一是“最小化”，即只做最核心的功能；二是“可行”，即用户能够使用起来，并且满足他们最核心的需求。
曾经有创业者问我，如何判断一个产品已经完成MVP阶段？
我个人认为就是客户是否愿意续约。之所以用“续约”而不是用“付费”，是因为担心客户付费以后，发现产品并不能很好的解决业务问题。
如果是SaaS产品，还建议区分标准化功能和定制化功能。
如果是定制化功能，建议与标准化功能区隔开，避免对标准化功能造成干扰。
比如，客户希望在订单上增加一个特殊逻辑，根据自定义公式自动生成商品价格。如果我们还没有计划对其进行标准化，就可以为这个公式设计单独的页面，并且默认商品价格计算不使用这个公式。
除了MVP版本的功能，我们还可以规划后续版本的功能。
长远考虑有利于提前设计好产品架构，降低后续迭代的成本。
比如，如果未来计划建设财务模块，或者对接成熟的财务系统，那么就可以提前考虑“关账”的概念：对于财务核算来说，本月是不允许随意调整上月出库订单等业务数据的，否则会影响已经出具的上月财务报表。
当然，不能为了“确定性较低”的未来规划，给研发造成过大负担。
这时候就比较考验产品经理的系统架构能力和业务洞察力。在这个方面，推荐大家阅读我的文章《成熟的B端产品经理，都有这个能力》。
B端产品往往需要支持多部门、多角色协同，因此对于业务链条较长的产品，需要绘制总体流程图，以便于从整体上鸟瞰整个产品的业务流程，避免错漏。
在范围上，整体流程图需要覆盖所有关键流程和业务类型。
在颗粒度上，整体流程图主要描述关键步骤，不需要细化到具体功能甚至页面。对于比较简单的业务流程，比如客户信息管理，可以跳过总体流程图，直接绘制详细流程图。
示例如下：
在上图中，现结和落地结算是XX制造企业的两种关键业务类型。
对于现结业务，出库即可确认商品所有权转移，因此根据实物出库数量冲减系统库存数量，并且生成财务结算单据即可。
对于落地结算业务，出库只是实物转移到客户现场，到月底时，需要根据客户实际使用数量生成财务结算单据，并冲减系统库存数量。
上述流程图正是描述了两种关键业务的整体流程。
对于比较复杂的系统，我们还需要绘制系统架构图。
特别是SaaS产品，合理的系统架构可以有效减少功能重复、避免数据混乱和降低系统扩展难度。
反之，一旦在不合理的系统架构上搭建起页面，特别是在拥有一定数量的企业客户后，修改的成本可能会很高。
相对来说，自研产品的纠错成本就低得多。毕竟只有一家企业在用，只要和业务部门协商好，推翻重建也是可行的。
系统架构设计的重点要做到低耦合、高复用。
所谓低耦合，是将功能按照业务相关性，分为多个系统应用。系统应用之间通过API进行交互。
这样，单个应用的升级，对其他应用的影响就小很多，从而提高了系统的敏捷性。
比如，销售订单管理、仓库管理和CRM就可以独立为多个应用，并且在必要的时候分配给不同的产品经理负责。
当然，对于同一类应用，有时候我们还需要进一步拆分。
比如，针对大客户的销售订单管理，和针对小客户的销售订单管理，由于需求差异较大，为了避免彼此影响而增加系统复杂度，可以考虑划分为两个独立应用。
毕竟，相对于研发成本，业务匹配程度和用户使用成本更为重要。
所谓高复用，即将各个模块所共用的功能抽离出来，单独形成一个系统应用。
这样，一方面确保了信息来源的一致性，另一方面也简化了系统架构，避免了重复开发。
比如，客户信息在销售订单管理、CRM、TMS（运输管理）等系统应用中都会用到，可以考虑合并成一个应用。
系统架构设计虽然没有标准答案，但实际上不管是传统的Oracle ERP系统，还是新兴的各大电商、SaaS系统，都有非常成熟的架构设计。
多研究竞品，再结合实际情况进行适当的调整是系统架构设计的好方法。示例如下：
在该示例中，品牌商系统主要面向年销售额50亿以上的品牌商，经销商系统主要面向年销售额2千万到1亿之间的经销商。
考虑到前端业务需求差异较大且相互排斥，同时用户对产品体验和效率要求较高。为降低系统复杂度，采取了首先按企业类型划分大版本，再按业务类型划分功能模块的系统架构策略。
而对于客户信息管理、商品信息管理等基础模块，考虑到业务需求差异较小且相互包容，同时也不是高频操作，为了增加可复用性，采取了共用一套模块的系统架构策略。
企业业务的开展，是基于多个部门的相互协同和相互监督的。
当用户在使用B端系统时，流程流转、数据安全性都必须符合企业协同与管控的要求。这就需要我们设计好组织、角色和权限功能。
对于存在多事业部或分子公司的大企业，还可能需要设计多组织架构。
示例如下：
某电器公司为扩大销售规模，分别在A市和B市建立了分公司，各负责一个大区的销售工作。为便于管理和激励分公司团队，公司决定两个分公司独立核算利润，并根据实现的利润进行分红。
为支持两个分公司的独立核算，并防止数据泄露，该公司IT团队决定分别给两个分公司建立一个“利润中心组织”。在“利润中心组织”下面建立了相应的“角色”，并分配了相应的“功能”比如销售订单、发货功能等等。最后，将相应的“角色”分别分配给了两个分公司的员工。
到这里，B端产品方案的总体方案部分就告一段落了。大家可以关注我的公众号，我抽时间再讲一讲详细方案怎么做。
最后，一份好的方案文档也是面试大杀器，很多产品经理就是通过提交方案文档来获得面试机会：
本文由人人都是产品经理作者【ToB老人家】，微信公众号：【ToB老人家】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。