需求产品管理

Uifhjvv

需求产品管理是对产品需求的统一规范的管理，是保障整个需求的生命周期从出生、成长、维护或下线 流程化的管理，是产品快速迭代所必须做的工作。

1 Z5 v. q5 U9 _2 R( F$ b

对于产品需求主要归纳为下面这两类,而这在产品管理的方式上也会大大不同：

1、模块化需求

模块化或紧密相关联的产品需求，通常有长期规划，是影响公司主营业务的需求。

2、零碎迭代需求

小范围迭代优化类需求，做为模块化需求的补充需求或从各部门收集到操作层面的优化建议类需求。

具体该怎么做好需求产品管理呢？我们需要了解下面这些维度：

9 F9 m4 H  K" t+ m. R# w

• 生命周期
  ) V/ W! Y2 ]- j3 z

产品的生命周期包括产品调研阶段，产品分析阶段，产品设计阶段，产品上线阶段，产品维护/下线阶段。

如下图为产品生命周期的流程图：

# g6 G# h: C' N& t- e' v

• 产品调研阶段：主要是对各个渠道来源的产品进行调研，是挖掘需求最重要的一个环节。
• 产品分析阶段：将已经调研过产品进行分析和排期，保障后续产品按期执行。
• 产品设计阶段：是从产品将思维变为实体化的过程，其要经历两个环节需求评审和技术的评审。
• 产品上线阶段：主要对产品进行开发，对业务部门进行产品培训以及产品上线。
• 产品维护/下线阶段：对已经上线的产品数据进行观察，分析产品是否需要迭代或下线。
  & N+ ~) R8 O6 X; ]

- Z2 r( I) f2 i: D2 g8 o

• 需求收集
  * [5 m% \& ]& i% t

对于需求来源有很多。可以说业务越复杂，实现的需求就更麻烦。而这对于涉及到的人员也就更多，而且每个业务流程也会延伸新需求，好的需求收取渠道能让业务发展更顺利，那么主要有哪些收集来源呢？

% Q( C# j& D' {* o. B' ^! Z: T
, B" t7 G  Z6 P

• 业务发展
  7 j* V: Z5 t' I4 a+ R; e
  • 主体业务：这个也是需求的主线。从公司的愿景中规划出来的产品或产品线，而后根据这条线路不断迭代新产品，从而产品也根据愿景进行调整。故主体业务的来源方主要是公司层面。
  • 内部提出：主要是各业务部门提过来的需求，如线上产品使用后的迭代或bug、业务部门的策略需求（如用户优惠券的使用规则）等，都是依靠于业务方提出。
    

6 M# _2 o$ z" A% V6 X1 H* r


( R* J! R' W( n* \0 X# V
3 D) V1 D, ?; C  o
• 用户调研：这个比较常见，就是通过一些用户调研、问卷调查、用户访谈、信息采集等手段来挖掘需求的方式。举个例子，我们经常做的就是给用户发送问卷的短信，让用户进行问卷答复。
• 用户反馈：收集用户的使用反馈，用户的意见虽然天马行空，但是有时候就能从中提取出有价值的需求。常见的做法是产品放一个意见反馈的入口，引导用户进行反馈，大部分都是放在个人中心的位置，比较符合用户习惯。
• 产品数据：在产品中使用统计工具，或对用户提交的数据进行用户画像数据分析。也可以参考公共调研机构出具的一些数据分析报告进行分析。大部分产品初期是使用腾讯统计，百度统计等第三方统计，这种研发成本低；后续的话就需要搭建BI数据统计平台，公司需要什么数据就进行相应的统计，更适合产品数据分析。
• 竞品分析：研究同类产品，从中找出优劣势，从而发现产品的突破口。去其糟粕，取其精华，做到人无我有，人有我精。假如给你分析一个到家服务类的产品，你可以从下面这些方面入手：
  3 ?+ g6 o; d4 d" F- [9 B1 b
  • 分析目前到家服务类的市场布局情况
  • 它们的数据情况（全还是不全）
  • 操作情况（刷新、页面跳转、查询等）
  • 界面情况（视觉、布局）
  • 产品的详细功能点（常规功能、特色功能，实现程度如何）
  • 用户流程分析（应用可用性、易用性等体验，喜恶程度）
  • 内部产品的优势与不足
    , T" o0 |; `' T4 N  c' i  K. A

9 d  E% C6 Z$ X" y) R! }) I


8 F2 Z) A$ V& l8 N' G

