B端产品经理产品心得(二)

B端产品经理在设计过程中需要遵循一些原则,避免一些误区,不断提高基础能力。

一、B端产品经理需要遵循那些原则?

1)业务为基,产品思维展开;上一次是说B端产品经理都是以提升供应侧的工作效率的,所以B端需求都是以业务问题为导向的。作为B端产品经理一定要理解业务,根据业务的实际发展,用产品思维去梳理逻辑,设计产品工具来解决问题。有些业务同学会说,我希望要一个反馈功能,其实可能隐藏了一个工单系统需求。

举例:之前设置过一个编辑工作台,原来业务诉求说希望编辑能够在完成销售的菜品录入任务后给销售一个反馈。深入了解后才发现其实编辑都是通过线下邮件形式接受菜品录入任务和解决问题。设计思路如下:

按照我们上一个博客来说这个需求的话,我们面向是编辑和销售两个角色,需要设计两个角色沟通的通道,建立在已有的菜品录入平台上的一个任务处理平台(系统边界);

系统流程逻辑,销售发起任务,编辑认领任务或者上级分发任务,处理任务(任务正常处理和任务非正常处理),处理过程销售可监控,处理完成后,销售可投诉,投诉后的工单可再次被分发处理(任务流转节点设计);系统最小维度应该是工单任务;

编辑工作台,任务根据业务形态可能有多种,角色分为:普通编辑、管理者、销售角色,每个角色在任务节点所承担的职责,任务内容尽可能最大程度涵盖所有业务场景,用系统流程逻辑将这些角色和任务串起来,借助现有菜品录入台,完成整个工作台原型设计,以页面展示;

最后就是完善一些交互逻辑、权限逻辑,以文字形式将原型里面的图表、页面、功能点详细描述出来;

2)脱离了使用者的产品纯属扯淡,忘记了这句话出自何处了,但是这句话对我作为产品经理是具有指导意义的,产品改变了我们的世界,我们世界基础构成是一个个人,我们因为人的需求,才出来了一个个产品;所以在做编辑工作台之前我特地去编辑工作地方考察了一天,也在编辑工作台上线后的也去实地看了一天,最后发现编辑认领操作频率太高,要点击按钮才知道现在没有可认领工单,所以后期也补充了1分钟待认领工单条数更新一次的策略,虽然对服务器压力还是比较大的,但是解决了编辑一个实实在在的痛点;

3)降低系统的耦合性,提高可扩展性;在这个点上,我是实实在在吃了亏的,我刚进现在公司时候,其实是负责商业CRM系统的,我要重新改造一个审核流程,使其达到审核同时不影响业务下单,但是当前的商户状态和审核状态是同一套状态,耦合度很高,其实只要多增加一些审核状态即可,但是为了区分商户状态,所以增加了商户状态和审核状态的不同组合状态,实在是因为涉及到的东西太多,如果要改,基本上是系统重构了;这个事情说明了,系统设计之初,这个设计的产品经理完全没考虑那么多,才会造成产品可扩张性差。

二、产品需要避免那些误区呢?

扫描二维码关注公众号,回复: 63068 查看本文章

1)可扩展性差,重要的一点哟,不重复说了;

2)功能无边界性,这个也是产品经理误区之一,功能设计无边界性,就会拥有好多重复的相同功能入口;其实我做公共审核平台也是出于这样的出发点,目标就是给业务同学呈现了一个公共的审核入口,而不是不同业务审核有不同入口,这样造成的业务培训成本会很大;

3)确少前瞻性,新入行产品经理会认为针对本次需求这样,但是没有深入了解公司业务战略,为之后一些业务拓展,留一些业务入口;

4)产品功能设计太拘泥细节设计了,什么样子的功能都想以线上形式实现并支持,这种想法是不可行的,如果真实的业务场景此服务只有一个人使用,而且需求可能变化概率比较大, 那我觉得前期以最节省时间和资源形式先支持即可,不必做太过复杂的功能;

5)功能太繁琐麻烦,好的产品培训成本会较低,比如微信等,功能一目了然,主产品逻辑简洁有条理性。如果太过复杂,那就是为之后的功能更新埋坑;

三、B端产品经理需要拥有哪些能力?

1)逻辑能力,这一点上,理科生相比于文科生还是有很大的优势的,在我接触的过的优秀B端产品经理中,理科生会很多,而且也更受研发、测试、交互、业务同学欢迎,文科生在C端产品中会更容易显示文科生一些优势;

2)理解业务能力,对于业务的认知和快速面对能梳理出业务中的问题,不同公司可能业务不同,所以要求产品经理要能够快速理解当前负责的业务发展进程;

3)学习能力,活到老学到老,这句话对于当前社会的每个行业都是这样,变化的实在太快了;

4)沟通能力,因为产品经理是对产品负责,贯穿这产品整个生命周期,参与的人也比较多,如何协调好各个角色资源,从而达到产品最终的目标,这也是产品经理必备能力之一;

心得应该先到此为止了,下面我会将自己之前做的一个项目,详细做一个复盘;



猜你喜欢

转载自blog.csdn.net/water_color/article/details/80068408