小作坊是如何完成产品迭代的



致想成为产品经理,或想成为更好的产品经理的你:

写这篇文章的原因是,看到许多想成为产品经理的同学,特别是pmcaff南通大学的某位小同学,愿意并努力去成为一名产品,通过培训班的方式,去增加自己的产品知识,去实践产品的工作。固然是好的,但是看到他们写的东西以后,真的很想告诉他们,产品跟培训班讲的不是一个东西。那些长篇大论的分析文,可能会成为你的敲门砖,但是绝对不是你的金刚钻。你会发现等你真正解除到产品工作以后,你会无从下手。分析永远是分析,模板永远是模板。分析不能落地,就是0,模板永远只是个框架,走不出来就是死胡同。抽空会不断更新文章,目前计划写两篇,其一为产品迭代流程,其二为从0-1的产品流程。

产品迭代流程:

一、需求

1、 需求获取

2、 需求分析

3、 需求管理

二、竞品分析

三、原型

四、Prd文档

五、需求评审(包括修改需求)

六、对接UI,对接开发

七、需求验收

八、上线,跟进数据

回到正题,如何主导产品线的迭代。个人习惯,一图流。(图片来自lisanke的一位产品实习生),借用一下,侵删。

sanke1.png

一、    需求

产品以解决用户核心问题为目的。这里的一个关键词,用户核心问题。可以理解为需求,虽然两者有区别,但是这样画上一个≈号,没什么不妥。

我们遇到了产品迭代第一步需求的第一个阶段:需求获取

获取需求的方式,也就是需求的来源:

1、商业需求-来自于商业化团队,或者老板、合作商,外包团队多见于甲方;

2、用户反馈-来自于各大应用商店的用户评论或应用自带的用户反馈,也可以是客服团队的用户反馈,问卷调查等;

3、团队其他部门-来自包括但不限于测试、运营、开发、产品等团队;

4、自身挖掘-产品线负责人体验自身产品、对比竞品、数据分析来得出的需求点。

身为产品经理在这个阶段要做什么?简单的收集和整理,就足够了。

随后是产品迭代第一步需求的第二个阶段:需求分析

顾名思义,不是所有的需求都是真正的需求,这就需要产品经理掌握需求分析的技能。首先是筛选,讲一些明显与产品定位背离的需求过滤。还有一部分需要过滤的需求,即不合理的需求或小众化场景的需求。综上可以统称为伪需求,如何辨别真伪需求是一个永恒的话题,作为一个初出茅庐的产品经理,以理解自己的产品为基础,若不能很好的判断。个人建议请教前辈,或了解这个产品的人,领导、同事,都是你可以咨询请教的对象,但是也要注意方式,不是拿着一堆需求,听他讲,哪些哪些是伪需求。一定是你先进行尝试,然后再拿有疑问的去请教。不耻下问,才能进步,这也是一种学习的方式,而且是很好的学习方式。第一步筛选过后,剩下的基本就是真需求了,我们已经完成了“做还是不做”这个问题,这时候又会面临一个问题“什么时候做”,网上有许多具体的方法,比如四象限分析法,kano原型等等,这里就不一一赘述了,还是那句话,作为一个初入产品的年轻人,要学会不耻下问,不要指望一下子就会把一件事做的很好。

最后是产品迭代第一步get需求的第三个阶段:需求管理

学会如何管理好需求,对产品经理接下去的产品迭代有很大的帮助。创建一个自己的需求池,并保持不断更新,从中发现产品迭代的方向。这里贴一个自己的产品需求池,放不了太多,大家谅解一下。表内包括了需求的收集和整理,也包括了需求的分析,还有需求的状态和时间等记录。

微信图片_20180528162435.png

二、竞品分析

当你从得到下个版本的需求以后,身为产品经理的你需要做什么。当然是对需要的功能进行设计规划啦,这时就少不了做竞品分析。注意,初入门的产品经理,一般都会被分配到一个小功能的优化和迭代,所以像产品培训班的对整个产品做所谓的深入分析,一般没什么X用,很少见有应届生或刚转行的产品能负责从0-1的,况且从0-1,也不需要如此大费周折的长篇大论。

那么在真实工作中,我们需要的一份正确做法的竞品分析,应该是什么样的呢?

