产品经理文档之PRD

1. 产品经理文档之PRD

PRD：产品需求文档，全称是Product Requirement Document，是产品文档中最底层最细致的文档。文档侧重对产品功能和性能的说明，主要是把产品规划与设计中的产品流程，界面，功能等定义向研发、设计、测试等团队做清晰的描述说明。
  
 1、帮助团队存档产品信息
  
 产品实现过程中，有很多的逻辑、算法需求，没有文档的记录，容易在团队变更、交接班的时候出现较大风险。通过产品需求文档记录产品的各种需求与实现方式，能有效降低团队的风险，同时也能提高交接效率。
  
 2、提升内部信息沟通的效率
  
 虽然需求可以口述，但是不代表说一次全员就都能记得，会遇到开发、设计或测试记不清楚的地方，可以直接查看文档。结构明确、表达清晰的文档仍然有不可取代的作用。
  
 3、产品工作有据可查
  
 各方需求理解不一致，或延期产品工作的时候，通过产品需求文档都可以有效的找到问题根源。
  
 研发人员：由于研发人员本身专注于功能的实现与性能，所以他们相对于其他岗位比如运营，时长，设计等，表现相对不太关系，对于产品更多地了解来自于产品经理的产品宣讲。
  
 设计人员：设计人员本身更多的会关注产品的表现形式与原型，所以对PRD的需求是相对较弱的。
  
 还有老板、项目经理、运营、市场、客户、财务……
  
 所以，PRD文档，根据阅读对象，可以用最平铺直叙的话，把产品描述清楚就行。
  
  文字模式 ：Word。时间较为充裕的或岗位责任制分明，有文档要求规范的团队，建议选择Word撰写文档。
  
  原型图模式 ：Axure。追求时间效率灵活性的团队，建议选择Axure撰写文档，原型搭配产品说明，无需切换，只用一个文件就可，方便快捷。
                                          
 无论哪种方式，都是大同小异，本质上并不影响PRD文档的使用效果。
                                          
 1、修订记录：版本号、修订日期、修订章节、修订内容、修订人等。
  
  版本号说明，以1.25举例： 
  
   版本号（ 1 .25）：重大调整升级，一般是产品结构功能等有调度。
  
   子版本号（1. 2 5）：在原有基础上对局部功能进行了升级或调整。
  
   修正版本号（1.2 5 ）：局部小范围优化与Bug修复，一般是不动功能性的东西。
  
  版本号的命名规则： 
  
 归零原则：前一个数字增加一位，后面的数字都归零。
  
  修订记录的作用： 
  
   对修改前后进行比较
  
   有利于维护和管理PRD
  
   记录修订人和修订日期
  
   方便查询，可以只看修订部分，快速查找变更之处
  
 2、名词术语：将一些产品里面不易理解，容易混淆，或者缩写的词汇在开篇进行统一的列表说明，有利于阅读。
  
 全局说明包括：权限说明、授权说明、异常情况、键盘说明等。
  
 权限说明：对角色权限进行划分，例如登录和未登录状态下可访问的功能权限。
  
 授权说明：手机号授权、地理位置授权、相册授权等。
  
 异常情况：加载失败、网络异常等。
  
 键盘说明：数字键盘、字母键盘。
  
  ...... 
  
 1、产品结构：包括产品功能结构图、信息结构图。
  
 2、业务流程图：通过用户行为串联信息结构和产品结构，可以更好的理解产品经理设计的用户行为。
  
 3、功能清单：清单包括功能模块、功能点、功能描述等。
  
 4、功能详情：原型设计、功能说明和用例。
  
 功能详情的表述顺序可以按照功能的逻辑来表述，或按照产品结构来表述，具体可以看个人习惯和团队要求。
  
 用例：用例图和用例说明。用例图表述的是系统的外部参与者与系统之间的关系，是由参与者与用例组成的示意图。
                                          
 注意：
  
   撰写前要保证思考到位，产品结构本身短期内不会有重大改动。这样即便是在交付后，出现调整或需要优化的地方，也不会出现重构的情况。
  
   文档中用词用语一致，对于同一事物的表述应该一样，避免混用。
  
 非功能性需求是对产品非功能性需求的说明，包括性能需求、技术组件需求、安全性需求、可用性需求、质量需求等。
  
 性能需求：系统满足多用户同时工作，保障同时在线用户五千人，并发操作一千人的使用需求。
  
 技术组件需求：数据存储及计算使用星环大数据平台等。
  
 安全性需求：涉及外网环境的需保证数据网络架构上保证数据的传输安全、具备良好的跨平台部署能力等。
  
 可用性需求：系统支持IE11并向下兼容，支持Chrome等主流浏览器。
  
 质量需求 ...... 
  
 上面的文档结构只是PRD的基本结构，并没有成为固定的可以供套用的东西，文章只是一种思路的分享，具体还是要根据自己公司及团队的习惯和达到你的目的为依据来进行调整，切勿生搬硬套。
  
  阅读原文 
  
 对产品经理感兴趣的朋友，可以移步“ 行业与市场分析 ”，期待共同交流。

