Mở đầu — vì sao bài này quan trọng
Hãy thành thật với nhau một chút: phần lớn ý tưởng sản phẩm mà bạn nghĩ ra là ý tưởng tồi. Không phải vì bạn kém — mà vì đó là bản chất thống kê của việc làm sản phẩm. Ngay cả những founder xuất sắc nhất cũng đẻ ra mười ý tưởng thì chín cái nên chết yểu. Vấn đề không nằm ở chỗ bạn có ý tưởng tồi, mà nằm ở chỗ bạn mất bao lâu để nhận ra điều đó.
Đây chính là lý do "kill bad ideas fast" — giết ý tưởng tồi thật nhanh — là một trong những kỹ năng có giá trị nhất nhưng lại bị xem nhẹ nhất trong toàn bộ hành trình product discovery. Trong các bài trước, bạn đã học cách phỏng vấn user, cách scoring opportunity, cách tìm secret. Tất cả những kỹ năng đó đều tạo ra ý tưởng. Nhưng tạo ra ý tưởng là phần dễ. Phần khó — và phần quyết định bạn sống hay chết — là biết cái nào nên vứt đi, và vứt đi trước khi bạn đã đổ sáu tháng và vài tỷ đồng vào nó.
Vấn đề tâm lý cốt lõi là thế này: founder và PM mặc định gắn cảm xúc với ý tưởng của mình. Ý tưởng giống như đứa con tinh thần. Bạn càng nói với người khác về nó, càng vẽ slide đẹp về nó, càng tuyển người về làm nó, thì cái giá tâm lý của việc thừa nhận "nó sai" càng đắt. Đến một lúc, bạn không còn discovery để tìm sự thật nữa — bạn discovery để tìm bằng chứng chứng minh mình đúng. Đó là lúc tổ chức bắt đầu đốt tiền.
Bài này dạy bạn biến "kill" thành một kỹ năng có quy trình, có tiêu chí, có cảm xúc được kiểm soát — thay vì một quyết định đau đớn mà bạn cứ trì hoãn mãi.
Khái niệm cốt lõi
Kill là tiết kiệm, không phải thất bại
Hãy đổi lại framing trong đầu bạn. Khi bạn kill một ý tưởng tồi sau hai tuần thay vì sau sáu tháng, bạn vừa tiết kiệm được khoảng năm tháng rưỡi nhân với chi phí team. Với một team năm người ở Việt Nam, đó có thể là 400-600 triệu đồng được cứu. Kill không phải là dấu hiệu bạn yếu kém — nó là dấu hiệu bạn có kỷ luật vốn. Mỗi lần kill nhanh, bạn giải phóng nguồn lực để đặt cược vào ý tưởng tiếp theo. Discovery về bản chất là một trò chơi loại trừ: bạn không tìm ra ý tưởng đúng bằng cách yêu một ý tưởng, mà bằng cách giết hàng loạt ý tưởng sai cho đến khi cái còn sót lại đủ vững.
Sunk cost fallacy — kẻ thù số một
Sunk cost fallacy (ngụy biện chi phí chìm) là hiện tượng bạn tiếp tục đầu tư vào một thứ chỉ vì bạn đã lỡ đầu tư vào nó rồi, dù bằng chứng nói nó không hiệu quả. "Mình build gần xong rồi, bỏ thì phí." — câu này đã chôn vùi hàng nghìn startup. Sự thật phũ phàng: tiền và thời gian bạn đã bỏ ra đã mất rồi, dù bạn quyết định gì đi nữa. Quyết định đúng đắn chỉ nên dựa trên: từ giờ trở đi, đặt nguồn lực còn lại vào đây có phải lựa chọn tốt nhất không? Nếu không, kill — bất kể bạn đã bỏ vào đó bao nhiêu.
Falsifiability — ý tưởng phải có khả năng bị bác bỏ
Một ý tưởng tốt là ý tưởng bạn có thể chứng minh là sai. Nghe ngược đời, nhưng đúng. Nếu bạn không thể nói rõ "điều gì xảy ra thì tôi sẽ kết luận ý tưởng này sai", thì bạn không có ý tưởng — bạn có một niềm tin tôn giáo. Trước khi cam kết build, bạn phải định nghĩa được kill criteria (tiêu chí giết): các con số, hành vi, hoặc tín hiệu cụ thể mà nếu chạm tới, bạn buộc phải dừng. Đặt kill criteria trước khi chạy thử nghiệm, lúc cảm xúc còn lạnh, là cách duy nhất để bảo vệ bạn khỏi chính mình lúc cảm xúc nóng lên.
Phân biệt "kill ý tưởng" và "pivot"
Đừng nhầm hai khái niệm. Kill là vứt bỏ hoàn toàn một giả thuyết về vấn đề hoặc giải pháp. Pivot (sẽ học kỹ ở Bài 18) là giữ lại phần lõi đã được validate và xoay hướng phần chưa đúng. Ở bài này ta tập trung vào hành động kill: nhận ra ý tưởng đã chết, gọi tên nó, và buông tay dứt khoát — kèm việc rút bài học để ý tưởng tiếp theo tốt hơn.
Reversible vs irreversible — tốc độ kill phụ thuộc vào loại quyết định
Không phải ý tưởng nào cũng cần kill cùng tốc độ. Với quyết định "hai chiều" (reversible — dễ đảo ngược), bạn nên quyết nhanh, thử nhanh, kill nhanh. Với quyết định "một chiều" (irreversible — khó đảo ngược, như đốt hết ngân sách marketing vào một campaign lớn), bạn cần thêm bằng chứng trước khi cam kết. Phần lớn ý tưởng discovery thuộc loại hai chiều — nghĩa là bạn được phép, và nên, kill nhanh hơn bạn tưởng.
Tình huống thực tế
Ví dụ 1 — App giao đồ ăn cho dân văn phòng (giả định, bối cảnh TP.HCM)
Một team bốn người ở quận 1 nảy ra ý tưởng: app đặt cơm trưa theo combo cố định cho dân văn phòng, giao đúng 11h45, giá rẻ hơn GrabFood vì gom đơn theo tòa nhà. Founder cực kỳ tâm huyết — anh tin "ai cũng ghét cảnh 12h mở app chọn món rồi đợi 40 phút".
Họ đặt kill criteria từ đầu (rất đáng khen): "Nếu sau hai tuần chạy thử ở ba tòa nhà, dưới 15% nhân viên đặt lại lần thứ hai, chúng ta kill." Họ chạy concierge thủ công — tự nhận đơn qua Zalo, tự đi mua, tự giao. Kết quả: lần đầu nhiều người thử vì tò mò và vì rẻ. Nhưng tỷ lệ đặt lại tuần hai chỉ 9%. Phỏng vấn ra mới hiểu: dân văn phòng thích sự đa dạng, ghét bị ép combo cố định; và việc phải đặt trước 10h sáng phá vỡ thói quen "quyết định phút chót" của họ.
Founder muốn cứu ý tưởng: "Hay là cho chọn 3 combo thay vì 1?" Nhưng team quay lại nhìn kill criteria đã đặt: 9% < 15%. Họ kill sau đúng 16 ngày. Bài học: kill criteria đặt trước lúc cảm xúc lạnh đã cứu họ khỏi vòng xoáy "thêm tính năng để cứu ý tưởng chết". Họ tiết kiệm được khoảng năm tháng và xoay sang một bài toán khác có tín hiệu tốt hơn.
Ví dụ 2 — Tính năng "social feed" trong một app fintech Đông Nam Á (giả định hợp lý)
Một startup ví điện tử có 200 nghìn user quyết định thêm "social feed" — nơi bạn bè thấy nhau chi tiêu, like, comment, kiểu Venmo của Mỹ. Đội ngũ mê mẩn vì Venmo thành công vang dội với mô hình này. Họ đã build 4 tháng, dồn 3 engineer.
Vấn đề: họ chưa bao giờ đặt kill criteria và chưa bao giờ test giả định cốt lõi — rằng người Việt/người Đông Nam Á muốn khoe và chia sẻ giao dịch tài chính. Khi ra mắt beta, chỉ 2% user bật tính năng, và trong số đó 80% tắt đi sau ba ngày. Lý do văn hóa rất rõ trong phỏng vấn: chuyện tiền bạc ở khu vực này mang tính riêng tư cao, "ai lại đi khoe mình vừa chuyển 500k cho ai".
Đáng lẽ đây phải là kill ngay. Nhưng sunk cost lên tiếng: "Build 4 tháng rồi, giờ bỏ thì phí ba người." Họ cố cứu thêm 3 tháng nữa bằng cách thêm chế độ riêng tư, thêm gamification — vô ích. Cuối cùng vẫn phải gỡ. Bài học: một giả định văn hóa lớn (người dùng muốn khoe tài chính) đáng lẽ phải được test bằng một smoke test rẻ tiền trước khi viết dòng code đầu tiên. Không có kill criteria + sunk cost fallacy = đốt thêm 3 tháng cho một xác chết.
Ví dụ 3 — Tiki và quyết định không làm "mạng xã hội đọc sách" (bối cảnh thật, diễn giải)
Giai đoạn đầu, Tiki khởi nguồn là nhà sách online tiếng Anh. Trong quá trình discovery, hẳn đã có vô số ý tưởng mở rộng hấp dẫn: làm cộng đồng review sách, làm mạng xã hội cho người yêu sách, làm nội dung… Điều đáng học là Tiki đã không lao theo mọi ý tưởng "hay ho" đó mà tập trung vào tín hiệu thật: người ta cần một nơi mua hàng nhanh, giao nhanh, đáng tin. Những ý tưởng cộng đồng/nội dung — dù gắn cảm xúc và "có vẻ đúng tinh thần yêu sách" — đã bị gác lại hoặc kill để dồn lực cho logistics và mở rộng ngành hàng.
Bài học: kill không chỉ là giết ý tưởng đã thử và thất bại, mà còn là kỷ luật không khởi động những ý tưởng hấp dẫn nhưng lệch trọng tâm. Mỗi "không" với một ý tưởng tồi là một "có" mạnh mẽ hơn cho ý tưởng cốt lõi. (Bạn sẽ xem sâu hành trình Tiki ở Bài 37.)
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho bất kỳ ý tưởng nào trước và trong khi discovery.
Bước 1 — Viết ra giả định nguy hiểm nhất (the riskiest assumption). Với mỗi ý tưởng, hỏi: "Điều gì phải đúng thì ý tưởng này mới sống được, và điều gì trong số đó tôi ít chắc chắn nhất?" Ở ví dụ fintech, giả định nguy hiểm nhất là "người dùng muốn chia sẻ giao dịch". Đó chính là thứ cần test đầu tiên, không phải thứ dễ test nhất.
Bước 2 — Đặt kill criteria bằng con số, trước khi chạy. Viết ra một câu rõ ràng dạng: "Nếu [chỉ số] dưới [ngưỡng] sau [thời gian/số mẫu], chúng tôi kill." Ví dụ: "Nếu dưới 20 trong 100 người được khảo sát sẵn sàng để lại email/đặt cọc, kill." Ghi nó vào tài liệu, cho cả team thấy. Đây là khoảnh khắc quan trọng nhất — vì lúc này cảm xúc của bạn còn lạnh.
Bước 3 — Chạy thử nghiệm rẻ và nhanh nhất có thể. Đừng build để test. Dùng smoke test, concierge, hoặc chỉ 10 cuộc phỏng vấn The Mom Test. Mục tiêu là lấy tín hiệu, không phải sản phẩm hoàn chỉnh.
Bước 4 — So tín hiệu với kill criteria một cách lạnh lùng. Đặt con số thực tế cạnh ngưỡng đã định. Không diễn giải, không "nhưng mà". Số là số.
Bước 5 — Ra quyết định và gọi tên nó công khai. Nếu chạm kill criteria, kill. Nói thẳng với team: "Ý tưởng này đã chết vì [lý do cụ thể]." Việc gọi tên công khai giúp giải phóng cảm xúc và biến nó thành bài học chung, không phải thất bại cá nhân.
Bước 6 — Viết postmortem ngắn (3-5 dòng). Ghi lại: giả định gì đã sai, tín hiệu nào cho thấy điều đó, và bài học mang sang ý tưởng kế tiếp. Đây là cách bạn biến mỗi cái kill thành vốn tri thức thay vì chỉ là mất mát.
Lỗi thường gặp & mẹo
Lỗi 1 — Đặt kill criteria sau khi đã có kết quả. Nếu bạn chỉ định ngưỡng sau khi nhìn thấy số, não bạn sẽ tự động kéo ngưỡng xuống cho khớp với kết quả đẹp. Luôn đặt trước.
Lỗi 2 — Liên tục dời cột mốc (moving the goalposts). "15% đặt lại là chưa đủ kết luận, đợi thêm hai tuần nữa." Nếu bạn thấy mình liên tục gia hạn, đó chính là sunk cost đang lái xe. Mẹo: cho phép tối đa một lần gia hạn, và phải có lý do phương pháp luận rõ ràng (ví dụ mẫu quá nhỏ), không phải vì bạn không thích kết quả.
Lỗi 3 — Nhầm "thiếu tín hiệu" với "tín hiệu xấu". Đôi khi thử nghiệm thất bại vì bạn chạy sai cách (sai đối tượng, sai kênh), không phải vì ý tưởng tồi. Mẹo: trước khi kill, hỏi "tôi có thực sự đã test đúng giả định chưa?". Nhưng cẩn thận — câu hỏi này cũng dễ bị lạm dụng làm cớ để không kill.
Lỗi 4 — Vote cảm tính trong phòng họp. Khi cả team gắn bó với ý tưởng, biểu quyết tay sẽ thiên vị "tiếp tục". Mẹo: giao vai "devil's advocate" (người phản biện) luân phiên — một người có nhiệm vụ chính thức là tìm mọi lý do để kill. Việc này hợp pháp hóa sự phản biện và gỡ áp lực cá nhân.
Lỗi 5 — Coi kill là chuyện riêng của founder. Mẹo: tổ chức nên có "kill ritual" — một nghi thức ăn mừng nhỏ mỗi khi kill nhanh một ý tưởng tồi. Khi kill được tưởng thưởng thay vì bị xấu hổ, cả đội sẽ kill nhanh hơn và trung thực hơn.
Mẹo vàng — "Nếu hôm nay mới biết những gì đang biết, tôi có khởi động ý tưởng này không?" Câu hỏi này gỡ sạch sunk cost ra khỏi quyết định. Nếu câu trả lời là "không", bạn đã có câu trả lời.
Bài tập thực hành
- Lập kill criteria cho ý tưởng hiện tại. Lấy một ý tưởng sản phẩm bạn đang ấp ủ. Viết ra giả định nguy hiểm nhất của nó trong đúng một câu. Sau đó viết một câu kill criteria dạng "Nếu [chỉ số] dưới [ngưỡng] sau [thời gian/mẫu], tôi kill." Yêu cầu: ngưỡng phải là con số cụ thể, không được dùng từ "tốt", "ổn", "khá".
- Bài tập gỡ sunk cost. Nghĩ về một dự án/tính năng bạn (hoặc công ty bạn) đang tiếp tục dù trong lòng nghi ngờ. Trả lời thành thật: "Nếu hôm nay tôi mới biết tất cả những gì đang biết, tôi có bắt đầu nó không?" Viết ra câu trả lời và một quyết định cụ thể bạn sẽ đề xuất.
- Đóng vai devil's advocate. Lấy ý tưởng của một người bạn cùng học. Trong 10 phút, liệt kê 5 lý do mạnh nhất khiến ý tưởng đó nên bị kill, kèm cách rẻ nhất để kiểm chứng từng lý do. Mục tiêu là luyện cơ "phản biện không cảm tính".
- Viết một postmortem giả định. Tưởng tượng ý tưởng ở bài tập 1 đã chết. Viết postmortem 5 dòng: giả định nào sai, tín hiệu nào lẽ ra cảnh báo bạn, và bạn sẽ test khác đi thế nào lần sau.
Tóm tắt
Kill bad ideas fast là kỹ năng phân biệt founder kỷ luật với founder đốt tiền. Phần lớn ý tưởng của bạn sẽ tồi — điều đó bình thường; vấn đề là bạn nhận ra trong hai tuần hay sáu tháng. Hai kẻ thù lớn nhất là gắn cảm xúc với ý tưởng và sunk cost fallacy ("đã lỡ bỏ vào nên tiếc"). Vũ khí chống lại chúng là kill criteria bằng con số, đặt trước khi chạy thử nghiệm, cộng với câu hỏi giải độc "nếu hôm nay mới biết những gì đang biết, tôi có khởi động không?". Hãy chạy thử nghiệm rẻ nhất có thể, so tín hiệu với ngưỡng một cách lạnh lùng, gọi tên cái chết của ý tưởng công khai, và viết postmortem ngắn để biến mất mát thành vốn tri thức. Mỗi lần bạn kill nhanh một ý tưởng tồi, bạn không thất bại — bạn vừa giải phóng nguồn lực cho ý tưởng tiếp theo, và đó chính là cách discovery thật sự vận hành.