寻找最小可行化产品背后的真理

一个成功的开始

同其他 99% 的产品经理一样，我是通过 Eric Ries 的《精益创业》这本书了解到 MVP（最小可行化产品）这个概念的。当我偶然发现这本书以及 Eric 的方法时，我想：“这正是我一直在寻找的！这个理念多么有意义！”，在你做这个产品之前先测试它？多么新奇的主意！我非常激动，仿佛被打了鸡血！我立刻就要创建对用户来说非常有影响力的东西！

坦白地说，这个东西来的正是时候。我实在非常厌烦创建没有人用的东西，紧紧盯着谷歌分析中的数据等待它上涨，结果却是再次下降，这个产品就逐渐老化了。我和我的队伍花费了数月在我们认为会成功的产品上，结果却让人失望。当我有机会在新的产品中尝试最小可行化产品的方法时，我将会毫不犹豫使用。

我们电子商务公司的 CEO 向我提了一个关于新产品想法的建议，并认为这个想法能够提高用户参与度、销售更多的产品。他想实现一个类推特的消息源，这个消息源能够让在我们网站销售产品的名人也发表他们个人生活的东西。这个想法在测试中十分重要。这是如此成熟的假设：我们的客户是否想要了解那些名人在我们平台忙什么？这能否会让我们销售更多的产品或是增加用户黏度？

我去问工程师们，按照我们 CEO 提议的方式，从零开始到完整实现这个想法需要多久。带着一个粗略的估算结果，我回到我们大胆的领导身边并告诉他：“完整实现这个想法将可能花费 75000 美元，而我们甚至不能确定我们的客户是否想要这个功能，但我能用 2000 美元在一周内证实这是否真的能够提高效益”。就这样，我加入了！

不到一周，我们证实了这是一个糟糕的主意。一周后我们找到了另一个能够将我们的产品点击率提高三倍的办法，我们还将转化率提高到原来的两倍。整个公司都被吸引了，然后我们被允许继续实验。我想：“太棒了，每个人都能看到这个测试的价值！这是毫无疑问的！”

最后，我换了另外一份工作，我也非常兴奋我能将最小可行化产品概念带到这个新的团队。说真的，我有点惊讶，公司的每个人都没有使用这个理念，他们是不是根本不知道这个神奇的魔法？我十分确信，我上一家公司的一切都会完全地按之前那样继续发展下去。

我们这里并不做那个

当“最小可行化产品”这个词第一次从我嘴巴说出时，房间里人们的反应跟我期待的完全不同。你可能以为我说了英语字典里的所有的脏话，像是在会议的中途唱起了 Giggie Smalls 的歌，没有哔开任何敏感词汇。他们的反应就像我侵犯了他们的祖先一样，最后 CMO 打破沉默说：“我们这里并不做那个，我们并不传递糟糕的产品。”

接下来的几年我经历了无数次这同样的反应。

我认识到最小可行化产品这个概念已经被广泛的误解了。一些人因为先入为主的概念而害怕做最小可行化产品，其他人因为过多地使用这个词导致它变得毫无意义。“那产品我们应该做成最小可行化产品！”在产品开发中已经成了仅仅意味着让产品变小变廉价变快的战斗口号。

人们怎么最终成为这样了？故事总是几乎相似的。 一些人阅读了《精益创业》，仿佛醍醐灌顶，说“我们这里应该做最小可行化产品！”。他们看到一个又快又便宜的方式去执行产品开发，然而并没有完整理解最小可行化产品的意图是什么或怎么把一个产品做的更好。在我特别厌倦的公司里，一个开发者最后做一个兼容来测试一个新功能，结果导致每一次有人使用该功能时该功能都会崩溃。我们客户因此生气，公司却总是归罪于最小可行化产品的概念而不是他们草率的开发。

这并不是最小可行化产品的错误，这个问题起源于对“最小可行化产品是什么”的误解和长久以来一直的不顺畅的沟通。

