Bỏ qua

P2.3 — Jobs to Be Done: hiểu tiến bộ khách hàng muốn đạt được

Module: P2 — Product Discovery Mục tiêu đọc: Hiểu cách xác định Job-to-be-Done (công việc khách hàng cần hoàn thành), tách công việc khỏi giải pháp và kết quả, khám phá tiêu chí thành công, nhận diện lực cản thay đổi, phân khúc theo nhu cầu, chuyển insight thành Value Proposition (đề xuất giá trị) và quyết định thử nghiệm. Nguồn tổng hợp: Jobs to Be Done — A Roadmap for Customer-Centered Innovation; Jobs to Be Done — Theory to Practice; Value Proposition Design Giới hạn của việc đọc: Đọc chương này giúp bạn nhận ra khung tư duy, ngôn ngữ và bộ artifact của JTBD. Nó không thay thế kinh nghiệm thực chiến: kỹ năng phỏng vấn không dẫn dắt khách hàng, khả năng đọc dữ liệu định lượng không bị nhiễu, và bản lĩnh nói "chưa đủ bằng chứng" trước lãnh đạo chỉ hình thành qua các dự án thật.

Mental model — nhìn toàn cảnh trước khi đi vào chi tiết

Khách hàng không thức dậy vì muốn dùng tính năng. Họ gặp tình huống, muốn tạo tiến bộ, rồi "thuê" một giải pháp để tiến lên. Sản phẩm chỉ là phương tiện cho việc đó.

Jobs to Be Done (JTBD — lý thuyết về công việc khách hàng cần hoàn thành) đổi đơn vị phân tích:

  • Từ sản phẩm sang tiến trình khách hàng muốn hoàn thành.
  • Từ nhân khẩu học sang bối cảnh và nguyên nhân lựa chọn.
  • Từ yêu cầu tính năng sang Success Criteria (tiêu chí khách hàng dùng để đánh giá thành công).
  • Từ đối thủ cùng ngành sang mọi lựa chọn giải quyết cùng công việc.
  • Từ tạo ý tưởng trước sang hiểu nhu cầu trước.

Mental model trung tâm, đi theo chín câu hỏi:

  1. Ai thực hiện hoặc chi phối công việc?
  2. Họ đang cố hoàn thành Job-to-be-Done nào?
  3. Bối cảnh nào khiến công việc trở nên quan trọng?
  4. Họ đo thành công ra sao?
  5. Hiện họ dùng cách nào, chịu đau gì, tạo cách chữa tạm nào?
  6. Điều gì kéo họ sang giải pháp mới hoặc giữ họ ở cách cũ?
  7. Phân khúc nào có kết quả quan trọng nhưng chưa được đáp ứng?
  8. Value Proposition nào cải thiện đủ mạnh mà doanh nghiệp vẫn thu được giá trị?
  9. Bằng chứng nào cần có trước khi đầu tư tiếp?

P2.3 - Jobs to Be Done- hiểu tiến bộ khách hàng muốn đạt được — diagram 1

Source mermaid — có thể chỉnh sửa 
flowchart TB
    A["Vai trò khách hàng và bối cảnh"] --> B["Job-to-be-Done (công việc cần hoàn thành)"]
    A --> E["Job Drivers (tác nhân công việc)"]
    B --> C["Job Map (bản đồ công việc)"]
    E --> D["Desired Outcomes (kết quả mong muốn)"]
    C --> D
    C --> F["Cách hiện tại, điểm đau, cách chữa tạm"]
    E --> K["Lực kéo sang giải pháp mới và lực giữ ở cách cũ"]
    F --> G["Mức quan trọng và mức được đáp ứng"]
    D --> G
    K --> G
    G --> H["Phân khúc chưa được phục vụ đủ"]
    H --> I["Value Proposition: cải thiện kết quả khách hàng"]
    F --> I
    K --> I
    I --> L["Chiến lược: doanh nghiệp thu được giá trị"]
    L --> J["Kiểm chứng giả thuyết bằng bằng chứng trước khi đầu tư tiếp hoặc dừng"]

Ba sách cùng đồng ý: khách hàng là điểm xuất phát, nhu cầu phải độc lập với giải pháp, ưu tiên cần dựa trên tầm quan trọng và mức đáp ứng, và ý tưởng phải được kiểm chứng bằng bằng chứng.

Khác biệt nằm ở độ chi tiết và công cụ:

  • Jobs to Be Done — A Roadmap for Customer-Centered Innovation dùng Jobs Atlas (bản đồ tổng hợp insight công việc) để nối công việc, Job Drivers, Pain Points, Success Criteria, Obstacles, giá trị và cạnh tranh trong một khung định tính, tường thuật.
  • Jobs to Be Done — Theory to Practice dùng Outcome-Driven Innovation (ODI) để chuẩn hóa phát biểu nhu cầu, đo Importance và Satisfaction, rồi tìm phân khúc bằng phân tích định lượng.
  • Value Proposition Design dùng Value Proposition Canvas để nối Customer Profile với cơ chế tạo giá trị, sau đó kiểm tra giả thuyết qua Test Card và Learning Card.

Không nguồn nào tự đủ. Jobs Atlas rộng nhưng dễ phụ thuộc diễn giải cá nhân. ODI chặt nhưng tốn nghiên cứu và có thể tạo cảm giác chính xác giả nếu áp dụng cứng nhắc. Value Proposition Canvas nhanh, dễ cộng tác, nhưng đường nối đẹp trên giấy không phải bằng chứng thị trường.

Core — hiểu đúng nền tảng

1. Job-to-be-Done là gì?

Trực giác: khách hàng không mua một sản phẩm vì thích sản phẩm, họ "thuê" nó để hoàn thành một tiến trình trong đời sống hoặc công việc.

Định nghĩa chính xác: Job-to-be-Done là tiến trình hoặc mục tiêu khách hàng muốn hoàn thành trong một bối cảnh nhất định, tồn tại độc lập với sản phẩm và công nghệ.

Vì sao khái niệm này tồn tại: nếu đơn vị phân tích là sản phẩm, nhu cầu sẽ thay đổi mỗi khi công nghệ đổi. Nếu đơn vị phân tích là công việc, nhu cầu ổn định qua nhiều thế hệ sản phẩm, cho phép so sánh giải pháp cũ và mới trên cùng một thước đo.

Ví dụ tối giản:

  • Gắn giải pháp (sai): "dùng ứng dụng để theo dõi chi tiêu".
  • Độc lập giải pháp (đúng): "kiểm soát số tiền có thể chi đến kỳ lương tiếp theo".
  • Quá rộng (sai): "quản lý tài chính cá nhân".
  • Quá hẹp (sai): "xem số dư tài khoản".
  • Trộn kết quả và cảm xúc (sai): "kiểm soát tiền nhanh, chính xác và không căng thẳng".

