Minimum Viable Product(MVP)
Phiên bản sản phẩm nhỏ nhất đủ để kiểm chứng một giả định quan trọng bằng người dùng thật. Mục tiêu là học được điều gì đó, không phải giao một bản rút gọn cho kịp hạn.
Định nghĩa
Có một cách hiểu sai đã ăn sâu tới mức khó gỡ: MVP là bản rút gọn, làm nhanh cho kịp deadline, xấu một chút cũng được, thiếu tính năng cũng được, sau này làm bù. Cách hiểu đó biến MVP thành cái cớ để giao hàng kém.
Eric Ries định nghĩa MVP là phiên bản sản phẩm cho phép team thu được lượng học hỏi đã kiểm chứng về khách hàng với ít công sức nhất. Từ khoá nằm ở "học hỏi", không nằm ở "tối thiểu". MVP tồn tại để trả lời một câu hỏi mà bạn chưa biết đáp án.
Nếu bạn đã chắc chắn người dùng cần cái đó, thứ bạn đang làm là bản phát hành đầu tiên, chứ chưa phải MVP.
Hai chữ hay bị bỏ quên: Viable
Chữ V trong MVP nghĩa là khả dụng. Người dùng phải làm được trọn một việc có ý nghĩa, và có trải nghiệm đủ tử tế để phản hồi của họ đáng tin. Sản phẩm chạy nửa vời, lỗi liên tục thì phản hồi thu về chỉ nói lên chuyện nó lỗi, chẳng nói được gì về nhu cầu thật.
Henrik Kniberg mô tả điều này bằng hình ảnh dễ nhớ: muốn giúp người ta đi lại, đừng giao lần lượt bánh xe, rồi khung xe, rồi mới tới ô tô. Hãy giao ván trượt, rồi xe đạp, rồi xe máy. Mỗi bước đều dùng được ngay và mỗi bước đều dạy bạn thêm điều gì đó.
Phân biệt MVP với PoC, Prototype và MMP
| Khái niệm | Trả lời câu hỏi | Ai dùng | Có chạy thật không |
|---|---|---|---|
| Proof of Concept | Cái này có làm được về mặt kỹ thuật không | Nội bộ, chủ yếu dev | Chạy được nhưng vứt đi sau |
| Prototype | Luồng này người dùng hiểu không | Vài người dùng, phòng lab | Không, chỉ là bản mô phỏng |
| MVP | Người dùng thật có cần và có dùng không | Người dùng thật, môi trường thật | Có |
| Minimum Marketable Product | Bản nhỏ nhất bán được ra thị trường | Khách hàng trả tiền | Có, đầy đủ hơn MVP |
Ví dụ thực tế
Đề bài từ ban lãnh đạo một chuỗi cà phê 22 cửa hàng nghe rất gọn: làm app đặt món cho đỡ xếp hàng giờ cao điểm. Kèm theo là danh sách tính năng: tích điểm, ví trả trước, giao hàng, đặt bàn, thông báo khuyến mãi. Ước tính khoảng 5 tháng.
Giả định thật sự cần kiểm chứng: khách có chịu đặt món trước qua điện thoại rồi tới lấy hay không. Mọi thứ khác đều dựa trên giả định đó.
MVP được chốt: chạy ở 2 cửa hàng đông nhất, menu 18 món bán chạy, chỉ đặt trước rồi tới lấy, thanh toán tại quầy, không tích điểm, không giao hàng. Ba tuần làm. Phần xác nhận đơn cho nhân viên là một màn hình web đơn giản trên máy tính bảng, không có app riêng cho quầy.
Sau 4 tuần chạy: 11% khách quen dùng thử, nhưng 58% trong số đó không quay lại lần hai. Phỏng vấn 15 người thì lý do lộ ra — họ không biết khi nào món pha xong, đến nơi vẫn phải đứng chờ 4 đến 6 phút. Vấn đề nằm ở thông báo trạng thái, một thứ chẳng ai nghĩ tới lúc đầu.
Kết quả: phần ví trả trước và đặt bàn bị lùi khỏi roadmap, thay bằng thông báo thời gian pha chế và hàng chờ theo thời gian thực. Ba tuần bỏ ra, đổi hướng của năm tháng còn lại. Và thứ đắt nhất thu về lại là mười lăm cuộc phỏng vấn kia: hai con số 11% với 58% chỉ báo có chuyện, còn chỗ hỏng thật thì nằm ở nơi chẳng ai ngờ tới.
Chọn giả định nào để kiểm chứng
Liệt kê những điều bạn đang tin nhưng chưa có bằng chứng, rồi xếp theo hai trục: sai thì thiệt hại tới đâu, và hiện đang chắc chắn tới mức nào. Cái nào thiệt hại lớn mà độ chắc chắn thấp thì kiểm chứng trước.
Đừng làm MVP cho những chuyện đã rõ. Không ai cần MVP để biết người dùng muốn đăng nhập được.
Lỗi hay gặp
- Gọi mọi bản phát hành đầu tiên là MVP, kể cả khi nó có 40 màn hình và 6 tháng làm.
- Làm MVP nhưng không đặt trước tiêu chí thành công. Chạy xong, mỗi người diễn giải kết quả một kiểu theo ý mình.
- Bỏ hết phần vận hành. MVP đụng tới tiền hoặc đơn hàng vẫn cần chỗ cho nhân viên xử lý sự cố, dù chỉ là một bảng tính.
- Cắt chất lượng thay vì cắt phạm vi. Cắt tính năng thì được, cắt tới mức app treo thì dữ liệu thu về vô giá trị.
- Làm MVP rồi không dám dừng. Kết quả nói nên đổi hướng, nhưng đã trót hứa với ban lãnh đạo nên cứ làm tiếp.