2. 产品经理的PRD到底该怎么写

PRD（Product-Requirement-Document，产品需求文档），写作目录如下：
1、文件命名（编号）
文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代。
2、修订控制页
一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。
3、目录
4、请与以下部门讨论PRD
PRD作为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”，这对于产品整体流程将是很重要的。
5、概述
概念就是总结，它包括的点有：名词说明、产品概述及目标、产品roadmap、产品风险。
6、使用者需求
使用者需求一般只有个需求描述。需求描述有以下几项内容：目标客户、需求描述、场景描述、优先级。
7、可选方案
列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案。
8、效益成本分析
产品经理是个全才，在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面：效益预测、产品技术中心成本、非产品技术中心支持成本。
9、功能需求
功能需求一般是由四部分组成，功能总览、功能详情、整合需求、BETA测试需求。
10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上，利用公司现有的资源或外部资源（合作公司等）实现产品功能需求的整合。
11、BETA测试需求
很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。
12、非功能性需求
都说产品经理是全才，在这点上得到彻底的体现。很多产品经理在这点上忽视了，但很多方面使用到的，只是在产品过程中弱化了。
13、上、下线需求
上线时限需求：此产品预定上线日期？上线日期有无任何特殊依据或规定？
下线需求（活动类需求必须明确下线时间）：此产品预定下线日期？下线日期有无任何特殊依据或规定？
14、运营计划
说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。
……
写PRD并不是产品经理的全部工作，但却是不可少的一部分，很大程度上反应了产品经理的思维和产品核心功能把握上，同时对产品经理沟通、协调、规划等
想学习更多PRD文档写作方式，可以来官网学习

3. 产品经理需要写MRD吗

产品经理需要写MRD吗
Market Requirements Document,简称市场需求文档。市场需求文档的主要功能是描述什么样的功能和特点的产品（包含产品版本）可以在市场上取得成功。产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现 商业目的，功能/非功能需求分哪几块，功能的优先级等等。

一般来说，我们最常见的PRD是在MRD的基础上产出的，当然，产出PRD还需要原型、思维导图还有Feature List之类一堆东西的辅助。

作为产品经理，我参与过好几个项目，从大公司到小公司，产品经理的角色，一直都在实际上处于很尴尬的位置。上周末的UCD广州年会，帽子男发问“能够参加自己公司核心战略会议的请举手”----会场上举手者寥寥无几。关键，白鸦问的是“参加”而不是“参与到”，如果问的是后者，估计人就更少了。

产品经理这一概念，在05～07年产品的理念刚刚插入中国互联网时，是很火热很强势的。产品经理的角色定位通常都是公司总裁或者副总裁的直属员工，管理的产品部门属于公司的直属部门，会参与到公司整个市场分析、战略、决策、运营、推广等各方面中去；那个时候，MRD是属于产品经理的重点工作之一，尤其那个时候的大部分产品经理都是由市场转型过去的。

最近几年，产品的概念在中国互联网开始深化。一方面，产品经理慢慢退出公司战略与决策部门，取而代之的是通过数据研究去知道决策的UED部门（初期这个也是产品经理的工作之一）；另外一方面，产品经理的更多精力也开始投放在产品细节上，并且与UED 部门进行协作式产出PRD文档；当然，还有一个不好的方面，当产品的概念泛滥以后，部分PD、前端甚至美工也开始自称产品经理，这些“产品经理”自然无权写MRD了。

