如何划定MVP的产品范围?
本文探讨了在构建最小化可行产品时,应该如何思考产品的范围,进一步有效控制产品开发成本和时间。
任何在过去五年中从事软件开发工作的人,都可能听说过MVP(Minimum Viable Product,最小化可行产品)一词。
如果您是负责用户体验的,那么您经常会对这三个字母感到沮丧。可能是因为您通常在项目结束时遇到它们,比如有人会这样说:“这是个好主意,但我们现在没法做。先发布一个MVP,以后再添加它。”这成为一些人的说辞,即使并没有未来迭代的计划。
这个本来可以帮助我们快速打造客户喜爱的产品的概念,反而成为了发布并不优秀产品的借口,这不是很讽刺吗?
最小可行产品的最常见定义是,产品具有足够的功能足以满足早期客户的需求,并为未来的开发提供反馈。
不幸的是,有时这种说法会被误解,团队认为构建“刚刚好”的产品意味着纯粹专注于功能。然而,产品不仅仅等于是功能的堆砌,不能只是发布有一些功能的产品,然后等待下一次迭代再使其可用。用户的信任是非常脆弱的,一旦被打破,就很难重建。
下面的模型最初由Jussi Pasanen提出(后来成为关于该主题的任何博客文章的产物),该模型解释了如何在尽快使用户获得产品的同时不让用户失望。它建议您应该在每一层上创建最小的块,而不是逐层构建。
任何MVP都必须具有一系列为用户提供的价值特征:足够的价值,赢得用户信任的可靠性层,以及用户不必过多地理解产品设计的可用性层,和可以获取到一些欢乐的顶层部分。
构建最低可行产品的方法:建立一个切片,而不是一次构建一个层(来自Jussi Pasanen的图表)。
缺了点什么?
这张图还很好地表达了另一个观点:产品层是堆叠在底层的,如果您扩展了一层的范围,则需要增加它上面所有层的范围。
例如,添加的新功能越多,就需要更多的工作来保持产品的可靠性和易用性。如果想要缩小范围,最合理的起点是这个金字塔的基础——功能。
那么应该要包含哪些功能?如何进行决定?我知道您的“UX触觉”(译者注:原文为‘蜘蛛侠的触感’)现在开始感觉到了什么。
我的也一样,直到我意识到“功能层”并非这座金字塔的真实底层。上图仅涵盖了产品本身的特征,但产品并非存在于真空中。我们构建它们是为了帮助希望对我们所提供的价值给予回报的人们,产品的真正基础层应该是受众及其需求。
缩小受众范围
假设我们需要一种能够为用户解决问题X的产品,我们应该为哪部分用户构建MVP的来验证我们的方法?
有关项目范围的讨论应该由此驱动:
选择“产品的受众”(谁将在最初阶段从产品中获得最大的价值),并向其他所有人说“不”(或“现在暂时不”),最能显著缩短开发时间。产品的受众范围越广,其需求和问题就越多,必须构建的功能就越多,产品将变得越复杂和难于使用。
没有什么比划定“受众”范围,更能显著地减少开发时间了。也有人这样说,您的MVP不一定要像最终产品那样酷,但是使用它的体验仍然应该令人愉快:“汽车的MVP是三轮车,而不是四个车轮。”
受众范围越广,需求和问题就越多,产品将越复杂。
但是,仔细看看这个MVP的本质,就会发现它与最终产品的最大区别在于它所服务的用户的广度。
汽车适合所有人,老少皆宜,无论是独自旅行或成群结队旅行,还是上下班通勤或拼车前往下一个城镇。但是,三轮车专门满足幼儿的运输需求。
对用户进行细分,并选择要满足的每个细分市场的需求,可以让您的团队事半功倍地为这些用户创造出色的体验,并且得到他们的喜爱。
当您缩小金字塔的底层时,其他每一层也会缩小。
了解用户的期望
让我们回到金字塔,看一看横切所有层次并将“最小值”与产品其余部划分开的那条线。它很重要,因为它概述了您的工作范围。
如何知道在哪里画这条线?
我认为这条线代表了用户的期望,无论选择哪种受众群体,他们都会对产品是什么、应该做什么有自己的看法,不应该辜负他们的期望。
MVP的范围基本上取决于产品受众和他们的期望。
认识到用户想要什么与期望什么之间的差异至关重要。
“期望”是人们认为某事应该如何运作的方式,而“想要”是人们对当前事物状态进行改进的愿望。缺少想要的东西可能是不好的,但不能达到期望可能是一场灾难。
例如,如果通常的上班通勤时间是30分钟,那么您会期望明天花的时间差不多。
人们会想要缩短旅行时间吗?
当然!但是大家都知道并不一定总能得到想要的东西。然而,如果您的电车明天晚15分钟出现,而乘车时间变成45分钟,您可能会暴跳如雷。
不仅是MVP版本,任何产品都不可能满足所有用户的愿望,什么产品都总是有改进的空间。但是,当您的产品达不到用户期望时,这是一条快速的失败之路。在尝试确定用户期望时,应牢记一些注意事项。
用户的期望来自于他们对类似产品的体验
只要没有开发出绝对新颖的产品(例如飞行汽车),就必须考虑竞争对手(甚至是间接竞争对手)提供的体验。如果他们可以立即同步用户数据,而您的应用程序会延迟4小时就完全不及格了。它可能会迫使您在图上向右移动划线,扩大项目的范围。
用户的期望基于现代标准
十年前,您可以开发一款只能在台式机上使用的产品,但如今,必须能在移动设备上对其进行访问。
如果产品无法在移动中为用户提供支持,那么按照今天的标准,该产品可能就无法获得“可靠性”标签。
用户的期望基于他们今天使用的解决方案
我很喜欢Jared Spool在他的博客中关于用户期望的示例。他的团队在Google Spreadsheets上进行了可用性研究,并观察到当簿记员找不到双下划线时,她就会感到非常沮丧。
她可以使用普通的单下划线吗?理论上当然可以。但是,电脑和电子表格出现之前,人们就已经在使用双下划线了,通过限制MVP的范围并不是一个忽略它的充分理由。
总结
- 构建MVP并不是单纯削减功能,而是划定最小的受众群体,为他们构建最低可用的产品范围。
- 缩小用户类型的范围将会大有帮助,因为它将减少产品必须满足的需求。
- 受众对产品的期望将定义产品的范围,理清这些用户期望,几乎就可以明白要做些什么了。
本文译自Andrey Gargul 的The thing that’s missing from your MVP,作者是Shopify的用户体验设计经理。
本文由 @海外设计参考 翻译发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
作为产品小白,之前对于最小可行性产品仅仅停留在产品功能的层面,从来没想过底层的用户需求,这个模型真的特别受用,已经收藏,受教了!