销售新人培养方案(吸引人气的营销方案)

本文总计 4414 字

阅读完需要 8 分钟

背 景

·项目背景

由于疫情的爆发,A公司的线上教育Web App涌入了一大批新用户,直接解决了App的「拉新」问题。

考虑到这批用户是与「疫情」高度相关的精准流量,且A公司目前对新用户「转化」的能力一般。

因此,打算打造一个名叫「疫情前线」的疫情内容聚合页模块,来对这批用户进行「留存」。

·我的角色

因为这个项目的评级是「不紧急不重要」,且当时产品经理在忙其他更重要的项目。

我有幸成为了这个产品模块从0到1开发的「负责人」。

·成果

整个产品模块从0到1在9天内上线,DAU最高近10万,0客诉且0宕机。

需 求 立 项

需求立项,是决定一个想法是否能够成为产品需求的阶段,主要分为以下4步,在介绍需求调研之前,先讲BRD撰写,理由后面会讲。

·BRD撰写

我觉得产品新人最容易踩坑的地方就是「各种文档的撰写」,因为许多产品新人遇到这种文档时不好意思问产品经理。

的确,做产品非常看重学习能力,如果拿这种基础的问题去麻烦产品经理的话,产品经理会认为你学习能力不足。

所以,我当时是自己去网上搜索「如何写BRD」,我发现,网上的这些回答可能是为了尽可能全面,会把一份BRD需要的全部要素的罗列出来。

如果真的按照网上说的写,长篇累赘,无非就是2种结果:

1、自己不愿意写;

2、别人不愿意看;

这种情况下,最好是能找产品经理要一下先前的BRD模板,我发现,真正的BRD无非就是3大板块:

1、用户需求:这个不用说,所有的产品创造出来都是满足用户需求的。

2、商业需求:咱们做的是商业产品,肯定得考虑商业需求;

不过,商业需求不一定是「赚钱」,占据市场有利位置,打压竞争对手都可以是商业需求。

3、开发实现:也就是开发能不能够实现这个产品构思,可以从开发技术、排期和硬件实力等出发;

打个简单比方,假如咱们造出了一款有着1000万日活的产品,但是咱们的服务器带宽只能承载10万用户,这势必会极大的损害用户体验。

·需求调研

明确了这3点之后,就可以开始需求调研了,按照一般流程来讲「需求调研」应该是产品开发的第1步,但由于我第1次做完整的产品,我倒是觉得先从BRD开始能够让我明确「我为什么要做需求调研」。

根据BRD文档的要求,不难看出。需求调研主要分为两大方向:

1、用户需求:我直接找了A公司的几个粉丝群,通过「群提问+私聊」的方式,确定了用户的大致需求点,并结合「群投票」进行筛选;

我发现,用户中有很多是上了年纪的叔叔阿姨,发现他们由于「搜索能力一般」,很难在海量疫情消息中找到自己想要的,为此,我决定做一个「疫情相关内容的聚合页」,简化他们的搜索成本。

2、商业需求:正巧,App的二级入口「免费课程专区」需要迭代,这个专区最开始的用途就是「留存」,这个需求可以做为「免费课程专区」的一个迭代。

3、开发实现:前端、后端、UI的排期都不是很紧张,服务器压力也不大,交互、联调、接口都不复杂。

·需求评审

这一步主要是将BRD放进「需求池」中,由产品经理来考虑要不要实现这个需求,要实现的需求会组织相关人员开展评审会,并按照「紧急-重要」2大维度对这些需求进行简单评级,如果是简单需求的话可以不用写BRD。

疫情期间,A公司大多数关于「疫情」的需求都开了绿灯,我这个项目很荣幸进入到了评审,我觉得需求评审最重要的是2点:

1、证据充足:很多时候产品经理会直接问你“这个结论怎么得出来的?”要准备用户的微信截图以及相关收集到的数据作为证据。

2、懂点技术:出席评审会的并不止产品经理,还有设计跟技术相关负责人,他们会说一些专业术语。

设计说的一些专业术语还好,关键在于技术负责人的术语体系,没有提前学真的比较难理解。

