# Playbook FDE cho startup AI cùng Bob McGrew

[Bob McGrew](https://homus.dev/speakers/bob-mcgrew) · [Y Combinator](https://homus.dev/orgs/y-combinator), [Jared Friedman](https://homus.dev/speakers/jared-friedman) · [Y Combinator](https://homus.dev/orgs/y-combinator), [Diana Hu](https://homus.dev/speakers/diana-hu) · [Y Combinator](https://homus.dev/orgs/y-combinator), [Harj Taggar](https://homus.dev/speakers/harj-taggar) · [Y Combinator](https://homus.dev/orgs/y-combinator)

> Bob McGrew giải thích mô hình forward deployed engineer của Palantir, cách định giá theo outcome, đo product leverage và vì sao startup AI agent áp dụng nó.

Topics: Service as Software, Startups, Agents

Canonical: https://homus.dev/talks/the-fde-playbook-for-ai-startups-with-bob-mcgrew

## 1. Mở đầu: vì sao ai cũng hỏi Bob về forward deployed engineer

Ngay đầu video, Bob McGrew nói: với AI agent thì không có sản phẩm đương nhiệm (incumbent product) nào cả, và theo anh đó là lý do mô hình FDE đang bùng lên, vì có quá nhiều product discovery phải làm. Bạn muốn đẩy quy mô hợp đồng (contract size) lên, như vậy bạn đang làm những việc ngày càng có giá trị hơn cho khách hàng này và cho cả những khách hàng tương lai. Và mô hình FDE, về bản chất, là làm những việc không scale được, nhưng làm ở quy mô lớn ("doing things that don't scale at scale") (theo Bob, video đăng ngày 08/09/2025).

![Bob McGrew nói chuyện bên bàn tròn, thẻ tên ghi Bob McGrew, Former Chief Research Officer, OpenAI](https://homus.dev/photos/Zyw-YA0k3xo-0003.jpg)

Bob McGrew trong tập Lightcone này; thẻ tên giới thiệu anh là "Former Chief Research Officer, OpenAI", Diana Hu ngồi bên trái (video đăng ngày 08/09/2025).

Đây là một tập của Lightcone, podcast của Y Combinator, đăng ngày 08/09/2025. Harj Taggar mở đầu bằng lời chào mừng trở lại với một tập mới, và nói Garry hôm nay không khỏe nên không thể có mặt. Thẻ tên trong video giới thiệu ba host còn lại: Diana Hu, General Partner, Harj Taggar và Jared Friedman, Managing Partner. Khách mời là Bob McGrew. Theo lời Harj và mô tả video đăng ngày 08/09/2025, Bob là một kỹ sư thời đầu ở PayPal, một lãnh đạo thời đầu ở Palantir, và gần đây là Chief Research Officer ở OpenAI, nơi anh dẫn dắt việc phát triển ChatGPT, GPT-4 và model suy luận o1. Harj nói thêm rằng Bob đang khám phá tương lai của AI và có một vai trò mới thú vị với Quân đội Mỹ (US Army), chuyện sẽ được nói tới sau. Bob đáp rằng anh rất vui được có mặt.

![Bốn người quanh bàn tròn trắng với thẻ tên Diana Hu, Harj Taggar và Jared Friedman](https://homus.dev/photos/Zyw-YA0k3xo-0037.jpg)

Bốn người quanh bàn tròn: từ trái sang là Diana Hu (thẻ tên "General Partner"), Bob McGrew, Harj Taggar và Jared Friedman (cả hai đều mang thẻ "Managing Partner") (video đăng ngày 08/09/2025).

Jared nói anh đặc biệt háo hức được ngồi xuống với Bob để nói về mô hình forward deployed engineer, vì đây là chủ đề cứ liên tục xuất hiện trong cuộc sống của nhóm. Theo anh, nó đang là một chủ đề rất nóng ở Silicon Valley, đặc biệt trong các công ty AI agent mà podcast đã nói tới nhiều. Bob có mặt trong phòng khi mọi thứ bắt đầu, nên theo Jared anh đúng là người để giải thích (video đăng ngày 08/09/2025).

Jared kể lại một câu chuyện vui mà Bob từng kể với anh: Bob dự một hội nghị AI do YC tổ chức vài tháng trước đó, và anh nghĩ tất cả founder sẽ tới nói chuyện với anh về việc tạo ra ChatGPT. Thay vào đó, điều mà mọi founder startup AI muốn hỏi lại là mô hình forward deployed engineer của Palantir. Bob xác nhận chuyện đó là thật, và không chỉ ở hội nghị đó: trong năm vừa qua khi anh làm cố vấn cho các startup, anh có thể nói rằng nhiều startup gần như chỉ tập trung tìm hiểu xem chiến lược FDE vận hành ra sao (theo Bob, video đăng ngày 08/09/2025).

Jared nói đây là một chủ đề người ta say mê, và nó rất đúng lúc vì theo anh nó đã trở thành cách chủ đạo mà các startup AI agent tự tổ chức. Hôm đó anh vừa xem job board của YC: có hơn 100 startup YC đang tuyển cho vị trí mang chức danh forward deployed engineer, tăng từ về cơ bản là con số không ba năm trước đó (theo Jared, video đăng ngày 08/09/2025). Trước khi đi sâu, anh nhờ Bob giải thích, cho những ai chưa biết, forward deployed engineer là gì và vì sao nó quan trọng vào lúc này.

## 2. FDE là gì, và Palantir bắt đầu từ việc làm phần mềm cho điệp viên

Bob định nghĩa: forward deployed engineer là một người, thường là người làm kỹ thuật, một kỹ sư, ngồi tại chỗ khách hàng (customer site) và lấp khoảng trống giữa những gì sản phẩm làm được và những gì khách hàng cần (theo Bob, video đăng ngày 08/09/2025).

Trong thực tế điều đó diễn ra thế nào? Theo Bob, bạn có một sản phẩm và bạn tới chỗ một khách hàng mới, bắt đầu làm việc với họ. Vấn đề họ muốn bạn giải lại không phải vấn đề bạn từng giải trước đây. Nhưng bạn tin rằng với một chút công sức, có thể là rất nhiều công sức, bạn có thể giải nó cho khách hàng cụ thể này và tạo ra tác động rất lớn cho họ, mang lại cho họ một outcome cực kỳ có giá trị. Vậy là bạn lấy sản phẩm bạn đang có, và FDE, với sự giúp sức của product team, tìm cách mang lại outcome đó: cách dựng use case đó, cách đưa phần mềm bạn đã build tới khách hàng theo một cách thật sự chạy được cho họ (theo Bob, video đăng ngày 08/09/2025).

Định nghĩa FDE theo lời Bob: một kỹ sư ngồi tại chỗ khách hàng, lấp khoảng trống giữa sản phẩm và nhu cầu (video đăng ngày 08/09/2025).

Jared đưa câu chuyện quay về điểm khởi đầu: Bob đã có mặt ở Palantir khi cả mô hình đang bùng nổ ở Silicon Valley này được tạo ra. Anh nhờ Bob kể nó bắt đầu thế nào (video đăng ngày 08/09/2025).

Bob nói cách thú vị để nghĩ về buổi đầu của Palantir là: khi anh và đồng nghiệp bắt đầu, công ty tập trung build phần mềm cho giới tình báo của chính phủ, cụ thể là phần mềm cho điệp viên. Một thách thức khi build phần mềm cho điệp viên là anh không quen điệp viên nào cả. Anh nói có lẽ người nghe cũng không quen ai ("Nope", một host đáp). Và nếu bạn có tình cờ tìm được một điệp viên và hỏi họ chính xác là họ làm gì, thường thì họ sẽ không nói cho bạn (theo Bob, video đăng ngày 08/09/2025).

Vì vậy anh và đồng nghiệp ở Palantir phải chọn một cách tiếp cận khá khác thường vào thời điểm đó. Về cơ bản, anh và đồng nghiệp bắt đầu bằng việc build một demo, rồi mang demo đó tới các khách hàng tiềm năng trong giới tình báo (theo Bob, video đăng ngày 08/09/2025).

## 3. Từ demo của Stephen Cohen đến chỗ rẽ khỏi lời khuyên product market fit

Theo Bob, Stephen Cohen, một trong những người sáng lập Palantir, nổi tiếng vì đã làm việc này. Anh ấy cho họ xem demo và hỏi: các anh nghĩ sao? Họ trả lời: cái này tệ lắm, chẳng liên quan gì tới việc chúng tôi làm cả. Anh ấy hỏi lại: vậy các anh muốn nó khác đi thế nào? Rồi họ nói: anh có thể sửa chỗ này, chỗ này không. Và anh ấy ngồi đó ghi lại tất cả (theo Bob kể, video đăng ngày 08/09/2025).

Bob nói tới đây, câu chuyện nghe rất giống lời khuyên chuẩn mà người ta cho founder ngày nay: bạn phải làm ra thứ người ta muốn, phải ra khỏi tòa nhà (get out of the building), phải đi nói chuyện với khách hàng. Anh cho rằng anh và đồng nghiệp đã làm việc này từ giữa những năm 2000, nên có một chút kiểu meme "tôi mất nhiều năm mới thành thạo kỹ thuật này, còn Paul Graham thì tweet nó ra cho mọi người" (theo Bob, video đăng ngày 08/09/2025).

Nhưng thứ thay đổi, và là thứ thật sự sinh ra chiến lược FDE, theo Bob là thế này. Điều bạn chờ đợi, điều chuẩn mực, là bạn bỏ nhiều thời gian lúc đầu làm những việc không scale: đi gặp khách hàng, ở thật gần khách hàng, rồi bạn tìm ra product market fit. Và khi đã tìm ra product market fit, theo cách kinh điển như trong Crossing the Chasm hay những cuốn sách tương tự, bạn làm một việc hoàn toàn khác. Thay vì ở sâu với khách hàng và làm mọi thứ để thật sự hiểu họ, bạn chấp nhận giữ khoảng cách với khách hàng. Tất cả những gì bạn muốn tập trung là scale: làm sao bán được nhiều hơn, làm sao đối xử với mọi khách hàng giống hệt nhau (theo Bob, video đăng ngày 08/09/2025).

Bob nói nếu bạn đang ở trong một mảng kinh doanh mà cách đó chạy tốt, thì tuyệt. Đừng làm chiến lược FDE. Bạn đã được trao một món quà tuyệt vời. Nếu bạn có cơ hội cứ thế scale, đối xử với mọi khách hàng như nhau, cứ làm vậy (theo Bob, video đăng ngày 08/09/2025).

Hai lối rẽ mà Bob mô tả: lời khuyên chuẩn sau product market fit, và lối mà Palantir phải đi vì lối chuẩn không chạy với họ (theo Bob, video đăng ngày 08/09/2025).

Nhưng cách đó không chạy với Palantir. Và theo Bob, đây là chỗ Shyam Sankar, một nhân viên rất sớm, mà theo anh nay là president và CTO của Palantir, thật sự đã phát minh ra chiến lược FDE (theo Bob, video đăng ngày 08/09/2025).

Điều cơ bản mà anh và đồng nghiệp nhận ra là với những khách hàng mà Palantir có, sản phẩm mà mỗi nơi cần lại hơi khác nhau. Vậy là anh và đồng nghiệp đi từ một khách hàng, build sản phẩm cho khách hàng đó, sang khách hàng tiếp theo và thấy nơi đó cần một thứ hơi khác. Thay vì build hai sản phẩm, hay build đúng feature cho từng nơi, anh và đồng nghiệp build một thứ giống platform hơn là một sản phẩm, có nhiều khả năng tùy biến tại từng site. Và khi làm vậy, bạn cần đưa một người tới site để hiểu người dùng đang làm gì và build phần tùy biến (theo Bob, video đăng ngày 08/09/2025).

## 4. Con đường sỏi và đường cao tốc, rồi câu hỏi về sales

Theo Bob, xưa nay việc đó được hiểu là services, và đó là thứ bạn muốn giảm thiểu: bạn không muốn làm nhiều việc cho từng khách hàng trong giai đoạn product market fit. Điều Shyam nhận ra là bạn có thể lật ngược nó lại và biến nó thành thứ có giá trị. Thứ anh ấy thấy Palantir cần là để FDE đóng vai product discovery. FDE tới site, lấy sản phẩm như nó đang có, và lấp khoảng trống giữa những gì sản phẩm làm được với những gì người dùng cần (theo Bob, video đăng ngày 08/09/2025).

Bob dùng một hình ảnh: FDE đi trước và làm một con đường sỏi (gravel road) tới nơi sản phẩm cần đến. Còn vai trò của team anh, product engineering team, là nhìn vào con đường đó và về cơ bản tìm ra nó nên được khái quát hóa thế nào cho năm khách hàng tiếp theo, hay mười khách hàng tiếp theo, rồi biến con đường sỏi đó thành một đường cao tốc trải nhựa (paved superhighway) (theo Bob, video đăng ngày 08/09/2025).

Hình ảnh con đường sỏi và đường cao tốc mà Bob dùng để mô tả cách FDE và product engineering team chia việc ở Palantir (theo Bob, video đăng ngày 08/09/2025).

Harj Taggar hỏi tiếp: anh có cảm giác sales như một hình thức product discovery không phải là khái niệm mới, chắc chắn nó đã có trước Palantir. Nhưng cách nhìn thường thấy trước đây là bạn có đội sales đi ra ngoài bán hàng và nói chuyện với khách hàng, rồi quay về báo lại cho kỹ sư. Còn ở Palantir, có vẻ chính kỹ sư làm việc đó. Đó là một quyết định có chủ đích hay nó đến từ đâu? Nhất là khi bạn bán cho chính phủ và quốc phòng, bạn sẽ tưởng xu hướng tự nhiên là thuê một người bán hàng dày dạn có lịch sử bán cho chính phủ, kiểu một Don Draper mặc vest, từng làm nhiều năm và hay mời các tướng đi ăn bít tết. Và đó thật ra không phải điều Palantir đã làm (video đăng ngày 08/09/2025).

![Harj Taggar đặt câu hỏi, Jared Friedman ngồi bên cạnh lắng nghe](https://homus.dev/photos/Zyw-YA0k3xo-0724.jpg)

Harj Taggar (trái) đặt câu hỏi về sales và product discovery, Jared Friedman ngồi bên cạnh (video đăng ngày 08/09/2025).

Bob nói có hai góc nhìn. Thứ nhất, lúc đầu anh và đồng nghiệp đã nói chuyện với nhiều người như vậy, và họ nói: tại sao tôi lại phải làm việc với một công ty Silicon Valley trong khi tôi có thể làm việc với một trong năm nhà thầu quốc phòng lớn (big five defense prime)? Thứ hai, ngay cả khi nói chuyện với những người có vẻ có thể thành công ở vai trò này, anh và đồng nghiệp thấy rất rõ là những người đó sẽ không hợp với văn hóa của công ty và sẽ không thật sự thành công. Và những lần thử làm theo cách đó hầu như không bao giờ hiệu quả (theo Bob, video đăng ngày 08/09/2025).

Vì vậy điều họ tìm ra rất khác. Theo Bob, khác biệt giữa product discovery do sales dẫn dắt và product discovery do FDE dẫn dắt là: với sales, bạn nói chuyện với người ta từ bên ngoài. Điều này quan trọng ở giai đoạn rất sớm, nhưng không hiệu quả bằng product discovery do FDE dẫn dắt, nơi bạn giải các vấn đề từ bên trong (theo Bob, video đăng ngày 08/09/2025).

## 5. Giải bài toán của CEO, land and expand, và cấu trúc team Echo, Delta

Bob mô tả phạm vi của một lần triển khai truyền thống: bạn có thể bắt đầu với thứ khá gần với những gì sản phẩm đang làm, nhưng bạn muốn giải một trong những vấn đề then chốt mà ban lãnh đạo đã xác định. Nếu bạn không giải một trong năm ưu tiên hàng đầu của CEO, có lẽ nó sẽ không thành. Họ có lẽ sẽ không có đủ năng lượng để kiên trì đi hết con đường khó khăn hơn nhiều, là build về cơ bản một phần mới của sản phẩm theo cách chạy được cho họ (theo Bob, video đăng ngày 08/09/2025).

Rồi khi đã giải xong vấn đề đầu tiên, FDE có thể nhận ra những vấn đề then chốt khác trong doanh nghiệp, đôi khi có giá trị hơn nhiều so với vấn đề bạn nhắm tới lúc đầu. Có thể không hiển nhiên rằng Palantir, hay công ty của bạn, giải được những vấn đề đó. Nhưng khi đã ở bên trong, nhờ hiểu sản phẩm (product insight), bạn thấy được là mình thật sự làm được, và bạn đi giải chúng. Như vậy, câu hỏi chuyển từ "làm sao bán cùng một thứ cho từng khách hàng" sang "làm sao land and expand" (theo Bob, video đăng ngày 08/09/2025).

![Jared Friedman vừa nói vừa ra dấu bằng tay, Harj Taggar ngồi cạnh lắng nghe](https://homus.dev/photos/Zyw-YA0k3xo-0945.jpg)

Jared Friedman (phải) nhờ Bob trình bày mô hình FDE ở Palantir như một cuốn sách hướng dẫn, Harj Taggar ngồi cạnh (video đăng ngày 08/09/2025).

Jared hỏi Bob có thể trình bày chính xác mô hình FDE vận hành thế nào ở Palantir không, gần như một cuốn sách hướng dẫn cho mọi người: đây là cách chúng tôi đã làm (video đăng ngày 08/09/2025).

Bob nói một điểm xuất phát là nghĩ về cách tổ chức team. Tất nhiên đã có nhiều phiên bản khác nhau qua thời gian, nhưng theo anh thứ then chốt vẫn giữ nguyên là hai vai trò chính, mà anh và đồng nghiệp gọi là team Echo và team Delta (theo Bob, video đăng ngày 08/09/2025).

Team Echo là các analyst được gắn vào chỗ khách hàng (embedded analysts). Họ tới customer site, nói chuyện với người dùng, cố tìm ra demo nào hay use case nào thật sự có ý nghĩa với người dùng ở site này, vấn đề then chốt nào có thể giải được. Họ cũng là account manager, cũng là những người quản lý các mối quan hệ tại customer site (theo Bob, video đăng ngày 08/09/2025).

Team Delta, những deployed engineer, về cơ bản là kỹ sư phần mềm, thường rất giỏi viết code cực nhanh và "chịu được rất nhiều đau" (eating a lot of pain), như cách anh và đồng nghiệp gọi. Họ là người lấy những ý tưởng kia, đưa chúng ra thế giới thật và build một giải pháp, một prototype, nhưng là thứ thật sự chạy được, rồi deploy nó cho khách hàng (theo Bob, video đăng ngày 08/09/2025).

## 6. Nhịp triển khai và chân dung người trong team Echo

Theo Bob, tất cả những việc này diễn ra trong một khoảng thời gian rất ngắn. Bạn vào với một ý tưởng về việc mình sẽ làm. Bạn đặt một mốc vài tháng sau đó, khi bạn sẽ có một buổi trình bày với ban lãnh đạo để cho họ thấy tiến độ. Và nếu buổi trình bày đó suôn sẻ, bạn sẽ thật sự deploy và triển khai ra toàn tổ chức (theo Bob, video đăng ngày 08/09/2025).

Diana Hu nói điều thú vị về hai vai trò này là chúng đòi hỏi những kiểu người và hồ sơ rất khác nhau. Làm sao để tìm được đúng người cho các vai trò này? Vì theo chị, không phải kỹ sư bình thường nào cũng hợp vai FDE: họ cần nói chuyện với người dùng nhiều hơn. Còn team Echo thì cũng phải có tính kỹ thuật hơn, không chỉ là account manager. Palantir đã build đội ngũ ban đầu này thế nào? (video đăng ngày 08/09/2025)

![Diana Hu ra dấu bằng hai tay khi đặt câu hỏi, Bob McGrew ngồi cạnh lắng nghe](https://homus.dev/photos/Zyw-YA0k3xo-1141.jpg)

Diana Hu hỏi Bob làm sao tìm được đúng người cho hai vai trò Echo và Delta (video đăng ngày 08/09/2025).

Bob nói một hồ sơ kinh điển cho team Echo là người đến từ chính lĩnh vực bạn đang làm, ví dụ một cựu sĩ quan quân đội hay một người từng làm sâu trong ngành y tế. Họ có kiến thức lĩnh vực sâu. Nhưng, và anh nhấn mạnh điều này rất quan trọng, họ cần là những người nổi loạn (rebels), hay như Shyam có lẽ sẽ gọi, những kẻ dị giáo (heretics). Họ cần là người hiểu mọi việc đang được làm thế nào và nhận ra rằng cách đó chưa đủ, rằng nó không chạy (theo Bob, video đăng ngày 08/09/2025).

Vì nếu góc nhìn của họ là "tôi đến từ thế giới này, nó ổn mà", thì họ sẽ không bao giờ tìm ra được bước nhảy vọt (step function change) mà phần mềm mới phải tạo ra. Theo Bob, nếu bạn không tạo được một thay đổi kiểu 3 lần hay 10 lần trong tổ chức đó, thì chẳng có lý do gì để bỏ ra ngần ấy công sức. Bạn có thể đã bán một phần mềm rất đơn giản nào đó cho xong. Đó là hồ sơ then chốt cho Echo (theo Bob, video đăng ngày 08/09/2025).

Còn với Delta, bạn muốn một người thật sự giỏi làm prototype. Hồ sơ sai cho một Delta, theo Bob, là một người thợ thủ công (craftsman), người rất thích bảo đảm các abstraction đúng y như chúng phải thế, rằng họ đang build phần mềm có thể bảo trì được trong khoảng chục năm. Vì đó không phải vai trò này, không phải công việc này (theo Bob, video đăng ngày 08/09/2025).

## 7. Chân dung Delta, FDE như trường đào tạo founder, và lời chê "chỉ là consulting"

Thứ bạn muốn, theo Bob, là một người có thể vào, tìm ra cách làm, viết code thô mà chạy được (rough and ready). Đôi khi code đó đẹp, nếu bạn có đúng người, nhưng thường thì không, và một lần nữa, đó không phải phần then chốt của công việc. Bạn cần một người có thể thật sự mang lại outcome dưới dạng phần mềm, đúng hạn. Và có thể phiên bản đầu tiên họ viết phải vứt đi, có thể họ viết lại hẳn phiên bản thứ hai, có thể người khác viết phiên bản thứ hai, tùy người đó. Nhưng đó là những bộ kỹ năng then chốt (theo Bob, video đăng ngày 08/09/2025).

Một host nhận xét nghe rất giống một founding team; có tiếng đáp "Yes". Có tiếng nói tiếp: nghe rất giống một founder; có tiếng đáp "Yeah". Rồi Jared hỏi: Palantir có thuê những người từng là founder startup và đưa họ vào các vai trò này không, hay chủ yếu đi theo chiều ngược lại? Theo Jared, chẳng phải ngẫu nhiên mà Palantir đã tách ra một số lượng startup đáng kinh ngạc, vì việc đào tạo FDE này đúng là sự đào tạo để trở thành founder: bạn học mọi kỹ năng của một founder. Nhưng chiều ngược lại có xảy ra không? (video đăng ngày 08/09/2025)

Bob nói hồi anh và đồng nghiệp mới bắt đầu, không có nhiều founder để tuyển. Anh nghĩ có lẽ bây giờ thì ngược lại (theo Bob, video đăng ngày 08/09/2025). Nhưng anh đồng ý rằng Jared nói đúng: điều bạn làm trong mỗi môi trường mới, ở mỗi customer site, hơi giống làm founder startup. Có điều bạn là một founder được tiếp cận một đòn bẩy sản phẩm (product leverage) rất mạnh khiến công việc dễ hơn. Theo anh, đó là sự đào tạo tuyệt vời, và như Jared nói, đó là lý do người ta thấy rất nhiều startup do người từ Palantir sáng lập (theo Bob, video đăng ngày 08/09/2025).

Jared đưa ra lời chê phổ biến mà anh hay nghe từ những người không thật sự hiểu chuyện: "ồ, đó chỉ là consulting được khoác lên bằng ngôn ngữ marketing bóng bẩy". Vì sao nói vậy là sai? (video đăng ngày 08/09/2025)

Bob nói anh không muốn trả lời một cách hời hợt rằng vì sao nó sai, vì theo anh thật sự có rủi ro là lời chê đó đúng. Nếu quay về năm 2015 và nói chuyện với mọi người về Palantir, có lẽ bạn sẽ nghe hai điều. Một, rằng Palantir là xấu xa (evil). Hai, rằng đó là một doanh nghiệp consulting sẽ không bao giờ scale được, rằng nó thật ra là một mô hình kinh doanh tồi, không phải một doanh nghiệp phần mềm. Và anh cùng đồng nghiệp đã bỏ nhiều thời gian để hiểu xem mô tả đó có đúng hay không (theo Bob, video đăng ngày 08/09/2025).

Từ góc độ mô hình kinh doanh, Bob nói một điều then chốt bạn sẽ thấy, và nên thấy, là: khi bạn vào một khách hàng mới và làm một lần triển khai mới, có thể lúc đầu bạn thật sự lỗ tiền (theo Bob, video đăng ngày 08/09/2025).

## 8. Biên lợi nhuận theo thời gian và vai trò của product team

Bob giải thích điều gì xảy ra khi bạn ở lâu hơn với một khách hàng. Thứ nhất, sản phẩm của bạn, nhờ product discovery, trở nên hợp hơn với việc khách hàng làm. Vì vậy bạn không còn cần một team lớn tại customer site để tìm hiểu khách hàng đang làm gì, để "trải đường", để viết code đó. Thứ hai, bạn nên đang giành được quyền, như Shyam sẽ nói (earning the right), để được tiếp cận những vấn đề quan trọng hơn ở khách hàng đó (theo Bob, video đăng ngày 08/09/2025).

Vì vậy về cơ bản bạn nên thấy chi phí trên mỗi đơn vị giá trị của outcome bạn mang lại đang giảm dần. Biên lợi nhuận bắt đầu ở mức âm, nhưng rồi trở nên dương sau một khoảng thời gian, có thể một năm, có thể vài năm ở customer site đó. Và nếu nhìn từ góc đó, theo Bob, bạn có thể thấy mình thật sự đang mang lại giá trị thật, lặp lại được (theo Bob, video đăng ngày 08/09/2025).

Đường biên lợi nhuận Bob mô tả cho một lần triển khai: âm lúc đầu, dương sau một năm hay vài năm (hình vẽ minh họa lời Bob, không phải số liệu; video đăng ngày 08/09/2025).

Diana nói một mảnh hấp dẫn để mô hình này chạy và kéo chi phí xuống chính là product team; có tiếng đáp "Yes". Chị hỏi product team ăn khớp và làm việc với team FDE thế nào (video đăng ngày 08/09/2025).

Bob nói về phía engineering, công việc của anh với tư cách kỹ sư thật ra không đến nỗi tệ. Những ngày đầu ở Palantir, anh và đồng nghiệp làm discovery do founder dẫn dắt và build sản phẩm mới. Về sau, những ngày muộn hơn ở Palantir, anh và đồng nghiệp vẫn làm vậy, vẫn build sản phẩm mới, và cảm giác đó rất tuyệt. Nhưng những vai trò thật sự khác là team FDE, và cả team product management (theo Bob, video đăng ngày 08/09/2025).

Theo Bob, sản phẩm bạn build không phải là một thứ được dọc hóa cao (highly verticalized), một luồng mà hàng triệu người sẽ đi qua, như khi bạn build Airbnb. Thay vào đó, vai trò của product team là giữ tầm nhìn sản phẩm (product vision). Bạn phải nghĩ: khi thấy một vấn đề mới ở một customer site, phiên bản khái quát của nó, áp dụng được cho mười khách hàng tiếp theo, là gì? (theo Bob, video đăng ngày 08/09/2025)

Vì có một kiểu thất bại kinh điển ở đây: FDE làm một thứ cho một khách hàng, và bạn nói "tuyệt, đó là cách nên làm", rồi đưa thẳng nó vào sản phẩm. Hóa ra nếu làm vậy, bạn đang build một thứ bị chuyên biệt hóa quá mức cho một khách hàng. Theo Bob, một phần "phép màu" ở đây là build được loại sản phẩm, với loại người làm product, có thể nhìn vào đó và đoán đúng vấn đề thật sự bạn đang giải, thứ mà lúc nào cũng khái quát hơn một chút so với vấn đề khách hàng mang tới (theo Bob, video đăng ngày 08/09/2025).

## 9. Khái quát hóa đúng mức: nguồn gốc ontology của Palantir

Diana tóm lại: vậy là cần có một sự khôn ngoan để biết nó thuộc nhóm nào, chỉ dành cho vertical này hay có thể khái quát hóa. Chị nhờ Bob cho một ví dụ trông như thế nào, về sản phẩm và vertical, thứ gì rơi vào nhóm này và thứ gì rơi vào nhóm kia (video đăng ngày 08/09/2025).

Bob nói có lẽ ví dụ cơ bản nhất là chính việc phát minh ra ontology của Palantir. Khi anh và đồng nghiệp mới bắt đầu bàn chuyện làm việc với chính phủ Mỹ, cụ thể là mảng tình báo, câu hỏi là: có nên có một bảng database cho người, một bảng khác cho tiền, một bảng khác cho thứ này? Theo anh, đến giờ thì rất hiển nhiên là nếu đi theo hướng đó và cố deploy cho nhiều người, database của bạn sẽ chẳng còn ý nghĩa gì (theo Bob, video đăng ngày 08/09/2025).

Vì thế thay đổi ở đây là: phải kéo nó lên một mức khái quát cao hơn. Thay vì nghĩ về những loại đối tượng cụ thể, nên cho phép team forward deployed engineering định nghĩa chúng theo từng khách hàng. Theo Bob, đó là câu chuyện nguồn gốc về việc Palantir có được ontology nổi tiếng của mình (theo Bob, video đăng ngày 08/09/2025).

Một host hỏi: vậy ngày nay nó vận hành thế nào? Có một database schema nền với các đối tượng dùng lại được như người và tiền, rồi được tùy biến cho từng site không? (video đăng ngày 08/09/2025)

Bob nói database schema cực kỳ khái quát. Chỉ có khái niệm đối tượng (objects), thuộc tính (properties), media, và liên kết (links) giữa các đối tượng. Anh nói rõ anh đang nói về sản phẩm cho chính phủ của Palantir, sản phẩm đầu tiên của công ty. Nhưng chính ontology là thứ mã hóa mọi thông tin chuyên biệt theo từng khách hàng, thứ nói rằng "đây là một người, đây là một con tàu, đây là một dòng tiền" (theo Bob, video đăng ngày 08/09/2025).

Cách Bob mô tả sản phẩm cho chính phủ của Palantir: schema chung ở dưới cùng, ontology mang phần chuyên biệt của từng khách hàng (theo Bob, video đăng ngày 08/09/2025).

## 10. Ontology ngày nay, product manager ở Palantir, và căng thẳng giữa FDE với product

Bob nói một lần nữa, đây có lẽ là ví dụ cơ bản nhất. Nhưng nếu bạn build thứ gì đó chỉ cho một khách hàng, bạn sẽ nghĩ bằng cách mô tả áp dụng cho khách hàng đó. Thay vì nói "với người thì ta làm thế này", bạn muốn kéo nó lên một mức và nói: có một thao tác chung ta muốn áp dụng cho những thứ có thuộc tính này. Người có thuộc tính này, có thể con tàu cũng có. Nhưng, anh nói thẳng, các khoản thanh toán tiền thì không có thuộc tính đó. Vậy là bạn phải nghĩ ở một mức abstraction cao hơn (theo Bob, video đăng ngày 08/09/2025).

Bob kể Palantir đã không tuyển product manager trong một thời gian dài. Khi tới lúc anh phải tuyển product manager, anh phỏng vấn những người từng là product manager xuất sắc ở các công ty khác, và anh yêu cầu họ nghĩ ở mức abstraction này. Họ không thật sự nghĩ được ở mức đó. Họ nói: được, đây là luồng, đây là nó nên trông thế nào cho khách hàng này. Nhưng đó là cách làm sai ở đây. Họ cần bật lên một mức và nghĩ: cái này vận hành thế nào trong ngữ cảnh của ontology? Ta thay đổi ontology thế nào để thứ chuyên biệt này chạy được qua nhiều khách hàng? Và tất nhiên còn nhiều ví dụ khác không liên quan gì tới ontology (theo Bob, video đăng ngày 08/09/2025).

Harj hỏi: điều đó có tạo ra căng thẳng văn hóa nào trong Palantir không? Theo anh, nghe như Bob đang mô tả FDE như những kẻ dị giáo: họ không muốn khái quát hóa, họ muốn làm điều tốt cho khách hàng và build giải pháp chuyên biệt. Nhưng hẳn là với product team nội bộ, bạn lại muốn tuyển người nghĩ được ở một mức abstraction nào đó, muốn build code bảo trì được và tồn tại lâu. Chắc chắn đâu đó phải có căng thẳng, khi một FDE nói: không, tôi không muốn dùng cái ontology khái quát đó, tôi muốn làm theo cách này (video đăng ngày 08/09/2025).

![Harj Taggar nói và ra dấu bằng tay, Jared Friedman ngồi bên cạnh](https://homus.dev/photos/Zyw-YA0k3xo-2043.jpg)

Harj Taggar hỏi về căng thẳng văn hóa giữa FDE và product team ở Palantir (video đăng ngày 08/09/2025).

Bob đáp: tất nhiên rồi, lúc nào cũng có rất nhiều căng thẳng. Nhưng anh sẽ không đóng khung chuyện này nhiều theo kỹ năng của từng người. Theo anh, nó phụ thuộc nhiều vào môi trường, vào việc người ta làm gì trong môi trường họ được đặt vào. Chuyện rất phổ biến là các FDE làm ngoài hiện trường một thời gian dài, rồi nói: này, tôi thật sự có thể sửa những sản phẩm này, rồi vào làm cực tốt ở phía product và nghĩ được ở mức abstraction đó. Nhưng khi bạn ở customer site, bạn đối mặt với một vấn đề rất cụ thể (theo Bob, video đăng ngày 08/09/2025).

## 11. Incentive khác nhau, cách build feature cùng FDE, và kỷ luật để không thành consulting

Một host hỏi xen: có lẽ incentive khác nhau chứ không phải kỹ năng khác nhau? Bob đồng ý: incentive khác nhau. Bạn đang giải một vấn đề rất cụ thể, và rất hợp lý khi cứ chọn cách đơn giản nhất để giải nó. Và theo anh, đó thật ra là điều FDE nên làm. Con đường sỏi trông như vậy. Còn đường trải nhựa thì phải đi qua không chỉ khách hàng này mà cả nhiều khách hàng khác ở xa hơn trên đường, nên đường trải nhựa thường trông hơi khác (theo Bob, video đăng ngày 08/09/2025).

Nhưng mặt kia của chuyện này, theo Bob: hãy tưởng tượng bạn nói "rõ ràng cách làm FDE này sai, anh ta đang build sai thứ. Sao product team không tự nghĩ thật kỹ xem nên build gì rồi đi build thứ đó?" Họ chắc chắn sẽ build sai thứ. Thực tế, cách anh và đồng nghiệp thường build feature lúc đầu là: team FDE build một thứ, thấy một nhu cầu ở một khách hàng. Anh và đồng nghiệp mang nó về product team ở Palo Alto và hỏi: phiên bản khái quát đúng là gì? Và những FDE đó tham gia các cuộc thảo luận đó, điều mà anh nói là cực kỳ quan trọng (theo Bob, video đăng ngày 08/09/2025).

Rồi anh và đồng nghiệp xác định thêm vài khách hàng khác: nếu nó chạy cho khách hàng này, ta nghĩ nó có thể chạy cho khách hàng kia. Vậy hãy mời cả FDE của những khách hàng đó vào để cùng thiết kế feature này, để khi build xong, ta biết nó sẽ chạy cho khách hàng nơi nó được làm prototype đầu tiên, và cũng chạy cho những nơi khác. Và khi đã dựng được ngữ cảnh đó, nơi mọi người thấy được "đây là ba workflow khác nhau một cách tinh tế", thì bỗng nhiên không còn cuộc tranh cãi kiểu "chúng tôi nghĩ nó nên khái quát" với "chúng tôi nghĩ nó nên cụ thể" nữa: mọi người cùng giải một vấn đề. Theo Bob, điều đó hòa hợp các incentive lại với nhau (theo Bob, video đăng ngày 08/09/2025).

Jared hỏi: Bob có thấy mô hình này đòi hỏi nhiều kỷ luật tổ chức để không thoái hóa thành consulting thuần túy, nơi các team FDE cứ đi build bất cứ sản phẩm nào khách hàng cần? (video đăng ngày 08/09/2025)

Bob nói có, bạn tuyệt đối phải tập trung vào chuyện này. Và theo anh còn một kiểu thất bại khác, xảy ra trước cả kiểu kia và là cách dễ hơn để trở thành một công ty consulting: khi bạn build ngoài hiện trường đúng sản phẩm mà khách hàng yêu cầu, thay vì sản phẩm thật sự có giá trị với họ. Vì thường thì "khách hàng" là cả một tổ chức. Bạn không nói chuyện với "khách hàng". Bạn nói chuyện với có thể là CIO, hoặc với một người bảo trợ cho dự án, thường thấp hơn CEO vài cấp, người mà bạn thỉnh thoảng mới gặp. Và thường thì họ thích để bạn giải một vấn đề dễ cho họ hơn là một vấn đề thật sự có tác động và cải thiện doanh nghiệp (theo Bob, video đăng ngày 08/09/2025).

Diana quay lại câu mở đầu của Jared: chuyện gì đang xảy ra với tất cả các công ty AI đang tăng tốc tuyển rất nhiều FDE? Điều gì khiến họ thật sự chọn mô hình này, trong khi thế hệ công ty SaaS trước đó thì không? Chuyện gì đã xảy ra? (video đăng ngày 08/09/2025)

## 12. Vì sao các công ty AI agent chọn mô hình FDE

Harj nói thêm vào câu hỏi: theo anh, ngay cả khi Palantir đã thành công và mô hình FDE được biết tới nhiều hơn, nó vẫn bị xem là một trường hợp cá biệt, vì Palantir là một công ty độc nhất và bán cho chính phủ là một chuyện rất kỳ lạ (video đăng ngày 08/09/2025).

Có tiếng nói tiếp: "Yeah, but you wouldn't, don't try this at home", kiểu tư duy "đừng thử ở nhà", đúng không? Còn bây giờ, như Diana nói, nó đã trở nên rất phổ biến. Câu hỏi cho Bob có hai phần: một, điều đó có làm anh ngạc nhiên không; và hai, vì sao anh nghĩ nó xảy ra (video đăng ngày 08/09/2025).

Bob nói điều này hoàn toàn làm anh ngạc nhiên. Lời khuyên thứ nhất, thứ hai và thứ ba của anh cho những ai đang tính thử chiến lược FDE là: đừng thử ở nhà. Nếu tránh được thì nó có lẽ không tốt cho bạn, có lẽ bạn sẽ kết thúc bằng việc làm services. Và chỉ khi bạn đã thật sự cố gắng không làm nó mà thất bại, thì có lẽ nó mới thật sự là một con hào (moat) cho bạn, nếu đó là cách duy nhất có thể chạy được trong thị trường của bạn (theo Bob, video đăng ngày 08/09/2025).

Vậy thị trường này có gì đặc biệt? Vì sao thị trường AI agent lại vận hành như vậy? Bob đề xuất bắt đầu từ câu hỏi vì sao Palantir phải chọn cách này. Thị trường của Palantir không phải một thị trường thống nhất. Anh và đồng nghiệp làm việc với các cơ quan tình báo quốc gia, với cơ quan thực thi pháp luật quốc gia, với quân đội. Tất cả các tổ chức này có một số dự án tương tự nhau. Nhưng ngay cả khác biệt giữa một workflow chống phổ biến vũ khí (counter-proliferation) và một workflow chống khủng bố (counter-terrorism), một bên bạn đang cố tìm ra ai đang chế tạo bom hạt nhân, bên kia là ai đang chế tạo IED, cũng đã khá khác nhau về cách vận hành (theo Bob, video đăng ngày 08/09/2025).

Vì vậy có một sự không đồng nhất (heterogeneity) đáng kinh ngạc, và theo Bob bạn nên nghĩ về thị trường như nhiều phân khúc khác nhau. Trong mỗi phân khúc, bạn có thể build một thứ và câu chuyện Crossing the Chasm áp dụng được phần nào: lúc đầu chẳng có gì chạy, rồi bỗng bạn tìm ra product market fit trong phân khúc đó, bạn deploy được cho những người làm loại workflow này, và ở khách hàng tiếp theo bạn thấy những người làm workflow tương tự và deploy được với rất ít tùy biến. Nhưng có một giới hạn tự nhiên cho điều đó. Rồi bạn muốn chinh phục một phân khúc khác và phải phát triển một công nghệ mới, thứ sau đó có thể được dùng lại ở các phân khúc khác (theo Bob, video đăng ngày 08/09/2025).

Bob nói rõ một phân khúc không nhất thiết là một khách hàng, đặc biệt ở một doanh nghiệp hay một doanh nghiệp rất lớn như chính phủ, nơi một khách hàng có thể là hàng chục nghìn người dùng. Đó là chỗ chiến lược FDE có ý nghĩa: bạn đang làm những việc không scale, nhưng làm chúng một cách scale được, hết lần này tới lần khác, cho mỗi phân khúc thị trường bạn bước vào (theo Bob, video đăng ngày 08/09/2025).

Vậy vì sao lại thấy điều này với AI agent? Theo Bob, điều độc đáo khác ở Palantir là anh và đồng nghiệp build một loại sản phẩm hoàn toàn mới. Người dùng trước đó về cơ bản làm phân tích và theo dấu người trong một công cụ trông giống PowerPoint, và cộng tác bằng cách gửi qua gửi lại các file. Sản phẩm Palantir build thì nói: này, khi bạn vẽ sơ đồ liên kết (link diagram) đó, bạn không chỉ đang sửa một file, bạn đang thay đổi một database, và mọi người dùng chung một database. Với người dùng, nó trông như một thay đổi nhỏ trên công việc họ đang làm; nhưng với doanh nghiệp, với tổ chức mà họ bán cho, đó là một hạng mục thị trường (market category) hoàn toàn khác (theo Bob, video đăng ngày 08/09/2025).

Và theo Bob, đó là điều đang xảy ra với AI agent: đây là một market category hoàn toàn mới. Nếu bạn triển khai một sản phẩm SaaS tiêu chuẩn và thay một cách trả hóa đơn bằng một cách trả hóa đơn khác, ai cũng hiểu thị trường đó là gì. Không có nhiều phân khúc nhỏ lẻ như vậy, không có cùng kiểu product discovery. Bạn có thể làm một sản phẩm tốt hơn sản phẩm đương nhiệm và scale bằng cách thay thế sản phẩm đó. Còn với agent thì không có sản phẩm đương nhiệm (theo Bob, video đăng ngày 08/09/2025).

Anh nói thêm rằng việc build agent thật ra có lẽ là rất nhiều thứ khác nhau, và chúng ta chưa biết đó là những gì, chúng ta phải tìm ra. Theo anh, có lẽ năm năm nữa nhìn lại, chúng ta sẽ nói: AI agent ư, đó thậm chí chẳng phải một thứ, chúng ta thật ra đang làm đủ thứ khác nhau. Và đó là lý do anh nghĩ mô hình FDE đang bùng lên: có quá nhiều product discovery phải làm, và bạn chỉ có thể làm nó từ bên trong doanh nghiệp (theo Bob, video đăng ngày 08/09/2025).

Một host hỏi: điều đó liên hệ thế nào với lời khuyên kinh điển của YC, "do things that don't scale"? Bob đáp: đó là lời khuyên bạn cho một founder ở giai đoạn sớm. Còn mô hình FDE, về bản chất, là làm những việc không scale, nhưng ở quy mô lớn (theo Bob, video đăng ngày 08/09/2025).

Jared hỏi tiếp: vì Bob thấy rất nhiều người đang cố áp dụng mô hình FDE vào startup mới của họ, kể cả nhiều người chưa từng làm ở Palantir và học nó qua tay thứ hai, thứ ba, thì người ta hay làm sai ở đâu, hay có những ngộ nhận nào anh muốn gỡ bỏ? (video đăng ngày 08/09/2025)

Bob bắt đầu bằng nhận xét từ những startup anh làm cố vấn đang làm theo hướng này: theo anh, những startup thành công nhất với mô hình FDE có người từ Palantir điều hành nó. Những startup anh từng nói chuyện đang chuyển sang mô hình FDE đã được lợi nhiều khi đưa một người từ Palantir vào một trong các vai trò cốt lõi. Như anh nói, engineering team thường khá giống nhau, có lẽ vẫn vui trong một thời gian dài. Nhưng cơ chế thực tế về cách các FDE làm việc, cách bạn xây dựng các account, cách bạn tìm ra outcome, thì khá khác với một công ty phần mềm tiêu chuẩn (theo Bob, video đăng ngày 08/09/2025).

## 13. Định giá theo outcome, Kastle, HappyRobot và đội IT

Một trong những khác biệt then chốt, và theo Bob là thứ khá khó để người ta hiểu, là cách bạn chọn một vấn đề, rồi cách bạn định giá vấn đề đó. Về căn bản, thứ bạn bán với mô hình FDE không phải việc cài đặt phần mềm. Như Shyam sẽ nói, bạn bán một outcome: bạn bán việc bạn đã giải được một vấn đề. Câu hỏi tiếp theo là: nếu bạn đã giải một vấn đề và đang mang lại giá trị cho người dùng, bạn định giá nó thế nào? (theo Bob, video đăng ngày 08/09/2025)

Diana nói đó là câu hỏi rất phổ biến mà nhóm nhận được từ các startup AI, vì trong thời SaaS bạn định giá theo mức sử dụng (usage), theo subscription hay theo seat. Còn bán outcome thì hoàn toàn khác. Làm sao định giá đây? Các founder AI nên định giá giải pháp của mình thế nào? (video đăng ngày 08/09/2025)

Bob nói một điều rất quan trọng phân biệt mô hình FDE với mô hình SaaS tiêu chuẩn là: với SaaS và product market fit, bạn hướng tới những hợp đồng rất đơn giản, lặp lại được, cách định giá rất đơn giản, lặp lại được, hợp lý cho mọi khách hàng. Và thường bạn khá thoải mái với hợp đồng nhỏ, vì chi phí biên để deploy rất thấp. Với mô hình FDE, bạn sẽ bị đẩy về phía hợp đồng ngày càng lớn. Như đã nói, bạn sẽ tăng giá trị hợp đồng với mỗi khách hàng theo thời gian. Và vì phức tạp, các hợp đồng sẽ linh hoạt hơn (theo Bob, video đăng ngày 08/09/2025).

Diana nói chị nghĩ đây là điều mà các startup AI nhóm làm việc cùng tự khám phá ra. Chị kể về Kastle, một công ty làm voice agent AI cho mortgage servicing (dịch vụ quản lý khoản vay thế chấp), làm việc với các ngân hàng rất lớn. Cách họ đi vào vận hành thật với các ngân hàng lớn đúng là mô hình tăng dần như vậy: tính theo số cuộc gọi thành công mà họ xử lý, tất cả những yêu cầu về khoản vay thế chấp. Rồi họ có các điều khoản kiểu khi lên quy mô lớn thì sẽ là mức này, mức kia. Theo chị, họ tự tìm ra điều đó (theo Diana, video đăng ngày 08/09/2025).

![Trang web của Kastle với dòng chữ Purpose-built AI agents for mortgage lending and servicing, nhãn Kastle (S24)](https://homus.dev/photos/Zyw-YA0k3xo-3132.jpg)

Trang web của Kastle như hiện trong video: "Purpose-built AI agents for mortgage lending and servicing", dòng phụ nói các ngân hàng được FDIC bảo hiểm và IMB tin dùng Kastle để tự động hóa các cuộc gọi khối lượng lớn từ lúc hỏi vay tới lúc tất toán; nhãn cam ghi "Kastle (S24)" (video đăng ngày 08/09/2025).

Diana kể thêm các startup khác cũng vậy, như HappyRobot, một công ty YC khác làm voice agent AI cho logistics. Họ làm việc với các công ty lớn như DHL, theo cách tương tự (theo Diana, video đăng ngày 08/09/2025).

![Trang web của HappyRobot với dòng chữ Intelligence that runs your operations, nhãn HappyRobot (S23)](https://homus.dev/photos/Zyw-YA0k3xo-3203.jpg)

Trang web của HappyRobot như hiện trong video: "Intelligence that runs your operations", với dòng mô tả HappyRobot là hệ điều hành AI-native biết về doanh nghiệp của bạn; nhãn cam ghi "HappyRobot (S23)" (video đăng ngày 08/09/2025).

Bob nói có một sự bất cân xứng ở đây giữa bạn, startup, và doanh nghiệp bạn bán cho. Thường khi bạn bán cho một doanh nghiệp lớn, họ không tin rằng họ thật sự làm được điều gì, vì nhiều khi họ đã có nhiều dự án lớn thất bại. Họ cũng không tin bạn làm được điều gì, vì họ nghĩ bạn, startup, cũng giống họ. Còn bạn thì biết mình thật sự thực thi được. Và nếu không làm được, thì đằng nào bạn cũng nên chuyển sang một ngành khác (theo Bob, video đăng ngày 08/09/2025).

Vì vậy theo Bob, lúc đầu hợp lý là startup gánh hết rủi ro và nói: chúng tôi sẽ tin vào khả năng thực thi của chính mình, chúng tôi nhận rủi ro, và các anh trả tiền nếu nó chạy, hoặc trả tiền khi chúng tôi thật sự mở rộng được (theo Bob, video đăng ngày 08/09/2025).

Sự bất cân xứng Bob mô tả giữa startup và doanh nghiệp lớn, và vì sao lúc đầu startup nên gánh rủi ro (theo Bob, video đăng ngày 08/09/2025).

Và chỗ điều này có thể hỏng, theo Bob, là nhất là khi bạn làm một thứ cần được deploy vào doanh nghiệp, on premise, hay có bất kỳ phần nào phải chạy on premise thay vì trên cloud: bạn sẽ phải chiến đấu với đội IT (theo Bob, video đăng ngày 08/09/2025).

Diana nói chị cũng đã thấy điều đó; có tiếng đáp "Yeah"; chị nói thêm: với một số công ty trong số này (video đăng ngày 08/09/2025).

Bob nói rộng hơn: ai cần nói "có" bên trong tổ chức bạn đang deploy vào để bạn thành công? Vì những người đó không nghĩ như startup. Họ không cùng phía với người dùng cuối. Và bạn sẽ phải tìm cách vượt qua họ (theo Bob, video đăng ngày 08/09/2025).

## 14. Executive buy-in, Collison install và giới hạn của việc làm custom

Đây là một phần lý do, theo Bob, tại sao việc bạn đang giải một trong năm vấn đề hàng đầu của CEO lại quan trọng. Bạn cần có khả năng mời một người từ cấp cao nhất vào để nói: được, cấp cho họ quyền vận hành (authority to operate). Cho họ khả năng dùng... Các anh dùng loại database này, họ cần dùng một loại database khác. Bạn có đủ thứ quy định tổ chức rất cụ thể, vốn dành cho nhân viên IT tự build trong nhà, nhưng chúng không áp dụng cho startup. Hãy để họ làm điều họ cần làm (theo Bob, video đăng ngày 08/09/2025).

Diana hỏi Palantir đã có được executive buy-in thế nào. Theo chị, đây có vẻ là điều đang xảy ra với tất cả các startup AI đang cất cánh và đi từ con số không lên doanh thu bảy, tám chữ số trong vòng một năm. Họ tìm ra cách có executive buy-in, nhưng theo chị mọi thứ đều khá tùy hứng, theo tất cả những câu chuyện chị biết (theo Diana, video đăng ngày 08/09/2025).

Bob nói lúc đầu ở Palantir cũng có cảm giác như vậy. Đó là một kỷ luật, một kỹ năng. Bạn cần sự lãnh đạo thật sự xuất sắc ở team FDE để có loại kỷ luật đó, để chia sẻ những gì hiệu quả, và để có được thực hành làm việc đó ở một khách hàng. Anh nói nó không đến nỗi tệ. Theo anh, Palantir bây giờ cực kỳ giỏi việc này, có lẽ giỏi hơn bất kỳ công ty nào khác. Và đó là lý do những công ty anh thấy làm việc này tốt nhất đều lấy kinh nghiệm từ những người đã làm nó trước đó. Nhưng nó có thể học được: anh và đồng nghiệp đã học được nó (theo Bob, video đăng ngày 08/09/2025).

![Harj Taggar nói và ra dấu bằng tay, Jared Friedman ngồi bên cạnh lắng nghe](https://homus.dev/photos/Zyw-YA0k3xo-3529.jpg)

Harj Taggar so sánh mô hình FDE với lời khuyên kinh điển của YC về "Collison install" (video đăng ngày 08/09/2025).

Harj nói Jared đã chỉ ra trước đó rằng mô hình forward deployed engineer của Palantir không quá khác lời khuyên kinh điển của YC về làm những việc không scale. YC có khái niệm gọi là Collison install, mà theo Harj nhóm rút gọn lại là: đừng chờ người ta tự tìm tới website của bạn, hãy đi tới chỗ họ và khiến họ cài phần mềm. Đi tới tận nơi, tới văn phòng của họ và ngồi cạnh họ (theo Harj, video đăng ngày 08/09/2025).

Theo Harj, đó vẫn là một chiến lược khởi đầu tuyệt vời, nhưng phần lớn startup không có hợp đồng lớn ngay từ đầu. Nên lý do thật sự khiến họ phải dừng cái quy trình thủ công, nhiều tương tác (high touch) này là bạn không thể duy trì tốc độ tăng trưởng nếu tới một lúc nào đó không có một sản phẩm scale được. Giống điều đã nói lúc nãy: tới một lúc, hy vọng là bạn build được một sản phẩm tốt tới mức người ta tự hiểu cách dùng, và khi đó mọi vấn đề của bạn chỉ còn là scale nó (theo Harj, video đăng ngày 08/09/2025).

Với AI, theo Harj, điều khác là vì các hợp đồng bây giờ quá lớn, bạn thật sự có thể đi khá xa bằng cách làm kiểu high touch. Và anh nhờ Bob giúp một chuyện: một câu hỏi office hours phổ biến mà anh hay nhận là "tôi có thể tiếp tục đẩy cách này tới đâu?". Lời khuyên của anh phần lớn là: làm việc custom cho từng khách hàng thì không sao, bạn chỉ cần ít custom hơn với mỗi khách hàng mới. Anh hỏi Bob có thể cho lời khuyên cụ thể hơn, "độ phân giải cao hơn" không: làm sao biết việc tiếp tục thêm khách hàng theo kiểu high touch, làm nhiều việc custom, vẫn ổn, hay đã tới lúc phải trừu tượng hóa và build một sản phẩm thật sự (theo Harj, video đăng ngày 08/09/2025).

## 15. Đo cái gì: giá trị outcome và product leverage cho FDE

Bob nói theo anh câu hỏi này gói trọn khác biệt then chốt giữa chiến lược product market fit và chiến lược FDE. Trong chiến lược product market fit, bạn muốn làm ít việc hơn cho mỗi khách hàng, muốn kéo chi phí xuống, muốn giữ nguyên quy mô hợp đồng. Trong chiến lược FDE, bạn muốn đẩy quy mô hợp đồng lên. Bạn đang làm việc ngày càng có giá trị cho khách hàng này và cho cả khách hàng tương lai. Và vì bạn đang làm việc có giá trị hơn, nên không sao: bạn có thể để lượng tùy biến cho mỗi khách hàng giữ nguyên (theo Bob, video đăng ngày 08/09/2025).

Khác biệt Bob nêu giữa hai chiến lược, và hai thứ anh nói nên đo (theo Bob, video đăng ngày 08/09/2025).

Harj hỏi lại: vậy KPI, chỉ số nội bộ, là quy mô hợp đồng, chứ không nhất thiết là họ làm bao nhiêu việc custom cho mỗi khách hàng? (video đăng ngày 08/09/2025)

Bob nói có hai điều hữu ích ở đây. Một, thứ bạn đo được: đúng, quy mô hợp đồng. Anh còn muốn nói khái quát hơn một chút: giá trị của outcome bạn đang mang lại, vì đó mới là thứ thật. Và bạn đã có "cơ bắp" để kiếm tiền từ nó, định giá nó và thu về giá trị đó chưa? Có thể chưa. Nhưng nếu bạn mang lại được những outcome ngày càng có giá trị cho khách hàng, thì bạn đang làm đúng điều gì đó (theo Bob, video đăng ngày 08/09/2025).

Phần thứ hai, mà theo Bob nhóm chưa nói tới, là giá trị của sản phẩm. Thứ khác bạn muốn đo là: bạn có đang có được ngày càng nhiều product leverage trên outcome đó không? Theo anh, tất cả điều này cực kỳ phản trực giác khi bạn ở bên trong nó. Rất khó nếu bạn là một FDE, hay đang dẫn một team FDE. Có nhiều việc bạn phải làm có vẻ rất phản trực giác. Bạn phải build cho khách hàng những thứ họ không yêu cầu, nhưng thật sự muốn (theo Bob, video đăng ngày 08/09/2025).

Ở phía product, theo Bob, bạn thường tự hỏi: làm sao tạo một sản phẩm thật dễ dùng cho mọi khách hàng? Anh thừa nhận chính anh đã vật lộn nhiều với điều này khi dẫn dắt product lúc đầu. Bạn muốn tập trung vào trải nghiệm người dùng, và bạn phải làm vậy. Nhưng bạn cũng phải nhớ rằng khách hàng then chốt khác của bạn là FDE. Sản phẩm của bạn rốt cuộc nên mang lại điều tốt cho người dùng sau khi được FDE tùy biến, nhưng nó cũng nên mang lại đòn bẩy cho FDE, người đang mang lại outcome ở customer site. Và lượng product leverage đó nên tăng theo thời gian. Họ nên dùng được sản phẩm của bạn để mang lại nhiều giá trị hơn cho khách hàng mà không phải kéo thêm ba kỹ sư nữa vào (theo Bob, video đăng ngày 08/09/2025).

Bob nói tiếp: nếu khách hàng đầu tiên bạn deploy tốn rất nhiều công sức, thì khi bạn muốn bán cùng outcome đó cho một khách hàng khác, việc ở khách hàng thứ hai nên dễ hơn nhiều, và còn dễ hơn nữa khi bạn đi qua từng khách hàng. Nhưng nếu bạn thật sự làm được, hãy nhớ rằng bạn đang build một platform. Bạn đang làm nhiều hơn là chồng các use case dọc lên nhau. Nếu bạn đã trừu tượng hóa đúng khái niệm cốt lõi mà mình thật sự đang build, bạn cũng sẽ dễ dàng hơn, có nhiều product leverage hơn, ngay cả khi không làm đúng use case đó mà làm một thứ tương tự. Hoặc bạn sẽ thấy, nếu nó thật sự tốt, các FDE của bạn có thể tìm ra cách mới để dùng kỹ thuật bạn đã build để giải một thứ hoàn toàn khác (theo Bob, video đăng ngày 08/09/2025).

Một host nói: gần như có một động lực thị trường nội bộ đang diễn ra, theo đó nếu bạn build nó thật tốt thì FDE sẽ tự chọn dùng nó, và bạn sẽ thấy nhu cầu từ các FDE muốn dùng sản phẩm đã được trừu tượng hóa của bạn thay vì tự hack một giải pháp dùng một lần (video đăng ngày 08/09/2025).

Bob đồng ý, nhưng lưu ý đây là một quá trình rất đau đớn cho tất cả mọi người, và anh nói có lẽ không thể dùng chữ "đau" đủ nhiều. Có nhiều lần anh build một thứ mà anh nghĩ là tuyệt vời, đẹp đẽ, dù chưa tới mức đó, nhưng thật sự sẽ giúp được các FDE nếu họ chịu nhìn vào nó. Anh nói: làm ơn dùng sản phẩm của tôi đi. Và họ đáp: không, cái này nhiều việc hơn nhiều, chẳng giúp gì. Anh thừa nhận, thành thật mà nói, phần lớn những lần đó có lẽ anh sai và đang build sai sản phẩm cho họ, và anh lẽ ra phải nhận ra điều đó. Nhưng đôi khi anh đi đúng hướng, chỉ là chưa làm đủ để FDE dùng nó dễ dàng. Thế là anh cử các developer ra hiện trường để deploy những giải pháp ban đầu đó và đưa chúng qua vạch đích, tới mức các FDE dùng chúng mà vẫn có lãi (theo Bob, video đăng ngày 08/09/2025).

Harj hỏi: trong trường hợp đó, FDE luôn đúng sao? Hay đôi khi founder nên áp đặt từ trên xuống và nói: tôi muốn các anh làm theo cách này? (video đăng ngày 08/09/2025)

## 16. Phán đoán, demo-driven development và một công ty biết học

Bob nói câu trả lời là "có" cho tất cả những điều đó. Điều khác cứ lặp đi lặp lại là đáp án đúng ở đây là chuyện phán đoán (judgment) đến mức nào. Quay lại câu hỏi về product vision: sản phẩm đúng, khái quát từ khách hàng này sang ba khách hàng tiếp theo, rồi mười khách hàng tiếp theo, là gì? Theo anh, theo nghĩa đen, bạn không có thông tin cần thiết để trả lời khi bạn mới thấy khách hàng đầu tiên. Vì vậy nó trở thành một quyết định dựa trên phán đoán (theo Bob, video đăng ngày 08/09/2025).

Diana hỏi: trong bối cảnh các công ty FDE định giá rất khác, dựa trên outcome, điều đó khớp thế nào với văn hóa làm demo? Vì chị nói ít nhất trong SaaS, chị từng bị các kỹ sư của mình phản đối: phát triển sản phẩm theo demo (demo-driven product development) bị coi thường. Nhưng trong trường hợp này thì khác với FDE, đúng không? (video đăng ngày 08/09/2025)

![Diana Hu đặt câu hỏi, cận cảnh bên micro](https://homus.dev/photos/Zyw-YA0k3xo-4101.jpg)

Diana Hu hỏi demo-driven development khớp thế nào với cách các công ty FDE làm việc (video đăng ngày 08/09/2025).

Bob nói một điều thú vị xảy ra ở đó là vì bạn phải liên tục cho khách hàng mới xem, bạn buộc phải làm những demo mới này. Nhưng thật ra anh nghĩ demo-driven development chạy rất tốt nếu bạn có đúng loại sản phẩm. Những ngày đầu ở Palantir, anh và đồng nghiệp thật ra chỉ có một demo: một luồng trong đó bạn đang ngăn chặn một âm mưu khủng bố. Nhóm bắt đầu nó với một feature. Và mỗi lần tích hợp một feature mới, cả nhóm phải tự hỏi: làm sao cho thấy feature mới này thật sự giúp ích cho người analyst đang đi qua demo này, đang ngăn chặn âm mưu này? (theo Bob, video đăng ngày 08/09/2025)

Khi tích hợp một histogram, nhóm phải hỏi: ta thật sự dùng nó thế nào, nó khớp thế nào với các feature đã có? Khi tích hợp một bản đồ, cùng câu hỏi đó. Theo Bob, nếu bạn nhìn thế giới từ câu hỏi "mình đang build gì", bạn nghĩ về năng lực của mình, có thể nghĩ về từng feature riêng lẻ và cách build phiên bản tốt cho mỗi feature. Nhưng khi build một demo, bạn nghĩ từ góc nhìn của khách hàng (theo Bob, video đăng ngày 08/09/2025).

Một demo thật sự tốt, theo Bob, là thứ khi bạn cho khách hàng xem, bạn tạo ra mong muốn trong họ đối với thứ bạn đang làm. Họ phải thấy những gì bạn đang làm và muốn với tay chộp lấy, mang nó vào cuộc sống của họ. Nếu bạn thấy điều đó, bạn biết mình đã xác định được một nỗi đau thật của khách hàng. Và làm như vậy cũng buộc bạn phát triển một sản phẩm tốt hơn, vì bạn không chỉ nghĩ "từng feature có hợp lý khi đứng riêng không" mà còn "chúng phối hợp với nhau thế nào". Nếu bạn sẽ cho xem demo này hết lần này tới lần khác, thì ngay cả những thứ đơn giản như chuyển từ feature này sang feature khác, đoạn đường đó phải rất trơn tru. Và đó đều là những điểm đau sản phẩm mà bạn thường thấy, nhưng phải tới sau khi đã thật sự deploy cho khách hàng (theo Bob, video đăng ngày 08/09/2025).

Vậy, theo Bob, demo làm thay đổi trọng tâm của điều bạn đang nghĩ, từ "mình có thể build gì" sang "khách hàng muốn gì, và mình có đang giải điểm đau đó cho khách hàng không" (theo Bob, video đăng ngày 08/09/2025).

Diana nói nghe như là bạn phải liên tục làm gradient ascent trong một không gian rất, rất nhiều chiều (video đăng ngày 08/09/2025).

Bob nói có lẽ đó là một điểm then chốt: loại công ty bạn phải build là một công ty biết học (learning company). Ai cũng muốn build một công ty biết học. Nhưng nếu bạn là một công ty như Google hay Meta, theo anh rất dễ để không học, vì những gì bạn đang làm vẫn đang chạy. Nếu bạn cứ tiếp tục làm vậy, thị trường đang lớn lên, ai cũng muốn làm điều bạn đang làm, bạn có thể cứ trôi theo cùng một chiến lược và nó vẫn đem lại kết quả (theo Bob, video đăng ngày 08/09/2025).

Lời khuyên của Bob cho những ai đang nghĩ nên gia nhập công ty nào: hãy gia nhập một công ty trẻ, không nhất thiết là công ty nhỏ, mà là công ty trẻ. Vì một công ty trẻ vẫn đang tìm đường, vẫn đang học, chưa thành công. Bạn muốn một công ty trẻ đang tăng trưởng rất nhanh, rồi bạn sẽ thấy thành công trông như thế nào, và điều đó đặt bạn vào đúng vị trí để sau này làm founder của công ty riêng (theo Bob, video đăng ngày 08/09/2025).

Theo Bob, đó là lý do Palantir đã sinh ra nhiều startup khác như vậy: ngay cả khi đã là một công ty rất lớn, nó vẫn là nơi mọi người lúc nào cũng đang học, tập trung vào việc học, và luôn làm cùng cái chuyển động mài miệt (grinding motion) của một startup mới (theo Bob, video đăng ngày 08/09/2025).

## 17. Bob gia nhập U.S. Army Reserve

Có tiếng nói tiếp: đúng vậy, startup mới cũng có rất nhiều đau đớn, phải không? Và đó có lẽ là phần cốt lõi của trải nghiệm YC: không phải trôi theo quán tính, mà là làm việc thật, thật vất vả cho một thứ bạn không chắc nó có thành công không (video đăng ngày 08/09/2025).

Harj nói: rõ ràng Palantir là một thành công khổng lồ, giờ là một công ty rất lớn, một tổ chức khổng lồ. Anh nghe nói Bob đang gia nhập một tổ chức lớn khác, U.S. Army Reserve (lực lượng dự bị của Quân đội Mỹ). Anh nhờ Bob kể một chút về chuyện đó, và hỏi có bài học nào từ kinh nghiệm ở Palantir mà Bob định áp dụng ở đó không (video đăng ngày 08/09/2025).

Bob nói chắc chắn rồi. Anh vừa gia nhập U.S. Army Reserve trong khuôn khổ Detachment 201. Anh nói trước để khỏi hiểu nhầm: mọi điều anh nói ở đây là ý kiến của anh, không phải ý kiến của Quân đội Mỹ, Bộ Quốc phòng hay chính phủ Mỹ. Theo anh, đó là một trải nghiệm cực kỳ dữ dội và là một câu chuyện rất thú vị (theo Bob, video đăng ngày 08/09/2025).

Bob kể anh và nhóm thuộc một đơn vị cố vấn cho Quân đội về công nghệ. Anh và nhóm không chỉ là cố vấn dân sự, mà là sĩ quan thật sự, đã tuyên thệ. Anh là trung tá (lieutenant colonel) trong Quân đội Mỹ (theo Bob, video đăng ngày 08/09/2025).

Một host hỏi có phải Bob cũng đã qua huấn luyện cơ bản. Bob nói anh và nhóm đã qua khóa direct commissioning (khóa phong cấp trực tiếp). Nhóm được các nhà giáo quân sự huấn luyện, thường vào lúc 5 giờ sáng, giờ hợp với những người ở Bờ Đông và không đụng với công việc chính của mọi người. Nhóm học từ các sĩ quan. Anh phải thi bài kiểm tra thể lực của Quân đội, và vì anh nói mình không khỏe lắm, đó là thứ anh phải tập luyện suốt chín tháng (theo Bob, video đăng ngày 08/09/2025).

Nhưng theo Bob điều đó thật sự quan trọng, vì anh và nhóm không chỉ đưa ra lời khuyên bên lề. Nhóm có "da thịt trong cuộc chơi" (skin in the game): nhóm thật sự là một phần của tổ chức mà nhóm đang cố vấn (theo Bob, video đăng ngày 08/09/2025).

Và chính Quân đội, theo Bob, có ban lãnh đạo rất khác so với cảm giác những ngày đầu ở Palantir, khi anh và đồng nghiệp ở Palantir làm việc với Quân đội khoảng năm 2005 hay 2010. Tướng Randy George, tham mưu trưởng Lục quân (chief of staff of the Army), và Bộ trưởng Lục quân Driscoll đã nêu rõ một kế hoạch chuyển đổi Quân đội. Theo Bob, họ biết Quân đội cần thay đổi, từ việc đánh những kiểu chiến tranh từng đánh ở Iraq và Afghanistan sang đánh những kiểu chiến tranh đang diễn ra hôm nay ở Ukraine, hay hình dung nó sẽ thế nào nếu phải đối mặt với các chiến dịch tác chiến quy mô lớn ở Thái Bình Dương. Họ biết Quân đội cần nhanh hơn, cần thay đổi. Và nhóm của Bob là một phần của chiến lược họ đang thực thi (theo Bob, video đăng ngày 08/09/2025).

Khi đưa nhóm vào, theo Bob, ban lãnh đạo đã nêu các ưu tiên của Quân đội, giao cho mỗi người trong nhóm một mảng để hoạt động, nhưng cũng cho nhóm quyền tự do đi khắp nơi tìm vấn đề, làm việc trực tiếp với các sĩ quan ngoài thực địa để giải các vấn đề đó, hoặc nếu cần thì đưa lên ban lãnh đạo để được sửa. Và theo anh, một điều rất thú vị là ở nhiều mặt nó rất giống việc chạy chiến lược FDE, áp dụng lên Quân đội (theo Bob, video đăng ngày 08/09/2025).

Bob nói anh và nhóm được thấy các "CEO", năm ưu tiên hàng đầu của ban lãnh đạo, là gì, và liệu có tạo được tiến triển với chúng không. Nhưng cũng là trong một thế giới mà bạn thấy có sự lệch pha giữa điều ban lãnh đạo muốn và 20 năm cách mọi thứ đã được triển khai, và cần rất lâu để thay đổi điều đó. Nhóm đang giúp họ tạo ra thay đổi đó. Anh nói anh rất mong có cơ hội tạo ra khác biệt (theo Bob, video đăng ngày 08/09/2025).

## 18. Cơ hội cho founder: khoảng trống giữa năng lực và adoption

Jared đặt câu hỏi mà theo anh podcast rất thích hỏi khách mời: Bob nghĩ đâu là những cơ hội tốt nhất cho founder startup vào lúc này (lúc video đăng ngày 08/09/2025)?

Bob nói theo anh câu trả lời quay lại đúng câu hỏi vì sao AI agent đang theo chiến lược FDE. Nếu lùi lại nhìn toàn cảnh, và đội "chiếc mũ nghiên cứu AI" lên một lần trong podcast này, thì điều anh và mọi người đã thấy là các cải thiện về năng lực (capability) thật ra cực kỳ nhanh. Anh nói anh có nghe người ta, sau GPT-5, cảm thấy mọi thứ đang chững lại. Nhưng thật ra, nếu nhìn vào khoảng thời gian giữa tháng 4/2024, với bản phát hành GPT-4o, và tháng 4/2025, với bản phát hành o3, đó là một tốc độ tiến bộ cực kỳ nhanh. Và anh nghĩ nó sẽ tiếp tục: năng lực sẽ tiếp tục tiến nhanh (theo Bob, video đăng ngày 08/09/2025; mốc thời gian và tên model là như anh nói).

Nhưng điều thật sự gây sốc, theo Bob, là adoption (mức độ áp dụng) không hề gần với mức bạn chờ đợi từ tốc độ của các năng lực đó. Thế giới trong năm năm tới sẽ trông như thế này: năng lực cứ lao lên, lao lên, lao lên, và không hiểu sao thế giới lại có cảm giác ngày càng tầm thường. Anh lấy ví dụ: bạn ngồi trong một chiếc Waymo và không nghĩ "trời ơi, chẳng có ai lái cái xe này", mà bạn nghĩ "ôi, kẹt xe, chậm quá" (theo Bob, video đăng ngày 08/09/2025).

Hình vẽ minh họa nhận định của Bob: năng lực lao lên nhanh, adoption chậm hơn nhiều, và khoảng trống ở giữa là cơ hội cho founder (không phải số liệu; theo Bob, video đăng ngày 08/09/2025).

Và theo Bob, giống như thế giới của FDE, nơi FDE lấp khoảng trống giữa sản phẩm và điều khách hàng cần, đây là thời điểm có rất nhiều chỗ để lấp khoảng trống giữa những gì năng lực thật sự làm được và những gì khách hàng có thể áp dụng (theo Bob, video đăng ngày 08/09/2025).

Bob kể lại những ngày đầu của AI: năm 2018, anh và mọi người ngồi quanh một chiếc bàn và bàn xem khi AGI được tạo ra thì sẽ trông thế nào. Người ta nghĩ: có lẽ qua một cuối tuần, nó sẽ sống dậy và chiếm lấy thế giới. Theo anh, một điều người ta đã bỏ lỡ khi đó là AI cần được áp dụng. Nó không tự xảy ra, mà cần sự khéo léo và khám phá của con người, trong khi chịu đựng rất nhiều đau đớn, để biến nó thành hiện thực. Vì vậy anh nghĩ có một lượng cơ hội khổng lồ ngoài kia: nhìn vào những năng lực đang có, và hỏi cần gì để biến chúng thành thứ thật sự hữu ích cho con người (theo Bob, video đăng ngày 08/09/2025).

Một host đưa ra một phép so sánh mà anh nói có thể hơi gượng: gần như OpenAI là product team ở "nhà", còn các startup là những FDE ngoài hiện trường, đang tìm cách đưa nghiên cứu mà OpenAI đang "nấu" ở văn phòng chính vào sử dụng thực tế (video đăng ngày 08/09/2025).

Bob nói anh nghĩ đó không phải một phép so sánh tồi chút nào. Theo anh, đó có lẽ là sự thật nền tảng của điều đang khiến cả chiến lược FDE này trở nên hấp dẫn trở lại (theo Bob, video đăng ngày 08/09/2025).

Một host khép lại tập: đó là tất cả thời gian của buổi hôm nay. Anh cảm ơn Bob đã tham gia và hẹn gặp lại mọi người lần sau.

## Nguồn và liên kết

- Tên gốc: The FDE Playbook for AI Startups with Bob McGrew
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=Zyw-YA0k3xo](https://www.youtube.com/watch?v=Zyw-YA0k3xo)

- Kênh YouTube Y Combinator (Bob McGrew, Jared Friedman, Diana Hu, Harj Taggar): [youtube.com/channel/UCcefcZRL2oaA_uBNeo5UOWg](https://www.youtube.com/channel/UCcefcZRL2oaA_uBNeo5UOWg)

- Paul Graham, "Do Things that Don't Scale" (July 2013), bài luận gốc của lời khuyên YC mà các host nhắc tới; bài có câu "At YC we use the term "Collison installation" for the technique they invented." (đọc ngày 03/11/2026): [paulgraham.com/ds.html](https://paulgraham.com/ds.html)

Nguồn: https://homus.dev/talks/the-fde-playbook-for-ai-startups-with-bob-mcgrew · cập nhật 2026-11-03