有些朋友告诉我，他们公司是把MRD合并在PRD里面一个文档完成的。我想，这是不是有点多此一举的味道在，一般来说，PRD 文档是交付给开发部门的文档，MRD写在里面，第一方面是没人看，第二方面是你写那么多东西给到下面开发部门，他们根本就看不懂（或者根本不愿意去看懂）。产品和开发从来就是一个不可调和的矛盾体，有些是运营做调解有些是根本就是产品部门去直接对接。妄想以MRD去告诉开发部门哪些功能非常重要切勿删掉还不如直接在PRD上以红色粗体说明更有意义（just kidding，我很多时候是真的想这么做的）。

4. 产品经理文档之BRD

阅读原文 
  
 BRD：商业需求文档，全称为Business Requirements Document，是产品生命周期中最早的文档，是基于商业目标或价值所描述的产品需求内容报告。其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。其内容涉及市场分析，销售策略，盈利预测等。它通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。
  
 当我们产生一些好想法，或者想到一个好的产品解决方案，或者想去开发一个App，想做一个网站，当遇到这样的场景，我们要做的第一件事情，不是马上行动，而是去分析这个事情，梳理思路，进行大量的考察和调研，前景展望以及它涉及到的资源如何使用，用在哪，获取什么样的收益和风险评估等，将之用系统的思路和语言表达出来，这就是商业需求文档（BRD）。创业者对应的是商业计划书（BP）。
  
 对撰写者来说，BRD可以推动产品的项目立项，获得企业高层的认可，从而为接下来的行动争取充足的资源，这些资源包括资金、场地、软件、硬件、运营等。
  
 BRD就是要向企业高层传达我们的产品很重要，希望得到支持，我们的需求是有价值的，希望获得重视，希望决策层协调资源，顺利推进进行。
  
 对企业高层来说，BRD是他们决策的依据。
  
 在撰写BRD文档后，面临如下受众群体：
  
  资本型： 一般是首席财务官（CFO）、财务总监。他们能够为我们提供充足的产品研发和推广经费。他们关注的有：投入产出比（ROI）、收益预测、营收增长率等。而且其实很多的项目在初期通常不大可能获得很大的利益，这就需要在BRD中体现出长远的收益预测。
  
  市场型： 一般是市场总监、运营总监。他们能为我们提供完善的运营资源。他们关注的有：外部环境（行业环境、市场环境和政策环境）、推广渠道、竞争对手、市场空间、营销资源等。
  
 外部环境是怎么样的，例如互联网金融刚开始的时候政府是没有相关政策的，没有相关政策就导致有很大的不确定性，导致监管一出台，很多平台倒闭；推广渠道是否成熟与营销工作是否容易开展相关；竞争对手和市场空间就是要看我们有多大的市场蛋糕可以吃，值不值得去做。
  
  研发型 ：一般是首席技术官（CTO）。他们能为我们提供充足的技术资源。他们关注的有：功能模块，技术难度等。对于这块，可以尽量简化表达，让CTO充分理解想做的项目是什么样的，功能模块、架构设计是什么就可以。
    
  因此，我们首先要确定这份文档是给谁看的，确定后就可以定下BRD报告大纲，  然后充分论述报告  的各方面侧重要点。 
  
 BRD主要使用Word或PPT进行撰写和展示，推荐使用PPT，图文并茂，便于演示。
  
 
  
                                          
   市场规模和潜力：宏观的行业趋势分析，对市场未来的判断，包括未来市场竞争格局，行业的风险，政策的变化，行业的发展方向等，这部分最好用数据进行分析，备注数据来源（可以是上市公司财报，艾瑞咨询，知名网站的采访文章等）。微观细分市场，包括对目标市场进行市场细分，确定目标市场和目标用户，以及现有市场规模的大小等。
  
   外部政策：国家的政策是否支持，国家和各个城市的政策是什么样的。例如共享单车的政策、网约车每个城市的政策不同，互联网金融从政策空白到政策的逐步收紧和规范。
  
   市场推广渠道：本公司掌握的渠道是否能支撑产品的推广，是否需要扩宽和增加渠道，市场能否有大概的措施进行推广。
  
   竞品分析：潜在竞品是什么，竞品的投入、产出是什么样，与我们对比，我们的优势和劣势是什么。
  
   用户在当前市场产品中的需求是否已经得到了满足，满足了哪些需求，哪些还没有满足，以及还可以再深度挖掘哪部分用户还没有表达出的需求。
  
   用户的这部分未满足的需求或者未表达出的需求，是否迫切，是否强烈，问题出现的频率是否频繁。
  
  综上得出可行性结论：要做一个什么样的产品。 
  
   我们将得到什么好处，包括经济类和非经济类，非经济类例如：带来用户，扩大市场，占有市场先机，满足未来三年战略规划等。
  
   提出预测：达到某一阶段目标及对应得到的好处。
  
  （1）产品介绍 ：清晰定义产品，说明要做一个什么样的产品。
  
   产品作用：解决了用户的哪些问题，填补了市场哪部分空白。
  
   产品定位：
  
 产品形态：简短说明要做一个什么样的产品，这个产品架构大概是什么样的，是资讯形态还是社交形态等。
  
 业务模式：说明产品是面向B端还是面向C端，还是B端和C端兼容的，以及参与者分别是谁，如何形成闭环等。
  
 运营模式：采用什么样的运营策略和手段让产品运营起来，如线上推广方式、线下地推等。
  
   产品愿景：讲产品商业价值具体化，设定产品目标的基本要求是可实现、可衡量。
  
  （2）核心功能 ：产品的核心功能是什么。
  
  （3）阶段规划： 产品发展路线是什么，以及每个阶段大致达到的目标。
  
        第一阶段，从XX到XX时间段，先用核心功能点的方式验证用户需求；
  
        第二阶段，从XX到XX时间段，完成产品，扩大用户规模到什么程度；
  
         ...... 
  
  在产品规划阶段，尽量不要有太多关于产品形态细节的东西，产品形态可以粗放一点，方案获得认可后，根据汇总意见，再来做产品具体的东西。
   
  
 描述清楚这个产品通过什么方式来赚钱，做企业的目的是为了赚钱，即使是财大气粗的公司也会考虑这个问题。
  
 （1）盈利方式包括收入的来源和渠道，例如广告，增值服务，出售商品等。
  
 （2）如何才能达到收支平衡，产品的收益增长率是怎样的。
  
  （1）成本预估 
  
 人力成本
  
 推广成本
  
 技术成本
  
 其他成本：如硬件设施、场地等
  
  （2）收益预估 ：根据产品的盈利方式进行预估。如前文中提到的，利，可以是直接的经济收入，也可以是有利于企业的一些客观条件，如带来用户，提高市场占有率等。
  
 风险是指有可能影响产品目标实现，或增加产品成本的行为和因素，在考虑风险的时候，我们不仅要对所有可能出现的风险进行评估，确定风险出现的可能性和严重性，而且要给出对应的规避预案，并明确预案的规避效益。
  
  （1）风险种类： 
  
   市场风险
  
   政策风险
  
   行业风险
  
   经济风险
  
   资本风险
  
   公司风险
  
   技术风险
  
      ...... 
  
  （2）应对办法 
  
   规避
  
   接受
  
   降低
  
   分担
  
   转移
  
     ...... 
  
 在BRD文档中要少关注产品细节，多关注产品商业价值、收入与成本、风险与对策部分。描述过程中要言简意赅，不要使用过多的专业术语，尽量通俗易懂，最好用图表演示，一图胜千言。
  
 文档是用来说服领导并且争取资源的，不是来做工作汇报的，语言要有逻辑，理论要有支撑。
  
 文档重要的目的是辅助你达到自己的目的，上面讲的文档结构，并不是标准的格式，只是一种思路的分享，你可以根据自己的情况进行优化调整，结合当下的特性环境来思考问题，切勿生搬硬套。
  
 对产品经理感兴趣的朋友，可以移步“ 如何自学产品 ”，期待共同交流。