什么是最小可行化产品？

我对最小可行化产品的定义是为了学习而用最少的工作量。当我在专题讨论会教这个定义时，我经常遇到不赞同的意见：“最小可行化产品是你能制作或销售产品的最小功能点集合，而不仅仅是一场实验。”

所以哪个是真相呢？最小可行化产品是一个产品？还是产品的一个子集？还是仅仅是一场实验？

最小可行化产品的词语是由 Steve Blank 创造的，而流行于 Eric Ries 的《精益创业》的书，我回头研究了这两位专家和一些其他人是怎么定义这个术语的：

“最小可行化产品是指仅仅只有那些功能点而已的产品，这个产品能够允许你去传递产品给早期的使用者们去看（至少他们中部分人有一些共鸣）和付你钱和开始给你反馈，”- Eric Ries, 2009

“最小的功能点集合（最小可行化产品）是一种客户发展的战术，用于减少工程师浪费和尽快获得从早期支持者们获得产品。” - Steve Blank, 2010

“最小可行化产品（MVP）并不总是你最终成品中更小 / 更便宜的版本。” - Steve Blank, 2013

“最小可行化产品并不仅仅是一个带着削减一半功能的产品，或一种出门早点拿到产品的方式。事实上最小可行化产品并不一定需要成为产品，它并不是一些你仅仅制作一次，然后就可以考虑工作结束的事情。”- Yevgeniy Brikman, Y Combinator, 2016

困惑对吧？不过通过这次研究有一点对我来说清楚的是，最小可行化产品的定义已经演变进化了。在早期，我们讨论这个概念作为一些来印证创业点子的东西。所有这些最小可行化产品正在寻找产品市场适应性。这些天我了解了礼宾部实验和绿野仙踪，它帮助我形成了我自己的定义和理解。随着我在企业和更成熟的公司中作为产品经理继续使用这些方法，我不得不定制我对最小可行化产品定义和的实践。我所学到的就是你需要确保两者都要成功——实验的设想和制作最小功能点集合。

虽然有大量的关于最小可行化产品定义的分歧，但每个人都一致赞同其目标。最小可行化产品的目标是迅速地学习什么是你客户想要的，你想尽快地学习这样你就能专心做正确的事情。所以让我们摆脱一些时髦术语并专心于上述各点，让我们停止讨论什么是最小可行化产品，并开始讨论什么是我们作为一家公司所需要学习的。

怎么学习和什么时候学习？

当我们开始做一项新功能或新产品时会有大量问题需要回答：“这个解决了用户问题吗？这个问题是否真的存在？用户期待从最终结果中获得什么？”。在确认解决方案之前我们不得不对这些问题寻找答案。

这就是为什么一开始就做最小功能集合是危险的，尤其你跳进制作一个忘记去学习的新产品或新功能的版本时。通过回答这些问题，实验能帮助你发现你的客户的问题和对他们来说合适的解决方案。它并不是仅仅用一场实验就能结束的，你应该有多个的能持续回答问题的后续行动。在你确认最终解决方案之前，你回答的越多，关于用户是否想要或是否想使用的不确定性就越少。

一旦你已经证实了用户想要你的产品，这就是时候去研究最小功能集合了。现在我们不仅能够开始寻找一个又有销路的又适合销售的产品，而且可以满足通过实验发现的用户需求。尽可能快地在市场发布这个产品是终极目标，然后才能从客户和迭代中获得反馈。但是，你不得不谨慎地发布一个高质量的产品，即使这个产品极其微小。损坏的产品对客户来说并不能产生价值，只会让客户头疼。一个产品的任意版本如果不能传递价值就是无用的。

在实践中看上去会怎样？我曾在一家 SAAS 公司中工作过，当时我们不得不创造一个新功能用于帮助我们客户预测他们的得分。通过与客户的会话，客户的销售团队给了我们一些输入资料。复核资料之后，我们发现我们不得不学习更多的东西。

