Thí nghiệm giá rẻ trước khi viết mã: trang đích, concierge, Wizard of Oz và bán trước

Đăng ngày 23/10/2026

Tóm tắt và điều cần nhớ

Giai đoạn xác thực có một câu hỏi thực dụng mà bài này trả lời: trước khi bỏ vài tuần viết mã, việc gần như không tốn tiền nào cho biết khách có thật sự làm điều bạn cần? Bài đứng sau phần chọn giả thuyết rủi ro nhất và phỏng vấn khách, trước phần đo mức sẵn sàng chi trả.

• Xếp thí nghiệm lên hai thang: công sức và tiền bạn bỏ ra, và mức cam kết của khách, từ chú ý đến tiền.
• Trang đích và video đo sự quan tâm; concierge và Wizard of Oz đo việc dùng và quay lại; bán trước đo cam kết bằng tiền nhưng buộc bạn giao hàng.
• Ngưỡng đi, đổi hướng hay dừng phải viết bằng con số trước khi chạy, kèm độ bất định của mẫu nhỏ.
• Kết quả rẻ thành giả khi sai nhóm người xem, mẫu quá nhỏ, cam kết quá rẻ, người làm thành một phần sản phẩm, hoặc chỉ thử điều dễ đo.
• AI hạ chi phí dựng, không hạ chi phí tìm đúng khách và nhận cam kết thật; dựng nhanh dễ tạo cảm giác đã xác thực.

Bối cảnh: viết mã là cách học đắt, nhưng thường được làm sớm nhất

Nhà sáng lập hay chọn việc nằm trong tầm kiểm soát. Một bài trên Startups.com giải thích rằng thiết kế và viết mã là việc cắm đầu làm, không phụ thuộc ai, còn hỏi khách thì ngượng và mất thời gian, nên nhiều người coi ra mắt sản phẩm là đích đến khi chưa có bằng chứng khách cần hay chịu trả tiền [1]. Andrew Ng, trong bài nói ngày 17/6/2025 tại YC AI Startup School, cho rằng rủi ro lớn của startup ứng dụng là làm xong mà không ai quan tâm [2].

Câu hỏi của bài hẹp hơn: trước khi viết mã, hành động rẻ nào cho bằng chứng về việc khách làm gì, không chỉ nói gì? Phỏng vấn cho lời nói; thí nghiệm cho hành vi đếm được. Bài tách bằng chứng nghiên cứu khỏi lời khuyên của người làm nghề.

Khái niệm và khung phân tích: sáu công cụ trên hai thang

Thí nghiệm rẻ, theo nghĩa của bài, là hành động ngắn, có giới hạn, dựng từ công cụ sẵn có để xem một nhóm khách cụ thể có làm một việc cụ thể hay không. Logic nền nằm trong mô tả công khai ghi chú Harvard Business School của Eisenmann, Ries và Dillard: biến tầm nhìn thành giả thuyết có thể bị bác bỏ, kiểm bằng chuỗi MVP (minimum viable product, tức sản phẩm khả dụng tối thiểu), rồi chọn kiên trì, xoay hướng hoặc bỏ [3]. Sáu công cụ rẻ nhất, theo tên gọi thông dụng, như sau.

• Trang đích (landing page) kiểm tra khói (smoke test): trang mô tả sản phẩm chưa có, đo số người để lại email hoặc đặt trước [4].
• Video giải thích: bản trình diễn ngắn luồng sử dụng dự kiến, ghi rõ phần đã hoạt động và phần chỉ mô phỏng.
• Concierge: nhà sáng lập tự tay làm dịch vụ cho vài khách đầu, và khách biết đó là việc thủ công [5].
• Wizard of Oz: giao diện nhận yêu cầu của khách trong khi một phần xử lý phía sau vẫn do người làm; phạm vi hỗ trợ phải được thông báo phù hợp.
• Bán trước và đặt cọc: nhận tiền hoặc cam kết ràng buộc khi sản phẩm chưa tồn tại [6].
• Nguyên mẫu giấy hoặc bản dựng bấm được: theo Startups.com, phản hồi của khách trên nguyên mẫu là bằng chứng, tự dựng nguyên mẫu thì chưa [1].

