如何在 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 等行為軟件來跟踪有多少用戶使用此選項，您可以很好地了解在下一次迭代中需要添加或更改哪些內容以增強您的產品。