Job To Be Done Application From Basic To Advanced

Tất tần về ứng ụng Job To Be Done vào xây dựng Product Management

Oct 22, 2024

Link nhận full các mindmap ở cuối bài

Có rất nhiều người nhầm lẫn Job To Be Done được sáng tạo bởi Ulwick hoặc Bob Moesta. Nhưng thực chất Concept Job To Be Done lần đầu tiên được đề xuất bởi Giáo Sư trường Đại Học Harvard là Theodore Levitt những năm 1970 . Còn Theory được đề xuất bởi Giáo Sư Clayton Christensen cũng thuộc trường Đại Học Harvard. Lý thuyết ban đầu được đề cập tới trong sách “The Innovator’s Solution” năm 2003 nhưng thực sự viết chi tiết và sâu hơn về Job To Be Done là quyển “The Competing Against Luck” năm 2016.

Nhưng khi mình tìm hiểu sâu hơn thì thực chất Ulwick để ứng dựng concept JTBD vào công việc tư vấn đổi mới sáng tạo của ông ở những năm 1991, 1992. Chỉ khác là ông lấy tên là Outcome-Driven Innovation. Rồi sau đấy Ulwick và Clayton cùng nhau đưa JTBD và ODI phổ cập rộng ra công chúng vào những năm đầu 2000. Nhưng những thông tin này cũng chỉ mang tính chất tham khảo nên chúng ta cứ xem như Theory là do bác Clayton đề xuất còn Framework ứng dụng thì do Ulwick đề xuất.

Còn đối với Bob Moesta thì tư duy về Causality kết hợp Experiment, Statistic được hình thành khi bác làm các dự án sản xuất sản phẩm vật lý ở Nhật Bản. Mà bác Bob có đề cập tới những Mentors là các nhà khoa học đổi mới vĩ đại ảnh hưởng tới bác như: Dr.W.Edwards Deming; Dr.Genichi Taguchi; Dr. Willie Hobbs Moore. Sau này thì là Clayton Christensen. Vậy tư duy Causality liên quan gì tới Job To Be Done? Để trả lời câu hỏi này thì tới phần giải nghĩa sâu về Job To Be Done mọi người sẽ hiểu sâu hơn. Nhưng phần lớn các ứng dụng Job To Be Done của bác Bob Moesta vào các sản phẩm vật lý như FMCG, mặt hàng tiêu dùng là khá nhiều.

Cả Ulwick và Bob Moesta đều là những nhà tư vấn đổi mới sáng tạo cho các doanh nghiệp lớn trên toàn thế giới. Mỗi phương pháp luận của họ đều có những ưu điểm và nhược điểm nên khi ứng dụng thì các bạn Practitioner JTBD trên toàn thế giới đều tinh chỉnh và kết hợp cả 2 chứ không dùng thiên 1 cái. Tức hiểu đơn giản là 2 Frameworks sử dụng song song đều được.

2. 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.

Hiểu đơn giản là khách hàng mua 1 sản phẩm không phải vì do người tạo ra nó hay vì tính năng hay ho của nó. Họ mua sản phẩm để hoàn thành công việc / giải quyết vấn đề gì đấy trong cuộc sống của họ.

Ví dụ:

Mua ô tô Kia Morning -> Di chuyển từ địa điểm A tới B
Mua ô tô Maybach -> Functional Job: Di chuyển từ địa điểm A tới B + Social Job: cảm thấy được mọi người nhìn nhận mình là 1 doanh nhân thành công.
Mua ổ bánh mì thịt nướng ăn sáng -> Ăn sáng trên công ty
Mua tô phở ăn sáng -> Ăn sáng ở nhà trước khi lên công ty
Mua 1 ly cà phê Highland -> Trò chuyện với bạn bè
Mua 1 ly cà phê ở quán Hebe -> Làm việc từ xa

Với các ví dụ trên thì mọi người sẽ thấy khách hàng trước giờ mua ly cà phê không phải vì nó ngon hay gì cả. Mà họ mua 1 ly cà phê để có không gian tiếp bạn bè của họ hoặc có không gian để họ làm việc vì quán đấy có ổ cắm và điều hòa.

Các câu trả lời trên dẫn tới 1 cấu trúc viết cho Job To Be Done chung như sau:

Verb + Object + Context