"Nhanh", "chính xác", "không căng thẳng" là Desired Outcomes (kết quả mong muốn) hoặc Emotional Jobs (công việc cảm xúc), không thuộc phát biểu công việc cốt lõi.

Cách viết trong thực tế, theo Jobs to Be Done — Theory to Practice:

Job statement = verb + object of the verb + contextual clarifier
Phát biểu công việc = động từ + đối tượng + phần làm rõ bối cảnh

Ví dụ: "Xác định số tiền có thể chi tiêu trước nguồn thu tiếp theo."

Một phát biểu tốt cần:

  • Stable over Time (ổn định theo thời gian): giải pháp đổi nhưng công việc còn.
  • Solution Agnostic (độc lập với giải pháp): không chứa tên ứng dụng, nút bấm, màn hình hoặc công nghệ.
  • Customer Perspective (góc nhìn khách hàng): mô tả điều khách hàng muốn hoàn thành, không mô tả thứ công ty bán.
  • Actionable Scope (phạm vi đủ để hành động): không quá rộng để vô nghĩa, không quá hẹp thành một bước nhỏ.
  • Single Dimension (một chiều): không trộn lẫn công việc, kết quả và cảm xúc.

Boundary/failure mode: chọn công việc đủ rộng để mở không gian giải pháp, nhưng tổ chức có thể và muốn phục vụ phần lớn tiến trình. Chọn quá hẹp khiến team chỉ tối ưu một thao tác nhỏ; chọn quá rộng khiến không ai chịu trách nhiệm cải thiện điều gì cụ thể.

2. Công việc, kết quả, điểm đau và lợi ích không đồng nghĩa

Đây là lỗi phổ biến nhất khi các đội mới tiếp cận JTBD: dùng lẫn các từ này như thể chúng thay thế được cho nhau.

Thành phần Câu hỏi trả lời Ví dụ
Job-to-be-Done Khách hàng đang cố làm gì? Xác định số tiền có thể chi
Job Driver (tác nhân công việc) Vì sao việc này quan trọng trong bối cảnh này? Thu nhập biến động, nhiều khoản trừ tự động
Desired Outcome (kết quả mong muốn) Họ đo thành công thế nào? Giảm khả năng chi vượt số tiền an toàn
Pain (kết quả xấu, rủi ro hoặc trở ngại) Điều gì gây khó, chậm, lo lắng hoặc thất bại? Không biết giao dịch nào chưa được ghi nhận
Gain (kết quả hoặc lợi ích mong muốn) Họ muốn nhận thêm giá trị gì? Tự tin ra quyết định mua sắm
Feature (tính năng) Giải pháp làm gì? Dự báo số dư cuối kỳ
Business Outcome (kết quả kinh doanh) Doanh nghiệp muốn đạt gì? Tăng tỷ lệ giữ chân người dùng

Success Criteria trong A Roadmap for Customer-Centered Innovation gần với Desired Outcomes trong Theory to Practice. Cả hai mô tả cách khách hàng đánh giá việc hoàn thành công việc, nhưng nguồn thứ hai đòi hỏi cú pháp chuẩn và khả năng đo lường nghiêm ngặt hơn.

Decision rule: với quyết định nhỏ, mô tả định tính có thể đủ. Với đầu tư lớn hoặc khó đảo ngược, nên chuẩn hóa và đo lường định lượng.

3. Sáu lớp nhu cầu cần tránh trộn lẫn

Jobs to Be Done — Theory to Practice chia nhu cầu thành sáu lớp:

  1. Core Functional Job-to-be-Done — tiến trình chính người dùng muốn hoàn thành.
  2. Desired Outcomes — chỉ số khách hàng dùng để đánh giá từng bước của công việc.
  3. Related Jobs (công việc liên quan) — công việc khác diễn ra trong cùng bối cảnh.
  4. Emotional Jobs và Social Jobs — khách hàng muốn cảm thấy gì hoặc muốn người khác nhìn nhận mình thế nào.
  5. Consumption Chain Jobs (công việc trong chuỗi tiêu dùng) — tìm hiểu, mua, nhận, cài đặt, học dùng, bảo trì, nâng cấp, thải bỏ.
  6. Financial Desired Outcomes (kết quả tài chính mong muốn) — chỉ số người mua hoặc người giữ ngân sách dùng để đánh giá lựa chọn.

Value Proposition Design dùng cấu trúc rộng hơn: Functional Jobs, Social Jobs, Personal/Emotional Jobs, Supporting Jobs (việc hỗ trợ liên quan đến mua, đồng tạo, chuyển giao giá trị).

Hai cách không mâu thuẫn. Cách của Value Proposition Design phù hợp để tổng hợp nhanh trong workshop. Cách của Theory to Practice phù hợp khi cần tách vai trò, xây dựng khảo sát hoặc ra quyết định danh mục sản phẩm.

4. Ai là khách hàng?

Trong sản phẩm đơn giản, người mua và người dùng có thể là một. Trong B2B (business-to-business), y tế, nền tảng hoặc khu vực công, nhiều vai trò có quyền phủ quyết độc lập.

Ba vai trò cơ bản từ Theory to Practice:

Vai trò Insight chính Giá trị cần tạo
End User (người dùng cuối) Công việc chức năng, cảm xúc, xã hội Làm công việc tốt hơn
Purchase Decision Maker (người quyết định mua) Kết quả tài chính, rủi ro khi mua Làm công việc rẻ hơn hoặc an toàn hơn
Product Lifecycle Support Team (đội hỗ trợ vòng đời) Cài đặt, vận hành, bảo trì, xử lý Giảm công sức và tổng chi phí sở hữu

Value Proposition Design bổ sung Influencer, Recommender, Economic Buyer, Decision Maker và Saboteur (người cản trở).

Decision rule (theo cả hai nguồn):

  • Không gọi mọi bên là "khách hàng" rồi trộn dữ liệu.
  • Lập hồ sơ riêng cho từng vai trò có nhu cầu hoặc quyền phủ quyết khác nhau.
  • Lập bản đồ xung đột tiềm tàng: ai dùng, ai trả tiền, ai chịu rủi ro, ai hỗ trợ, ai có thể cản trở.

Failure mode: thiết kế cho End User nhưng bỏ qua Purchase Decision Maker khiến sản phẩm được yêu thích nhưng không bao giờ được mua.

5. Bối cảnh và Job Drivers

Cùng một người có thể ưu tiên khác nhau theo tình huống. Nhân khẩu học không giải thích đủ lý do lựa chọn.

A Roadmap for Customer-Centered Innovation chia Job Drivers thành:

  • Attitudes (thái độ): niềm tin, tính cách, áp lực xã hội.
  • Background (nền tảng): văn hóa, địa lý, kinh tế, kinh nghiệm dài hạn.
  • Circumstances (hoàn cảnh): thời gian, địa điểm, thời tiết, lịch trình, người đi cùng.

Value Proposition Design nhấn mạnh Job Context (bối cảnh thực hiện công việc): cùng một hoạt động nhưng yêu cầu khác nhau khi đang lái xe, ở nhà, đi cùng trẻ em hoặc chịu áp lực thời gian.