Hai thang giúp chọn công cụ. Thang chi phí cho bạn gồm giờ công, tiền và nghĩa vụ phát sinh; thang cam kết của khách đi từ xem, để lại liên lạc, dành thời gian, trả tiền đến quay lại dùng lần nữa. Thí nghiệm tốt nằm ở góc ít tốn cho bạn mà đòi khách cam kết cao; Hình 1 đặt sáu công cụ lên hai thang theo đánh giá của bài, không phải số đo.

Ranh giới với MVP không rõ trong các nguồn: ghi chú của Harvard gọi MVP là tập nhỏ nhất các tính năng hoặc hoạt động đủ kiểm chứng một khái niệm [3], còn YC coi trang đích kèm bảng tính cũng là MVP rất tinh gọn [7]. Bài dùng chữ thí nghiệm cho thứ bỏ được sau khi trả lời có nên xây không, và chữ MVP cho bản đầu dùng thật, trả lời cái đã xây có giải quyết được vấn đề không.

Trang đích và video: đo sự quan tâm, chưa đo nhu cầu

Eric Ries dùng video Dropbox làm ví dụ về việc bắt đầu học trước khi hoàn thiện sản phẩm [8]. Với cách thử này, bài đề xuất quay đúng một việc khách muốn hoàn thành, dừng tại thời điểm phải chọn một hành động thật. Một cảnh đẹp khiến người xem hiểu sản phẩm khác với việc họ dành thời gian để thử nó.

Đừng dựng cảnh chưa làm được rồi để khách tưởng sản phẩm đã sẵn sàng. Ghi rõ đó là bản minh hoạ, phân biệt đăng ký nhận tin với đặt lịch thử. Đội cần giữ cùng lời hứa từ video sang trang tiếp theo; nếu đổi lợi ích hoặc điều kiện giữa chừng, số người chuyển bước không còn kiểm tra cùng một giả thuyết.

Bài hướng dẫn công cụ trên Startups.com mô tả quy trình: dựng trang từ mẫu trong vài phút, chỉnh câu chữ và lời kêu gọi đến khi thấy chuyển đổi, rồi gắn trang thanh toán để xem khách có trả tiền [4]. Bài ghi ngày 2023 nhưng có thể là bài cũ đăng lại, nên chỉ lấy ý tưởng, không lấy tên công cụ.

Concierge và Wizard of Oz: tự làm thay phần mềm

Khi giá trị nằm ở kết quả khách nhận chứ không ở phần mềm, cách rẻ nhất là làm kết quả đó bằng tay. Paul Graham, trong bài viết năm 2013 trên thư viện YC, mô tả hai biến thể: dùng sản phẩm thay khách, như Viaweb tự dựng cửa hàng trực tuyến cho thương nhân ngần ngại, và đóng vai phần mềm, như Stripe lúc đầu tự tay đăng ký tài khoản thương mại truyền thống ở phía sau để khách có tài khoản tức thì [6].

DoorDash gắn thí nghiệm với ba câu hỏi cụ thể. Theo Tony Xu kể với Garry Tan năm 2025, ở giai đoạn đầu nhóm dựng trong chưa đầy một giờ một trang tĩnh có tám thực đơn PDF và một số điện thoại ảo đổ chuông vào máy của bốn nhà sáng lập; ai nhấc máy trước nhận đơn và tự đi giao. Cần biết khách có trả tiền không, nhà hàng có cần không, tài xế có muốn làm không; tín hiệu được coi trọng là khách quay lại mà không cần quảng cáo hay phiếu giảm giá [5].

