Thấu hiểu người dùng với Jobs-to-be-Done: Tại sao khách hàng mua tính năng của bạn?

Sau khi vẽ xong toàn bộ process model của quy trình đặt phòng — từ lúc khách chọn ngày, chọn phòng, thanh toán, đến lúc lễ tân check-in — Minh gửi bản BPMN cho Huy để đội kỹ thuật bắt đầu breakdown backlog. Huy đọc xong, gõ một câu trong Slack: "Flow thì rõ rồi, nhưng sao trong wireframe không thấy chỗ nào gợi ý spa hay tour cho khách? Nếu không có, feature này coi như chỉ là một cái form đặt phòng, không hơn."

Minh khựng lại. Đúng là quy trình "đặt được phòng" đã đủ chặt chẽ về mặt luồng nghiệp vụ. Nhưng Huy đang hỏi một câu khác hẳn: đặt phòng xong rồi thì sao? Câu hỏi đó không nằm trong bất kỳ ô nào của sơ đồ BPMN. Nó nằm ở tầng sâu hơn — tầng mà process modeling không chạm tới: khách hàng thực sự đang cố hoàn thành cái gì khi họ mở app Reso lên?

Đây chính là lúc Minh cần một công cụ khác hẳn — không phải để vẽ quy trình, mà để hiểu động cơ đằng sau quy trình. Công cụ đó là Jobs-to-be-Done (JTBD).

Sự thật cơ bản (First Principle)

Khách hàng không mua hay dùng một sản phẩm vì bản thân sản phẩm đó. Họ "thuê" (hire) sản phẩm để hoàn thành một công việc (job) cụ thể đang tồn tại trong đời sống hoặc công việc của họ — và hiểu đúng job đó quan trọng hơn hiểu đặc tả tính năng.

Câu nói kinh điển của Theodore Levitt vẫn đúng tuyệt đối ở đây: "Người ta không muốn mua một cái khoan 6mm, người ta muốn một cái lỗ 6mm trên tường." Không ai thức dậy buổi sáng và nghĩ "hôm nay mình muốn dùng một tính năng đặt phòng có bộ lọc theo giá". Họ nghĩ "mình sắp đi Đà Lạt cuối tuần này, cần lo xong chỗ ở càng nhanh càng ít lo càng tốt".

Sai lầm phổ biến nhất của BA — kể cả BA có kinh nghiệm — là dừng lại ở tầng "yêu cầu" (requirement) mà không đào xuống tầng "job". Yêu cầu là bề mặt, có thể thay đổi theo công nghệ và bối cảnh. Job thì bền vững, gần như không đổi qua nhiều năm, nhiều nền tảng. Người ta đã cần "một chỗ ở an tâm khi đi xa" từ thời chưa có internet, và sẽ vẫn cần y như vậy khi VR booking ra đời. Cái thay đổi chỉ là công cụ hoàn thành job đó.

Phân tích

Minh áp dụng JTBD không phải cho một, mà cho hai lớp khách hàng khác nhau của cùng một dự án Reso — vì cả hai đều đang "thuê" một thứ gì đó, dù đối tượng khác nhau hoàn toàn.

Lớp 1 — Khách du lịch, người trực tiếp dùng app Reso để đặt phòng.

Nếu chỉ nhìn vào màn hình checkout, ai cũng nghĩ job của họ là "đặt được một phòng trống, đúng ngày, đúng giá". Đó là job chức năng (functional job) — dễ thấy, dễ đo, nhưng chưa phải toàn bộ câu chuyện.

Minh ngồi lại đọc review của khách trên các kênh OTA hiện tại của Serene Hotels — không phải review về phòng ốc, mà review về trải nghiệm đặt phòng và những gì xảy ra sau đó. Một mẫu lặp lại: khách phàn nàn không phải vì phòng xấu, mà vì "đặt xong rồi mà vẫn phải tự tìm hiểu chỗ đưa đón sân bay ở đâu", "tới nơi mới biết khách sạn không có dịch vụ spa như quảng cáo", "đặt tour riêng bên ngoài rồi bị hủy sát ngày, xáo trộn hết lịch trình".