Quy trình đúng:

  1. Xác định Job-to-be-Done.
  2. Tìm tình huống làm thay đổi tầm quan trọng của công việc.
  3. Tìm yếu tố làm công việc khó hơn.
  4. Kiểm tra xem các yếu tố đó có tạo ra nhóm nhu cầu khác nhau không.
  5. Chỉ dùng nhân khẩu học để tiếp cận nhóm sau khi sự khác biệt về nhu cầu đã rõ.

Boundary: phân khúc theo tuổi, nghề nghiệp hoặc quy mô tài khoản có thể hữu ích cho phân phối, nhưng không tự chứng minh sự khác biệt về nhu cầu.

6. Từ công việc sang Job Map

Job Map (bản đồ công việc) phân rã công việc cốt lõi thành các bước khách hàng cần hoàn thành, mô tả tiến trình lý tưởng, độc lập với cách dùng sản phẩm hiện tại.

Khung phổ quát từ Theory to Practice: Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude. Đây là khung chống bỏ sót, không phải khuôn mẫu bắt buộc — không phải công việc nào cũng cần đủ tám bước.

Job Map khác Customer Journey Map (bản đồ hành trình khách hàng):

Job Map Customer Journey Map
Mô tả tiến trình lý tưởng cần hoàn thành Mô tả trải nghiệm thực tế với giải pháp hoặc tổ chức
Độc lập giải pháp Gắn liền với kênh, điểm chạm, sản phẩm
Ổn định hơn theo thời gian Thay đổi khi quy trình hoặc kênh thay đổi
Dùng để thu thập tiêu chí thành công Dùng để sửa chữa trải nghiệm hiện tại

Failure mode: dùng Journey Map để thu thập Desired Outcomes sẽ trộn nhu cầu với chi tiết giao diện hiện tại — không thay thế cái này bằng cái kia.

7. Viết Desired Outcome Statement

Mẫu từ Theory to Practice:

Outcome statement = direction of improvement + performance metric + object of control + contextual clarifier

Ví dụ: "Giảm khả năng số tiền được báo là có thể chi bỏ sót giao dịch đang chờ xử lý."

Phát biểu tốt phải đo lường được, có thể tác động qua thiết kế, độc lập giải pháp, chỉ chứa một chiều đo, gắn với một bước của Job Map, và đủ ổn định qua nhiều thế hệ sản phẩm.

Không viết: "Có dashboard đẹp" (giải pháp, chủ quan); "Cảm thấy tốt hơn" (mơ hồ); "Nhanh, dễ, chính xác" (trộn ba chiều đo); "Tăng doanh thu" (kết quả kinh doanh của công ty, không phải của khách hàng).

Desired Outcomes giúp đội ra trade-off có chủ đích: nếu khách hàng coi độ chắc chắn quan trọng hơn độ chi tiết, đội có thể hy sinh phân tích phong phú để lấy một tín hiệu đơn giản, đáng tin cậy.

8. Hiểu cách làm hiện tại, điểm đau và sức ì

Khách hàng luôn có Current Approach (cách tiếp cận hiện tại), ngay cả khi họ không dùng sản phẩm cùng loại: dùng sản phẩm đối thủ, bảng tính, nhờ người khác, ghép nhiều công cụ, trì hoãn, chấp nhận hậu quả, hoặc không làm gì.

Workaround (cách giải quyết tạm thời) là bằng chứng mạnh về nhu cầu và mức cấp bách, nhưng không tự chứng minh thị trường lớn hoặc sự sẵn lòng trả tiền.

Pain Point chỉ có ý nghĩa khi đủ nghiêm trọng để thúc đẩy thay đổi hành vi. A Roadmap for Customer-Centered Innovation cảnh báo các đội thường đánh giá thấp Inertia (sức ì) của hành vi cũ.

Hai loại trở ngại:

  • Obstacles to Adoption (rào cản tiếp nhận): chi phí, thiếu kiến thức, rủi ro, phê duyệt, thay đổi thói quen.
  • Obstacles to Use (rào cản sử dụng): khó học, thiếu hạ tầng, tạo điểm đau mới, không tích hợp vào luồng làm việc.

Năm hướng giảm Inertia: tận dụng hành vi đã có; đưa giải pháp vào dịp sử dụng quen thuộc; gắn với giao dịch khách hàng đã thực hiện; hạ rào cản về giá; làm cho dùng thử và chuyển đổi dễ dàng hơn.

Boundary: một sản phẩm tốt hơn là chưa đủ. Lợi ích chuyển đổi phải lớn hơn chi phí học hỏi, rủi ro, mất dữ liệu, mất uy tín và nỗ lực thay đổi.

9. Cạnh tranh theo công việc

Đối thủ là mọi lựa chọn khách hàng có thể "thuê" để hoàn thành cùng một Job-to-be-Done. Nếu công việc là "ra quyết định chi tiêu an toàn", tập cạnh tranh có thể gồm: ứng dụng tài chính cá nhân, ứng dụng ngân hàng, bảng tính, tiền mặt chia phong bì, hỏi ý kiến bạn đời, không mua, hoặc chấp nhận phí phạt.

Non-consumption (phi tiêu dùng) không có nghĩa là không có cạnh tranh — nó thường là lựa chọn để tránh chi phí, rủi ro hoặc nỗ lực. Cần tìm nguyên nhân và kiểm tra các điều kiện tiên quyết như hạ tầng, khả năng chi trả, niềm tin hoặc quyền truy cập.

Decision rule: so sánh tính năng chỉ có ích sau khi đã biết tính năng đó cải thiện Desired Outcome nào.

10. Từ định tính sang định lượng

  • Qualitative Research (nghiên cứu định tính) tìm ngôn ngữ, công việc, các bước, bối cảnh, điểm đau, cách chữa tạm và Success Criteria.
  • Quantitative Research (nghiên cứu định lượng) đo Importance, Satisfaction, quy mô và sự khác biệt giữa các nhóm.

Boundary: không dùng định tính để khẳng định quy mô phân khúc. Không dùng định lượng để thay thế việc hiểu nguyên nhân.

ODI đo Importance, Satisfaction, sự khác biệt giữa các nhóm, mức thiếu hụt trên từng kết quả. Theory to Practice đưa ra hai biến thể Opportunity Score không được hòa giải trong nguồn:

cơ hội = quan trọng + (quan trọng - hài lòng)
cơ hội = quan trọng + max(quan trọng - hài lòng, 0)

Không dùng công thức này như chân lý phổ quát. Dùng nó như quy ước xếp hạng nhất quán trong cùng một nghiên cứu; không so sánh điểm số giữa các khảo sát có thang đo, mẫu hoặc cách hỏi khác nhau.

Ba trạng thái cần phân biệt: Underserved (chưa được phục vụ đủ), Appropriately Served (được phục vụ phù hợp), Overserved (được phục vụ quá mức).

