Jobs-to-be-done áp dụng như thế nào vào Product management? (phần 1)

Jobs-to-be-done (JTBD) là một framework để phân tích nhu cầu người dùng đã được nhắc tới khá nhiều trong cộng đồng làm sản phẩm. Nên mình đã dành chút thời gian để cố gắng hiểu concept của mô hình này, để đánh giá xem liệu mô hình này có phù hợp áp dụng cho công việc của PM không, áp dụng được ở mức độ như thế nào. Phần 1 của các bài về JTBD sẽ nêu ra nguồn gốc xuất xứ, định nghĩa và các thành phần của framework này (Hic, cá nhân mình thấy khá trừu tượng, dù đã cố gắng xem, đọc những tài liêu nổi bật nhất về mô hình này, từ chính cha đẻ của nó Tony Ulwick, tới các practitioner, tác giả có tiếng trong lĩnh vực UX research như Jim Kalbach).

JTBD xuất phát từ một research và segmentation technique của Tony Ulwick, người từng có kinh nghiệm ở IBM về phân tích customers để làm plan cho sản phẩm. Technique sau đó được Giáo sư Clayton Christensen phát triển thành lý thuyết JTBD, đi kèm concept về innovation trong quyển sách "The Innovator's Solution". (Mình chưa có thời gian để research kĩ hơn về lí thuyết này: context ra đời, cách áp dụng,… để hiểu rõ hơn về context áp dụng của JTBD. Có thể, nó sẽ phù hợp cho một đối tượng công ty nào đó cần innovation, ví dụ, những công ty rất lớn cỡ IBM).

Theo nhiều tài liệu mình đọc, JTBD có vẻ là bất kì điều gì mà con người muốn hoàn thành: goal, objective, mà cũng có thể là quá trình để hoàn thành mục tiêu đó, là lí do để customer cần tìm tới (nghe khá chung chung, và dễ nhầm lẫn) trong một context cụ thể. Context được nhấn mạnh rất nhiều trong framework này, mình sẽ giải thích thêm ở phần sau.

- JTBD không bao gồm solutions, technology: chỉ thuần tập trung vào problem, vào mục tiêu của user (Ví dụ trong ảnh, JTBD “Search by keyword for documents in the database” không đúng vì đề cập tới techlogy, thay vào đó sẽ là “Retrieve content online)

- Ổn định theo thời gian

Mình nghĩ đây cũng là một điểm hay của framework, khi cố gắng nhìn rõ ràng, sâu sắc vào motivation thực sự của user, thay vì nghĩ xem user họ expect một solution như thế nào. Thực ra, điều này cũng rất consistent với triết lí phát triển sản phẩm tập trung vào con người (human-centric/ user-centric), được phổ biến trong các sản phẩm công nghệ hiện nay. Mình có một giả thiết là: Có thể tầm năm 2000, thời điểm khởi đầu của JTBD, cũng khoảng thời điểm ra đời của "The design of everyday things", quyển sách “gối đầu giường” về design principles của Don Norman, chính là thời điểm design, product dần chuyển trọng tâm innovation sang khám phá con người, thay vì innovation về máy móc.

JTBD chủ yếu bao gồm 3 loại sau (ngoài 3 lên trên, có có các job liên quan - related job/ supporting job). Các cách giải thích này được mình tham khảo từ tổ chức Strategyn với founder là cha đẻ của phương pháp này, và trong cuốn Value proposition design.

- Functional: 1 hành động, 1 task cụ thể nào đó, ví dụ, viết báo cáo (không phải viết báo cáo trên Google docs), cập nhật tin tức (không phải đọc báo, vì báo là một loại sản phẩm)

- Emotional: User muốn có một trạng thái cảm xúc nào đó (ví dụ, tìm kiếm sự yên tâm về các khoản đầu tư của một người với tư cách là người tiêu dùng)

- Social: được đồng nghiệp, bạn bè hoặc những người khác nhìn nhận theo một khía cạnh nào đó, ví dụ: trông như một người tiêu dùng sành điệu

Nhìn chung, mình thấy cách phân chia này có điểm hay ở chỗ, sản phẩm không chỉ serve consumer về mặt tính năng, mà còn đáp ứng các nhu cầu vô hình, “tinh tế” hơn như emotional, hay social.