Từ đó lộ ra job thật, ở tầng cảm xúc (emotional job): khách không chỉ muốn "có một chỗ ngủ", họ muốn đặt xong là có thể yên tâm, không phải lo nghĩ gì thêm cho cả chuyến đi. Việc đặt phòng chỉ là bước đầu của một chuỗi lo lắng dài hơn nhiều: đi lại thế nào, ăn ở ra sao, có dịch vụ gì đi kèm, lỡ có vấn đề thì ai xử lý. Cái họ thực sự "thuê" Reso để làm không phải là giữ chỗ — mà là gánh bớt sự bất định của một chuyến đi xa.

Có thêm một lớp job xã hội (social job) mỏng hơn nhưng vẫn đáng chú ý: đi nghỉ ở resort boutique, nhiều khách muốn thể hiện với bạn bè/gia đình một chuyến đi "được chăm sóc chu đáo, không phải tự lo lắng vặt vãnh" — khoe không phải cái phòng, mà khoe trải nghiệm liền mạch.

Lớp 2 — Chị Lan Anh và Serene Hotels, người "thuê" chính dự án Reso.

Đây là lớp mà nhiều BA bỏ qua, vì họ mặc định "khách hàng nội bộ/sponsor thì đã rõ yêu cầu rồi, không cần JTBD". Nhưng đúng như bài 3 đã lật ra: câu chị Lan Anh nói ("Tôi muốn một app để khách đặt phòng online, giống mấy khách sạn lớn có") là yêu cầu bề mặt che giấu job thật.

Job chức năng bề mặt: "có một cái app đặt phòng". Nếu Minh và Huy chỉ build đúng như vậy — một app đặt phòng đơn thuần, đẹp, chạy mượt — dự án vẫn có thể "thành công" về mặt giao hàng nhưng thất bại hoàn toàn về mặt kinh doanh. Vì job thật của chị Lan Anh, đúng như áp lực ban giám đốc Serene đang đặt lên chị, là: giảm phụ thuộc vào hoa hồng OTA (đang ăn 15-20% doanh thu mỗi đặt phòng), tăng tỷ lệ đặt phòng trực tiếp, và sở hữu được dữ liệu khách hàng trực tiếp để chăm sóc và bán thêm dịch vụ (spa, tour, đưa đón sân bay).

Job cảm xúc đi kèm: chị Lan Anh cần một câu trả lời thuyết phục trước ban giám đốc — không phải "chúng ta đã có app" mà là "chúng ta đã giảm được X% chi phí hoa hồng, tăng Y% booking trực tiếp". Đó là thứ giúp chị "yên tâm" trước sức ép từ trên.

Điểm mấu chốt Minh nhận ra khi đặt hai lớp JTBD cạnh nhau: chúng không mâu thuẫn — chúng giao nhau ở đúng một điểm. Khách du lịch muốn "yên tâm mọi thứ đã được lo, không phải tự tìm hiểu thêm". Chị Lan Anh muốn "bán thêm được dịch vụ, có dữ liệu khách hàng". Cả hai job này được giải quyết bằng CÙNG MỘT tính năng: gợi ý dịch vụ đi kèm (spa, tour, đưa đón sân bay) đúng vào thời điểm khách đang trong trạng thái tâm lý muốn chốt hết mọi thứ cho chuyến đi — tức ngay sau khi xác nhận đặt phòng, hoặc trong quá trình điền thông tin đặt phòng.

Nếu Minh chỉ dừng ở process modeling của bài trước, tính năng này gần như chắc chắn sẽ bị bỏ sót khỏi phạm vi ban đầu — vì nó không nằm trong "flow đặt phòng" theo nghĩa hẹp. Nhưng nhìn qua lăng kính JTBD, nó không phải một "tính năng thêm" (nice-to-have) — nó là tính năng phục vụ đúng cả hai job cốt lõi cùng lúc, và vì vậy phải nằm trong phạm vi MVP, không phải phase 2.

Giải pháp

Câu tuyên bố Job (Job Statement) là công cụ cụ thể để buộc bản thân phải diễn đạt job — thay vì tính năng — thành một câu duy nhất, theo công thức:

Khi [tình huống/bối cảnh cụ thể], tôi muốn [động lực/hành động], để [kết quả mong đợi].

Ba lưu ý khi viết câu Job này:

