MVP LÀ GÌ VÀ TÁM LOẠI MVP

Chọn cách thử nghiệm rẻ nhất cho rủi ro lớn nhất, từ trang đích đơn giản đến mô hình phù thủy xứ Oz

---

Khi nghe từ MVP, nhiều nhóm khởi nghiệp hình dung một phiên bản ứng dụng rút gọn: ít tính năng hơn, giao diện thô hơn, nhưng vẫn là phần mềm phải lập trình trong vài tháng. Cách hiểu này khiến MVP trở thành một dự án phát triển sản phẩm thu nhỏ, trong khi mục đích ban đầu của nó là một công cụ học hỏi. Hệ quả là nhiều nhóm mất ba tháng để dựng thứ mà một trang đích, một đoạn video hay vài buổi phục vụ khách bằng tay có thể trả lời trong ba tuần.

MVP, viết tắt của Minimum Viable Product, nghĩa là sản phẩm khả dụng tối thiểu. Điểm then chốt không nằm ở từ "sản phẩm" mà ở câu hỏi nó trả lời: giả định nào trong ý tưởng của bạn rủi ro nhất và cách rẻ nhất để kiểm chứng giả định đó với khách hàng thật là gì. Có nhiều loại MVP khác nhau, mỗi loại hợp với một loại rủi ro và một mức ngân sách.

Bài viết gồm sáu phần. Mục 1 định nghĩa MVP và phân biệt nó với prototype và MVBP. Mục 2 trình bày tám loại MVP phổ biến kèm ví dụ. Mục 3 hướng dẫn chọn loại MVP theo rủi ro lớn nhất và theo chi phí. Mục 4 giới thiệu pretotyping, cách thử trước cả khi làm nguyên mẫu và trình tự kiểm chứng theo loại rủi ro. Mục 5 mô tả cách thiết kế một thí nghiệm MVP để kết quả có thể ra quyết định. Mục 6 tổng hợp những sai lầm thường gặp và bàn về MVP trong thời AI.

1. MVP là gì và không phải là gì

Khái niệm MVP thường bị lẫn với bản mẫu thử nghiệm hay phiên bản đầu tiên của sản phẩm. Mục này nêu định nghĩa, nguồn gốc và phân biệt MVP với hai khái niệm gần nó.

1.1. Định nghĩa và nguồn gốc

Thuật ngữ MVP được Frank Robinson dùng từ đầu những năm 2000 và trở nên phổ biến nhờ cuốn The Lean Startup của Eric Ries (2011). Ries định nghĩa MVP là phiên bản của sản phẩm mới cho phép nhóm thu được nhiều học hỏi đã được kiểm chứng về khách hàng nhất, với ít công sức nhất. Hai vế của định nghĩa này đều quan trọng: "nhiều học hỏi nhất" nghĩa là MVP phải trả lời được một câu hỏi rõ ràng; "ít công sức nhất" nghĩa là không làm thêm bất cứ thứ gì không cần cho việc trả lời câu hỏi đó.

MVP là trung tâm của vòng lặp Xây dựng, Đo lường, Học hỏi trong phương pháp tinh gọn. Nhóm xây một thứ tối thiểu, đo phản ứng thật của khách hàng, học từ dữ liệu, rồi quyết định tiếp tục hay xoay trục. Vòng lặp càng ngắn, nhóm càng học nhanh và càng ít lãng phí.

1.2. Prototype, MVP và MVBP

Ba khái niệm prototype, MVP và MVBP thường bị dùng lẫn lộn, nhưng chúng trả lời ba câu hỏi khác nhau và nối tiếp nhau, như Hình 1.

Hình 1. Prototype, MVP, MVBP và sản phẩm đầy đủ.

Khái niệm MVBP, viết tắt của Minimum Viable Business Product, đến từ phương pháp Khởi nghiệp có kỷ luật của Bill Aulet (2013), ở bước 21. Aulet nhấn mạnh rằng một sản phẩm tối thiểu chỉ thật sự có ý nghĩa kinh doanh khi thỏa ba điều kiện: khách hàng nhận được giá trị khi dùng, khách hàng trả tiền cho nó và nhóm có được vòng phản hồi từ khách hàng. Bảng 1 so sánh ba khái niệm.

