产品需求分析：从用户到需求文档的历练

产品定位

这是产品设计的方向，也是需求文档和设计产出的判断标准。此外，产品定位也是团队成员形成统一的目标和对产品的认识，提高团队的凝聚力和工作效率，可以这么说，产品定位是需求中的需求。

那什么是产品定位呢？

一些产品经理和设计师沟通时候，往往会把功能、业务逻辑梳理得很清楚，但却忘记了把产品主要面向对象、他们的使用场景如何，还有产品的功能、特色等也说清楚，这就会导致设计师很难做决策。

这里可以看出，产品定位实际上就是关于产品的目标，范围、特征等约束条件，主要包括两个方面的内容：产品定义和用户需求。

产品定义由PM得出，用户需求由UED得出，但这一般只出现在大型项目or有充足团队配置的情况中，实战案例更多是PM一手操办，Orz，三头六臂的哪（P）吒（M）啊。

其中产品定义中的主要功能、产品特色和用户需求中的目标用户形成了产品定位中最核心的内容，是产品设计最主要的依据和方向。

产品定义

产品定义就是用一句话概括某个产品，一般可以这么说：

该产品主要面向XX用户提供XX功能，具有XX特色。

这里可能会有疑问，对于一些全用户的产品例如***、淘宝怎样准确描述呢？这其实有个小小的误区，对于这些发展历程已久，业务迭代升级变化较大的产品，现在的意识形态早已不是当初的样子。***当初不就是想取代手机短信的功能吗。所以产品定义也是会升级迭代的。

如果你的产品很难用一句话描述清楚，要么就是定位不清晰、方向不明确，要么你正在做的是类似***一样的超级产品，企图连接一切。而对于创业者来说，连自己都无法流利简洁描述你的产品，那么跟着混的兄弟似乎就要对这个leader多一点存疑了。

举个栗子：陌陌

使用人群：80后、90后单身人群

主要功能：发展基于地理位置的陌生关系

产品特色：LBS搜索用户和群组

有了产品定义之后，可以迫使产品经理努力思考产品的方向和机会，在竞争中寻找差异化，也限定大致的范围，让团队不至于茫然。

用户需求

用户需求就是在具体场景中，目标用户的目标事件。根据一定方法（头脑风暴、调研访谈等），可以得出用户需求示意列表。

值得注意的是，用户类型不是绝对的互斥和独立，更多是以主要取向为区分标准，这不影响后面的筛选和匹配。

其中目标用户是最为关键的，明确目标人群可以使你更专注于服务某一类特定人群，这样更容易提升这类人群的满意度，也更容易使产品做到差异化和成功。

产品是给用户用的，钱也是用户掏的。选择哪种类型的用户作为目标用户，需要综合权衡用户对公司的价值和潜在用户量。

通常会优先考虑最右上角的用户（潜在量大，价值高）。

确定目标用户类型后，就可以筛选匹配出相应的场景和需求。整个过程包含大量思考和决策，因此产品经理需要做足准备工作，包括：了解市场调研结果（趋势、相关联行业或者产品的态势）、了解市场上同类产品的情况（竞品分析）、了解潜在用户的基本情况、了解公司、团队的优势和劣势等等。

需求来源

确定产品定位之后，然后通过不同的方式来收集大量的需求，然后根据这些需求的有效性和真实性、产品定位和项目资源情况进行筛选和匹配，提炼出产品需求，定义出优先级。从产品定位到需求优先级，整个过程不仅涉及对用户的分析和理解，还包括了对产品定位、项目资源的考虑。

需求来源可以大致分为以下几种，其中竞品分析、产品数据、用研是从产品层提出，老板敏锐的眼光则是“人为”思考的结果。

通过五花八门的渠道收集到一堆需求之后，不可能全部都能做，需要按照一定规则和流程，筛选出来最有价值的需求，将有限的投入产出最大化。

其中有一个较重要的环节，也是考验PM能力的地方，透过现象看本质，挖掘用户的真实需求（有个经典的故事：汽车之父亨利·福特曾有一个经典的句子：“如果我问客户他们想要什么，他们总是说想要更快的马。

这里谨记两条：

倾听用户不等于听从用户

用户想要什么不等于真实需求

需求文档

经历完需求筛选和优先级定义之后，通常可以得到需求列表，负责各个功能的产品经理就可以领任务去写PRD了（对于一般更新迭代的需求，可能筛选完之后只有一两条需求，优先级都不需要定义，就可以直接开写了）。

下面是标准需求文档的内容示例：

① 文档备案：包括文档日期、版本号、修改人、修改内容和审核人等信息，一般以表格形式位于文档开头。

② 目录：方便阅读

③ 背景描述：为什么要做这个产品/模块，市场行情，业务目标，产品定位等

④ 用户类型：简单地描述目标用户的情况

⑤ 项目时间安排：启动、结束等时间节点

⑥ 信息结构：简单理解为内容和页面的层级

⑦ 业务流程说明：以流程图形式说明业务各个状态间的切换逻辑（例如：游戏服务器满人时候需要切换到排队登录状态）

⑧ 需求详细说明：每一条需求的详细说明（包括：使用场景、UI描述、功能描述、优先级、输入/输出条件、处理流程、补充说明等）

⑨ 涉及关联业务部门的支持，还需要特别备忘。

如同设计稿，代码一样，需求文档很难一次成型，需要不断修改，在评审中发现问题是很正常的。

需求分析广义上看包括了需求获取和分析筛选两个方面。产品定位是确定产品需求的根本依据，而目标用户则是产品定位的标尺。要想得到正确的需求，PM需要全程参与，充分准备，深入到各个关节中，并且充分听取不同成员的意见。

上述方法论是标准化流程，实战运用，不同公司不同项目会有更接地气的一套过程，本文谨对新人作分享和启发之用。需求文档的撰写同理，引用在京东实习时候，曾经就PRD模版和导师有关一些讨论，最后导师给出的意见是：根据需求和进度来灵活变通，切勿迷恋所谓模版。尤其移动互联网时代。仅以此话与诸君分享。

网上搜集的一些资料  和大家分享