如何在 3 小时内定义 MVP 范围

当我被一家早期支付处理公司聘为产品经理时，该公司正在努力及时创建和交付库存管理系统。 解决方案是一个简单的键盘应用程序，它对用户不友好，因此导致了大量的客户流失。 我的工作是领导一个负责构建库存系统的团队，将应用程序的功能扩展到键盘功能之外。

因为我们必须在截断的时间线上进行操作，所以我创建了一种简单但极其有效的方法来构思、设计和构建具有符合用户需求的核心功能的最小可行产品 (MVP)。 这个过程将 MVP 的范围缩小到一个密集的三个小时的会议中——而不是几天或几周——并为我们的团队节省了几个月的开发时间。

这种加速的 MVP 范围界定过程可用于指导任何产品团队，并可应用于任何零对一产品的创建。

用例概述

问题：该应用程序的简单键盘功能无法为供应商用户提供管理库存或选择要添加到客户订单中的项目的能力。

限制：公司领导希望在八周内交付解决方案； 潜在的筹款轮次部分取决于产品改进版本的成功。

背景：通过对市场的分析，在与我们的许多用户打交道后，我确定这些供应商需要一个库存管理系统来简化他们的销售流程。 我看着他们处理客户的订单：首先，他们将要求的商品写在纸上，用计算器计算商品数量，然后将订单输入到应用程序中。 他们本应该只需要一个的时候却使用了三个工具。

解决方案：我们需要开发一种解决方案，使用户能够将他们的库存加载到数字目录中，管理这些库存，然后点击选定的项目将它们添加到客户的购物车中——所有这些都在应用程序中。

设计冲刺决策

因为我们已经知道我们需要开发什么产品，所以我选择放弃典型的设计冲刺——一个为期四到五天的研讨会，团队在其中协作确定一个主要的业务挑战，从客户那里收集关于如何解决问题的想法，开发产品概念，设计原型并开始测试。

设计冲刺是构建 MVP 的一种有效方法——对于那些需要确定核心问题并且有大量时间来开发解决方案的人来说。 然而，在早期公司或现有组织中的新业务部门中，核心问题通常很明显：概念已经制定，产品/市场契合度通常在产品经理、工程师和设计师被引入之前就已经确定。

下面的流程图分解了我在决定进行该项目的最佳方式是跳过设计冲刺并从三个小时的会议开始时所采取的步骤，也称为团队启动。 在那次会议上，参与者将集思广益并产生数十个功能想法，然后将列表缩减为仅 MVP 所需的内容。

MVP 开发过程

准备

在三小时的会议之前，您需要通过与当前或潜在客户交谈和观察并进行市场调查来收集有关您的用户角色的信息。

然后，为设计师和工程师创建演示文稿。 它应该解释：

• 你试图解决的问题。
• 您正在构建的产品。
• 产品将如何在指标和用户体验方面解决该问题。
• 产品对您和您客户的业务的预期影响。
• 公司和团队级别的任务、目标和关键结果 (OKR)，以及产品如何帮助完成这些任务和实现这些 OKR。

演示文稿应该让设计师和工程师对产品有深入的了解，以继续确定 MVP 的范围。

三小时的启动会议

启动应该涉及整个开发团队，允许他们参与流程的每个阶段，从构思和故事创建到 MVP 概念开发。 这包括高级、初级​​和副产品经理； 产品所有者； 产品线索（如适用）； 用户体验设计师； 软件工程师； 和质量保证工程师。

快速提示：虽然它是非正统的，但我建议在构建阶段之前包括工程师。 他们通常会提供很棒的想法，并对他们正在尝试改进的产品充满热情。 他们中的大多数人都喜欢参与确定 MVP 的范围。 它可以帮助他们对项目进行更多投资并受到其他团队的重视。

将所有人聚集在会议室或虚拟工作空间中。 在我们的例子中，我们有 10 个人。 封锁三个小时。

产品和用户旅程（60 分钟）

1. 交付演示文稿。 （15分钟）

2. 开始为您的产品识别所有用户角色。 即使您尚未确定任何流程或功能工作，您也可以定义需要构建的流程数量。 （10分钟）

   快速提示：不要通过添加不必要的角色来过度设计。 在 MVP 发布后，客户反馈将显示您是否需要额外的角色。

   用例示例：我们有三个角色：商店经理（或管理员）、收银员和最终客户。 还有其他潜在的高级角色，例如店主，但出于 MVP 的目的，管理员可以涵盖这些角色。

3. 从头到尾映射用户旅程。 为每个角色分配一种颜色，以帮助识别用户将遇到的流程的每个步骤。 对于面对面会议，将便签贴在墙上或使用白板。 对于虚拟会议，请使用 FigJam 板或类似的东西。 （35 分钟）

   快速提示：让团队分享他们所有的想法——并细化。 流程的每一步都将成为一个要构建的功能——每个用户都有一个单独的流程——但概述这些步骤的过程将是相同的。

   用例示例：这是我们的收银员角色的功能列表：

   • 打开销售点应用程序。
   • 使用 PIN 登录。
   • 确定客户购买的第一个项目。
   • 确定项目的数量。
   • 确定客户购买的任何其他物品。
   • 为商品添加折扣（如果适用）。
   • 购物车中所有商品的总成本（此时显示全部购买价格，包括销售税）。
   • 完成结帐和付款处理。
   • 确认购买。
   • 允许客户添加小费。
   • 关闭销售。
   • 显示所有每日销售额的总和。
   • 在预定的不活动时间（例如，五分钟）后超时。

   注意：此列表详细说明了我们为此角色考虑的大部分功能。 作为收银员、商店经理和最终客户，我们在所有角色中提出了大约 60 个总功能，重叠最少，因为收银员、商店经理和最终客户都以不同的方式与应用程序互动。 根据您正在开发的产品类型，用户类型之间可能会有更多的功能重叠。

   

