作为一个产品经理,你会如何优化自己的需求池?

作为一个产品经理,你会如何优化自己的需求池?
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 97 浏览
  • 略问用户 提出于 2021-01-16 09:53:15

58 个回答

xxxxxa

首先,我觉得我们说优化需求池,不仅仅是优化这个池子,真正优化的应该是从需求的收集到最终形成功能融入到产品中的这个过程。所以接下来我按照这个思路来说下我认为的好的流程。


一、需求收集

  • 从用户、市场、竞品、同事、朋友等渠道 无差别 的收集各类问题、建议、与想法,另外通过数据分析和解读出来的需求也可以添加进去。
  • 尽量详细的记录需求的相关属性信息,如提出人信息、需求场景、需求描述等等。


二、需求分析

针对上面的采集的需求,我需要进行初筛和评审。


1、初筛

产品经理每天(或每周)对需求池中的粗略的筛选。主要做以下几件事:

  • 删除不合理的、无用的需求;
  • 按照不同的类型进行标记。这个根据产品情况自定义,可以按转化阶段来分,也可以按商业模式或者功能的模块来分,也可以同时多维度标记。
  • 对可行性、优先级、价值进行初步的评估。


2、评审

将初筛过的需求,每周固定的时间和与该产品核心关联的运营、市场、技术以及其他一些核心领导在固定的时间进行评审,评审的原则大概如下:

  • 与当前产品阶段策略符合度高的优先级高
  • 与产品核心流程相关度高的优先级高
  • 投入产出比高的需求优先级高
  •  ……

我个人认为对于需求池来说,最重要的就是这一轮评审,因为参与的人包含了产品的环节,对需求的评审会更全面和精确,避免了产品经理自嗨的一些需求。另外,产品开发完成后,后面与运营、市场的衔接也会更好。


三、功能提炼

根据当前产品的路线规划与需求的优先级等因素进行结合,来进行新功能的提炼或者原有功能的优化迭代,并制定相应的版本规划。


四、功能设计

到这步,需求已经完全清晰,需要做的就是产品功能的设计了,原型、UI、技术方案等等。

请先 登录 后评论
xxxxxa

为什么要有需求池?

需求池主要用来缓冲各种资源与限制,另外也是重新评估需求合理性、优先级,防止产品无限度庞大起来的最好机会。需求池要做到有进有出、宽进严出。

优化需求池也是优化筛选各种需求、评估需求价值的过程, 是需求管理的一部分工作;

我理解的需求管理:

需求管理一般分为需求收集、筛选、需求优先级定义、需求工作量的评估、需求变更管理等多类内容。

我的需求搜集方式:

1、几乎每天要有两个小时左右回复用户在友盟、QQ、微信、微博、论坛提出的各种反馈。主动的、被动的找到用户反馈,了解当前用户的产品使用问题;(因为做的是某运动轨迹软件,经常会在微博上查看用户分享出来的轨迹图是否出现轨迹漂移、中断;分享的时间段;是否有吐槽等内容)

2、找到问题后要及时了解出现该问题的原因,以及如何解决、如何防范该问题,以及如何防范类似问题;并当天回复用户该问题的进度;部分不能及时解决的问题要提交工单;(记录问题反馈用户ID、昵称、机型、系统版本、产品版本、反馈日期、问题类型、反馈描述、反馈解决、解决状态、备注等信息)

3、一些不能也不好解决记录问题,列入待办需求列表(记录记录人、产品模块、问题描述、使用场景、功能点、紧急重要程度等)

4、 定期整理优化代办需求列表;

5、潜水在竞品、泛竞品的用户群(微博、QQ群、微信群),了解竞品用户反馈的问题、以及竞品状态等信息;

6、与产品老用户、目标用户、小白用户等沟通,了解用户使用产品的来源渠道,初衷,以及期待的功能;判断是否与产品定位的目标用户群一致等,顺便作为评判渠道质量的依据之一。

7、不定期跟踪竞品状态,比如版本更新文案、功能更新点、PR文章、渠道下载量、关键词排名及覆盖率;

我的需求池优化方式:

1、删需求(不符合产品定位的需求、随时间变更已经无意义的需求、技术无实现可行度或者代价得不偿失的需求),需求池的瘦身;

2、合并归类需求(相似度较高的需求、由一个需求引发的关联需求、功能类需求、体验优化类需求、bug等),形成需求逻辑树,继续瘦身;

3、需求优先级归类(需求优先级预估、功能点预估、技术工作量预估、版本预估),形成初步版本需求迭代规划;

4、不断的重复以上过程。

请先 登录 后评论
xxxxxa

首先得找一个强大的工具 excel ,将需求经过筛选,有的需求不符合常理可以不接,需求确定之后,录入进去。

字段包括:

时间:提需求的时间

需求部门:提需求部门

需求人:提需求的人