Key của JTBD ở đây chính là Context tức ngữ cảnh mà khách hàng muốn hoàn thành công việc. Mọi người thấy có 1 vài ví dụ mình chỉ viết theo Verb + Object mà không có Context vì nó sẽ phụ thuộc vào Strategy của công ty hoặc tổ chức đấy. Lấy ví dụ, có 1 quán cà phê ở Hà Nội thấy khách hàng hay ngồi uống cà phê của họ tới sáng bình minh thì họ mới đi về. Khi họ nghiên cứu hành vi khách hàng và lý do tại sao thì họ mới phát hiện ra là góc ngồi ngoài đường của họ đối diện hướng mặt trời mọc nên khách hàng là cú đêm rất thích ngồi đâu nói chuyện với nhau vào buổi tối tới bình mình. Như vậy, khác với Highland Coffee JTBD của khách hàng là: “Trò chuyện sau giờ làm việc” thì JTBD của quán cà phê kia là “Trò chuyện vào lúc gần bình minh”. Hoặc mọi người sẽ thấy nhiều quán cà phê khách hàng không thuê không gian để làm việc mà để “Checkin sống ảo”.

Điều này trả lời cho câu hỏi phía trên là tại sao Bob Moesta lại ứng dụng tư duy Causality kết hợp Job To Be Done. Đằng sau việc chọn 1 sản phẩm thì đều có 1 động cơ hoặc nguyên nhân sâu xa nào đấy. Dẫn tới hành vi chọn lựa là sẽ khác nhau. Nhưng bác Bob mở rộng ra thì làm sao tối ưu hóa sản phẩm giúp khách hàng cảm thấy sản phẩm được đáp ứng là tốt nhất bằng phương pháp Run Experiment Taguchi. Ví dụ máy bắn đá mini thì các Factors thiết kế như: sức nặng cục đá, góc điều chỉnh bắn,… là những Factors có thể kiểm soát được bởi người tạo ra nó -> Control Factors. Còn những Factors như sức gió là những Noise Factors khó kiểm soát được hơn. Khi tính ra các chỉ số Control Factors thì sẽ chọn ra 1 bộ chỉ số tương ứng với các Factors giúp tối ưu hóa việc tạo sản phẩm.

3. ỨNG DỤNG JOB TO BE DONE CẤP STRATEGY

Ta sẽ nói tới ứng dụng ở cấp high level trước. Ví dụ nếu 1 quán cà phê có quá nhiều JTBD cùng lúc tức quán phục vụ quá nhiều nhu cầu 1 lúc thì dễ gây ảnh hưởng benefits tới nhau. Ví dụ, ông ngồi làm từ xa hay cắm chốt từ sáng tới tối mua có 1 ly cà phê 30k dẫn tới các bạn mua ly cà phê để trò chuyện 2-3 tiếng không có chỗ ngồi. Về mặt kinh tế thì quán nhìn thì như có khách nhưng thực tế vòng xoay của 1 bàn như vậy là không tối ưu. Nếu bàn đấy bán cho 3 lần khách hàng tới thuê để nói chuyện, mỗi khách là 30k thì như vậy cửa hàng thu được 90k thay vì 30k cho 1 khách. Nhưng chúng ta lại không thể đuổi khách ngồi lâu được. Vậy xử lý như thế nào? Mình đang có dịp trải nghiệm dựa trên nhu cầu khách hàng để làm lại toàn bộ không gian quán giải quyết bài toán trên. Mọi người có thể tới trải nghiệm quán Hebe Sư Vạn Hạnh Quận 10.

Họ segmentation dựa trên JTBD ở cấp chiến lược. Họ thiết kế tầng 2 không có ổ cắm và ánh sáng khá tối để những khách hàng nào muốn làm việc thì phải di chuyển lên tầng 3. Ở tầng 3 thay vì họ thiết kế 1 cái bàn hình chữ nhật dài để 1 khách ngồi, thì họ thiết kế 1 bàn hình vuông nhỏ để 2 khách vẫn có thể ngồi kèm với mỗi bàn đều có 1 ổ cắm.

4. JOB TO BE DONE Ở TẦNG THỰC THI ĐỂ LÀM INNOVATE PRODUCT

4.1 External Job To Be Done By Bob Moesta

Đây là cách gọi của Jim Kalbach để phân biệt JTBD của Ulwick với Bob. Còn lý do để hiểu tại sao gọi là External thì phải apply rồi mới có thể hiểu sâu bản chất được. External JTBD có 2 Models chính được sử dụng trong việc ứng dụng

4.1.1 Timeline