Decision rule: tìm cơ hội tạo giá trị ở vùng chưa được phục vụ đủ; tìm cơ hội giảm chi phí ở vùng được phục vụ quá mức; giữ Table Stakes (điều kiện tối thiểu phải có) dù chúng không còn là yếu tố khác biệt hóa.

11. Phân khúc theo nhu cầu

Outcome-Based Segmentation tìm ra các nhóm có tập kết quả chưa được đáp ứng khác nhau một cách có ý nghĩa thống kê.

Trình tự: thu thập danh sách Desired Outcomes đủ rộng → khảo sát mẫu đại diện → đo Importance và Satisfaction → phân tích cụm để tìm nhóm có mẫu nhu cầu khác nhau → tìm Complexity Factors (yếu tố gây phức tạp) giải thích sự khác biệt → kiểm tra quy mô, khả năng tiếp cận, giá trị kinh tế → dùng thuộc tính dễ quan sát để tiếp cận nhóm, không thay cho bằng chứng nhu cầu.

Một Persona (chân dung khách hàng) giúp giao tiếp và thiết kế, nhưng không chứng minh một phân khúc nhu cầu tồn tại trên thị trường.

Decision rule về mức nghiêm ngặt: chỉnh thông điệp dùng bằng chứng nhẹ; xây tính năng cần thử nghiệm hành vi; thay đổi nền tảng, mở thị trường mới hoặc mua công ty cần nghiên cứu mạnh hơn.

12. Nối sang Value Proposition

Value Proposition Design tổ chức insight thành hai phía:

Customer Profile: Customer Jobs, Pains, Gains. Value Map: Products and Services, Pain Relievers (cơ chế giảm đau), Gain Creators (cơ chế tạo lợi ích).

Fit (mức phù hợp) trên giấy xuất hiện khi cơ chế tạo giá trị nhắm đúng công việc quan trọng, điểm đau nghiêm trọng và lợi ích thiết yếu — nhưng chưa là bằng chứng khách hàng sẽ dùng hoặc trả tiền.

Trình tự đúng: chọn phân khúc và vai trò cụ thể → điền hồ sơ bằng giả định đã dán nhãn → cập nhật từ nghiên cứu thực tế → xếp hạng ưu tiên → thiết kế ít cơ chế nhưng xử lý tốt nhu cầu quan trọng nhất → nối từng cơ chế với nhu cầu tương ứng → ghi rõ phần chủ động không phục vụ → kiểm chứng bằng hành vi khách hàng.

Boundary: một đề xuất mạnh không xử lý mọi nhu cầu, nó chọn trade-off rõ ràng.

13. Ba mức bằng chứng

  1. Problem–Solution Fit: có bằng chứng về nhu cầu đáng quan tâm và giải pháp đã được thiết kế cho nhu cầu đó.
  2. Product–Market Fit: có bằng chứng sản phẩm tạo giá trị trong thị trường và có Traction (sức kéo thị trường).
  3. Business Model Fit: có bằng chứng doanh thu, chi phí, kênh, nguồn lực và vận hành tạo ra mô hình tồn tại hoặc mở rộng được.

Failure mode: dùng bằng chứng cấp thấp để xin cam kết cấp cao. Lời khen không chứng minh sự sẵn lòng trả tiền. Danh sách email không chứng minh sử dụng lâu dài. Bán trước không chứng minh mô hình mở rộng được. Nhu cầu mạnh của người dùng không thay thế phê duyệt của người mua. Đề xuất hấp dẫn không sửa được cấu trúc chi phí hỏng.

14. Từ insight sang thử nghiệm

Insight không tự trở thành quyết định, cần chuyển thành giả thuyết kiểm chứng được.

Test Card: We believe that (điều tin là đúng) → To verify that, we will (cách kiểm tra) → And measure (dữ liệu cần đo) → We are right if (ngưỡng quyết định, đặt trước).

Learning Card: We believed that → We observed → From that we learned that → Therefore, we will.

Kiểm tra theo thứ tự: nhu cầu và công việc → phản ứng với đề xuất giá trị → mô hình kinh doanh và khả năng cung cấp. Ưu tiên kiểm tra Business Killer (giả thuyết có thể giết mô hình) nhưng tôn trọng sự phụ thuộc trình tự — không kiểm tra giá nếu chưa có bằng chứng nhu cầu, không xây sản phẩm đầy đủ nếu một mô phỏng đã đủ để kiểm tra hành vi.

Applied — đi qua một tình huống sản phẩm (mô phỏng)

Lưu ý: đây là tình huống mô phỏng để minh họa cách áp dụng khung lý thuyết, không phải một case study thực tế được trích dẫn từ nguồn.

Facts

Đội sản phẩm tại một ngân hàng số quan sát: người dùng mở màn hình số dư nhiều lần gần ngày nhận lương. Đây là dữ liệu hành vi — cho biết cái gì xảy ra, không cho biết vì sao.

Current behavior

Sales đề xuất "dashboard tài chính cá nhân". Design đề xuất biểu đồ phân loại chi tiêu. Engineering đề xuất mô hình dự báo. Ba đề xuất xuất phát từ trực giác chức năng, chưa được củng cố bằng bằng chứng về Job-to-be-Done. Đội đặt tên sáng kiến tạm: "giúp khách hàng tránh chi tiêu quá khả năng" — vẫn là một giả thuyết, chưa phải sự thật đã xác nhận.

Underlying need

Đội tách vai trò trước khi nghiên cứu: End User (chủ tài khoản), Purchase Decision Maker (cũng là chủ tài khoản nếu dịch vụ có phí), Product Lifecycle Support Team (vận hành, chăm sóc khách hàng, quản trị rủi ro), và các bên nội bộ có quyền phủ quyết (pháp chế, bảo mật, quản trị mô hình). Artifact: Customer Role Map.

Đội phỏng vấn người từng chi tiêu vượt mức an toàn, trì hoãn mua sắm vì không chắc còn bao nhiêu tiền, dùng bảng tính hoặc chia tiền qua nhiều tài khoản, có thu nhập biến động, hoặc không dùng công cụ quản lý chi tiêu nào cả. Câu hỏi tập trung vào sự kiện quá khứ (theo nguyên tắc của Value Proposition Design: hỏi hành vi đã xảy ra, không hỏi ý định tương lai) — ví dụ: "Lần gần nhất bạn không chắc mình có đủ tiền để mua một món đồ là khi nào? Bạn đã làm gì lúc đó? Thông tin nào bạn cần nhưng không có?"

Kết quả lộ ra ba Job-to-be-Done gần nhau: (1) xác định số tiền có thể chi cho đến nguồn thu tiếp theo, (2) tránh thiếu tiền cho nghĩa vụ bắt buộc, (3) phối hợp quyết định chi tiêu với người trong gia đình. Đội chọn công việc (1) làm phạm vi chính: "Xác định số tiền có thể chi tiêu trước nguồn thu tiếp theo." Job Drivers giả thuyết: thu nhập không đều, giao dịch treo, nhiều tài khoản, chi phí gia đình chia sẻ, hậu quả phí phạt.

