Build MVP thế nào khi AI viết code

1. Lời khuyên cũ về MVP cần được cập nhật

Đây là một tập của Dalton + Michael, chương trình trò chuyện giữa Dalton Caldwell và Michael Seibel (tên hai người theo phần mô tả của video đăng ngày 18/05/2026). Theo phần mô tả đó, hai người xem lại lời khuyên kinh điển về việc build một MVP và cập nhật nó cho thời của AI coding: khi build feature bằng Claude Code hay Codex đã dễ, rất dễ làm ra một thứ có cả đống feature, cồng kềnh và không phải thứ người ta muốn.

Trước lời chào, Michael nói (video đăng ngày 18/05/2026): dù tốt hay xấu, vấn đề nhất quán xưa nay vẫn là làm sao giúp khách hàng của bạn thành công hơn. Nếu 5 năm trước có ai hỏi anh rằng giá của việc build feature đã giảm xuống, chẳng phải điều đó rõ ràng là tốt sao, thì anh nghĩ có lẽ anh đã trả lời là có. Và anh nghĩ TLDR của video này là... rồi câu được chốt bằng chữ "unclear", không rõ ràng.

Lời chào mở đầu: đây là Dalton + Michael, và hôm nay hai người nói về cách build một MVP trong thời đại AI. Rồi Michael nói (video đăng ngày 18/05/2026): đây là một chủ đề thú vị, vì anh thật sự nghĩ hai người phải không đồng ý với chính lời khuyên trước đây của mình. Có tiếng nói thêm: hoặc là giờ có một bộ ràng buộc khác.

Michael giải thích (video đăng ngày 18/05/2026): trước đây bạn phải tìm ra đâu là tập feature nhỏ nhất cần build mà vẫn tạo ra giá trị, vì build feature thì tốn kém. Có tiếng nói tiếp: giờ có lẽ đã ở một tình huống khác; chúng ta đang ở trong môi trường nào?

Một người trong hai đồng ý (video đăng ngày 18/05/2026): điều đó hoàn toàn đúng. Đã có rất nhiều điều được nói về cách build một MVP và có được những khách hàng đầu tiên; hai người cũng đã nói về nó, và ngoài kia có nhiều nội dung hay. Nhưng lời khuyên đó cần được cập nhật cho các công cụ AI.

2. Xoá bớt feature trước khi launch

Dalton nói anh có thể kể từ chính trải nghiệm của mình một chút, vì anh vừa build và launch một sản phẩm. Anh nói sẽ không đi vào chi tiết của nó, nhưng anh đã thật sự trải qua chuyện này: anh vừa build và launch một sản phẩm (video đăng ngày 18/05/2026).

Rồi anh bắt đầu với điều khác biệt. Điều số một, theo Dalton (video đăng ngày 18/05/2026): build feature giờ dễ đến mức để launch được sản phẩm đó, anh đã phải xoá 80% số feature mà anh build trong MVP. Một người trong hai nói thêm: đó không phải vấn đề cũ, đó là một vấn đề rất mới.

Dalton kể (video đăng ngày 18/05/2026): anh đã build một thứ khổng lồ điên rồ cùng co-founder của mình trong hai tuần. Rồi anh nhìn lại và nghĩ: ồ, cái này dở, cái này giống một đống rác. Và thế là anh phải... Anh bỏ lửng câu nói ở đó.

Theo Dalton (video đăng ngày 18/05/2026), cảm giác đó rất khác so với chuyện đơn giản là cố build một sản phẩm như trước: trước đây, chính cái khó của việc build đã ngăn bạn rơi vào feature creep. Michael nói thêm: hoặc feature creep đó sẽ mất hàng tháng. Dalton đồng ý.

Michael nói tiếp (video đăng ngày 18/05/2026): còn Dalton thì về cơ bản đã bị feature creep trong hai tuần. Dalton nhắc lại: anh bị feature creep trong hai tuần.

3. Phải làm một người biên tập

