b端产品和c端产品差别很大，产品经理在设计产品、撰写产品需求文档时，分别侧重，b端产品注重战略逻辑和技术性，但也要考虑用户体验。

b端，或2B，一般指英语to busniss，中文是面向企业的意思。 与b端相对应的是c端，或者2C，同样是指英语的to customer，也就是面向消费者的意思。 因此，通常所说的b端产品是指面向企业的产品。 例如，企业中使用的一系列内部办公软件、内部财务结算软件、办公erp平台、支持企业数字化转型的云计算平台、大数据分析平台、AI人工智能

与此相对，c端产品是指直接面向专业大众的产品，也是直接面向消费者群体的产品。 其中，互联网app是其中的产品之一，Wechat、QQ、外卖app、淘宝、嘀嗒等都是直接面向消费者的c端互联网产品。

在产品开发层面，b端产品经理和c端产品经理的工作职责也不同。

比起c端产品更追求用户的新鲜感和体验感，b端产品更重视为客户降低生产成本，提高生产效率。

因此，c端的产品经理必须开动脑筋，考虑如何满足用户的衣食住需求，一方面非常重视满足用户的新鲜感，另一方面，b端的产品经理要结合企业的实际情况，提供客户

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

产品需求文档作为从需求到功能的具体实现指南，是所有开发、测试人员在产品开发过程中的必备文档。 个人认为，无论是b端还是c端，产品需求文档都应该具有结构清晰、逻辑完整、准确、易懂的特点。

结构鲜明：整个文档的文章结构要鲜明。 各章应有合理安排，章间关系明显。 逻辑完整性：指产品文档的内容具有较强的逻辑性。 特别是在需求背景和产品战略部分，产品经理必须回答这里有很多理由，比如为什么要做这个需求，为什么这个功能是这样的逻辑。 准确表达：就是每一个词，每一个词，甚至每一个定义都不能有歧义。 开发和测试看到这句话后，就会明白表达的意思。 不是形成各自的解读。 通俗易懂：重要性也很高，意味着产品文档的表达应该是普通的书面表达，同时要避免错误的句子。

二、B端文档的撰写视角

B端产品特有的一些性质，如资费性质/客户导向/监控和日志管理等，要求B端产品需求文档从结构上表现出这些差异。

那么，如何为具有鲜明行业特性的b端产品制定好的产品需求文档呢？

写了20个文档，再追加研究了10多个文档后，总结了b端文档在编写时应该具备的几个观点。

1. 逻辑视角

B端的产品需求文档应该重视产品战略，文档开头以后的大部分内容应该重点介绍产品的设计战略，更重要的是要明确为什么要这样做。 需求背景、产品战略和战略原因必须成为b端产品需求文档的中心，而不是像c端产品那样着重说明前端页面的设计风格。

写学术论文的朋友都知道，论文的重点是论，不是简单地介绍你做了什么。

b端产品的需求文档也是如此，明确为什么这样设计有助于后续的开发流程，特别是测试环节。

b端产品包含许多策略，包括产品本身的策略/收费策略/产品监控策略/数据处理策略等。 这些策略的规则和到期条件必须在产品要求文档中说明，而不是说明理由。

此外，这些战略必须涵盖产品的所有发生情况，包括常规流程和在异常流程中的操作方法，都必须说明，保证战略在场景覆盖中的广泛性。 其中，表是我常用的方式，多维度涵盖所有情况的应对规则。

同时，在具体罗列战略后，必须总结所有情况的战略。 这样不仅可以整理产品经理自身的思维，还可以方便后续的开发流程，保证开发节奏。

除了说明某一战略的经过外，更重要的是，文件的结构在顺序和框架方面也具有很强的逻辑性。 例如，第一节和第二节的关系是什么，写的时候必须弄清楚。

个人认为最高的排名规则是总分，根据需求背景从宏观过渡到微观的顺序更有助于开发者理解自己要做什么以及为什么要这样做。

也就是说，b端的产品要件书在说明要件的背景后，需要用适当的篇幅说明各产品战略以及战略被那样设计的理由。

2. 技术视角

B端的产品往往偏向于技术，特别是云计算、AI、大数据这些与基础技术密切相关的产品。 产品经理在制作功能时，应该考虑需求实现时的技术可行性。

此外，还需要确定实现这一需求需要何种级别的开发支持，并在产品需求文档中相应章节的内容之后标记该级别的开发人员。

同时，产品经理希望将需求级逻辑与技术实现时的逻辑在关键点进行同步。

例如，我最近做的需求之一是开始对产品的某些功能收费。 现在这个功能的服务是免费的。 在中，产品经理在创建产品需求文档时必须明确该服务的状态会发生变化

变，并在文档中对新增状态和字段进行定义。

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

代码讲究的是全面，哪怕是一个小概率发生的事件，也需要在代码中考虑，不然代码就会报错。

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

同时，测试也可以直接参照产品需求文档开始工作，而不需要自己规划测试场景和测试用例。

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

3. 客户视角

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

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

三、产品需求文档的框架

结合自己的经验，我总结出一份B端产品设计文档的大致框架，从开始到最后可以分为：背景介绍、策略介绍、前端展示和排期。

这个框架给我的感觉，有点类似学术论文的框架，二者有异曲同工之处。

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

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

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

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

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

总结

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

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

本文由@Steven 原创发布与人人都是产品经理，未经许可，禁止转载。

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