MVP模型实战:以导出功能为例

AI时代,如何更快入行抢占红利得高薪?前阿里巴巴产品专家带你15天入门AI产品经理。了解一下>

精益创业术语“最小可用产品”或MVP,这个词汇我们常常听到。笔者基于工作实践,结合设计案例,推导了MVP模型的数据导出功能。

MVP模型是最小可行产品(Minimum Viabe Product)的简称,由Eric Ries在《精益创业实战》中提出,指的是用最快、最简明的方式建立一个可用的产品模型,推向市场,测试用户是否喜欢这个产品,进而迭代完善细节。

功能背景

本人任职于一家CRM公司,负责的是BI产品线,本文举例的导出需求是大客户的需求。之前的导出能力只支持到了10000条,而大客户的数据量普遍在10万条以上,因此决定增加『大批量跨对象数据导出』的能力。

虽然客户只提了把导出数量加上去,但是从产品角度出发,这肯定是不够的,长远看,这必然得做成一个完整的功能。把功能一步做到位不现实,而且,客户要求的实施交付期限也不允许。

这个时候,就需要有一个既能敏捷的满足客户需求,又可以满足后期扩展的MVP方案。

开始设计一个MVP方案

1. 会议前

首先,先对系统现有的导出能力进行调研,明确我们的导出功能最终目标是做到什么程度;

然后,对当前正在实施的客户进行调研,清楚知道客户想要用导出实现什么,它的使用场景是什么;

最后,上面问题有结论之后,开始预订日程、会议室,召集相关的同事进行讨论,并准备便签纸、笔、白板等。

2. 会议中

会上,首先确定一个主讲人,先对背景、会议目的进行阐述。

然后,将调研结果分享给大家,目的是画出用户画像,这个过程里,需要其他的人提问或者补充,以防漏掉一些信息,逐步完善用户画像。

这里的用户画像并不是标准意义上的,更多的目的是让所有人了解什么样的公司、什么样的职位、什么样的场景对该功能有需求

随后,在用户画像完成之后,开始用便签纸头脑风暴,写下『如果你是客户,你想要用导出实现什么功能』,目的是发现客户没提但不排除以后提的点,这也是后续版本迭代的方案来源之一。

一张便签纸只记录一个观点,便于后续的分类与整理。

之后,收集所有卡片,讨论出『用户使用导出功能必须经历的大步骤』,写在白板上,并把所有卡片贴在相应的步骤下。然后,挨个卡片进行讨论,选出哪些点是『如果不做,就没办法满足客户这版本的需求』,选出来的这些点就是MVP。

在对卡片进行分类的过程中,以下情况是正常的:

  1. 不是所有的卡片都有效。参会人员岗位不同,头脑风暴的时候可能会带一些各自的职业习惯,还有可能会有一些主观性太强的想法,是否有效,需要斟酌;
  2. 不是所有卡片都能进行归类。有些不属于本功能承担的能力等,也有可能出现在记录的卡片上,需要判断是步骤划分不合理,还是卡片上的想法不合理。

3. 会议后

及时整理会议记录,在电脑端上选一个软件进行输出,我用的是axure,这比纸上记录更容易进行整理和分类,control+F不要太好用。还有一个目的是功能实现是分多个版本迭代的,哪些功能点在哪个版本实现了,软件里记录更容易。我在输出的时候是模仿项目管理的那种卡片式记录的,拖拽排列是很方便。

到此为止,产品设计阶段的MVP方案基本确定了,剩下的就出原型、出视觉稿、技术评审……

前期的调研、收集反馈所耗费的时间都是碎片进行的,MVP方案的讨论不到两个半小时完成,然后半小时内完成了原型……

总结这样做的好处

  • 加深对项目的理解。在无法面见客户、了解客户需求的时候,产品设计进行输出时要么按客户成功的反馈做,要么自我感觉良好,自嗨型输出,最后的结果是要的你没有,给的不想用;
  • 节省沟通成本。在参与的过程中,会有各种各样的问题抛出,然后得到回答、讨论等,这比看PRD印象更深刻,也会大大节省沟通和信息传递所耗费的时间成本;
  • 更多的成功参与感。推导MVP的过程可以让一些非核心岗位的同事有更深的参与感,任何产品的成功都是团队的成功,只有大家觉得这个产品值得我付出,并且一起努力了,才会有好的结果。

写在最后

MVP方案确定了之后,在产品后续迭代的时候,只考虑会上讨论出的功能点还是不够的,还需要综合产品、技术层面输出一些内容才能进行下一步的设计。

比如:会上无人提到编码格式,但技术上有限制,这是用户在填写表单时必须填的。

最后说点小废话,MVP是产品设计中非常好用的一个方法,但是如果你的团队中有人对你的方案持怀疑态度的时候,不妨挑选一些业务逻辑没那么复杂的需求,来进行一次MVP的推导,成本不大,还会有意向不到的效果,比如,信任感、认同感~~

 

本文由 @瓶子 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. PM学习重点
    思维:提前思考,比顾客想的再远一点,包括用户需求的实现程度、应用场景、想要达到的目的
    方法:MVP方法,一人牵头,进行头脑风暴,明晰用户的需求;讨论/判断需求优先级;确认MVP方案;画原型,准备评审
    其他:由于参会人员的复杂性,或许可以考虑提前出一个流程图,让大家再框架下发散思维,避免疏漏
    感谢输出,Thanks♪(・ω・)ノ

    回复
    1. ;-) ;-)

      回复
  2. 哈哈哈

    回复
  3. 此文,不明所以?

    回复
  4. 很有意义的方法

    回复