Dalton nói tiếp (video đăng ngày 18/05/2026): vì thế bạn thấy người ta cứ vibe coding ra toàn rác. Michael đồng ý. Theo Dalton, đó là vì quá dễ để cứ thêm, thêm và thêm mãi. Nên anh nghĩ bạn gần như phải làm một người biên tập (editor) nhiều hơn so với trước đây.

Michael gọi đó là một ý lớn. Anh lập luận thêm (video đăng ngày 18/05/2026): điều này còn khiến mọi thứ khó hơn nhiều khi bạn build sản phẩm cho người khác. Vì khi build sản phẩm cho chính mình, ít ra bạn có thể dùng nó suốt quá trình làm MVP và xem mình có nhận được giá trị không.

Còn khi build sản phẩm cho người khác và bạn có thể build vô số feature, theo Michael (video đăng ngày 18/05/2026), đầu óc bạn sẽ kiểu: chà, họ sẽ muốn feature này, họ sẽ muốn feature kia. Sao mình lại tới gặp họ với một thứ không có đủ mọi feature họ sẽ muốn? Sao không đưa cho họ mọi feature họ muốn ngay từ đầu?

4. Viết feature thì gây nghiện

Dalton nói thêm (video đăng ngày 18/05/2026): và nó gây nghiện. Viết feature thì vui. Anh nói rõ điều anh đang lập luận: lúc này, cám dỗ không nói chuyện với user, và không launch với một thứ nhỏ, lớn hơn bao giờ hết. Michael đồng ý.

Michael muốn mở rộng ý đó (video đăng ngày 18/05/2026). Khi bạn nói chuyện với user và họ đưa cho bạn một danh sách dài dằng dặc các feature, trước đây bạn biết mình không thể build hết chừng đó, hay ít ra những người thông minh thì biết. Nên bản năng của bạn sẽ là: để mình đào sâu hơn, để mình tìm hiểu xem họ thật sự cần gì, chuyện gì thật sự đang diễn ra.

Dalton chen vào (video đăng ngày 18/05/2026): giờ thì theo đúng nghĩa đen là có thể đưa luôn những thứ đó. Rồi anh đưa ra một ví dụ cực đoan: bạn có thể ghi chú lại cuộc nói chuyện của mình với một user, đưa những ghi chú đó cho Codex, và Codex sẽ build mọi feature mà user đó yêu cầu. Theo Dalton, làm vậy là rất tệ. Đừng làm thế.

5. Bạn chính là cái hố hắc ín

Michael gọi đó là điểm phản trực giác (video đăng ngày 18/05/2026): chuyện muốn build mọi feature mà user đòi thì xưa nay vẫn có, nhưng giờ nó tăng theo cấp số nhân, vì bạn làm được. Bạn thật sự có thể làm điều đó. Và theo anh, điều đó thật sự, thật sự, thật sự tệ.

Theo Michael (video đăng ngày 18/05/2026), hệ quả không may là việc bạn tự hiểu về vấn đề giờ quan trọng hơn rất nhiều. Vì nếu bạn không hiểu vấn đề, user cứ nói với bạn về feature, họ đang hào hứng, còn bạn thì chẳng biết chuyện quái gì đang diễn ra, bạn có thể tự đưa mình vào... về cơ bản bạn đã tạo ra một cái hố hắc ín (tar pit) ở nơi mà có lẽ trước đó chưa từng có. Chính bạn là cái hố hắc ín.

Dalton nói lại (video đăng ngày 18/05/2026) rằng anh đã trải qua chuyện này, anh cảm nhận nó rất rõ trong người: quá dễ để cứ thế cho ra hết thứ này tới thứ khác. Nên lời khuyên của anh cho founder là: bạn phải cố gắng hơn bao giờ hết để cưỡng lại cám dỗ build những sản phẩm siêu phức tạp, có bề mặt (surface area) rộng.

Tất nhiên, theo Dalton (video đăng ngày 18/05/2026), bạn nên thêm feature cho sản phẩm. Nhưng anh nghĩ đó phải là vì user đang kéo bạn về phía build thêm, chứ không phải vì Codex có thể cho ra feature đó.