Model này nhìn thì khá là đơn giản, chỉ cần trace ngược từ lúc Consuming sản phẩm tới thời điểm suy nghĩ đầu tiên của khách hàng mua sản phẩm là gì. Nhưng thực tế Model này khi interview thực tiễn rất khó để trace nếu không xem các tips nhỏ rải rác mà Bob Moesta chia sẻ. Mình đã phải đọc khoảng 4-5 quyển sách ứng dụng JTBD của Bob vào trong Marketing, Growth thì họ đều có Script Interview riêng của họ. Nhưng lúc mình apply ở người Việt, mình có điều chỉnh lại trong quá trình phỏng vấn hàng chục đáp viên. Mình có 1 may mắn là trong quá trình đi tư vấn và đi làm hồi ở tập đoàn thì công ty đều khá ủng hộ mình việc đi interview users. Nên mình có khá nhiều cơ hội để thử nghiệm các kịch bản phỏng vấn khác nhau để xem cách hỏi nào giúp khai phá sâu hơn.

4.1.2 Switch (Four Force Progress)

Model này cũng khá đơn giản nếu chỉ nhìn sơ qua. Hiểu nôm na là chúng ta tìm ra lực đẩy (Pull) từ Old Solution của khách hàng sang New Solution (Push). Tức khách hàng gặp phải vấn đề với giải pháp hiện tại của họ ở một ngữ cảnh cụ thể nào đấy và họ đang trình tiến trình tìm kiếm một giải pháp khác hấp dẫn hơn. Ví dụ: nếu sản phẩm mới của họ là app quản tài chính cá nhân thì giải pháp của họ có thể là Excel hoặc 1 tờ giấy.

Nếu chúng ta nhìn lại 2 models trên thì khi kết hợp lại với nhau Bob Moesta nhấn mình của tầm quan trọng trong việc chúng ta nhìn lại lịch sử quá khứ mà khách hàng đã sử dụng các giải pháp cũ và các nhìn về tương lai các tiêu chí mới để thuê 1 sản phẩm / giải pháp mới

Phương pháp luận của Bob Moesta theo mình thấy không hề khó, thứ mà mình thấy khó nhất là quá trình interview users. Mình đã từng nghe rất nhiều chuyên gia interview và sách dạy interview như The Mom Test. Nhưng nếu mọi người được học các tips và lắng nghe bác Bob phỏng vấn thử thì mình cảm thấy chưa ai qua được bác. Hay nói cách khác phương pháp luận này đặt nặng về vấn đề ứng dụng khai thai Outcomes và quá khứ của khách hàng. Nhiều bạn đọc tới đây sẽ cười khẩy kêu ba cái interview mà khó cái gì. Đấy là các bạn chưa gặp những users là Sale họ có khả điều phối và dẫn dắt ngược lại người phỏng vấn dẫn tới bias kết quả. Hoặc những users là các cô chú bán hàng low tech, họ sẽ không hiểu các từ ngữ và thuật ngữ như tính năng công nghệ, giải pháp công nghệ hay trải nghiệm khách hàng,… Mình đã từng phải dành 1 tuần để học ngôn ngữ của các cô chú bán thịt heo để có thể interview cô chú ấy thân thiện và gần gũi hơn trong 1 dự án Social Commerce.

4.2 Internal Job To Be Done (Outcome-Driven Innovation)

Framework của Ulwick mình đánh giá là khó và phức tạp hơn so với External JTBD của bác Bob

Không giống như External thì việc đầu tiên của Framework là xác định Core Functional Job của khách hàng bằng câu hỏi: “Khách hàng mua sản phẩm này để hoàn thành công việc gì?” Sau đấy viết dựa trên cấu trúc “Verb + Object + Context”.

Sau đấy xác định hành trình cốt lõi mà khách hàng làm là để hoàn thành công việc đấy -> Job Map

4.2.1 Job Map

Ulwick đề xuất thông thường customer hoàn thành sẽ trải qua 8 bước trên nhưng không phải Functional Job nào cũng sẽ đầy đủ 8 Steps. Có những Functional Job sẽ chỉ có 5-6 Steps.

Job Step trong Job Map thể hiện “bản chất” bước đấy thực sự mà khách hàng cần thực thi là gì. Ví dụ bước “Gather the desired music” thì thời kỳ máy IPOD của Apple là bạn cần phải tải nhạc về máy tính, up các bài nhạc đã tải về lên IPOD. Nhưng tới bây giờ Spotify thì bạn có nghể thu thập các bài nhạc yêu thích về album của mình ngay trên sản phẩm thay vì phải tải về ngày xưa. Nếu nhìn về Ipod thì chúng ta có bước tải các bài nhạc yêu thích về máy tính nhưng qua Spotify thì lại không vì bản chất Spotify là lưu trữ các bài nhạc Online nên khách hàng chỉ cần search tên bài nhạc và lưu vào album của mình. Điều này dẫn tới sự khác biệt với User Flow.

