# Khách nói dashboard chậm, nhưng thứ họ thiếu là conversion: bài học discovery của FDE > Kevin B., FDE tại Rippling, gọi lời phàn nàn của khách là triệu chứng; việc của bạn là tìm ra căn bệnh trước khi viết dòng code đầu tiên. Bản gốc: https://fdetimes.net/vi/bach-khoa/customer-discovery/ Một khách hàng phàn nàn dashboard tải chậm. Phản xạ của kỹ sư giỏi là mở profiler, soi query, thêm cache. Nhưng nếu thứ khách thật sự cần là conversion, thì độ trễ chỉ là triệu chứng, và một FDE có thể đốt trọn engagement vào việc gọt từng mili giây mà không chạm tới mục tiêu nào của khách. Kevin B., FDE tại Rippling, gói bài học đó trong một câu: vấn đề hiếm khi là vấn đề. Theo anh, điều khách hàng kể cho bạn nghe chính là triệu chứng. Nếu bạn đang muốn chuyển sang FDE, đây là kỹ năng tách bạn khỏi một kỹ sư nhận ticket. Khóa học FDE của Educative gọi discovery là một cuộc điều tra kỹ thuật có cấu trúc, tiến hành dưới dạng hội thoại. Mục đích của buổi discovery là hiểu vấn đề, không phải trình diễn cách FDE sẽ giải nó. ## Ba cách khách hàng che mất vấn đề thật Educative lưu ý rằng khách hiếm khi mô tả ràng buộc thật của họ ngay trong buổi nói chuyện đầu tiên. Thay vào đó, họ mở đầu bằng một triệu chứng, một giải pháp đã chọn sẵn, hoặc một kết quả chung chung. Cả ba đều là điểm xuất phát hợp lệ, nhưng không cái nào là spec. Quay lại dashboard. "Tải chậm" là triệu chứng. "Cần thêm một lớp cache" là giải pháp chọn sẵn. "Muốn tăng doanh thu quý này" là kết quả chung chung. Ba câu đó có thể đến từ cùng một người trong cùng một cuộc họp, và nếu bạn nhận bất kỳ câu nào làm đề bài, bạn đang xây thứ dễ ticket nhất chứ không phải thứ đúng nhất. Vì thế Educative mô tả công việc của FDE là lần ngược từ lời mô tả đó về vấn đề workflow nằm bên dưới. Thử hình dung bạn hỏi tiếp: ai mở dashboard, vào lúc nào, họ làm gì sau khi nhìn số. Câu trả lời có thể hé lộ rằng đội sales chỉ nhìn dashboard mỗi sáng để quyết định gọi ai trước, và cái chậm thật sự không nằm ở query mà ở chỗ dữ liệu lead đến muộn nửa ngày. **Điểm mấu chốt:** Lời phàn nàn của khách là nơi cuộc điều tra bắt đầu, không phải nơi spec kết thúc. ## Workaround là bản đồ dẫn tới nỗi đau Có một manh mối đáng giá hơn mọi lời phàn nàn: thứ người dùng tự làm khi quy trình chính thức không chạy. Educative gọi workaround là tín hiệu rõ nhất về nơi nỗi đau vận hành thật sự nằm. File Excel xuất tay mỗi sáng, kênh Slack để hỏi số liệu, một đồng nghiệp được giao "canh" dashboard: mỗi thứ đó là một bản đồ vẽ sẵn, chỉ chờ bạn đọc. Để đọc được, câu hỏi phải đổi hướng. Nguyên tắc đầu tiên của The Mom Test, cuốn sách của Rob Fitzpatrick mà Yevgeniy Brikman điểm lại, là nói về cuộc sống của họ thay vì ý tưởng của bạn. Nguyên tắc tiếp theo: hỏi về những chuyện cụ thể trong quá khứ thay vì ý kiến chung chung về tương lai. Khác biệt nghe nhỏ nhưng quyết định chất lượng bằng chứng. "Nếu dashboard nhanh hơn, anh có dùng nhiều hơn không?" chỉ thu về một lời hứa lịch sự. "Lần gần nhất dashboard chậm, anh đã làm gì tiếp theo?" thu về một hành vi đã xảy ra, và rất có thể chính là workaround bạn cần tìm. Palantir từng kỳ vọng FDE của mình làm việc tại văn phòng khách hàng ba đến bốn ngày mỗi tuần. Nabeel Qureshi, người viết lại trải nghiệm ở đó, cho rằng chính việc onsite giúp FDE nắm được hiểu biết tỉ mỉ về quy trình kinh doanh trong những ngành khó, rồi dùng hiểu biết ấy để thiết kế phần mềm giải đúng vấn đề. Workaround hiếm khi lộ ra qua một cuộc Zoom; nó lộ ra khi bạn ngồi cạnh người đang mở Excel. ## Khách sở hữu vấn đề, bạn sở hữu giải pháp Nhưng còn một điểm giằng co mà FDE phải xử lý hằng ngày: ai được quyết định cái gì. The Mom Test đặt ra một thỏa thuận: bạn không được bảo khách vấn đề của họ là gì, và đổi lại, họ không được bảo bạn phải xây cái gì. Trong khi đó, sổ tay FDE của PostHog nói rằng đôi khi việc đúng là sửa mental model của khách thay vì xây đúng thứ họ yêu cầu. Hai nguyên tắc này không mâu thuẫn, chúng chia đôi lãnh thổ. Nỗi đau là của khách: bạn không tranh cãi rằng dashboard không chậm. Giải pháp là của bạn: khi khách khăng khăng "thêm cache", bạn có quyền và trách nhiệm đặt bằng chứng lên bàn, chỉ ra rằng lớp cache sẽ không làm lead đến sớm hơn. PostHog nhấn mạnh thêm một ý: giải quyết vấn đề thật, chứ không phải vấn đề dễ ticket nhất. Cache là vấn đề dễ ticket. Thiết kế lại luồng dữ liệu lead để đội sales có số lúc tám giờ sáng là vấn đề thật, khó viết thành ticket hơn nhiều, nhưng là điều khiến khách nhớ đến bạn. ## Luyện trước khi có chức danh Bạn không cần chức danh FDE để bắt đầu. Ticket tiếp theo từ PM hay khách nội bộ là một buổi discovery thu nhỏ: trước khi code, hỏi lần gần nhất chuyện này xảy ra, họ đã xoay xở ra sao, ai dùng kết quả cuối cùng. Viết lại vấn đề bằng lời của bạn trong một đoạn và gửi cho người yêu cầu xác nhận; nếu họ sửa, bạn vừa tìm thấy khoảng cách giữa triệu chứng và vấn đề. Khi đọc job description, hãy để ý những từ như discovery, scoping, customer workflow, onsite. Gặp những từ đó, bạn nên chuẩn bị sẵn một câu chuyện về lần mình tự đi tìm đề bài thay vì nhận đề bài. Trong CV, cách kể chuyện thuyết phục nhất không phải "đã tối ưu latency 40%" mà là "yêu cầu ban đầu là X, sau khi tìm hiểu đã xây Y, vì Z". Câu đó cho người phỏng vấn thấy bạn biết phân biệt triệu chứng với căn bệnh. Ticket tiếp theo bạn nhận có thể vẫn ghi "dashboard chậm". Việc của bạn là đi tìm xem ai đang mở Excel để bù cho nó. **Thử ngay tuần này:** - Với ticket tiếp theo nhận từ PM hay khách, trước khi code hãy hỏi ba câu: lần gần nhất chuyện này xảy ra là khi nào, anh chị đã làm gì để xoay xở, ai dùng kết quả cuối cùng - Viết một đoạn problem statement bằng lời của bạn và gửi cho người yêu cầu xác nhận; nếu họ sửa, bạn vừa phát hiện khoảng cách giữa triệu chứng và vấn đề - Trong CV, viết lại một dự án theo cấu trúc: yêu cầu ban đầu là X, sau khi tìm hiểu đã xây Y, vì lý do Z ## Nguồn - [What Is a Forward Deployed Engineer? Complete 2026 Guide](https://ocpd.georgiasouthern.edu/blog/2026/08/05/what-is-a-forward-deployed-engineer-complete-2026-guide/) - [Running customer discovery (Forward Deployed Engineer course)](https://www.educative.io/courses/forward-deployed-engineer/running-customer-discovery) - [How forward deployed engineers work (PostHog Handbook)](https://posthog.com/handbook/forward-deployed-engineering/how-we-work) - [Reflections on Palantir](https://nabeelqu.substack.com/p/reflections-on-palantir) - ['The Mom Test' by Rob Fitzpatrick (review by Yevgeniy Brikman)](https://www.ybrikman.com/blog/2023/03/29/the-mom-test/)