Để thấy khác biệt, xét một dịch vụ phân loại hóa đơn do bài tự đặt ra. Concierge là người sáng lập nhận tệp và trả bảng đã xử lý; khách biết mình đang được hỗ trợ trực tiếp. Với Wizard of Oz, khách tải tệp vào giao diện nhưng người hỗ trợ vẫn kiểm tra phía sau. Nhóm cần nói rõ ai có thể thấy tài liệu và không tuyên bố tự động hoàn toàn. Hai cách đều đo kết quả khách nhận được, nhưng chưa đo độ chính xác khi bỏ người hỗ trợ.

Giới hạn lớn nhất của cả hai là năng lực. Tony Xu kể rằng trong trận bóng bầu dục đầu tiên của Stanford năm 2013, lượng đơn vượt xa số tài xế, mọi chuyến giao trễ ít nhất một giờ, và hoàn tiền sẽ ngốn khoảng 40% số dư tài khoản, nhưng nhóm vẫn hoàn tiền toàn bộ [5]. Theo cách áp dụng của bài, cần đặt trần đơn, dừng nhận khi quá tải và dự trù tiền hoàn.

Bán trước và đặt cọc: bằng chứng đắt giá nhất, nghĩa vụ nặng nhất

Bán trước là thí nghiệm có cam kết cao nhất vì khách đưa tiền thay vì lời khen. Wil Schroter viết trên Startups.com rằng người mua trả tiền là chuyên gia quan trọng nhất, vì nói sẽ dùng thứ miễn phí thì dễ [9]. Với phần cứng, bán trước còn gỡ thế kẹt: nhà máy thường đòi đơn tối thiểu vài trăm nghìn đô la, nên không có sản phẩm thì khó có tiền làm sản phẩm [6].

Paul Graham nhận định rằng nhóm Pebble tự lắp vài trăm chiếc đồng hồ đầu tiên, và nếu không qua giai đoạn ấy thì có lẽ đã không bán được khoảng 10 triệu đô la đồng hồ khi lên Kickstarter [6]. Dù bán trước giúp kiểm mức cam kết, nhóm vẫn phải nghĩ tới giao hàng. Trên trang nghiên cứu Wharton, Ethan Mollick cho biết hơn 75% dự án trong nghiên cứu gọi vốn cộng đồng giao muộn [10]. Đây là bối cảnh nền tảng và thời kỳ nghiên cứu, không phải tỷ lệ dự báo cho mọi chiến dịch hiện nay.

Từ đó suy ra cách thiết kế: bán cho nhóm nhỏ, ghi ngày giao có biên độ, nêu rõ điều kiện hoàn tiền, chỉ bán số lượng chắc chắn phục vụ nổi. Khoản hoàn lại được cho biết khách nghiêm túc đến đâu; khoản không hoàn lại cho tín hiệu mạnh hơn nhưng tăng nghĩa vụ. Cách gọi tên khoản tiền còn kéo theo hệ quả pháp lý tại Việt Nam (xem phần Việt Nam).

Chỉ số quyết định phải viết trước khi chạy

Một thí nghiệm không có ngưỡng chỉ là cuộc thăm dò, vì kết quả nào cũng đọc được thành tin tốt. Ghi chú của Harvard nhấn mạnh giả thuyết phải bác bỏ được và phản hồi phải dẫn đến một trong ba lựa chọn: kiên trì, xoay hướng, bỏ [3]. Vì vậy giả thuyết nên có đủ bốn thứ: người, hành động, con số và thời hạn.

Ví dụ giả định để minh hoạ: trong bảy ngày, ít nhất 6 trong 30 chủ quán nhỏ nhận được lời mời sẽ đặt lịch gọi, và ít nhất 2 người trong số đó trả trước một khoản nhỏ; mẫu số là người đã thấy lời mời. Tín hiệu mạnh nhất thường là hành vi lặp lại: DoorDash theo dõi khách quay lại khi không khuyến mãi [5], và Michael Seibel gợi ý hỏi xem với vấn đề xảy ra hằng ngày người dùng có trở lại hôm sau không [7].