5. 产品需求文档（PRD）

产品需求文档（PRD），是产品经理的工作中非常重要的一份文档，如果能写的好，对于产品的落地是非常有帮助的。关于产品需求文档，可以按照这种方式去写，当然形式不重要，无论是Word、Excel、PPT、还是Axure，关键是怎么样更好的给这份文档的目标用户看，产生价值。接下来是个人的一点愚见，还会持续更新。
                                          
 产品需求说明书文档的简介应提供整个文档的概述。它应包括此产品需求说明书文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。
  
 主要介绍产品的目标用户角色，包含前后端用户、各种平台、运营人员等等。还有他们的相关描述，如果可以的话，可以进行用户画像的描述。
  
 主要是高度概括产品的功能与介绍。
  
 列出产品的特性。特性是为让用户获益而必须具备的高级系统功能。每一项特性都是外部所需的服务，它通常需要一系列输入来实现预期的结果。
  
 此节为设计的系统功能性需求, 一般以用例结合自然语言来表达。此节通常按特性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。
  
 这一节应包含所有的产品需求，其详细程度应使架构设计人员和软件需求设计人员能够设计出可以满足这些需求的系统，不包括可选流程和异常流程，不对具体语义做约束。
  
 从业务视角提出各项可用性指标的大致需求。具体的技术指标会体现在产品的设计文档中（根据项目实际情况增删）
  
 风险内容描述，说明风险产生原因，可能造成的危害以及相应出现的频率信息，另外在此处还需要描述相关风险预防措施及风险出现后的应对措施信息。此处不包括任何系统技术实现层面的风险，例如：系统的备份，监控，模块依赖等。
  
 产品所需的其余相关文档，如：产品市场需求说明书（MRD）、产品功能介绍PPT、产品规划书。
  
 将产品需求的demo作为附件，可以是原型图或者产品手稿等。