Bảng 1. So sánh prototype, MVP và MVBP

Như Bảng 1 cho thấy, một prototype đẹp có thể chứng minh nhóm làm được, nhưng không chứng minh ai cần. Một MVP tốt có thể không có dòng mã nào, nhưng phải cho ra bằng chứng về hành vi của khách hàng thật. Bài Khởi nghiệp có kỷ luật với 24 bước của Bill Aulet (MIT) đặt MVBP trong toàn bộ 24 bước.

2. Tám loại MVP phổ biến

Có rất nhiều cách làm MVP, nhưng phần lớn thuộc tám dạng cơ bản. Mục này mô tả từng dạng, kèm ví dụ quốc tế đã được ghi nhận rộng rãi và ví dụ giả định ở Việt Nam.

2.1. Nhóm kiểm chứng sự quan tâm: trang đích, video và cửa giả

Ba dạng đầu tiên kiểm chứng xem có ai quan tâm đến ý tưởng hay không, trước khi làm ra bất cứ thứ gì để giao.

Trang đích là một trang web mô tả sản phẩm như thể nó đã tồn tại, kèm một lời kêu gọi hành động như đăng ký nhận tin, để lại số điện thoại hay đặt chỗ. Nhóm chạy một ít quảng cáo đến trang và đo tỷ lệ chuyển đổi. Đây là dạng thử khói phổ biến nhất, được trình bày chi tiết trong bài Xác thực nhu cầu thị trường bằng thử khói.

Video giới thiệu dùng khi sản phẩm khó mô tả bằng chữ. Trường hợp nổi tiếng là Dropbox: trước khi sản phẩm hoàn thiện, Drew Houston làm một video vài phút trình diễn cách đồng bộ tệp hoạt động, nhắm đến cộng đồng công nghệ. Theo Ries (2011), danh sách chờ bản thử nghiệm tăng từ khoảng 5.000 lên 75.000 người chỉ sau một đêm, xác nhận nhu cầu trước khi nhóm đầu tư tiếp vào hạ tầng phức tạp.

Cửa giả (fake door) là một nút bấm hoặc mục menu cho một tính năng chưa có. Khi người dùng bấm, họ thấy thông báo tính năng đang được phát triển và có thể đăng ký nhận tin. Tỷ lệ bấm cho biết mức quan tâm thật. Cần dùng cửa giả một cách trung thực và tiết chế, vì lạm dụng sẽ làm người dùng mất lòng tin.

2.2. Nhóm giao giá trị bằng tay: Concierge và Wizard of Oz

Hai dạng tiếp theo giao giá trị thật cho khách hàng, nhưng phần việc phía sau được làm thủ công thay vì tự động.

Concierge MVP nghĩa là nhóm phục vụ khách hàng trực tiếp và công khai bằng tay, như một người quản gia. Ries (2011) kể trường hợp Food on the Table, một dịch vụ lập thực đơn và danh sách đi chợ theo khuyến mãi của siêu thị: nhà sáng lập bắt đầu bằng việc tự đến nhà một khách hàng, tự tìm khuyến mãi và tự soạn thực đơn mỗi tuần, rồi mới tự động hóa từng phần khi số khách tăng. Khách biết có người phục vụ và nhóm học được chính xác điều gì khách coi trọng.

Wizard of Oz MVP thì ngược lại: khách hàng nghĩ mình đang dùng một hệ thống tự động, nhưng phía sau là con người làm thay. Trường hợp thường được nhắc là Zappos: năm 1999, Nick Swinmurn chụp ảnh giày ở các cửa hàng địa phương, đăng lên website và khi có đơn thì ra cửa hàng mua giày đó với giá bán lẻ rồi gửi cho khách. Phép thử trả lời câu hỏi then chốt: mọi người có chịu mua giày trực tuyến không, trước khi đầu tư kho bãi và hệ thống.

