MVP là gì và những thứ hay bị gọi nhầm là MVP

MVP — minimum viable product — là khái niệm bị dùng sai nhiều nhất trong khởi nghiệp. Phần lớn thứ được gọi là MVP thật ra là một sản phẩm đầy đủ bị cắt bớt cho kịp hạn.

Sự khác nhau không nằm ở kích thước. Nó nằm ở mục đích.

Định nghĩa hay bị hiểu sai

Cách hiểu phổ biến: MVP là phiên bản có ít tính năng nhất mà vẫn dùng được. Cách hiểu này dẫn tới một câu hỏi sai — "cắt được gì?" — và câu trả lời luôn là cắt những thứ khó làm, giữ những thứ dễ làm.

Cách hiểu dùng được hơn: MVP là thứ rẻ nhất trả lời được câu hỏi mà nếu bạn trả lời sai thì bạn mất nhiều nhất.

Định nghĩa này đổi hẳn thứ tự công việc. Bạn không bắt đầu từ danh sách tính năng rồi gạch bớt. Bạn bắt đầu từ danh sách những điều mình đang giả định, xếp theo mức thiệt hại nếu giả định đó sai, rồi hỏi: rẻ nhất để kiểm cái đầu tiên là gì?

Bắt đầu từ câu hỏi đắt nhất

Viết ra ba đến năm điều bạn đang tin mà chưa có bằng chứng. Ví dụ với một tiệm bán đồ ăn theo tuần:

• Người ta chịu đặt trước cả tuần thay vì mua từng bữa.
• Họ chịu trả cao hơn hàng quán quen ba chục phần trăm.
• Mình giao được đúng giờ ở khung sáng sớm.

Với mỗi giả định, hỏi hai câu: nếu sai thì mất bao nhiêu, và kiểm nó tốn bao nhiêu.

Giả định "người ta chịu đặt trước" mà sai thì toàn bộ mô hình sụp — thiệt hại lớn nhất. Và nó lại rẻ nhất để kiểm: nhận đặt trước cho hai mươi suất trong một tuần, thu tiền thật, nấu thủ công. Không cần ứng dụng, không cần bếp mới.

Giả định "giao đúng giờ khung sáng" đắt để kiểm hơn và ít chết người hơn — nếu sai, bạn đổi khung giờ. Nó xuống sau.

Thứ tự này là toàn bộ giá trị của MVP. Làm sai thứ tự thì bạn xây ứng dụng đặt hàng trước khi biết có ai muốn đặt trước không.

Bốn dạng MVP không cần code

Bán trước khi có. Mở nhận đơn và thu tiền cho thứ chưa tồn tại, nói rõ ngày giao. Đây là phép kiểm mạnh nhất vì nó bắt người ta trả giá bằng tiền. Nếu không ai đặt, bạn vừa tiết kiệm được vài tháng.

Người đứng sau màn. Giao diện trông tự động, bên trong bạn làm tay. Khách nhận đúng kết quả cuối; bạn học được quy trình thật trước khi tự động hoá nó. Rất nhiều dịch vụ lớn khởi đầu đúng như vậy.

Một trang đích và một nút. Mô tả sản phẩm, đặt nút mua, đo bao nhiêu người bấm. Yếu hơn bán trước vì không có tiền đổi tay, nhưng rẻ và nhanh — hợp khi bạn cần loại nhanh vài ý tưởng.

Làm tay cho ba người. Không sản phẩm, không giao diện. Bạn tự phục vụ ba khách hàng từ đầu đến cuối và ghi lại từng bước. Ba khách là đủ để thấy chỗ nào tốn thời gian nhất — và đó chính là chỗ đáng xây đầu tiên.

Khi nào MVP kết thúc

MVP kết thúc khi câu hỏi của nó đã có câu trả lời — không phải khi nó đủ đẹp.

Đây là chỗ nhiều người mắc kẹt: họ nhận được câu trả lời rõ ràng từ tuần thứ hai, nhưng vẫn tiếp tục hoàn thiện bản MVP thêm ba tháng vì nó chưa "xong". Nếu bạn đã biết người ta chịu đặt trước, việc tiếp theo không phải là làm giao diện đặt trước đẹp hơn. Việc tiếp theo là kiểm giả định tiếp theo trong danh sách.

Một MVP tốt để lại hai thứ: một câu trả lời, và một danh sách giả định ngắn hơn danh sách hôm qua.

Ba thứ hay bị gọi nhầm là MVP

Bản demo. Một bản chạy được để trình bày cho nhà đầu tư hoặc cho chính mình xem. Nó không có người dùng thật, không thu tiền, và không ai chịu bất tiện gì để dùng nó. Demo trả lời câu hỏi "làm được không", còn MVP trả lời câu hỏi "có ai cần không". Hai câu khác nhau, và câu thứ hai mới là câu giết doanh nghiệp.

Bản beta. Sản phẩm đã xây gần xong, mở cho một nhóm dùng trước để bắt lỗi. Đến lúc này mọi quyết định đắt tiền đã ra hết rồi — beta chỉ chỉnh được phần ngọn. Gọi nó là MVP là tự trấn an rằng mình đã kiểm giả định, trong khi thật ra mình đã đặt cược xong.

Bản cắt cho kịp hạn. Cắt vì hết thời gian, không phải vì có chủ đích. Cách nhận ra: hỏi "tính năng này bị bỏ để kiểm giả định nào?" Nếu câu trả lời là "vì không kịp", đó không phải MVP, đó là một sản phẩm chưa xong.

Sai lầm ngược lại: MVP quá nhỏ

Có một hướng sai ít được nói tới. MVP nhỏ đến mức không ai dùng được thì nó cũng không trả lời được gì.

Chữ viable trong minimum viable product nghĩa là người dùng phải nhận được một kết quả trọn vẹn, dù bằng con đường xấu xí. Một tiệm bán đồ ăn theo tuần có thể nhận đơn qua tin nhắn thay vì ứng dụng — nhưng vẫn phải giao đủ bảy bữa đúng giờ. Bỏ bớt bữa để "tối giản" thì phép kiểm hỏng: khách không quay lại vì thiếu bữa, và bạn kết luận nhầm rằng người ta không cần dịch vụ này.

Quy tắc thực dụng: cắt cách làm, đừng cắt kết quả. Kết quả phải nguyên vẹn thì tín hiệu mới sạch.

Một khuôn để bắt đầu tuần này

Viết ba dòng, mỗi dòng một giả định, theo mẫu:

Tôi tin rằng [nhóm người cụ thể] sẽ [hành động tốn kém] vì [lý do].

Ví dụ: Tôi tin rằng các mẹ có con nhỏ ở khu này sẽ trả trước cả tuần tiền ăn vì họ muốn hết phải nghĩ bữa sáng.

Rồi với mỗi dòng, điền hai con số: mất bao nhiêu nếu sai, tốn bao nhiêu để kiểm. Sắp xếp theo tỷ lệ giữa hai con số đó và làm cái đầu tiên. Đó là MVP của bạn — và nó thường nhỏ hơn nhiều so với thứ bạn đang định xây.