所以说,“懂技术”并不是要你去学那些专业代码,而是要懂得技术说的那些术语:联调、复现、排测……不然你听不懂技术说啥。

·团队组建

我感觉在当时的评审中,自己表现是比较差的,好在产品经理圆场,我的需求才没有被毙掉。

需求通过之后,就进入到团队组建,技术负责人跟设计负责人会确定自己手下成员的排期,根据项目配置前端、后端、UI、测试等人员,并成立攻坚小组。

竞 品 分 析

我觉得竞品分析应该算是产品设计流程中最复杂的模块之一了,当然,这并不是因为这个模块执行起来很困难,而是因为竞品分析的可延展性太强了。

产品经理跟我说过:“天底下很难找到同一份竞品分析。”所以说,做竞品分析,最主要的是要明确竞品分析目的。

主要分为2大板块:

1、宏观:比方说产品战略或者是KSF(关键成功要素)分析,宏观分析主要是从0到1的产品或者是产品高层做分析,产品新人应该很少用到。

2、微观:主要聚焦于产品3大要素——功能、可用性(也有人说是“易用性”,我倒感觉差别不大)、性能,咱们产品新人竞品分析的主要板块。

回到实际,当时我对产品模块的定位是「疫情相关内容的聚合页」,但并没有确定具体的功能模块,所以我竞品分析最大的目的就是“根据竞品,确定现有产品的功能模块。”

当时主要参照了“丁香医生”和某在线教育平台的功能分布,确定了我们的功能要在2者的基础上「做加法」,将专区内容分为视频、新闻、疫情数据、防疫知识、防疫课程五大版块。

并参照竞品分析对这5大板块的界面布局和UI进行大致设计。

敏 捷 开 发

可能在很多人眼里,需求调研跟竞品分析完成后,就可以马上开始画原型图了。

但产品经理告诉我,如果是简单的需求,确实可以这样做。

面对像我这种产品模块的整个迭代,如果马上开始原型图的话,会遇到以下三大问题:

1、由于需要做的需求很多,原型图会过于庞大和复杂,不利于沟通和理解。

2、没有MVP,无法在第一时间测试这个产品模块用户是否真的能接受,可能辛辛苦苦做出来,最后竹篮打水一场空。

3、设计跟技术的排期会过分集中,这样一来不利于团队士气,二来也降低了工作效率。

所以当时我采用了敏捷开发,这个概念其实不难理解,就是将一个完整的产品项目拆分成各种各样的不同迭代版本。

每次都只实现这个完整项目的一小部分功能,进而通过一次次的迭代来完成整个项目,概括起来就是8个字——小步快跑,快速前进。

要想实现这一切,大致要经历如下流程:

·需求分类

一个产品是由无数需求组成的,这些需求不可能每个都去实现,所以,首先要对这些需求进行分析。

一般分析的维度有两个:重要和紧急,按照两大维度,可以划分出4个区域矩阵:

1、重要且紧急的需求:从数量上讲不会太多,他们往往是迭代中的核心功能,因此,可以以这些功能为核心划分出不同版本的迭代。

2、重要但不紧急的需求:很可能是刚才提到的重要且紧急需求的辅助功能,往往根据之前的步骤划分好迭代之后,就可以将这些重要且不紧急的需求划分进不同的迭代。

3、紧急但不重要的需求:大都是项目开发的其他参与者提出来的,要想解决这一需求,能跟当事人沟通争取理解,就尽量跟当事人沟通。

也有可能是产品经理对这个需求认知不足导致它被划入了错误的区间。

4、不重要但不紧急需求:那就更好处理了,直接抛弃掉即可,但是要建立需求的储备池,在池子里面备注为什么这些需求就会被抛弃。

·确定迭代

将这些需求进行逐个细分之后,就可以开始确定各个迭代了,确定迭代一般以重要且紧急的需求为核心,将与他们有关的其他需求进行逐个划分即可。

我当时划分迭代用到的是“卡片分类法”,也就是把所有的需求都写在一张又一张的便利贴上,将这些需求进行多次的划分,然后开会与相关人员讨论这些划分的合理性,最终找到最适合的。

·原型+PRD

