# FDE lo "how", PM lo "what": cách tách một blocker ở khách hàng làm hai

> OpenAI đang tuyển Deployed PM cho Codex, một PM ngồi ngay trong tài khoản khách hàng. Vai trò này cho FDE thấy rõ phần nào mình tự sửa, phần nào phải mang về cho đội product.

Bản gốc: https://fdetimes.net/vi/bach-khoa/fde-vs-product-manager-fdpm/

Thử hình dung bạn đang ở tuần thứ ba của một đợt deployment. Integration đã chạy, dữ liệu đã thông, rồi trưởng nhóm kỹ thuật bên khách hàng hỏi: "Sao sản phẩm của các anh không làm được việc này?" Bạn có hai lựa chọn: tự viết thêm vài trăm dòng code để lấp chỗ trống, hoặc nói "để tôi chuyển cho đội product".

Cả hai câu trả lời đều có thể đúng, và cũng đều có thể sai. Muốn biết lúc nào nên làm gì, bạn cần hiểu ranh giới giữa FDE và Product Manager. OpenAI là một ví dụ đáng xem: công ty này đang tuyển một vai trò nằm ngay trên ranh giới đó, Deployed Product Manager cho Codex.

## Ai trả lời câu hỏi "vì sao"?

Scaler tách hai vai trò bằng thước đo thành công. FDE được đánh giá theo việc deployment có chạy hay không, còn PM theo việc đội đã xây đúng thứ cần xây hay chưa. Theo cách chia đó, PM quyết định làm gì và vì sao, còn FDE làm cho nó vận hành được trong thực tế của khách hàng.

Mind the Product áp phép chia này vào hẳn bên trong khách hàng. Forward Deployed PM (FDPM) là PM do vendor tuyển nhưng làm việc ngay trong tổ chức của khách hàng: thuộc một công ty, nhưng được nhúng vào công ty khác. Thay vì sở hữu một sản phẩm, họ sở hữu kết quả ở một tài khoản.

Khi làm cạnh nhau, FDPM giữ phần "what" và "why" của tài khoản đó, còn FDE lo phần dựng kỹ thuật. FDPM cũng mang điều học được về cho đội làm sản phẩm lõi, để các khách hàng khác cùng hưởng lợi.

Câu hỏi của trưởng nhóm kỹ thuật ở trên thật ra chứa cả hai phần. "Làm sao cho nó chạy" là việc của bạn. "Có nên làm không, và vì sao" là một quyết định về product.

## JD của OpenAI gợi ý gì về khoảng trống?

OpenAI mô tả đội Forward Deployed Engineering là đội làm cùng khách hàng để biến đột phá nghiên cứu thành hệ thống chạy production. JD cho vị trí quản lý đội này còn yêu cầu đóng gói những gì hiệu quả thành công cụ, playbook và đầu vào cho roadmap. Nghĩa là FDE ở đây vốn đã phải mang bài học từ khách hàng về cho sản phẩm.

JD Deployed PM không nêu lý do vì sao vị trí này ra đời. Nhưng đọc nó cạnh JD của đội FDE, có thể suy ra một cách hợp lý: mang bài học về là việc tốn sức, và khó có kỹ sư nào vừa debug pipeline lúc nửa đêm vừa viết được bản phân tích product chỉn chu. Đó là suy luận, không phải lời OpenAI nói.

Điều JD nói rõ là người này đóng vai product lead bên trong các tài khoản khách hàng chiến lược, giúp khách hàng dùng và mở rộng việc dùng sản phẩm OpenAI. Họ làm việc sát với Deployment Engineer và đội GTM, đồng thời chuyển nhu cầu cùng blocker kỹ thuật của khách hàng thành feedback sản phẩm và hướng thực thi rõ ràng cho các đội nội bộ.

**Điểm mấu chốt:** FDE làm cho sản phẩm chạy được ở khách hàng; người làm product quyết định sản phẩm có nên thay đổi hay không.

## Một blocker, hai câu hỏi

Hãy hình dung một tình huống cụ thể. Bạn đang triển khai một coding agent cho một công ty có hàng trăm repo nội bộ. Pull request do agent tạo liên tục bị CI chặn vì công ty có bộ quy tắc lint riêng mà agent không biết.

Câu hỏi "how" thuộc về bạn. Bạn có thể nạp file cấu hình lint vào context của agent, thêm một bước tự format trước khi mở PR, rồi đo tỷ lệ PR qua CI trước và sau khi sửa. Đến cuối tuần, deployment chạy được, và đó đúng là điều FDE được đánh giá.

Câu hỏi "what/why" thì chưa ai trả lời. Đây là chuyện riêng của một khách hàng, hay khách hàng doanh nghiệp nào cũng sẽ gặp? Nếu bạn dừng ở bước sửa xong, đội product sẽ không bao giờ biết vấn đề này tồn tại.

PostHog chỉ ra vì sao khoảng trống này tự sinh ra: FDE làm discovery và phát triển với một khách hàng mỗi lần, tính tổng quát chỉ đứng thứ hai. Việc khái quát hóa bài học cho các khách hàng khác thuộc về đội sản phẩm lõi, và họ chỉ làm được khi bài học đến tay họ.

## Làm sao biết vấn đề có lặp lại?

Handbook FDE của Agile Lab mô tả một thói quen đáng chép: mỗi khi ghi nhận vấn đề của khách, kỹ sư tạo một mục công việc có thể truy vết, nêu vấn đề, giá trị cho khách và kết quả kỳ vọng. Chính các mục này biến câu hỏi "có lặp lại không" thành một phép tìm kiếm, thay vì một cảm giác.

