以需求管理为例,产品经理如何打造自己的需求分析能力

23 评论 35373 浏览 325 收藏 15 分钟

我始终认为产品经理拥有批量化复制自己能力的能力是一种很高级的能力,这篇文章以需求管理为例,讲的是产品经理何如模型化(批量化)自己的需求分析能力,希望产品同学们阅读后有所启发。

文章框架:

  1. 需求管理引擎的定义&框架;
  2. 管理引擎框架串讲;
  3. 关于能力批量化复制能力的一些思考。

一、需求管理引擎的定义&框架

定义:需求管理引擎是一个框架模型,规范了从需求分析到需求逻辑产品化过程中的所有思考路径和思考边界,有利于培养模型化思维。

框架:如下图,需求分析引擎主要分为四个模块:

  1. 需求分析;
  2. 需求立项;
  3. 需求(产品)研发;
  4. 归档,下文会串讲这四个模块的主要内容。

二、管理引擎框架串讲

2.1 需求分析

2.1.1  需求分析框架闭环

需求分析框架闭环的意思是我们面对一个新的需求,思考的时候要形成逻辑闭环。这里引用了经典的思考模型——3W模型:what,why,how ,既这个需求是什么,为什么会产生这样的需求,如何将需求转化为产品进行后续的价值分析。

what 层:需求来源&需求分类

what 层主要让我们标记需求的来源和分类,需求的来源又分为两个维度:方式 & 对象。方式维度:用户访谈,竞品分析,数据分析等产品经理通过某种行为而获得的需求。对象维度:用户,产品经理,其他,对象维度指的是需求的提出对象。

需求分类主要分三种:

  1. 以前没有过的需求,归类为新增需求;
  2. 以前有过的需求再次优化,归类为迭代优化;
  3. 以前的需求存在缺陷进行修复,归类为缺陷处理。

why 层:陈述事实,表达感受,说出期望

很多时候用户提出的是他们认为的解决方案,而并不是真实的需求,产品经理进行需求分析的时候一定要多问几次为什么,询问的时候尽量的让用户陈述需求当前的事实,表达内心感受,说出自己的期望。

《乔布斯传》中提到一个细节,如果亨利福特在发明汽车之前去做市场调查,他得到的答案一定是大家想要一辆更快的马车。这里我们不去讨论产品经理要不要去做用户调研,而是回到上个世纪初,模拟一下福特如果进行用户调研会是什么样的场景。

场景一:

福特:你们的需求是什么?

用户:我们想要一辆更快的马车。(表达期望,并没没有陈述事实以及表达感受)

福特:一辆更快的马车会满足你们的需求吗?

用户:是的。

福特:好的,我们会造出世界上最快的马车。

场景二:

福特:你们的需求是什么?

用户:我们想要一辆更快的马车。(表达期望,并没没有陈述事实以及表达感受)

福特:为什么你们希望要一辆更快的马车。(引导用户陈述事实)

用户:因为我们能更快的出行和运输,现在的马车出行和运输都很慢。(表达感受)

福特:所以你们是为了更快的出行和运输吗? (引导用户说出期望)

用户:是的 (说出期望)

福特:那我们可以创造出比世界上最快的马车还快的东西,你们愿意用吗? (需求逻辑产品化建模)

用户:当然愿意。

通过以上场景分析,我们在需求分析时,应该以why的形式引导用户说出内心的真实需求,用户的世界里面也许只有马车,但是你也许能为他造出更快的汽车。

How层:需求逻辑产品化建模

在why层我们已经明确的用户的真实需求,接下来需要在思考层面对需求逻辑进行产品化建模,为后续的需求价值判断做准备。

需求建模的方法很简单,在已知的产品模型工厂里筛选合适的产品模型进行建模,产品工厂参考如下图:

产品工厂中列出了不断拓展完善的基础系统和通用体系,在进行需求逻辑产品化建模的时候,最终的产品模型都是由这些基础系统和通用体系组合而成的,只要平时的产品学习进阶过程中有计划的去研习这些基础系统和通用体系的产品设计方法论,就能快速完成需求逻辑产品化建模。

很多产品同学接到新需求的时候往往不知道设计什么样的产品来满足,原因自己产品工厂里面的基本产品模型太少了。

2.1.2  需求(产品)价值判断

在完成需求逻辑产品化建模后,脑海里大概有了一个可满足需求的产品基本模型。这个阶段已经确定了需求的真实有效性以及有了基本的产品模型,接下来就是对产品模型进行价值评估。