Đội lập Job Map: xác định thời điểm nguồn thu tiếp theo → tìm số tiền hiện có → xác định giao dịch chưa phản ánh trong số dư → xác định nghĩa vụ phải trả trước kỳ đó → ước lượng chi tiêu khó tránh → tính phần còn lại có thể chi → theo dõi biến động → điều chỉnh khi hoàn cảnh thay đổi.

Từ đó, một số Desired Outcome Statements được viết: giảm thời gian xác định giao dịch chưa phản ánh trong số dư; giảm khả năng bỏ sót nghĩa vụ phải trả trước nguồn thu tiếp theo; giảm sai lệch khi ước lượng chi tiêu khó tránh; giảm khả năng người dùng hiểu nhầm một số ước lượng là số tiền được bảo đảm. Kết quả cuối cùng chạm tới rủi ro niềm tin và pháp lý — nhiều khả năng là một Table Stake, không phải điểm khác biệt hóa. Artifact: Customer-defined Metrics Repository.

Về cách làm hiện tại: người dùng tự trừ hóa đơn bằng ghi chú, chuyển tiền sang tài khoản tiết kiệm riêng, hỏi ý kiến bạn đời trước khoản lớn, giữ khoản đệm cố định, hoặc bỏ theo dõi vì mệt (Non-consumption). Cách làm cũ có lợi thế: dễ hiểu, tạo cảm giác kiểm soát, không cần tin vào mô hình của ngân hàng. Đội kết luận: một mô hình dự báo "thông minh hơn" có thể thua một con số đơn giản nếu khách hàng không hiểu nguồn gốc của nó — Inertia ở đây đến từ niềm tin, không chỉ từ thao tác.

Options

Customer Profile được tổng hợp: công việc (xác định số tiền có thể chi), pains (giao dịch treo, hóa đơn bị quên, số dư gây hiểu nhầm), gains (quyết định nhanh, tự tin, giải thích được với gia đình). Ba Value Proposition được đưa ra thảo luận:

  1. Một dashboard phân tích đầy đủ.
  2. Một con số duy nhất "có thể chi", kèm giả định và khả năng chỉnh sửa.
  3. Cảnh báo rủi ro ngay trước khi thực hiện một giao dịch lớn.

Decision criteria

Đội không bỏ phiếu chọn sản phẩm. Họ ánh xạ từng phương án với các Desired Outcomes ưu tiên (Fit Map), đồng thời xét rủi ro niềm tin/pháp lý và thời điểm xuất hiện trong hành trình ra quyết định của khách hàng. Phương án 2 xử lý được nhiều kết quả ưu tiên hơn nhưng rủi ro niềm tin lớn. Phương án 3 ít tốn công sức hơn nhưng xuất hiện quá muộn.

Đội thiết kế Test Card đầu tiên: tin rằng người dùng có thu nhập hoặc nghĩa vụ biến động không tin tưởng số dư hiện tại để ra quyết định chi tiêu; để kiểm tra, cho họ xem bản giải thích cách tính số tiền "an toàn để chi" từ dữ liệu giao dịch của chính họ (đã ẩn danh phù hợp quy định) và hỏi họ xác định dữ liệu nào bị thiếu; đo lường khả năng xác định thiếu sót và tỷ lệ muốn dùng lại phương pháp này; đúng nếu >70% người tham gia xác định được ít nhất một khoản thiếu sót và >50% muốn được thông báo khi ra mắt — ngưỡng đặt trước khi chạy thử nghiệm.

Chuỗi thử nghiệm tiếp theo được lên kế hoạch theo mức tăng chi phí và cam kết: phỏng vấn/quan sát → mẫu dữ liệu thủ công cho xem tính toán thật → Wizard of Oz (giao diện thật, vận hành thủ công) nội bộ có kiểm soát → phát hành giới hạn cho nhóm tự nguyện → kiểm tra sẵn lòng trả tiền hoặc tác động giữ chân, chỉ sau khi giá trị sử dụng có tín hiệu rõ.

Decision

  • Không xây dựng dashboard rộng.
  • Tiếp tục thử nghiệm con số "có thể chi" cho nhóm phức tạp cao.
  • Giữ khả năng kiểm tra và sửa đổi giả định cho người dùng.
  • Không dùng ngôn ngữ mang tính đảm bảo.
  • Đo lường rào cản niềm tin song song với hiệu suất hoàn thành công việc.
  • Hoãn quyết định tính phí đến khi có bằng chứng sử dụng lặp lại.

Kết quả thử nghiệm hỗn hợp cũng được đội ghi lại trung thực: một nhóm đánh giá cao con số đơn giản, một nhóm khác không tin dữ liệu tự động và muốn tự kiểm soát hoàn toàn, người có thu nhập ổn định thấy vấn đề không đáng kể, đội vận hành cảnh báo chi phí xử lý tranh chấp nếu con số bị hiểu như một cam kết của ngân hàng. Đội không tuyên bố một thị trường đồng nhất mà tạo hai giả thuyết phân khúc (nhóm phức tạp cao cần dự báo và giải thích; nhóm cơ bản được phục vụ đủ bằng số dư hiện tại và cảnh báo cơ bản) để tiếp tục kiểm chứng.

Authority

Product Lead chịu trách nhiệm về phạm vi công việc và quyết định thử nghiệm nào chạy trước; Research đồng sở hữu chất lượng phát biểu nhu cầu; đội vận hành và pháp chế có quyền phủ quyết đối với việc dùng ngôn ngữ đảm bảo hoặc cách trình bày số liệu tài chính; Portfolio/Sponsor phê duyệt bước tính phí.

Artifact

Customer Role Map, Job Statement, Job Map, Customer-defined Metrics Repository, Value Proposition Canvas, Feature-to-Outcome Catalog, Fit Map, Test Card và Learning Card cho từng vòng thử nghiệm.

Consequence if wrong

Nếu đội bỏ qua bước xác thực niềm tin và triển khai thẳng con số "có thể chi" như một cam kết, hậu quả có thể là: tranh chấp khách hàng khi con số sai lệch do giao dịch treo, chi phí xử lý khiếu nại tăng, rủi ro uy tín và pháp lý nếu khách hàng dựa vào con số để chi tiêu rồi bị phạt. Nếu đội xây dashboard đầy đủ mà không kiểm tra Inertia niềm tin trước, rủi ro là đầu tư lớn vào một giải pháp "tốt hơn về kỹ thuật" nhưng thua cách làm cũ vì khách hàng không tin dữ liệu tự động.

Senior Lens — ra quyết định trong điều kiện không hoàn hảo

1. Governance: ai quyết định gì?

Jobs to Be Done không loại bỏ quyền quyết định, nó làm rõ đầu vào cho các quyết định đó.