• 需求排期
  7 R* J0 x% O% H9 t0 N% Q

对于需求排期是产品分析阶段不可或缺的一部分，直接决定在业务近期的走向。而且对于产品来说需求来源很多，经常面临着需求过多的困境，那么面对堆积如山的需求，产品应该从目标和优先级入手。

• 目标
  

$ ^1 h* I) F1 X) d& w

对于需求来说要先找准目标，而且对于目标也应该有个机构来判定，应该要有规范化的流程来判定，而不是一时头脑发热就做出判断。对于我们来说，我们是通过产品委员会来进行每月目标判定的，有多个部门负责人以及高层来共同评定，具体主要从下面几点进行考量：

* b' s' W/ r8 d# X0 N
# a0 K$ B8 O5 h4 v2 f2 [1 Z

• 满足业务部门紧迫的功能需求。无论是运营部门还是客户，在一定程度上，都是产品的最直接需求供给方，因此解决他们遇到的问题，或许是产品最大的职责之一。
• 解决终端用户备受困扰的痛点问题。互联网是用户体验为王的行业，及时有效的满足用户需求，提高用户体验，解决痛点问题，这是产品经理需要一直努力的方向。
• 避免重复开发或无效的低效率开发。产品不仅要对市场负责，也要对开发负责，不能因为自己的无知而拖累整个开发团队疲于奔命，因此在功能规划、需求排期时一定要结合开发人员的产出比综合考量。
• 要控制好整个产品功能规划的设计节奏。这一点强调的是要对产品经理自己负责，如果把产品看做一匹奔腾的骏马，那作为产品的灵魂人物，产品经理应该是一名优秀的骑手，永远不能让骏马脱缰。
  ) t& l* N: o- \; C& c

6 `) _$ u9 z- `* f" \+ k

2 e2 X; I0 S) t  b8 I* z
. r; q$ d  v8 w+ P; s
• 优先级
  1 f$ _1 f; ?# ]% _7 i

定好目标后，产品经理就要聚焦每个需求点，然后准确的定义优先级。产品经理可以从下面几个方面入手：

8 C. i4 L- V( E5 S, c; _1 f+ v
2 ^" ~5 @# |/ G4 I  s# ~2 L; Z

• 要对业务有足够了解。因为并不是所有的业务方都能够清晰的知道自己想要什么，或者随着不同时刻摆在他们面前的问题不同，他们嘴中最急迫的功能需求也会变动，所以作为产品经理，要在对业务有足够深的了解之上，做到慧眼识真。
• 合理安排需求的串行和并行规划。
  8 n2 N9 n4 w8 ]9 ?9 t+ t! i
  • 需求串行注重的是看清需求之间的先后关联性，某些需求点并不是孤立的存在，而是互相牵扯，很多情况下是需要先实现需求A，在A的基础上才能更顺畅的实现需求B，如果看不透这层关系，硬先实现需求B则会得不偿失。
  • 需求并行注重的是看透需求的规模，模块化新功能需求和细节性优化需求所要求的开发周期和工作量截然不同，要学会将不同规模的需求合理的穿插揉并在一起，这样对项目的进展速度会很有帮助。
    ; T' B. q/ z; i+ E! ]

# ~# I, B9 w7 }" z& l2 M