Ví dụ giả định ở Việt Nam: một nhóm muốn làm ứng dụng gợi ý thực đơn tuần cho dân văn phòng. Thay vì lập trình thuật toán gợi ý, nhóm lập một nhóm Zalo 30 người, mỗi tối Chủ nhật gửi thực đơn tuần do một thành viên tự soạn, kèm danh sách đi chợ. Sau bốn tuần, nhóm đo bao nhiêu người mở, bao nhiêu người hỏi thêm và bao nhiêu người đồng ý trả 49.000 đồng mỗi tháng để tiếp tục.

2.3. Nhóm dựng tối thiểu: ghép công cụ sẵn có và MVP một tính năng

Hai dạng này có phần mềm thật, nhưng được dựng theo cách tối thiểu nhất.

MVP ghép công cụ sẵn có (piecemeal) dựng dịch vụ bằng cách nối các công cụ đã có thay vì tự lập trình. Groupon thời kỳ đầu thường được dẫn làm ví dụ: website ban đầu là một blog dựng trên WordPress, phiếu giảm giá được tạo thành tệp PDF và gửi qua email. Ngày nay, các công cụ như biểu mẫu trực tuyến, bảng tính, công cụ tự động hóa và nền tảng không cần viết mã cho phép dựng một dịch vụ khá hoàn chỉnh trong vài ngày.

MVP một tính năng chỉ làm đúng một việc cốt lõi và làm tốt việc đó. Thay vì một ứng dụng quản lý tài chính cá nhân đầy đủ, nhóm chỉ làm tính năng nhập chi tiêu bằng một câu nhắn tin. Nếu người dùng quay lại dùng tính năng đó mỗi ngày, nhóm có bằng chứng để mở rộng; nếu không, thêm tính năng khác cũng khó cứu.

2.4. Nhóm thu tiền trước: đặt trước và gây quỹ cộng đồng

Dạng cuối cùng cho bằng chứng mạnh nhất vì khách hàng bỏ tiền thật trước khi sản phẩm có mặt. Nhóm mở cho đặt trước với tiền cọc, hoặc chạy chiến dịch gây quỹ cộng đồng. Năm 2012, đồng hồ thông minh Pebble huy động hơn 10 triệu USD trên Kickstarter, cho thấy nhu cầu trước khi sản xuất hàng loạt. Với nhóm nhỏ ở Việt Nam, hình thức tương đương là nhận đặt cọc cho lô hàng đầu tiên qua trang đích hoặc mạng xã hội, kèm cam kết hoàn tiền rõ ràng nếu không giao được.

2.5. Tóm tắt tám loại MVP

Bảng 2 tóm tắt tám loại MVP theo cách làm, câu hỏi chính mà mỗi loại trả lời và ví dụ.

Bảng 2. Tám loại MVP phổ biến

Tám loại trong Bảng 2 không loại trừ nhau. Một nhóm có thể bắt đầu bằng trang đích để kiểm chứng sự quan tâm, chuyển sang concierge để hiểu giá trị, rồi mới dựng MVP một tính năng khi đã biết chính xác cần tự động hóa phần nào.

3. Chọn loại MVP nào?

Với tám lựa chọn, câu hỏi thực tế là bắt đầu từ đâu. Mục này trình bày hai tiêu chí chọn: loại rủi ro lớn nhất của ý tưởng và tương quan giữa chi phí với mức cam kết đo được.

3.1. Chọn theo rủi ro lớn nhất

Mỗi ý tưởng có nhiều giả định, nhưng thường có một giả định mà nếu sai thì mọi thứ khác không còn ý nghĩa. MVP nên nhắm vào giả định đó trước. Bảng 3 gợi ý loại MVP phù hợp với từng loại rủi ro.

Bảng 3. Chọn loại MVP theo rủi ro lớn nhất