需求简述:简单概述提的需求

对接部门:工作的部门

对接人:对接的人员

重要紧急程度:重要紧急、重要不紧急、紧急不重要、不重要不紧急

产品时间:产品画原型、写文档时间点

设计时间:设计师出稿时间点

开发时间:开发时间点

测试时间:测试需要时间点

上线时间:上线时间点

备注:这个过程中有什么问题,怎样改,是否延期等等

这个只是自己的需求池,不涉及真正给各个部门真正排期,如果真正排期,需要更复杂一些,会去掉一些需求相关的字段。

后边的时间点,是真正评审通过之后填写,前期只需要写需求相关的部分,如果需求评审没有通过,后续就不用写了。

并且需要定期更新表格。

请先 登录 后评论
xxxxxa

新人根据半年多的产品工作经验和老大日常做需求的讲到的一些东西,和大家分享下一些心得和想法。

需求.png

     我们老大经常说的一句话我觉得很有用分享给大家,如果一个功能,这个版本排不上,下个版本的时候你又想不起来,这个功能肯定不是重点,甚至是可以放弃的。

     需求池,顾名思义,就是把很多需求放到一起的东西。然后,在规划版本的时候,从池子里捞出几个需求,排一排,搞个版本开发。

  当一个产品一旦开始,就会有很多的需求冒出来。很多人自然就想到说,这些需求,先收集起来,然后,等有时间的时候再来排一排,算一算,做什么,怎么做。

  这个思路,看上去很自然,也很科学。需求池这个东西,很多产品经理都想搞,很多团队也想用。

  不过,我们真的需要这么一个需求池吗?

  我认为,实际上,我们完全不需要这个东西。需求池,是一个看上去很美好,实际上意义不大的事情。

  首先,任何一个产品,都是变化很快的。不论是市场环境,用户行为,产品演进。

  这直接意味着,需求实际上是在不断变动的。就像我之前说的,「需求应该是自然而然的」。

  换句话说,这个时间的需求,再过一段时间,已然变化了。

  其次,我们一直在说抓重点,做亮点。这句话很好理解,也很好说出来,不过,核心难点在于,怎么判断是不是重点?

  我有一个武断且奏效的办法,如果这个功能不能总是在你脑子里留着,这个功能就不是重点。

  如果一个功能,这个版本排不上,下个版本的时候你又想不起来,这个功能,肯定不是重点,甚至是,可以放弃的。

  这个方法,我一直用,看似很武断,实际上,很好用。

  我之前说,不做什么比做什么更重要。很多时候,产品经理的困难在于,从100个功能里只挑3个出来做。

  一样的道理,选择越多,选择就越困难,需要从需求开始的时候就筛选,而不是为了筛选去筛选。

  当越来越多的工具出现时,你会发现团队使用的工具数量已经快要超过团队成员的数量了,其实我们需要的只是让团队成员之间能够很好的协作和沟通的工具而已。

  就像一个朋友说的,「需求池,难道不是用来安慰那些提了需求却没被接受的人吗?」

请先 登录 后评论
xxxxxa

需求池.png

直接上图最能表达意思。

1、优先级。需求的轻重缓急,怎么分可以根据个人喜好来定, 重要、紧急、不重要、不紧急4种组合下。

2、需求申请。即提出需求时间。

3、需求描述,提出需求要解决什么问题。

4、提出部门。哪个部门的需求。

5、设计到的产品线。

6、需求方案。即需求方案确定的时间。

7、是否需要设计。

8、开发、测试、上线时间。

9、预计上线为排期时间。

10、需求状态。新提的可以写待评估,开发的就开发。完成的完成,用颜色填充注明下就好。

11、需求对接人、技术对接人。

12、产品负责人。

13、设计师。


问题是如何优化需求池,而需求池是管理需求的表格。

即真实需求是如何高效管理自己的需求。

那么,有这几点:

1、每处理完一个需求及时更新表格。

2、每周5下班更新一次本周的需求。总结本周对需求的操作以及需求状态,上线X个、移交开发X个、新的需求X个、本周处理了X个需求、待处理需求还有X个…… 。

3、当有新的需求来的时候评估优先级。

4、表格按完成状态排列、按优先级大小排列。


要优化需求池是一个非常考验耐心和细心的事情。把每一个需求所包含的要素体现在需求池里这样就OK了。

请先 登录 后评论
xxxxxa

需求池是产品经理用来管理需求的,是工作职责中重要的一个环节,而市场上的需求是瞬息万变的,因此在思考需求池该如何设计的时候,我会考虑到管理的便捷性与积极性,毕竟对产品经理来说,更新需求池是一个高频的需求。

要提高便捷性与积极性,就要做减法,确保留下来的字段,都有其意义的。

