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

Mình đã giới thiệu chung về những thông tin nền tảng như “xuất xứ”, khái niệm và các thành phần của jobs-to-be-done (JTBD) ở phần 1. Bài này, mình sẽ đi vào phần chính và được mong đợi nhất: framework này áp dụng trong công việc của PM, user researcher như thế nào. Nếu như research có thể coi framework này là một data-driven approach để lượng hóa các nhu cầu chưa được đáp ứng đủ (underserved needs), tìm kiếm segment khách hàng mới, PM có thể sử dụng concept của framework này để phân tích nhu cầu người dùng một cách tổng quan hơn.

Sau khi phân tích rất nhiều thành phần của JTBD, 1 người sử dụng framework như chúng ta có thể viết nó dưới dạng Job story để có thể hiểu rõ hơn về nhu cầu của user, về những gì user đang muốn cố gắng, đạt được, trong một context cụ thể. Job story khác user story ở điểm:

- Job story: tập trung vào vấn đề

- User story: tập trung vào giải pháp (product/ feature) và những giá trị mà giải pháp này mang lại

Flow gồm 5 bước, trong đó, bước 1 và bước 2 mình suy luận. 3 bước sau được tham khảo từ Tony Ulwick, Jim Kalbach, và 1 blog hiếm hoi về cách áp dụng ở app VN.

Trước khi xây dựng một sản phẩm, PM sẽ cần lựa chọn một một task, một mục tiêu nào đó của user để xem user có vấn đề gì để giải quyết hay không. Tương tự như trước bắt đầu một startup, founder sẽ tìm kiếm một vùng nào đó trong cuộc sống hàng ngày của consumer để giải quyết. Ví dụ, function lớn nhất muốn giải quyết là chuyện ăn trưa.

Những người nào có nhu cầu ăn trưa, hãy specific hơn như: địa bàn của họ (ở Việt Nam hay nước ngoài), độ tuổi của họ, nơi làm việc của họ.

Ví dụ, thực hiện interview user để:

- Identify quá trình thực hiện job của họ là gì

- Identify nững expected outcome của họ là gì, họ nghĩ thế nào là job của họ được hoàn thành.

- Họ đánh giá importance của các outcome ntn, tại sao?

- Họ đánh giá satisfaction với các app hiện tại ntn, tại sao?

Note nhẹ. Theo Jim Kalbach (tác giả của nhiều cuốn sách về UX như Mapping experiences), nếu làm kĩ càng hơn, còn có thêm 1 bước nữa để validate outcomes bằng cách phỏng vấn thêm 1 round nữa. (Mình nghĩ đây là 1 process chuẩn chỉnh, đưa ra như proposals).

Bước 5: Prioritize các outcomes (needs) bằng quantitative data. Ví dụ, thực hiện survey với các câu hỏi thang Likert (kiểu cho điểm từ mức 1-5), để đánh giá 2 yếu tố:

- Importance: needs đó quan trọng với user ở mức độ nào

- Satisfaction: họ cảm thấy hài lòng ở mức nào với các solution hiện tại đang giúp họ giải quyết needs đó

Sau khi có kết quả quanti, đối chiếu lại 1 lượt với đánh giá sơ bộ từ bước 4 xem có khớp hay không.

a. Phát hiện underserved needs: dựa trên kết quả quanti từ đánh giá mức độ quan trọng và hài lòng của user, tìm ra các needs quan trọng nhưng chưa được serve tốt, từ đó, nhắm xem mình sẽ lựa chọn giải quyết các vấn đề gì.

b. Một cách segmentation khác: theo JTBD, segmentation là combine của 1 tập những người cùng thực hiện 1 JTBD. Tìm ra các tập segment chưa được đáp ứng tốt.

Quyển sách “Value proposition design” giới thiệu framework để định vị giá trị sản phẩm, công ty. Mảnh ghép đầu tiên của value là customer profile - hiểu user cần gì, để có thể định vị mình cung cấp value gì cho user.

Theo đó, Customer profile bao gồm:

- Customer Jobs: tương đồng rất lớn với concept của JTBD

+ Sách cũng nhấn mạnh Job Context: context có thể có những giới hạn riêng. Ví dụ, gọi điện thoại ở trên máy bay rất khác so với việc gọi lúc đang đi lái xe (1 yếu tố mà UX cần chú ý là accessibility). Một bước quan trọng ở đây là đánh giá Job Importance. Có những job quan trọng hơn trong cuộc sống của user tới mức nếu không thực hiện được đó, nó sẽ gây ra những hệ quả nghiêm trọng.

