从事于一家做生鲜配送行业 B2B 的公司的产品经理一职,公司主要依靠于生鲜商品二手倒
卖价格来进行营利,同时呢,也为生鲜行业的一些小商家提供线上解决方案。
对于产品经理,容我这 27 年的经验来揉搓揉搓。马拉松大家都知道吧,在这场运动中,
有人负责规划途径线路,有人负责途径中的营养补给…而产品经理就像是规划线路的人,
告诉运动人怎么去奔跑,告诉运动员前方有水有山,向左还是向右,到哪里是终点。
来到这家公司之初,leader 直接丢一句话:以后项目归你管。由你牵头,更新什么你来确
定,你来安排。每月给我汇报一次就行。留下的我默默不知所措…怎么去做呢,容我徐徐
道来~~
1 想快速了解业务,首先得了解公司的组织架构。为什么这么说呢,组织架构下部门的工
作是按照业务拆分重新整合在一起,了解部门是做什么的,那么这个部门的业务,在公司
中充当什么角色也一目了然了,以及部门当前业务面临的问题是什么(这对你后面做需求
很重要)。当然还有一条,与其被动不如主动了解。试想一下,自己默默的看一周的企业
资料和主动与部门沟通,哪一个更好呢。
2 需求收集。每周定时花时间,主动沟通了解各部门对目前系统的改进。然后结合自身对
于系统目前逻辑判断是否可做。当然啦,作为专业的产品经理,只从部门了解需求是不够
准确的。一定一定要多去和终端客户沟通,这些客户的需求能给你带来很大的影响。作为
生鲜行业,还是 toB 的生意,很大一部分客户的年龄普遍在于 50 岁以上。这就会影响我
们产品的字体是不是应该更大些啊,能不能支持语音搜索啊等等。还有来自老板的需求也
很重要,但是老板带来的往往是战略上的需求,可能需求很长时间才能达到,那么目前怎
么把产品接近呢,也是需求产品经理思考的问题。
3 需求分析。问题也收集啦,怎么办?改!如果以前工作做的很好,也轮不到我来找问题 。
期间做了一个叫做“sku”分析的功能,这个功能一听也不难啊,无非就是找找计算的规则。
但是呢,当时我们的服务器内核小,运行慢。而我们的 sku 就高达二万多个,每种 sku 需
要计算占比、销售额、重量、排行、动销等等指标就高达 10 多个,怎么在查询速度慢的
情况下又不影响体验呢。后来和需求提出人详细沟通,原来啊,有些指标需要优先看到,
有些只需要能看见就好,而且呢,还希望先看到分类的占比。了解这些,我们是不是就可
以先按分类展示啦,这样不会影响速度(毕竟分类不过 20 个),而分类下的 sku,可以
从分类展开。这样就完美的解决问题啦。
4 需求文档。最开始工作的时候,对于技术不按照文档开发,那是相当的气愤啊。出了问
题他说,产品没说啊。我说,文档上有啊。他说,哦,忘了。看到这里是不是很无语,一
股怒火中烧啊。
产品的本质就是保证产品的质量,保障用户的体验。在和用户沟通时,多听听技术的意见
让技术同时参与进来。开发过程中,也要积极保持沟通,对于技术提出问题,最快速度响
应。
什么样的需求需要写文档?涉及业务、页面、体验、逻辑特别多的,一定要准备好原型和
文档。当然啦,这种情况也需要和技术同事沟通了,毕竟看文档的是技术同事。
5 需求会议并跟进执行 在会议之前,一定要做好需求准备。因为面对技术同事、领导的问
评论0