一般的价值评估维度分为两个方面:

  1. 用户层面的使用价值;
  2. 商业层面的研发价值。

用户层面的使用高价值主要的分析维度有:1.用户规模;2使用频次;3.必要性;4.其他维度。

商业层面的研发价值主要的分析维度有:1.研发资源;2.研发成本;3.研发风险;4.稀缺性;5.其他维度。

一个需求(产品化)的是否有价值,做与不做需要根据用户和商业两个层面的多种维度综合判断。

2.2 需求立项

在进行需求价值判断后,筛选出的需求需要进行需求立项。

需求立项主要分为六个阶段:

  1. 需求优先级分配;
  2. 需求逻辑产品化;
  3. 初审(产品+需求提出者);
  4. 需求逻辑可视化(产品+需求方);
  5. 二审(需求方)
  6. 终审 (产品,项目,设计,技术,测试)。

2.2.1 需求优先级分配

需求立项的第一步,确定需求的优先级。一般判断需求优先级的维度有:

  1. 按照紧急程度(紧急维度);
  2. 按照价值权重(价值维度);
  3. 资源配置最优(资源维度);
  4. 按照实现难易程度(难易维度);
  5. 按照上级指示(老板维度);
  6. 按照需求产生的时间顺序(时间维度)。

一个需求的优先级判断通常是多种维度综合的判断结果。

2.2.2  需求逻辑产品化

与之前需求分析阶段的需求逻辑产品化建模不同,需求逻辑产品化建模更多是基于思考层面的,而需求逻辑产品化则是强调输出层面的,接到可行性需求后开始输出基本的产品方案,输出物包括但不限于产品蓝图(产品架构图),思维导图,原型图demo等。

这个阶段跟多的输出产品的大的可行的方案的框架,设计理念和产品逻辑闭环等,还没有具体到细节原型和流程图的输出。

2.2.3  初审会(产品+需求方)

需求逻辑产品化后需要开初级评审会,用需求逻辑产品化阶段的输出物向需求方介绍产品大方向的设想,如果评审通过则证明大方向上的可行性,不通过则继续修改复审。

2.2.4  产品逻辑可视化

初审通过后,接下来进行的是产品逻辑可视化。之所以会有初审的原因是,我们设计产品就像修建大楼一样,需求逻辑产品化就是确定大楼地基和蓝图的过程。如果这个过程没有问题,接下来的产品逻辑可视化就像装修添砖加瓦一样,不会有大的问题。反之,如果已经输出了细节的原型图和流程图再去评审,那么一旦评审失败返工将会花费大量的时间。

产品逻辑可视化阶段就是在确保大楼的地基和框架没有问题后,添砖加瓦的过程。这个过程主要的输出物一般是原型图,流程图&PRD文档等。

2.2.5  二审(产品+需求方)

二审是对具体的产品细节和流程细节逻辑进行评审,评审通过后就可以进入开发阶段了。这个过程中如果评审失败,产品经理只需要花很短的时间修改表层逻辑,不需要做框架层面的修改。

2.2.6  终审 (产品,项目,设计,技术,测试)

终审就具体的产品可行性进行评估,确定具体的项目排期计划。需求排期表最为一个基本的里程碑式的交付物,表示需求进入正式的开发阶段。

2.3 需求研发

需求研发阶段主要阶段有:1.设计&开发;2. 测试 ;3.验收;4.发布上线。这个过程中产品经理主要跟进需求的研发进度,以及保证整个过程中的信息对称,以及对一些突发的需求修改给出可行性方案。

2.4 需求归档

需求归档环节主要有两个过程,输出项目复盘报告& 输出迭代计划。

  • 项目复盘报告主要是对整个项目进行总结,取得的成绩以及存在的问题和不足。
  • 迭代计划,主要针对一些需要二次迭代的需求进行迭代计划输出。

截止到需求归档,标志着一个需求从需求分析到价值校验以及需求逻辑产品化到最后的研发上线归档全生命周期的结束。

三、关于能力批量化复制能力的一些思考

我始终认为产品经理拥有批量化复制自己能力的能力是一种很高级的能力,这篇文章以需求管理为例,讲的是产品经理何如模型化(批量化)自己的需求管理能力。不仅仅是需求管理,产品很多知识都可以模型化,框架化的输出。

