Competing Against Luck: câu hỏi Clayton Christensen để lại cho FDE trước mỗi buổi discovery

“Các công ty chưa bao giờ biết nhiều về khách hàng như hiện nay, nhưng quy trình đổi mới của họ vẫn lúc trúng lúc trượt.” Đó là cách Harvard Business Review mở bài viết rút từ cuốn sách, đăng trong số tháng 9/2016, ít tuần trước khi sách ra mắt.

Câu đó đúng với một FDE hơn bạn tưởng. Bạn có thể ngồi cạnh khách cả tuần, đọc hết log, phỏng vấn mười người dùng, rồi vẫn deploy một thứ không ai mở lại sau buổi demo.

Competing Against Luck: The Story of Innovation and Customer Choice trả lời vì sao chuyện đó xảy ra. Và câu trả lời của nó là một kỹ năng bạn có thể dùng ngay trong buổi customer discovery kế tiếp.

Ai viết, và cuốn sách nói gì?

Harper Business phát hành sách ngày 4/10/2016, với bốn tác giả: Clayton M. Christensen, Taddy Hall, Karen Dillon và David S. Duncan. Christensen là người đứng sau lý thuyết; Julia Freeland Fisher của Christensen Institute viết về sách ngay tuần nó ra mắt.

Luận điểm trung tâm khá ngược tai. Theo phần giới thiệu của nhà xuất bản, hiểu khách hàng không phải thứ quyết định đổi mới thành công; hiểu job mới là thứ quyết định. Khách không mua sản phẩm hay dịch vụ, họ “thuê” chúng để làm một việc.

Lời hứa của sách là biến đổi mới từ trò may rủi thành tăng trưởng có thể dự đoán. Tên sách nói luôn điều đó: cạnh tranh với vận may.

Ba ý đáng giữ lại

Ý đầu tiên là phép ẩn dụ “thuê”. Christensen Institute diễn đạt cùng ý: người ta không chỉ mua hay chọn sản phẩm, họ kéo nó vào cuộc sống của mình để tiến lên. Với FDE, điều này đổi câu hỏi từ “khách muốn tính năng gì” sang “khách thuê hệ thống này để làm gì”.

Ý thứ hai là định nghĩa job, được Yevgeniy Brikman tóm gọn trong bài review năm 2022: job là bước tiến một người tìm kiếm trong một hoàn cảnh cụ thể. Hai chữ quan trọng là “bước tiến” và “hoàn cảnh”. Thiếu hoàn cảnh, bạn chỉ có một nhu cầu chung chung không ai đo được.

Ý thứ ba dễ bị bỏ qua nhất: theo Freeland Fisher, jobs to be done là một lý thuyết về cạnh tranh. Nếu khách thuê giải pháp cho một job, thì đối thủ của bạn là mọi thứ khác họ có thể thuê cho job đó, kể cả một bảng tính hay một nhân viên làm tay.

Áp vào một deployment thì trông thế nào?

Theo bài review của Brikman, ví dụ kinh điển để giới thiệu jobs to be done là ly milkshake. Inside Higher Ed kể rằng Christensen xây dựng khung này khi tự hỏi vì sao người ta mua milkshake ở nhà hàng fast food. Câu hỏi không phải “khách thích vị gì”, mà “họ thuê ly milkshake để làm việc gì”.

Thử hình dung bạn là FDE tại một công ty logistics, và khách nói: “Chúng tôi cần một AI agent trả lời câu hỏi của tài xế.” Đó là yêu cầu tính năng. Nếu dừng ở đó, bạn sẽ build một chatbot RAG trên tài liệu nội bộ và đo bằng độ chính xác câu trả lời.

Giờ hỏi theo kiểu Christensen: lần gần nhất tài xế cần hỏi là khi nào, họ đang ở đâu, họ làm gì khi không có ai trả lời? Giả sử câu trả lời là: tài xế đứng trước cửa khách vắng nhà, gọi tổng đài chờ lâu, rồi tự quyết. Job thật là “quyết định đúng ngay tại cửa, không phải chờ”.

Gọi được tên job rồi, các quyết định phía sau cũng đổi theo. Giao diện có lẽ phải dùng được bằng một tay trên điện thoại, điều không hề có trong yêu cầu ban đầu. Trước khi viết dòng code đầu tiên, hãy điền bốn ô sau:

Bước	Ghi ra	Trong ví dụ logistics
1. Job	Bước tiến trong một hoàn cảnh	Quyết định đúng ngay tại cửa, không phải chờ
2. Đối thủ	Thứ khách đang thuê hôm nay	Cuộc gọi tổng đài, phán đoán của tài xế
3. Chỉ số	Đo bước tiến, gắn với hoàn cảnh	Thời gian đến quyết định
4. Kiểm tra	Báo cáo gửi khách đã dùng chỉ số mới chưa	Không chỉ báo độ chính xác câu trả lời

Ô thứ tư chặn lỗi hay gặp nhất: tìm ra job mới nhưng vẫn giữ chỉ số cũ, nên hệ thống được build lại còn báo cáo vẫn nói chuyện cũ. Nếu chỉ số ở ô thứ ba không nhắc gì tới hoàn cảnh, nhiều khả năng bạn chưa tìm ra job.

Khung này cũng không chỉ dành cho sản phẩm bán ra ngoài. Inside Higher Ed áp nó vào giáo dục với câu hỏi sinh viên thuê một trường đại học để làm việc gì. Ở chỗ khách, câu tương đương bạn nên hỏi là: nhân viên vận hành thuê hệ thống nội bộ này để làm việc gì, và khi nó chậm thì họ quay sang thuê thứ gì khác?

Nên đọc theo thứ tự nào?

Bắt đầu bằng bài HBR “Know Your Customers’ ‘Jobs to Be Done’” (tháng 9/2016): ngắn, đủ để nắm khung. Sau đó đọc trang Jobs to Be Done của Christensen Institute để có định nghĩa gọn.

Nếu buổi discovery của bạn hay rơi vào cảnh khách liệt kê tính năng, hãy đọc cả cuốn sách để thấy lý thuyết được áp vào nhiều tình huống. Bài review của Brikman trên ybrikman.com là bản tóm tắt tốt để ôn lại trước khi gặp khách.

Sách hợp nhất với engineer 2-4 năm sắp bước vào vai trò phải đối mặt khách hàng. Người đã làm product lâu năm có thể thấy quen, nhưng vẫn đáng đọc phần cạnh tranh.

Biến nó thành lợi thế khi đi xin việc

Khi đọc job description của một vị trí FDE, hãy tìm những dòng nói về customer discovery hay việc làm rõ yêu cầu mơ hồ của khách. Nếu có, jobs to be done cho bạn một ngôn ngữ cụ thể để chứng minh mình làm được việc đó.

Trong CV, đừng viết “làm việc với stakeholder để thu thập yêu cầu”. Hãy viết một dòng cho thấy bạn đã định nghĩa lại vấn đề: yêu cầu ban đầu là gì, job thật bạn tìm ra là gì, và chỉ số bạn đổi sang đo nhờ đó. Trong phỏng vấn, kể lại đúng hành trình đó, từ yêu cầu ban đầu đến job thật.

Khách sẽ luôn mô tả giải pháp họ tưởng tượng ra. Việc của FDE là hỏi thêm một câu để tìm ra thứ họ thật sự muốn thuê.