Land and expand: FDE tìm hợp đồng thứ hai ngay trong dự án vừa giao
Cơ hội mở rộng hợp đồng thường đã có sẵn trong log sử dụng và những cách khách tự xoay xở. Việc còn lại là người kỹ sư ngồi tại chỗ biết đọc chúng.
Tóm tắt nhanh
- Việc mở rộng dựa trên niềm tin từ dự án đầu: giao tốt lát cắt hẹp trước, chỉ bàn mở rộng khi adoption đã có.
- FDE thấy được những tín hiệu mà sales không thấy: ai đang tự xoay xở, dữ liệu nào đang bị export ra ngoài, code nào dùng lại được.
- Biến code tùy biến thành thành phần dùng lại được để mỗi lần mở rộng rẻ hơn, rồi đưa cơ hội qua đội revenue.
Tuần thứ sáu ở khách hàng. Workflow bạn xây đã chạy ổn, buổi demo cuối được khen, account manager nhắn cảm ơn cả đội. Rồi bạn rút về, và ba tháng sau hợp đồng được gia hạn đúng bằng phạm vi cũ, có khi còn không được gia hạn.
Với một số công ty tuyển FDE, kết cục đó nghĩa là việc mới làm được một nửa. Tin tuyển FDE của Firecrawl viết thẳng rằng vai trò này được đo bằng adoption và expansion, không phải số ticket đã đóng.
Tin này cũng yêu cầu FDE phối hợp với đội revenue để biến kết quả kỹ thuật thành adoption và hợp đồng mở rộng. Ở những nơi như vậy, giao xong dự án đầu chưa phải là đích đến.
Nếu bạn đang nhắm vai trò FDE, kỹ năng nhìn ra hợp đồng thứ hai từ dự án thứ nhất là thứ tách bạn khỏi một kỹ sư outsource giỏi. Kỹ năng này học được, và nó bắt đầu từ việc đọc dữ liệu, không phải từ khả năng ăn nói.
Vì sao phần “expand” lại thuộc về kỹ sư?
Palantir nói chiến lược này công khai. Ryan Taylor, giám đốc doanh thu của hãng, phát biểu trong cuộc họp kết quả quý 1/2024 rằng công ty sẽ không ngừng chốt khách hàng mới rồi mở rộng các hợp tác đó khi sản phẩm bắt đầu có chỗ đứng.
Cửa vào là bootcamp. Theo Taylor, đến thời điểm đó đã có hơn 915 tổ chức tham gia. Từ cuối năm 2023, Palantir mô tả AIP bootcamp là cách đưa workflow thật chạy trên dữ liệu của khách trong 5 ngày hoặc ít hơn.
Hãng cũng cho biết bootcamp giúp có những deal lớn hơn và rút ngắn thời gian để chuyển đổi rồi mở rộng hợp đồng. Nhưng nếu cửa vào là một workflow chạy trên dữ liệu thật, hợp lý khi nghĩ rằng cơ hội mở rộng cũng lộ ra từ chính workflow ấy, tức là từ phần việc của kỹ sư.
Sales không biết phòng kho đang export cùng một file Excel mỗi sáng thứ Hai, cũng không biết connector ERP bạn viết dùng được cho ba phòng khác. Bạn biết, vì bạn ngồi trong hệ thống của khách.
Thứ tự thì không đảo được. Playbook triển khai của fde.academy cảnh báo rằng niềm tin đã mất trong những tuần đầu thì rất tốn kém để xây lại. Cũng playbook đó khuyên giao trước một lát cắt hẹp chạy được trong khoảng hai tuần, rồi mới mở rộng tính năng. Giao chắc một việc nhỏ trước, bàn mở rộng sau.
Một ví dụ: từ đối soát hóa đơn sang phòng mua hàng
Thử hình dung một công ty logistics. Dự án đầu của bạn là một agent đọc hóa đơn nhà cung cấp, đối chiếu với đơn đặt hàng trong ERP và đẩy các khoản chênh lệch cho kế toán duyệt. Phạm vi được cắt hẹp có chủ đích: chỉ hóa đơn vận tải nội địa, chỉ một phòng kế toán.
Bốn tuần sau go-live, việc đầu tiên là mở log. Giả sử 20 kế toán được cấp quyền và 15 người dùng hằng tuần, tức adoption 75%. Đó là nền đủ vững để bắt đầu nói chuyện mở rộng. Nếu chỉ có 4 trên 20 người dùng, việc của bạn là sửa adoption, chưa phải bán thêm.
Tín hiệu thứ hai là workaround. Bạn để ý trưởng phòng mua hàng nhờ một kế toán export danh sách chênh lệch mỗi thứ Hai để mang đi đàm phán với những nhà cung cấp hay tính sai. Đó là một người dùng mà hợp đồng không tính tới, nhưng đã tự tìm đến sản phẩm.
Tín hiệu thứ ba nằm trong code. Parser hóa đơn và connector ERP đã có sẵn. Hóa đơn vận tải quốc tế đi qua cùng ERP, chỉ khác định dạng và tiền tệ.
Lát cắt thứ hai vì thế rẻ hơn hẳn lát cắt đầu, đúng cơ chế mà playbook của fde.academy mô tả: phần việc tùy biến một lần dần được chuẩn hóa thành tính năng dùng lại được.
Gom ba tín hiệu đó vào một bảng là bạn đã có tài liệu để đưa cho account manager:
| Tín hiệu | Thấy ở đâu | Câu hỏi kiểm chứng | Người cần biết |
|---|---|---|---|
| Adoption 15/20 kế toán | Log sử dụng hằng tuần | Ai chưa dùng, vì sao? | Trưởng phòng kế toán |
| Mua hàng tự export mỗi thứ Hai | Yêu cầu xin file, email chuyển tiếp | Họ dùng file để quyết định gì? | Trưởng phòng mua hàng |
| Hóa đơn quốc tế cùng ERP | Schema dữ liệu, connector sẵn có | Cần thêm gì ngoài định dạng mới? | Đội revenue, kỹ sư nội bộ |
Bước tiếp theo là buổi review với khách, và ở đây cách đặt câu hỏi rất quan trọng. Đừng mở đầu bằng “bên em làm thêm được phần quốc tế”. Hãy hỏi về vấn đề:
Em thấy chị bên mua hàng lấy file chênh lệch mỗi tuần. Chị dùng nó để làm gì, và hiện mất bao lâu?
Nếu câu trả lời là hai buổi chiều mỗi tuần ngồi ghép số liệu tay, bạn vừa có một vấn đề được định lượng. Bạn mang nó về cho đội revenue chứ không hứa phạm vi ngay tại bàn.
Tự làm trong năm bước
Bước đầu tiên làm ngay từ lúc scoping: chọn lát cắt hẹp và ghi lại những workflow lân cận bạn chủ động để ngoài phạm vi. Danh sách đó là bản đồ mở rộng tương lai, và nó giúp bạn từ chối scope creep mà khách không mất lòng.
Sau go-live, đo adoption theo tuần bằng số người dùng thật trên số người được cấp quyền, không phải bằng số tính năng đã giao. Song song, ghi lại mọi workaround: file export, bước copy tay, những người hay nhờ người khác lấy kết quả hộ.
Khi viết code, tách phần chung (connector, parser, eval) khỏi phần riêng của khách. Đây là khoản đầu tư khiến lát cắt thứ hai rẻ hơn, và cũng là thứ đội sản phẩm cần để chuẩn hóa thành tính năng.
Đến lúc adoption đã vững, điền bảng tín hiệu, kiểm chứng từng dòng bằng một câu hỏi về vấn đề, rồi chuyển cho account manager hoặc đội revenue. Họ lo ngân sách, hợp đồng và người ký. Phần của bạn là bằng chứng kỹ thuật và ước lượng công sức.
Cuối cùng, khi lát cắt thứ hai được duyệt, lặp lại đúng chu trình: hẹp, giao nhanh, đo, tìm tín hiệu tiếp theo.
Những lỗi làm cơ hội biến mất
Lỗi đầu tiên là mở lời quá sớm. Đề nghị mở rộng khi mới có 4 trên 20 người dùng thì chỉ khiến khách nghĩ bạn đang lo bán hàng hơn là lo cho họ, và lúc đó niềm tin bắt đầu mòn đi.
Lỗi thứ hai là tự hứa phạm vi. Một câu “cái này bên em làm thêm nhanh thôi” nói trong buổi họp có thể phá cả chiến lược giá của đội revenue, và đội bạn sẽ phải làm thêm mà không ai trả tiền.
Lỗi thứ ba khó thấy hơn: mở rộng bằng cách copy-paste code tùy biến. Lát cắt thứ hai khi đó không rẻ hơn, nợ kỹ thuật nhân đôi, và đến lát cắt thứ ba thì không ai muốn động vào nữa.
Lỗi cuối là chỉ nói chuyện với người dùng. Kế toán yêu sản phẩm của bạn không có nghĩa là trưởng phòng mua hàng biết nó tồn tại. Người có vấn đề và người có ngân sách thường là hai người khác nhau.
Đưa kỹ năng này vào CV
Nhu cầu tuyển đang rất nóng: dữ liệu Indeed cho thấy tin tuyển các vị trí applied AI tăng hơn 800% từ tháng 1 đến tháng 9/2025. Khi đọc JD, hãy tìm các cụm như “adoption”, “expansion” hay “partner with revenue team”. Chúng cho bạn biết công ty sẽ đánh giá bạn theo tiêu chí nào.
Trong CV, thay “xây pipeline đối soát hóa đơn” bằng một dòng có số: “đưa 15/20 kế toán dùng hằng tuần sau bốn tuần; phát hiện nhu cầu của phòng mua hàng, mở ra lát cắt thứ hai dùng lại connector sẵn có”. Dù bạn đang làm outsource hay sản phẩm nội bộ, dự án nào cũng có log sử dụng và workaround để kể.
Giao tốt dự án đầu mới chỉ là điều kiện cần. Từ dự án tới, hãy tập nhìn ra dự án thứ hai trước khi khách kịp nghĩ tới nó.
Bài này có hữu ích không?
Cảm ơn bạn đã góp ý!
5 nguồn
- Palantir Technologies (PLTR) Q1 2024 Earnings Call Transcript (Motley Fool) · 2024-05-06
- Palantir's commercial business scales with help of AI boot camps · 2023-11-02
- Forward Deployed Engineer - Revenue (Firecrawl, Built In LA)
- The Forward Deployed Engineer Playbook: How Top FDEs Approach a New Deployment · 2026-06-16
- OpenAI, Anthropic hire engineers who can code and communicate with customers · 2025-11-03