生吃需求，如何解忧？

文章ID: 596

状态: publish

分类: uncategorized

• 小姐姐，可以帮忙做个小需求吗？

• Emmm...你怕是对“小”有什么误解吧？

发现没有，总有人骗我们需求好吃，入口即化！！

好不好吃心里没点数吗？

好的，这其实是一篇正经的定义需求的文章~~

需求，可以说是产品经理的高频词了，然而它又是被误会最多的一个词。当我们谈论需求时，我们可能在谈论痛点，也可能是诉求、问题等。

需求 vs. 诉求

无论用户、运营，甚至老板希望你加一个什么功能时，背后有他的诉求。接到需求，第1步通常是厘清诉求，这已经是老生常谈了。

厘清诉求最常用的方法是问为什么。但是要注意这通常用在对方有大致明确的诉求时。如果是深度访谈挖掘用户需求，“为什么”其实要慎用。下文具体讲。

需求 vs. 问题

这可能是对于大部分 PM 来说最日常的解释了吧。也是外行最深的误解。别人总觉得 PM 成天在想着怎么挖掘人性、改变世界，然而事实是大部分时间在处（背）理（锅）问（撕）题（逼）。

这些问题通常表现为：xxx 解决方案要不要上？听上去好像是个上、不上的非黑即白的问题，其实需要经过诸多考量。

怎么能快速找到合适方案又不容易被怼呢？呐，套路都帮你准备好了。

Step 1 评估必要性

问题有必要解决吗？有时，问题可能没想象的那么严重。

问题的影响是什么？

问题真的存在且重要到要改变现状吗？

在数量上、质量上重大吗？

必须要改变现状吗？

问题的原因是现状固有的吗？

现状的调整和修补没用吗？

不采取积极措施，问题会继续吗？

Step 2 提出解决方案

这就有很多方法了，列举几种。

最优解

这是最常见的。穷尽影响 -> 穷尽措施 -> 找到最优解。

例如有一次一大早在群里收到客服的消息：北海因为环球自行车赛封路，接送机限制下下单吧～

给到的是一个两难问题：限制还是不限制？

这就需要评估：

发生了什么：自行车赛封路。

有何影响？影响多大：时间上多久？路段有多少？路段的占比是多少？

有何措施？措施的利弊：可禁止下单，也可不禁止，只做提示；如果禁止下单，会影响多少单量？

措施如何选择？

启发法

个人理解是不一定是最优解，但对解决问题有帮助的方法。

有时候寻找最优解的成本和代价太大了，就可以用启发法。

STC算子

这是《创新算法》里提到的概念。和前面解决问题的方法不同，这个通常用于创造性地解决问题。（事实上作者很 diss 试错法、启发法，这 2 个方法确实很难有创新，但不失是解决问题的方法。）

《创新算法》是一部被前苏联雪藏了50年的技术创新专著。作者研究了大量专利，总结出切实可行的创新方法。

其中的 STC 算子 部分是说，要去考虑物体的极值状态，从大小（size）、时间（time）、成本（cost）三方面考虑。

例如：

假定改变物体的尺寸，从给定值到 0 ，这个问题能解决吗？如果可以，怎么解决？

假定改变物体的尺寸，从给定值到无穷大 ，这个问题能解决吗？如果可以，怎么解决？

——《创新算法》

例如要发明更好的出行工具。如果看到几十年来汽车轮子的直径越来越小，那么可大胆假设，最终直径为 0，即没有轮子，会是什么样的东西呢？

这本书成书时间较早，且主要研究的是机械领域的发明，但对于互联网产品设计也有很好的借鉴意义。

例如我们可以定义出要解决事物的每个属性 （来替换 STC ），然后通过考虑属性的极值来看是否有好的创新方案。

Step 3 评估解决方案

提出解决方案就完事了吗？并没有！你还要搜集数据，证明解决力度。

方案可以解决需求、达到目标或符合标准吗？

会产生和现状一样大甚至更大的问题吗？

方案所产生的优势是否是其内在的？不使用这个方案不会有这个优势？

方案所产生的优势是否是方案独有的？

有缺点吗？优势是否大于缺点？

需求方总有着谜之误解，提需求时爱说“我有个小需求很简单”、“这个地方只需要微小的改动，可以安排下吗？”。我通常心里已经 MMP 了。

其实最害怕别人提小需求。看上去小，似乎很好解决，其实要耗费的思考精力是一样的，需要的资源是少，但设计研发通常都不爱做呀，于 KPI 又无利。

所以，正确的提需求姿势其实应该是：“我有 1 个大需求，还挺麻烦，能安排下吗？”

需求 vs.  痛点

痛点，这可能最接近需求的本义，和产品人的初心。

按梁宁在得到的产品课程里说的，需求除了有痛点（感到恐惧的），还有爽点（感到愉悦的）和痒点（虚拟自我）。

如何挖掘痛点？这就要扯到比较虚的洞察和同理心了。

如果有机会，可以做一下用户深度访谈。但深访其实不容易。

说起用户访谈，外行会觉得“就是一直问为什么嘛”。而稍微有些经验的人就知道最痛苦的是“明知道对方没答到点子上却不知道问什么”。

前面说过，和了解诉求不同，此时尽量不要问为什么。

为什么是一个正确的词汇，但是它太抽象了，可能会导致被访者不知道如何回答。....什么导致、什么影响、什么塑造、什么推动了…等等更好些。

——《质性访谈方法》

痛点挖掘之外，更难的是定义需求，这个有待下一篇再讲了....

对了，这是《产品经理关键能力》系列的第三篇。

图片来自网络

题图来自 gratisography.com