确定好迭代之后,就可以开始画原型图,写PRD了,关于原型制作,网上有非常多详细的教程,我就不讲具体细节了。这一步骤和普通的产品开发基本上没啥区别,唯一不同的是,普通产品开发需要将整个产品模块都做出来,但在敏捷开发中,你只需要将现阶段迭代的产品原型做出来即可。

也不用太纠结工具选择问题,不管是Axure还是Visio,甚至是网上大火的Processon和墨刀,基本都属于所见即所得的简单工具,就算没有任何基础,画画低保真原型也不会存在什么困难。

我觉得,作为一名产品新人,在画产品原型的过程中最需要注意的是极端情况。

比如说我现在有一个输入框,是用来输入用户的昵称和密码的,相信这种原型能非常简单的做出来,但最重要的还是要考虑两种极端情况:

1、用户没有输入昵称和密码:这种情况你不能单单的认为是用户没有输入,有可能是用户的手机输入但是卡了,或者是说用户的输入设备出现问题,还有一种情况就是输入框只支持英文输入用户却输入了中文。

情况有很多种,遇到不同的情况,怎么去引导用户走到正确的道路上才是一个原型真正要考虑的地方。

2、用户输入了N次都不正确:这种情况,可能是黑客正在尝试暴力破解网站,也有可能是用户记错了用户名和密码,先不讲具体提示信息如何,这里面光是对用户访问设备的MAC标识码识别就很大学问。

不要被吓到了,我当时第1次自己做的原型也是bug一大堆,好在当时我的产品经理帮了我,才不至于在评审的时候被开发骂个狗血淋头。

·需求评审

这里的需求评审,跟我之前讲的需求评审基本上是一模一样的,唯一不同的是,参与人员不单是相应模块的负责人,还有之前组建的攻坚小组中的成员。

他们会给你反馈一大堆问题,如果这些问题基本上都能得到解决,那就可以进入开发阶段了。

·排期

开发阶段的主要工作在设计和技术中间,产品助理唯一要做的工作就是给技术跟设计排期。

所谓排期,就是画一张甘特图来安排设计和技术什么时候做什么事情,这里面需要对技术跟设计的一些术语作了解。

一般的流程是这样的:首先,UI根据原型图制作各个图片零件,UI作图同时,后端也可以开始数据库的工作,切好图之后交由前端去做出来,前端做的同时后端也可以着手进行数据库的测试。

当前后端的工作基本全部完成的时候,前端和后端双方的接口对接,开始联调,联调没有问题之后,测试组开始进行测试。

可能看起来工序还是蛮多的,但如果产品助理排期排得合理的话,其实完成这些可能仅需要2天。

·测试

如果测试测出来基本上没问题,那就可以着手发布测试版了,测试版一般分两种:阿尔法和贝塔。

阿尔法版一般指的是内测版本,也就是说,将我们的产品开发好之后,直接丢进员工群里面进行测试。

贝塔版指的是公测版本,员工内测没有问题之后,再丢到核心粉丝群里面进行测试。

·灰度上线

当贝塔版测试出来没有问题之后,就可以准备灰度上线了,灰度上线是腾讯创造出来的一个方法,指的是一个新功能在上线时仅覆盖极小一部分用户。

在这批用户使用没有任何问题的情况下,逐步扩大用户群,直至所有用户都上线这个新功能。

经历这样一番下来,相信初次迭代就可以完美的上线了,然后,在这个过程中收集用户的反馈,按照同样的流程进行下一次敏捷开发,让下一个迭代顺利上线,这样整个项目就基本上完成了。

敏捷开发 的 繁与快

跟你一样,第1次接触敏捷开发的时候,我感觉它的流程又长又复杂,但只有实际操作后才发现,虽然工序变多了,但每个工序的完成都变得非常简单。

原有的开发方式确实工序会简单很多,但由于将众多需求压缩进了一个迭代,不管是产品经理画原型图,还是技术跟设计去实现都要花很多时间。

敏捷开发通过将复杂项目拆分成各大模块,简化了多方的工作量,进而提升了效率。

如果您有更好的建议,欢迎添加我为好友,感谢支持!