B端产品经理入门的第一年做了什么?
编辑导语:作为产品经理,你入门的第一年都做了什么呢?本文作者作为B端产品经理,为我们分享了他入职第一年,作为一个产品新人的一些经验和想法,希望能对一些刚入门B端产品经理或者对产品经理行业感兴趣的人带来一些参考。
今年年初我入职了一家医疗信息化行业的公司做产品实习生,在这里第一次接触到了B端产品经理的职位。
入职快一年了,从最开始零基础入行到现在确定未来的职业发展方向为产品经理,在这个过程种不断的会有朋友问到我一个问题,“B端产品经理这个职位是做什么的?”
我也发现在网上很少有对B端产品经理相关工作的详细介绍,尤其是B端产品新人们在做什么的信息更是寥寥无几,所以在这里将我自己将近一年的B端产品新人工作的内容分享给大家,希望能够对一些伙伴尤其是对B端产品经理职业感兴趣的伙伴提供参考。
一、懵懂入行
2月份顺利入职,我的领导是负责公司手术室麻醉信息系统的产品经理。
我来的节点正是公司要全面升级改版手术室麻醉信息系统的时候,所以在后面我会讲到我很荣幸参与到了这次公司新产品的设计过程。
此时这款产品的战略层目标设置已经完成,正在进行范围层和结构层的商议,这种商议当然暂时由于我只是实习生身份无法参与,不过这也刚好给了我补充产品知识以及熟悉公司产品的时间。
我在网上以及人人都是产品经理社区里查找了很多关于产品经理的碎片化信息,然后读了几本产品经理相关的书籍,比如《人人都是产品经理》、《B端产品经理必修课》。
这两本算是产品经理的入门书籍,这两本书让我对产品经理有了系统性的认识。其中,在《B端产品经理必修课》里作者对产品经理的必备技能做了如下归纳:
通过书中的技能描述及结合我的工作实际情况,我先学习了产品原型设计软件的使用、产品文档的撰写、项目管理的知识以及进行了一些软技能的磨练。
当然这些基本上都是在非工作时间做的,在工作时间我需要查找我们手术室麻醉信息系统产品所需要的资料、整理文档、维护旧版本产品以及使用产品设计软件画一些简单的弹窗等一些繁琐的工作。
同时在这些繁琐的工作中不断的学习产品的知识,了解业务的流程。这些不起眼的工作其实让我对新产品细节的了解产生了非常大的帮助。
二、渐入佳境
经历了两个月的琐碎工作之后,5月初,为了加快新产品的项目进度,新产品项目组进入到两个月的封闭研发阶段。
由于我前期的工作得到了领导的认可,领导在和我确定保密信息后,将我加入到了新产品项目组,这是产品已经处于框架层和表现层阶段了。
在封闭研发阶段,我第一次体会到了产品书籍中描述的产品需求从评审到设计到研发和测试的流程,我将其主要流程用流程图的形式展现给大家。
在上图中,最左边的文字代表角色,每个角色后面的流程节点代表该角色的工作内容。
我们看到产品经理首先将需求池中需要做的需求提取出来,随后进行该需求的设计,设计之后,需要由相关角色,通常是产品的相关干系人,也包括研发和测试,进行需求设计的评审工作。
如果评审没有通过,产品经理需要根据大家的反馈重新进行设计,如果通过了,就交由研发进行编码实现。
研发实现后测试会对该需求的实现情况进行测试,测试不通过会将该需求返回给研发继续编码,测试通过通常我们产品经理还会再进行验证,验证需求的实现效果是不是和我们设计时所构想的一致。
如果验证通过了那这个需求就算告一段落,如果验证不通过就需要继续和研发进行沟通,而这个阶段也是经常被大家调侃产品经理和程序员相爱相杀的时刻。
在封闭研发这个过程中,我在做一些页面的设计工作,通常由我的领导告诉我相关的需求背景和要求。
我通过产品设计软件将他的想法在页面中设计出来,如果是我比较了解的需求,当然这个阶段还是一些小的需求,评审、以及和研发、测试的沟通协调、需求的验证工作就由我自己来负责了。
经历了新产品的封闭研发阶段之后,我对产品工作的内容有了一定程度的认识,并且经过了这一段时间的积累对我们部门的手术室麻醉信息系统也熟悉不少。
但是这时候我却产生了一种莫名的离地感,这是什么感觉?又是什么原因导致的呢?
三、直面挑战
在越来越多的和我们的研发同事进行沟通的时候,我发现了问题,那就是在我们沟通需求的过程中,如果他问到我“为什么要做这个需求?他的业务场景是什么样的?”的时候,我不知道该如何回答。
在这期间我也去了一家医院给客户做了一次我们老版本的产品演示,演示产品对我来说没什么问题,但是演示完产品之后,客户关于产品和业务结合的一些问题我也不能做出最合适的回答。
这时候我已经意识到问题所在了,那就是缺乏B端产品经理很重要的一点要求:懂业务。
这里的懂不是在办公室点点产品、听听领导讲讲业务就算懂了,而应该是真正的作为使用者在真实的业务场景中了解业务、学习业务甚至尽可能实践业务。
没有真正的在业务场景中体验过,那在面对研发、面对客户、面对产品时就会有一种离地的漂浮感,是没有实实在在的底气去提出需求、回答问题和设计产品的。
于是我向我的领导提出我的问题,并且向他申请如果有机会能够去医院的业务现场待一段时间。
7月份的时候来了一个机会,一个医院购买了我们的手术室麻醉系统,但是公司实施人员紧张,实施负责人就向我们事业部申请人员支持。领导问我愿不愿意去,这是一次很好的在手术室接触麻醉医生真实业务场景的机会,但是需要做一些前期的实施工作。
这里给大家解释一些实施人员的工作职责,我们的软件在卖给医院之后,还需要由实施人员到现场为医院进行安装,按照医院的现场情况为其定制产品的部分功能,并且将手术间的硬件设备数据接入到我们的系统中。下图是我们实施人员工作的流程图。
这里其实就有了一个大家可能不知道的B端产品设计尤其是传统软件公司需要考虑的一个因素。那就是使用我们产品的除了我们的客户麻醉医生,我们公司内部的实施人员同样是我们产品的使用者。
我们产品在设计的时候也需要将他们实施的易用性考虑进来,提升实施人员现场安装调试产品的效率。
所以考虑到既然实施人员也是我们系统的使用者,为了体会我们的实施工作与手术室的业务场景,我就接受了这个任务,去了项目现场待了两个月的时间。
这两个月的时间是我收获最大的两个月,过程固然是很艰辛的,但是结果最终是好的。
从公司层面上来说项目顺利完成了验收,从我个人成长来说,我在医院的两个月深度体会了实施人员与麻醉医生的工作流程,从实施的角度和用户的角度都对我们的产品有了更深的理解。
四、输出成果
十月份从项目现场回来之后,我的整个工作内容较之前质量上有了一些提高。
第一点是培训,应培训部门和我们事业部的要求,我对我们公司没有去过医院现场的同事进行了一个主题为《手术室业务场景》的培训,以及对所有事业部的同事进行了一系列主题为《新产品功能》的培训。
这几次培训都是我将业务现场体会到的真实业务场景与产品进行结合进行的,都取得了非常好的反馈,被用来作为新员工的入职培训资料。
第二点是开始负责模块的设计,与之前简单的按照领导的要求设计页面不同了,领导开始将产品的某些功能模块交由我来进行设计,一些模块完整的逻辑实现以及展现甚至需要十几个页面共同组成,加上这些页面上的操作元素,在产品原型图的设计以及产品需求文档的撰写上来说更加考验逻辑的缜密性、业务的熟悉度、以及评审时的展现能力了。
第三点是审核合同标参,基于对产品的熟悉程度,我开始接触销售发往事业部需要由产品经理进行评估的合同标参。
同时这也是搜集现场需求以及市场需求的一个方式。我需要对合同中的标参项进行审查,然后将标参类别分为下面这几类回复到销售团队:
- 产品标准版标参
- 产品标本版需定制标参
- 产品高级版标参
- 产品不响应标参
并且在销售团队需要的时候,我们产品经理也会去医院现场对产品向客户进行更专业细致的演示和交流。
第四点是管理demo,研发同事会有属于研发人员的研发环境系统,测试同事会有属于测试人员的测试环境系统,而我们产品在不断设计以及完善过程中由我们产品部门使用的系统就是demo环境的演示系统。
我需要在这个系统中验证需求的实现效果,以及随着产品功能的扩充和完善不断保持demo系统中数据与真实业务场景的高度相似性,在需要对外进行演示时我就要带着我们的demo系统进行系统演示。
五、总结
从上面我的分享中我们看到,我的工作有了质的改变是在去医院业务现场待了两个月之后发生的,所以对B端产品新人来说,对产品业务的熟悉程度以及理解程度会直接决定你的工作内容。
尽快尽早尽可能多的接触业务对B 端产品经理的成长来说应该是非常重要的。
另一点就是去读一些前辈们写的产品的书籍,在这些书籍里前辈们会把他们的经验分享出来,我们在进行产品工作的时候,可以将他们的经验和我们的工作结合起来快速进步。
最后就是注意软技能的能力,比如演讲能力沟通能力共情能力等,这些都会在培训、评审、接触用户时直接对其他人产生影响力。
大家可能还会感到疑惑,为什么我也做了很多好像不是属于产品经理的工作?
比如售前、实施、培训甚至我没提到的参与到的旧版本产品售后的工作,其实如果是一个成熟的产品,可能这些工作不需要产品经理的参与,但是对于一款还处于全新设计中的产品,可能B端产品新人在庆幸能参与设计的同时,也必须要想办法通过其它工作来快速全方位的熟悉产品。
下一篇文章我就会详细的给大家分享一下这些好像不属于产品经理工作的内容,以及作为B端产品经理我们又能从这些参与机会并不会太多的售前、实施、培训、售后工作中提炼出哪些对产品工作大有帮助的内容。
我是小游,非常感谢能够阅览到文章结束的伙伴,欢迎交流,下篇文章再见!
本文由@小游不会游泳 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
很受用
我也是做手麻、重症的产品,可以一起交流交流啊
很棒
蟹蟹!
讲的贞不戳!如果产品已经很完善,那还需要产品经理干嘛呢?
哈哈是的