5 h" _; T8 w$ F( j- A
• 学会产品设计MVP思路。MVP即为最小化可执行产品，即意味着在需求不明确之前，不做或者最小化设计。MVP思路强调先保障最基本的功能实现，甚至是将需求拆分完成，避免过渡设计的冗余，先实现基本功能，通过用户反馈等明确需求之后再做针对性设计。在另一个角度看待，就是要最大化开发资源的收益比，面对堆积的需求时更是如此，每份资源都是异常珍贵的。
  , q' A' Q+ i- }( S

8 n4 z$ A- q" v

• 需求评审
  2 k! r' f8 ^' n: v4 y

需求评审简单来说就是一个评议、审查、明确需求、统一思想并确定实现过程的会议。也是评估产品合理性的重要一个环节，对于我们来说这个环节也是产品委员会的重要职责之一。

• 需求评审目的
  ! d  w+ |0 m. \8 q& f
  • 本身也是知识传递过程：相关人员可以与产品经理一起讨论需求设计的前因后果，这有助于相关人员获得用户需求的前期认识
  • 与需求方达成统一认知：任何一个团队想要做好一件事情，都需要所有团队成员达成统一认知。
  • 发现不明确和遗漏的需求：这个就需要产品进行二次确认。
  • 发现间接需求或隐藏需求：参与评审的相关人员可以群策群力共同思考解决问题的方式。
  • 当局者迷、旁观者清：再有经验的产品经理也可能犯错或思考不全面，评审人员可以提出更合理或者更有建设性的想法供产品经理参考。
    3 a. p" |3 W! w' p0 _6 b

6 v- _: \3 l. u8 m7 D% b8 M# |
8 p$ f2 Y4 `6 }0 L( t# f7 B
3 e" D+ a5 @2 ?# i7 A) b( _9 L; S

• 需求评审维度
  5 \: ?5 q5 T2 \. A: M* f$ @
  • 需求背景：概述需求从哪来，为何要做这块。
  • 用户诉求：描述需求应该要做成什么样。
  • 功能模块：需求涉及相关重点大的功能点。
  • 流程：讲解本次需求涉及主要流程。
  • 数据指标：讲解本次需要哪些关键性的指标。
  • 原型与交互：讲解原型内容和交互。
  • 资源和上线时间：预计需求上线时间和需要的资源。
    

( M4 h9 M& ]- j+ T# H6 @( @! b3 U

• 产品委员会
  

产品委员会是产品开发管理、产品生命周期管理的最高决策机构。是对需求的重要把控环节，目的保障产品的决策和正常运转。故参与需求评审也是产品委员会的职责之一。那需求评审的主要流程如下：

• 提前发送资料：产品经理准备相关资料，并提前将相关资料放到共享盘，并通过邮件通知到涉及到评审的所有人。
• 确定评审时间：将资料通过邮件通知的同时，需要同时发起具体评审时间的征询流程。
• 开始评审
  # a+ }/ K4 |, R( O
  • 产品经理讲解内容。
  • 产品委员会有问题记下来，等产品讲完后统一解答。
  • 产品经理将会议的疑惑点记下，待会后统一整改处理。
    ; J# e+ S$ {3 m. V& C# P; ~

. A7 o1 l) p9 @1 a

/ W, I& Z5 O5 E- J8 ]+ B
2 m; l# F+ U, j, D! o
• 评审结果
  
  • 产品委员会讨论评审结果。
  • 若评审结果为不开发，则此需求终止。
  • 若评审结果为通过，产品经理则可进行后续的技术评审。
  • 若评审结果为不通过，产品经理需要对需求进行调整，调整后发起再次评审会议。
    

. v' k4 B, l4 q. V
* D- `# D9 D2 h3 x6 B) ?

0 I& ?* v+ X% i0 A, z

• 说明文案
  " x* B% T8 i  \6 w; e

说明文案在需求管理中起到非常重要的作用。是需求完整性所必须的。是对需求的详细描述，方便开发和测试根据文案进行研发。

1、存在的必要性

做好说明文案能让后续人员方便查看需求。毕竟人的记忆是有限的，过了一阵子后，之前的需求可能就会出现遗忘，这个时候有说明文案查阅可以快速熟悉整个需求。

举个例子，公司之前产品都走光了，没有留下完善的需求说明文案。然后随着业务相关人也离职后，基本上后续来的新员工根本就对系统不熟悉，只能找研发看代码来看业务逻辑。这种情况就出现了有一些功能就根本没有去用，因为根本不知道有什么用处。甚至本来系统已经存在的功能了，而业务部门不清楚又让产品开发相应功能，导致了重复开发。

从上面的例子来看，如果有完善的需求说明文案是可以避免的。就不会造成公司这么大的损失，我们应该要让公司成员就算流失也不会影响公司正常运转。

2、如何做好需求文案

（1）文字要能够描述产品的核心功能或典型使用情景。

（2）文字要简练可读性好，对于按钮或者功能定义最好控制在2-4个汉字;对于产品情景描述标题文字控制在6-20个汉字。

（3）文字设计要考虑目标用户的可理解性，了解目标用户的认知行为习惯与文化特征。

• 文字设计要具有情感化特征。
  $ R; X& \2 O( k" K* K; u

（5） 文字设计要有阅读层次性，以渐进式的文字设计引导用户认知产品，以标题文字为核心，以内容解释文字为展开基础。

（6）文字设计要具有延续性和统一性。

（7）注意标点符号的使用。

（8）注意语气，有时该直接就得直白明了，慎用疑问。

（9）每张原型图下面需要备注功能的路径，以方便开发明白该原型图在哪个模块的哪个菜单。

( D5 x5 o/ A: I8 D" U9 O

• 对有功能操作的地方应该进行详细说明，涉及状态变更需要说明状态变更的流程。
  

• 事例说明
  

- b+ t9 Y& s2 K/ H1 K/ d/ B. y5 S
' G  w( b! g' z; E

这个是我们之前的一个产品原型，如图可以看出这个是一个简单的绑定手机页面。具体是业务逻辑就不在这里阐述了，一个好的产品设计就要把细节的每一点都考虑到，并且要对其做好文案描述说明。

• 培训使用
  " Q# G+ K3 F! O! P

对于用户我们没有办法进行实际上的培训，故我们除了提高用户体验之外，还可以在关键操作上做操作指引。对于业务人员来说，因为系统上线后就要马上对系统进行使用，其对系统操作的熟悉程度直接影响的业务的运转，故要在上线前对其进行培训。

之前就是产品培训不到位，导致后续业务使用过程中，每次出现问题就像研发反馈bug，但是本身就不是bug，只是少配置了个参数，而且这种问题反馈了好多次，导致感觉研发是在给业务讲需求。所以培训是很重要的，可以从下面入手:

$ t5 k8 S/ E$ i0 W5 P* @) G

• 产品文案要做好，除了要有原型，还要有ppt。
• 要结合系统操作进行讲解。
• 在讲解过程中要多对培训人员提问。
• 培训完后要讲培训资料发送给相关人员，让其会后继续熟悉需求。
• 讲解一天后对培训人员进行考核。
  

4 \9 k; u$ g) i" m0 f+ L

• 观察分析
  

需求从获取到上线，还要对产品进行观察分析，而不是产品上线了就丢下不管。产品都是通过不断的迭代发展来的，而不是一蹴即就的。就是微信也是通过不断的产品迭代发展的，如果一个软件不迭代那么很快就会被淘汰。尤其是MVP发展产品的理念，不断对产品进行试错及快速迭代，故对我们上线的产品进行分析就显得尤为重要了。那么应该如何去分析产品，我们可以从下面几点来进行：

$ R' y; @- z5 Q8 n+ u

• 新功能是否受欢迎
  % \- w0 [; G) a& A: ^, O

* |; J9 A2 h" c/ i. m, C

要衡量一个新功能是否受欢迎，基本就看这个功能上线之后，用的人数多不多，用的人越多，表示这个新功能还是挺受欢迎的（当然，这里还有一些运营推广的因素）。

一个比较好的衡量指标是功能活跃比，什么叫功能活跃比，也就是使用了新功能的用户数/同期活跃用户数，比如说新功能的用户数是1000人，而同时期产品的整体活跃用户数是10000人，那么这个功能的活跃比就是10%。

• 对产品的转化率是否有提升
  

很多时候，产品经理接手一个新项目之后都喜欢对原来的产品设计界面进行改版，不管之前的界面是美是丑，总之我来了，就要产出一套新的界面。当然，也不是说对产品界面改版就完全是不靠谱的事情，如果改版之后，对产品流程的转化率（或者其他数据指标）的确有提升，那还是相当有用的。

所以，这个时候，我们就需要通过去观察整个产品的流程转化率是否因为产品迭代改版而有所提升。最基本的方法，就是通过创建流程漏斗来进行数据观察，现在很多第三方的数据分析工具，像我们用过的百度统计或者腾讯统计都支持用户自己手动创建转化漏斗了，我们只需要梳理清楚一个产品流程转化漏斗都包含哪些环节。比如电商网站，最基本的转化漏斗的路径便是：

网站首页–>商品搜索–>商品详情–>加入购物车–>立即支付–>确认收货

这样，我们就可以将上述事件组装成一个转化漏斗，如果你优化了商品详情页或者是搜索页面，那么就可以很好地通过漏斗来看出，改版之前和改版之后，这个流程的转化数据发生了什么变化，每个小环节的漏斗转化率又发生了什么变化，这样就能比较准确地评估出产品迭代对流程转化率是否具备提升作用。

7 O4 ]9 r, n( K

• 对产品整体留存的影响
  

  x: }; f/ k6 O3 d4 E4 F( M

一个好的功能是能够产生用户粘性的，这是因为用户对产品更加喜爱的话，会让用户更加频繁地使用产品（也有一部分的确是刚需的因素）。所以，我们在迭代之后，也可以好好观察一下产品的整体留存是否产生了变化，比如次日留存、周留存、月留存等等指标，是否朝着更好的方向发展。

1 i/ }7 x; v/ D: y8 u* h1 |

