B端产品需求文档怎么写？

B端，或者2B，通常指的是英文中的 to busniss，中文即面向企业的含义。与B端相对应的，是C端，或者2C，一样指的是英文中的 to customer，即面向消费者的意思。所以，人们日常所说的B端产品，就是指面向企业的产品，好比企业中用到的一整套内部办公软件，内部财务结算软件，办公erp平台，以及帮助企业实现数字化转型的云计算平台，大数据分析平台，AI人工智能平台，这些都属于面向企业的B端产品。

而与之相对的C端产品，就是指直接面向普罗大众的产品，直接面向消费者群体。其中，互联网app即是其中的产品之一，包括微信、QQ、外卖app、淘宝、抖音等都是直接面向消费者的C端互联网产品。

在产品研发的层面，B端产品经理和C端产品经理的工做职责也是不同的。

相比起C端产品更加追求用户的新鲜感和体验感，B端产品更加注重为客户下降生产成本，提高生产效率。

所以，C端产品经理须要发动大脑去想如何知足用户的衣食住行需求，并不是常重视知足用户的新鲜感；而B端产品经理则要更加贴合企业实际，将客户需求转换为产品功能，提高客户的生产和办公效率，下降生产成本。

1、产品需求文档是什么？

产品需求文档做为从需求到功能的具体实现指南，是全部开发、测试人员在产品开发过程当中的必备文档。我的认为，不论是B端仍是C端，产品需求文档都应该具备如下特色：结构鲜明、逻辑完整、表达准确、通俗易懂。

结构鲜明：是指文档总体上要有鲜明的行文框架，每个章节都应该有其合理的布局，而且章节之间的关系显而易见。逻辑完整：是指产品文档的在内容上具备强烈的逻辑性，尤为是在需求背景和产品策略的部分，产品经理要在这里回答众多个为何，好比为何要作这个需求，为何这个功能是这样的逻辑。表达准确：是指每一句话，每个词，甚至每个定义都不该该有任何歧义，开发和测试在看到这句话以后，就知道表达的意思是什么，而不是造成各自的解读。通俗易懂：重要性也很高，是指产品文档的表达应该是普通的书面表达方式，同时要避免错句。

2、B端文档的撰写视角

B端产品特有的一些性质，好比收费性质/客户导向/监控和日志管理等，都要求B端的产品需求文档在结构上体现这些差别性。

那么，对于带有鲜明行业特性的B端产品，如何写一份好的产品需求文档？

在写了20+份文档又额外研究了十几份文档后，我总结出B端文档在撰写时应该具备的几个视角：

1. 逻辑视角

B端产品需求文档更应该重视产品策略，文档的开头及随后大部份内容都应该重点介绍产品的设计策略，更重要的是讲清楚为何要这样作。需求背景、产品策略和策略原因更应该成为B端产品需求文档的核心，而不是像C端产品重点描述前端页面上的设计样式。

写过学术论文的朋友都知道，论文的重点在于论，而不是单纯地介绍你作了什么。

B端产品需求文档也是同样，讲清楚为何这样设计，对后续的开发流程其实有很大的帮助，尤为是测试环节。

B端产品会涉及到众多策略，好比产品自己的策略/收费的策略/产品监控策略/数据处理策略，这些策略的规则和启停条件都应该在产品需求文档中进行说明，而不是简单地在后续前端页面设计中直接告诉开发人员哪些操做须要封禁而不作缘由上的解释。

同时，这些策略的要涵盖产品全部的发生状况，包括正常流程和异常流程下的操做方式，都应该予以说明，要保证策略在场景覆盖上的普遍性。在这里，表格是我比较经常使用的一种方式，经过多维度来涵盖全部状况下的对应规则。

同时，在对策略作了具体的罗列以后，更应该对全部状况下的策略进行总结。这不只仅是对产品经理自身思惟的梳理，更能够方便后续的开发流程，保证开发节奏。

除了要阐述清楚某一项策略的前因后果，更重要的，文档的结构在顺序上和框架上也要具备很强的逻辑性，好比第一节和第二节的关系是什么，都要在撰写时想清楚。

我的认为最好的排序规则是总分，根据需求背景开始逐渐由宏观过渡到微观，这样的顺序更容易帮助开发人员理解本身要作什么以及为何这么作。

