对于大的B端产品，详细方案可能需要分解给多个产品经理完成

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

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

对于大的B端产品，详细方案可能需要分解给多个产品经理完成。

对于一个完整的详细方，需要包括以下内容：

1. 需求分析
2. 明确成功指标
3. 方案要点说明
4. 方案流程
5. 原型图
6. 接下来我们逐个阐述。

二 、需求分析

虽然在业务调研部分，我们已经对详细需求进行过分析，但是考虑到合理的需求是成功产品的基石，另外，也考虑到需要给开发、测试等部门承诺需求的可靠性。因此，我们可以在详细方案中对需求的合理性进行阐述。

除了对重点需求的描述，我们还需要明确三点：

1. 是不是伪需求
2. 是不是当前版本需求
3. 是不是个性化需求

对于伪需求，需要我们秉持“究竟精神”，多问几个为什么。另外，有一些需求可能是真需求，但价值很低，需要综合考量以评估优先级。

比如，客户可能希望在发货时，给订单对应的销售人员发送一条短信，告知订单已发货。但你可以告知客户，一条短信需要支付8分钱，客户如果明确表示不愿意支付，那么这样的需求可能就属于低价值需求了。

如果是0到1 的项目，当前版本需求是指：如果不满足这个需求，客户就无法走完整个流程，或者体验和效率存在明显缺陷。对于没有纳入当前版本的重要需求，我们也需要记录下来，便于从整体上对架构进行设计。

比如，如果我们计划将产品扩展到财务核算模块，或者与专业财务系统打通，产品架构和技术架构设计就可以提前进行准备。

如果是SaaS产品，且面对大客户，则可能需要满足一些“个性化需求”。

首先，我们必须承认，所谓个性化需求往往都是“产品能力不足”造成的。因为运营和管理本身就是个性化的，毕竟每个企业都要面对不同的内外部环境（包括政治环境），因此大部分个性化需求都是合理的。

对于个性化需求，短期来说，需要做好低耦合的设计：即将个性化的功能做成可配置，这样就不会影响其他客户的使用。长期来说，我们需要完善产品的PaaS能力。只有能满足大多数“个性化需求”的SaaS产品，才能低成本、高效率满足大客户的需求。

比如，对于个性化报表需求，短期来说，我们可以做成单独的应用，完全和其他客户的应用隔离开。长期来说，我们可以研发BI报表平台，通过配置来满足客户需求。

三、 明确成功指标

所有的B端产品或功能，都有成功指标。成功指标不但可以衡量工作成果，更重要的是，通过明确和拆分成功指标，我们可以找到让产品变得更好的方法。