6. 做产品一定要需求说明文档（PRD）吗？

 其实在我刚入行做产品时和大多数新人一样，遇到最大的一个问题就是「怎么写需求说明文档？」，而现在做了一年多之后回过头来看，这个问题的答案仍然是「需要」，但我所理解的「需求说明文档」和传统意义上的可能不太一样。
    先来说说我们团队现在的配置： 
   除了运营之外我们就只是一个不足10人的产品研发团队，体量太小，如果是用标准的 PRD 来进行需求沟通，那太慢了，而且维护成本太高，大部分时候 PRD 并没有起到沟通的作用，在产品的起步阶段我写了上万字的 PRD 结果却没有一个工程师认真的看，在这种情况下 PRD 反倒成了累赘。
    PRD 的核心作用无非就是以下几点： 
    而在大公司可能还有其他作用： 
   总的来说 PRD 的作用是减少团队沟通成本，但值得注意的是，PRD 只是需求沟通的一种形式，而不是目标，产品经理的目标应该是提供满足需求的功能和推动功能的实现，其实大部分产品经理没必要写需求文档去表述功能，尤其是在人数较少的创业团队，只要能让所有人理解需求功能点，具体是怎样一种表现形式又有什么关系呢。
    简单说一下目前我们团队开发的基本流程： 
   可能我们团队有些特殊，我和 UI 设计师异常默契，有时候甚至连手稿都不需要他就能完全把我想要的交互画出来，大大减少了画原型的时间；而前端工程师经验丰富，交互基本都是通过口头沟通对方即可理解，即使有什么遗漏的扭头喊一声我就马上跪倒在其面前进行讲解；测试用例近期也在进行迭代，不再使用传统的格式「功能点、用例说明、用例编号、前置条件、测试步骤、预期结果、测试结果、失败原因」，而是用思维导图一句话表达即可，所以总的来说我需要产出的文档就只有「后端功能逻辑」和「测试用例」，对于需要快速开发上线的小团队来说，面对面沟通显然好过文档（关于这点当初我和 Leader 产生了分歧甚至因此大吵过一架）。
   但需要注意的是这种模式并不适用于所有团队，规范有规范的好处，随着团队的人数扩张，产品页面数量越来越多，业务逻辑越来越复杂时，一份相对规范的文档能够帮助你理清思路，只靠单纯地沟通，会显得吃力且容易遗漏。
   所以关于是否一定要写 PRD 这一问题的答案并无绝对，需根据团队实际情况以及产品经理的习惯，找出最适合你们的沟通方式即可，至于是用 Word 还是 PowerPoint 甚至是 Excel 都可以，而我则更喜欢用 Markdown 编辑器，毕竟能有效地传达需求给对应的人员并确保对需求的理解一致才是根本目的，没必要拘泥于形式。

7. 产品经理必备文档之【MRD市场需求文档】