6. Spam không phải là nói chuyện với user

Michael chuyển sang phần user (video đăng ngày 18/05/2026): được rồi, build sản phẩm thì dễ hơn. Anh nói anh đang định nói "không tin nổi là mình đang nói điều này", nhưng tất nhiên là anh tin được. Có tiếng nói tiếp: spam cũng dễ hơn. Spam thì lúc nào cũng ngày càng dễ hơn, lịch sử là vậy.

Dalton nhắc lại lời khuyên cũ (video đăng ngày 18/05/2026): hãy có một trăm người yêu sản phẩm của bạn; hãy nói chuyện với càng nhiều user càng tốt. Theo anh, tất cả vẫn đúng, hai người không nói điều đó là sai. Vấn đề nằm ở chỗ khác.

Theo Dalton (video đăng ngày 18/05/2026), giờ dễ hơn bao giờ hết để bảo "claw" của bạn spam người ta, hoặc tự đi mua một đống lead trên mạng rồi spam. Nên với nhiều founder, phiên bản "nói chuyện với user" của họ là spam, và nó dễ, còn các con số thì lớn.

Và đây là điều phản trực giác, theo Dalton (video đăng ngày 18/05/2026): đừng làm thế. Đó là nhiễu. Một số ít cuộc trò chuyện chất lượng cao, nơi bạn thật sự lắng nghe, tốt hơn nhiều so với spam một nghìn người.

7. Khách hàng cũng không có sẵn playbook

Michael muốn đi sâu thêm một bước (video đăng ngày 18/05/2026). Nếu startup đơn giản chỉ là nói chuyện với user rồi build thứ họ muốn, thì sẽ có nhiều startup thành công hơn rất nhiều.

Theo Michael (video đăng ngày 18/05/2026), về căn bản bạn phải giả định rằng phần lớn user của bạn muốn công việc kinh doanh hay dự án của mình thành công, nhưng không biết chính xác phải làm thế nào. Vì vậy một phần căn bản trong việc bạn làm khó hơn gấp mười lần, vì bạn đang cố tìm cách giúp việc kinh doanh của khách hàng tốt lên, trong khi chính khách hàng cũng không có sẵn một playbook hoàn hảo cho việc đó.

Michael kết luận ý này (video đăng ngày 18/05/2026): khi nói chuyện gần gũi, sâu hơn với một số ít khách hàng, khả năng bạn thật sự tạo ra tác động lên việc kinh doanh của họ tăng lên rất nhiều. Và điều đó làm quay một bánh đà (flywheel) không phải là spam, mà là truyền miệng.

8. Mười hai cuộc gọi Zoom: ít feature hơn, nhiều người dùng hơn

Dalton kể ví dụ thật của anh với sản phẩm vừa launch (video đăng ngày 18/05/2026). Anh và co-founder đã build một đống thứ, rồi anh đặt 12 cuộc gọi Zoom với những founder anh quen, những người có thể là user của nó. Anh và co-founder cùng vào các cuộc gọi đó và chỉ đơn giản là hỏi.

Theo Dalton (video đăng ngày 18/05/2026), nhiều người trong số đó không thực sự hiểu nó là gì, vì nó quá phức tạp. Anh thử giải thích nó là gì, rồi kiểu như: ồ, không biết nữa. Nhưng khi anh cắt bỏ 80% chức năng, họ kiểu: được, tôi đăng ký ngay bây giờ. Có người còn đăng ký ngay trong cuộc gọi. Có tiếng đáp: đấy thấy chưa.

Dalton nói đó là điều phản trực giác (video đăng ngày 18/05/2026): ít feature hơn, dùng nhiều hơn. Lạ không? Theo anh, đó là vì những người dùng đó bị choáng ngợp bởi quá nhiều phức tạp. Anh có một tầm nhìn rộng lớn về những gì sản phẩm có thể trở thành, nhưng user không quan tâm tới điều đó. Họ chỉ muốn biết nó giải quyết những vấn đề ngắn hạn của họ thế nào. Michael đồng tình.

