过滤业务需求,后台产品人请抗住最后防守线

最近工作太忙,在负责后台需求工作中总是会被一些临时的需求插入。甚至最尴尬的期间是当一个需求已经过了调研期进入开发周期,属于上一个迭代的需求临时被插了上来。这样的场景估计最常见的就是集合业务需求为中心的后台产品人了。

最近工作太忙,在负责后台需求工作中总是会被一些临时的需求插入。甚至最尴尬的期间是当一个需求已经过了调研期进入开发周期,属于上一个迭代的需求临时被插了上来。这样的场景估计最常见的就是集合业务需求为中心的后台产品人了。

那么如何做好需求过滤、抗住需求方的需求?注意的是这里的过滤需求、抗住需求不是拒绝需求,而是通过尽量减少原计划开发计划下解决需求方的问题,或者调节需求的复杂层度等等,我们可通过下面2个维度来考虑

一周一迭代,一周一需求

最佳的开发平时时间.

混乱的产品迭代往往都是需求临时插进来,优先级排不上找领导push 最终将需求优先级排上去。但又因加了新的工作任务,导致开发时间往后延期。好的情况是延期几天,坏的情况是反复的需求插进来、反复的延期。延期中,又因为业务或其他需求突然插进来。

因此,从事后台产品的同学我建议将需求周期化、级别化,除了需求能够以优先级来排列。我们还要将周期罗列出来,在这一个迭代能做的需求有哪些、下一个迭代能做那些。一旦以上的这样走上健康的需求流程,产品同学也会持续的平稳输出,开发同学也会稳重有序的落地需求。

优惠券的例子

优惠券降价与限时降价

比如公司一个产品线同学找到后台产品人,希望能够为了即将上线的新产品做优惠券管理的功能。在当前开发资源紧缺的状态下,分心思做任何需求都是可能导致开发进度延期。每个企业或产品都有不止一条产品线,如果以一个产品线为例来规划优惠券会出现需求不明确的情况。

之前有分享过关于优惠券的产品设计优惠券到底应该怎么思考?|案例分析,针对运营模块,优惠券的设计在那位同学的需求中其实很简单:需要一个能够对新产品做限时优惠、能够做数量控制,促进销量。

作为后台产品线,抗住这一个需求我提出了先阶段的解决办法,以设计文案中提出限时特价的方案。优惠券的运营需要计算几大元素

  • 优惠券数量
  • 总抵消价格
  • 总促销周期

优惠券根据定义不同,有周期性优惠券、静态优惠券(长期),但针对当前那位同学给我的场景来说,无非就是周期性的优惠券。

如何在不用开发的情况下,满足这个需求?至少能够为他促销做好支持?

那么是不是可以尝试用:限时特价的方案?仅仅需要修改设计文案就可以解决这个问题?

如果一个优惠券优惠300元,在当前场景中需要每一个同学都能够使用优惠券。那么即每一个产品都是限时特价,为此限时特价少300元其实可以带来同样的传递结果。

但针对用户行为,优惠券用户需要通过领取优惠券、使用优惠券、消息提醒等来围绕优惠券做一些辅助性工具。为此结合现阶段场景

  • 产品线可能还有变化
  • 需求提出方对优惠券使用单一
  • 开发资源紧张

为此,限时特价的方案完整的解决了该位同学的需求,很快的将一个需求“抗住了”。

这样的场景不胜枚举,为此后台产品同学在接到需求后要学会过滤、全局性思考。就像上周在周六开讲说过的一个案例:“赛马的问题”

一个用户说:“我希望一个更快的马”

b用户说:“我希望一个不颠簸的马”

C用户说:“我希望一个好养的马”

不合格的产品同学或经验浅的同学,首先考虑的是解决一个更快、不颠簸、好养的马

针对有一定沉浮的后台产品同学,给予的答案是:“给予用一个安全、舒适、跑得快、甚至能够给予用户彰显个性的马”

2个答案,体现了产品经理在需求过滤与调研中的思考点不同。这也是我们功力深厚的判别。

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表