Thứ tự trong Bảng 3 cũng thường là thứ tự kiểm chứng hợp lý: chưa chắc có nhu cầu thì chưa nên tốn công kiểm chứng vận hành. Trước khi chọn MVP, nhóm nên đã có dữ liệu định tính từ phỏng vấn khách hàng, như hướng dẫn trong bài 25 câu hỏi phỏng vấn khách hàng theo The Mom Test.

3.2. Chọn theo chi phí và mức cam kết

Tiêu chí thứ hai là cân nhắc chi phí dựng MVP so với độ mạnh của bằng chứng thu được. Hình 2 đặt tám loại MVP trên hai trục này.

Hình 2. Bản đồ tám loại MVP theo chi phí dựng và mức cam kết đo được (vị trí mang tính tương đối).

Hình 2 cho thấy hai điều đáng chú ý. Thứ nhất, các MVP rẻ nhất cho bằng chứng yếu nhất: một lượt đăng ký email cho thấy sự tò mò, chưa cho thấy nhu cầu trả tiền. Thứ hai, đặt trước là ngoại lệ đáng giá: chi phí không cao nhưng bằng chứng rất mạnh, vì tiền thật là cam kết khó giả vờ. Ngược lại, MVP một tính năng tốn kém nhất, nên chỉ làm khi các loại rẻ hơn đã trả lời xong câu hỏi về nhu cầu và giá trị.

4. Pretotyping và trình tự kiểm chứng

Sau khi chọn được loại MVP, nhiều đội vẫn mắc một lỗi quen thuộc: lao ngay vào viết mã hoặc chế tạo nguyên mẫu. Alberto Savoia, từng phụ trách kỹ thuật ở Google, đề xuất một bước đi trước cả nguyên mẫu mà ông gọi là pretotyping (Savoia, 2019).

4.1. Giả lập trước khi chế tạo

Từ pretotype ghép từ "pretend" (giả vờ) và "prototype" (nguyên mẫu): một pretotype giả lập trải nghiệm sản phẩm mà không xây hệ thống thật phía sau. Lý do nằm ở hai câu hỏi khác nhau. Nguyên mẫu trả lời "chúng ta có làm ra được không và nó trông thế nào?". Pretotype trả lời "nếu làm ra, có ai thật sự muốn không?". Tìm cách chế tạo một thứ không ai cần là lãng phí, nên câu hỏi thứ hai nên được trả lời trước (Savoia, 2019). Khi dùng pretotyping, có ba nguyên tắc:

1. Rẻ nhất, nhanh nhất, gần dữ liệu thật nhất: thử một chút trước khi đầu tư nhiều.
2. Đo hành vi có cam kết: khách phải tốn công bấm, để lại email, đặt cọc hay trả tiền, thay vì chỉ nói "tôi sẽ mua". Savoia gọi đó là dữ liệu có "da thịt trong cuộc chơi" (skin in the game).
3. Hỏi đúng câu: MVP dùng để đo việc khách dùng lại, MVBP dùng để đo việc khách trả tiền.

Nhiều loại MVP ở mục 2 thực chất là kỹ thuật pretotyping: trang đích, video, cửa giả, Wizard of Oz, concierge, ghép công cụ. Savoia còn mô tả thêm một số kỹ thuật ít được nhắc tới, tóm trong Bảng 4.

Bảng 4. Một số kỹ thuật pretotyping bổ sung cho tám loại MVP

Nguồn: phỏng theo Savoia (2019).

4.2. Pretotyping không thay thế nguyên mẫu

Pretotyping là bộ lọc để trì hoãn việc xây thật cho đến khi có bằng chứng về nhu cầu, không phải cách xây doanh nghiệp. Sau khi pretotype thành công, đội vẫn phải làm nguyên mẫu để giải bài toán kỹ thuật và phải làm MVP, MVBP thật vì hai lý do. Thứ nhất, các kỹ thuật giả lập thường làm bằng tay, không mở rộng được. Thứ hai, pretotype chủ yếu đo ý định mua lần đầu; muốn biết khách có ở lại và trả tiền đều đặn không, phải có một sản phẩm thật chạy đủ lâu để đo tỷ lệ giữ chân.

