Những tờ sticky note trông rất tự tin ở đầu buổi workshop. Một cột ghi “must have,” một cột ghi “later,” và một tờ nhỏ ở góc ghi “MVP” như thể bản thân chữ đó sẽ bảo vệ team khỏi build quá nhiều. Đến cuối buổi chiều, board vẫn đầy, ngày launch vẫn gần, và không ai hoàn toàn chắc phiên bản đầu tiên cần chứng minh điều gì.
Minimum Viable Product là một trong những ý tưởng hữu ích nhưng trở nên nguy hiểm khi biến thành khẩu hiệu. Ở dạng tốt nhất, MVP là một công cụ học. Nó là phiên bản nhỏ nhất của product hoặc feature có thể kiểm tra một assumption quan trọng với user thật hoặc hành vi thị trường thật. Ở dạng yếu hơn, nó trở thành giấy phép để ship thứ chưa hoàn chỉnh, khó hiểu, hoặc mỏng đến mức không dạy team được gì.
Cái bẫy đầu tiên là cắt cho đến khi product không còn viable. Team bỏ onboarding, feedback message, empty state, support path, data quality check và error handling vì những phần đó trông phụ so với main feature. Rồi user chạm vào product, thấy lạc, và rời đi. Team kết luận “người ta không cần nó,” trong khi có thể chỉ học được rằng người ta không hiểu hoặc không tin nó.
Cái bẫy thứ hai là build quá nhiều trước tín hiệu thật đầu tiên. Điều này xảy ra khi MVP trở thành phiên bản nhỏ hơn của giấc mơ cuối cùng, thay vì một bài test tập trung. Team thêm setting, dashboard, integration, role permission và edge-case support trước khi validate assumption rủi ro nhất. Product có thể nhìn hoàn chỉnh hơn, nhưng learning đến muộn và đắt. Một first release đẹp vẫn có thể quá nặng.
Cái bẫy thứ ba là không có hypothesis rõ. “Cứ launch MVP rồi xem sao” nghe linh hoạt, nhưng thường che đi uncertainty mà team nên gọi tên. Mình cần học gì? Rằng user có vấn đề này? Rằng họ sẽ đổi behavior? Rằng họ sẽ trả tiền? Rằng workflow này nằm vừa trong một ngày làm việc của họ? Rằng solution của mình tốt hơn spreadsheet hoặc manual service? Không có hypothesis, kết quả nào cũng dễ bị diễn giải lại.
Cái bẫy thứ tư là đo activity thay vì learning. Page view, signup, click và demo đều có thể hữu ích, nhưng chỉ khi chúng nối với câu hỏi đang test. Nếu assumption là user sẽ hoàn tất một workflow đau nhanh hơn, completion rate và time saved quan trọng hơn visits. Nếu assumption là willingness to pay, sự quan tâm lịch sự có thể chưa đủ. Metric nên được chọn trước launch, khi team ít bị cám dỗ bảo vệ ý tưởng hơn.
Cái bẫy thứ năm là bỏ qua operations. Product có thể minimal nhưng vẫn cần support, monitoring, rollback, documentation và ownership. Nếu MVP tạo manual work cho team, manual work đó là một phần của experiment và nên được nhìn thấy. Nếu mỗi user đều cần developer sửa data bằng tay, team đã học một điều quan trọng. Gọi nó là tạm thời không làm nó miễn phí.
Technical debt là một cái bẫy thầm lặng khác. Một số shortcut hợp lý vì chúng mua learning. Một số khác chỉ là confusion trong tương lai được dán nhãn product. Khác biệt nằm ở việc team có ghi lại shortcut, risk và điều kiện để quay lại xử lý hay không. “Mình sẽ hardcode integration này cho mười pilot customer” có thể là lựa chọn có chủ đích. “Mình quên chuyện này hardcode cho đến khi customer thứ mười một xuất hiện” là câu chuyện khác.
MVP tốt cũng bảo vệ user trust. Minimal không có nghĩa là cẩu thả. Nếu product xử lý tiền, private data, quyết định nghề nghiệp, health information hoặc thứ gì có sức nặng cảm xúc, thanh viable phải cao hơn. Phiên bản đầu có thể hẹp, nhưng không nên liều. Đôi khi bài test có trách nhiệm nhỏ nhất là concierge workflow, prototype, waitlist conversation, hoặc manual service đứng sau một lời hứa được làm chỉn chu, không phải một production feature vội.
Theo thời gian, tôi cẩn trọng hơn với chữ MVP. Không phải vì ý tưởng này dở, mà vì nó cần kỷ luật. Câu hỏi hữu ích không phải “mình cắt được gì?” Mà là “cách nhỏ nhất và trung thực nhất để học điều quan trọng nhất là gì?” Nếu team trả lời được câu đó bình tĩnh, phiên bản đầu không cần gây ấn tượng với tất cả mọi người. Nó chỉ cần dạy team quyết định tiếp theo.