最简可行产品

最简可行产品(英语:minimum viable product, MVP),是新产品开发中的名词,是指有部份机能,恰好可以让设计者表达其核心设计概念的产品。设计者可以进行验证式学习英语validated learning,根据使用者的回馈,进一步了解使用情形,并且继续开发此产品 [1]。由最简可行产品来搜集相关想法常常会比开发有更多机能的产品要便宜。开发更多机能产品的的费用较高,也会有产品失败的风险(例如产品基本假设有误的情形)。最简可行产品一词是由法兰克·罗宾生(Frank Robinson)创建[2],因史蒂夫·布兰克埃里克·莱斯的使用而流行[3][4][5][6]

利用最简可行产品,也可以提早进行市场分析

说明

编辑

最简可行产品是一个只有重要核心功能,可以提供给客户的产品,没有其他多馀的功能。开发者一般会将最简可行产品提供给部份的可能客户,例如比较容易宽容错误、比较愿意回馈意见、可以从早期原型或是行销资讯中找到产品愿景的早期采用者英语early adopter。此一策略避免制作一个客户不想要的产品,希望可以在相同的花费下,尽量的发掘客户的资讯。“最简可行产品就是一个用来在最小付出下,对客户进行最大量验证式学习的产品版本。”[1]。定义中的最小及最大不是公式上的,在实务上需要判断什么方式的最简可行产品才是合理的。

最简可行产品可以是直接制造及贩售商品给顾客的流程及策略中的一部份[7]。最简可行产品是概念产生、原形、演示、资料收集、分析及学习的迭代过程中的核心工具。一般会希望减少迭代过程中花的时间,迭代会进行到已达到理想的产品市场契合英语Product/market fit,或者确认产品不可行为止。

史蒂夫·布兰克将最简可行产品视为最简功能集(minimum feature set)[8]

目的

编辑
  • 可以在使用最小资源的情形下确认和产品相关的假设。
  • 加速学习。
  • 减少开发设计时间的浪费。
  • 尽早让早期客户拿到产品。
  • 作为其他产品的基础。
  • 建立可以产出需要产品的能力。

测试

编辑

最简可行产品测试的结果是要确认此产品是否应进行开发。测试的目的是要确认原始问题或是目标是否有达成,使产品开发可以继续进行。

著名的评论

编辑
  • 史蒂夫·布兰克:“要贩售愿景及提供最简可行产品给有远见的人,不是给所有的人。”[8]

技术

编辑

最简可行产品可以是原型、完整的产品或是产品的一部份(例如一项特征)。

产品

编辑

网路应用程式的标准MVP策略是建立一个模仿产品的网站,并且购买线上广告让此网站有流量。模仿网站可以包括营销目标网页,其中可提供更多讯息或是可以购买的连结。可购买的连结不用连结到真正的购买系统,不过需记录每个点击,并评估用户的兴趣。

功能

编辑

网页应用程式中连结到新功能的连结可以放在已有网页的显著位置。功能本身可能尚未完全实现,点选连结后出现模仿网页或是行销网页,并说明此功能尚未完成的道歉讯息。系统会记录此一连结的点击,并评估客户端对此功能需要的程度。这也称为“早些部署,晚点编程”(deploy first, code later)的方式。

差异

编辑

释放最简可行产品以及评估其影响都是测试市场的策略,用来在产品产生后快速筛选产品理念。像网络应用程序开发常用的快速应用程式开发工具也促进这一类产品的产生。

最简可行产品和测试之前先投注时间及金钱以布署产品的传统市场测试策略不同。最简可行产品希望在花费金钱及时间开发产品时,先确认市场的确需要此一产品。最简可行产品也和开放源代码提到的尽早发布,经常发布新版本英语release early, release often不同,后者强调倾听使用者的需求、让使用者定义产品的功能及未来。最简可行产品一开始就有产品的理念,在整个产品生命周期中都会维持此一理念,不过会根据未来潜在客户对产品直接及间接的回馈来调整产品理念[9]

最简可行产品是布兰克出的“客户开发”方法论中的一部份,主要专注于持续性的产品开发迭代过程,根据客户的回馈来精进产品。另外,展示还不存在的产品及机能也可以用网路为基础的假设检定来进行,例如A/B测试

商业模式图

编辑

商业模式图可用来标示新创公司的主要成份及活动。可以用商业模式图中的一些元素来设计最简可行产品:[10]

参考资料

编辑
  1. ^ 1.0 1.1 Ries, Eric. Minimum Viable Product: a guide. August 3, 2009 [2016-06-14]. (原始内容存档于2019-02-17). 
  2. ^ SyncDev methodology. SyncDev. [May 16, 2016]. (原始内容存档于2019-02-18). 
  3. ^ W. S. Junk, "The Dynamic Balance Between Cost, Schedule, Features, and Quality in Software Development Projects页面存档备份,存于互联网档案馆)", Computer Science Dept., University of Idaho, SEPM-001, April 2000.
  4. ^ Eric Ries, March 23, 2009, Venture Hacks interview: "What is the minimum viable product?"页面存档备份,存于互联网档案馆), Lessons Learned
  5. ^ Perfection By Subtraction – The Minimum Feature Set. [2016-06-14]. (原始内容存档于2021-03-07). 
  6. ^ Holiday, Ryan The single worst marketing decision you can make页面存档备份,存于互联网档案馆The Next Web. 1 April 2015
  7. ^ Radoff, Jon. Minimum Viable Product rant. Jon Radoff's Internet Wonderland. May 4, 2010 [19 August 2014]. (原始内容存档于2014-03-23). 
  8. ^ 8.0 8.1 Blank, Steve. Perfection By Subtraction – The Minimum Feature Set. March 4, 2010 [2016-06-14]. (原始内容存档于2021-03-07). 
  9. ^ Ries, Eric. Lessons Learned: Minimum Viable Product: A Guide, Lessons Learned. August 3, 2009 [January 28, 2013]. (原始内容存档于2013-01-29). 
  10. ^ Kromer, Tristan. The Four Parts of a Minimal Viable Product. April 15, 2014 [2016-06-15]. (原始内容存档于2015-07-22). 

相关条目

编辑

外部链接

编辑