Design Thinking Và Job To Be Done Khác Nhau Không?
Bài viết giải thích về ứng dụng 2 Framework / Model đang nổi tiếng trong ngành Product hiện tại
Sorry anh em, bữa giờ bận tư vấn cho vài case nên mình không có time nhiều để viết bài. Tranh thủ mấy nay được nghỉ ngơi nên viết bài mới cho anh em đọc. Đáng lẽ phải viết bài Job Story # User Story # Use Case nhưng mà cách đây vài hôm thì mình tổ chức Workshop Problem Solving thì bọn mình nhận được một vài câu hỏi là vẫn chưa phân biệt được Design Thinking và Job To Be Done. Đấy là lý do hôm nay mình sẽ giải thích cụ thể hơn về từng thứ và sự khác biệt của cả 2. Xem lại cả hai bổ trợ nhau hay là thay thế cho nhau. Sau đấy thì tụi mình sẽ viết bài Job Story anh em sau nhé.
Các Loại Problems
Trước khi phân biệt Design Thinking và Job To Be Done thì mọi người cần phải biết được sự khác nhau giữa các loại Problems là gì đã. Còn mọi người muốn nghe sâu hơn thì hay tham gia nhóm JTBD Việt Nam và inb mình sẽ gửi record Workshop.
Bọn mình đã tổng hợp rất nhiều thể loại các problems nhưng bọn mình quyết định chỉ giữ là định nghĩa 3 problems hay gặp nhất và mang tính chất tổng quan nhất.
Structured Problem: là những vẫn đề mà mọi người có một cấu trúc có thể dễ dàng bóc tách theo công thức toán học, tài chính nào đấy. Hoặc có thể kết nối các ý lại với nhau theo dạng mindmap. Thường để giải quyết vấn đề này người ta hay dùng Issue Tree và MECE để bóc tách.
Complex Problem ám chỉ những vấn đề phức tạp mà phụ thuộc vào nhiều yếu tố khác (Factors). Thông thường khó bóc tách ra vì nó bị phụ thuộc nhiều yếu tố khác. Ví dụ: để phát hiện ra cá mập từ quan sát trên cao. Nhưng chúng ta có thể sử dụng Machine Learning để dự báo xem động vật đang di chuyển dưới nước có phải cá mập hay không.
Ví dụ khác: nếu chúng ta phân tích các yếu tố ảnh hưởng đến nhu cầu mua bảo hiểm thì nó đôi khi phải dùng tới mô hình hồi quy tuyến tính Regression Model.
Như ta có thể thấy nếu ta không kiểm định thống kê hoặc xem Correlation Matrix thì ta sẽ vô tình bỏ qua hiện tượng đa cộng tuyến (2 biến có sự tương quan với). Nếu chúng ta chỉ chạy riêng lẻ các biến trong mô hình hồi quy sẽ dẫn tới sự sai lệch. Nên để xử lý hiện tượng đa cộng tuyến thường người ta sẽ tạo biến điều hòa (Moderator Variable). Hay mọi người có thể hiểu rằng Người có thu nhập (Income) thường sẽ đi đôi với độ tuổi của họ như lớn tuổi hơn (Age).
Wicked Problem là vấn đề nan giải tức rất khó có thể giải quyết triệt để nó hoặc tìm ra 1 solution trọn vẹn giải quyết cho vấn đề đấy. Thường các vấn đề như nạn đói, khủng bố,… sẽ là các vấn đề nan giải. Và Customer Problem cũng là 1 dạng Wicked Problem vì chúng ta không thể nào giải quyết được hết vấn đề của khách hàng. Cũng như không có giải pháp nào khiến họ hài lòng trọn vẹn mà chỉ là 1 phần nào đấy mà thôi. Nên để giải quyết Wicked Problem người ta sử dụng Design Thinking để “Thấu cảm” chuyển dịch sang lăng kính của khách hàng xem họ đang thực sự gặp những vấn đề gì cần được ưu tiên giải quyết trước. Sau đấy xây dựng các giải pháp và chạy thử nghiệm xem giả thuyết (Hypothesis Solution) của chúng ta là chính xác chưa.
Design Thinking Gồm Những Bước Gì?
Design Thinking gồm 5 bước nhưng nó không tuân theo một đường thẳng tuyến tính. Mà có thể là có sự lặp lại ở một vài bước.
Empathize: thấu cảm với người gặp vấn đề và nhìn dưới lăng kính của họ (Customer Problem)
Define: xác định vấn đề cụ thể mà khách hàng thể gặp là gì sau khi chúng ta thấu cảm và phân tích
Ideate: lên ý tưởng cho các giải pháp để giải quyết vấn đề
Prototype: làm bản mẫu thử để kiểm tra xem nó đã thực sự giải quyết vấn đề khách hàng chưa
Test: kiểm tra xem khách hàng có trải nghiệm và đưa ra feedback về giải pháp chúng ta
Như vậy, hai bước Empathize và Define hường dùng để xác định vấn đề của khách hàng là gì. Còn 3 bước cuối sẽ là đề xuất giải pháp và kiểm tra nó.
Chúng ta cũng có nhiều phiên bản nâng cấp hơn như sử dụng Diamond Thinking để kết hợp vào Design Thinking. Tức việc Empathize giúp chúng ta phân kỳ (liệt kê) ra các vấn đề khác nhau mà không bị bó hẹp hoặc giới hạn. Còn việc Define giúp chúng ta hội tụ (gom lại) thành 1 vài vấn đề cần được ưu tiên. Và phần giải pháp cũng như vậy.
Job To Be Done Là Gì?
Cốt lõi của lý thuyết này của chúng tôi không có một thấu hiểu tuy đơn giản nhưng rất mạnh mẽ: khách hàng không mua sản phẩm hay dịch vụ: họ lôi kéo chúng vào cuộc đời mình để tạo ra tiến triển. Chúng tôi gọi tiến triển này là “công việc” họ đang cố gắng hoàn thành và trong cách nói ẩn dụ của mình, khách hàng “thuê” sản phẩm hay dịch vụ để giúp họ giải quyết công việc. “Công việc” là tiến triển mà người ta đang cố gắng tạo ra trong một tình huống cụ thể. Định nghĩa công việc này không chỉ đơn giản là một cách phân loại mới về khách hàng và các vấn đề của họ. Nó là chìa khóa để thấu hiểu tại sao họ đưa ra lựa chọn của mình.
Như anh em có thể thấy khách hàng mua đồ ăn sáng để hoàn thành một công việc nào đấy ở một “Context – ngữ cảnh” cụ thể nào đấy. Nếu chúng ta nhìn lăng kính của người làm sản phẩm chúng ta thường bị bó buộc vào việc giới hạn đối thủ của chúng ta theo hàng dọc như tôi bán bánh mì thì đối thủ của tôi cũng sẽ là bán bánh mì. Nhưng chúng ta dịch chuyển sang lăng kính khách hàng thì họ xem bánh mì chỉ là 1 trong nhiều giải pháp của họ ở ngữ cảnh họ muốn ăn sáng trên công ty mà thôi. Nên đối thủ của chúng ta sẽ rộng hơn rất nhiều.
Một ví dụ khác ở công ty cũ mình là VnExpress ở gần đây ra đấy là VnExpress phát hiện ra khách hàng không có quá nhiều thời gian đọc tin tức trên đường đi (thường 1 bài báo dài 2-3 trang A4). Nên VnExpress đã ra 1 tính năng dùng AI để rút ngắn đoạn văn bản lại cũng như tạo Podcast cho bài viết đấy giúp khách hàng có thể thuận tiện nghe trên đường đi làm.
Design Thinking Và Các Công Cụ Hay Được Sử Dụng
Design Thinking thật ra mỗi công ty, tổ chức lại có những công cụ khác nhau ở mỗi bước. Nhưng theo mình thấy thì thường Design Thinking sẽ hay có các công cụ như sau:
Design Thinking Kết Hợp Job To Be Done
Nhưng sau khi mình sử dụng Empathy Map và Value Proposition Canvas thật sự thì bọn đã gặp rất nhiều trở ngại như phỏng vấn lan man, khách hàng quên pain point đã từng xảy ra, không đào sâu vào được các pain point hoặc không tìm ra được những Pain Point giúp đột phá công nghệ. Rồi ở bước hội tụ vấn đề, bọn mình hay gặp tranh cãi làm sao biết pain point nào là nên quan tâm hàng đầu, rồi pain points nào nên ưu tiên tạo Business Value cho doanh nghiệp. Vậy là bọn mình tranh cãi rất lâu cho việc tìm ưu tiên problems. Rất may sau đấy mình trong quá trình tìm kiếm đo lường Outcomes cho khách hàng thì mình vô tình biết tới Job To Be Done. Và khi ứng dụng vào JTBD để nâng cấp Design Thinking thì bọn mình đã vượt qua được những câu hỏi trên. Đồng thời khi mình đi tư vấn cho các bạn bè, doanh nghiệp, ngân hàng sử dụng JTBD đã rất nhiều tạo ra được tính năng đột phá bằng JTBD giúp metrics tăng lên rất nhiều lần.
JTBD theo chuẩn Global (mình được cấp chứng chỉ) để tiến hành phỏng vấn giúp bọn mình đào sâu vào Pain Points của khách hàng. Không chỉ đào sâu theo chiều dọc mà còn mở rộng theo chiều ngang tức bọn mình có thể hiểu rõ ngữ cảnh mà khách hàng đang gặp nỗi đau đấy. Chưa dừng lại ở đấy JTBD giúp bọn mình lượng hóa được những Outcomes nào quan trọng đối với khách hàng nhưng chưa cảm thấy hài lòng với các giải pháp hiện tại.
Chưa dừng lại ở đấy khi mình và bạn bè mình làm ở Zalo, MoMo, Chợ Tốt hay gặp 1 bài toán Solution là bọn mình thường phải chạy AB Test nên bọn mình sẽ phải setup các chỉ số AB Test. Nhưng đồng thời các team UX hoặc team Product ở các công ty Kỳ Lân hoặc thuần Product thường 1 Solution sẽ lại cho ra nhiều phiên bản Prototypes khác nhau. Làm sao để quyết định chọn 1 Prototype trong 4 Prototypes cũng lại là 1 bài toán nhức đầu của tụi mình. Vì bọn mình không thể nào release chạy 4 versions (Multiple Variants) cùng lúc. Thật ra vẫn chạy được nhưng sẽ tốn nguồn lực hơn hiều so với chạy AB Test. Nên mình từ đấy đã tìm ra cách đo lường các phiên bản Prototype theo Quick and Dirty Test. Các bạn chưa rõ về Quick and Dirty Test / Measure UX / Usability Test thì mọi người đọc bài viết Lượng Hóa Usability thêm nhé.
Chưa hết khi mình đo lường được rồi thì có những Wireflow phức tạp và yêu cầu độ chính xác cao cũng như bug tối thiểu giảm xuống. Như luồng onboard 1 khách hàng doanh nghiệp lên hệ thống Core Banking. Họ cần độ chính xác cao về xử lý task (Task Complete), thời gian xử lý nhanh (Time Success) cũng như số Bug phải ít nhất có thể vì luồng Bank sẽ yêu cầu gắt về độ uy tín (Bug). Cũng như xu hướng các Bank đang chuyển đổi số cần tăng sự hài lòng của khách hàng lên (Satisfaction). Một ví dụ khác mà anh em Bank đang bị dí đó là làm Flow xác thực sinh trắc học theo Nghị Định 2345.
Trước khi có NĐ 2345 thì Bank thường sẽ bắt user làm eKYC (Electronic Know Your Customer) nhưng sau nghị định ra thì anh em phải thêm một số phần như NFC (Near-Field Communication). Nếu anh em bỏ qua bước Usability Test và đo lường mình đảm bảo các bạn đã vô tình skip qua bước NFC khiến cho users gặp problems nhiều nhất. Hôm trước mình đã quick interview 5 Product Owner mà cả 5 người đều mất 10-15 phút loay hoay ở bước NFC của các ngân hàng. Bản thân mình cũng mất 10p mới quét NFC xong
Tại sao lại xảy ra vấn đề như vậy. Đầu tiên, không phải điện thoại hãng nào cũng có thể quét NFC một cách dễ dàng. Ví dụ như Android rất dễ bị NFC lỗi do không hỗ trợ, hoặc Iphone từ đời 7 trở xuống khả năng quét được rất thấp. Thứ 2, hành vi khách hàng là hay sử dụng ốp điện thoại dày nếu không nhắc khách hàng tháo ốp ra thì việc quét rất khó. Thứ 3, khách hàng không biết để vị trí CCCD có gắn chip ở đầu để sát lên điện thoại để quét. Thứ 4, các Bank hay sử dụng hình đại diện hoặc dạng ảnh động như Gif để diễn tả cho users hiểu. Nhưng đấy là góc nhìn của các bạn Product thiết kế. Còn thứ users cần là 1 video hướng dẫn thực tế của 1 người thực tế với các góc nhìn khác nhau. Đến mình và bạn bè mình là dân Tech còn confuse 10p thì bố mẹ hoặc những người low tech hơn thì sao.
Với những dạng flow phức tạp cần làm Measure UX kĩ như 2 ví dụ thường bọn mình sẽ phải sử dụng các loại đo lường phức tạp hơn (4 Dimensions) để tính ra 1 Metrics chung để kết luận đấy Wireflow / Prototype đấy đã ổn với bao nhiêu users được làm Usability Test (lượng hóa Usability song song).
Đấy là lý do bọn mình ra 2 khóa học để nâng cấp Design Thinking cho môi trường các công ty có Data và vấn đề của khách hàng ngày càng phức tạp cũng như với sự đòi hỏi xây dựng 1 Product Innovation từ phía Ban Giám Đốc.
Kết lại
Job To Be Done thực chiến là 1 Framework siêu mạnh mẽ giúp tối ưu hóa 2 bước ở Design Thinking. Nó không chỉ giúp solve problems mà nó còn giúp làm Innovation bằng cách xác định Underserved Needs. Job To Be Done giúp chúng ta dịch chuyển từ 1 người suốt ngày chỉ cắm mắt Laptop vào xây dựng Product sang lăng kính của khách hàng.
Thông tin thêm về mình:
Mình có một thời gian trải nghiệm làm tại các công ty như Onpoint, VnExpress, KAS, Zalo. Mình cũng hiện là Trainer và quản lý chất lượng khối Product Manager của 1 trung tâm đào tạo công nghệ lớn tại Việt Nam. Đồng thời mình cũng đang là một trong những người tiên phong tư vấn ứng dụng bài bản Job To Be Done cho các Bank và công ty công nghệ tại Việt Nam. Một số mình tư vấn đã ứng dụng như Momo, Chợ Tốt, BIDV, Vua Nệm… và một số công ty Startup AI khác. Background của mình thật ra không dính tí gì tới Product cả :v Mình học Quantitative Finance rồi lên Master mình học Applied Economic and Data Science của chương trình Erasmus University Rotterdam với UEH. Mình có một bài viết liên quan về “Hấp thụ công nghệ và bằng chứng về Hội Tụ Câu Lạc Bộ” tại hội nghị Kinh Tế Châu Á, được đăng trên tạp chí khoa học JABES. Mình thấy khá hứng thú về hấp thụ công nghệ nên từ đấy mình chuyển sang làm công nghệ và Product luôn là thế. Mình là dân dữ liệu và định lượng nhưng mình lại có niềm đam với việc tìm hiểm các nhu cầu của khách hàng.
Mình có 2 công ty: 1 công ty về Education, 1 công ty về cửa hàng đồ ăn. Bạn nào ở HCM có thể qua ăn ủng hộ :D
Cộng Đồng Job To Be Done:
Các kênh và group có tên “Job To Be Done Viet Nam” hoặc Job To Be Done VN” hầu như là của mình nên mọi người search là ra.
Linkedin của mình:
Đăng ký để đọc nhiều bài viết hay hơn!!!