第一次原型评审,产品经理的你该怎么开?

共 3340字,需浏览 7分钟

 ·

2021-05-13 08:46




前言:
关键在于要搞定两大阵营:需求阵营、技术阵营。

栽过不少跟头,悟出少许实战小窍门儿,希望能帮您少走弯路。

一、会前

1、产品团队先内部评审

俗话说,家丑不可外扬。

一般情况,是不会拿着你的2B原型,跟团队内部小伙伴过一次的。

因为,谁也不想把不好的一面,露骨的展现给身边人看的一清二楚。

一般人不推荐,等你有足够的自信之后,不妨一试。

但是,如果你拉的下这个脸,可以邀请小伙伴们来个原型部门分享会。

其实,小伙伴们大部分是很乐意参与并帮助你的,除非他们当时比较忙。

我们产品部门之前就试过,效果还蛮好的,可以提前规避不少小问题。

2、两大阵营先单点逐个击破

先找业务方评审,再找技术团队评审,虽然慢了点儿,麻烦些。

但是,可以很大程度能让你在原型评审大会上,不会被两大阵营怼得体无完肤,手足无措。

2.1、单点突破——需求阵营

自己初步画的原型和规则,得先跟业务方单独过一下,确认是否达到初步预期。

业务方,是告知其该产品他们当初提的需求,如今如何满足,页面之间如何跳转、如何操作。

所以,可多次骚扰他们,小腿儿勤快些,再约他们抽时间聊聊人生,直到在用户体验上,他们点头满意为止。

2.2、单点突破——技术阵营

技术阵营选手有:项目经理、UI设计师代表、前端开发代表、后台开发代表、测试工程师代表等

技术,会抠产品的每一个细节,不断的问你为什么有这些页面、流程和规则。

你原型里有的,他能问的,都会问;没有的,也会问,谁让你没想清楚?

我觉得他们真的是一群很了不起的人儿,谢谢你们,笔芯~~

不仅要写代码、设计图片、测试产品,还要来帮你这个渣渣产品擦屁股。

不是漏了这个规则,就是漏了那个流程,或者是这个页面,反正就想怼你啦!

温馨提示:如果你没有跟技术阵营小伙伴,先小范围至少原型评审一次,你会死得很惨。

除非,你对自己的业务流程、原型、规则极其自信。那请忽略我的友情提示。

同样,别害怕被蹂躏,勇敢的面对他们,直到他们在流程、原型、规则上,不怼你为止,此轮小范围评审才算暂时告一段落。
  
3、做好必要准备工作

3.1、必须邀请关键人参与会议

先用各种途径(当面、邮件、钉钉、语言电话、微信等)与各关键人物,预约并定好可参会的时间。

温馨提示:如果关键人物没空参与或与其他会议发生冲突,咱们可往后延期再约。

但是,必须约到。能拍板的人没空来参与,你的评审会,开了等于白开。

谁经历,谁酸爽~~

 3.2、会议通知提前一到两天


一般以邮件+钉钉群公告形式,正式邀请项目相关所有人来参加会议

最好一个都不能少,当然特殊情况非关键人可提前请假。

3.3、准备好会议所有必备资料

需要分发的资料可以提前打印几份出来,发给有需要的小伙伴。

3.4、提前与运维同事打好招呼,连接调试好大会议室投影仪。

这事儿可大可小,如果关键时候掉链子,投影仪连不上,是很尴尬的一件事哟!

3.5、提前10分钟到达会议室,并再次提醒项目组成员。

温馨提醒大家,会议马上要开始,请移步到会议室参会。

大家都很忙,可能一天要参加N多个会议,特别是关键人物。

你不提醒,不少小伙伴或许早已把你的会议忘得一干二净,很正常。


二、会中

准备工作做足后,那么可以正式评审啦喂!快快拿好小板凳,排排坐。

4、告知会议目标

相信很多产品经理都会发现,明明我开会是聊这个需求的评审。

结果,被大家一通瞎几把乱聊之后,多少人被带到阴沟里面去了呢?

开完会,啥结论也没。好好的一个原型评审会,变成了产品吐槽大杂会。丢~

因此,重点关注会议主题、会议目标,为什么开,怎么开,要达到什么效果?

为了不重蹈覆辙,会议目标必须开会刚开始就向所有人强调。

5、介绍项目背景

等等,别猴急嘛!怎么也先来个前戏,让人家有点心理准备吧?

无论有多少人,已经知道此项目的基本情况,依然建议你统一再次为参会人员介绍下为什么要做这个产品,为谁服务,解决哪些痛点,有什么价值。

