Mở đầu — vì sao bài này quan trọng
Hãy thử tưởng tượng bạn vừa nhận một yêu cầu từ sếp: "Làm cho app mình có tính năng lưu video offline đi." Bạn ngồi xuống viết spec, mô tả nút "Download", chỗ lưu file, dung lượng cho phép... Một tháng sau tính năng ra mắt, có người dùng, nhưng tỷ lệ giữ chân (retention) chẳng nhúc nhích. Vì sao? Vì bạn đã spec một giải pháp mà chưa hiểu công việc mà người dùng đang cố hoàn thành.
Đây chính là khoảng trống mà Jobs-To-Be-Done (JTBD) — "công việc cần hoàn thành" — lấp đầy. Trong các bài trước, bạn đã học cách viết Problem, Goals, User Stories. JTBD không thay thế chúng — nó là một lớp tư duy nằm ngay phía trên User Story, giúp bạn neo mọi dòng spec vào động lực thật sự của con người. Khi PM, designer và engineer cùng đọc một câu JTBD rõ ràng, họ ngừng cãi nhau về "nút màu gì" và bắt đầu hỏi "câu này có thực sự giúp người dùng hoàn thành việc của họ không?".
Bài này dạy bạn cách diễn đạt JTBD theo đúng format chuẩn, đưa nó vào trong spec ở đúng chỗ, và dùng nó để ra quyết định scope. Đây là kỹ năng phân biệt một PM viết spec "đủ chạy" với một PM viết spec khiến cả team tự tin rằng họ đang xây đúng thứ.
Khái niệm cốt lõi
JTBD là gì — và không phải là gì
Jobs-To-Be-Done là một lý thuyết do Clayton Christensen (Harvard) phổ biến, với ý tưởng nền tảng: người dùng không "mua" sản phẩm, họ "thuê" (hire) sản phẩm để hoàn thành một công việc trong cuộc sống của họ. Câu ví dụ kinh điển của Christensen: người ta không mua một mũi khoan 6 ly, họ muốn một cái lỗ 6 ly trên tường. Và sâu hơn nữa: họ muốn treo bức ảnh gia đình để căn phòng ấm cúng hơn.
Điểm mấu chốt cần hiểu:
- JTBD mô tả mục tiêu của con người, ổn định theo thời gian. "Tôi muốn nghe nhạc lúc đi đường" là một job tồn tại từ thời băng cassette đến Spotify. Giải pháp thay đổi liên tục; job thì gần như đứng yên.
- JTBD không phải là một tính năng. "Người dùng cần nút download" không phải job — đó là giải pháp. Job là: "Khi tôi sắp đi máy bay không có mạng, tôi muốn xem được video đã chọn, để không phí thời gian bay."
- JTBD không phải là persona. Persona mô tả ai; JTBD mô tả họ đang cố làm gì. Hai persona rất khác nhau (sinh viên và giám đốc) có thể chia sẻ cùng một job ("nhanh chóng nắm ý chính của một tài liệu dài").
Format chuẩn
Format được dùng rộng rãi nhất (do Intercom và Alan Klement chuẩn hóa) là:
> "When [tình huống], I want to [động lực], so I can [kết quả mong muốn]." > "Khi [tình huống], tôi muốn [động lực], để tôi có thể [kết quả]."
Ba thành phần này không phải trang trí — mỗi phần làm một việc:
- When / Tình huống (situation): Bối cảnh kích hoạt job. Đây là phần hay bị bỏ quên nhất nhưng quan trọng nhất, vì nó cho team biết khi nào tính năng cần xuất hiện và xuất hiện thế nào. "Khi tôi đang xem livestream và bình luận trôi quá nhanh..." gợi ý một context rất cụ thể.
- I want to / Động lực (motivation): Điều người dùng muốn làm ngay lúc đó. Diễn đạt ở mức hành vi/mong muốn, chưa phải giải pháp kỹ thuật.
- So I can / Kết quả (outcome): Lý do sâu xa — điều khiến job có giá trị. Đây là thứ bạn dùng để định nghĩa thành công và đo lường sau này.
Functional, emotional, social — ba tầng của một job
Một job tốt thường có ba tầng nhu cầu chồng lên nhau:
- Functional (chức năng): việc cụ thể cần xong. "Lưu video để xem offline."
- Emotional (cảm xúc): người dùng muốn cảm thấy thế nào. "Cảm thấy yên tâm rằng chuyến bay 2 tiếng sẽ không buồn chán."
- Social (xã hội): họ muốn được người khác nhìn nhận ra sao. "Trông như một người biết tận dụng thời gian."
JTBD đứng ở đâu trong spec
JTBD không phải một section riêng dài dòng. Cách dùng hiệu quả nhất là đặt 1–3 câu JTBD ngay đầu phần Solution hoặc User Stories, làm cầu nối giữa Problem Statement (đã viết ở các bài trước) và các user story chi tiết. Mỗi user story sau đó nên truy ngược được về một job. Nếu một story không phục vụ job nào trong danh sách, đó là tín hiệu để bạn hỏi: có nên cắt nó không?
Tình huống thực tế
Ví dụ 1 — Spotify Việt Nam và job "nghe nhạc trên đường đi làm không tốn data"
Bối cảnh: Một nhóm sản phẩm âm nhạc (lấy cảm hứng từ cách Spotify và các app như Zing MP3 tiếp cận thị trường VN) nhận thấy người dùng ở TP.HCM nghe nhạc nhiều nhất vào khung 7–8h sáng khi đi xe máy. Họ định nghĩa job:
> "Khi tôi đi xe máy đến chỗ làm vào buổi sáng, tôi muốn nghe playlist quen thuộc mà không lo tốn 3G/4G và không phải đụng vào điện thoại giữa đường, để tôi vừa an toàn vừa bắt đầu ngày làm việc với tâm trạng tốt."
Diễn giải: Nếu chỉ đọc yêu cầu "thêm nút download playlist", team có thể đã làm xong với một màn hình download tiêu chuẩn. Nhưng phần situation ("đi xe máy", "không đụng vào điện thoại giữa đường") buộc spec phải xử lý: tự động tải sẵn playlist hay nghe gần đây vào ban đêm khi có wifi, phát tiếp tự động không cần thao tác, và điều khiển bằng nút tai nghe. Phần outcome ("an toàn", "tâm trạng tốt") định hướng metric: không chỉ đếm lượt download, mà đo tỷ lệ phiên nghe liên tục >15 phút trong khung giờ sáng.
Bài học: Situation và outcome trong câu JTBD trực tiếp đẻ ra acceptance criteria và metric mà một dòng yêu cầu trần trụi không bao giờ chạm tới.
Ví dụ 2 — Tiki và job "đặt lại đơn hàng định kỳ" (câu chuyện reorder)
Bối cảnh: Một sàn TMĐT giả định kiểu Tiki/Shopee phát hiện 18% người dùng mua đi mua lại cùng một nhóm sản phẩm tiêu dùng (tã, sữa, nước giặt) mỗi 3–4 tuần. Team ban đầu định build một tính năng "Subscription" phức tạp (đăng ký giao hàng tự động). Trước khi viết spec đầy đủ, họ viết JTBD:
> "Khi đồ dùng trong nhà sắp hết (tã, sữa cho con), tôi muốn mua lại đúng những món lần trước với ít thao tác nhất, để tôi không phải nhớ và không bao giờ rơi vào cảnh nửa đêm hết tã."
Diễn giải: Câu này lộ ra rằng job thật là "mua lại nhanh và không bao giờ thiếu", chứ không phải "đăng ký subscription". Subscription chỉ là một trong các giải pháp. Đối chiếu với job, team nhận ra giải pháp v1 đơn giản hơn nhiều: một mục "Mua lại" gom các đơn cũ + nhắc nhở thông minh dựa trên chu kỳ. Họ hoãn subscription phức tạp sang sau. Kết quả giả định: thời gian build giảm một nửa, và vì giải pháp khớp job, tỷ lệ dùng lại tính năng "Mua lại" đạt ~30% trong nhóm mục tiêu.
Bài học: JTBD giúp tách job khỏi giải pháp, từ đó tránh over-engineering. Khi bạn neo spec vào job, bạn có quyền chọn giải pháp rẻ nhất hoàn thành được job đó.
Ví dụ 3 — Livestream commerce và job "không bỏ lỡ deal khi bình luận trôi quá nhanh"
Bối cảnh: Một nền tảng livestream bán hàng (kiểu TikTok Shop / các phiên live của shop VN) — đây cũng chính là tình huống còn dang dở trong ghi chú gốc của bài. Trong phiên live đông, bình luận và thông báo flash sale trôi vài chục dòng mỗi giây. Team viết:
> "Khi tôi đang xem livestream và bình luận trôi quá nhanh, tôi muốn không bỏ lỡ mã giảm giá và sản phẩm host vừa giới thiệu, để tôi mua được đúng món với giá tốt trước khi hết suất."
Diễn giải: Job này nói rõ vấn đề là tốc độ thông tin vượt khả năng theo dõi của con người. Từ đó spec sinh ra các yêu cầu rất cụ thể: ghim (pin) sản phẩm đang được giới thiệu lên đầu màn hình, tách thông báo mã giảm giá ra khỏi luồng bình luận, và một nút "Lấy mã" nổi không bị cuốn đi. Phần outcome ("trước khi hết suất") còn buộc spec phải hiển thị số suất còn lại và đếm ngược — chi tiết mà nếu chỉ nghĩ "làm khung chat đẹp hơn" sẽ không bao giờ xuất hiện.
Bài học: Một câu JTBD sắc bén hoạt động như một bộ lọc thiết kế — nó nói cho bạn biết thông tin nào phải nổi bật và thông tin nào có thể để chìm.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay khi ngồi viết phần JTBD trong spec:
Bước 1 — Thu thập tình huống thật, không phải tính năng mong muốn. Bắt đầu từ phỏng vấn người dùng, support ticket, hoặc data hành vi. Tìm câu trả lời cho: "Lần gần nhất bạn gặp vấn đề này là khi nào, đang làm gì?". Câu trả lời cho bạn phần situation. Tránh hỏi "bạn có muốn tính năng X không" — câu đó dẫn bạn về giải pháp, không phải job.
Bước 2 — Viết job ở mức trung tính với giải pháp. Khi diễn đạt phần "I want to", tự kiểm tra: câu này có nhắc đến một UI cụ thể (nút, màn hình, swipe) không? Nếu có, kéo nó lên một mức trừu tượng. "Tôi muốn bấm nút download" → "Tôi muốn có sẵn nội dung khi mất mạng".
Bước 3 — Luôn viết đủ ba mệnh đề. Một câu JTBD thiếu so I can thường là dấu hiệu bạn chưa hiểu giá trị thật. Nếu bạn không viết nổi phần outcome, hãy quay lại phỏng vấn — đừng bịa.
Bước 4 — Đặt JTBD lên đầu phần Solution / User Stories trong spec. Liệt kê 1–3 job chính (đừng nhiều hơn cho một spec; nếu có 7 job, bạn đang scope quá rộng — nên tách thành nhiều spec).
Bước 5 — Map từng user story và acceptance criteria về một job. Lập một bảng đơn giản: cột job, cột user story, cột metric. Story nào không map được về job nào → đánh dấu để cân nhắc cắt.
Bước 6 — Dùng outcome để định nghĩa metric thành công. Phần "so I can" gần như luôn gợi ý chỉ số đo lường. "...để tôi không bao giờ rơi vào cảnh hết tã" → metric: tỷ lệ khách hàng reorder trước khi hết hàng / số lần "hết hàng đột xuất" giảm.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhét giải pháp vào job. Viết "Khi tôi mở app, tôi muốn thấy nút Mua lại" — đây là spec UI trá hình. Job đúng phải mô tả tình huống đời thực (sắp hết đồ), không phải hành vi bên trong app.
Lỗi 2 — Bỏ phần situation. Nhiều người viết tắt thành "Người dùng muốn xem offline". Mất phần "When", team không biết tính năng cần kích hoạt lúc nào, dẫn đến trải nghiệm chung chung. Situation là phần đắt giá nhất — đừng cắt nó đi.
Lỗi 3 — Job quá to hoặc quá nhỏ. "Khi tôi sống cuộc đời mình, tôi muốn hạnh phúc" — vô dụng vì quá rộng. "Khi tôi bấm vào pixel thứ ba từ trái, tôi muốn nó đổi màu" — quá hẹp, đó là chi tiết triển khai. Job tốt nằm ở mức "một việc người dùng nhận ra mình đang cố làm".
Lỗi 4 — Lẫn lộn JTBD với persona. Đừng viết "Là một sinh viên, tôi muốn..." trong phần JTBD — đó là format user story gắn vai trò. JTBD cố tình bỏ qua danh tính để tập trung vào hoàn cảnh, vì nhiều persona có thể chia sẻ một job.
Mẹo 1 — Test bằng câu hỏi "vì sao": Hỏi "vì sao họ muốn điều đó?" tối đa 2–3 lần để đào tới outcome thật, nhưng đừng đào quá sâu thành ra "vì họ muốn hạnh phúc". Dừng ở mức còn hành động được.
Mẹo 2 — Một spec, tối đa 3 job. Nếu danh sách job dài, đó là tín hiệu scope. Hãy dùng nó như công cụ cắt phạm vi, không phải để liệt kê mọi mong muốn.
Mẹo 3 — Viết job bằng giọng người dùng, không bằng giọng PM. "Để tăng retention 5%" là outcome của bạn, không phải của họ. Outcome trong JTBD phải là điều người dùng quan tâm; metric kinh doanh là chuyện bạn suy ra sau.
Bài tập thực hành
Chọn một tính năng bạn đang hoặc sắp viết spec (nếu chưa có, dùng tình huống giả định: "tính năng nhắc lịch uống thuốc trong app sức khỏe").
- Viết 2 câu JTBD theo đúng format "Khi [tình huống], tôi muốn [động lực], để tôi có thể [kết quả]." cho tính năng đó. Bắt buộc đủ ba mệnh đề.
- Soi lại phần "I want to": gạch chân bất kỳ từ nào ám chỉ giải pháp UI cụ thể (nút, màn hình, swipe). Viết lại ở mức trung tính hơn.
- Lập bảng map với 3 cột: Job | User story tương ứng | Metric suy ra từ outcome. Viết ít nhất 3 dòng. Nếu có user story nào không map về job nào trong danh sách của bạn — ghi chú lại và tự hỏi có nên cắt không.
- Kiểm tra tầng cảm xúc: với một trong hai job, viết thêm một câu mô tả người dùng muốn cảm thấy thế nào. Xem nó có gợi ra edge case hay lựa chọn thiết kế nào mà phân tích chức năng bỏ sót không.
Tóm tắt
- JTBD mô tả công việc người dùng đang cố hoàn thành, ổn định theo thời gian, tách bạch khỏi giải pháp cụ thể.
- Format chuẩn: "Khi [tình huống], tôi muốn [động lực], để tôi có thể [kết quả]." Cả ba mệnh đề đều quan trọng; phần situation và outcome thường bị bỏ quên nhưng lại sinh ra acceptance criteria và metric.
- Vị trí trong spec: 1–3 câu JTBD đặt ở đầu phần Solution/User Stories, làm cầu nối từ Problem tới các story chi tiết. Mỗi story nên truy ngược về một job.
- Giá trị thực dụng: JTBD giúp tránh over-engineering (chọn giải pháp rẻ nhất hoàn thành job), lọc thông tin nào cần nổi bật trong thiết kế, và định nghĩa metric thành công từ phần outcome.
- Tránh: nhét giải pháp vào job, bỏ situation, viết job quá to/quá nhỏ, lẫn JTBD với persona.