Cách làm cụ thể, nếu đội bạn dùng Jira, Linear hay bất kỳ tracker nào: gắn cho mỗi mục một tag theo loại vấn đề, ví dụ `ci-policy` hay `repo-conventions`, cùng tên tài khoản. Khi gặp blocker lint, bạn lọc theo tag đó và đếm số tài khoản khác nhau đã có mục tương tự.

Nếu tracker chưa có gì, hãy hỏi thẳng trong kênh chat chung của các FDE: "Có ai gặp agent bị CI chặn vì quy chuẩn repo riêng chưa?" Hai, ba câu trả lời "có" là đủ để ghi chú của bạn chuyển từ phàn nàn của một khách thành giả thuyết đáng xem xét.

Khi đã có số đếm, ghi chú gửi về nên ngắn và có cấu trúc:

```text
Blocker: PR của agent bị CI chặn vì quy tắc lint nội bộ
Tác động: [số PR bị chặn / tổng PR trong 1 tuần — số đo thật]
Workaround tạm: nạp config lint vào context + bước format trước khi mở PR
Lặp lại: [số tài khoản có mục cùng tag ci-policy]
Đề xuất cho product: cho phép khai báo quy chuẩn repo ở cấp tổ chức
```

Nếu công ty có Deployed PM, ghi chú này chính là thứ họ cần để bắt tay vào việc. Nếu không có, nó là phần việc product mà bạn đang phải tự gánh.

## Tự làm: tách "how" khỏi "what" trong mỗi buổi họp

Bắt đầu bằng thói quen ghi chép hai cột. Mỗi vấn đề khách hàng nêu ra, bạn ghi vào một trong hai: việc cần làm để hệ thống chạy, và câu hỏi về việc sản phẩm có nên khác đi không. Đa số vấn đề có phần ở cả hai cột.

Giải quyết cột "how" thật nhanh rồi đo kết quả, vì đó là thước đo của bạn. Với cột "what/why", tạo mục công việc có tag, tìm các mục cùng tag trước khi viết đề xuất, rồi gửi ghi chú cho Deployed PM nếu có, hoặc PM phụ trách mảng đó, kèm ngày xem lại.

Handbook của Agile Lab gọi mục đích của cả quy trình này là rút ngắn vòng phản hồi giữa bằng chứng từ khách hàng và đội kỹ thuật sản phẩm.

## Những lỗi hay gặp

Lỗi phổ biến nhất là biến workaround thành sản phẩm riêng. FDE giỏi code dễ xây cả một lớp tính năng chỉ chạy được ở một khách hàng, rồi lớp đó thành gánh nặng bảo trì không ai sở hữu. Lỗi ngược lại là đẩy hết cho product, kể cả việc bạn tự sửa được trong một buổi chiều, khiến khách hàng mất niềm tin.

Lỗi thứ ba khó nhận ra hơn: gửi feedback kiểu "khách hàng muốn tính năng X". Câu đó không có tác động, không có workaround, không có số tài khoản gặp cùng vấn đề. Đội product đọc xong không thể ra quyết định gì.

## Nghề nào cho bạn?

Khi đọc JD, hãy tìm các cụm như "partner closely with Deployment Engineers" hay "product feedback". Chúng cho biết bạn sẽ có đối tác phía product, hay phải tự gánh cả hai cột. Với JD FDE, những cụm như "roadmap inputs" báo hiệu vòng phản hồi về sản phẩm là một phần công việc được đánh giá.

Dù bạn đi hướng nào, kỹ năng viết ghi chú như mẫu ở trên đều có giá trị. Trong CV, hãy kể một lần bạn đưa một blocker ở khách hàng thành một thay đổi trong sản phẩm, có số đo trước và sau, và số khách hàng được hưởng lợi.

Câu hỏi "sao sản phẩm không làm được việc này" sẽ còn được hỏi lại ở mọi khách hàng. Người được tin tưởng là người biết khi nào nên tự sửa, và khi nào cần mang vấn đề về cho đội product quyết định.

**Thử ngay tuần này:**

- Lấy blocker gần nhất bạn gặp ở khách hàng và viết lại theo mẫu năm dòng trong bài, tách riêng workaround và đề xuất cho product
- Tìm trong ticket tracker của đội các mục cùng loại với blocker đó và đếm xem nó xuất hiện ở bao nhiêu khách hàng
- Thêm vào CV một dòng kể chuyện bạn từng đưa một vấn đề ở khách hàng thành một thay đổi trong sản phẩm

## Nguồn

- [What is a Forward Deployed Product Manager, anyway?](https://www.mindtheproduct.com/what-is-a-forward-deployed-product-manager-anyway/)

- [Deployed Product Manager, Codex @ OpenAI](https://jobs.khoslaventures.com/companies/openai/jobs/76966806-deployed-product-manager-codex)

- [Manager, Forward Deployed Engineering - OpenAI](https://www.builtinnyc.com/job/manager-forward-deployed-engineering/9872042)

- [Forward Deployed Engineer vs Product Manager: Where the Roles Split (and the Rise of the FDPM)](https://www.scaler.com/topics/forward-deployed-engineer-vs-product-manager/)

- [WTF is a forward deployed engineer? (and why everyone is hiring them)](https://posthog.com/blog/forward-deployed-engineer)

- [Forward-Deployed Engineering](https://handbook.agilelab.it/Witboost_ProductDevelopment_ForwardDeployedEngineering.html)