9. Phép ẩn dụ GarageBand

Michael nói (video đăng ngày 18/05/2026): dù tốt hay xấu, vấn đề nhất quán xưa nay vẫn là làm sao giúp khách hàng của bạn thành công hơn. Nếu 5 năm trước có ai hỏi anh rằng giá của việc build feature đã giảm, chẳng phải điều đó rõ ràng là tốt sao, thì anh nghĩ có lẽ anh đã trả lời là có. Và anh nghĩ TLDR của video này là... rồi câu được chốt bằng chữ "unclear", không rõ ràng.

Dalton nói anh nghĩ về chuyện này rất nhiều, và anh kể lại cho Michael. Anh bảo hãy nghĩ xem hồi thập niên 60, để làm ra một đĩa thu âm khó tới mức nào (video đăng ngày 18/05/2026): bạn cần một hợp đồng với hãng đĩa, phải trả tiền thuê phòng thu, cần nhạc cụ, kiểu như là siêu đắt đỏ. Anh hỏi: hồi thập niên 60 có bao nhiêu người làm ra được một bản thu đạt chất lượng phát trên radio? Có tiếng đáp: vài nghìn?

Còn bây giờ, theo Dalton (video đăng ngày 18/05/2026), bạn mua một chiếc Mac và nó đi kèm GarageBand. Và nhiều bản hit số một, bạn có thể tự tìm hiểu, đã được làm trong GarageBand. Vậy là bạn đang dùng cùng công cụ mà những người giỏi nhất thế giới đang dùng.

Dalton hỏi tiếp (video đăng ngày 18/05/2026): vậy nhu cầu nghe nhạc bây giờ nhiều hơn thập niên 60 bao nhiêu? Anh trả lời: đi ngang. Một ngày người ta nghe nhạc được bao nhiêu giờ? Michael nói thêm: người ta không sống quá 24 giờ một ngày. Dalton hỏi: có bao nhiêu người thức dậy mỗi sáng mà nghĩ "trời, mình thật sự muốn nghe vài bài hát do một anh chàng nào đó ở Illinois viết"? Michael thêm: một người chưa ai từng nghe tên. Dalton nhắc lại: chưa ai từng nghe tên. Không ai muốn thứ đó cả.

Theo Dalton (video đăng ngày 18/05/2026), đó là phép ẩn dụ của anh cho rất nhiều thứ vibe coding: trong tay đúng người thì nó tuyệt vời. Nó là một việc để làm cho vui. Anh thích làm bài hát bằng GarageBand, và anh sẽ không phát hành chúng, xin lỗi mọi người. Làm nhạc thì vui.

Nhưng Dalton nói anh không hề ảo tưởng (video đăng ngày 18/05/2026) rằng mấy thứ rác anh làm trong GarageBand sẽ thành bản hit số một. Có tiếng chen vào: rồi nó sẽ đưa anh đi lưu diễn. Dalton đáp anh không nghĩ vậy. Có tiếng nói: chẳng có nhu cầu cho nó. Dalton nói thêm: anh không có tài. Michael đồng ý.

10. Số người thắng không tăng, nhưng nhân viên thì được tiếp sức

Lý thuyết của Dalton (video đăng ngày 18/05/2026): việc dân chủ hoá những công cụ này là tuyệt vời, nó sẽ giúp nhiều người trẻ hơn được phát hiện và bước chân vào ngành, hoan hô. Nhưng tổng số... Michael điền vào: người thắng. Dalton nói tiếp: số người thắng thì không hiển nhiên là sẽ tăng lên. Michael đồng ý.

Michael nói điều buồn cười là khi bạn build công cụ cho chính mình (video đăng ngày 18/05/2026), anh sẽ lập luận rằng một nhân viên bên trong một công ty giờ được tiếp sức mạnh hơn rất nhiều nhờ những công cụ này, khi họ có một việc rõ ràng phải làm và biết cách làm. Giờ họ không phải lấy bớt nguồn lực của công ty nữa. Theo Michael, có lẽ họ nhận được hiệu ứng nhân (multiplier effect) cao hơn nhiều so với một startup.