一、简述 
  
  
   
  
 1、MRD概念：何种产品功能满足市场需求
  
 2、主要内容：市场分析、目标用户分析、产品需求概述、功能分析、产品需求优先级
  
 3、使用对象：产品、运营、研发
  
 4、商讨内容：怎么做、做什么、什么时候做
  
 5、MRD BRD PRD 三者之间的关系
  
 BRD：生命周期第一个文档，包含市场分析、销售策略、盈利预测；战略上给老板们看的需求文档，一般用PPT 形式展现，维度较高
  
 PRD：传统意义上的需求文档，主要内容功能使用的具体描述，接地气
  
 从流程上来看：（论题）先BRD（决策） 再有（论点）MRD（如何开始一款款产品） 最后(论据)PRD （怎么实现）
  
   
  
  二、框架 
  
  
   
                                          
   
  
 1、构成
  
  文档说明、市场分析、用户分析、竞品分析、产品分析 （主要有四个维度）
  
 记法：第一步，先知道市场行情什么样
  
 第二步，用户是否买账
  
 第三步，市场竞争激烈，受到冲击，优劣势
  
 第四步，产品做成什么样
  
 2、详细剖析
  
  文档说明： 
  
   
  
 1、基本信息：产品需求名称、文档创建日期、创建人、部门职位
  
 2、版本修改记录 ：日期、版本、修改人、修改内容、备注
  
  市场分析： 
  
   
  
 市场问题现状、目标市场分析、市场分析结论
  
 1、市场问题现状：有问题才有机会
  
 市场问题现状包括但不限于以下几点：用户、产品、技术、运营、商业模式
  
 2、目标市场分析：选择最优可趁之机的市场
  
 例：互联网金融细分市场：车贷、房贷、旅游贷、基金等等
  
 3、目标市场分析：市场规模、发展趋势、分析结论
    
 发展趋势：现在及未来发展情况，包括行业政策
  
 分析结论：带来收益，把握多大，可能性多大
  
  案例分享：市场问题现状直播行业 
  
   
  
 1、乱象打击
  
 2017年1月国家相关部门严查违规直播平台，9万个直播间被关闭，超过3万个主播账号被封禁
  
 2、直播行业洗牌
  
 估值5亿光圈直播倒下
  
 直播行业排行榜：前15，虎牙、yy、斗鱼、映客、触手、熊猫、虎牙等等
  
 主要三类：秀场、社交、游戏
  
 3、商业化成为关键
  
 盈利模式：打赏
  
 同时探索新的盈利模式
  
 4、市场规模
  
 体育直播市场，国务院46号文公布后，体育产业上升到国家战略，2015年中国体育产业达5万亿的目标。据易凯资本估算，2016年体育市场规模为1.5万亿，其中观赏性体育市场规模2895亿元，体量十分可关。
  
 5、市场特征
  
 2014年赛事转播权开发后，涌入以乐视为代表的新媒体，央视垄断的局势逐渐被打破。资本一拥而上，腰部，尾部版权的交易成本水涨船高。
  
 解说员到弹幕，拉近用户的距离，加强用户参与感，行程较为活跃的即时社区气氛。
  
 6、发展趋势
  
 国家政策鼓励，体育产业是少有的朝阳行业。付费观看便于行程用户习惯，加强互动，提供个性化、专业化、娱乐化的观赏体验是行业的发展方向。
  
 7、结论
  
 直播行业头部格局确定，巨头难以撼动
  
 细分领域成为直播行业的新突破口
  
 体育直播市场潜力巨大，符合国家发展战略
  
 赛事版权成为体育直播核心资源
  
 可以与游戏娱乐金融影视结合，商业模式想象空间较大
  
  用户分析 
  
   
  
 1、目标用户群体：年龄、性别/地域/地域、经济条件、生活习惯
  
 2、用户画像构建：粗细得当，群体代表
  
 两个维度：
  
 用户信息（年龄性别收入职业居住地）
  
 用户特征（性格爱好技能习惯）
  
 案例：金融行业用户画像
  
 张三男28 已婚 有子女 运营经理
  
 工作忙，喜欢看电影，打球，摄影，旅游
  
 喜欢股票，常关注东方财富新浪财经，习惯用信用卡支付宝等
  
 喜得贵子，生活压力大，支出多
  
 希望活取活用，资金安全高，收益大于储蓄
  
 3、用户使用场景：用户在某个环境中完成某个任务的故事
  
 案例：张三和朋友聊天，说用钱地方多，但股市萎靡，朋友推荐理财app，决定晚上看看
  
 4、用户的动机和目标
  
 表面和本质
  
 如吃米线：表面想吃米线，实际饿了
  
   
  
  竞品分析 
  
   
  
 1、竞品对象：找准找全，不要把眼光局限在同行中，不要局限在互联网行业
  
 案例：摩拜单车
  
 直接竞争对手：ofo小蓝
  
 间接竞争对手：滴滴 神州
  
 2、竞品基本情况
  
 背景历史、市场现状、目标用户、运作商业模式、运营推广策略
  
 3、竞品优缺点分析
  
 优点是否能继承、缺点是否能规避
  
   
  
  产品分析 
  
  主要包含六部分：产品定位、产品核心目标、产品结构、产品路线图、产品功能性需求、产品功能性需求 
  
   
  
 （1）产品定位：于BRD一致，一句话描述产品是干什么的，满足用户什么需求
  
 案例：陌陌，一款基于地理位置的移动社交工具
  
 摩拜：一款互联网短途骑行工具
  
 （2）产品核心目标：明确工作优先级，不迷失不盲目
  
 案例：WiFi万能钥匙，帮助用户免费并成功连接WiFi
  
 （3）产品结构：需要哪些物料准备
  
 案例：电商，商家、商品、订单、库存、物流、客服（桥梁）
  
 （4）产品路线图：以任务为导向的时间节点。（甘特、泳道、表格roadmap）
  
 （5）产品功能性需求：产品自身的功能，MRD只做功能罗列，不讲具体解决方案
  
 案例：电商，注册登录、搜索商品店铺、商品展示、收藏购物车、充值支付、客服售后、物流查看、订单查看
  
 （6）产品非功能性需求：用户看不到的需求，或者不是产品团队提出的
  
 性能需求：几万人同时在线，服务器稳定
  
 安全需求：支付环境保证安全
  
 扩展性需求：未来产品设计
  
 兼容性需求：兼容多大市场，苹果 iOS对应不同版本，4.0 5.0 等
  
 运营市场需求：提供埋点、数据支持
  
  三．MRD撰写注意事项 
  
 1、不一定要写MRD
  
 2、BRD 给老板和投资人汇报，MRD 可能被省略，PRD沟通一线
  
 3、MRD 一般是由高级产品经理、产品总监
  
 4、MRD重点内容：目标市场分析、目标用户分析、竞品优缺点分析、产品功能性需求
  
 5、MRD 主要论证要做什么，为什么要做
  
 6、MRD需要写多少，建议使用PPT，突出重点