Quyết định Người chịu trách nhiệm chính Bằng chứng tối thiểu
Phạm vi công việc Product Lead cùng Research Phỏng vấn, quan sát, phản biện xuyên chức năng
Chuẩn phát biểu nhu cầu Product/Research Governance Quy tắc dùng chung, kiểm tra chất lượng
Phân khúc cơ hội Product Strategy hoặc Portfolio Owner Định tính cộng định lượng phù hợp quy mô
Đề xuất giá trị Product, Design, Marketing Nhu cầu ưu tiên và phản ứng khách hàng
Khả thi kỹ thuật Engineering Lead Prototype và phân tích rủi ro
Khả thi kinh tế Finance, Product, Commercial Giá, chi phí, kênh, hành vi mua hàng
Rủi ro pháp lý/an toàn Chức năng chuyên trách (Pháp chế, Bảo mật) Tiêu chuẩn ngành và bằng chứng bắt buộc
Tăng vốn đầu tư Sponsor hoặc Portfolio Board Bằng chứng tương xứng với tính khó đảo ngược

Value Proposition Design yêu cầu tăng độ nghiêm ngặt của bằng chứng theo vốn, rủi ro và tính không thể đảo ngược của quyết định. Theory to Practice coi việc định nghĩa nhu cầu là vấn đề quản trị xuyên chức năng, không chỉ là kỹ thuật nghiên cứu.

2. Ngôn ngữ chung nhưng không biến thành nghi thức

Hệ thống tối thiểu nên có: Customer Role Map, Job Statement, Job Map, danh sách Desired Outcomes, bằng chứng về bối cảnh/điểm đau/cách chữa tạm/Inertia, Outcome-Based Segment Profile khi cần, Value Proposition Canvas, và nhật ký giả thuyết-thử nghiệm-học hỏi-quyết định.

Không bắt mọi dự án tạo đủ bộ artifact. Artifact tồn tại để giảm mơ hồ trong quyết định quan trọng. Nếu một quyết định nhỏ đã rõ ràng bằng dữ liệu hiện có, không cần một dự án nghiên cứu lớn — cảnh báo về việc dùng công cụ như nghi thức đến từ cả Theory to Practice và Value Proposition Design.

3. Khi nào dùng bản nhẹ, khi nào dùng ODI đầy đủ?

Dùng bản nhẹ khi: quyết định dễ đảo ngược, chi phí thử nghiệm thấp, phân khúc và vai trò đơn giản, đã có dữ liệu hành vi gần với câu hỏi cần trả lời, mục tiêu là sửa đổi thông điệp hoặc một luồng nhỏ. Công cụ: phỏng vấn, Job Map gọn, Value Proposition Canvas, vài thử nghiệm hành vi.

Dùng ODI sâu khi: đầu tư lớn hoặc khó đảo ngược, thị trường có nhiều phân khúc ẩn, nhiều bên mua/dùng/hỗ trợ, danh mục sản phẩm cần tái cấu trúc, tổ chức tranh cãi lâu về ưu tiên, cần so sánh với đối thủ trên một hệ tiêu chí thống nhất.

Trade-off: ODI tăng tính nhất quán nhưng cần chuyên môn nghiên cứu, mẫu phù hợp, thời gian và governance dữ liệu.

4. Quyết định chiến lược sau khi hiểu mức phục vụ

Hiệu suất hoàn thành công việc Giá Nhóm phù hợp Logic chiến lược
Tốt hơn rõ rệt Cao hơn Underserved, sẵn lòng trả Differentiated Strategy
Tốt hơn rõ rệt Thấp hơn Thị trường rộng Dominant Strategy
Kém hơn ở vài chiều Thấp hơn Overserved hoặc Non-consumption Disruptive Strategy
Kém hơn Cao hơn Khách hàng bị hạn chế lựa chọn Discrete Strategy
Cải thiện nhỏ Gần tương đương Khách hàng hiện tại của đương nhiệm Sustaining Strategy

Không dùng các ngưỡng phần trăm trong nguồn như định luật. "Tốt hơn" phải đo bằng Desired Outcomes, không phải số lượng tính năng. Discrete Strategy còn có thể tạo rủi ro đạo đức và danh tiếng khi khai thác tình huống khách hàng bị hạn chế lựa chọn.

5. Các quyền phủ quyết độc lập

Một cơ hội có thể chết vì: người dùng không muốn, người mua không trả tiền, kênh không phân phối, đội hỗ trợ không vận hành được, pháp lý không cho phép, cấu trúc chi phí không tồn tại, hành vi chuyển đổi quá khó, đề xuất dễ bị sao chép, hoặc thị trường chưa có điều kiện tiên quyết.

Value Proposition Design nhấn mạnh ba lớp Desirability, Feasibility, Viability. A Roadmap bổ sung Inertia và điều kiện tiếp nhận. Insight mạnh ở một lớp không thay thế bằng chứng ở các lớp khác.

6. Dấu hiệu cảnh báo

Job-to-be-Done sai phạm vi: chứa tên sản phẩm/tính năng, là cảm xúc mơ hồ, bao phủ cả cuộc đời khách hàng, chỉ mô tả một thao tác trong giải pháp hiện tại, trộn tốc độ/chất lượng/an toàn vào câu công việc.

Nghiên cứu yếu: hỏi ý định tương lai thay vì sự kiện quá khứ, chỉ phỏng vấn khách hàng hiện tại, bỏ qua khách hàng của đối thủ và người chưa tiêu dùng, trình bày giải pháp quá sớm, dùng lời nói thay hành vi, gọi vài cuộc phỏng vấn là một phân khúc đã xác thực.

Ưu tiên sai: đếm số lần một Pain được nhắc đến nhưng bỏ qua mức nghiêm trọng, dùng số liệu trung bình toàn thị trường che khuất nhóm bị thiếu hụt, chọn nhu cầu vì khớp công nghệ sẵn có, chọn ý tưởng qua bỏ phiếu nội bộ, so sánh tính năng thay vì kết quả, bỏ qua Table Stakes vì chúng không khác biệt hóa.

Thử nghiệm sai: đặt ngưỡng sau khi đã thấy dữ liệu, dùng click như bằng chứng mua hàng, dùng bán trước như bằng chứng mô hình mở rộng được, tối ưu giải pháp trước khi xác thực công việc, không tách bạch quan sát/diễn giải/quyết định, chạy thử nghiệm mãi nhưng không bao giờ quyết định.

