笔者以实际经验为例，总结To B产品解决方案的一些心得，enjoy~

对于To B产品来说，写解决方案是一个经常性的工作，主要原因是To B产品面对的客户种类太多，不同种类的客户又有不同的定制化需求，很难通过一份标准产品介绍做到一劳永逸。

以做区块链产品的公司为例，如果客户是政府部门，需要区块链在智慧城市的融合方案，那么就需要制作一份智慧城市的解决方案；如果面对的客户是不动产行业，那么就需要先调研不动产行业现状，写一份区块链在不动产行业中的应用方案；如果客户是企业，就要根据与客户的交流需求定制化企业解决方案，如利用区块链去优化供应链金融，或利用区块链优化企业间的对账效率等。

总之To B产品很难通过一份产品介绍就完成销售的工作，通常都需要根据客户的需求，通过解决方案来告知客户自己的产品如何与对方结合，结合后的效果是什么。

笔者以实际经验为例，总结To B产品解决方案的一些心得。

一、心态

看淡：

以笔者的实际经历为例，所写的多数解决方案其实是不会落地的，大多数方案可能是写完就没有后文，客户收到解决方案后轻描淡写的看一下，面对这种经常发生的事情，有一个良好的心态是十分重要的。

看淡并不是说可以不用心去写解决方案，而是解决方案写完之后即使没有被落地，不要太过于失望。在实际的商业运转之中，购买者采购产品都会货比三家，所以按照“三家”的数量来看，至少有两家会落选，成功概率也仅仅是三分之一而已，再加上一些根本就没有需求来“骗方案”的客户或心不诚的客户，把成功率的分母基数拉的越来越大，一份解决方案可以被成功落地的概率仅有十分之一左右也不足为奇。

二、原则

1. 目标决定方案的粒度

方案没有最细化，只有更细化，具体细化到什么程度就要根据细化展开后是否有助于目标的达成来决定。例如写区块链在政府数据交易领域的解决方案，初稿方案的目标是让政府领导了解区块链，了解以区块链的模式进行数据交易可以合法合规，并且具有安全、保护隐私、权责明确等特点，围绕着这个目标，去展开写区块链的系统如何部署，数据如何建模等业务细节就没有必要，反而写了会让文档更加臃肿，不易阅读。

2. 读者的地位、时间决定方案的内容

如果是一份商业计划书，读者是资方的领导，计划书写了近50页，交给领导后你认为会发生什么？

领导随意翻一下，发现内容、数据太多，交给下属的专业人士去研究。如果方案的第一印象勾不起读者兴趣，那么方案大概率就会失败。

因此上述的商业计划书情景，就需要先面向资方领导写一份一页纸的详情介绍，在配以一份有数据有计划的详情介绍，总结下来就是要围绕读者来写，方案也需要具备用户思维。

2. 读者的认知、态度决定方案的详略

对于甲方客户来说，如果解决方案中，充斥着大量专业词汇，或方案中具有高度复杂的逻辑关系，甲方客户大概率会“跳看”，反而达不到效果。因为人是懒惰的，花费太长的时间去了解一份方案，客户很有可能没有那么强的动力，方案要优先考虑客户是否有读下去的动力。

举个例子，用一本书叫做《思考快与慢》，公认的好书，但是读起来会很耗费时间。如果是自己买回来这本书，可能会一页一页的去看仔细的看，保障自己能吸收书中的每一个知识点，但是如果乙方客户写一份类似于《思考快与慢》如此复杂的解决方案发给了甲方，甲方客户若对方案是非刚需，就没有特别强的动力去仔细阅读，一定是挑着阅读，反而影响了方案的效果。

三 、如何写解决方案

1. 开始前

多数方案的需求来自于领导、客户或销售，对方在描述方案背景、方案目的时候思维和表述是发散的，所传达的信息不充分，如果这时就直接去写方案，写好之后对方会意识到还有信息点没体现出来，往往会因此而返工。因此在方案开始前，需要了解清楚几件内容：读者、需求、现状、目的、信息点。

（1）读者

读者就是方案的阅读对象，希望发给谁。有时候方案的读者不是一个人或一类人，是几类人，例如经由系统集成商递送给政府的方案，首先的读者是系统集成商的人员，其次是政府，再复杂一些可能还会涉及到方案的最终应用方或监管方。

类似于此类方案，需要在方案中考虑到这几类潜在读者的需求，权衡各方的利益，满足各方的诉求。针对系统集成商要体现出做这个事情有收益，有好处，对他们来说还不复杂；针对政府需要体现出方案对其有政绩，有社会效益，最好花费还比较低……

对于读者，最好可以对各类读者进行读者画像。用户画像对于产品经理来说再熟悉不过了，笔者在写解决前方案，一般对读者的画像会从几个方面展开，认知程度，了解什么，不了解什么。认知程度就是对方的文化背景，知识水平，如对方是个体工商户，未完成学业就开始创业，这一类方案不能写的太高大深，高度太大反而不接地气，读者无法读懂其中的价值。

关于了解什么，不了解什么就要看对方的工作内容，判断对方是不是对一些概念，一些词汇可以轻松读懂，如若不能，就需要将概念进行展开。例如区块链与智慧城市的结合方案，如果提交给政府，区块链的概念就需要解释，如果只提交给系统开发商或集成商，就不需要详述区块链是干什么的了。