8. 作为产品经理，BRD,MRD,PRD,FSD 你写过几个？

BRD, Business Requirements Document(商业需求文档)，是产品生命周期中最早的文档，内容涉及市场分析，销售策略，盈利预测等，通常是给Boss演示的PPT，短小精悍，没有产品细节。
  
  
 它的重点放在定义项目的商业需求上。BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。它也可能包含一个高级的商业案例，例如营收预期，市场竞争分析和销售策略。
  
 BRD一般是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写。在小型公司，可能由高级主管或者创始人撰写。一般情况下，BRD是一份连续的1~3页的word,或者小于10页的PPT文档。
  
 
  
                                          
 BRD被老大们认同后，在产品进入实施阶段前，需要先出一份MRD，具体点说，就是要有细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等，实际工作中，这个阶段可能产出的是思维导图，excel的feature list等
  
 MRD重点应该放在为一个被提议的新产品或者现有产品的改进定义市场需求。与BRD提出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节。
  
 这些细节：
  
 1. 解决这些商业问题所需要的特色
  
 2. 市场竞争分析
  
 3. 功能和非功能需求
  
 4. 特色/需求的优先级
  
 
  
                                          
 
  
  
 MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写。通常是一份连续5~25页word文档甚至更长。
  
 这就是我们传统意义桑德需求分析，主要是功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块）,Visio做的功能点业务流程，界面的说明，demo等。可能用dreamweaver,ps甚至画板简单画一下，有时候会有UI/UE支持，出高保真的demo,开发将来可以直接用的那种。
  
 PRD重点放在为一个被提议的新产品或者现有产品的改进鼎益市场需求。与MRD侧重于从市场需要角度看需求不同。PRD侧重于从产品本身角度看需求。
  
 FSD有点儿像"概要设计"，这步就开始往开发先接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。FSD把焦点集中在实现，定义产品功能需求的全部细节。FSD可能通过一张张的截屏和一条条功能点来定义产品规格。FSD把重点放在了以表格形式定义产品细节，再让工程师实现。它也可能包含了完整的屏幕截图和UI设计细节。
  
 FSD通常是由拥有产品分析师，工程领导一起撰写的。通常是一份连续10页左右的word或类似文档。