Cần FDE có phải vì sản phẩm chưa xong? Hãy xem code tùy biến đi về đâu

“Làm một cách thiển cận, tại một khách hàng và cho đúng một khách hàng, thì không phải sản phẩm, đó là dự án.” Câu đó của Thomas Otter, một nhà đầu tư, được viết vào tháng 12/2025, đúng lúc forward deployed engineer đang được gọi là nghề nóng nhất trong giới startup.

Sáu tháng trước đó, a16z đã đặt tiêu đề cho một bài phân tích là “đổi biên lợi nhuận lấy hào phòng thủ” và lập luận rằng nhiều khi phải dựa vào những dịch vụ cần nhiều nhân lực thì mới tạo được phần mềm mang tính chuyển đổi.

Hai quan điểm ấy chạm nhau ở một câu hỏi khó chịu: nếu một công ty cần cử kỹ sư ngồi tại khách thì có phải sản phẩm của họ chưa xong?

Với bạn, một developer đang muốn chuyển sang FDE, đây không phải chuyện lý thuyết của nhà đầu tư. Công ty bạn gia nhập nằm ở phía nào sẽ quyết định ba năm tới bạn học cách xây sản phẩm, hay chỉ làm outsourcing với một chức danh hợp thời hơn.

Phe bảo vệ: tự động hóa bằng AI không có bản cắm vào là chạy

Lập luận mạnh nhất cho FDE không nằm ở chuyện sản phẩm còn dở. Semafor, trong bài viết tháng 7/2025, giải thích vì sao các startup AI đang chép lại cách làm của Palantir, công ty đã phổ biến khái niệm này: với kiểu tự động hóa mạnh mà AI hứa hẹn, không có giải pháp nào cắm vào là chạy.

Thử hình dung một agent đọc hóa đơn cho doanh nghiệp. Mô hình có thể giỏi, nhưng mỗi khách có một ERP khác nhau, quy trình duyệt khác nhau, và dữ liệu nằm ở những chỗ chỉ người trong nhà mới biết. Không gói phần mềm nào tự giải quyết được những thứ đó trước khi có người đến tận nơi.

a16z đẩy lập luận đi xa hơn: thứ đổi được bằng biên lợi nhuận là một hào phòng thủ, và hào ấy đến từ việc kiểm soát nơi và cách dữ liệu của khách đi vào hệ thống. Ai ngồi cạnh khách lúc nối dữ liệu, người đó viết luật chơi. Nhìn theo cách này, FDE là một khoản đầu tư có chủ đích chứ không phải miếng vá.

Phe hoài nghi: dự án không phải sản phẩm

Otter không phủ nhận giá trị của việc ngồi tại khách. Ông lo ở chỗ khác: startup dựa quá nhiều vào FDE có nguy cơ trượt thành công ty tư vấn, và ông viết thẳng rằng quỹ của mình không rót tiền cho công ty tư vấn. Thứ ông muốn thấy là một con đường mở rộng được bằng sản phẩm.

Nỗi lo đó có cơ sở ngay trong chính bài của a16z. Bài viết thừa nhận vai trò này thường là chức năng professional services hay triển khai cũ được đặt tên mới, khi thì mang tên FDE, khi thì là implementation specialist hoặc solutions specialist.

Valletta Software ghi nhận một chi tiết cụ thể hơn: ở các hãng làm nền tảng, FDE thường báo cáo qua khối dịch vụ chứ không qua khối sản phẩm. Databricks là một ví dụ, khi đăng tuyển vị trí FDE nằm bên trong professional services. Cùng một chức danh, nhưng sơ đồ tổ chức kể hai câu chuyện khác nhau.

“Chưa xong” chưa bao giờ đồng nghĩa với thất bại

Chính Otter lại đưa ra lý lẽ để gỡ nút thắt. Nhìn lại thời phần mềm doanh nghiệp đời đầu, ông nhớ rằng lúc giao cho khách, sản phẩm vẫn còn đang phát triển chứ chưa phải thành phẩm. Ông gọi việc đánh đồng “đang phát triển” với thất bại là một hiểu lầm phổ biến.

Vì thế câu hỏi ở tiêu đề thực ra đặt sai chỗ. Sản phẩm cần FDE gần như chắc chắn là chưa xong, và điều đó chẳng có gì đáng xấu hổ. Câu hỏi đúng là: mỗi lần FDE ra hiện trường, sản phẩm có tiến gần hơn tới “xong” hay không?

Phép thử nằm ở chỗ code đi về đâu