Có rất nhiều bạn đang sử dụng JTBD, thậm chí 1 trung tâm nào đấy ở Việt Nam đang dạy Job Map giống như User Flow. Nhưng sự thật thì không phải vậy, user flow phát sinh ra khi user trải nghiệm trên nền tảng công nghệ của chúng ta. Ví dụ use case: thanh toán tiền trên app ngân hàng. Thì sẽ có user flow như:

User Flow được thể hiện ở giải pháp là sử dụng thanh toán trên app ngân hàng. Nhưng bản chất của cả User Flow chỉ là giải quyết 1 bước nhỏ là thanh toán tiền. Hiện tại có rất nhiều giải pháp mới như thanh toán bằng quét vân tay, quét Face ID hoặc quét bằng lòng bàn tay. Nếu chúng ta innovate trên user flow thì chỉ là maintain tính năng hiện tại chứ không phải dựa công nghệ mới nhất của thời đại để giải quyết bản chất cốt lõi của khách hàng.

4.2.2 Quantify Outcomes (Measure Pain Point)

Đây là phần khó nhất và phần Long được mời về tư vấn sử dụng nhiều nhất. Vì làm sao để xác định được Pain Points nào có tính ưu tiên cao nhất là vấn đề nan giải của các công ty ở Việt Nam hiện tại. Thú thật khi mình đọc sách và tính toán thử rồi xử lý data thì là 1 nỗi kinh hoàng vì nó quá phức tạp. Nên sau khi apply thành công và giải quyết thực tiễn các bài toán ở Việt Nam bằng đo lường thì mình mới đúc kết lại thành 1 file Excel giúp các công ty có thể chỉ cần nửa tiếng là tính ra được Opportunity Score.

4.2.3 Outcome-Based Segmentation

Có hàng chục cách Segmentation như Demograpic, Behavior Segmentation,… nhưng khi làm Innovation thì Ulwick đề xuất thêm phần Outcom-Based Segmentation:

Ví dụ sau khi xác định được 10 Unmet Outcomes từ 100 Outcomes (phỏng vấn định tính từ Job Map) có điểm số cao nhất thì cluster 10 Unmet Outcomes theo thuật toán Factor Analysis. Hiểu nôm na là chạy các dữ liệu của 10 Unmet Outcomes này để tìm Correlation với nhau và cluster thành 1 nhóm. Thông thường sẽ có 2-3 Groups tức 2-3 Outcome-Based Segmentation (phân khúc khách hàng dựa trên nỗi đau).

5. ADVANCED APPLICATION UPDATE WITH JTBD

2 phương pháp luận trên đã phổ biến ở nước ngoài cách đây từ 2015. Nhưng tới hiện tại với sự phát triển mạnh mẽ của mạng xã hội như Linkedin thì Job To Be Done đã được rất nhiều người ứng dụng và nâng cấp lên. Mình cũng rất may mắn được tiếp xúc với các nâng cấp mới nhất của Global để đem về cho người Việt sử dụng.

Bản nâng cao thì sẽ đòi hỏi phải kết hợp với các Frameworks khác để phù hợp với từng bài toán của doanh nghiệp. Điều này dẫn tới 1 câu hỏi khi mình đi tư vấn là làm sao để phân lớp hoặc trình độ của các công ty đang sử dụng JTBD. Vì cũng có nhiều công ty đang apply JTBD ở Việt Nam như Chợ Tốt vs Grab.

6. THÁP MỨC ĐỘ ỨNG DỤNG JTBD

Tháp mức độ được mình dựa trên concept Shuhari tức phải hiểu nguyên lý bản chất rồi mới tạo thành phiên bản của riêng mình

Tuy nhiên, ở phiên bản của mình thì mình nâng cấp lên 5 levels thay vì 3 tầng như của Shuhari

Khoảng 40% người làm Product ở Việt Nam mình gặp thì khi hỏi biết JTBD ra sao thì họ đều ở tầng level 1, 20% ở level 2, 5% ở level 3 và 35% người level 0 tức chưa nghe bao giờ. Điều này cũng dễ hiểu vì thật ra gần đây cũng bắt đầu có nhiều PO PM hoặc Content Creator đang share viết concept JTBD. Nhưng vẫn chỉ dừng ở mức level 1 là cùng. Còn các bạn ở Level 3 thường là các bạn làm ở các Big Corp có tính chất Quốc Tế.