1.明确竞品分析的目的;解决一个实际的问题,比如要做购物车的商品分享功能,想看看同行都怎么做?

2.选择好竞品分析的对象选择细分行业的前二/三即可;比如对于淘宝公司来说:天猫,京东,就是不错的选择;

3.对比目标状态的截屏,放到一起;横向放置不同产品同一功能的截屏,纵向放置当前功能页面的不同状态;

4.在页面合适的位置可以使截屏右侧叙述优缺点,和自己的思考与总结;

5.通过对比分析,得出自己的观点,我们应该怎么搞?

同样来自lisanke,链接在下面,有详细的讲,也有模板。

链接:https://www.zhihu.com/question/23601989/answer/317794141

三、原型

原型是产品经理很关键的一个输出物,个人不推荐用墨刀或者mockplus等原型工具,还是喜欢用axure,当然更推荐有条件的同学使用sketch。我想讲述的并不是如何使用这些工具,我想讲述的,是一个产品新人,如何去产出原型。流程来到这里,你已经做足了功课,完成了竞品分析,now,就是把需求落地的第一步,产出一个demo,也就是原型设计稿。这里引申出两个问题:

你是否已经完美的完成了竞品分析,明确需求的规划和设计?

是否已经决定参照哪一款竞品或者已经有了自己的规划和设计?

有自信鉴定的回答是好事,但是往往事与愿违。因为,经历不足导致你还摸不透领导的想法,你还不知道需求到底想达到一个什么样子的效果。怎么办?如果在做竞品分析的时候没有和领导讨论过。那我想最好的方法,就是参照竞品,结合自己的产品,设计出多套原型稿,根据自己的思考和分析,推荐一套,并跟领导进行讨论,在过程中讲明各方案的优劣。如果在竞品分析时已经完成了和领导的沟通,也不要局限,至少产出两套原型方案,再和领导沟通。如图(比较粗糙。。突然找不到好点的了,将就下吧):

TIM截图20180530141127.png

再补充一点,许多产品经理在纠结做高保真还是低保真的问题上分歧很大,我对这个问题的看法是这样的,在所限时间内,根据任务轻重缓急,能画的高保真一点就高保真。我的许许多多迭代需求原型都是直接在原图上进行修改的,效果看上去会很直接。高保真原型也有利于UI进行视觉优化,可能有人要反驳我了,但站在UI的视角上,你给我一个很丑的原型,我连看都不想多看两眼。能画高保真,为什么不呢?对自己也是一种技能的提升,何乐不为。下图贴自己的低保真,0-1的项目,任务重的情况下我也会画低保真,但是效果上绝对不会做的很差劲。

TIM截图20180530141826.png

四、PRD文档

prd文档无疑是产品经理输出内容的重中之重了,上下游交付,全靠这份文档。这里小小diss一下pmcaff的高赞文,题目叫上下游都喜欢的XXX文档。大概是这个名字,我看了以后很不是滋味,因为这样的文章,包含的内容太多,任凭UI还是开发,不会有那么多时间,来看这种文档。这里还是贴一下lisanke老师的一则文章,侵删。

链接:https://www.zhihu.com/question/19685255/answer/364925819

这里贴一下前项目组小伙伴的一些文档,各有各的特色,但是无一例外,都是不错的文档(开发挺喜欢看着,然后拿着文档骂需求啥时候改了这种)。

111.png

上图展示的仅仅是某个功能的prd文档单页,prd远远不止这些内容,下面贴一个一般prd需要的目录,详细的在上面lisanke老师的链接里也有,看官们选择性阅读。图如下:

1111.png

最后,prd文档不是写完上交,就可以了。要保持实时更新,特别是版本的需求变更等情况,要及时的记录并更新,一是为了不背锅;二是为了等待下一位有缘人接盘的时候,需求出现偏差不知所措。

五、需求评审

在完成了原型和PRD文档以后,需求评审就到了终于要交付的时候了。你要做到的就是告诉上下游,项目组的所有人,这个版本我们要做什么,为什么要做这个,设计是怎么样的,预计上线时间等等。当然,这样直接讲,压力难免有些大,而且,你怎么保证你写的文档没有问题呢?so,我们来讲一讲需求评审的流程。