7. Lúc không nên dùng JTBD một cách máy móc

  • Sản phẩm hạ tầng kỹ thuật sâu: Emotional Jobs có thể ít quan trọng hơn độ tin cậy, tương thích, bảo mật, tổng chi phí sở hữu. Vẫn dùng công việc chức năng và kết quả kỹ thuật, không ép ngôn ngữ cảm xúc.
  • Hệ thống mà "khách hàng" là một hệ thống khác: mô tả tác nhân con người/tổ chức chịu trách nhiệm về kết quả, cùng hợp đồng kỹ thuật giữa các hệ thống.
  • Khủng hoảng an toàn hoặc tuân thủ: yêu cầu pháp lý có thể là ràng buộc bắt buộc dù khách hàng không ưu tiên nó.
  • Thị trường hoàn toàn mới: khách hàng khó đánh giá giải pháp chưa từng thấy. Kết hợp quan sát vấn đề với prototype và thí nghiệm hành vi.
  • Quyết định vận hành nhỏ: không cần khảo sát ODI đầy đủ nếu thay đổi rẻ, an toàn, dễ đảo ngược.
  • Thị trường quá nhỏ cho phân tích cụm đáng tin cậy: dùng bằng chứng định tính, dữ liệu hành vi, phân tầng thủ công và ghi rõ mức độ bất định.

8. Tổ chức năng lực

Theory to Practice đề xuất một nhóm chuyên gia nhỏ hoặc Innovation Center of Excellence để giữ chuẩn mực nghiên cứu và kho insight. Cách này giảm biến thiên nhưng có rủi ro tạo ra một nhóm "thầy tế", xa rời đội delivery.

Mô hình cân bằng: nhóm chuyên gia sở hữu tiêu chuẩn, đào tạo, thực hiện nghiên cứu phức tạp và quản lý kho Desired Outcomes; product team tham gia phỏng vấn, diễn giải, thử nghiệm; Engineering/Design/Marketing/Sales/Operations phản biện tính khả thi; lãnh đạo danh mục sở hữu quyết định về vốn. Không để nhóm nghiên cứu độc quyền "sự thật về khách hàng"; không đào tạo toàn công ty sâu như một practitioner nếu họ chỉ cần dùng output.

Value Proposition Design bổ sung: tổ chức cần vận hành ở hai chế độ — khám phá trong môi trường bất định, và thực thi mô hình đã biết. Cùng một governance sẽ làm một trong hai chế độ thất bại.

Quick reference

Checklist khám phá một Job

Bước Cần rõ Artifact tối thiểu
1. Chọn vai trò Ai dùng, mua, trả, hỗ trợ, chặn? Customer Role Map
2. Định nghĩa công việc Động từ, đối tượng, bối cảnh; không chứa giải pháp Job Statement
3. Phân rã tiến trình Khách hàng cần hoàn thành bước nào? Job Map
4. Thu thập tiêu chí Thành công được đo ra sao ở từng bước? Danh sách Desired Outcomes
5. Hiểu hiện trạng Cách hiện tại, điểm đau, cách chữa tạm, sức ì Process Map hoặc ghi chép
6. Tìm bối cảnh Yếu tố nào làm đổi mức quan trọng hoặc độ khó? Danh sách Job Drivers
7. Ưu tiên Quan trọng, đáp ứng, quy mô, tiếp cận, kinh tế Hồ sơ cơ hội
8. Thiết kế giá trị Cơ chế nào giúp giảm đau hoặc tạo lợi ích? Value Proposition Canvas
9. Kiểm tra giả thuyết Cần đúng điều gì, đo gì, ngưỡng nào? Test Card
10. Quyết định Tiếp tục, sửa, đổi hướng, dừng Learning Card và nhật ký quyết định

Quy tắc viết

Thành phần Viết đúng Tránh
Công việc Động từ + đối tượng + bối cảnh Tên sản phẩm, tính năng, cảm xúc
Kết quả Hướng cải thiện + chỉ số + đối tượng kiểm soát "Nhanh, dễ, tốt hơn"
Pain Hậu quả, trở ngại hoặc rủi ro cụ thể Đảo ngược máy móc từ gain
Gain Lợi ích có mức độ và bối cảnh Danh sách mong ước không có ưu tiên
Giải pháp Cơ chế tác động đến nhu cầu Tuyên bố xử lý mọi nhu cầu
Bằng chứng Hành vi, ngưỡng đặt trước, nguồn rõ ràng Ý kiến nội bộ hoặc lời khen

Decision rules

  • Job-to-be-Done chứa giải pháp: viết lại.
  • Một phát biểu chứa nhiều chiều đo: tách ra.
  • Người mua khác người dùng: nghiên cứu riêng.
  • Định tính cho biết mẫu hình; chưa chứng minh quy mô.
  • Định lượng cho biết phân bố; chưa giải thích nguyên nhân.
  • Nhu cầu quan trọng nhưng đáp ứng thấp: xem xét tạo giá trị.
  • Nhu cầu ít quan trọng nhưng đầu tư quá mức: xem xét giảm chi phí.
  • Pain nhẹ hơn chi phí chuyển đổi: Adoption yếu.
  • Canvas đẹp nhưng chưa có hành vi: chưa có Fit.
  • Quyết định càng khó đảo ngược, yêu cầu bằng chứng càng mạnh.

Thuật ngữ sử dụng trong chương

