Hai phần ba công việc triển khai của chúng tôi hiện được thực hiện tự động bởi chính sản phẩm của chúng tôi (thông qua Duet).
Bài viết này bàn về lý do tại sao lại như vậy, triết lý của chúng tôi trong việc xây dựng sản phẩm + phương thức triển khai, và cách điều đó đã phát triển theo thời gian.
Thứ mà chúng ta từng coi thường giờ đã trở thành câu trả lời mặc định
"Kỹ sư triển khai tiền phương" (Forward Deployed Engineer – FDE) đã trở thành câu trả lời cho gần như mọi câu hỏi khó trong việc đưa AI ra thị trường. Triển khai gian nan? Thuê FDE. Khách hàng không thể tự dùng? FDE. Sản phẩm chưa sẵn sàng? FDE. Anthropic và OpenAI đều đã thành lập các bộ phận triển khai doanh nghiệp được xây dựng theo mô hình của Palantir, và mọi công ty giai đoạn hạt giống mà tôi trao đổi hiện đều có tin tuyển dụng FDE. Các tin tuyển dụng cho vị trí này được báo cáo là đã tăng vài trăm phần trăm trong năm qua.
Điều kỳ lạ là cho đến rất gần đây, đây vẫn là điều bạn bị chỉ trích. Việc đưa kỹ sư vào làm việc tại khách hàng từng bị xem là dấu hiệu cho thấy bạn không có sản phẩm thực sự: doanh thu của bạn kém chất lượng hơn, và biên lợi nhuận của bạn bị giới hạn về mặt cấu trúc. Nhưng không có gì thay đổi về mặt kinh tế cơ bản.
Điểm mấu chốt của FDE là họ mang lại kết quả. Điều này rất tuyệt trong thời đại AI, vì doanh nghiệp có thể không chắc chắn con đường để đạt được kết quả là gì, nhưng rõ ràng là AI tạo ra những kết quả hấp dẫn.
Đồng thời, vai trò này đang bị lạm dụng và không nên trở thành cái nạng để che giấu một vấn đề cấu trúc.
"FDE ăn đau khổ và thải ra sản phẩm"
Palantir (nơi đồng sáng lập @AshwinSreenivas của tôi từng làm việc) đã phổ biến vai trò này vào giữa những năm 2000 khi bán Gotham cho CIA, NSA và các đơn vị tình báo Lục quân. Và họ đã hứng chịu chỉ trích trong một thời gian dài. Joe Lonsdale, một trong những đồng sáng lập, từng viết rằng trong gần hai thập kỷ, quan điểm chủ đạo về Palantir là một công ty tư vấn hào nhoáng hơn là một công ty công nghệ thực thụ, và quan điểm đó dựa trên một quan sát có thật: rất nhiều kỹ sư của họ đã dành rất nhiều thời gian ngồi cùng khách hàng.
Nhưng Shyam Sankar, CTO của Palantir, có một câu nói ông lặp lại liên tục: FDE ăn đau khổ và thải ra sản phẩm.
Các đợt triển khai Gotham đầu tiên của Palantir mang tính đặt riêng sâu sắc, được xây dựng để trả lời một câu hỏi tình báo cho một đơn vị duy nhất. Palantir đã mã hóa những vấn đề họ gặp phải thành các nguyên thủy của nền tảng: ontology, mô hình đối tượng, phân quyền, bộ máy quy trình làm việc, theo dõi nguồn gốc. Những nguyên thủy đó trở thành Foundry. Foundry trở thành thứ có thể bán thương mại. Apollo và AIP cũng đi theo con đường tương tự.
Không điều nào trong số đó có thể tồn tại nếu không có các kỹ sư ăn đau khổ tại hiện trường trước tiên. Cơn đau chính là nguyên liệu đầu vào của sản phẩm, không phải là chi phí bán hàng.
Khi Foundry trưởng thành, các quy trình triển khai chuẩn hóa đã giảm mạnh nhu cầu làm việc tùy chỉnh, biên lợi nhuận gộp tăng lên mức 80%, và Palantir chuyển từ mô hình do FDE dẫn dắt sang bán hàng theo tài khoản. Nhiều FDE trong số đó đã chuyển sang bộ phận kỹ thuật cốt lõi. Họ cũng nổi tiếng với việc từ chối những hợp đồng mà khách hàng chỉ muốn một Accenture với phần mềm tốt hơn.
Đội FDE không phải là mô hình kinh doanh. Nó là cách để xây dựng sản phẩm đúng đắn.
Tại sao một số startup AI thực sự cần FDE ngay lúc này
Nếu bạn xây dựng một SaaS CRM vào năm 2015, bạn không cần phải khám phá quy trình làm việc. Hai mươi năm con người đã suy nghĩ thấu đáo về pipeline là gì, một giai đoạn là gì, bàn giao khách hàng tiềm năng trông như thế nào.
Nếu bạn đang xây dựng một AI agent cho kế toán vào năm 2026, sẽ không có quy trình làm việc nào được thiết lập sẵn, vì thực sự chưa từng có ai sử dụng những thứ như thế này. Không ai biết hành trình người dùng trông như thế nào — không phải bạn, và quan trọng là, cũng không phải khách hàng của bạn. Họ không thể nói cho bạn biết họ muốn gì, vì thứ họ muốn vẫn chưa có hình dạng.
Đó cũng chính là tình huống mà Palantir đã bắt đầu. Lonsdale lý giải rằng họ chọn mô hình triển khai tiền phương xuất phát từ sự cần thiết: họ có công nghệ mạnh nhưng không biết khách hàng quốc phòng và tình báo thời kỳ đầu thực sự vận hành như thế nào.
Vì vậy, đúng vậy, hãy cử kỹ sư đến. Ngồi trong phòng. Chứng kiến sản phẩm của bạn hỏng theo những cách mà các bài kiểm tra của bạn không bao giờ tưởng tượng ra. Trong một danh mục thực sự mới, chặng cuối không phải là bài toán giao hàng, mà là bài toán khám phá, và không gì có thể thay thế cho việc có mặt ở đó.
Cái bẫy không phải là không bắt đầu. Mà là không dừng lại.
Một khi bạn đã biết hành trình người dùng thực sự là gì, bạn nên bắt đầu rút FDE ra.
Bạn sẽ không muốn làm điều đó. Không phải vì ai đó đưa ra quyết định tồi, mà vì giữ họ lại dễ dàng hơn trong từng sprint.
FDE cho phép bạn né tránh mọi sự đánh đổi khó khăn về sản phẩm. Bạn không bao giờ phải quyết định sản phẩm làm gì, hoặc yêu cầu nào trong hai yêu cầu của khách hàng thắng, hoặc ranh giới cấu hình kết thúc ở đâu. Cảm giác rất thoải mái. Không ai phải từ chối ai. Không có quyết định kiến trúc đau đầu nào được đưa ra. Khách hàng hài lòng.
Và giờ bạn đã nhận mọi nhược điểm của mô hình mà không có lợi ích khám phá nào. Chi phí phục vụ không giảm. Biên lợi nhuận vẫn bị giới hạn. Tăng trưởng bị giới hạn bởi tốc độ tuyển dụng. Mỗi bản vá tùy chỉnh tại hiện trường là một quyết định sản phẩm mà bạn đã chọn không đưa ra. Mỗi lần triển khai nên giúp lần triển khai tiếp theo dễ dàng hơn.
Trên hết, rất ít startup có thể chốt được những hợp đồng 8 con số như Palantir đã có ngay từ đầu, điều này khiến bài toán kinh tế càng khó duy trì hơn.
Một điều nữa đừng nhầm lẫn
FDE cũng không giống với triển khai kỹ thuật (implementation). "Xây dựng tích hợp này vào hệ thống ticketing của họ" là công việc thực tế, cần thiết, nhưng đó là thực thi theo một bản spec đã biết, không phải khám phá một spec chưa biết. Gộp cả hai dưới một chức danh là cách các công ty tự thuyết phục mình rằng một bộ phận dịch vụ đang phát triển là một khoản đầu tư vào sản phẩm.
Các mô hình giờ viết code đủ tốt đến mức phần lớn những gì một đội triển khai kỹ thuật làm vào năm 2023 đang trở thành thứ mà sản phẩm tự làm. Cuối cùng, bạn sẽ có thể xây dựng một agent có thể thực hiện tất cả công việc chặng cuối từ đầu đến cuối. Nó có thể quan sát quy trình làm việc và thậm chí phỏng vấn khách hàng.
Điều chúng tôi đã làm thay vào đó
Trong trường hợp cụ thể của chúng tôi với @DecagonAI, chúng tôi tin tưởng cơ bản rằng cách tiếp cận dẫn dắt bởi sản phẩm là câu trả lời, thay vì dẫn dắt bởi dịch vụ hay FDE. Chăm sóc khách hàng là công việc có khối lượng lớn, lặp đi lặp lại và có thể phân rã, và khi chúng tôi trao đổi với doanh nghiệp, hai điều luôn nhất quán:
- Tốc độ lặp lại là chìa khóa. Ra mắt một AI agent không phải việc một lần. Nó liên tục cần được tinh chỉnh và cập nhật theo thời gian. Nếu mỗi lần chỉnh sửa đều cần đến kỹ sư, sẽ quá chậm và quá đắt để mở rộng quy mô.
- Khóa chặt nhà cung cấp và quyền tự chủ. Xuất phát từ trải nghiệm của các tổ chức với SaaS, không ai muốn bị khóa chặt vào một nhà cung cấp và phụ thuộc vào nguồn lực của họ.
Trong những ngày đầu, Ashwin và tôi sẽ trực tiếp xây dựng bất cứ thứ gì khách hàng yêu cầu. Khi sản phẩm bắt đầu cất cánh, chúng tôi đưa ra quyết định rõ ràng rằng đề xuất giá trị cốt lõi của chúng tôi là sở hữu sản phẩm tốt nhất.
Để nói rõ, chúng tôi vẫn đồng hành cùng khách hàng để mang lại kết quả cuối cùng từ đầu đến cuối. Tuy nhiên, trong suốt quá trình đó, chúng tôi là bên sở hữu việc xây dựng, đồng thời trang bị cho đội ngũ của họ những kiến thức về sản phẩm và trao cho họ chìa khóa. Khi sản phẩm trưởng thành, khối lượng công việc riêng cho từng khách hàng mà đội ngũ kỹ thuật của chúng tôi phải làm đã giảm đi đáng kể.
Quyết định đó cũng có những đánh đổi. Nó có nghĩa là không được hack một giải pháp tạm bợ tại hiện trường khi điều đó có thể nhanh hơn. Nó có nghĩa là tiếp nhận các sự cố leo thang và biến chúng thành yêu cầu sản phẩm thay vì các bản vá, điều này tốn thời gian trong ngắn hạn.
Kết quả đạt được:
- Hai phần ba công việc triển khai giờ đây diễn ra tự động thông qua Duet: cấu hình, lặp lại, phần đuôi dài của việc tinh chỉnh mà trước đây cần có con người trong vòng lặp.
- Hiện chỉ mất trung bình vài ngày để ra mắt AOP đầu tiên, ngay cả với các ngân hàng lớn, hãng hàng không, nhà mạng, v.v.
Vẫn còn nhiều việc phải làm, nhưng chúng tôi đang trên hành trình.
Vậy: dùng FDE, hay không dùng FDE?
Hãy triển khai tiền phương sớm. Thu thập tín hiệu. Đặt kỹ sư của bạn trước mặt khách hàng mãi mãi.
Sau đó hãy đặt những câu hỏi thực sự. Tính tùy biến nằm ở môi trường của khách hàng, hay ở những khoảng trống của chính sản phẩm của bạn? Chặng cuối là không thể tối giản, hay chỉ đơn giản là chưa được xây dựng? FDE của bạn đang khám phá điều gì, hay đang hấp thụ điều gì? Và điều gì đã được xây dựng vào sản phẩm trong lần cuối một trong số họ quay trở lại?
Hãy dùng FDE để tìm ra điều gì cần tồn tại trong sản phẩm. FDE ăn đau khổ và thải ra sản phẩm. Nếu FDE của bạn đang ăn đau khổ và thải ra thêm đau khổ, bạn không có một đội FDE. Bạn có một doanh nghiệp dịch vụ.