用户旅程的基本特征（45 分钟）

1. 在真实或虚拟白板上将每种用户类型的功能分组到每个用户旅程的离散部分。 然后，在板上画一条水平线。 在该线上方，确定产品工作所需的套件。 在这条线的下方，放置一些不错的功能，但可以等到以后的版本。 （30分钟）

   快速提示：将设计师和工程师分成小组以完成此步骤，然后重新开会比较笔记。 这在 10 人或更多人的会议中特别有用。

   用例示例：对于我们的应用程序，此时我们有 12 个功能集，包括将商品加载到库存目录、定价、选择要添加到客户购物车的商品、结账和关闭销售、重新订购低库存、和更多。 我们最终将功能集的数量减少到四个。

   这个消除过程帮助我们确定用户的安全登录在应用程序的第一次迭代中不是必需的。 也没有增加折扣或小费。 我们还决定，作为 MVP 的一部分，收银员不需要能够显示所有每日销售额的总和，尽管商店经理或所有者可能会这样做。

2. 细化特征列表。 问“如果这被省略了，产品还能用吗？” 如果答案是肯定的，请将该功能排除在 MVP 之外——将其保存到产品的后续迭代中。 如果答案是否定的，您必须在 MVP 中包含该功能。 在此过程结束时，您将了解使您的产品功能真正需要什么。 通常，这将仅包含每组的三个或四个功能。 （15分钟）

   注意：避免在 MVP 中构建过多的功能集。 虽然您应该预料到关于最重要的内容的不同意见，但您作为产品经理的工作是打电话。 您已经完成了研究并拥有数据来支持您的决定。 根据我的经验，许多产品最初的构建比他们需要的更强大，大多数公司更愿意尽快将一些东西送到用户手中进行测试和反馈。

产品设计、测试和工程（75 分钟）

1. 让设计人员将核心功能集成到 MVP 的线框设计中，工程师将使用它来构建产品的架构。 （45分钟）

2. 允许产品专家和设计师一起对线框设计进行一些轻量级的 UX 测试。 （15分钟）

   注意：很少有产品管理场景可以在不涉及最终客户的情况下构建，但在快速测试和开发的情况下，您可以在内部或与不了解您产品的朋友和家人一起测试设计原型。 如果他们感到困惑，那么您的一些用户也会感到困惑。

3. 将设计好的线框图交给工程师，让他们开始构建 MVP 的架构。 他们不会拥有构建完整解决方案所需的一切或时间，但他们可以开始，并且在完成 MVP 时将使用他们构建的架构。 同时，产品和设计团队可以继续以内部团队成员或朋友和家人作为用户对其线框图进行测试。 让团队在此步骤上同时工作可以节省时间。 （15分钟）

随着您越来越熟练地使用此过程，识别哪些功能是 MVP 的核心组件以及哪些功能可以稍后构建将变得更加容易。 这种做法还可以防止您构建错误的东西：您可能对“稍后”的列表有一些想法，但后来才知道没有客户想要它。

结果和关键要点

在我们努力之前，我们的应用程序是一个带有数字 0 到 9、小数点和充电按钮的键盘。 由于这种限制和它创建的低效工作流程，在一年的时间里，我们的保留率一直很低——大约 20%。 虽然我们获得新用户的速度比我们的竞争对手快，但我们失去他们的速度几乎一样快。

在创建 MVP 的整个过程中，我们构建了四个关键功能集，所有这些功能集的范围都很小，但质量很高。 用户现在可以：

1. 只需使用相机、输入名称并输入价格，即可将物品直接从移动设备加载到库存中。
2. 选择这些商品并将它们添加到客户的购物车中。
3. 在查看正在出售的物品时关闭销售。
4. 查看在给定时间范围内售出的商品数量。

客户喜欢改进后的产品。 在加载项目的第一周内，利用目录功能结账至少五次的新用户的保留率为 45%。

由于我们 MVP 范围界定过程的效率，我们在大约两个月内构建并交付了我们完全完成的应用程序。 使用传统的开发方法，这个过程可能需要四个月或更长时间——如果产品曾经被构建过的话。

这种快速的过程可以节省时间和金钱。 完整的设计冲刺可能会很昂贵。 从启动会议开始，我的流程从一开始就更加经济，而这些节省被更短的整体开发时间表放大了。

但是，这两个流程也可以协同工作：如果您的团队完成了设计冲刺以定义核心业务问题和您需要创建的解决方案，您可以使用我的流程更有效地定义您的 MVP 范围。

请记住，这个过程只是一个开始：MVP 是一项正在进行的工作，将在以后的版本中进一步完善。 一旦它完全构建并准备好交付，我建议添加一个用户可以关闭以返回旧应用程序体验的 beta 开关。 利用 Heap 等行为软件来跟踪有多少用户使用此选项，您可以很好地了解在下一次迭代中需要添加或更改哪些内容以增强您的产品。