Thuật ngữ tiếng Anh Acronym Giải nghĩa tiếng Việt Ngữ cảnh sử dụng
Jobs to Be Done JTBD Lý thuyết về công việc khách hàng cần hoàn thành Khung tư duy tổng thể
Job-to-be-Done — Công việc khách hàng muốn hoàn thành Đơn vị phân tích cốt lõi
Core Functional Job-to-be-Done — Công việc chức năng cốt lõi Định nghĩa thị trường
Functional Job — Tác vụ hoặc mục tiêu thực tế Nhu cầu chức năng
Emotional Job — Trạng thái cảm xúc khách hàng muốn đạt được hoặc tránh Thiết kế, thông điệp
Social Job — Cách khách hàng muốn được người khác nhìn nhận Định vị, thương hiệu
Related Job — Công việc khác diễn ra trong cùng bối cảnh Mở rộng giải pháp
Consumption Chain Job — Công việc mua, cài đặt, dùng, bảo trì, thải bỏ Trải nghiệm vòng đời
Job Driver — Yếu tố làm thay đổi mức quan trọng hoặc độ khó của công việc Bối cảnh, phân khúc
Job Statement — Phát biểu công việc được chuẩn hóa Chốt phạm vi
Job Map — Bản đồ các bước của công việc Thu thập kết quả mong muốn
Customer Journey Map — Bản đồ trải nghiệm của khách hàng qua các điểm chạm Sửa chữa hành trình hiện tại
Desired Outcome — Chỉ số khách hàng dùng để đo lường thành công Ưu tiên nhu cầu
Desired Outcome Statement — Phát biểu kết quả mong muốn được chuẩn hóa Nghiên cứu ODI
Success Criteria — Tiêu chí khách hàng dùng để đánh giá thành công Thiết kế trade-off
Outcome-Driven Innovation ODI Đổi mới dựa trên kết quả mong muốn Quy trình JTBD định lượng
Importance — Mức quan trọng Đo lường nhu cầu
Satisfaction — Mức được đáp ứng Đo lường khoảng trống
Opportunity Score — Điểm xếp hạng cơ hội Ưu tiên outcome
Underserved — Chưa được phục vụ đủ Cơ hội tạo giá trị
Overserved — Được phục vụ quá mức Cơ hội giảm chi phí
Table Stakes — Điều kiện tối thiểu phải có Thiết kế cạnh tranh
Outcome-Based Segmentation — Phân khúc theo tập kết quả chưa được đáp ứng Chọn thị trường mục tiêu
Complexity Factor — Yếu tố làm công việc trở nên khó hơn Giải thích khác biệt giữa phân khúc
Current Approach — Cách khách hàng đang dùng để giải quyết công việc Phân tích hiện trạng
Workaround — Cách giải quyết tạm thời Tín hiệu điểm đau và tính cấp bách
Pain Point — Điểm đau trong tiến trình Tìm kiếm cơ hội
Inertia — Sức ì giữ khách hàng ở cách làm cũ Rào cản tiếp nhận
Non-consumption — Trạng thái không dùng giải pháp nào Cơ hội hoặc cảnh báo
Value Proposition — Tập hợp các lợi ích được hứa hẹn cho khách hàng Nối insight với giải pháp
Value Proposition Canvas — Khung nối hồ sơ khách hàng và bản đồ giá trị Thiết kế đề xuất
Customer Profile — Hồ sơ Jobs, Pains và Gains của khách hàng Tổng hợp nhu cầu
Value Map — Bản đồ sản phẩm, cơ chế giảm đau và tạo lợi ích Thiết kế giải pháp
Pain Reliever — Cơ chế giảm đau Ánh xạ giá trị
Gain Creator — Cơ chế tạo lợi ích Ánh xạ giá trị
Fit — Mức phù hợp giữa nhu cầu, đề xuất và thị trường Đánh giá tiến triển
Problem–Solution Fit — Mức phù hợp vấn đề–giải pháp Bằng chứng sớm
Product–Market Fit — Mức phù hợp sản phẩm–thị trường Bằng chứng sử dụng
Business Model Fit — Mức phù hợp mô hình kinh doanh Bằng chứng kinh tế
Test Card — Thẻ giả thuyết, phép kiểm, chỉ số và ngưỡng Thiết kế thử nghiệm
Learning Card — Thẻ tách bạch quan sát, diễn giải và hành động Quản trị quá trình học hỏi
Wizard of Oz — Giao diện có vẻ hoàn chỉnh nhưng vận hành thủ công Thử nghiệm trước khi tự động hóa
Business-to-business B2B Giao dịch giữa doanh nghiệp với doanh nghiệp Bối cảnh có nhiều vai trò mua và dùng
Qualitative Research — Nghiên cứu định tính Khám phá nguyên nhân và bối cảnh
Quantitative Research — Nghiên cứu định lượng Đo lường và phân khúc
Trade-off — Sự đánh đổi có chủ đích giữa các mục tiêu Thiết kế, chiến lược
Governance — Cơ chế về quyền quyết định và kiểm soát Tổ chức quá trình discovery

Nguồn và giới hạn

Jobs to Be Done — A Roadmap for Customer-Centered Innovation

Đóng góp chính: Jobs Atlas hệ thống hóa insight; phân biệt Functional Jobs và Emotional Jobs; Job Drivers (thái độ, nền tảng, hoàn cảnh); phân tích cách làm hiện tại, cách chữa tạm, Pain Points và Inertia; cạnh tranh theo công việc bao gồm Non-consumption; chiến lược giảm rào cản tiếp nhận và sử dụng; nhấn mạnh trade-off và Success Criteria.

Giới hạn: một số case study về công nghệ và điều kiện thị trường đã cũ; cách tổng hợp rộng phụ thuộc kỹ năng người nghiên cứu; nghiên cứu sơ cấp sâu tốn nhiều thời gian; Emotional Jobs có thể ít rõ ràng trong sản phẩm hạ tầng kỹ thuật hoặc hệ thống.

Jobs to Be Done — Theory to Practice

Đóng góp chính: phân loại sáu lớp nhu cầu; chuẩn hóa Job Statement và Desired Outcome Statement; Job Map phổ quát; kết hợp nghiên cứu định tính và định lượng có hệ thống; Outcome-Based Segmentation; ma trận chiến lược tăng trưởng; governance xuyên chức năng và mô hình năng lực nội bộ.

Giới hạn: nhiều bằng chứng hiệu quả do Strategyn hoặc khách hàng của Strategyn cung cấp; tiêu chí thành công giữa các case study không đồng nhất; các ngưỡng phần trăm và Opportunity Score là quy tắc kinh nghiệm, không phải định luật; hai công thức tính điểm cơ hội trong nguồn chưa được hòa giải; phương pháp đầy đủ đòi hỏi mẫu lớn, kỹ năng thống kê, ngân sách và thời gian đáng kể; lịch sử phương pháp được kể chủ yếu từ góc nhìn tác giả.

Value Proposition Design

Đóng góp chính: Customer Profile và Value Map; phân biệt ba cấp độ Fit; nối Value Proposition với mô hình kinh doanh; kỷ luật giả thuyết qua Test Card và Learning Card; thư viện mẫu prototype và thử nghiệm; governance theo mức độ bất định, chi phí và tính khó đảo ngược; cách xử lý nhiều vai trò trong B2B và nền tảng nhiều phía.

Giới hạn: canvas chỉ cấu trúc cuộc trò chuyện, không tự xác thực thị trường; điểm số nội bộ và bỏ phiếu không phải bằng chứng; lượt click, email và bán trước có thể tạo tín hiệu sai lệch; một số công cụ, chi phí, nền tảng và case study đã lỗi thời; nguồn không giải quyết đầy đủ các vấn đề về suy luận nhân quả, đạo đức thử nghiệm giả lập, hoặc mọi yêu cầu pháp lý.

Giới hạn chung của chương

Jobs to Be Done giúp xác định đúng vấn đề và tiêu chí giá trị. Nó không bảo đảm: công nghệ khả thi, kênh phân phối hoạt động, khách hàng sẽ trả tiền, mô hình kinh doanh có lợi nhuận, tổ chức thương mại hóa tốt, thị trường sẵn sàng, hoặc sản phẩm an toàn/hợp pháp/khó sao chép.

Dùng Jobs to Be Done như một hệ điều hành cho các câu hỏi trong giai đoạn discovery, không như một công thức dự báo chắc chắn. Insight tốt giúp giảm rủi ro chọn sai vấn đề. Bằng chứng thị trường, khả năng cung cấp và mô hình kinh doanh vẫn quyết định kết quả cuối cùng. Và cuối cùng: hiểu khung này qua đọc là điểm khởi đầu, còn năng lực phỏng vấn không dẫn dắt, đọc dữ liệu không nhiễu, và ra quyết định dưới áp lực thời gian thực chỉ hình thành qua việc trực tiếp làm discovery trên sản phẩm thật.