需求池目的是管理,而非单纯的收集,管理是动态的,从哪里来,往哪里去,如何从感性得来的需求,转换成理性的文档输出理性的同事,反之。因此我在记录的时候会分两方面。


以下是我自己管理的需求池表格,可供参考。

理性:影响指标(注册,留存,销量等等),需求的坐标(端,版本,频道,页面,模块等等),状态(待开发,开发中,已完成,验证中等等),结果(验证后的情况记录)

感性:需求描述(以用户故事的方式阐述,基于假设)、需求优先级(以当前阶段所需,作出判断,基于主观)

请先 登录 后评论
xxxxxa

进池子前,已经过滤一边了。

主要过滤的基本都是臆想需求

怎么判断是不是臆想的,看最初的产品定位,背道而驰的肯定咔了。

还有就是需求来源是什么?不是谁的需求都应该满足的。


开始搅池子了

抽象的说就是重要紧急、重要不紧急、紧急不重要、不紧急不重要

太抽象了,我想很多PMer都不能准确划分。

运营说,这个重要快该,用户那边催着呢,是真的很重要吗?

在有准确数据分析的前提下,当然可以尽量保证,但是没有数据怎么办?

靠PMer自己的经验,靠之前定好的产品发展线、靠产品方向不跑偏。


归类方法反正都大同小异,公司模版也不一样,没有的话,从做个表格开始吧。


想到什么,就说点什么。。

请先 登录 后评论
xxxxxa

1、考虑需求池,一定首先考虑产品范围和产品原则。界定清晰的产品范围和产品原则,需求池不会太大。

2、一般我的优先排序考虑点:产品的独特价值主张、需求来源、场景还原、团队资源等等;

3、与运营人员和商务人员沟通获取信息。

4、与用户沟通。(一般会和产品用户建立友好联系。

5、主观判断。

当然最后以上说的都没啥卵用,因为大多时候需求来的都那么的急,很多时候也是没办法。但需求池还是有必要去管理的,这样有助于自己对产品全局的把握和更深入的理解。

请先 登录 后评论
xxxxxa

需求池是存放跟产品有关的未来可能会做的功能点子的地方,拿我们的产品来举例,在道长的需求池里面,会在现有“展览、发现、我的”三个帧上面增加一个帧,暂且叫“碎片”,这帧是未来给用户带来跟艺术相关的内容,呈现方式是文字、图片和视频,内容形式包括艺术家/策展人/批评家/达人专访。

我对需求池的建议有两点,第一是不必考虑能不能做或者是做了没用什么的这样的限制,先不必设置伪命题,只要是觉得OK的,都先列出来;第二点是最好用xmind来做,每个点子是属于哪一个模块的,如果是已经做了,标记出来,这样方便检查和对比。

不过,我们真的需要这么一个需求池吗?

首先,任何一个产品,都是变化很快的。不论是市场环境,用户行为,产品演进。这直接意味着,需求实际上是在不断变动的。就像我之前说的,「需求应该是自然而然的」。换句话说,这个时间的需求,再过一段时间,已然变化了。

其次,我们一直在说抓重点,做亮点。这句话很好理解,也很好说出来,不过,核心难点在于,怎么判断是不是重点?我有一个武断且奏效的办法,如果这个功能不能总是在你脑子里留着,这个功能就不是重点。如果一个功能,这个版本排不上,下个版本的时候你又想不起来,这个功能,肯定不是重点,甚至是,可以放弃的。这个方法,我一直用,看似很武断,实际上,很好用。很多时候,产品经理的困难在于,从100个功能里只挑3个出来做。一样的道理,选择越多,选择就越困难,需要从需求开始的时候就筛选,而不是为了筛选去筛选。

当越来越多的工具出现时,你会发现团队使用的工具数量已经快要超过团队成员的数量了,其实我们需要的只是让团队成员之间能够很好的协作和沟通的工具而已。

就像一个朋友说的,“需求池,难道不是用来安慰那些提了需求却没被接受的人吗?”

请先 登录 后评论
xxxxxa

新人一枚,随便谢谢自己平时是如何管理各产品线的需求内容的:

1、首先要准备好一个很好的管理工具,一般都会选择excel工具

2、将需求按照提出人、提出时间、提出人、需求类型、需求描述、优先级、设计产品线、需求现阶段等主要因素按照一定的顺序创建所需的表格

3、需求池整理,及时记录每个需求,意向的、部门反馈的、竞品中存在的等等。

4、需求筛选,基本上每周或者每天都要去筛选一遍需求池,及时的更新各条需求的状态

5、每周根据各部门反馈信息的紧急程度、当前开发任务等情况,将需求池再进行下一步的筛选和更新,这个过程主要是其他部门人员和内部人员的沟通

6、根据已制定好的需求排序优先处理已安排内容,若有中途插入需求则需根据紧急程度,临时变更需求处理的时间安排

请先 登录 后评论