Chính các nhu cầu emotional, social lại khiến sản phẩm có tính kết dính với user hơn. Và có thể tạo nên lợi thế cạnh tranh cho sản phẩm, bởi, có rất nhiều sản phẩm đang serve user, nhưng sản phẩm có thể mang lại 1 trải nghiệm tốt, một cảm xúc tích cực, thì có thể giữa chân người dùng lâu hơn. Các sản phẩm như mạng xã hội (Instagram, TikTok) không chỉ đáp ứng mặt tính năng là chỉnh sửa ảnh đẹp, chỉnh sửa video nhanh, mà còn đáp ứng nhu cầu social - build sự nổi tiếng cho những người sáng tạo nội dung.

JTBD bao gồm các thành phần sau: job performer (Who - ai thực hiện job này), Jobs itself (What), Process (How), Context (Where/When), và Desired outcome (Why) (ảnh đính kèm).

Là người thực hiện job, trong trường hợp này là user/ consumer (mình tập trung nhiều hơn vào consumer).

Thường được mô tả với 1 động từ, rất straightforward. Ví dụ, trong ảnh minh họa, “I need to research and plan vacation that my partner and children wil enjoy” thì đơn giản hiểu task là “plan family vacation”).

Job process là cách job vốn dĩ được thực hiện, không có sự involve của các sản phẩm. Job map là các step được ra để phân tích cách user thực hiện 1 task.

- Job map: show các step để job executor thực hiện công việc đó (nghĩ về job như thế nào, start từ đâu, plan như thế nào, feedback loop về công việc ntn, kết quả đạt được ra sao), thuần, mà không bị tác động bởi bất kì product, technology, solution nào. Ví dụ, với JTBD là cập nhật tin tức. Job map có thể sẽ là: quyết định xem chủ đề tin tức là gì, tìm kiếm xem nên đọc loại tin tức nào (ví dụ, đọc báo chả hạn), điều chỉnh tốc độ đọc cho phù hợp,…

- Customer journey map: trải nghiệm của user với 1 product/ service nhất định. Ví dụ, trải nghiệm đọc báo trên app VnExpress (tiếp xúc, biết tới sản phẩm ntn; khi mới dùng app thì sẽ ntn; tìm kiếm tin tức ở đâu;…)

Context khác nhau, nhu cầu sẽ khác nhau. Ví dụ, khi chúng ta có nhu cầu uống nhậu với bạn bè/ uống chill một mình/ uống để làm việc,…

Các tác giả đưa ra khái niệm về Desired outcome statement:

- Là needs của users, để "measure success", thế nào là jobs đã hoàn thành

- Các đơn vị thường dùng để đo lường success:

+ Time: ví dụ, nhu cầu thời gian di chuyển từ HN - SG nhanh hơn

+ Ability: khả năng để làm gì đó (Ví dụ, có khả năng đặt, thanh toán vé máy bay online)

+ Effort: mức độ khó khăn, dễ dàng để làm gì đó (Ví dụ: thanh toán vé máy bay dễ dàng hơn)

- Object of control/ qualifier: đối tượng của outcomes, đối tượng mà metrics cần tác động lên; yêu cầu, requirement của jobs

Vậy có phải là 1 metrics và cần thỏa mãn các điều kiện của metrics không? Mình nghĩ nó không hẳn là một metrics, mà nó là một nhóm objectives, nhóm outcomes và cần tìm metrics cụ thể biểu thị cho nó. Ví dụ, framework UX của Google gồm có 5 nhóm metrics, bao gồm Happiness, Engagement, Activation, Retention, và Task Success. Bản thân mỗi loại này đâu phải là 1 metrics, mà nghe cũng rất trừu tượng, thể hiện cho value chung chung. Để đo mỗi mục tiêu đó, mình cần chọn các metrics phù hợp. Do đó, có thể hiểu HEART là desired outcome của UX của 1 hệ thống.

Nhìn chung, JTBD là framework tập trung vào nhu cầu của con người, cũng nằm trong xu hướng design sản phẩm “human-centric”. JTBD giúp người làm sản phẩm aware về 3 loại job của user: functional, emotional và social, trong đó, emotional và social jobs ngày càng được chú trọng hơn ở các sản phẩm. Framework này nhấn mạnh vào outcome: WHY user dùng sản phẩm là có desired outcome nào đó. Mình sẽ viết thêm về cách ứng dụng framework này để research về user với PM, với UX researcher ở phần tiếp theo.

Đọc thêm về JTBD (highly recommend xem video của các practioners nhé để biết câu chuyện áp dụng thực tế, đọc sách khá trừu tượng):

- JTBD in UX Research, Jim Kalbach (Video)

- Practical Jobs To Be Done, Jim Kalbach (Video)

- JTBD, Tony Ulwick (Video)

- Know your customers JTBD (Article)