1. "Khi..." phải là một tình huống có thật, có thể quan sát, không phải một persona chung chung. Không viết "Khi là một khách du lịch" — viết "Khi vừa xác nhận đặt phòng khách sạn cho chuyến đi 3 ngày ở Hội An mà chưa từng đến trước đây".
2. "Tôi muốn..." mô tả động lực, không phải giải pháp. Không viết "tôi muốn có nút đặt spa" (đó là giải pháp) — viết "tôi muốn biết trước những gì tôi có thể cần và chuẩn bị sẵn tất cả trong một lần" (đó là động lực).
3. "Để..." là kết quả cảm xúc/chức năng cuối cùng, là lý do sâu xa. Đây là chỗ phân biệt rõ ba loại job:
   • Job chức năng (functional): kết quả đo được, cụ thể (VD: "để không phải mở thêm ứng dụng khác").
   • Job cảm xúc (emotional): trạng thái tâm lý mong muốn (VD: "để cảm thấy an tâm, không còn gì phải lo").
   • Job xã hội (social): cách người khác nhìn nhận mình (VD: "để thể hiện đây là một chuyến đi được chuẩn bị chu đáo").

Khi phỏng vấn stakeholder hoặc phân tích dữ liệu người dùng, Minh khuyên nên đi tìm cả ba tầng job cho mỗi nhóm đối tượng chính — vì tính năng tốt thường phục vụ đồng thời nhiều hơn một tầng. Và quan trọng hơn: với dự án B2B2C hoặc nội bộ như Reso, đừng chỉ áp JTBD cho người dùng cuối — áp luôn cho chính sponsor/khách hàng đang trả tiền cho dự án. Họ cũng đang "thuê" một kết quả, không phải một sản phẩm.

Quy trình gợi ý, tổng quát hóa cho mọi dự án:

1. Liệt kê tất cả các nhóm "người thuê" liên quan đến sản phẩm — không chỉ end-user, mà cả sponsor, người vận hành, người trả tiền.
2. Với mỗi nhóm, viết ít nhất một câu Job Statement đầy đủ ba phần Khi/Tôi muốn/Để.
3. Phân loại job vừa viết theo ba tầng chức năng/cảm xúc/xã hội.
4. Đối chiếu ngược: với mỗi tính năng đang có trong backlog, tự hỏi "tính năng này phục vụ job nào, của nhóm nào?" — nếu không trả lời được, tính năng đó đáng bị nghi ngờ về mức độ ưu tiên.
5. Tìm điểm giao giữa các job của các nhóm khác nhau — đó thường là nơi ẩn giấu tính năng có ROI (tỷ suất lợi nhuận) cao nhất, vì một tính năng phục vụ nhiều job cùng lúc luôn đáng đầu tư hơn tính năng chỉ phục vụ một job đơn lẻ.

📎 Actionable Template

Bảng JTBD áp dụng cho case Reso — copy và điều chỉnh theo dự án của bạn:

🧠 Tư duy phản biện: Nếu một tính năng trong backlog của bạn không thể viết thành một câu Job Statement rõ ràng cho bất kỳ ai — liệu nó đang phục vụ nhu cầu thật, hay chỉ đang tồn tại vì "khách sạn lớn nào cũng có tính năng này"?

🔗 Case Study & Bài viết liên quan

Bài này là một chương trong hành trình phân tích dự án Reso xuyên suốt series 12 bài "BA 4.0: Từ Phân tích đến Giải pháp". Job Statement vừa xác định ở đây — đặc biệt là tính năng gợi ý dịch vụ đi kèm — sẽ trở thành tâm điểm tranh luận về phạm vi ở bài tiếp theo, và là nền tảng để đặt câu hỏi 5 Whys sâu hơn nếu bạn muốn quay lại kỹ thuật đào sâu yêu cầu: Kỹ năng "Đặt câu hỏi" (The Art of Questioning). Còn quy trình vừa được model hóa ở bài trước là nơi bạn sẽ cắm chính xác tính năng này vào đúng bước nào của luồng nghiệp vụ: Phân tích quy trình (Process Modeling).

Hiểu job không phải là điểm dừng — nó là điểm khởi đầu của một cuộc tranh luận khó hơn nhiều: bao nhiêu trong số những job vừa tìm ra sẽ thực sự nằm trong phạm vi của phiên bản đầu tiên? Gợi ý dịch vụ đi kèm nghe rất hợp lý trên giấy — nhưng Huy đã cảnh báo: mỗi tính năng thêm vào đều kéo theo tích hợp PMS, thêm luồng thanh toán, thêm rủi ro trễ deadline. Đó chính là lúc Minh phải đối mặt với bài toán quản trị phạm vi ở chương tiếp theo.

Bài trước: Phân tích quy trình (Process Modeling) · Bài tiếp theo: Quản trị phạm vi (Scope Management)