详细分析：高级产品经理做一个需求，和你有什么不同？

2016-12-19 12:25:00

前段时间“高级产品经理与普通产品经理的差异”这个话题讨论得火热，联系到这段时间的工作感悟，从如何做一个需求这个工作中最常见的点切入，以供反思和讨论。

1 前提

首先定义一下这篇文里提到的两种产品经理。

普通产品经理大约分为两种，一种是资历比较浅、没有亲身经历过足够的版本迭代或产品生命周期的新手；另一种则是可能从业时间较长、也经历过足够的需求历练，但一直在进行重复性的需求处理，没有从更高层或者更深刻的角度去反思自己的业务，从而导致自己的业务能力到达一定水平后就停止爬坡。这里需要说明的是，普通产品经理并不是工作不到位，而是工作侧重执行层面、对工作的思考程度尚浅、还有很大的提升空间。

而文中说的高级产品经理，不与任何公司的等级或头衔挂钩，而是指在完善处理需求的基本业务能力以外，能够拥有自身的产品观与严谨的方法论，并应用在日常每一个需求的处理或决策上。一些高级产品经理仍然奋斗在一线，而另一些已经在管理岗位，虽然不完全直接做需求，但同样会用他的产品观与方法论影响整个团队。

2 做一个需求

那么高级产品经理做一个需求，究竟有什么不同？很早之前我做“零基础进击产品经理”的科普课程时，总结过一个产品经理日常处理需求的流程：需求分析——产品文档——需求评审——跟进开发——需求上线——评估效果——迭代优化。其实无论是高级产品经理，还是普通产品经理，整个流程的差异不大，区别在于期间每个流程的方法论与侧重点。

需求处理流程

a. 需求分析

对一个普通产品经理来说，分析需求的步骤很多时候在回答"用户要什么"以及"老板要什么"，能够回答好这两个问题就非常不容易了。而对于高级产品经理来说，在此基础之上，还需要回答两个问题： “业务要什么” 以及“ 产品本身要什么 ”。

问“业务要什么”，很显然是要考虑公司目标和利益。时代不同，整个行业正在从务虚转向务实，很多公司已经越来越重视盈利性，单纯只考虑用户诉求是不足够的。即便考虑的不是盈利性，也要考虑你当前的需求是否与公司整体目标一致，比如当前公司主推的业务是什么？发力点在哪部分用户？未来一段时间要的是拉新还是留存？我曾经专门在微信群里分享如何基于行业和业务进行产品分析，并整理了文字版发在微信号破壳里，就是给大家一个方法论去回答好业务的问题，进而把握好整个需求的方向。

问“产品本身要什么”，则是对产品本身成长和发展的整体把握。很多产品经理在评估一个需求的时候，觉得是用户需要的、也是业务需要的，就没什么问题了，然而这时候高级产品经理则会再进一步去思考：这个需求后续该如何去迭代？是否与产品本身的规划一致？高级产品经理要做的不光是抓住一个需求点、打造一个功能，更需要考虑清楚这个功能以后如何成长、如何和产品整体规划融合起来。

b. 产品文档

文档的表现形式和书写习惯多种多样，这个和公司规模和团队合作都有关系，倒也不能作为区分高级产品经理和普通产品经理的点。这个环节里能让人觉得“高下立现”的有三个点：需求释义；特殊场景；数据追踪。

需求释义是指，高级产品经理要确保自己对需求的理解足够清晰和准确，并够传达给整个团队。普通产品经理需求执行阶段，往往直接就开始写文档描述功能，这就无法把这个功能的重要性传递给整个团队；相反，高级产品经理则会把为什么做这个功能、为什么要这么做、对业务有多大影响这些问题都和团队解释清楚，无论是通过文档本身，还是口头或邮件表述（上面说了各个公司习惯可能不一样），都会是对整体团队的激励，提升技术、测试、运营等团队的参与感，甚至可能在沟通中带来更好的想法，优化实现目标的方案。