Dalton đồng ý (video đăng ngày 18/05/2026): hãy nghĩ xem có bao nhiêu người được thuê để làm video cho mục đích đào tạo nội bộ hay mục đích gì đó, so với số người làm phim bom tấn Hollywood, hay có bao nhiêu đạo diễn. Nên có lẽ có rất, rất nhiều người dùng những công cụ này để hoàn thành công việc của mình, mà không phải đang tạo ra một Facebook tiếp theo. Michael đồng ý.

11. Build in public và chuyện nội dung rác

Michael tóm lại (video đăng ngày 18/05/2026): TLDR, build MVP trong thế giới AI thì khác. Về feature, anh luôn nghĩ feature là xấu, nhưng giờ feature lại rẻ. Đáng sợ. Bạn phải biết kén chọn.

Dalton thêm một điều nữa (video đăng ngày 18/05/2026): rất nhiều lời khuyên của hai người xưa nay là build in public, đăng nhiều về những gì bạn đang làm. Vấn đề là các "claw" khiến việc tạo ra rác trên LinkedIn và X về thứ bạn đang build dễ đến vậy, và tất cả đều giống nhau. Ngược lại, nếu bạn bỏ thời gian viết những thứ thật sự độc đáo, bạn có thể xây được một lượng người theo dõi.

Dalton kể (video đăng ngày 18/05/2026) anh thấy rất nhiều founder chỉ tung ra nội dung rác (slop), trái ngược với một người mà anh nhắc tên, người lúc nào cũng viết về file system. Người đó đang xây được lượng người theo dõi vì những bài viết về file system cực kỳ mang dấu ấn riêng.

Trớ trêu thay, theo Dalton (video đăng ngày 18/05/2026), nội dung tốt nhất để biết các lab đang làm gì lại là tài khoản Twitter của những người làm ở các lab, và chắc chắn họ không viết ra mấy thứ đó. Anh hỏi Michael có hiểu ý anh không: kiểu như họ đang làm rò rỉ "alpha".

12. Vòng phản hồi giả, và lợi thế của người biết tập trung

Michael đồng ý: đúng vậy, đó là một trò chơi kỳ lạ. Theo anh (video đăng ngày 18/05/2026), về cơ bản giờ một startup dễ trông như đang đi qua một vòng phản hồi tích cực (positive feedback loop), trong khi thật ra nó đang ngầm đi qua một vòng phản hồi tiêu cực. Spam một đống khách hàng, lấy được lượt dùng của họ, họ không thích sản phẩm, tất cả rời bỏ (churn), rồi cứ thế làm tiếp.

Nhưng theo Michael (video đăng ngày 18/05/2026), đó lại là một lợi thế theo một kiểu kỳ lạ. Nếu ngày càng nhiều đối thủ của bạn làm vậy, còn bạn thì không, bạn có thể tìm ra cách dùng những công cụ này một cách chừng mực để thật sự tạo ra giá trị cho mọi người. Có vô số lợi thế để nắm lấy, tính đến lúc ghi hình.

Một người trong hai nói tiếp (video đăng ngày 18/05/2026): gần như là những người giỏi nhất ở việc biên tập, hay tạo ra khoảng trắng (white space), và tập trung, thì đang ở vị trí rất tốt khi mọi người khác làm điều ngược lại. Đó là một cách để nổi bật giữa đám đông.

Một người trong hai đưa ra phép so sánh (video đăng ngày 18/05/2026): "chúng tôi có hai feature chạy được, thật sự làm cho việc kinh doanh hay cuộc sống của bạn tốt hơn", so với 150 feature. Lúc đầu bạn có thể bị nhầm, rõ ràng thứ có 150 feature thì tốt hơn; rồi khi bắt đầu dùng, bạn kiểu: không, cảm ơn.

Michael chào Dalton ("Cheers, Dalton"), và Dalton đáp: được rồi, cảm ơn.