Valletta đưa ra một phép thử dễ dùng. Sau mỗi lần triển khai, hãy ghi lại cái gì đã phải tùy biến và vì sao, rồi đẩy nửa dùng lại được vào sản phẩm lõi. Đội nào bỏ qua bước này, theo họ, thực chất chỉ là một đội professional services khoác áo kỹ sư.

Một bài essay trên Substack tháng 7/2026 nói gần giống: thứ tách FDE khỏi dịch vụ tư vấn đắt tiền với chức danh đẹp hơn là một quyết định thiết kế nội bộ, không phải cái tên.

Nối với hai ghi nhận của Valletta, có thể suy ra quyết định ấy xoay quanh hai câu hỏi: FDE báo cáo cho ai, và quy trình có bắt buộc bước đưa ngược về lõi hay không.

Hai câu hỏi đó dính vào nhau. Một kỹ sư nằm dưới khối dịch vụ, như mô hình Valletta mô tả ở các hãng nền tảng, dễ được đo bằng việc khách go-live hơn là bằng code đã vào sản phẩm. Đó là suy luận, nhưng nó giải thích vì sao sơ đồ tổ chức đáng xem ngang với chức danh.

Quay lại ví dụ agent đọc hóa đơn, giả sử công ty có ba khách. Ở khách thứ nhất, FDE viết một bộ chuyển đổi cho định dạng ERP của họ, ghi chú phần nào đặc thù và tách phần đọc file chung thành connector trong sản phẩm. Đến khách thứ ba, nếu dùng cùng loại ERP, việc tích hợp chỉ còn là cấu hình.

Đội dịch vụ trá hình sẽ đi con đường khác: ba khách, ba nhánh code, ba người duy nhất hiểu từng nhánh. Doanh thu vẫn có, khách vẫn hài lòng, nhưng khách thứ mười tốn công gần bằng khách thứ nhất. Đó chính là kịch bản Otter gọi là dự án chứ không phải sản phẩm.

Khía cạnh	FDE như chiến lược sản phẩm	Dịch vụ đổi tên thành FDE
Tuyến báo cáo	Gắn với sản phẩm, để phần dùng lại được có đường về lõi	Qua khối services, như Valletta ghi nhận ở hãng nền tảng
Sau mỗi lần triển khai	Ghi lại phần tùy biến, đưa phần dùng lại được vào lõi	Code riêng nằm lại ở khách
Lợi thế tích lũy	Kiểm soát cách dữ liệu đi vào hệ thống	Quan hệ với từng khách, khó nhân rộng
Khách thứ mười so với khách đầu	Nhanh hơn rõ rệt nhờ module chung	Tốn công gần như cũ
Góc nhìn nhà đầu tư	Đổi biên lợi nhuận lấy hào phòng thủ	Một công ty tư vấn, khó gọi vốn

Đọc JD như đọc sơ đồ tổ chức

Nhiều developer Việt Nam đã đi qua môi trường outsourcing và hiểu rõ cảm giác code cho một khách rồi để nó nằm lại đó. Nếu bạn chuyển sang FDE để thoát vòng ấy, hãy kiểm tra trước khi ký, đừng để chức danh quyết định thay bạn.

Trong JD, tìm hai dòng. Dòng thứ nhất là vị trí báo cáo cho ai: product, engineering hay services. Dòng thứ hai là có nhắc việc đóng góp ngược vào sản phẩm lõi, viết connector hay module dùng chung hay không. Một JD chỉ toàn “triển khai”, “hỗ trợ khách hàng”, “đảm bảo go-live” mà không nói gì về sản phẩm thường đang tả một vai trò dịch vụ.

Trong phỏng vấn, hỏi cụ thể: phần việc FDE làm tại khách gần đây có gì đã thành tính năng chung? Câu trả lời mơ hồ cũng là một câu trả lời.

Còn trên CV, đừng chỉ ghi “triển khai cho khách X”. Hãy viết theo đúng phép thử của Valletta: bạn làm gì riêng cho khách, bạn nhận ra phần nào lặp lại, và bạn đã biến nó thành thứ đội khác dùng lại ra sao.

Cách viết ấy cho nhà tuyển dụng thấy bạn hiểu FDE như một chiến lược sản phẩm, chứ không phải kiểu làm dự án mà Otter lo ngại.

Cuộc tranh luận giữa các nhà đầu tư rồi sẽ ngã ngũ bằng số liệu tăng trưởng của từng công ty. Với một kỹ sư, có một tín hiệu đến sớm hơn nhiều: mở git log, xem code bạn viết tại khách tháng trước giờ đang nằm ở đâu.