从0到1的B端产品方案，10年老兵的经验和总结
编辑导语：对于一名B端产品经理来说，如何写好B端产品方案是一个重要的技能。一方面，能够给公司及客户高层进行有效汇报，另一方面也有利于同事之间相互了解工作，提供沟通与协作效率。作者总结了10年的工作经验和总结，与你分享。
上一篇，我们讲了从0到1设计B端产品的总体方案。有兴趣的朋友可以阅读我的《5000字长文：B端产品从0到1，产品方案+案例》。
今天，我们继续讲详细方案，并且分析产品经理如何培养自己的方案能力。
一、 详细方案的结构和要点
总体方案主要是对产品价值、总体流程和架构进行说明。一方面便于给公司和客户高层进行汇报；另一方面也便于产品经理们了解彼此的工作，提高沟通与协作效率。
而详细方案则需要对每个模块的需求进行分析并明确成功指标，然后通过文字说明和流程图对解决方案进行阐述，最后才是页面设计和相关逻辑说明。
对于大的B端产品，详细方案可能需要分解给多个产品经理完成。
对于一个完整的详细方案，需要包括以下内容：
需求分析
明确成功指标
方案要点说明
方案流程
原型图
接下来我们逐个阐述。
二 、需求分析
虽然在业务调研部分，我们已经对详细需求进行过分析，但是考虑到合理的需求是成功产品的基石，另外，也考虑到需要给开发、测试等部门承诺需求的可靠性。因此，我们可以在详细方案中对需求的合理性进行阐述。
除了对重点需求的描述，我们还需要明确三点：
是不是伪需求
是不是当前版本需求
是不是个性化需求
对于伪需求，需要我们秉持“究竟精神”，多问几个为什么。另外，有一些需求可能是真需求，但价值很低，需要综合考量以评估优先级。
比如，客户可能希望在发货时，给订单对应的销售人员发送一条短信，告知订单已发货。但你可以告知客户，一条短信需要支付8分钱，客户如果明确表示不愿意支付，那么这样的需求可能就属于低价值需求了。
如果是0到1 的项目，当前版本需求是指：如果不满足这个需求，客户就无法走完整个流程，或者体验和效率存在明显缺陷。对于没有纳入当前版本的重要需求，我们也需要记录下来，便于从整体上对架构进行设计。
比如，如果我们计划将产品扩展到财务核算模块，或者与专业财务系统打通，产品架构和技术架构设计就可以提前进行准备。
如果是SaaS产品，且面对大客户，则可能需要满足一些“个性化需求”。
首先，我们必须承认，所谓个性化需求往往都是“产品能力不足”造成的。因为运营和管理本身就是个性化的，毕竟每个企业都要面对不同的内外部环境（包括政治环境），因此大部分个性化需求都是合理的。
对于个性化需求，短期来说，需要做好低耦合的设计：即将个性化的功能做成可配置，这样就不会影响其他客户的使用。长期来说，我们需要完善产品的PaaS能力。只有能满足大多数“个性化需求”的SaaS产品，才能低成本、高效率满足大客户的需求。
比如，对于个性化报表需求，短期来说，我们可以做成单独的应用，完全和其他客户的应用隔离开。长期来说，我们可以研发BI报表平台，通过配置来满足客户需求。
三、 明确成功指标
所有的B端产品或功能，都有成功指标。成功指标不但可以衡量工作成果，更重要的是，通过明确和拆分成功指标，我们可以找到让产品变得更好的方法。
比如，对于“供应商自主上传商品”的功能，如果目标是减轻运营负担和增加商品上架速度，那么“上传商品数”、“商品上传成功率”都是重要的成功指标。
如果商品上传成功率偏低，或者商品数据质量不高，我们就必须分析原因并找到改善方法。比如，如果上传的条码数据错误率很高，我们就可以在上传流程中接入第三方服务对条码进行验证。
而对于SaaS产品，“活跃用户数”是一个通用指标。不过，有时候活跃并不能反映用户粘性。比如，如果用户使用的只是“打卡”、“日报”这类相对浅显的功能，那么用户的活跃质量可能并不高。只有用户通过SaaS产品来管理核心业务，比如销售订单、发货单等，这样的活跃才是有质量的。
因此，我们可以考虑使用“核心功能使用率”、“核心单据数量”等作为成功指标。
关于SaaS产品的指标分析，可以阅读我的原创《不懂这些指标，你就做不出优秀的SaaS产品。附案例》
四、方案要点说明
B端产品虽然体现为业务流程，但是真正解决用户痛点的，可能是其中几个功能。因此，在方案要点部分，我们需要对这些功能特性进行说明，以便于大家明确产品重点，确保关键功能的研发质量。
比如，在快消品行业中，及时了解各品牌的铺货数据，对于了解行业竞争动态，以及我方铺货质量非常重要。比如在便利店冰柜中，最外面一排一共有42个位置，如果百事可乐占据了21个位置，那么它的排面占有率就达到了50%。
如果不考虑其他因素，我们可以粗略认为客户有50%的概率会购买百事可乐。在以前，一个冰柜被哪些品牌占据，以及这些品牌分别占据了多少位置，需要由业务员在门店拜访时人工识别并手工录入，工作量非常大。
而我们的SFA（销售自动化）产品则提供了图像识别功能，通过拍照就可以识别品牌和排面占有率，从而大大减轻业务员工作量。
毫无疑问，图像识别功能将是门店拜访流程中的关键功能，需要我们在详细方案中重点说明，并将“识别成功率”作为关键指标。研发和测试同学也需要对图像识别功能重点关注，并确保满足指标要求。
五、方案流程图
一般来说，如果是0到1的产品，方案流程图是必要的。但如果是后续的小迭代，方案流程图则可以省略。
好的方案流程图，应该是从角色和行为两个维度，清晰、完整的对整个业务流程进行阐述。这样不管是开发同学，还是测试同学，都能够快速对所负责的功能流程有一个清晰完整的认识。如下图：
XX公司库存盘点流程
六、原型图
原型图是产品详细方案的主体部分，也是直接决定产品研发质量的部分。因此我个人认为，对于B端产品，原型图的页面和注释应该尽可能的详细。原因有如下几点：
1. 便于梳理思路
B端产品非常强调流程和交互的逻辑性，一旦考虑不周，小则影响用户体验，大则影响正常业务，甚至导致用户投诉。
而做原型图的过程，其实就是我们梳理思路的过程。当我们把每一个新的交互都画出来，并且描述清楚相关逻辑，我们总是能发现自己的一些疏漏。
2. 便于与开发和测试协作
好的原型图，应该是方案评审以后，开发和测试都能独立完成自己的工作。我做产品经理的时候，开发和测试很少来找我沟通产品细节，就是因为他们总是能在原型图上找到答案。
这样一方面是大家的效率都很高，另一方面是，也最大程度上规避了口头沟通导致的bug。
3. 便于与其他产品经理协作
随着产品越来越大，我们难免需要把部分工作交接给其他同事，或者有新同事入职，你需要给他介绍当前的产品逻辑。如果你有一个详细的原型图，就可以减少很多不必要的沟通。
另外，我画原型图的时候，喜欢把历史版本都归集在一个原型文档，这样非常便于追溯。当然，前提是我们要做好版本更新记录，如下图是一个报表功能的版本更新记录：
七、如何培养方案能力
方案能力实际上是一种综合能力，培养的难点是架构能力和商业思维。当然，交互设计等能力也很重要，但是相对来说，这些能力培养起来相对容易得多。
关于产品经理的架构能力和商业思维，大家可以阅读我的文章：
《我的实践：如何提升B端产品架构能力》
《成熟的B端产品经理，都有这个能力》
如果我们想快速具备架构能力和商业思维，最关键的是要持续学习。包括向客户学、向对手学、向先进学和向自己学。具体学习方法，大家可以阅读我的文章：《这几个能力决定B端产品成败，你有吗？》
作者
王戴明，微信公众号：To B老人家，多年互联网产品与信息化管理经验。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