我们与客户会见是为了了解他们想在预测中寻找什么。一旦我们认为我们已经掌握了需求，我们就为他们建立电子表格并输入他们的目前的数据进去。这耗费我们不到一周的时间，我们给客户展示这个电子表格并在搜集他们反馈之前让客户先使用它一周。我们第一次、第二次、第三次并没有得到正确的结果，但在第四次迭代时，我们已经能够发布用户想要的精确的结果。我们通过少量的客户又做了相同的过程来确保结果是成比例的。

电子表格给我们一些客户提供了直接价值，但我们并没有资源给我们全部客户提供，因此我们不得不构建一个软件解决方案。通过我们电子表格收到的反馈，我们开始探索最小功能集合。虽然我们有足够多的用户想要的花哨功能，但在第一个版本中我们成对撤回并回到本质。我们花费了几周获得第一个工作的版本，其中包含了最重要的片段。然后我们向用户开放电子表格去获得他们的反馈，通过几次迭代我们开始销售给其他用户。

这个过程将帮助你们公司寻找合适的问题解决方案，如果你正创建一个目的是为你的用户解决不同的问题的新功能或新业务线时，这个方法能够确保你为你的客户所做的是正确的事情。但是如果你已经有一个成熟的并不是从零开始的产品呢？

在企业内实验

现在许多企业单位通过顾问引入最小可行化产品的概念，这些顾问建议创建一个从零开始的新产品，这也许不是最好的主意。当你的公司已经有了适合市场的产品，你已经做了客户正在使用的产品，那么你就没有必要重建你们的产品，你需要的是改善它。改善方法应该适用于这种情况。

重建和改善这两个方法的区别在于目标。当寻找一个适合市场的产品时，你的目标是想让用户去采用你的产品并为之付费。这并不总是我们改善已经存在的产品的目标，改善的目标可以是提升用户黏度或是一些特定产品的参与度。无论你所决定的目标是什么，它都应当对队伍来说是清晰的、能够帮助做出明智决定的。

一旦目标清晰，你应该再次集中注意力去学习，在确认解决方案之前你所需要做的就是学习。记下这些关于你所想到的假设将会改善现状，然后设计一个产品实验去验证这些假设。你不必创建一个全新的产品，也许在实验过程中你会发现一个新产品是必要的，但这不应该是最终的目标。

一个我曾经辅导过的公司想提高他们整个网站的转换率，他们已经有一个流行的并且已经有成千上万用户使用的电子商务订购产品。然而尽管流量进来了，用户并没有像预测般转化地多，当为他们提供测试时并没有任何东西得到提高。他们仔细研究了大量客户的来源并发现其中许多客户来自推荐，但事实上只有少数人真正地发送了推荐。通过用户研究我们发现了两个主要的原因: 他们不知道他们可以发送推荐和他们并不确定推荐什么给朋友。

该团队决定着手处理第一个问题，并假设：“如果我们让用户清晰地知道他们有可利用的推荐方法，他们就会发送推荐”。第一个实验主要内容是当用户登录网页的时候会展示一个弹出页来鼓励用户去发送推荐。实验后推荐发送量上升了 30%，直接导致一个转化率的提升！他们在这里并没有实现一个全新的项目，他们只是不得不创建一个使之更明显的方式而已。

该团队继续挖掘关于转化的问题，他们发现了关于直接访问页面体验的三大问题：

1. 客户并不确定服务是怎么工作的。
2. 客户想知道哪些具体项目来自订阅。
3. 客户并不知道为什么产品价格高于竞争对手。

