做产品，如何拿捏需求

　　之前听过刘文智《产品经理深入浅出》的讲座，其中有一句话给本屌留下的印象最深：做产品经理，最重要的就是“拿捏”。作为一个初级产品经理，专业填坑经理，资深挨砖师，当时听到“拿捏”这个骚气十足的词，我居然可耻的硬了（表示有共鸣）。

当我们面对用户的需求，运营的吐槽，市场的恐吓，老板的圣旨，如何“拿捏”，这是个问题。拿好了，对谁都能交代，捏不准，结果必然是被别人群起而“拿捏”，直至蛋碎。

为了保护好我们的蛋蛋，分享几个小心得。

新的功能，给需求打分

对于已经确定的日常工作，我们通常会按照第二象限法安排工作时间（关于“第二象限时间管理”请自行搜索）。但当我们面对诸多新需求的时候，却无法使用这个逻辑。因为我们很难判断哪些事情是“重要”or“紧急”的。

一个新功能的需求，没什么运营数据可以参考，我们无法准确地知道这个功能做出来是有用还是没用，也无法判断做了这个之后，会带来什么样的结果（除非你真的经验很丰富啦~反正本屌是不敢做这个判断）。从老板过来的需求就是“重要”的嘛？市场的恐吓就一定是“紧急”的嘛？某某人说：如果没有这个功能，就不能如何如何！这句话是真的嘛？假设真做了这个功能，某某人就一定会如何如何嘛？（敢立军令状嘛？这句话可以在心里问，但是不要说出来，说出来就不能好好地玩耍了）

作为产品经理，在这种“砖头与瓦片齐飞”的境况下，要有自己做出判断的准绳。否则最终就会发现，所有的事情在做之前全都是“重要且紧急”的，但是当我们做完了之后，就全尼玛变成“不重要且不紧急”了！长此以往的话，就该是“鲜血共朝阳一色”了。

在惨剧发生之前，我们可以用“给需求打分”的办法来对需求进行评审。

首先在一个跌代周期的初始，把各种新功能的需求从需求池里列出来，召开需求评审会议。评审会议要避免需求的发起者参与，以保证评审结果相对客观。并且所有人都应该客观、积极地发表自己的意见。

然后设置几个符合自己产品特点的指标，例如：此功能对发展用户数量的影响程度，对发展业务广度的影响程度，业务深度的影响程度，是否是产品正确方向下的进步，能提高使用人员的工作效率么？是否是高层的要求？是否是普遍共性需求？……等等，根据自己产品的特性，设置适合的指标。

接下来对每一个需求，以五分制or十分制，按几个维度的指标进行打分，综合下来看，哪个需求分数最高则优先进入产品设计，淘汰掉的需求暂时回到需求池。

这样，就可以有理有礼有节的往下进行了，小伙伴们又可以愉快的玩耍了。另外，淘汰掉的需求就真的不做么？也不一定的，后面还会有说明。

旧功能的改进，以数据为指导

除了全新的功能之外，还会有很多需求是针对旧功能的改进提出的。如果需求的起因只是“咱们已经有了A了，所以应该有B，有B更好，别人都有B”，这绝对不能成为进入设计和开发的理由。

要在旧的功能上继续往下迭代，要先确认前几步已经走到位了，已经可以开始继续往下走了，再往下走。

是不是可以往下走了？接下来往哪里走？这时就应该以数据为指导，例如：发送聊天消息的功能已上线，应该在聊天中加入发送表情的功能，这样可以让大家聊的更愉快！这时候你先需要判断一下，聊天这个功能的数据如果没有达到预期，那么你首要的任务是解决如何引流的问题，入口的设计有没有可以改进的？运营推广的方式是不是没有抓住重点？把这些问题解决好之后，再去做表情。做表情，是结果，而不是原因。

用数据为需求设置时间点

有可能有这样一些需求，它是应该做的，但不是现在应该做的。有的时候确定了一个现在就要开始做的需求，但它可以拆成多个功能，全都做完黄花菜都凉了。有的时候一个功能已经做完了，但是他并不完美，甚至存在严重的漏洞。

这时候我们不能仅仅因为自己有完美主义的强迫症而投入过多的资源（当然也不能因为有拖延症而拖着不做……），我们应该有“用数据为需求设置时间点”的观念。当我们遇到以上情况，可靠的思路是，设置一个或多个数据指标的节点，当指标达到预期后，则某需求进入设计阶段，否则不继续往下走。比如当用户数达到x后，则设计用户资质审核流程；当某模块的访问量达到y后，开始开发之前暂时压下来的缺失功能。当然也许这个预估的数字不是那么准确和可靠，但是我们应该有这个观念。

让这个观念成为习惯，才能逐步的甄别出哪些投入是有价值的，哪些是浪费时间。并且，总能在没出事儿的时候，保持投入资源最少，见效最显著的轻装状态，在一段时间后，快出事儿还没出事儿的时候，又投入很少的资源把之前的坑填掉。是不是逐渐有点运筹帷幄的赶脚了？（好吧，完全没有）

以上三点，是对需求的“拿捏”的三个小心得。对于如何迭代，如何设计，如何拆分开发任务，如何管理项目，其实有很多“拿捏”的思路是共通的。最后，祝你拿（chan）的（pin）准（gou）、捏（lu）的（yi）爽（fa），如果觉得本文有帮助，别忘了点赞哦~。

本文为作者hoovay投稿发布，转载请注明来源于人人都是产品经理并保留本文链接