（2）需求

需求即读者想知道什么，为什么要知道，需要感受到什么。挖掘需求是产品经理的基础工作，并不只是产品设计需要挖掘需求，写文档、写方案也同样需要挖掘需求。

挖掘需求的方法可以采用丰田公司的5why分析法，就是对一个问题连续问5个“为什么”，以找到需求背后的根本诉求。读者想知道什么属于what，读者为什么要知道属于why，读者需要感受到什么属于再深一层次的why，利用这种方法，找到读者真正需要了解的内容，找到读者真正的需求，好进行下一步的方案撰写。

（3）现状

现状即做了什么，计划做什么，什么不做。我们还是以区块链和智慧城市的解决方案为例，智慧城市是一个泛泛的概念，包括智慧交通，智慧物流，智慧医疗等等，针对读者，需要了解对方已经做好了哪些内容，这些内容是不是还需要新技术来融合，如若不需要，就没必要在去写这方面的解决方案了。

计划做什么就是对方的计划，近期计划是你的重点，远期计划可以畅想。什么不做就是对方的边界，对于政府、系统开发商都有自己负责的范围（如智慧交通已经承包给其他开发商或由其他政府部门来负责），如果跨出了范围，对方不会对这部分内容感兴趣，就没必要费笔墨费脑筋去写了。

（4）目的

关于目的，要理清楚自己方案的主要目标和次要目标，多数情况目标就是为了满足读者的需求，也存在一些情况下方案就是为了抛砖，或者就是为了给对方搞晕（这种情况不多），目标不同写方案的粒度和角度都会不同。其次要搞清楚方案的形式目标，是用于演讲还是用于发送阅读，演讲在什么场地上进行，阅读是电子还是打印。

（5）信息点

信息点就是要看交代方案的人有啥想法没有，多数情况下给你交代方案的领导或者销售，都会有一些自己的思路，他们是方案的第一读者，需要先听一听他们的思路，思路不对需要给他们掰过来，否则方案都到不了目标读者就会被否掉重新。

在信息点里面需要了解两方面内容，一是期望表达的内容，二是切入点。

还是上面的例子，领导希望把区块链的智能合约用到智慧城市里面，就是重要的一个信息点，虽然用其他的方式也可以满足读者的需求，但是方案毕竟要过领导一关，所以领导的需求也需要满足。

切入点就是方案要从哪个点里面切入，例如区块链在打通政务数据方面的解决方案，可以从多个角度、多个领域切入，可以通过民政领域的应用，打通各个部门的数据通道，也可以通过大数据领域的应用，来打通各部门数据，具体选定哪个领域，哪个切入点，是需要在写方案之前明确的。

以上五点，笔者写方案之前都会写下来，写到纸上，以防自己写着写着就偏离了目标，忘记了读者，钻到细节里面。

2. 方案标题

如果是非演讲的文档，标题和副标题至少有一个需要点明主旨。标题不是展示你是文艺青年的时候，读者也不是去意会你的诗意，起一个含义极深的标题，和不用标题没什么区别，白白浪费了标题的价值。

3. 方案内容

内容要根据上面所述的需求，目的和信息点来决定，内容没有通用规则，需要根据实际情况来，例如解决方案的目标是介绍产品在特定行业的结合点，目标读者已经和你之前进行过初步的交流，方案内容直接写一两页内容甚至画个流程图都可以。下面几个常见的内容方向供参考，根据实际情况自行选择。

• 背景（可以参考金字塔原理的SQCA，情景、冲突、疑问、回答来描述方案的背景）
• 政法规（即政策、法规、法规，TO G方案常见，公务人员做事参考的标准）
• 产品功能(有时候一个方案会涉及多方用户，一定要在描述产品功能时候告诉读者这个功能的用户是谁，例如智慧城市解决方案里面，涉及到的后台系统，用户是政府部门的管理者，涉及到的APP，用户是城市居民还是执法人员，都需要重点突出，否则读者容易混乱产品给谁来用。产品的用户可以尝试使用UML的用例图来描述)
• 已有案例（有相关案例的话，一定要列上，大部分企业都不想做尝鲜者，有成熟案例落地概率高很多）
• 方案效果（对于领导来说，都是“乐见其效”的，突出效果，突出意义方得读者欢心）
• 方案优势
• 核心流程
• 功能模块
• 资源投入
• 实现周期

4. 方案内容查找来源

从0到1的编文字很痛苦，如果有现成的文字拿来使用自然轻松不少，反正方案又不查重。查找内容大家最先想到的就是利用搜索引擎，搜索引擎确实是个好途径，但内容比较碎片化，以下两个渠道可以参考。

渠道1：解决方案对应领域书籍、白皮书、研究院报告（例如：查找智慧城市主题的书籍、研究院报告，里面一定会提到区块链的应用方式，结合点等信息）；

渠道2：产品领域书籍、白皮书、研究院报告（例如：查找区块链的书籍、研究院报告，里面会提到区块链如何应用在智慧城市领域）。

5. 修改方案

方案写好后需要通篇修改方案，修改方案需要先思考方案框架是不是正确，而后逐字逐句的删词改句；最后切记朗读一遍，把内容改顺耳，很多时候默读、快读确实没问题，一旦朗读就会发现文章的不顺，切记朗读一遍。

本文由 @产品工具箱 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。