Bằng chứng nghiên cứu ủng hộ kỷ luật này ở mức vừa phải. Camuffo và cộng sự chia ngẫu nhiên 116 startup Ý thành hai nhóm cùng nhận mười buổi tập huấn; nhóm được dạy kiểm giả thuyết chặt như nhà khoa học đạt kết quả tốt hơn và xoay sang ý tưởng khác nhiều hơn, còn tỉ lệ bỏ cuộc sớm không thấp hơn [11]. Koning, Hasan và Chatterji, dùng dữ liệu quan sát, thấy công ty dùng A/B testing có hiệu quả tốt hơn ở lượt xem trang và tính năng mới, còn startup trẻ thất bại nhanh hơn [12]. Vậy ngưỡng quyết định cũng giúp dừng sớm.

Mẫu nhỏ khiến một kết quả bằng không khó diễn giải. NIST trình bày khoảng tin cậy nhị thức chính xác và cách chuyển sang giới hạn một phía [13]. Bài tự tính: nếu 20 quan sát độc lập, cùng xác suất, không có đăng ký nào, giới hạn trên một phía ở mức tin cậy 95% là khoảng 14%; với 60 quan sát thì còn gần 4,9%. Không được dùng phép tính này để chữa mẫu lệch do quảng cáo hay người quen.

Năm cách một thí nghiệm rẻ cho kết quả giả, và giới hạn của bằng chứng

Thí nghiệm rẻ sai theo những kiểu khá đều, và năm kiểu dưới đây đáng kiểm trước khi tin một kết quả tốt hoặc xấu: hai kiểu đầu liên quan đến số liệu, hai kiểu giữa đến cách làm, kiểu cuối đến chính khung lập luận.

• Sai người xem. Lưu lượng mua từ quảng cáo rộng hay kéo từ bạn bè đem lại lượt đăng ký của người không có vấn đề bạn nhắm tới (suy luận của bài); cần ghi rõ người xem đến từ kênh nào và loại những lượt truy cập không thuộc nhóm mục tiêu.
• Mẫu quá nhỏ. Startups.com nhắc rằng một phản hồi chỉ là một phản hồi và mẫu lớn chỉ thu hẹp sai số chứ không làm kết luận đúng hơn [9].
• Cam kết quá rẻ. Email, lời khen và lượt thích nằm ở bậc thấp của thang; Seibel khuyên hỏi về vấn đề, tần suất, độ nghiêm trọng và việc có trả tiền thay vì hỏi về tính năng [7].
• Người làm thành một phần sản phẩm. Khi bạn tự phục vụ, sự tận tâm của bạn có thể là thứ khách mua, và bản tự động sẽ không có nó (suy luận của bài).
• Chỉ thử điều dễ đo. Một lời hứa quen thuộc thường dễ được hiểu hơn giải pháp cần thay đổi quy trình; bài đề xuất ghi cả phần giá trị mà phép thử chưa thể hiện thay vì coi lượt nhấp là phán quyết cho toàn bộ ý tưởng.

Bằng chứng nghiên cứu chưa bao phủ mọi loại sản phẩm. Kết quả Camuffo chỉ ra lợi ích của cách kiểm giả thuyết có kỷ luật [11], còn dữ liệu A/B tập trung vào sản phẩm số [12]. Suy luận của bài: phép thử rẻ hữu ích khi nó chạm đúng bất định, và yếu khi chỉ chọn câu hỏi dễ trả lời. Với công nghệ dài hạn, cần phối hợp nghiên cứu kỹ thuật, khách hàng và điều kiện đưa vào vận hành.

Góc nhìn AI: dựng nhanh hơn, xác thực chưa chắc nhanh hơn