总之，B端产品需求文档要在介绍完需求背景以后，须要花适当的篇幅来介绍每一项产品策略，以及策略这样设计的缘由。

2. 技术视角

B端产品每每不少状况下是偏向技术的，尤为是云计算、AI、大数据这些与底层技术紧密相关的产品。产品经理在作一项功能的时候，应该考虑需求在实现时候的技术可行性。

同时，也须要判断这个需求的实现须要哪一层开发的支持，并在产品需求文档对应章节的内容后对该层开发人员进行标记提醒。

与此同时，产品经理最好能将需求层面的逻辑和技术实现时候的逻辑在关键点上保持同步。

好比，我最近在作的一个需求，是将产品中的某一项功能开始计费。目前，这项功能的服务是处于免费状态。那么，产品经理在撰写产品需求文档的时候，就应该明确该项服务的状态量会发生改变，并在文档中对新增状态和字段进行定义。

这样一来，技术人员能够在写代码的时候直接参考需求文档中新的定义量，并根据文档中的状态启停条件设置自身代码中的if-else语句策略，是算法设计的一种参考。

代码讲究的是全面，哪怕是一个小几率发生的事件，也须要在代码中考虑，否则代码就会报错。

所以，正如策略视角中说到的，产品需求文档要在考虑正常策略流程的同时，将全部异常策略下的状况罗列清楚，这对提高开发效率也是一件有益的事情。

同时，测试也能够直接参照产品需求文档开始工做，而不须要本身规划测试场景和测试用例。

总之，从技术视角而言，产品需求文档须要罗列并考虑所有使用场景（正常+异常），并尽量的对新出现的状态和字段进行定义，并在产品需求文档中进行说明。

3. 客户视角

客户视角，并非说要把产品需求文档拿给客户去审核，而是要在需求设计时考虑客户的体验。当产品交付客户以后，使用产品的也是客户公司的员工。所以，B端产品的设计，要在知足客户降本提效需求的同时，兼顾客户员工的使用需求，在必定程度上知足用户体验。

关于用户体验上的设计，通常要在前端页面设计的部分进行展现，并告知前端开发如何操做。因为各家产品在自身页面交互设计上都有统一的流程，所以只要告知前端开发作哪种指引或者提示，并将该种提示在文档中进行说明。

3、产品需求文档的框架

结合本身的经验，我总结出一份B端产品设计文档的大体框架，从开始到最后能够分为：背景介绍、策略介绍、前端展现和排期。

这个框架给个人感受，有点相似学术论文的框架，两者有殊途同归之处。

背景介绍部分，主要介绍该需求的背景，包括需求来源、需求规划、需求预期、竞品状况、名词解释及可行性分析。这一部分中须要将该需求的前因后果说清楚，在功能上相似于论文中的introductin部分，对全文进行导读。

策略介绍部分，是整个产品需文档中最为重要的部分。要从上述的逻辑视角和技术视角进行全面的介绍，尤为是规则上的制定和其制定的缘由。好比我所从事的云计算行业，须要进行计费、服务启停、监控策略的制定，更要对产品自己各模块的策略进行介绍。这部分相似于论文的methodology部分，重点介绍方法和方法论。

前端展现部分很容易理解，主要关注功能在用户可见页面的流程和跳转操做，并对正常和异常状况下的操做方式和规则在前端页面进行说明。这就须要用到产品经理必备的UE画图能力（固然也能够将该部分交由UE同事负责）。这部分相似于论文中的results，对于策略执行后的具体表现进行说明。

而最后的排期部分，相似于论文中的appendix部分，看似多余但实则有用。该部分须要对评审时各方预估的工做量和排期进行记录，将其做为该项目管理的一个指标或者参考。

在云计算产品的设计流程中，有时候还会涉及到API或者SDK的设计，须要产品经理对该接口的名称和参数进行定义，以后交由开发同窗开发。

总结

总之，B端产品和C端产品的差别性较大，产品经理在设计产品和撰写产品需求文档时，要分别有所侧重，且B端产品更加注重策略逻辑和技术性，但也要兼顾用户体验。

其实写任何东西都是思惟输出的过程，形式是次要的，重要的是要将思惟梳理清楚并将其转化为文字，同时要让看的人明白本身要作什么以及为何要这样作。