新知一下
海量新知
6 5 2 3 1 9 7

B端产品新人,快速入门必读

王戴明 | 多年B端产品经验 2022/09/14 10:20

 

最近,有很多刚转型B端产品经理的星友,希望我能讲一讲:

1)如何才能更快上手工作?

2)如何才能圆满完成第一个项目?

今天这篇文章,就和大家分享一下我的经验,同时也分享一下:如何才能高质量的完成一个千万级项目。

可能有朋友会说:我做的是标准化产品,你给我讲项目有什么用?

其实,如果是针对大客户的标准化SaaS,那么从0到1的过程,就和B端项目并没有本质区别。

毕竟,SaaS的早期版本,也是要和标杆客户共创的。

01 新人如何快速入门

大部分公司,会给新人3个月考察期,如果期间没有工作亮点,试用期可能就会黄。甚至有一些公司,新人板凳还没坐热,就急着把工作甩过来。

这样的公司想法很简单:压力之下,产品经理自然会成长起来。虽然我不认同这样的理念,但这就是现实,作为新人的我们,必须积极去应对。

1、心态准备

新人首先要在心态上做好准备。

虽然“人人都是产品经理”,但是要成为一个合格的B端产品经理,没有一年以上的时间是很难做到的。

在这期间,我们很可能会遭遇焦虑。

焦虑不一定是坏事,毕竟“焦虑+复盘=快速成长”。实际上,几乎每个B端产品新人(包括你的领导)都经历过焦虑的阶段。

当然,只是自我安慰也是不行的。我们还需要给自己制定一个学习计划,每天尽量抽出固定的时间学习,这样才能实现快速成长。

另外, 新人在公司的地位往往比较弱势,所以我们更应该放下身段,努力应对基础工作,并且主动融入团队,从而给自己营造一个良好的成长环境。

2、工作准备

有些星友给我抱怨,一入职就要接手离职同事的工作,结果因为不了解情况,做的方案出了问题,还被领导批评。

其实除非我们经历过很类似的项目,否则不可能一来就做出完美的方案。所以面对这种情况,比较好的处理方式就是尽量争取领导和同事的支持。

新人入职,在对工作情况有初步了解后,一定要主动和领导沟通。

一是询问领导对自己的期望,从而了解后面的工作重点;

二是给领导汇报工作开展的思路,试探领导的态度,并询问能否获得必要的支持:比如安排同事对自己的方案提前把关,以弥补自己前期对工作的不熟悉。

除了获得领导支持,也要积极建立良好的同事关系。我建议,新人不妨放低身段,让同事意识到“我是过来帮助你的”,这样会更容易赢得同事的好感。

以刚才那位星友为例,如果他能积极与离职的同事交好,比如请同事吃饭等等,就有可能避开很多暗坑。

当然了,打铁还要自身硬。靠他人帮助,也只是权宜之计。最关键的,还是要尽快熟悉工作。

我个人建议,刚入职的新人在前3个月要辛苦一点,甚至可以主动多加下班。

这么做当然不是为了博得同情,而是为了尽快走上正轨,提高成功转正的概率。

在试用期,新人要利用一切时间做好以下三件事:

1)阅读产品文档

只要是和自己工作相关的产品文档或项目文档,都应该至少通读一遍,并做好问题记录,有机会就把这些问题一一搞清楚。

2)熟悉公司产品

如果我们的工作是产品的1到N迭代,或者是成熟产品的实施,那么公司产品就必须尽快熟悉起来。

当然,新人对B端产品了解不够,研究起来可能比较慢。在这种情况下,我们就可以想办法到一线去,请教下用户是如何使用产品的。

3)了解内部流程

方案如何评审?有哪些关键角色?需要做什么准备工作?

尽快把这些事情搞清楚,可以帮助我们少踩坑。当然了,很多公司并没有把这些流程文档化,所以我们需要提前建立好和领导、同事的关系,这样关键时候才有人拉我们一把。

02 如何完成第一个项目

如果运气好,新人可以从一个小模块做起,跟着高级产品经理逐步成长。但是如果运气不好,那可能领导直接扔过来一个项目,明明新人没有0到1的经验,也只能硬着头皮接下来。

我从事B端工作十几年,参与和负责过多个千万级的项目,我的感受是,如果要成功完成一个项目, 规范的项目流程和标准非常重要。

但是这一点往往容易被大家忽略。

曾经有一次,我给SaaS课程的学员讲解了项目文档如何编写,结果有同学反馈:按照新的文档结构,工作突然变得更顺利了。

