Medplum cho FDE làm thay PM, và quy trình bắt đầu gãy khi đội FDE lớn dần

Medplum không có product manager. Rahul Agarwal, đồng sáng lập kiêm COO, nói thẳng rằng ông chưa thấy thuyết phục khi PM tồn tại như một vai trò toàn thời gian, với một kiểu hồ sơ tuyển dụng riêng.

Ở Medplum, việc của PM được giao cho FDE. Nhưng chính Agarwal cũng thừa nhận quy trình ấy “bắt đầu gãy khi quy mô tăng”.

Với developer Việt đang nhắm vào vai FDE, đây là bài học về phần việc mà mô tả công việc ít khi ghi ra: bạn không chỉ deploy cho khách hàng, bạn còn mang tiếng nói của khách hàng về cho sản phẩm.

FDE làm PM thì trông như thế nào?

Blog của Medplum viết rằng FDE là đầu vào chính cho roadmap. Đội FDE triage mọi issue, feature request và bug từ khách hàng lẫn cộng đồng, tức toàn bộ khâu tiếp nhận mà ở công ty khác thuộc về PM.

Công ty muốn FDE góp phần quyết định sản phẩm sẽ trở thành gì, chứ không dừng ở việc giúp khách dùng tốt sản phẩm đang có.

Cơ chế Agarwal kể khá đơn giản. Mỗi tuần, các yêu cầu được gom vào một bảng tính, các FDE thương lượng với nhau để ra thứ hạng ưu tiên, rồi một FDE luân phiên đứng ra trình bày với đội engineering.

Điểm gãy nằm ở ngữ cảnh, không nằm ở con số

Agarwal giải thích chỗ gãy rất ngắn gọn: khi đội đã có mười, hai mươi FDE, ticket nào cũng kéo theo quá nhiều ngữ cảnh. Nhưng không nên đọc con số ấy như một giới hạn cứng. Ông dùng nó để minh họa tình trạng quá tải, và nói sẽ sửa thiết kế chứ không coi đó là trần cố định.

Hãy thử hình dung người FDE trực tuần này phải trình bày một ticket “cần thêm bộ lọc theo ngày”. Ticket đó do một đồng nghiệp viết sau ba cuộc gọi với một khách hàng mà người trình bày chưa từng làm việc cùng. Đội engineering hỏi vì sao khách cần, khách đang xoay xở ra sao, còn ai khác cần không, và người trình bày không trả lời được.

Tuần sau đã là người khác đứng ra trình bày.

Vì thế, khi nhìn lại, Agarwal cho rằng người đóng vai PM không nên luân phiên hàng tuần. Ông gợi ý chu kỳ theo tháng hoặc theo quý, gắn với việc phân công khách hàng, để người trình bày thực sự hiểu những ticket mình mang vào phòng họp.

Bài toán khó nhất của FDE

Đổi chu kỳ luân phiên chỉ giảm bớt triệu chứng. Agarwal cho rằng vấn đề gốc vẫn còn ở mọi quy mô: theo ông, bài toán khó của FDE là giữ được ngữ cảnh khi kiến thức đi qua tay hàng trăm người.

Tandem, một công ty làm công cụ cho đội FDE, nhìn ra cùng lỗ hổng: ghi lại những gì học được ngoài hiện trường là việc thật, nó tranh thời gian với delivery, và delivery luôn thắng.

Quỹ Northzone nhìn vấn đề từ phía động lực. FDE được thúc đẩy để thắng từng khách hàng của mình, còn đội product được thúc đẩy để xây thứ dùng chung cho nhiều người. Khi FDE bị gắn với kết quả của từng account, phía account thắng: họ thôi làm trinh sát sản phẩm và trở thành account manager.

Northzone diễn đạt ý đó bằng hình ảnh những viên gạch: FDE nhặt được gạch ngoài hiện trường, nhưng nếu không ai mang chúng về cho đội product thì công ty không thực sự có một tổ chức FDE.

Developer Việt nên luyện gì từ chuyện này?

Kỹ năng Medplum đang thiếu khi lớn lên chính là kỹ năng bạn có thể luyện ngay: viết một ticket mà người chưa từng gặp khách hàng vẫn đọc hiểu và ra quyết định được.

Quay lại ví dụ bộ lọc theo ngày. Bản tệ chỉ có một dòng: “Khách X cần lọc theo ngày, ưu tiên cao.” Bản tốt, cũng chỉ năm câu, trả lời trước những câu engineering sẽ hỏi.

Đội vận hành của khách X không lọc được bản ghi theo ngày nên mỗi sáng phải dò tay. Họ nhắc việc này trong cả ba cuộc gọi, ghi chú cuộc gọi có đính kèm. Hiện họ xuất dữ liệu ra Excel để lọc tạm.

Hai khách khác từng hỏi điều tương tự, nên đây không phải nhu cầu riêng của một account. Nếu không làm, khách X tiếp tục dựa vào file Excel nằm ngoài hệ thống. Người đọc không cần gọi lại cho bạn mới ra được quyết định.

Khi đọc JD, hãy để ý những cụm như “triage feature requests” hay “input to roadmap”. Đó là dấu hiệu công ty kỳ vọng bạn làm cả phần việc của PM. Lúc phỏng vấn, hãy hỏi lại xem tín hiệu từ FDE đi về đội product theo đường nào, ai đọc nó, và bao lâu một lần.

Những công ty bỏ vai PM sẽ không thiếu engineer biết code. Thứ họ thiếu là người biết đóng gói ngữ cảnh để nó không mất dọc đường.