Nhưng có 1 điểm mình phát hiện ra là có rất nhiều bạn khi apply JTBD đều nhảy cóc vì các bạn không muốn đọc sách hoặc đọc tài liệu gốc. Mà thấy người ta apply nên tôi cũng apply theo cách tôi tự hiểu

Lời khuyên của mình là các bạn cứ apply từng level một trước. Nhưng điều này cũng sẽ dẫn tới 1 mâu thuẫn là công ty của tôi không cho thực hiện bài bản thì làm sao thực thi level 2. Để giải quyết vấn đề này chúng ta cùng tới phần Agile Triangle For JTBD.

7. TRADE-OFF KHI ỨNG DỤNG JTBD

Thông thường các công ty Việt Nam nhất là Startup sẽ không có quá nhiều nguồn lực để làm bài bản Job To Be Done. Họ bị giới hạn (constraint) về thời gian (time) và nguồn lực / ngân sách (resource). Nên cách tốt nhất là chúng ta sẽ điều chỉnh scope ứng dụng của Framework như hình trên. Đối với trường hợp xấu nhất là công ty không cho có thời gian và nguồn lực gì cả thì bọn mình mới phát triển một loạt các Prompt Chat GPT giúp học viên mình hoặc khách hàng của mình đặt ra hypothesis trước để build solution từ đấy deliver sớm để lấy data là feedback của khách hàng. Xem ngoài pain point mà AI gợi ý thì còn pain point nào khác mà khách hàng gặp không.

8. MỐI QUAN HỆ JTBD VÀ TRÍ TUỆ NHÂN TẠO

Gần đây nhiều doanh nghiệp mà mình gặp gỡ thì họ đang xem AI / Generative AI chỉ là 1 Solution thay thế cho Digital Features. Ví dụ như Chợ Tốt thay vì users phải nhập thông tin xe cũ bằng tay lên app thì sử dụng AI để quét chiếc xe ô tô cũ thì các thông số của xe ô tô đấy sẽ tự động nhập lên app.

Tức JTBD rất hữu dụng để xác định pain point mà các giải pháp thủ công hoặc digital app đang gặp phải để từ đấy đề xuất giải AI giúp tăng hiệu suất cho người sử dụng. Vì bản chất AI chỉ là công cụ giúp con người tăng năng suất, giảm thời gian, giảm rủi ro, tăng khả năng thực thi thành công 1 công việc nào đấy. Nhưng quan trọng nhất là AI đấy phải giúp doanh nghiệp tạo ra được giá trị về mặt kinh tế thì lúc đấy việc xây dựng mới có ý nghĩa cho cả khách hàng và doanh nghiệp chứ không phải xây dựng để fancy và đu theo trend thế giới.

9. JOB TO BE DONE Ở GÓC ĐỘ CONSULTANT

Khi ở cấp độ này thì mình phải am hiểu nhiều framework và hiểu rất sâu về ưu và nhược điểm của từng Framework. Dựa vào đề bài doanh nghiệp để mình thiết ra công cụ JTBD hiệu quả nhất. Ví dụ là 1 Framework được bọn mình nâng cấp lên cho 1 vài bài toán.

Nếu bạn đọc đến đây thì mình cảm thấy rất vui vì phần nào đã giúp cho các bạn đọc là dân Product có thể nắm khái quát về các Framework và mức độ ứng dụng của JTBD để từ đấy có thể apply tốt hơn vào việc build ra những Product Innovation cho người Việt. Nếu bạn có những ứng dụng JTBD vào công việc hiệu quả thì nếu không ngại thì có inbox Zalo mình để cùng nhau hẹn cà phê trao đổi chia sẻ để càng ngày cộng đồng Job To Be Done Việt Nam càng phát triển hơn nhé.

10. KẾT LẠI

Job To Be Done là 1 theory về Disruptive Innovation nhưng để ứng dụng vào thực tiễn thì cần có các Framework khác nhau. Framework không phải hoàn hảo nó là 1 pattern do 1 vài nhà đổi mới tích lũy dựa trên khoa học + kinh nghiệm. Nó cần được điều chỉnh lại cũng như kết hợp với các Framework khác để giải quyết bài toán của doanh nghiệp. Tuy nhiên, để điều chỉnh thì chúng ta cũng cần hiểu sâu bản chất của Framework đấy là gì.

Link Mindmap

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ểu 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

Địa Chỉ Quán Mình