Với sản phẩm vật lý, nơi không thể dùng Wizard of Oz và sản xuất hàng loạt rất đắt, gọi vốn cộng đồng là một dạng MVBP gần như lý tưởng: video giới thiệu cộng với trang đích, nhưng khách trả tiền thật cho một sản phẩm chưa sản xuất. Đó vừa là vốn, vừa là bằng chứng mạnh về nhu cầu trước khi nhà máy bấm nút.

4.3. Trình tự kiểm chứng theo loại rủi ro

Đến đây có năm khái niệm: bằng chứng khái niệm (POC), pretotype, nguyên mẫu, MVP và MVBP. Không có một trình tự cố định cho mọi dự án; trình tự phụ thuộc vào rủi ro nào lớn hơn, như Hình 3.

Hình 3. Hai trình tự kiểm chứng theo loại rủi ro.

Với dự án công nghệ sâu, y tế hay phần cứng phức tạp, nhu cầu thường đã rõ nhưng chưa biết khoa học có cho phép làm được không, nên POC phải đi trước để chứng minh nguyên lý. Với phần mềm tiêu dùng, dịch vụ hay nền tảng kết nối, công nghệ đã sẵn và ai cũng làm được; rủi ro lớn nhất là khách có dùng và trả tiền không, nên có thể bỏ qua POC và bắt đầu ngay bằng pretotyping.

5. Thiết kế một thí nghiệm MVP

Một MVP không có tiêu chí thành công rõ ràng thì kết quả nào cũng có thể được diễn giải là tốt. Mục này mô tả cách viết thẻ thí nghiệm và cách quyết định sau khi có kết quả.

5.1. Thẻ thí nghiệm

Trước khi dựng MVP, hãy viết ra giả thuyết, chỉ số đo và ngưỡng quyết định, rồi thống nhất trong nhóm. Bảng 5 là một thẻ thí nghiệm mẫu cho ví dụ thực đơn tuần ở Mục 2.2 (số liệu giả định).

Bảng 5. Thẻ thí nghiệm MVP mẫu (giả định)

Điều quan trọng nhất trong Bảng 5 là ngưỡng quyết định được đặt trước khi có kết quả. Nếu đặt sau, nhóm rất dễ hạ ngưỡng cho vừa với con số mình có được.

5.2. Sau thí nghiệm: tiếp tục, điều chỉnh hay xoay trục

Kết quả của một MVP dẫn đến một trong ba quyết định. Tiếp tục khi chỉ số vượt ngưỡng: chuyển sang kiểm chứng giả định rủi ro tiếp theo, hoặc tự động hóa phần đã làm tay. Điều chỉnh khi kết quả lưng chừng: thay đổi một yếu tố như phân khúc, thông điệp hay mức giá rồi thử lại. Xoay trục khi kết quả thấp rõ rệt: giả định cốt lõi sai, cần thay đổi hướng đi. Bài Phát triển mô hình kinh doanh qua bốn giai đoạn bàn thêm về các kiểu xoay trục. Khi các MVP liên tiếp cho kết quả tốt và khách hàng bắt đầu ở lại lâu dài, nhóm chuyển sang đo Product-Market Fit, như trình bày trong bài Product-Market Fit là gì? Cách đo PMF bằng Sean Ellis test.

6. Sai lầm thường gặp và MVP trong thời AI

Dù khái niệm MVP đã phổ biến hơn mười năm, nhiều nhóm vẫn mắc những lỗi giống nhau. Mục này tổng hợp các sai lầm đó và bàn về việc AI làm thay đổi ý nghĩa của MVP như thế nào.

6.1. Năm sai lầm thường gặp

Bảng 6 tổng hợp năm sai lầm phổ biến nhất và cách tránh.

Bảng 6. Năm sai lầm thường gặp khi làm MVP