6、对评审会议进行管控。

会议主持人做好控场工作,严格遵守会议流程。

先礼后兵,对事不对人。

偏题的话题避免拉长会议时间,浪费大家表情,建议直接打断拉回主题。

7、心态要好,控制好情绪,别激动。

做产品经理,如果你没有一颗大心脏,我现在就想劝退你。

见过舌战群雄吗?没错,你的第一次原型评审大会,将会感受到。

记住,你就是全场最亮的那个zai。

放松,坦然面对,亲。

 
8、指定专人做会议纪要。

老铁,醒醒!一般也就是你自己记录啦。

当然,如果有个小助理,那就美滋滋咯!

9、认真落实会议决议并严格执行,责任到人。

放空炮谁不会啊?关键是很多需要落地的东西,必须责任到人。

比如说:如果原型评审没通过,作为产品经理的你得会后继续优化原型再评审,直到通过为止,才能往下推进工作;如果通过了,设计需要谁出UI图?多久出?

好多事儿呢,各项工作,都得在会议上逐一落实,各自认领。
 
9、不讨论技术实现细节,只探讨可行性。
 
别忘记了,你已经单独跟技术聊过技术规则细节了。

在这种大会上,那么多非技术人员参与,你聊过多技术实现细节问题,结果是啥,知道不?

玩手机的玩手机,睡觉的睡觉。大会哦,大佬?并不是技术原型评审会,切记。


三、会后

10、将整理好的会议记要,发给项目参会人。

会上肯定讨论了很多需要落地的会议决议,为了以防大家忘记,记录下来,并以公司正式邮件发给大家

猪哥将平时工作中使用的会议通知、会议纪要模板分享给你。




公众号后台回复:【会议纪要】领取模板。  

如果你还需要什么工作模板,请私撩我咯~

11、与技术团队沟通产品提测、上线时间。

原型评审通过之后,产品也闲不下来的啦!

拉小会与技术阵营小伙伴沟通:UI图什么时候出来?代码什么时候提测?测试什么时候上灰度环境?什么时候产品和业务方验收?等等一堆问题,都需要定个时间节点。

12、给业务方反馈上线时间

很多时候,业务方在你还没跟技术阵营讨论上线时间之前。

大家才刚刚评审完,便拉着你,来那么一句:什么时候上线啊?我很急?

然后你又要很无奈的再次解释一遍:我得先跟技术团队讨论,然后跟你同步。

有木有?所以,讨论完的上线时间,赶紧告诉业务方,给他们吃颗定心丸吧!

13、管控项目进度

项目管理,主要的痛,个人觉得是以下几点,建议重点关注一二。
13.1、需求变更

又一个老大难问题,需求变更导致的风险,是很麻烦严重的。不过,要根据自己的经验与能力判断,此次需求方变更需求的影响范围。
如果影响不大,那能改就改;如果影响较大,那必须上报风险,事前告知需求方并给出合理理由。
如果是影响思维模型中的底层数据架构,那必须报严重风险。
13.2、紧急需求

最怕这类人,不讲理还霸道,整个项目正常的上线流程又不是不知道,但还要提出我现在就要,一周之内就要这种不懂互联网项目正常上线流程的无理要求。
谁的事不急,谁的需求不重要?你现在要,我也给不了,小需求我可以快速评估,尽快上线,尽量做到能今天上线绝不拖延到明天。
但是,大需求该怎么走流程还是得怎么走。
13.3、项目组临时换人


项目开发到一半,技术突然离职或者被其他项目借调,导致项目突然报风险,也是很容易让人措手不及。

如果技术离职,得找人尽快接手咱们的项目。如果技术被借调,咱们产品得去了解具体原因,想解决方案。

最终目的,保证项目正常上线。



总结:
原型评审,是我们产品人,不得不面对并认真做好的一步。任重而道远,各自加油哦!
送您一份作者常用的需求评审模板,关注“刻意练习产品思维”后台回复 “需求评审”  获取



  我的新书《B端产品经理必修课2.0》已经开售了。

这是对我的第一本书的全新改版,也是关于B端产品的方方面面。

查看具体内容:我的《B端产品经理必修课》升级了



推荐阅读:

SaaS新用户登录指南(附8个好例子)

SaaS 客户成功: 减少客户流失和提高 MRR 的秘诀

【干货】B端产品差异化指南

SaaS免费模式的本质

10个做SaaS业务的重要原则

[建议收藏]极简SaaS创业手册

[收藏]7个可以调研B端产品的网站

浏览 29
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