+ Pains: bad outcomes, obstacles liên quan tới customer jobs (unwanted, undesired outcomes ~ này có thể là những outcomes bị điểm satisfaction thấp

+ Gains: outcomes customer want to achieve (desired outcomes được xếp hạng theo mức độ cần thiết ~ này có thể dựa trên điểm importance của các outcomes).

(Pains và Gains là một chủ đề rộng mà mình sẽ cố gắng đọc thêm và giải thích ở một bài khác)

Dựa trên kết quả của research, PM có thể quyết định xem sẽ giải quyết nhu cầu gì. Tuy nhiên, nhu cầu (Jobs) ở đây hoàn toàn không bao gồm solution. Một số concern của mình:

a. Resource của team thường thiếu, liệu có thể có khả năng để handle một nghiên cứu mà “very very intensive” (dùng theo từ của Jim Kalbach) như vậy hay không?

Những nghiên cứu đòi hỏi công sức nhiều như vậy, thường sẽ có thể đã được handle bởi các công ty lớn. Với một công ty startup có vẻ sẽ không phù hợp, vì startup rất giới hạn nguồn lực. Theo lời của Paul Graham:

Mình nghĩ, nếu nguồn lực không thể quantify, JTBD có thể là một góc nhìn để PM hướng tới.

- Kết hợp cùng kĩ thuật đặt câu hỏi 5W (5 Whys): Hỏi Tại sao 5 lần để tìm được ngọn nguồn: user thực sự cần gì, có nhu cầu gì, muốn outcomes như thế nào ⇒ tìm tới JTBD mà không phụ thuộc solution (Ví dụ. User nói “muốn 1 con ngựa tốt hơn” ⇒ hỏi hỏi hỏi ⇒ tìm ra JTBD là “Di chuyển nhanh hơn”). Có thể đó là lí do tại sao, nó là 1 phần trong theory về Innovation của Giáo sư Clayton Christensen.

- Chú ý tới các yếu tố khác của JTBD: user là ai, context cần thực hiện job là gì (sử dụng Job story).

- Cho mình một cách nhìn rộng hơn về nhu cầu của người dùng: functional, emotional và social.

- “Sense”: phải dùng khả năng phán đoán, đánh giá, thấu hiểu thị trường (tức là sử dụng qualitative data khác: competitor, trend, observation,…) để có một cảm nhận về mức độ quan trọng của các JTBD, đánh giá xem JTBD nào bị miss. Mình hiện tại chưa thể giải thích rõ ràng về điều này, nhưng dựa trên quan sát của mình, đây cũng là cách mà các sản phẩm thành công được hình thành. Lại dẫn lời của Paul Graham:

Khi user tương tác với sản phẩm (solution), họ cũng có những expected outcomes nhất định. Vì user đã từng tiếp xúc với các sản phẩm khác, họ đã dần hình thành mental model sử dụng sản phẩm theo cách nào đó, đến mức UI của nhiều sản phẩm trở nên “chuẩn hóa” (hãy nhìn màn hình của các app như Shopee, Tiki, Lazada, Alipay,…). Nếu không follow theo những hình thức này, product có thể mất thêm thời gian để educate user.

Quá trình sử dụng sản phẩm cũng sẽ phát sinh các vấn đề cho user mà PM cần lưu tâm. JTBD (không bao gồm solution) sẽ nằm ở đâu trong lúc này? Hay PM sẽ dùng Customer journey map để thấu cảm user?

Như đã trình bày, các ứng dụng của framework này đang được chính cha đẻ hay practitioner về research recommend là cần một research chuẩn chỉnh.

Đây là một framework mới phát triển khoảng 20 năm gần đây, tài liệu và cách ứng dụng về nó vẫn còn rất hạn chế. Điều ấy có thể là rào cản để researcher Việt Nam tiếp cận được. Và có thể, hiện tại, mới có một bộ phận nhỏ researcher quan tâm, biết tới và có thể áp dụng JTBD được.

Túm lại là, JTBD là 1 framework để áp dụng chuẩn chỉnh cho researcher, tìm hiểu motivation, needs thực sự của user. Với vị trí là PM, dù có thể không áp dụng trọn vẹn JTBD, mình vẫn có thể học hỏi được concept của nó:

- Chú ý tới needs thực sự của user, needs độc lập với solution

- Cho mình một cách nhìn rộng hơn về nhu cầu của người dùng: functional, emotional và social.

- Xây dựng “Sense”: hãy biết cách kết hợp quali data user trong JTBD, với các loại data khác: competitor, market trend, sự quan sát của chính bản thân,…