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

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

在产品研发的层面,B端产品经理和C端产品经理的工作职责也是不一样的。

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

因此,C端产品经理需要发动大脑去想如何满足用户的衣食住行需求,并非常重视满足用户的新鲜感;而B端产品经理则要更加贴合企业实际,将客户需求转换为产品功能,提升客户的生产和办公效率,降低生产成本。

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

产品需求文档作为从需求到功能的具体实现指南,是所有开发、测试人员在产品开发过程中的必备文档。个人认为,不管是B端还是C端,产品需求文档都应该具有以下特点:结构鲜明、逻辑完整、表达准确、通俗易懂。

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

二、B端文档的撰写视角

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

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

在写了20+份文档又额外研究了十几份文档后,我总结出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端产品更加注重策略逻辑和技术性,但也要兼顾用户体验。

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

B端产品需求文档怎么写?的更多相关文章

  1. 如何写出好的PRD(产品需求文档)(转)

    作者:Cherry,2007年进入腾讯公司,一直从事互联网广告产品管理工作,目前在SNG/效果广告平台部从事效果广告的产品运营工作. PRD(Product Requirement Document, ...

  2. 产品需求文档(PRD)的写作方法之笔记一

    1.写前准备(思维导图): http://www.woshipm.com/?p=80070 1.在写之前,请先很区分清楚什么是MRD文档(市场需求文档),BRD文档(商业需求文档),什么是PRD文档( ...

  3. [转]产品需求文档(PRD)的写作

    产品需求对产品研发而言非常重要,写不好需求,后面的一切工作流程与活动都会受到影响.转载一篇文章,关于产品需求文档写作方面的,如下: 本文摘自(一个挺棒的医学方面专家):http://www.cnblo ...

  4. 产品需求文档(PRD)的写作 【转】

    产品需求文档(PRD)的写作   一.文章的摘要介绍 无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过四篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是 ...

  5. PRD产品需求文档

    什么是PRD? PRD是Product Requirement Document的英文缩写,即产品需求文档的意思.PRD昰产品流程中的最后一步工作,是将原型中的功能.界面具象化描述,是提交给设计(UI ...

  6. 产品需求文档 PRD

    第一轮: 1,文档使用方:UI设计师 2.内容:       根据战略层定义出来产品功能范围,       说明此产品的目的,方便UI设计人员更好的理解产品       产品基本流程       详细 ...

  7. app开发需求文档怎么写

    我们在开发app前都会做需求分析,这个app开发需求文档怎么写呢?一般可以从这几点入手:确定APP方案的目标,APP方案的受众分析,APP开发方案功能设计,APP的操作系统说明方案,APP是是否是原生 ...

  8. PRD产品需求文档概要

    PRD概念 PRM就是Product Requirements Document的简称,也就是产品需求模型.一般来说一个产品会伴随有市场需求文档(Market Requirements Documen ...

  9. 优质产品需求文档(PRD)写作三大原则

    在上一篇文章中有介绍,产品经理的两项主要职责包括:对产品机会进行评估,以及对开发的产品进行评估.而定义即将开发上线的产品,则需要借助产品需求文档,来进行产品的特征和功能描述.PRD文档的写作会因公司. ...

随机推荐

  1. 修改woocommerce列表产品显示数量

    WooCommerce列表产品数量默认显示为10,如果是显示3列或4列,则最后一行会有空白留出,为了美观,往往我们要设置显示合适的产品数量.因此,只要把如下代码复制到当前主题的functions.ph ...

  2. [Tkinter 教程12] 布局管理 (Pack Place Grid)

    简介: 本文讲述如何使用 tkinter 的布局管理 (被称作 layout managers 或 geometry managers). tkinter 有三种布局管理方式: pack grid p ...

  3. Python前言之Markdown使用

    一.Markdown基本语法 1.1标题 代码: # 一级标题 ## 二级标题 ### 三级标题 #### 四级标题 ##### 五级标题 ###### 六级标题 效果: 一级标题 二级标题 三级标题 ...

  4. LeetCode 654. Maximum Binary Tree最大二叉树 (C++)

    题目: Given an integer array with no duplicates. A maximum tree building on this array is defined as f ...

  5. Log-Structured Merge Tree (LSM Tree)

    一种树,适合于写多读少的场景.主要是利用了延迟更新.批量写.顺序写磁盘(磁盘sequence access比random access快). 背景 回顾数据存储的两个“极端”发展方向 加快读:加索引( ...

  6. [LeetCode] 380. Insert Delete GetRandom O(1) 常数时间内插入删除和获得随机数

    Design a data structure that supports all following operations in average O(1) time. insert(val): In ...

  7. [LeetCode] 80. Remove Duplicates from Sorted Array II 有序数组中去除重复项之二

    Given a sorted array nums, remove the duplicates in-place such that duplicates appeared at most twic ...

  8. thinkphp5.0学习(九):TP5.0视图和模板

    原文地址:http://blog.csdn.net/fight_tianer/article/details/78602711 一.视图 1.加载页面 1.继承系统控制器类 return $this- ...

  9. ASP.NET MVC 下使用支付宝支付接口 以及 ASP.NET Core 下相关改造支付

    通过nuget首先引用AopSdk.dll 包 下面写的是 Asp.Net MVC 下相关的支付接口 APP支付 配置客户端相关的参数,配置成自己的代码就可以了 private string APPI ...

  10. 实战django(一)--(你也能看懂的)注册与登录(带前端模板)

    先是具体目录:(主要是注意templates和static的位置),其中person文件夹是上一期实战的,不用理会,login是本节实战app 项目urls.py from django.contri ...