特殊场景是说那些主流程以外的流程分支。比如用户登录时输错密码了怎么办？用户输对了密码但是验证码又错了怎么办？突然变成弱网环境怎么办？……普通产品经理能够对主流程梳理地清楚到位，对特殊场景的覆盖往往力不从心；这时候高级产品经理则会尽可能覆盖全这些特殊场景或者是错误分支，给开发团队更明确的处理方案，这么做一方面是确保自身对功能表现的控制力，一方面也是从产品层面确保产品在不同端的体验一致。

到了数据追踪的环节，很多普通产品经理会直接把该打的tracking全部加上，确保没有遗漏即可。有些时候这么做的确也可行，然而如果遇到排期紧张或页面交互复杂的情况，这种做法则会造成开发资源浪费。实际上，做数据追踪的科学方式，是要依据该需求的核心目标而制定，数据追踪所实现的其实是定性目标的量化分解。

举个例子，假设一个电商产品想要增加销量，在首页新增了一个专题功能，目的是引导用户、刺激购买，那么最核心需要追踪的就是点击率和购买率，以及专题触发的点击率和购买率与其他路径带来的有什么不同，是否真的能更加刺激用户购买。比照交互路径，收集的数据应当是设备开启次数、专题区域展示次数、交互路径上可点击区域的展示次数和点击次数，从这个路径触发的商品页展示次数、购买次数等等（其中的次数要考虑到展示设备数、展示人数、实际展示次数的不同）。以目标量化分解为出发点，追踪核心路径的路径并保证数据纯粹性，比盲目打点更能帮你评估功能的效用。

c. 需求评审&跟进开发

把需求评审和跟进开发写一起，是因为对于高级产品经理来说，由于前期对于需求的处理思考维度更多，方案设计更具说服力，也能够激励到整个团队的协作，在需求评审和跟进开发的环节，反而耗费的精力要小很多。相对地，普通产品经理还沉浸在“如何与程序猿相处”的问题中，甚至在开发环节发现一些问题再做修补，其实都是对精力的损耗。

d. 需求上线

这个流程其实大家都在做三件事：一是确保功能相关的素材和相关的部门准备完毕；二是功能回测无问题，达到可上线状态；三是上线节奏控制，是否需要内测、分渠道等等。这些其实都没有太大的差异，只是高级产品经理会在细节处理上更到位。比如说，一个新功能的上线，普通产品经理会通知到运营团队准备相关素材或者活动推广，也会主动参与到方案讨论，然而高级产品经理会同时通知到客服团队，做好用户咨询的准备。

虽然是细节，体现的则是考虑更周全。

e. 评估效果

需求上线后到了评估效果的环节，这里就是我之前写的“数据追踪”派上用场了。比起普通产品经理面对数据的再加工，高级产品经理在进行数据追踪时就已经想好了该如何评估这个功能的效果，主要是看哪些指标。

f. 迭代优化

普通产品经理通常是在评估效果后，根据数据反馈对功能做下一轮的调整和优化。然而这会产生一些很棘手的问题：比如说，有些优化会造成版本不兼容（尤其是移动端），这就不得不维护两套逻辑，还要分别考虑到不同版本的用户体验；又比如说，到了下一个版本，这个功能的优化需求被降低优先级了，那么上一个版本的问题可能会在线上待更长时间，回头再处理时就是更恶心的版本不兼容；还有一种可能，时间长了，事情又多，这个优化需求就被大家遗忘了……

高级产品经理在做需求时，首先一个出发点是：不留已知的坑在下个版本优化——因为下个版本可能就优化不了。所以在刚开始做需求设计时，就尽量避免一些有可能会挖坑的设计，或者在上线效果不确定时先做小流量测试，甚至是通过H5页面或者微信生态测试；其次，在需要优化升级时，也会再次根据当时的产品状态和业务要求进行评估，这又回到了第1步的需求分析，完成需求处理的闭环。