Sai lầm cuối trong Bảng 6 cần hiểu đúng. Tối thiểu không có nghĩa là cẩu thả ở phần cốt lõi: nếu MVP kiểm chứng giá trị của một bữa ăn lành mạnh, thì bữa ăn phải thật sự ngon và lành mạnh, chỉ có bao bì, giao diện đặt hàng hay quy trình thanh toán là được phép thô sơ.

6.2. MVP trong thời AI

Công cụ AI giúp dựng một ứng dụng trông hoàn chỉnh chỉ trong vài ngày. Điều này làm giảm mạnh chi phí xây dựng, nhưng cũng tạo ra một cái bẫy mới: sản phẩm trông hoàn chỉnh dễ khiến nhóm nhầm rằng mình đã tiến bộ, trong khi chưa có thêm bằng chứng nào về khách hàng. Steve Blank (2013), người đặt nền móng cho phương pháp phát triển khách hàng, cho rằng trong bối cảnh này, việc dựng được sản phẩm không còn chứng minh được điều gì và đề xuất khái niệm IUP thay cho MVP trong lớp học khởi nghiệp. Bài Từ MVP đến IUP trong lớp khởi nghiệp trình bày chi tiết quan điểm này.

Hệ quả thực tế là tinh thần ban đầu của MVP càng quan trọng hơn: thước đo không phải là đã dựng được gì, mà là đã học được gì từ khách hàng thật. Khi dựng sản phẩm trở nên rẻ, lợi thế chuyển sang những nhóm biết đặt đúng câu hỏi và thiết kế đúng thí nghiệm.

Kết luận

MVP là phiên bản giúp nhóm học được nhiều nhất về khách hàng với ít công sức nhất, không phải phiên bản thu nhỏ của sản phẩm cuối cùng. Nó khác prototype, vốn trả lời câu hỏi có làm được không và đứng trước MVBP của Aulet, nơi khách hàng trả tiền, nhận giá trị và cho phản hồi. Tám loại MVP phổ biến trải từ kiểm chứng sự quan tâm (trang đích, video, cửa giả), giao giá trị bằng tay (concierge, Wizard of Oz), dựng tối thiểu (ghép công cụ, một tính năng) đến thu tiền trước (đặt trước, gây quỹ).

Chọn loại MVP nên bắt đầu từ rủi ro lớn nhất của ý tưởng và cân nhắc chi phí so với độ mạnh của bằng chứng; đặt trước thường là lựa chọn có tỷ lệ bằng chứng trên chi phí tốt nhất. Mỗi MVP cần một thẻ thí nghiệm với giả thuyết, chỉ số và ngưỡng quyết định viết ra từ trước. Trước khi xây, pretotyping giúp kiểm tra có ai thật sự muốn sản phẩm hay không và trình tự kiểm chứng nên đi theo rủi ro lớn nhất: công nghệ hay thị trường. Trong thời AI, khi dựng sản phẩm trở nên dễ dàng, giá trị của MVP càng nằm ở việc học, không nằm ở việc xây.

Đọc thêm

• Từ MVP đến IUP trong lớp khởi nghiệp
• Xác thực nhu cầu thị trường bằng thử khói
• Khởi nghiệp có kỷ luật với 24 bước của Bill Aulet (MIT)
• Phát triển mô hình kinh doanh qua bốn giai đoạn
• Bảy chặng kiểm chứng của một startup

Tài liệu tham khảo

Aulet, B. (2013). Disciplined entrepreneurship: 24 steps to a successful startup. Wiley. https://www.wiley.com/en-gb/Disciplined+Entrepreneurship%3A+24+Steps+to+a+Successful+Startup-p-9781118720813

Blank, S. (2013). Why the lean start-up changes everything. Harvard Business Review, 91(5), 63–72. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything

Ries, E. (2011). The lean startup: How today's entrepreneurs use continuous innovation to create radically successful businesses. Crown Business. https://www.penguinrandomhouse.com/books/210088/the-lean-startup-by-eric-ries/

Savoia, A. (2019). The right it: Why so many ideas fail and how to make sure yours succeed. HarperOne. https://www.amazon.com/s?k=The+right+it+Savoia&i=stripbooks