衡量一个产品经理是否优秀,如果只有个一个标准的话,我觉得应该是看他是否能快速培养一个和自己同样优秀的产品经理,因为快速意味着你的所有知识输出都是基于方法论层面的模型和框架,就像需求管理引擎一样,掌握了这套管理引擎,所有的需求只需要交给大脑按照标准模式处理,实现真正的规范和高效。

这篇文章不仅希望大家能理解这套需求管理引擎,更希望读者们能培养模型化思维,拥有批量复制自己能力的意识,从而打造适合自己的需求管理引擎。

#专栏作家#

AllenDan, 微信公众号:思维改变生活,人人都是产品经理专栏作家。致力于研究高阶的产品学习方法论,从而改变职业成长的加速度变量。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 我相信产品经理的硬实力可以通过系统化的学习和不断的训练被复制,但软实力很难被复制,正因为此,才会有个体与个体间的差异

    来自上海 回复
    1. 是的,我没有描述好,常识让我们把产品做到60分,技术让我们工作从60分做到90分(精确算法),90以上就是艺术(模糊心法)了,可复制的能力指的是:60分~90分的能力。

      来自广东 回复
  2. 有没有 文中那些体系 和系统的学习资料

    来自陕西 回复
  3. 作者应该是总结了整个产品的生命周期管理过程,整体还是很系统、全面的,先赞一个。emm….这里我也有几点想和大家分享一下。why 层处作者应该是由于时间问题没展开来说,其实在了解用户的真实需求时,可以将需求分为几个层面来看。
    第一个,伪需求,就是作者举的例子,想要一辆更快的马车,用户的真实诉求可能只是追求速度上的增加,而非特指一定要更快的马车。
    第二个,未知需求,还是原来的例子,用户真实诉求就是要一辆更快的马车,那么我们是否还应该考虑:需要给马车配车夫?需要装上车帘子?需要装上舒适的椅子?这个是我们在做需求挖掘应该费工夫去考虑的方向。
    第三个,潜在需求,大部分用户提需求都是模糊、形象的,我们需要将它具体化,就是需求无限分解。拿一个花瓶来说,应考虑花瓶的尺寸多大?花瓶的材质是什么?花瓶是否要图案?图案的颜色?……无限分解需求目是需求没有二义性。

    来自广东 回复
    1. 嗯,需求分析其实是个伪命题。
      做用户产品,PM能接触到多少用户? 做业务系统,北区大佬要绿色,南区大佬要蓝色,PM那个都惹不起,听谁的?
      无论做什么产品,得是PM自己有能力设计主流程和规则,而不是翻译谁的需求。
      并且具备运营思维,掌握使用者的使用结果,对比产品KPI,分析偏差了那些,为什么偏差,再次升级系统

      来自黑龙江 回复
    2. 需求分析是个伪命题,这个好。所以乔布斯说最糟糕的事,就是倾听你的用户。只要不断章取义,我是特别赞同的。

      来自四川 回复
  4. 感谢分享!既然有自己的想法,就把3w改成2w1h吧

    回复
  5. 哥,能快速培养下我不?

    回复
  6. 呵呵 如果真的优秀,怎么可能快速被模仿学习?经验完全没用?眼界不需要时间积累?

    回复
  7. 哥,牛皮!能快速培养下我不

    来自广东 回复
  8. 学习了

    来自湖南 回复
  9. 标题;产品经理如何打造自己的需求分析能力,但是整篇文章讲的实际上是一个产品从需求收集开始到产品上线结束的整个过程。看目录:分析-立项-研发-归档,也就是一个产品的一个周期。和文章标题“如何打造需求分析能力”没啥关系,但是对于一个产品新手来说,不看标题,单看文章内容还是很干货的。

    来自福建 回复
    1. 原文章标题是:产品经理如何打造自己的需求管理引擎; 被人人的小编给改了。

      来自广东 回复
    2. 这么坑的小编

      来自福建 回复
  10. 回复
  11. 能简单论证一下你自己的观点么,蛮新奇的

    回复
  12. 分析的很清晰,非常感谢

    来自广东 回复
  13. 需求管理有哪些软件可以推荐?

    来自天津 回复
  14. 非常不错,给了我很大的帮助

    回复
  15. 非常认同

    来自广东 回复
  16. 优先度排序纬度挺多

    回复
  17. 常规流程,如果每个需求都能按照常规流程来就好了。

    来自上海 回复
  18. 有点意思

    回复