在确定方案并完成了初版的prd文档v1.0之后,与产品线领导1对1,或产品组内部,进行需求评审。指出不足和有问题需要修改的点。大概流程就是你先讲一遍,然后大家讨论,自己做记录,然后结束后抓紧时间讲prd文档进行完善。

然后的然后,在prd文档v1.1会有专家组(boss们)对prd文档进行专家评审,有问题则指出并修改,循环。没问题则选良辰吉日,交付项目组其他成员(一般为设计团队和开发团队)。

第三轮,prd文档v1.2,可以交付设计团队和开发团队了。无可避免的,会上大家会各自发表意见,会发生诸如,需求变更,需求延期等常见问题,身为产品经理的你,要记录并整理,参与讨论甚至主导讨论,多站在对方的立场看待问题,并试图说服别人或者被别人说服。同样,需要快速产出prd文档v1.3,确认无误后,交付设计和开发团队,进行下一阶段。这里顺带提一句,如果是Axure完成文档的小伙伴,建议在设计产出作品后,将prd文档中的图片进行替换,可能有人会说多此一举或者麻烦,但是好处是显而易见的,开发可以看得更明白更直接,问题会少很多。

至此,需求评审结束,prd文档经过一系列的修改,完成归档。

六、对接UI,对接开发

这个话题也是产品届经久不衰的话题了,不多做赘述,没有什么意义。个人的意见是,在设计团队,开发团队,测试团队,运营团队,任何人在这个版本,或者你负责的某个功能上有疑问的时候,你都要及时出现,说明并解决问题。保证进度正常。其实话语之间,都凝结为一句话,别人在加班,你也就老老实实待着吧,乖。

至于如何和大家沟通,这个全凭自己,谁都教不了你,一句话:不会沟通,难以胜任产品经理。

补充一点:进入开发以后,产品经理可以就下一轮的版本迭代计划进行筹备了,即开始接需求,然后就是循环往复了。

七、需求验收

需求验收不等同于测试,测试有专门的测试方法论和测试工具。产品的需求验收,指的是对自己负责的功能点进行验收,确认与设计稿是否一致,确认是否存在问题。这个流程非常重要,直接关系到了预想和实际的差距。这个阶段多发的状况,是在原先的基础上进行优化,这是很正常的,在不改变需求的情况下,更好的将需求落地。

同样,期间可以安排设计团队走查,保证UI稿的正确性。

同时,更新项目进度表,记录并整理开发时间,进入测试流程。下图贴一个自己的项目进度表吧,看起来更加直接一点。

TIM截图20180531133541.png

八、上线,跟踪数据

一般APP上线流程:选择一个小渠道进行灰度测试,以防不测。在确保一系列的数据正常没有问题的情况下,再推广到所有渠道,并开放升级。

APP的一些重要数据:错误率、日活、新增、留存、新增事件点击等等。

一般对于新版本,最关心的错误率和新增事件点击。所以会做一个简单的表格来做记录。同样,我们以错误率为例。如图:

TIM截图20180531134242.png

每个产品对于错误率的标准不同,数值仅供参考,个人接触下来那么多APP产品,错误率≤0.5%为良好。

完成每一轮的工作之后,都需要进行汇报,因为根据领导部门的要求,可能会要求加快项目进度或新增某些紧急需求,不要闷头干活,两耳不闻窗外事。四通八达的产品经理,才是大家喜欢的产品经理。

最后,虽然更新完了,还是说几句吧,不是所有人都适合做产品经理,不要被“门槛低,就业简单,工作轻松,收入高”等培训班的招生金句蒙骗了。本人做过开发,做过实施,最后转行做了产品,也算是了解互联网常识,刚开始做起产品来,都感觉力不从心,什么都做不好。比如非科班出生的应届生或者转行人员来说,连“SDK是什么”“接口是什么意思”“A/B测试是什么”等等这些常识性问题都不了解,我觉得起码你离互联网产品经理,还有很长的路要走,离你想要的高收入,也绝对是漫漫长路。静下心来,一步一步来,尝试做真正产品经理的工作内容,“人人都是产品经理”,只是一个书名而已。

欢迎交流,邮箱:PenGodlike@outlook.com

关注点赞,留言任选其一你所需要的模板,我会择日发送于你。为什么任选其一呢,我觉得还是自己动手做一做,比较好啦。

浙江省宁波市海曙区厂堂街