Mở đầu — vì sao bài này quan trọng
Hãy bắt đầu bằng một câu hỏi tưởng chừng đơn giản: "Khách hàng mua sản phẩm của bạn để làm gì?" Phần lớn Product Owner trả lời theo kiểu mô tả tính năng — "họ mua app vì nó có tính năng đặt lịch", "họ dùng vì giao diện đẹp". Nhưng đó là cái nhìn của người làm sản phẩm, không phải của người dùng. Người dùng không thức dậy và nghĩ "hôm nay mình muốn dùng một tính năng đặt lịch". Họ có một việc cần hoàn thành trong cuộc sống, và họ tìm một thứ gì đó để giúp họ hoàn thành nó.
Đây chính là tinh thần của Jobs To Be Done (JTBD) — một framework do Clayton Christensen (giáo sư Harvard, tác giả "The Innovator's Dilemma") phổ biến. Câu nói nổi tiếng của ông là: "People don't buy products; they hire them to do a job" — Con người không mua sản phẩm; họ "thuê" sản phẩm để làm một công việc nào đó. Khi sản phẩm làm tốt công việc, họ tiếp tục thuê. Khi có thứ khác làm tốt hơn, họ "sa thải" sản phẩm cũ.
Ở cấp độ PSPO II, JTBD không chỉ là một kỹ thuật phỏng vấn khách hàng. Nó là một lăng kính tư duy chiến lược giúp bạn định nghĩa lại thị trường, nhìn ra đối thủ cạnh tranh thật sự (thường không phải đối thủ trực tiếp), và ưu tiên Backlog dựa trên việc cần làm của khách hàng thay vì dựa trên ý kiến chủ quan của stakeholder. Trong bối cảnh Product Owner ngày càng phải chứng minh giá trị bằng outcome (kết quả) chứ không phải output (số lượng tính năng), hiểu sâu "job" của khách hàng là điều kiện sống còn để bạn tạo ra giá trị thật.
Khái niệm cốt lõi
"Job" là gì — và không phải là gì
Một job (việc cần làm) là sự tiến bộ mà một người muốn đạt được trong một hoàn cảnh cụ thể. Hãy chú ý ba từ khóa: tiến bộ (progress), hoàn cảnh (situation/context), và con người (chứ không phải phân khúc nhân khẩu học).
Job không phải là:
- Một tính năng ("gửi thông báo push")
- Một sản phẩm ("ứng dụng ngân hàng số")
- Một đặc điểm nhân khẩu học ("phụ nữ 25–35 tuổi ở Hà Nội")
Ba chiều của một job
Một job hoàn chỉnh luôn có ba chiều, và PO giỏi phải nắm cả ba:
- Functional (chức năng): việc thực tế cần làm — "đi từ nhà đến công ty đúng giờ".
- Emotional (cảm xúc): người dùng muốn cảm thấy thế nào — "cảm thấy chủ động, không lo trễ giờ".
- Social (xã hội): người dùng muốn được nhìn nhận thế nào trong mắt người khác — "trông như một người chuyên nghiệp, đúng hẹn".
Job statement — định dạng chuẩn
Cách viết một job statement để cả team hiểu chung:
Khi [hoàn cảnh],
tôi muốn [động lực / điều cần làm],
để tôi có thể [kết quả mong đợi].(When [situation], I want to [motivation], so I can [expected outcome].)
Ví dụ: "Khi tôi vừa chuyển đến một thành phố mới và chưa quen đường (hoàn cảnh), tôi muốn di chuyển đến nơi cần đến mà không bị lạc (động lực), để tôi đến đúng giờ và không căng thẳng (kết quả)."
Lưu ý: job statement không nhắc tên sản phẩm hay giải pháp. Ngay khi bạn viết "tôi muốn mở Google Maps", bạn đã rơi vào giải pháp và đánh mất tính trung lập của job.
Đối thủ cạnh tranh thật sự
Một hệ quả mạnh mẽ của JTBD: đối thủ của bạn là bất cứ thứ gì khách hàng "thuê" cho cùng một job. Đối thủ của Netflix không chỉ là Disney+, mà còn là giấc ngủ, TikTok, và một ván game. Đối thủ của một khóa học online không chỉ là khóa học khác, mà còn là YouTube miễn phí và việc "không học gì cả". Nhìn theo job mở rộng tầm nhìn cạnh tranh của bạn ra ngoài danh mục sản phẩm.
Tình huống thực tế
Ví dụ 1 — Milkshake của McDonald's (kinh điển, để hiểu phương pháp)
Bối cảnh: McDonald's muốn tăng doanh số milkshake. Họ làm theo cách truyền thống — khảo sát khách hàng thuộc phân khúc "người thích milkshake", hỏi họ muốn vị đậm hơn, ngọt hơn hay rẻ hơn. Họ cải tiến theo phản hồi, nhưng doanh số không nhúc nhích.
Christensen và nhóm của ông tiếp cận khác: họ đứng trong cửa hàng quan sát khi nào và tại sao người ta mua milkshake. Phát hiện gây sốc: gần một nửa milkshake được bán trước 8h sáng, mua bởi người đi làm một mình, mang theo lên xe. Khi phỏng vấn, họ phát hiện job thật là: "Khi tôi lái xe đi làm một mình trên quãng đường dài và buồn chán, tôi cần một thứ giúp tôi qua thời gian và không đói đến trưa, mà tôi có thể cầm một tay khi lái xe."
Diễn giải: Milkshake được "thuê" không phải vì nó ngon, mà vì nó đặc (uống lâu, qua được 30 phút lái xe), không vương vãi, cầm một tay tiện. Đối thủ của milkshake buổi sáng không phải milkshake của hãng khác — mà là chuối (mau hết, nhanh đói lại), bánh donut (vụn, dính tay), cà phê (không no).
Bài học rút ra: Nếu chỉ tối ưu theo phân khúc nhân khẩu học và phản hồi bề mặt, bạn sẽ cải tiến nhầm hướng. Hiểu job (làm milkshake đặc hơn, đặt máy bán tự lấy ở trước quầy để khách vội không phải xếp hàng) mới tạo tăng trưởng thật.
Ví dụ 2 — Ứng dụng giao đồ ăn tại Việt Nam (bối cảnh địa phương)
Bối cảnh: Một startup giả định tên "BếpNhà" ra mắt app giao đồ ăn, định vị cạnh tranh trực tiếp với GrabFood và ShopeeFood bằng cách giảm giá ship. Sau 6 tháng, họ đốt tiền khuyến mãi nhưng tỷ lệ giữ chân (retention) tháng thứ hai chỉ 12%. PO của BếpNhà quyết định làm 20 cuộc phỏng vấn JTBD với người dùng đã rời bỏ.
Họ phát hiện hai job rất khác nhau bị gộp làm một:
- Job A — bữa trưa văn phòng: "Khi tôi kẹt deadline buổi trưa và không có thời gian ra ngoài, tôi cần đồ ăn đến nhanh và rẻ, để tôi ăn vội rồi làm tiếp." Với job này, tốc độ và giá là tất cả — và họ đã thua Grab về quy mô tài xế.
- Job B — bữa tối gia đình cuối tuần: "Khi cuối tuần cả nhà muốn đổi món nhưng ngại nấu, tôi muốn đặt một bữa chỉn chu cho 4 người, để cả nhà cảm thấy như đi nhà hàng mà không phải ra ngoài." Job này quan tâm chất lượng, khẩu phần gia đình, đóng gói đẹp — và gần như không ai phục vụ tốt.
Bài học rút ra: Cùng một sản phẩm có thể được "thuê" cho nhiều job khác nhau. Trộn lẫn chúng khiến bạn dàn trải và thua ở mọi mặt trận. JTBD giúp bạn chọn job để thắng.
Ví dụ 3 — Sản phẩm B2B SaaS quản lý nhân sự (chiều cảm xúc & xã hội)
Bối cảnh: Một công ty SaaS HR tại Đông Nam Á bán phần mềm chấm công và tính lương cho doanh nghiệp vừa và nhỏ. Đội sales liên tục báo về rằng khách hàng "muốn thêm tính năng báo cáo". PO định đưa hàng loạt biểu đồ vào Backlog. Trước khi làm, anh phỏng vấn JTBD với người ra quyết định mua — thường là kế toán trưởng hoặc chủ doanh nghiệp.
Phát hiện: Job functional là "tính lương đúng và nhanh". Nhưng job cảm xúc và xã hội mạnh hơn nhiều: "Khi đến kỳ duyệt lương, tôi muốn tự tin rằng con số là chính xác và có thể giải trình ngay nếu sếp hoặc nhân viên thắc mắc, để tôi không bị mất mặt vì sai sót." Cái họ cần không phải "nhiều biểu đồ", mà là bằng chứng kiểm toán — một dấu vết rõ ràng cho biết con số được tính ra sao, ai chỉnh sửa gì, khi nào.
Diễn giải: Thay vì xây dashboard hào nhoáng, PO ưu tiên tính năng "lịch sử thay đổi và lý do điều chỉnh lương" cùng nút "xuất bảng giải trình một chạm". Tính năng này không đẹp mắt nhưng chạm đúng job cảm xúc (tự tin) và xã hội (không mất mặt). Tỷ lệ chuyển từ bản dùng thử sang trả phí tăng đáng kể vì người mua cảm thấy được "che chắn".
Bài học rút ra: Stakeholder (ở đây là sales) thường truyền đạt job dưới dạng giải pháp ("thêm báo cáo"). Nhiệm vụ của PO là đào ngược về job thật, nơi chiều cảm xúc và xã hội thường nằm ẩn.
Hướng dẫn từng bước
Đây là quy trình áp dụng JTBD mà bạn có thể bắt đầu ngay trong Sprint tới:
Bước 1 — Xác định người để phỏng vấn. Ưu tiên người vừa mới chuyển đổi: vừa mua sản phẩm của bạn, vừa rời bỏ, hoặc vừa chuyển từ giải pháp cũ sang giải pháp khác. Trí nhớ của họ về hoàn cảnh và động lực còn tươi mới. Tránh phỏng vấn người dùng lâu năm đã quên lý do ban đầu.
Bước 2 — Phỏng vấn theo dòng thời gian (timeline), không theo ý kiến. Đừng hỏi "bạn thích gì ở sản phẩm". Hãy hỏi: "Lần đầu bạn nhận ra mình cần một thứ như thế này là khi nào?", "Lúc đó chuyện gì đang xảy ra?", "Bạn đã cân nhắc những lựa chọn nào khác?", "Điều gì khiến bạn cuối cùng quyết định?". Bạn đang tái dựng lại "câu chuyện thuê".
Bước 3 — Tìm bốn lực đẩy. Mỗi quyết định chuyển đổi bị chi phối bởi bốn lực: (a) Push — nỗi khó chịu với hiện trạng đẩy họ đi; (b) Pull — sức hấp dẫn của giải pháp mới; (c) Anxiety — lo lắng về cái mới; (d) Habit — quán tính bám vào cái cũ. Sản phẩm chỉ được "thuê" khi Push + Pull lớn hơn Anxiety + Habit. PO cần khuếch đại hai lực đầu và giảm hai lực sau.
Bước 4 — Viết job statement. Tổng hợp các cuộc phỏng vấn thành 1–3 job statement theo định dạng "Khi… tôi muốn… để…". Ghi rõ cả ba chiều functional/emotional/social.
Bước 5 — Xác định tiêu chí thành công của job. Với mỗi job, hỏi: khách hàng đo lường "làm tốt job này" bằng gì? (Ví dụ: "nhanh hơn", "ít sai sót hơn", "ít bước hơn".) Đây là nơi JTBD kết nối với việc đo outcome.
Bước 6 — Map vào Backlog và Product Goal. Đối chiếu từng Product Backlog Item: nó phục vụ job nào? Đẩy job đó tiến bộ ra sao? Item nào không gắn với job nào nên bị nghi ngờ. Đây là cách JTBD giúp bạn ưu tiên có cơ sở.
Bước 7 — Kiểm chứng bằng bằng chứng. Đưa giả thuyết về job vào thử nghiệm thực tế (landing page, MVP, A/B test) để xác nhận trước khi đầu tư lớn. Job là giả thuyết cho đến khi có dữ liệu chứng minh.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm giải pháp với job. Khi khách hàng nói "tôi muốn nút export Excel", đó là giải pháp. Hỏi "để làm gì?" vài lần (kỹ thuật 5 Whys) để chạm tới job thật. Mẹo: nếu trong job statement của bạn có tên một tính năng, bạn chưa đào đủ sâu.
Lỗi 2 — Job quá rộng hoặc quá hẹp. "Sống hạnh phúc hơn" thì rộng vô dụng; "bấm nút màu xanh ở góc phải" thì hẹp đến mức chỉ là thao tác. Job tốt nằm ở mức "giải quyết một tiến bộ cụ thể trong một hoàn cảnh cụ thể". Mẹo: nếu job đúng, bạn sẽ thấy nhiều giải pháp khả dĩ cạnh tranh cho cùng job đó.
Lỗi 3 — Bỏ qua chiều cảm xúc và xã hội. Đây là lỗi của các team thiên về kỹ thuật. Hãy luôn hỏi: "Người dùng muốn cảm thấy gì? Muốn được nhìn nhận thế nào?" Nhiều cơ hội khác biệt hóa nằm ở đây.
Lỗi 4 — Phỏng vấn để khẳng định thay vì để khám phá. Nếu bạn đi vào cuộc phỏng vấn với kết luận sẵn, bạn sẽ chỉ nghe cái mình muốn nghe (confirmation bias). Mẹo: đặt câu hỏi mở, để khoảng lặng, và đặc biệt chú ý khi khách hàng kể câu chuyện trái với giả thuyết của bạn — đó thường là vàng.
Lỗi 5 — Coi JTBD là một lần làm rồi xong. Job thì ổn định, nhưng tiêu chí "làm tốt job" và hoàn cảnh thì tiến hóa. Định kỳ rà soát lại.
Mẹo tổng quát: JTBD bổ trợ chứ không thay thế Personas (Bài 35) và Customer Journey Mapping (Bài 34). Personas cho biết ai, journey cho biết hành trình, còn JTBD cho biết tại sao họ tiến bước. Dùng kết hợp, đừng đối lập chúng.
Bài tập thực hành
- Viết job statement cho chính sản phẩm bạn đang phụ trách. Chọn một tính năng hoặc luồng người dùng quan trọng. Viết job statement theo định dạng "Khi… tôi muốn… để…", và đảm bảo nêu đủ ba chiều functional, emotional, social. Kiểm tra: trong câu có lọt tên giải pháp nào không? Nếu có, viết lại.
- Phỏng vấn một người dùng thật theo dòng thời gian. Tìm một người vừa bắt đầu hoặc vừa rời bỏ sản phẩm của bạn trong 30 ngày qua. Dùng các câu hỏi ở Bước 2 để tái dựng "câu chuyện thuê". Sau đó điền vào mô hình bốn lực (Push, Pull, Anxiety, Habit). Lực nào đang cản trở chuyển đổi mạnh nhất?
- Đối chiếu Backlog với job. Lấy 10 item đầu trong Product Backlog. Với mỗi item, ghi nó phục vụ job nào và đẩy job đó tiến bộ ra sao. Đánh dấu những item không gắn với job rõ ràng — đây là ứng viên để loại hoặc xếp lại ưu tiên.
- Tìm đối thủ phi truyền thống. Liệt kê 5 thứ mà khách hàng có thể "thuê" thay cho sản phẩm của bạn cho cùng một job — bao gồm cả "không làm gì cả" và các giải pháp thủ công (Excel, giấy bút, nhờ người khác). Sản phẩm của bạn thắng/thua chúng ở điểm nào?
Tóm tắt
Jobs To Be Done đảo ngược cách nhìn của Product Owner: thay vì hỏi "sản phẩm của tôi có tính năng gì", ta hỏi "khách hàng đang cố hoàn thành tiến bộ gì, trong hoàn cảnh nào". Cốt lõi là câu của Christensen — khách hàng thuê sản phẩm để làm một job, và sẽ sa thải nó khi có thứ làm tốt hơn.
Những điểm cần khắc cốt: một job luôn có ba chiều functional, emotional, social; job statement viết theo định dạng "Khi… tôi muốn… để…" và tuyệt đối không nhắc tên giải pháp; đối thủ thật của bạn là bất cứ thứ gì được thuê cho cùng job, kể cả "không làm gì cả". Quy trình áp dụng đi từ phỏng vấn người vừa chuyển đổi, phân tích bốn lực (Push, Pull, Anxiety, Habit), viết job statement, rồi map vào Backlog và kiểm chứng bằng bằng chứng.
Với một Product Owner ở cấp PSPO II, JTBD không phải mẹo phỏng vấn — nó là lăng kính chiến lược để định nghĩa thị trường, ưu tiên dựa trên giá trị thật của khách hàng, và chuyển trọng tâm từ output sang outcome. Khi bạn thực sự hiểu job khách hàng đang cần làm, mọi quyết định Backlog đều có một câu trả lời vững vàng cho câu hỏi quan trọng nhất: "Điều này giúp khách hàng tiến bộ ra sao?"