AI làm rẻ phần dựng, nhất là nguyên mẫu bỏ đi. Andrew Ng nêu kinh nghiệm dựng nguyên mẫu nhanh hơn nhờ trợ lý lập trình tại AI Startup School ngày 17/6/2025 [2]. Bài không dùng kinh nghiệm đó làm hệ số tiết kiệm chung: tốc độ phụ thuộc phần việc, mã sẵn có và yêu cầu kiểm tra. Theo AI Index 2026 (Stanford HAI), trong một năm điểm trên bài đo lập trình SWE-bench Verified đã đi từ 60% lên gần 100% [14].

Điều AI không đổi là chỗ thắt. Cũng theo Ng, khi kỹ thuật nhanh lên, việc lấy phản hồi người dùng và quyết định làm gì trở thành nút thắt [2]. Tìm đúng khách và nhận cam kết thật vẫn tốn thời gian và tiền như trước. Nếu dùng tác tử AI làm phù thủy phía sau, AI Index nêu tác tử còn thất bại khoảng một phần ba lượt trên bài đo thao tác máy tính OSWorld [14]. Đó không phải tỷ lệ lỗi chăm sóc khách hàng; nhóm phải tự đo tác vụ mình định giao cho máy và giữ phương án người tiếp quản.

Rủi ro chính là nhầm tốc độ với xác thực. Thử nghiệm ngẫu nhiên METR (tháng 7/2025) giao 246 tác vụ cho 16 lập trình viên giàu kinh nghiệm của các dự án mã nguồn mở; họ dự báo AI rút ngắn thời gian 24% và sau đó tự ước tính 20%, nhưng đo thực tế thời gian tăng 19% [15]. Đó là dự án trưởng thành, không phải nguyên mẫu; bài học chỉ là cảm giác nhanh không phải số đo. YC ghi nhận năm 2026 rằng trang dựng bằng AI giống nhau đến mức vẻ đẹp không còn là tín hiệu [16].

Quy tắc dùng AI cho thí nghiệm: để AI tạo nhiều bản câu chữ và nguyên mẫu, nhưng khoá chỉ số và ngưỡng trước khi xem kết quả; không dùng AI thay lời khách thật; ghi rõ khi bản trình diễn do AI dựng.

Việt Nam: nguyên mẫu từ dịch vụ sẵn có và giới hạn khi nhận tiền

Một cách giảm chi phí nguyên mẫu tại Việt Nam là tận dụng dịch vụ sẵn có. Trang dùng thử của FPT.AI công bố Voicemaker tạo giọng đọc tiếng Việt và gói ký tự miễn phí ban đầu [17]. Đây là mô tả của nhà cung cấp được đọc ngày 24/10/2026; bài không mở tài khoản hay đo chất lượng. Nó chỉ cho thấy có thể thử một luồng giá trị mà chưa phải tự xây công nghệ giọng nói.

Trong tình huống do bài xây dựng, nhóm làm công cụ đọc hướng dẫn cho cửa hàng nhỏ có thể tạo vài bản mẫu và yêu cầu khách chọn dùng trong một ca làm việc. Cần ghi khách dùng lại bao nhiêu lần và có thay thế cách cũ không. Kết quả của nhà cung cấp công nghệ không chứng minh cửa hàng muốn trả tiền cho dịch vụ đóng gói của nhóm.

Cổng Chính phủ công bố Bộ luật Dân sự số 91/2015/QH13, kèm văn bản gốc và mốc hiệu lực ban đầu [18]. Lượt sửa này mới kiểm được trang thuộc tính, chưa đọc được Điều 328 trong bản gốc, nên bài không kết luận một khoản thu cụ thể có phải đặt cọc hay không. Trước khi nhận tiền thật, cần làm rõ nghĩa vụ giao, hoàn tiền và điều kiện áp dụng với người có chuyên môn; đổi tên khoản thu không tự giải quyết được nghĩa vụ.

Kế hoạch thử nghiệm: mười ngày, ba bậc cam kết, hai cổng dừng

