MVP (Minimum Viable Product, sản phẩm khả dụng tối thiểu) là phiên bản nhỏ nhất của một sản phẩm mà khách hàng thật dùng được, làm ra để trả lời một câu hỏi kinh doanh cụ thể, thường là: có ai cần cái này đủ để dùng hoặc trả tiền không. Nhận định của bài: trong báo giá và hợp đồng, MVP chỉ an toàn khi được định nghĩa bằng câu hỏi cần trả lời và danh sách những thứ sẽ không làm; một chữ MVP đi kèm câu "bản rút gọn" mà không có hai thứ đó là nguồn tranh chấp phổ biến nhất khi nghiệm thu.
Bài viết cho chủ doanh nghiệp định làm một sản phẩm số mới (ứng dụng cho khách, cổng đặt hàng, công cụ nội bộ) và đang nhận báo giá có dòng "giai đoạn 1: MVP".
Nghĩa bằng lời thường: bán thử trước khi mở cửa hàng
Trước khi thuê mặt bằng và sửa sang một nhà hàng, người cẩn thận sẽ bán thử vài món ở một quầy nhỏ để xem khách có quay lại không. MVP là quầy nhỏ đó. Nó phải nấu được món thật, cho khách thật ăn, thu tiền thật, nếu không thì không học được gì. Nhưng nó không cần bàn ghế đẹp, thực đơn năm mươi món hay hệ thống đặt bàn.
Khái niệm này phổ biến từ phương pháp Lean Startup (khởi nghiệp tinh gọn) của Eric Ries, xoay quanh vòng lặp xây dựng, đo lường, học hỏi: làm nhanh một bản nhỏ, đo khách dùng thế nào, rồi quyết định đi tiếp, đổi hướng hay dừng.
MVP hay bị nhầm với hai thứ gần nó. Bản mẫu (prototype) là mô hình để xem và bấm thử, thường chưa có dữ liệu thật, dùng để thống nhất giao diện và luồng. Bản thử nghiệm kỹ thuật (proof of concept) chứng minh một phần khó về kỹ thuật chạy được. MVP khác cả hai ở chỗ người dùng thật dùng nó cho việc thật. Bài ship MVP trong 30 ngày trên blog của Trần Công Thắng kể lịch làm MVP theo từng tuần từ phía người viết phần mềm, trong đó có một danh sách những thứ không làm được giữ cạnh màn hình suốt tháng.
MVP trong báo giá: chữ ngắn nhất, rủi ro tranh chấp lớn nhất
Báo giá thường có dòng "Giai đoạn 1: MVP, 8 tuần" kèm một danh sách tính năng. Rủi ro nằm ở chỗ bên mua và bên bán hiểu chữ tối thiểu khác nhau. Bên mua nghĩ MVP là sản phẩm hoàn chỉnh nhưng ít màn hơn; bên bán nghĩ MVP là bản chạy được luồng chính, chưa tối ưu, chưa xử lý các trường hợp hiếm. Đến lúc nghiệm thu, hai cách hiểu đó thành hai danh sách lỗi khác nhau.
| Hạng mục | Cách ghi dễ tranh chấp | Cách ghi đo được |
|---|---|---|
| Mục tiêu | Bản rút gọn của sản phẩm | Trả lời câu hỏi: 50 khách đầu tiên có đặt hàng lại trong 30 ngày không |
| Phạm vi | Các tính năng cơ bản | Danh sách luồng được làm, mỗi luồng một câu mô tả người dùng làm gì |
| Ngoài phạm vi | Không ghi | Danh sách thứ KHÔNG làm ở giai đoạn này: báo cáo nâng cao, đa ngôn ngữ, ứng dụng điện thoại riêng... |
| Chất lượng | Chạy ổn định | Thiết bị, trình duyệt được hỗ trợ; lỗi nào chặn nghiệm thu, lỗi nào để giai đoạn sau |
| Đo lường | Không ghi | Những con số sản phẩm phải tự ghi lại: lượt dùng, đơn hàng, điểm bỏ dở |
| Sau MVP | Phát triển tiếp theo nhu cầu | Mã nguồn và dữ liệu thuộc ai; giai đoạn 2 báo giá lại dựa trên số đo |
Dòng "Ngoài phạm vi" và dòng "Đo lường" là hai dòng hay vắng nhất, và cũng là hai dòng giữ tiền cho bên mua. Thiếu dòng ngoài phạm vi thì mọi yêu cầu nảy ra giữa chừng đều thành tranh luận có tính tiền hay không. Thiếu dòng đo lường thì sau MVP không có số liệu nào để quyết định đi tiếp, và toàn bộ lợi ích của việc làm nhỏ trước biến mất.
Về tiền, MVP thường được báo giá trọn gói cho giai đoạn một, còn các giai đoạn sau để ngỏ. Cách chia này hợp lý, với điều kiện hợp đồng ghi rõ đơn giá tính cho phần phát sinh (theo giờ công hay theo hạng mục) ngay từ đầu. Nếu không, sau khi MVP chạy tốt, bên mua đứng ở thế khó đàm phán: sản phẩm đã có người dùng, đổi đơn vị làm tiếp tốn thời gian bàn giao, và giá giai đoạn hai do bên bán tự định.
Thời hạn cũng nên quy ra lịch cụ thể thay vì "8 tuần" hay "60 ngày làm việc", vì nghỉ lễ và nghỉ bù làm hai cách đếm lệch nhau đáng kể. Ví dụ dưới đây đếm 60 ngày làm việc từ thứ Hai 05/10/2026, bỏ qua cuối tuần, lễ và nghỉ bù.
Làm nhỏ rồi đo: điều ALODEV áp dụng cho chính sản phẩm của mình
Với ALODEV AIO, phần mềm quản trị nội bộ của ALODEV, quy tắc làm việc hiện hành là dựng giao diện bằng dữ liệu mẫu để duyệt trước, chưa viết phần xử lý phía máy chủ cho tới khi màn hình được chốt. Cách này giữ chi phí sửa ở mức thấp nhất: đổi một màn hình chưa có dữ liệu thật rẻ hơn nhiều so với đổi cả giao diện lẫn cơ sở dữ liệu.
Việc đo cũng dẫn tới quyết định bỏ. Ngày 17/09/2026, ALODEV xoá 11 màn của ALODEV AIO sau khi số lượt mở trên hệ thống thật trong 12 ngày của các màn đó bằng 0. Đó là đúng tinh thần MVP áp dụng ngược lại: thứ không ai dùng thì không nên tiếp tục tốn công bảo trì, và chỉ biết được điều đó khi sản phẩm tự đếm lượt dùng ngay từ bản đầu.
Những câu nên hỏi nhà cung cấp trước khi ký
- MVP này sẽ trả lời câu hỏi kinh doanh nào của tôi, và con số nào cho biết câu trả lời là có hay không.
- Danh sách những thứ KHÔNG làm trong giai đoạn này là gì, và yêu cầu thêm giữa chừng được xử lý thế nào (đổi chỗ với tính năng khác hay báo giá riêng).
- Sản phẩm tự ghi lại những số liệu sử dụng nào, và tôi xem ở đâu.
- Phần nào của MVP sẽ dùng tiếp được ở giai đoạn sau, phần nào là làm tạm sẽ phải viết lại.
- Mã nguồn, tài khoản máy chủ, tên miền và dữ liệu người dùng thử thuộc về ai khi MVP kết thúc.
- Ngày bàn giao cụ thể là ngày nào, và tiêu chí nghiệm thu gồm những gì.
Khi nào không nên làm MVP
- Phần mềm thay thế một quy trình bắt buộc đang chạy, như tính lương, kế toán, hoá đơn. Không thể cho nhân viên dùng một nửa phần mềm lương; ở đây nên làm đầy đủ từng phân hệ và chạy song song với cách cũ.
- Đã có phần mềm đóng gói làm tốt việc đó. Thuê bao vài tháng để thử thường rẻ và nhanh hơn làm MVP riêng.
- Câu hỏi có thể trả lời không cần phần mềm: một biểu mẫu, một trang giới thiệu có nút đặt trước, hoặc gọi điện cho mười khách quen có khi đủ để biết có ai cần.
- Ngành có yêu cầu pháp lý hoặc an toàn chặt (y tế, tài chính, dữ liệu cá nhân nhạy cảm): phiên bản tối thiểu vẫn phải đạt các yêu cầu bắt buộc, nên phạm vi tối thiểu thường lớn hơn dự tính.
Với phần lớn sản phẩm mới hướng tới khách hàng, làm MVP vẫn là cách rẻ nhất để biết mình có đi đúng hướng. Điều kiện là hợp đồng ghi rõ câu hỏi, phạm vi, phần không làm và cách đo. Các điều khoản hợp đồng phần mềm khác nên có được bàn trong bài cách đàm phán hợp đồng phần mềm.
Câu hỏi thường gặp
MVP là gì, nói ngắn gọn?
MVP là phiên bản nhỏ nhất của sản phẩm mà khách hàng thật dùng được, làm ra để kiểm chứng một giả định kinh doanh trước khi đầu tư lớn.
MVP khác prototype thế nào?
Prototype là bản mẫu để xem và bấm thử, thường chưa có dữ liệu thật; MVP là sản phẩm chạy thật, có người dùng thật, dùng cho việc thật.
Làm MVP mất bao lâu?
Không có con số chung; phụ thuộc số luồng trong phạm vi. Điều nên làm là chốt ngày bàn giao cụ thể trong hợp đồng và cắt phạm vi để kịp ngày đó, thay vì kéo dài ngày để thêm tính năng.
MVP có phải là sản phẩm kém chất lượng?
Không. MVP ít tính năng chứ không được lỗi ở những luồng đã làm; khách dùng một bản lỗi sẽ cho kết quả đo sai, vì họ bỏ đi do lỗi chứ không phải do không cần sản phẩm.
Sau MVP thì làm gì?
Đọc số liệu đã đo và quyết định một trong ba hướng: đi tiếp và mở rộng, đổi hướng giả định, hoặc dừng. Báo giá giai đoạn hai nên dựa trên số liệu đó.