新知达人, B端产品新人,快速入门必读

星友的留言

SaaS星球星友可以在知识星球APP的直播课帖子《 B端产品新人的第一个项目 》中,下载我整理的项目文档模板。

1、需求管理

需求管理不但是做好项目的关键步骤,也最能体现一个产品经理的能力。说白了,“问题”如果都错了,“答案”有可能对吗?

优秀的需求管理有三个要点,分别是:

1)调研文档

优秀的B端产品经理在调研之前,一定会整理好调研文档。调研文档的结构包括:

1.1)业务概况

包括客户的产品、销售额等等。

1.2)组织架构

了解项目可能涉及的组织和岗位。做项目表面上是搞定业务,实际上是搞定人。

1.3)业务详细说明

针对每一块业务进行详细了解。比如,采购管理业务就可以分别对供应商、招投标、采购订单等环节分别进行调研。

业务详细说明不仅仅有当前业务的详细阐述,还需要绘制对应的流程图。

1.4)管理报表

管理层是B端系统最重要的用户,因此一定要尽早调研管理报表。

1.5)现有系统

可能需要集成的其他业务系统

1.6)用户期望

这其实是非常重要的一个部分。系统能正常上线并运行,项目评分最多60分。而用户期望得到了很好的满足,那么就可能得到90分甚至100分。

因此,必须有专门的章节记录用户期望,并且在方案部分针对性的进行解答。

2)调研步骤

如果有条件,我建议尽量让客户提前按照调研文档收集资料和填写内容。

在调研之前,把客户提供的资料仔细读一遍,可以进一步完善调研思路和文档。正式调研的时候,我们根据新的调研文档和客户进行面谈,会大大提高调研的效率和质量。

调研结束后,我们需要对调研文档进行整理,并且和客户进行确认。

2、方案管理

1)方案编制原则

方案文档的结构也非常关键。总的来说, 需要遵守总分原则和对应原则。

所谓总分原则,就是一定要先写整体方案,再写详细方案。只有这样,才能培养我们的大局观,并且避免错漏。

而所谓对应原则,则是方案文档的内容要和调研文档对应。比如调研文档有用户期望、系统集成的内容,方案文档则必须针对这些内容,一一阐述相应的方案。

2)方案编制步骤

首先应该完成整体方案的编制,包括整体方案流程图、方案要点说明等。

整体方案除了可以培养我们的大局观,避免方案错漏,还可以作为给客户高层汇报的基础材料。这也是培养我们与高层沟通能力的好方法。

整体方案和客户确认以后,还需要编制详细方案。

详细方案具体又包括详细方案说明、流程图、流程图说明等。详细方案的内容必须与调研文档、整体方案的内容保持对应关系。比如,调研文档有供应商管理部分,那么详细方案也应该有供应商管理部分。

整体方案和详细方案完成以后,应该形成正式的文档,让客户签字确认。

即便合同没有规定签字的步骤,也要拉着客户一起把方案文档过一遍。这样,客户就很容易识别出其中的错漏。

3)原型文档的争议

如果是比较简单的系统,在确认方案时,可以一并把原型设计和客户进行确认。

如果是比较复杂的系统,可以先确认方案,再确认原型设计。

关于原型设计大家有很多争议,比如是否要把历史版本都归纳在一个原型文档中。

我个人建议是归纳在一个原型文档里面,主要有2个好处。

其一是便于追溯。当系统出现bug,我们可以很容易还原相关功能的迭代历史。其二是便于交接。当有新同学接手产品时,一个原型文档有利于他快速了解功能的完整逻辑。

另一个争议是原型注释要不要写得很详细。

这个问题并没有唯一正确的答案。如果整个团队特别是开发同学对系统逻辑、业务逻辑都很熟悉,整个研发团队也比较稳定,简单的注释也许就够了。

但是如果团队存在新人,特别是部分开发同学对系统逻辑、业务逻辑不是特别了解,详细注释的好处就体现出来了。

我以前负责的产品,上线后很少出现比较严重的bug,就是因为注释写得很详细,以至于开发同学的代码也会变得更加严谨。

详细注释还有一个好处,就是帮助产品经理梳理思路。实际上,对于复杂逻辑,只有写出来才能想清楚各种细节。

所以对于新人同学,我还是推荐详细注释。

 

  

更多“产品”相关内容

更多“产品”相关内容

新知精选

更多新知精选