生吃需求,如何解忧?

table of contents

    - 小姐姐,可以帮忙做个小需求吗?

    - 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

    转载请注明来源:生吃需求,如何解忧?
    声明:本站文章内容最新发布文章多为原创,同时转载了不少知乎和公众号多年之前就已经发布过的比较好的文章。保存文章的目的是为了提高自己的水平,同时可以看看各位当年的大佬对未来预测是否靠谱,另外也是为了自己查找回顾方便。转载文章每篇都亲自阅读,并且做了整理和修改,删除了一些招生或者培训信息,每篇文章尽量保留原作者信息和意图。