• 用户究竟如何使用新功能
  

要衡量一次产品迭代到底效果如何，数据表现固然是很重要的一方面，但另一方面，产品经理也该深入到用户之中，去询问和了解用户对于新功能的反馈和体验如何，或者近距离地观察一下用户是如何使用产品的。更重要的是，当出现迭代之后数据表现不佳的情况下，只有这样近距离地观察用户操作使用产品，你才能发现问题所在，也许是因为用户的微信版本比较低，导致一些功能不支持，也许是因为用户的网络不太好，导致加载信息不完整，诸如此类的异常情况，还是需要产品自己和用户产生连接，才能更好地洞察这些情况。

, g+ S- h6 l- r

• 结果决策
  

对于新功能是否受欢迎，如果一个新功能上线半个月活跃比都很低，那就要分析是这个功能是否符合用户刚需，考虑下功能入口是否明显，不是的话就要考虑入口提升或者下线。对于产品流程迭代的时候，如果因为环节带来的用户流失就要产品经理从用户的角度去体验整个流程，重点关注流失的环节，看是否有阻碍用户流程的因素，从而对产品进行再次迭代。对于营收方面，如果产品一直属于亏损状态要分享下该产品能带给公司什么利益，如流量方面的分析，间接带动其他产品营收，如果分析后带来的利益小于亏损的程度就要对产品进行下线的分析或者转化经营理念。

4 ~1 d) [. }) {, `" D3 l4 @

• 小结
  

对于需求产品管理，是对产品生命周期管理的过程；通过5种渠道进行需求收集；从目标和优先级入手进行需求排期； 利用产品委员会把控需求评审环节；要求产品设计做好文案说明、存档和使用培训；最后通过数据观察分析，是否继续迭代维护或下线。

# y4 m9 j; V* C0 \+ D" K, W

Heaven_1

用户调研这个环节很重要