Kế hoạch này nối tiếp ví dụ giả định ở phần trước: 30 chủ quán nhỏ và một công cụ giữ lịch hẹn chưa tồn tại. Ngày 1 chỉ để viết giả thuyết, ba ngưỡng, trần giờ công và trần tiền hoàn. Từ đó kế hoạch leo từng bậc cam kết thay vì chia theo tuần: mỗi bậc có trần riêng, và chỉ leo tiếp khi bậc dưới đạt ngưỡng viết sẵn. Các con số chỉ minh hoạ.

• Ngày 2 đến 3, bậc một: dựng trang một lời hứa hoặc soạn tin nhắn riêng, gửi 30 người đúng nhóm và ghi nguồn từng người. Trần: một ngày dựng, không quảng cáo.
• Ngày 4, cổng một: từ 6 người đặt lịch gọi thì đi tiếp, dưới 3 thì dừng, ở giữa thì gọi hỏi lý do, đổi lời hứa và chạy lại đúng một lần.
• Ngày 5 đến 8, bậc hai: làm tay đúng việc phần mềm sẽ làm cho nhiều nhất 3 quán, ghi quán nào quay lại dùng hôm sau. Trần: hai giờ mỗi quán mỗi ngày.
• Ngày 9, bậc ba: đề nghị các quán đã dùng trả trước một khoản nhỏ, ghi rõ điều kiện hoàn tiền và ngày giao có biên độ. Trần: tối đa 3 đơn, tổng tiền hoàn viết ra trước.
• Ngày 10, cổng hai: đọc kết quả cùng người ngoài, ghi nhật ký một trang gồm giả thuyết, số thật, điều bất ngờ, quyết định. Từ 2 quán trả trước thì đi tiếp bằng bản nhỏ nhất.

Khác với kế hoạch theo lịch tuần, đơn vị ở đây là bậc cam kết: nếu cổng một không đạt, sáu ngày còn lại không dùng, và đó là kết quả tốt vì tiết kiệm công. Đầu ra duy nhất là nhật ký quyết định, không phải một bản dựng. Với 30 người được mời, ngưỡng chỉ chặn được quyết định tệ rõ rệt chứ không chứng minh nhu cầu (Hình 2).

Kết luận

Thí nghiệm rẻ không thay việc xây sản phẩm; nó quyết định có đáng xây không và xây gì trước. Bằng chứng nghiên cứu trong bài chỉ ở mức vừa phải: một thử nghiệm ngẫu nhiên nhỏ, một nghiên cứu quan sát, còn lại phần lớn là lời khuyên của người làm nghề. Điều đáng giữ là thứ tự: viết ngưỡng trước, leo từng bậc cam kết, đặt trần rủi ro, coi kết quả đẹp từ mẫu nhỏ là tín hiệu thô. AI hạ giá phần dựng, nên việc còn lại là tìm đúng người và nhận cam kết thật.

Nguồn và phương pháp

Bài có hỗ trợ AI trong tổng hợp, biên tập và kiểm định dạng; phần phân tích được viết bằng lời riêng, không phải bản dịch. Bản nháp ngày 23/10 được đối chiếu lại ngày 24/10/2026 qua nguồn công khai YC, Startups.com, kho trường đại học, NIST, Stanford, METR, FPT.AI và Cổng Chính phủ. Ghi chú HBS và các nghiên cứu Camuffo/NBER chỉ dùng phần mô tả, tóm tắt; kết quả Mollick lấy trang Wharton do tác giả giới thiệu.

Lượt sửa không mở lại được bài SSRN của Mollick, bài MIT về lean startup và trang Selling Power nên không giữ khẳng định dựa riêng vào chúng. Trang PubMed không có tóm tắt được thay bằng hướng dẫn NIST. Phép tính nhị thức là minh hoạ của bài với giả thiết nêu rõ. Điều chưa kiểm chứng là toàn bộ pháp luật áp dụng cho bán trước. Nguồn thực hành và thông tin nhà cung cấp không thay bằng chứng thử nghiệm với khách hàng mục tiêu. Hãy đọc bản gốc trước khi dùng.