1年半工作总结:B端产品经理需要注意的那些事(1.0)
从踏入产品经理至今,已经有1年半的时间了,本篇文章会总结一下我能感受到的自己成长点;其次,跟大家分享一下产品日常工作中需要注意的关键点。
一、成长点
考虑需求更加全面,提前告知业务风险点。
对于B端产品经理,很多需求来源于我们的业务方,他们会天马行空地跟我们说出很多需求。这个时候,我们需要快速地思考如下方面的问题:
1. 明确需求的合理性
这个问题需要回答的是要不要做的问题。
首先:引导业务明确地阐述为什么要做这个需求,如果业务只说结果,我们很难洞察到背后的原因。因此需要让业务描述出在什么场景下,遇到了什么问题,期望得到的结果是什么。通过了解背后的原因,可以探讨需求的本质。
其次:产品同学可以结合目前产品本身的功能,看是否有本身已经有的功能可以解决问题。如果没有,则分析一下需求的价值及合理性,很多业务提出的需求是伪需求,或者是在原本错误的逻辑上提出的解决方案,这种需求就不建议做。
2. 需求的优先级
这个问题需要回答的是该不该现在做的问题,很多需求是合理且有意义的,但不代表就要立马做,产品需要梳理本次需求的方向与产品的大方向是否吻合,产品本身是有自己的发展路径的,比如目前产品处于起步阶段,需要做到更多的是系统能力的搭建。
如果这时,业务提出比较大的活动引流玩法,在系统不够成熟的情况下,很容易造成系统崩溃,用户体验差,引流来的用户无法在持续地在系统上留存。这个时候,产品经理需要结合产品发展阶段给出需求在此阶段开发的合理性。
除此之外,在需求评估的时候,即使需求合理,也需要考虑使用的场景的频率和用户的使用范围,如果该需求无法成为后续可推广性的功能,那可以适当地把需求的优先级降低。
3. 是否有什么风险
在明确需求该做,且比较迫切时。这个时候,就需要发挥产品经理的洞察风险的能力,这也是资深产品和萌新产品经理很重要的区别点。
风险点一般出现在哪些方面呢?
- 提出需求的人,和真正的用户并非是同一类型的用户。提出需求的人,大多情况是站在管理者,平台方的角度。所以,站在他们的视角需求可能是合理的,但是站在真正使用者的角度,存在很多不合理或者体验不好的地方。这种情况,需要提出这样的风险点,避免需求上线后,真正的使用者不买账的情况;
- 需求要在哪个平台或者页面做,是否有权限的问题。这也是很多初级产品经理容易忽略的问题-权限问题,需要跟业务方明确,是允许哪种角色的人使用该功能。如本身系统无法满足该权限类别,这也是需求的工作量;
- 数据覆盖同步和覆盖问题,一旦涉及到数据问题,就需要系统之前的数据传递,需要提前告知业务,是实时同步,还是T+1同步,还是几个小时的延时同步,最好可以在后台系统上标明同步时间,避免用户产生歧义;
- 所有环节查看的数据是实时信息还是快照信息,一旦涉及到数据的修改,尤其是用户端已完成的数据,查看的是实时数据还是快照数据。这些都需要在方案阶段进行梳理,不同的决定方案,可能会影响后续的数据处理和存储方式;
- 重要行为用户行为操作记录,如商品的价格修改,上下架等业务认为重要的行为是否需要记录,并展示出来,这个也可以在需求沟通中明确要记录的用户关键动作,形成操作日志。
二、工作习惯
产品经理是一个信息的汇集地,每天需要输入,并输出大量的信息。在工作上多反思,每天给自己“长个记性”会让工作更加高效。
1. 数据的处理
很多产品经理在做需求时,只能考虑到此时,此刻的数据状态和现实情况,很容易忽略掉数据的动态变化过程。
比如,历史的数据该怎么处理?数据后续更改属性后,数据该怎么同步?数据删除后,该数据是否在前端显示,如果显示,用户端点击后,该怎么提示?A获取B的信息,B变动之后,A的同步机制是什么?
每次涉及到数据的处理,请默念【增】、【删】、【改】、【查】,每次条理清晰地把数据的状态分场景罗列清楚,开发和测试同时会爱上你的需求文档~~
2. 多思考异常情况
近期在设计优惠券在用户界面的展示逻辑,在设计这个需求的过程中,就需要产品经理结合运营诉求定义优惠券展示的排列规则。在定义好未领取的优惠券排序高于已领取的优惠券之后(目的:提高优惠券的领取率),就需要再对每一个类别的优惠券再次进行排序。
- 未领取优惠券中,新最发布的位置最高,发布时间以后台时间为准;
- 异常场景:发布时间按照后台记录的ms级进行记录,如果时间相同,随机取一个优惠券优先排列;
- 已领取优惠券中,最后领取的位置最高,以用户领取时间为准;
- 异常场景:当用户领取时间相同时(一键领取多张时会触发同时领取),顺序以优惠券的截止时间进行排序,距离结束时间越近的(即马上要到期的)顺序放在上方。
这些异常场景都需要产品在撰写需求文档的时候就要考虑清楚。每次在写需求文档的时候,多问自己问题,就会避免开发和测试同学来问你问题,也会让他们在读你需求文档的时候,觉得产品的思维是缜密的。
3. 可测试的场景
前几天开发问我,**需求的第3个场景在什么情况下发生?
这时候,我才发现我的场景3是针对于几个月后市场部推广成功后才会应用到的场景,因此,这种在开发和测试眼中就是“不可测试”场景。
这件事情也给我上了一课,产品经理可以把梳理的思路写到需求文档,但给到开发和测试沟通的文档一定是清晰、明确、可测试的。必要的情况下,可以提供如何达到这种场景的前置条件,方便开发了解场景的前因后果,也方便测试准备对应的数据。
三、小结
希望自己可以每天对工作进行反思,多总结,多归纳。不断磨练自己的思维。而且有一点点小的感悟就一定要记下来,这样每次写需求之前多看看自己的感悟,就可以规避很多问题,久而久之,能力就会提升一大截。
本文作者@黑心老巫婆 。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!