下一步解决这个问题的方式是看团队是否在能够传递价值的同时并从中学习。他们建立了假设：“如果我们在注册流程给用户他们正在寻找的信息，用户就会转化地更多”。他们也想知道哪个问题用户会最想点击从而看看哪个问题最强烈。他们计划了一个简单的方式用于在注册中去获得他们所需要的用户信息：在注册流程中增加一些显示问题的链接给用户。当链接被点击时，会展示一个弹出页解释的对应问题的答案。在构建和测试的这周末尾，他们看到实验促进了转化率接近至我们原始的目标，他们同时知道展示一些关于来自订阅信息是最重要的。该队伍将继续学习什么东西阻止了潜在顾客注册，并通过实验有条不紊地回答这些问题。

谨慎前行

一个公司犯下的错误就是将所学会的功能持续保留在场上，随后这些功能将给用户产生各种问题。你应该为了学习和前进而持续设计，而不是去实现一些能够永远持续的功能。

在上述团队中，他们学习到他们提供的信息是帮助潜在顾客回答问题，但是没有足够的用户能看到这个解决方案。经过多次的实验，他们学习到一个更健壮的解决方案是必要的。

是时候开始计划一个可持续地将学习纳入实验的解决方案了，在下一个阶段中远离产品实验并不是一个停止衡量的借口。该团队仍在不断发布小批量的组件，这些组件仍是带着完整的漂亮设计和更全面的愿景完成的。每隔两周一次地发布后，他们都会衡量在转换方面的效果，并在客户面前测试。用户的反馈会帮助他们产品的迭代并达到一个转化率目标。

Chris Matts 已经雄辩地将这样称为最小可行化投资，他指出你应该不仅要寻求改善你的用户面对产品的体验的方法，同样需要寻找一些能够帮助你快速创建产品的基础架构。上述团队同样改善他们的网站架构使客户等待测试结果时体验更加快速，我介绍 ProductKata 给团队用于改善他们的产品，并借此帮助他们通过产品实验和最小可行化投资寻找架构。

学习是目标

公司们在这一过程中最害怕的一部分是发布不完美的东西。用快速设计平衡好的设计和用快速开发平衡好的开发是十分重要的。最好做这件事情的方式是使 UI 设计师和开发者成对工作。在为迭代或实验定义目标之后，一起坐下来讨论如何执行主意。如果我们用稍微不同的方式设计，是否会对用户同样有用同时更容易开发呢？一起做原型，一起画草图，在整个过程中一边工作一边讨论代价与权衡，这就是好的队伍快速行动和避免重做的方法。

通过在早期学习什么是用户想要的，我已经避免了无数时间用于重做和抛弃功能。这就是为什么无论是 B2B 还是 C2C 中，团队做实验是十分重要的。应当给产品团队接触用户的途径，我已经看到公司会为他们的员工说或做一些让用户沮丧的事情而恐惧。如果你们用正确的方式教授你们的产品队伍去沟通和实验，这恐惧就不会发生。在用户研究方面锻炼团队，不要对任何人都进行实验，创建一个与小部分用户沟通的反馈队伍。为小团体建立相关基础架构，这样你便可以进行实验或打开一些功能。这些用户会指导你们创建满足他们需求的功能

我梦想有一天当我能够走进一家公司并提及最小可行化产品时，并不会听到“我们这里不做这个”。虽然最小可行化产品的定义也许会让我们的工作陷入混乱，但其之后的目标却对产品公司有着非凡的价值：快速了解你的客户想要什么。优秀的产品开发方式是在做产品之前了解用户想要什么。当你们投身于一个功能或解决方案时，确保它是正确的。

关于作者

** Melissa Perri ** 是一名产品经理、UX 设计师、演讲者和教练。她建立了 ProdUX Labs 来帮助产品队伍，并通过教导他们回答两个问题（“我们应该做这个吗？为什么？”）来制定满足用户和驱动商业目标的战略。她的用户包括 Spotify、Rovio、Valtech、Plated、Wayra UK 和 Levo League. 除了与客户合作之外，她还完成了 The Build Trap的书以及面向初高级产品经理们发布的一个在线平台 Product Management School 。
Twitter 地址： twitter

查看英文原文： https://www.infoq.com/news/2016/04/multitasking-economic-effects

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。