Ma trận Ship to Learn và góc nhìn sai mang tên Agile.

Đưa một tính năng sơ sài ra thị trường rồi gọi đó là MVP để học hỏi? Không đâu, đấy thực chất là sự lấp liếm cho việc lười làm Product Discovery.

Cứ đưa lên Production đi rồi xem Data nó nói gì. Thật ra Data nó bảo: Bố ông PM dỡ hơi ạ, sao không hỏi User từ đầu mà lại xả rác vào app?.

Ship to learn. Ba chữ dỡ hơi nhất hay được mấy tay PM mới vào nghề và Agile giả cày dùng để nói. Ngày xưa mình cũng vậy. Nghĩ ra một cái ý tưởng loé sáng trong toilet, vẽ đại 3 cái wireframe vớ vẩn, dí cho Dev kêu làm gấp thành cái “MVP” tung ra thị trường. 1 tháng sau? Không ai xài. Mình vuốt cằm ra chiều uyên bác: À, thị trường không cần, chúng ta đã học được một bài học quý. Gớm, tấu hài với vẫn!

Ông anh Tech Lead đập thẳng cái ly trà đá xuống bàn: “Em học được cái quái gì ngoài chuyện đốt mất của anh 2 sprint mồ hôi nước mắt?”. Cú tát thẳng mặt về bản chất giả tạo của phong trào lạm dụng chữ Agile.

Sự lừa ngọt ngào của vỏ bọc MVP

Ship nhanh để học là triết lý đỉnh cao của vĩ nhân. Không sai. Khốn nỗi, đa số PM bây giờ dùng nó làm khiên chắn cho sự lười biếng tận mạng. Lười nghiên cứu, lười vẽ user behavior, lười đối thoại trực tiếp với khách hàng. Nói chung là lười Discovery.

Chưa cần nói ra khỏi mồm chữ Agile sành điệu, hệ lụy nhãn tiền:

• Bạn biến User thành chuột bạch cho một tính năng nửa mùa, đầy bugs, và UI xấu rối mù. Họ chán, xóa app.

• Bạn tống bầy nhầy vào codebase. Khi tính năng fail lòi, chả ai buồn dọn đống code thừa mứa ấy đi. Mọi thứ cứ nằm lỳ ở đấy như một mớ Tech Debt (nợ kỹ thuật) khổng lồ, giảm nhịp độ chạy của các sprint sau.

• Data nhiễu loạn. Lúc tính năng gây ra lỗi, data bảo user không click vào cái mới. Do họ không thích hay do nút bấm bị chìm lỉm? Mù tịt. Bạn chẳng học được cái khỉ khô gì từ một mẫu test chưa rõ mục tiêu.

Agile không bảo bạn nhắm mắt phi tiêu trong bóng tối bạt ngàn. Agile xui bạn đưa giả thuyết và luôn có hypothesis, tìm một cách để chứng minh giả thuyết đó, rồi mới nhúng tay viết code.

Discovery: Làm ơn đừng làm biếng

Khắc phục chứng ngáo lạm dụng Ship to learn bằng cách nào? Siêng lên. Trả chữ Learn về đúng chỗ của nó: Dịch ngay lên đầu, trước chữ Ship.

1. Test bằng nước bọt: Chưa có dòng code nào? Dùng miệng mà test. Lôi cái ý tưởng đó ra cafe nói chuyện với 5 người dùng tiềm năng. Nếu họ chửi rát mặt, bạn vừa tiết kiệm cho công ty vài ngàn đô Mỹ.

2. Fake door test: Vẽ đúng cái nút bấm (CTA) tinh vi. Bấm vào thì hiện dòng chữ trần tình “Tính năng đang xây, nhập email đợi nhé”. Đo lường đúng độ mót của tệp người dùng. Thế mới là dân chơi.

3. Ship to WIN, đừng Ship to LEARN: Một khi đã dồn lực huy động 5 anh Dev và 3 anh QA vào cuộc, tâm thế là phải đẩy thành công để chiến thắng. Đừng đẩy rác cầu may lấy bài học.

4. =)) cho PR tý dùng thử skill mình đóng gói lại cách mình hay làm. Link ở đây

Chốt hạ lại cái gì bạn có thể làm nhanh nhất.

Có một bài test rất rẻ. Ngày mai, bật danh sách Backlog ra. Chọn ngẫu nhiên 3 tính năng bạn định đẩy vào “MVP tháng sau”. Đặt đồng hồ đếm ngược 10 phút. Nếu bạn không thể mô tả dõng dạc cho thằng nhóc lớp 5 hiểu vì sao 3 cái tính năng này giải quyết sống còn nỗi đau của user... thì bạn chỉ đang vẽ spec rác.

Agile cho phép lặp, không cho phép lười. Dám vứt đi nửa Backlog để xây 1 tính năng mượt khiến user sướng vì bạn biết đó thực sự vấn đề của user hoặc ít nhất bạn đã rất tin vào nó, bạn làm được không?

T.D
4.2026