Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một loạt phỏng vấn người dùng và xây xong vài persona đẹp đẽ: "Chị Lan, 32 tuổi, nhân viên văn phòng tại TP.HCM, thích cà phê sữa đá, dùng iPhone, lương 18 triệu". Persona trông rất chỉn chu, nhưng khi cả team ngồi lại bàn xem nên xây tính năng gì tiếp theo, bạn nhận ra nó… chẳng giúp được mấy. Biết chị Lan thích cà phê sữa đá thì có liên quan gì đến việc chị ấy có dùng app giao đồ ăn của bạn hay không?
Đó chính là khoảng trống mà Jobs-To-Be-Done (JTBD) ra đời để lấp đầy. JTBD chuyển trọng tâm nghiên cứu từ câu hỏi "người dùng này là ai" sang câu hỏi quan trọng hơn nhiều: "người dùng đang cố hoàn thành điều gì, và vì sao họ lại tìm đến sản phẩm của chúng ta?".
Với vai trò một UX Researcher, JTBD là một trong những lăng kính tư duy mạnh nhất bạn có thể trang bị. Nó giúp bạn nhìn xuyên qua những lời than phiền bề mặt để chạm tới động lực thật sự đằng sau hành vi. Nó giúp bạn định nghĩa đối thủ cạnh tranh một cách rộng và chính xác hơn (đôi khi đối thủ của bạn không phải app cùng ngành, mà là… một cuộc gọi điện thoại). Và quan trọng nhất, nó cho phép bạn và đội ngũ thiết kế đưa ra quyết định dựa trên job ổn định, thay vì chạy theo demographic vốn hay thay đổi và dễ gây thiên kiến.
Trong bài này, chúng ta sẽ đi sâu vào tư duy gốc của Clayton Christensen, học cách viết một job statement chuẩn, phân biệt ba tầng "job" (chức năng, cảm xúc, xã hội), và thực hành một quy trình khai thác JTBD từ phỏng vấn người dùng. Đây là kiến thức nền tảng để bạn áp dụng cho mọi loại nghiên cứu về sau.
Khái niệm cốt lõi
"Người dùng thuê sản phẩm để làm một công việc cho họ"
Câu nói nổi tiếng của giáo sư Clayton Christensen (Đại học Harvard) là: "People don't simply buy products or services, they 'hire' them to make progress in specific circumstances." — Người ta không đơn thuần mua sản phẩm, họ thuê (hire) sản phẩm để tạo ra một sự tiến bộ nào đó trong hoàn cảnh cụ thể của mình.
Từ khóa cần nhớ là progress (sự tiến bộ) và circumstance (hoàn cảnh). Một "job" trong JTBD không phải là một tính năng, cũng không phải là một nhiệm vụ kỹ thuật. Nó là sự thay đổi mà người dùng muốn đạt được trong cuộc sống của họ — đi từ trạng thái hiện tại (thường có gì đó khó chịu, dang dở) đến một trạng thái tốt hơn.
Khi bạn nghĩ theo kiểu "thuê" và "sa thải", mọi thứ trở nên sắc bén lạ thường. Nếu sản phẩm của bạn làm tốt công việc được giao, người dùng sẽ tiếp tục "thuê" nó. Nếu có một giải pháp khác làm công việc đó tốt hơn — kể cả khi nó thuộc một danh mục sản phẩm hoàn toàn khác — người dùng sẽ "sa thải" bạn để "thuê" cái kia.
Ví dụ ly milkshake huyền thoại
Đây là ví dụ kinh điển nhất của JTBD, do Christensen và cộng sự thực hiện cho một chuỗi nhà hàng fast-food. Họ được giao nhiệm vụ tăng doanh số bán milkshake (sữa lắc). Cách làm truyền thống là khảo sát khách hàng "điển hình của milkshake": bạn muốn nó đặc hơn hay loãng hơn? Ngọt hơn? Nhiều hương vị hơn? Họ thu thập phản hồi, cải tiến sản phẩm theo đúng yêu cầu — và doanh số gần như không nhúc nhích.
Nhóm nghiên cứu đổi cách tiếp cận. Họ đứng trong quán suốt 18 tiếng quan sát khi nào, ai, mua milkshake để làm gì. Phát hiện gây sốc: gần một nửa milkshake được bán trước 9 giờ sáng, cho những người mua một mình, mang đi, và thường ngồi xe ô tô. Khi phỏng vấn sâu, họ hiểu ra "job" thật sự: những người này có một quãng đường lái xe đi làm dài và buồn chán. Họ cần một thứ gì đó để giết thời gian và chống đói tới trưa, mà phải cầm được bằng một tay, không vương vãi, và "trụ" được lâu.
Hóa ra milkshake được "thuê" để làm công việc đó tốt hơn hẳn các ứng viên khác: chuối thì ăn hết quá nhanh, bánh donut thì dính tay và rơi vụn, cà phê thì không no. Milkshake đặc, hút bằng ống hút mất 20 phút — vừa đủ cho quãng đường. Đối thủ cạnh tranh thật sự của milkshake không phải các loại milkshake khác, mà là chuối, donut và cà phê. Bài học: nếu chỉ hỏi "anh chị muốn milkshake ngon hơn thế nào", bạn sẽ không bao giờ khám phá ra điều này.
Cấu trúc một Job Statement
Một job statement chuẩn không nhắc tên sản phẩm hay công nghệ. Công thức phổ biến (theo Tony Ulwick và trường phái Outcome-Driven Innovation) là:
> Động từ (verb) + đối tượng của hành động (object) + bối cảnh làm rõ (contextual clarifier)
Ví dụ: "Giúp con ăn sáng đủ dinh dưỡng khi cả nhà đang vội buổi sáng đi học, đi làm."
Một dạng đầy đủ hơn, thường dùng trong nghiên cứu, là job story:
> Khi [hoàn cảnh], tôi muốn [động lực], để [kết quả mong đợi].
Ví dụ: "Khi tôi vừa chuyển đến một thành phố mới và chưa quen đường, tôi muốn tìm được quán ăn ngon gần chỗ ở mà người địa phương hay tới, để tôi cảm thấy mình hòa nhập chứ không như khách du lịch lạc lõng."
Lưu ý job story khác hẳn user story kiểu "Là một [vai trò], tôi muốn [tính năng], để [lợi ích]". Job story đặt hoàn cảnh (when) lên đầu và cố tình không nhắc đến giải pháp.
Ba tầng của một Job
Mỗi job thường có ba lớp chồng lên nhau, và người mới làm hay chỉ nhìn thấy lớp đầu tiên:
- Functional job (chức năng): việc cụ thể cần làm xong. Ví dụ: "chuyển 2 triệu cho mẹ ở quê".
- Emotional job (cảm xúc): người dùng muốn cảm thấy thế nào. Ví dụ: "yên tâm rằng tiền đã tới nơi, không bị thất lạc, không sợ bị lừa".
- Social job (xã hội): họ muốn được người khác nhìn nhận ra sao. Ví dụ: "là đứa con biết lo cho gia đình, gửi tiền đúng hẹn không để mẹ phải nhắc".
Tình huống thực tế
Ví dụ 1 — MoMo và job "an tâm khi chuyển tiền cho người thân"
Hãy nhìn vào ví điện tử MoMo ở Việt Nam. Nếu chỉ phân tích theo functional job, ta sẽ nói: người dùng cần chuyển tiền từ A đến B. Nhưng nếu chỉ dừng ở đó, MoMo chẳng khác gì chuyển khoản ngân hàng thông thường.
Khi đào sâu theo JTBD, ta thấy một nhóm người dùng quan trọng: người trẻ đi làm xa quê, hằng tháng gửi tiền về cho bố mẹ. Functional job: gửi 2-3 triệu về quê. Emotional job: an tâm rằng giao dịch thành công ngay lập tức, không phải chờ "trong vòng 30 phút đến 1 ngày làm việc" như cảnh báo của một số kênh. Social job: thể hiện mình là đứa con có trách nhiệm.
Bài học rút ra: chính các tính năng phục vụ tầng cảm xúc và xã hội — thông báo "Mẹ đã nhận được tiền" hiển thị tức thì, lời nhắc gửi tiền định kỳ, giao diện đơn giản để bố mẹ lớn tuổi cũng nhận được — mới tạo nên sự gắn bó. Đối thủ thật sự của MoMo trong job này không chỉ là Banking app, mà còn là thói quen cũ "nhờ người quen cầm tiền về" hay "gửi qua nhà xe". Khi nghiên cứu, đừng dừng ở "người dùng cần chuyển tiền"; hãy hỏi tới khi chạm được nỗi sợ và niềm tự hào bên dưới.
Ví dụ 2 — Một startup học tiếng Anh bị "sa thải" mà không hiểu vì sao
Một startup ứng dụng học tiếng Anh (gọi là EngGo cho dễ hình dung) có tỷ lệ rời bỏ rất cao: 60% người dùng ngừng mở app sau 3 tuần. Team sản phẩm tin rằng nguyên nhân là nội dung chưa đủ hay, nên dồn lực làm thêm bài học, thêm trò chơi gamification. Tỷ lệ rời bỏ vẫn không cải thiện.
Họ mời một UX Researcher làm phỏng vấn JTBD với 12 người đã rời bỏ. Câu hỏi cốt lõi không phải "app thiếu gì", mà là "Lần cuối anh/chị quyết định bắt đầu học tiếng Anh, lúc đó chuyện gì đang xảy ra trong cuộc sống?". Câu trả lời lặp lại theo một mẫu: phần lớn họ tải app vào thời điểm có một biến cố cụ thể — sắp phỏng vấn vào công ty nước ngoài, sắp đi du lịch, hoặc vừa bị sếp chê tiếng Anh kém trong cuộc họp.
Job thật sự không phải "học tiếng Anh giỏi" (một mục tiêu mơ hồ, dài hạn), mà là "chuẩn bị đủ tự tin để vượt qua một tình huống áp lực sắp tới". Khi tình huống đó qua đi — phỏng vấn xong, du lịch về — động lực biến mất, và app bị "sa thải" vì nó được thiết kế cho hành trình học dài hạn chứ không cho cú nước rút ngắn hạn.
Bài học rút ra: EngGo đã giải sai job. Thay vì thêm bài học, họ tạo lộ trình "21 ngày tự tin nói trước buổi phỏng vấn" với mục tiêu rõ ràng, có cảm giác hoàn thành. Hiểu đúng hoàn cảnh kích hoạt (triggering circumstance) giúp họ thiết kế đúng thứ người dùng "thuê" app để làm.
Ví dụ 3 — Grab và job "ăn trưa nhanh ở văn phòng"
GrabFood không bán "đồ ăn", họ phục vụ một loạt job khác nhau tùy hoàn cảnh. Hãy so sánh hai job:
- Job buổi trưa ngày làm việc: "Khi tôi chỉ có 45 phút nghỉ trưa và không muốn ra ngoài nắng, tôi muốn có bữa ăn nóng tới bàn làm việc thật nhanh và dễ đoán, để tôi ăn xong còn kịp nghỉ ngơi." Ở đây yếu tố quyết định là tốc độ và sự chắc chắn — món quen, quán gần, giao đúng giờ.
- Job tối cuối tuần: "Khi cả nhà quây quần tối thứ Bảy, tôi muốn đặt một bữa đặc biệt mà ở nhà không nấu được, để cả nhà có cảm giác đổi gió, thưởng cho mình." Ở đây yếu tố quyết định là sự đa dạng, hấp dẫn và trải nghiệm.
Hướng dẫn từng bước
Dưới đây là quy trình thực dụng để khai thác và viết JTBD từ nghiên cứu người dùng.
Bước 1 — Xác định "câu chuyện mua/chuyển đổi" gần nhất. Trong phỏng vấn, đừng hỏi chung chung "anh dùng sản phẩm này thế nào". Hãy yêu cầu họ kể lại lần gần nhất họ bắt đầu dùng (hoặc chuyển từ giải pháp cũ sang). Câu hỏi vàng: "Lần đó, chuyện gì đang xảy ra khiến anh/chị quyết định tìm một cách làm mới?".
Bước 2 — Truy tìm triggering circumstance (hoàn cảnh kích hoạt). Đào sâu vào thời điểm và bối cảnh: lúc đó họ đang ở đâu, làm gì, cảm thấy thế nào, điều gì khiến "giọt nước tràn ly"? Hoàn cảnh chính là phần "When" của job story và là chìa khóa quan trọng nhất.
Bước 3 — Tách functional, emotional, social job. Với mỗi câu chuyện, hỏi tiếp ba lớp: Họ cần làm xong việc gì? Họ muốn cảm thấy thế nào? Họ muốn người khác nghĩ gì về mình? Ghi lại cả ba.
Bước 4 — Lập sơ đồ bốn lực (Forces of Progress). Mỗi quyết định chuyển đổi bị chi phối bởi bốn lực: (1) Push — sự khó chịu với hiện trạng đẩy họ đi; (2) Pull — sức hút của giải pháp mới; (3) Anxiety — lo lắng về cái mới; (4) Habit — quán tính giữ họ ở lại cái cũ. Push và Pull thúc đẩy thay đổi; Anxiety và Habit cản trở. Hiểu bốn lực giúp bạn biết phải khuếch đại điều gì và gỡ bỏ rào cản nào.
Bước 5 — Viết job statement / job story. Tổng hợp thành câu theo công thức "Khi [hoàn cảnh], tôi muốn [động lực], để [kết quả]". Tuyệt đối không nhắc tên sản phẩm hay tính năng trong câu này.
Bước 6 — Liệt kê đối thủ thật sự theo job. Tự hỏi: ngoài sản phẩm cùng loại, người dùng còn "thuê" cái gì khác để làm cùng job này? Đây thường là nơi insight bất ngờ xuất hiện (như chuối và donut với milkshake).
Bước 7 — Đối chiếu sản phẩm với job. Cuối cùng, đánh giá xem giải pháp hiện tại của bạn phục vụ job đến mức nào, và quyết định nên cải tiến điều gì.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm job với tính năng. "Người dùng cần nút chia sẻ" không phải job; đó là giải pháp. Job là "tôi muốn cho bạn bè thấy thành tích của mình để được công nhận". Mẹo: nếu câu của bạn chứa tên tính năng hay công nghệ, nó chưa phải job.
Lỗi 2 — Job quá rộng hoặc quá hẹp. "Sống hạnh phúc" thì quá rộng để hành động; "bấm nút màu xanh" thì quá hẹp. Mẹo: job tốt nằm ở mức một người dùng có thể nhận ra mình trong đó và team có thể thiết kế quanh nó.
Lỗi 3 — Bỏ qua tầng cảm xúc và xã hội. Nhiều researcher dừng ở functional job và bỏ lỡ động lực thật. Mẹo: luôn hỏi thêm "Lúc đó anh/chị cảm thấy thế nào?" và "Anh/chị có muốn ai biết về việc này không?".
Lỗi 4 — Hỏi về tương lai giả định. "Nếu có tính năng X anh có dùng không?" cho câu trả lời vô giá trị vì người ta dự đoán kém về chính mình. Mẹo: luôn neo vào câu chuyện đã thật sự xảy ra trong quá khứ.
Lỗi 5 — Gắn job cứng vào demographic. "Phụ nữ 25-34 cần…" dễ dẫn tới thiên kiến. Job vượt qua tuổi tác, giới tính. Mẹo: một bà 60 và một anh 22 có thể chia sẻ cùng một job; hãy nhóm theo job, không theo nhân khẩu.
Mẹo nâng cao: kết hợp JTBD với dữ liệu định lượng. Sau khi tìm ra các job qua phỏng vấn định tính, dùng khảo sát để đo mức độ phổ biến và mức độ "chưa được phục vụ tốt" của từng job, từ đó ưu tiên job nào đáng đầu tư nhất.
Bài tập thực hành
Bài tập 1 — Phân tích chính bạn. Chọn một sản phẩm bạn mới bắt đầu dùng trong 30 ngày qua (một app, một dịch vụ, một món đồ). Viết một job story đầy đủ theo công thức "Khi… tôi muốn… để…". Sau đó tách rõ functional, emotional, social job. Cuối cùng liệt kê 3 thứ khác mà bạn đã có thể "thuê" thay thế.
Bài tập 2 — Phỏng vấn mini. Tìm một người bạn vừa mua hoặc đổi sang dùng một thứ gì đó gần đây. Thực hiện cuộc phỏng vấn 15 phút theo Bước 1-4 ở trên, tập trung tìm triggering circumstance và bốn lực. Mục tiêu: viết được ít nhất một job statement không chứa tên sản phẩm.
Bài tập 3 — Định nghĩa lại đối thủ. Lấy một sản phẩm Việt Nam bất kỳ (ví dụ ứng dụng nghe nhạc, app đặt xe, sàn thương mại điện tử). Xác định một job cụ thể nó phục vụ, rồi liệt kê tối thiểu 4 "đối thủ" thật sự theo job đó — trong đó ít nhất 2 cái không cùng ngành. Giải thích vì sao.
Bài tập 4 (nâng cao) — Viết hướng dẫn phỏng vấn. Soạn một bộ 6-8 câu hỏi phỏng vấn JTBD có thể tái sử dụng, đảm bảo bao quát: hoàn cảnh kích hoạt, ba tầng job, và bốn lực. Đây sẽ là tài sản bạn dùng lại cho nhiều dự án.
Tóm tắt
Jobs-To-Be-Done là tư duy đặt câu hỏi "người dùng thuê sản phẩm để làm công việc gì trong cuộc sống của họ", thay vì chỉ mô tả họ là ai. Cốt lõi xoay quanh hai chữ progress (sự tiến bộ) và circumstance (hoàn cảnh): người dùng tìm đến giải pháp để đi từ trạng thái hiện tại sang một trạng thái tốt hơn, được kích hoạt bởi một hoàn cảnh cụ thể.
Một job có ba tầng — chức năng, cảm xúc và xã hội — và sản phẩm thắng cuộc là sản phẩm phục vụ tốt cả ba. Job statement chuẩn không bao giờ nhắc tên sản phẩm; job story theo công thức "Khi… tôi muốn… để…" giúp bạn giữ trọng tâm vào động lực chứ không vào giải pháp. Qua ví dụ ly milkshake, MoMo, app học tiếng Anh và GrabFood, ta thấy giá trị lớn nhất của JTBD: nó tiết lộ đối thủ cạnh tranh thật sự, vạch ra động lực ẩn, và giúp team quyết định nên xây gì tiếp theo.
Hãy nhớ quy trình bảy bước: từ câu chuyện chuyển đổi gần nhất, truy hoàn cảnh kích hoạt, tách ba tầng job, lập sơ đồ bốn lực, viết job story, định nghĩa lại đối thủ, và đối chiếu sản phẩm. Khi bạn ngừng hỏi "người dùng này là ai" và bắt đầu hỏi "họ đang cố tạo ra tiến bộ gì", chất lượng insight của bạn sẽ thay đổi hoàn toàn. Đó chính là sức mạnh của Jobs-To-Be-Done.