P9.1 — Ra quyết định khi bằng chứng chưa hoàn hảo

Module: P9 - Senior Product Practice

Mental model

Bất định tồn tại trong mọi quyết định sản phẩm. Đội thường chưa biết chắc:

• Khách hàng có vấn đề đủ nghiêm trọng không.
• Giải pháp có làm thay đổi hành vi không.
• Đội có xây, triển khai và vận hành được không.
• Doanh thu có vượt chi phí không.
• Thay đổi có gây hại cho niềm tin, an toàn, thương hiệu, quyền riêng tư hoặc hệ thống hiện tại không.

Nhiệm vụ của Product Manager không phải sản xuất nhiều tính năng nhất. Nhiệm vụ là giảm rủi ro quan trọng nhất bằng chi phí bằng chứng phù hợp, sau đó tăng cam kết nguồn lực theo mức tin cậy đạt được.

Đọc chương không thay thế trải nghiệm dự án. Người đọc cần thực hành với khách hàng thật, dữ liệu thật, giới hạn ngân sách thật và người có quyền quyết định thật. Khung trong chương giúp tổ chức việc suy nghĩ và ghi chép; nó không biến bằng chứng yếu thành sự thật.

Bốn nguồn chính đóng góp bốn lớp:

1. Good Strategy Bad Strategy định khung thách thức và lựa chọn cách tiếp cận tập trung.
2. Testing Business Ideas phân rã ý tưởng thành giả thuyết, thử nghiệm, bằng chứng, nhận định và hành động.
3. Lean Analytics cung cấp logic chọn chỉ số, giai đoạn, ngưỡng và quy tắc quyết định.
4. Shape Up giới hạn rủi ro giao hàng bằng Appetite (ngân sách thời gian), định hình công việc và cơ chế ngắt mạch.

Các nguồn bổ sung, không thay thế nhau. Bằng chứng khách hàng mạnh không chứng minh đội giao được trong sáu tuần. Giao đúng hạn không chứng minh sản phẩm tạo giá trị. Chỉ số tăng không tự chứng minh quan hệ nhân quả. Chiến lược rõ không miễn trừ kiểm tra giả định.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A["Thách thức chưa rõ"] --> B["Chẩn đoán"]
    B --> C["Chính sách định hướng"]
    C --> D["Chuỗi hành động"]
    D --> E["Đặt hoặc xem lại ngân sách thời gian"]
    E --> F["Phân rã giả định"]
    F --> G["Chọn rủi ro lớn nhất"]
    G --> H["Đặt chỉ số, ngưỡng và mức tin cậy"]
    H --> I["Thiết kế thử nghiệm"]
    I --> J["Thu bằng chứng"]
    J --> K["Tạo nhận định"]
    K --> L["Cổng quyết định<br/>Tiêu chí • hậu quả • artifact ghi căn cứ<br/>Người có thẩm quyền phê duyệt quyết định"]
    L --> M{"Quyết định theo<br/>ngưỡng, tin cậy và<br/>giới hạn rủi ro"}

    M -->|"Đạt ngưỡng; rủi ro chấp nhận được"| N["Tăng hoặc giữ cam kết nguồn lực"]
    N --> O{"Xem lại ngân sách<br/>thời gian?"}
    O -->|"Có"| E
    O -->|"Không"| G

    M -->|"Chưa đạt ngưỡng; còn cách kiểm tra khác"| G
    M -->|"Cần đổi hướng chiến lược"| B
    M -->|"Rủi ro vượt giới hạn hoặc không còn cơ sở tiếp tục"| P["Dừng cam kết và tái phân bổ nguồn lực"]

    Q["Chiến lược"] -.-> B
    Q -.-> C
    R["Thử nghiệm"] -.-> F
    R -.-> I
    S["Phân tích"] -.-> H
    T["Giới hạn giao hàng"] -.-> E
    T -.-> P

Chuỗi quyết định:

Giả thuyết → Thử nghiệm → Bằng chứng → Nhận định → Hành động

Dữ liệu chưa gắn với giả thuyết chưa phải bằng chứng. Bằng chứng chưa tạo nhận định chưa giúp ra quyết định. Nhận định không có hành động chỉ là ghi chú. Một thử nghiệm đạt ngưỡng không xác thực toàn bộ ý tưởng.

Mọi quyết định vật chất phải trả lời chín câu hỏi:

1. Sự thật nào đã biết?
2. Hành vi hiện tại là gì?
3. Nhu cầu nền là gì?
4. Có lựa chọn nào?
5. Tiêu chí chọn là gì?
6. Quyết định nào được đưa ra?
7. Ai có thẩm quyền?
8. Artifact nào ghi căn cứ?
9. Quyết định sai gây hậu quả gì?

Core

1. Định khung thách thức trước khi kiểm tra giải pháp

Trực giác

Yêu cầu “xây chatbot” thường che giấu câu hỏi quan trọng hơn: khách hàng đang gặp khó khăn nào, tại bước nào và giải pháp nào đáng kiểm tra trước.

Định nghĩa chính xác

Kernel (hạt nhân chiến lược) gồm ba phần:

1. Diagnosis (chẩn đoán): Giải thích bản chất thách thức và cơ chế gây ra kết quả.
2. Guiding Policy (chính sách định hướng): Chọn cách tiếp cận tổng thể và nêu điều không làm.
3. Coherent Actions (chuỗi hành động nhất quán): Các hành động phối hợp để thực hiện chính sách.

Mục tiêu tăng trưởng, danh sách tính năng và tuyên bố tầm nhìn không tự tạo thành chiến lược.

Vì sao cần

Nếu đội chấp nhận giải pháp do bên có quyền lực nêu ra, đội dễ đo mức hoàn thành tính năng thay vì giảm rủi ro. Chẩn đoán đúng giúp đội tìm đúng cơ chế, giới hạn phạm vi và tránh tối ưu triệu chứng.

“Hiệu suất kém” chỉ mô tả kết quả. Chẩn đoán phải chỉ ra nguyên nhân có thể hành động, như “người dùng mới chưa đạt giá trị cốt lõi trong phiên đầu vì quy trình đăng ký trì hoãn hành động chính”.

Ví dụ tối thiểu

• Chẩn đoán: Người dùng mới rời đi vì chưa đạt giá trị trong phiên đầu, không phải vì thiếu tính năng.
• Chính sách: Rút ngắn thời gian tới giá trị; không tăng thu thập dữ liệu trong đăng ký.
• Hành động: Rút gọn đăng ký, tạo dữ liệu mẫu, đưa hành động giá trị đầu tiên lên trước.

Dùng trong công việc

PM viết Kernel trước khi mở backlog. Product, Design và Engineering kiểm tra cơ chế gây vấn đề. Data xác minh mẫu hình. Sales và Support bổ sung bối cảnh khách hàng. Legal, Safety, Compliance hoặc Finance tham gia khi chẩn đoán chạm ranh giới chuyên môn.

Senior PM yêu cầu bằng chứng đối nghịch, không chỉ bằng chứng ủng hộ. Dùng Create-Destroy (tạo rồi phá): viết giả thuyết thuận, sau đó viết điều có thể khiến giả thuyết sai.

Ví dụ:

• Thuận: “Gợi ý tự động giúp quản trị viên trả lời nhanh hơn.”
• Đối nghịch: “Gợi ý tự động làm tăng thời gian kiểm tra và sửa, nên quản trị viên bỏ dùng.”

Thất bại và ranh giới

Mục tiêu lớn không có đường hành động là mục tiêu viển vông. Chẩn đoán quá chung không hướng dẫn ưu tiên. Chẩn đoán không được xem như sự thật cuối cùng; bằng chứng mới có thể buộc đội sửa chiến lược.

2. Tìm đòn bẩy và đặt mục tiêu cận kề

Trực giác

Trong tương lai không chắc chắn, dự báo xa thường kém giá trị hơn một mục tiêu gần, có thể kiểm tra và mở thêm lựa chọn.

Định nghĩa chính xác

Leverage (đòn bẩy) là điểm mà nỗ lực tập trung tạo tác động lớn hơn tương đối. Đòn bẩy có thể đến từ:

• Anticipation (tiên liệu): yếu tố có thể dự đoán trong thị trường hoặc hành vi đối thủ.
• Pivot Point (điểm tựa): nút then chốt làm thay đổi hệ thống.
• Concentration (sự tập trung): dồn lực đủ mạnh để vượt hiệu ứng ngưỡng.

Proximate Objective (mục tiêu cận kề) là mục tiêu gần, khả thi với năng lực hiện có, tạo vị thế cho quyết định kế tiếp.

Vì sao cần

Mục tiêu cận kề giảm phạm vi dự báo, giới hạn chi phí sai và tạo tín hiệu học. Nó không thay thế tầm nhìn; nó nối tầm nhìn với hành động có thể kiểm tra.

Ví dụ tối thiểu

“Trở thành nền tảng cộng đồng dùng trí tuệ nhân tạo hàng đầu” không chỉ rõ phép kiểm tra.

“Trong sáu tuần, xác định liệu quản trị viên có dùng gợi ý trả lời để giảm ít nhất 20% thời gian xử lý câu hỏi lặp lại hay không” là mục tiêu cận kề.

Dùng trong công việc

PM ghi:

• Phân khúc.
• Hành vi cần quan sát.
• Khoảng thời gian.
• Chỉ số.
• Ngưỡng.
• Ranh giới an toàn.
• Người sở hữu quyết định.

Thất bại và ranh giới

Mục tiêu cận kề không được thu hẹp thành chỉ số dễ đạt nhưng không liên quan giá trị. Một đội có thể đạt tỷ lệ nhấp cao mà không tạo giữ chân, doanh thu hoặc an toàn.

3. Đặt Appetite trước khi đặt cược xây dựng

Trực giác

Đội cần biết ý tưởng đáng nhận bao nhiêu thời gian trước khi bắt đầu. Nếu thời gian mở vô hạn, phạm vi và rủi ro sẽ phình ra.

Định nghĩa chính xác

Appetite (ngân sách thời gian) là mức thời gian tối đa tổ chức sẵn sàng đặt cược cho ý tưởng. Đây là thời gian cố định, phạm vi linh hoạt; không phải Estimate (ước tính thời gian cần thiết).

Có thể dùng:

• Small Batch (lô nhỏ): khoảng một đến hai tuần.
• Big Batch (lô lớn): tối đa một chu kỳ sáu tuần.

Vì sao cần

Appetite giới hạn rủi ro giao hàng và buộc đội chọn phần quan trọng nhất. Nó không thay thế kiểm tra mức khách hàng mong muốn, khả thi vận hành, khả thi tài chính, pháp lý hoặc an toàn.

Ví dụ tối thiểu

Ý tưởng thư viện trả lời được cấp hai tuần để kiểm tra giá trị thủ công. Ý tưởng chỉ được đưa vào chu kỳ sáu tuần khi vấn đề, luồng chính và rủi ro lớn đã rõ.

Dùng trong công việc

Pitch (bản đề xuất đã định hình) cần có:

1. Vấn đề.
2. Ngân sách thời gian.
3. Giải pháp ở mức thô.
4. Hố thỏ và cách né.
5. Kết quả mong đợi.
6. Phần cố ý không làm.
7. Phạm vi có thể gọt.

Thất bại và ranh giới

Dùng Appetite như hạn chót áp lên phạm vi cố định tạo làm thêm giờ, cắt chất lượng và che giấu rủi ro. Gia hạn không được mặc định. Nếu bất định lớn vẫn còn, đội cần dừng và định hình lại.

4. Phân rã ý tưởng thành giả định có thể kiểm tra

Trực giác

Một ý tưởng không phải một niềm tin duy nhất. Nó là tập điều kiện phải đúng.

Định nghĩa chính xác

Ba nhóm rủi ro tối thiểu:

Nhóm	Câu hỏi	Ví dụ
Desirability Risk	Khách có vấn đề, muốn giá trị, tiếp cận được và đổi hành vi không?	Quản trị viên có dùng gợi ý không?
Feasibility Risk	Tổ chức có xây và vận hành được không?	Hệ thống có tạo gợi ý đúng thời gian và đúng quyền không?
Viability Risk	Doanh thu, giá và chi phí có bền vững không?	Chi phí tạo gợi ý có thấp hơn giá trị tiết kiệm không?

Thường kiểm tra Desirability trước, sau đó Feasibility và Viability. Không áp dụng máy móc nếu rủi ro pháp lý, an toàn hoặc kỹ thuật có thể loại bỏ ý tưởng ngay.

Vì sao cần

Phân rã giúp đội kiểm tra điều có thể giết ý tưởng, thay vì chọn câu hỏi dễ trả lời.

Ví dụ tối thiểu

Không viết: “Khách hàng muốn, đội xây được và sản phẩm có lãi.”

Viết riêng:

• Quản trị viên có gặp câu hỏi lặp đủ thường xuyên không?
• Gợi ý có giảm thời gian xử lý không?
• Dữ liệu có thể dùng đúng quyền không?
• Chi phí tạo gợi ý có phù hợp không?

Dùng trong công việc

Assumptions Map (bản đồ giả định) dùng hai trục:

• Tầm quan trọng.
• Mức bằng chứng.

Vùng	Hành động
Quan trọng, thiếu bằng chứng	Thử nghiệm sớm
Quan trọng, đã có bằng chứng	Kiểm tra chất lượng và theo dõi
Ít quan trọng, thiếu bằng chứng	Chưa ưu tiên
Ít quan trọng, đã có bằng chứng	Lưu tham chiếu

Đội cốt lõi gồm Product, Design và Engineering. Mời Data, Legal, Safety, Compliance, Finance, Sales hoặc Research khi giả định cần chuyên môn.

Thất bại và ranh giới

Đội thường thử điều dễ thay vì điều có thể giết ý tưởng. Bản đồ giả định không phải danh sách việc cần làm; nó là công cụ ưu tiên bằng chứng.

5. Viết giả thuyết và Test Card

Trực giác

Một giả thuyết tốt cho người khác biết đội tin điều gì, sẽ quan sát gì và kết quả nào làm thay đổi hành động.

Định nghĩa chính xác

Giả thuyết phải Testable (có thể kiểm tra), Precise (chính xác) và Discrete (đơn nhất).

Mẫu:

Chúng tôi tin rằng [phân khúc] sẽ [hành vi quan sát được] trong [bối cảnh và thời hạn] vì [động cơ]. Bằng chứng ủng hộ nếu [chỉ số] đạt [ngưỡng], đồng thời [chỉ số bảo vệ] không vượt [giới hạn].

Test Card (thẻ thiết kế thử nghiệm) là Decision Contract (hợp đồng quyết định), không chỉ là tài liệu nghiên cứu.

Vì sao cần

Viết trước ngưỡng và hành động chống Quick Closure (đóng vội vàng), giảm việc đổi tiêu chuẩn sau khi thấy kết quả và giúp người có thẩm quyền xem xét cùng một căn cứ.

Ví dụ tối thiểu

Chúng tôi tin rằng quản trị viên cộng đồng có hơn 500 thành viên sẽ gửi hoặc chỉnh sửa ít nhất 30% gợi ý trong hai tuần vì gợi ý giảm thời gian soạn. Thời gian sửa trung vị dưới 60 giây; tỷ lệ khiếu nại không tăng.

Giả thuyết đối nghịch:

Quản trị viên sửa phần lớn nội dung vì không tin giọng điệu và độ chính xác; tổng thời gian không giảm.

Dùng trong công việc

Test Card ghi:

• Giả thuyết.
• Đối tượng.
• Bối cảnh.
• Yếu tố được kiểm tra.
• Cách chạy.
• Thời lượng.
• Chỉ số.
• Ngưỡng.
• Chỉ số bảo vệ.
• Hành động khi đạt, không đạt hoặc chưa rõ.
• Chủ sở hữu.
• Điều kiện dừng sớm.

Thất bại và ranh giới

Giả thuyết gộp nhiều niềm tin khiến kết quả không giải thích được. “Khách thích và đội xây được” không phải một giả thuyết có thể kiểm tra tốt.

6. Chọn chỉ số, ngưỡng và chỉ số bảo vệ

Trực giác

Một chỉ số chỉ hữu ích khi nó thay đổi quyết định. Nhiều số liệu không tạo nhiều hiểu biết hơn.

Định nghĩa chính xác

One Metric That Matters (một chỉ số quan trọng nhất hiện tại) là chỉ số trả lời câu hỏi rủi ro nhất trong giai đoạn hiện tại. Nó không phải chỉ số duy nhất được thu thập và không tồn tại vĩnh viễn.

Line in the Sand (ngưỡng quyết định) là ranh giới hành động được đặt trước khi xem kết quả.

Guardrail Metric (chỉ số bảo vệ) phát hiện tác hại mà chỉ số chính có thể che giấu.

Vì sao cần

Chỉ số chính tập trung chú ý. Ngưỡng biến quan sát thành quy tắc. Chỉ số bảo vệ ngăn đội tối ưu cục bộ.

Ví dụ tối thiểu

• Chỉ số chính: tỷ lệ gợi ý đủ điều kiện được gửi hoặc chỉnh sửa rồi gửi.
• Ngưỡng: ít nhất 30%.
• Chỉ số bảo vệ: khiếu nại không tăng, thời gian sửa trung vị dưới 60 giây.

“Tổng lượt nhấp” yếu hơn “tỷ lệ quản trị viên gửi gợi ý trên tổng số gợi ý đủ điều kiện” vì chỉ số sau nối trực tiếp với hành vi cần kiểm tra.

Dùng trong công việc

Quy trình:

1. Xác định mô hình kinh doanh.
2. Xác định giai đoạn.
3. Chọn giả định rủi ro nhất.
4. Chuyển giả định thành câu hỏi.
5. Chọn chỉ số trả lời câu hỏi.
6. Đặt ngưỡng và hành động trước thử nghiệm.
7. Đổi chỉ số khi nút thắt đổi.

Ngưỡng có thể dựa trên yêu cầu kinh doanh, mốc ngành có bối cảnh tương đương, mốc nội bộ, hiệu suất hiện tại hoặc mức cải thiện tối thiểu đáng đầu tư. Ngưỡng không phải chân lý thống kê.

Ghi thêm:

• Cỡ mẫu tối thiểu.
• Khoảng thời gian.
• Phân khúc.
• Độ tin cậy cần thiết.
• Điều kiện dữ liệu hợp lệ.
• Vùng chưa kết luận.

Kiểm tra:

• Tử số và mẫu số.
• Dữ liệu thiếu và trùng lặp.
• Phân khúc.
• Mùa vụ.
• Ngoại lệ.
• Cỡ mẫu.
• Thay đổi sản phẩm trong thời gian chạy.
• Tương quan và quan hệ nhân quả.

Thất bại và ranh giới

Không hạ ngưỡng sau khi xem dữ liệu. Nếu định nghĩa ban đầu sai, ghi quyết định mới và lý do; không viết lại lịch sử. Chỉ số đạt nhưng khiếu nại, lỗi, hoàn tiền, chi phí hoặc rủi ro an toàn vượt giới hạn thì không phải thành công.

7. Chọn thử nghiệm theo mức cam kết

Trực giác

Bằng chứng yếu có thể đủ để bỏ một hướng rẻ. Bằng chứng mạnh hơn cần thiết trước khoản đầu tư lớn, khó đảo ngược.

Định nghĩa chính xác

Discovery (khám phá) tìm vấn đề, động cơ, ngôn ngữ, phân khúc và hướng giải pháp. Validation (xác thực) kiểm tra hành vi, thanh toán, khả năng cung cấp và kinh tế đơn vị trong bối cảnh gần thật.

Bằng chứng mạnh dần theo bốn chiều:

1. Ý kiến yếu hơn sự kiện.
2. Điều người dùng nói yếu hơn điều họ làm.
3. Mô phỏng yếu hơn bối cảnh thật.
4. Cam kết nhỏ yếu hơn cam kết lớn.

Vì sao cần

Đội tránh nhảy thẳng từ ý tưởng sang xây dựng. Chi phí thử nghiệm tăng theo độ chân thực; mức độ thử phải phù hợp với chi phí sai.

Ví dụ tối thiểu

Thử nghiệm	Bằng chứng chính	Giới hạn
Phỏng vấn khách hàng	Vấn đề và hành vi quá khứ	Không chứng minh ý định tương lai
Paper Prototype	Cách hiểu luồng	Không chứng minh nhu cầu thị trường
Clickable Prototype	Hoàn thành tác vụ	Không chứng minh giá trị bền vững
Feature Stub	Quan tâm trong sản phẩm thật	Cần minh bạch và cơ chế tắt
Concierge	Giá trị do dịch vụ thủ công	Chưa chứng minh tự động hóa
Wizard of Oz	Trải nghiệm gần tự động	Rủi ro lừa dối cao
Presale	Sẵn sàng trả	Cần khả năng cung cấp và điều khoản rõ
Extreme Programming Spike	Khả thi kỹ thuật	Mã thử không tự đủ điều kiện sản xuất

Dùng trong công việc

Ba câu hỏi chọn thử nghiệm:

1. Đang kiểm tra Desirability, Feasibility hay Viability?
2. Hiện có bao nhiêu bằng chứng?
3. Còn bao lâu tới quyết định lớn hoặc hết Appetite?

Quy tắc:

• Biết ít: thử nhanh và rẻ.
• Cam kết lớn: yêu cầu bằng chứng mạnh.
• Giả thuyết quan trọng: dùng nhiều loại thử nghiệm độc lập.
• Sản phẩm khó đảo ngược: kiểm tra sâu trước xây.
• Rủi ro kỹ thuật riêng biệt: chạy Spike có giới hạn thời gian.

Thất bại và ranh giới

Một cuộc phỏng vấn tốt không chứng minh người dùng sẽ trả tiền. Prototype tốt không chứng minh khả năng vận hành. Thanh toán thử không chứng minh giữ chân. Không có thử nghiệm đơn lẻ nào xác thực toàn bộ mô hình kinh doanh.

8. Phân biệt dữ liệu, bằng chứng, nhận định và hành động

Trực giác

Con số chỉ có ý nghĩa khi biết nó thuộc giả thuyết nào, nhóm nào, bối cảnh nào và thay đổi quyết định nào.

Định nghĩa chính xác

• Dữ liệu: Quan sát thô.
• Bằng chứng: Dữ liệu gắn với giả thuyết, phân khúc và bối cảnh.
• Nhận định có thể hành động: Giải thích bằng chứng có ý nghĩa gì.
• Hành động: Tiếp tục, đổi hướng, dừng hoặc chạy phép thử phân biệt.

Vì sao cần

Phân biệt bốn lớp ngăn đội nhảy từ số liệu sang kết luận nhân quả.

Ví dụ tối thiểu

• Dữ liệu: 10% gợi ý được gửi.
• Bằng chứng: Trong năm cộng đồng, quản trị viên gửi 10% gợi ý; thấp hơn ngưỡng 30%.
• Nhận định: Người dùng không tin nội dung chưa chỉnh sửa, nhưng có thể dùng mẫu để sửa.
• Hành động: Bỏ tự động gửi; kiểm tra thư viện mẫu có chỉnh sửa.

Dùng trong công việc

Learning Card (thẻ học hỏi) ghi:

• Điều tin trước thử nghiệm.
• Điều quan sát được.
• Điều học được.
• Mức tin cậy.
• Điều làm tiếp.

Decision Record (hồ sơ quyết định) ghi thêm:

• Quyết định.
• Người có quyền.
• Ngày.
• Bằng chứng thuận và nghịch.
• Giả định còn mở.
• Hệ quả.
• Phần bằng chứng mất hiệu lực.
• Điều kiện xem xét lại.
• Chủ sở hữu hành động.

Thất bại và ranh giới

Tương quan không tự là nhân quả. Chỉ số tăng có thể do mùa vụ, thay đổi phân khúc, thay đổi sản phẩm hoặc lỗi đo. Dữ liệu thiếu hoặc mẫu sai không trở thành bằng chứng mạnh chỉ vì có nhiều dòng.

9. Ra quyết định Pivot, Persevere, Kill

Trực giác

Mục tiêu của thử nghiệm không phải bảo vệ ý tưởng. Mục tiêu là chọn hành động tốt hơn với thông tin hiện có.

Định nghĩa chính xác

• Persevere (tiếp tục): giả thuyết được ủng hộ, chỉ số bảo vệ ổn và mức tin cậy đủ cho cam kết kế tiếp.
• Pivot (đổi hướng): bằng chứng bác bỏ hướng hiện tại nhưng chỉ ra hướng khác về khách hàng, vấn đề, giải pháp, giá trị hoặc mô hình.
• Kill (dừng): giá trị kỳ vọng không đáng chi phí, kinh tế không đạt, hoặc rủi ro pháp lý, an toàn, thương hiệu không chấp nhận được.
• Tiếp tục kiểm tra: bằng chứng mâu thuẫn, mẫu yếu hoặc thử nghiệm không phân biệt được giả thuyết cạnh tranh.

Vì sao cần

Quy tắc trước giúp tổ chức giảm thiên kiến chìm vốn và bảo vệ nguồn lực cho cơ hội tốt hơn.

Ví dụ tối thiểu

Kết quả vượt chỉ số chính nhưng phá chỉ số bảo vệ không được gọi là Persevere. Đội sửa thiết kế hoặc dừng. Kết quả dưới ngưỡng nhưng cho thấy nhu cầu ở phân khúc khác có thể dẫn tới Pivot, không tự động Kill.

Dùng trong công việc

Mỗi quyết định phải ghi quyền quyết định. Đội sản phẩm có thể tiếp tục trong ngân sách được duyệt. Người có quyền đặt cược quyết định tăng vốn, đổi chiến lược, dừng hoặc gia hạn ngoài ngân sách.

Thất bại và ranh giới

Dừng không phải thất bại nếu nó ngăn tổ chức đầu tư tiếp vào hướng yếu. Đổi hướng lớn làm một phần bằng chứng cũ mất hiệu lực; đội phải kiểm tra lại giả định liên quan.

Applied

Tình huống mô phỏng: ConnectUp

Tình huống sau là mô phỏng. Tên công ty, số liệu và kết quả chỉ phục vụ minh họa, không phải dữ liệu ngành hay kết quả nghiên cứu đã công bố.

Bối cảnh

ConnectUp cung cấp nền tảng quản lý cộng đồng. Khách hàng lớn phản ánh quản trị viên mất nhiều thời gian xử lý câu hỏi lặp lại. Ban lãnh đạo đề xuất “chatbot trí tuệ nhân tạo trả lời tự động”.

Tín hiệu ban đầu:

• Một số email phàn nàn.
• Một yêu cầu từ khách hàng lớn nhất.
• Danh sách vé hỗ trợ có câu hỏi lặp.
• Niềm tin của lãnh đạo rằng tự động hóa là hướng chiến lược.

Tín hiệu chưa đủ để cam kết xây chatbot.

Case 1: Chọn vấn đề cần kiểm tra

Facts: Vé hỗ trợ có câu hỏi lặp; email phàn nàn nói quản trị viên mất thời gian; chưa có phân tích thời gian theo từng bước; chưa biết người dùng gặp khó ở tìm thông tin, soạn, phê duyệt hay gửi.

Current behavior: Quản trị viên tự tìm thông tin, tự soạn câu trả lời và tự quyết định đăng. Ban lãnh đạo yêu cầu chatbot tự động.

Underlying need: Quản trị viên cần giảm công việc lặp lại nhưng vẫn giữ quyền kiểm soát nội dung, giọng điệu và thời điểm đăng.

Options:

1. Xây chatbot tự động trả lời.
2. Xây gợi ý trả lời để quản trị viên sửa và gửi.
3. Xây thư viện mẫu có tìm kiếm.
4. Dùng dịch vụ thủ công để kiểm tra giá trị trước.

Decision criteria:

• Có kiểm tra được nhu cầu trong hai tuần không.
• Có giới hạn rủi ro sai nội dung không.
• Có đo được thời gian tiết kiệm không.
• Có giữ quyền kiểm soát cho quản trị viên không.
• Có tránh cam kết xây dựng sớm không.

Decision: Dùng hai tuần khám phá và xác thực bằng phân tích vé, quan sát quy trình và Concierge; chưa xây chatbot.

Authority: PM sở hữu cách kiểm tra trong Appetite được duyệt. Product leadership sở hữu quyết định cấp vốn xây dựng. Legal hoặc Safety sở hữu phê duyệt rủi ro thuộc thẩm quyền của họ.

Artifact: Kernel, Assumptions Map, Pitch, Test Card.

Consequence if wrong: Nếu chọn chatbot quá sớm, đội có thể xây tính năng đắt nhưng không giải quyết đúng bước nghẽn, đồng thời tạo rủi ro sai nội dung và mất niềm tin.

Case 2: Ưu tiên giả định

Facts: Có tín hiệu về câu hỏi lặp; chưa biết tỷ lệ đủ lớn; chưa biết gợi ý có giảm thời gian; chưa biết dữ liệu có quyền sử dụng; chưa biết kinh tế đơn vị.

Current behavior: Đội đang nói về công nghệ trước khi đo hành vi và chi phí.

Underlying need: Tổ chức cần biết giả định nào có thể giết ý tưởng trước khi cấp vốn lớn.

Options:

1. Kiểm tra mức khách hàng mong muốn trước.
2. Chạy Spike kỹ thuật trước.
3. Tính chi phí mô hình trước.
4. Kiểm tra pháp lý và quyền dữ liệu trước.
5. Làm tất cả cùng lúc.

Decision criteria:

• Rủi ro có thể loại bỏ ý tưởng ngay không.
• Chi phí kiểm tra.
• Thời gian tới quyết định.
• Mức phụ thuộc giữa giả định.
• Mức độ không thể đảo ngược.

Decision: Kiểm tra quyền dữ liệu và nhóm nội dung rủi ro cao song song với Desirability; dùng Spike kỹ thuật nhỏ chỉ khi cần xác minh điểm có thể chặn hướng. Không xây hệ thống trước.

Authority: Product xác định thứ tự học. Legal, Compliance hoặc Safety có quyền chặn thử nghiệm thuộc ranh giới của họ. Engineering sở hữu kết luận khả thi kỹ thuật trong Spike.

Artifact: Assumptions Map, Experiment Guidelines, Spike note.

Consequence if wrong: Nếu bỏ qua quyền dữ liệu, thử nghiệm có thể phải hủy, gây chi phí và rủi ro pháp lý. Nếu kiểm tra kỹ thuật quá sớm, đội có thể tối ưu hệ thống cho nhu cầu chưa tồn tại.

Case 3: Thử nghiệm gợi ý

Facts: Chưa có sản phẩm gợi ý; quản trị viên cần xử lý câu hỏi lặp; nội dung sai có thể gây khiếu nại; tự động đăng chưa được chấp thuận.

Current behavior: Quản trị viên soạn thủ công và kiểm tra trước khi đăng.

Underlying need: Quản trị viên cần bản nháp hữu ích, có thể chỉnh sửa nhanh, không mất quyền phê duyệt.

Options:

1. Concierge minh bạch.
2. Wizard of Oz ẩn người xử lý.
3. Prototype tương tác.
4. Chatbot tự động trong sản phẩm thật.
5. Phỏng vấn về ý định sử dụng.

Decision criteria:

• Mức gần hành vi thật.
• Chi phí và thời gian.
• Rủi ro gây hiểu lầm.
• Khả năng đo thời gian và hành vi.
• Khả năng dừng nhanh.
• Phù hợp với nhóm nội dung rủi ro thấp.

Decision: Dùng Concierge. Năm cộng đồng tham gia. Nhân viên hỗ trợ soạn gợi ý từ tài liệu đã duyệt. Quản trị viên được thông báo con người đang hỗ trợ. Quản trị viên có thể gửi, sửa hoặc bỏ. Không tự động đăng.

Authority: PM sở hữu thiết kế thử nghiệm. Quản trị viên sở hữu quyết định gửi nội dung của cộng đồng mình. Legal hoặc Safety phê duyệt ranh giới dữ liệu và nội dung. Người được chỉ định có Kill Switch.

Artifact: Test Card, Experiment Guidelines, bảng sự kiện đo lường, log quyết định.

Consequence if wrong: Nếu dùng Wizard of Oz mà không minh bạch, người tham gia có thể hiểu sai năng lực sản phẩm và tổ chức chịu rủi ro niềm tin. Nếu tự động đăng, lỗi nội dung có thể lan rộng trước khi có cơ chế dừng.

Case 4: Đọc kết quả

Facts: Sau hai tuần, 10% gợi ý được gửi nguyên văn; 42% được chỉnh sửa rồi gửi; thời gian xử lý giảm 24%; không tăng khiếu nại; quản trị viên thường sửa lời chào, giọng điệu và chi tiết cộng đồng.

Current behavior: Quản trị viên không chấp nhận nhiều gợi ý nguyên văn nhưng dùng một phần làm bản nháp.

Underlying need: Người dùng cần khởi tạo câu trả lời có thể chỉnh sửa, không cần tự động đăng hoàn toàn.

Options:

1. Gọi thử nghiệm thất bại vì gửi nguyên văn dưới 30%.
2. Hạ ngưỡng để gọi thành công.
3. Giữ hướng chatbot tự động.
4. Đổi hướng sang thư viện mẫu và gợi ý chỉnh sửa.
5. Dừng mọi nỗ lực.

Decision criteria:

• Ngưỡng đã khóa trước chưa.
• Chỉ số chính có phản ánh giá trị giả định không.
• Chỉ số bảo vệ có ổn không.
• Hành vi chỉnh sửa có tạo giá trị không.
• Kết quả có phù hợp giả thuyết đối nghịch không.
• Bằng chứng đủ cho cam kết nào, chưa đủ cho cam kết nào.

Decision: Pivot từ chatbot tự động sang thư viện trả lời có gợi ý và chỉnh sửa. Kết luận rằng bản nháp có thể chỉnh sửa tạo giá trị; chưa kết luận rằng thành viên chấp nhận câu trả lời tự động.

Authority: PM đưa khuyến nghị dựa trên Decision Record. Product leadership quyết định có cấp vốn cho nguyên mẫu tiếp theo. Safety hoặc Legal quyết định ranh giới nội dung và dữ liệu.

Artifact: Learning Card, Decision Record, bản cập nhật Assumptions Map, Pitch mới.

Consequence if wrong: Nếu coi 42% chỉnh sửa là bằng chứng cho tự động đăng, đội có thể tăng rủi ro sai nội dung và làm mất quyền kiểm soát của quản trị viên. Nếu chỉ nhìn 10% gửi nguyên văn, đội có thể bỏ qua giá trị của bản nháp.

Case 5: Quyết định đặt cược sáu tuần

Facts: Giá trị của bản nháp có thể chỉnh sửa đã có tín hiệu; luồng chính chưa hoàn thiện; quyền dữ liệu đã được xem xét cho nhóm nội dung rủi ro thấp; khả năng tích hợp chưa được thử đầy đủ; tự động đăng chưa được chứng minh.

Current behavior: Đội muốn đưa toàn bộ chatbot vào chu kỳ sáu tuần.

Underlying need: Tổ chức cần kiểm tra giá trị đã thấy mà không cam kết phạm vi vượt quá bằng chứng.

Options:

1. Đặt cược chatbot đầy đủ.
2. Đặt cược thư viện mẫu và gợi ý có chỉnh sửa.
3. Chạy thêm một thử nghiệm thủ công.
4. Dừng vì chưa chứng minh tự động hóa.

Decision criteria:

• Mức tin cậy cho luồng bản nháp.
• Rủi ro kỹ thuật và dữ liệu.
• Khả năng gọt phạm vi.
• Khả năng đo kết quả trong sáu tuần.
• Điều kiện dừng.
• Hệ quả nếu tự động hóa sai.

Decision: Đặt cược có giới hạn vào thư viện mẫu và gợi ý có chỉnh sửa. Không tự động đăng. Không sinh nội dung cho chủ đề nhạy cảm. Chạy Spike cho tích hợp và quyền truy cập. Ghi rõ phần không làm và điều kiện dừng.

Authority: Betting Table hoặc người có quyền đặt cược cấp Appetite. Engineering sở hữu thiết kế kỹ thuật trong ranh giới. Product sở hữu kết quả sản phẩm. Safety, Legal và Compliance có quyền phê duyệt hoặc chặn phạm vi thuộc họ.

Artifact: Pitch, Decision Record, kế hoạch đo lường, Experiment Guidelines, điều kiện Kill Switch.

Consequence if wrong: Nếu phạm vi không gọt được, chu kỳ sẽ quá tải, chất lượng giảm và rủi ro bị che giấu. Nếu luồng bản nháp không tạo giá trị trong bối cảnh rộng hơn, đội dừng hoặc định hình lại thay vì gia hạn mặc định.

Senior Lens

1. Quyền quyết định, trách nhiệm và escalation

Senior PM không chỉ hỏi “nên làm gì”. Senior PM phải làm rõ ai có quyền quyết định, ai chịu hậu quả, ai cung cấp chuyên môn và khi nào phải escalatе.

Quyết định	Người sở hữu	Người tham gia
Chẩn đoán và chính sách định hướng	Lãnh đạo sản phẩm cùng lãnh đạo kinh doanh	Product, Design, Engineering, Data
Chọn giả định và thiết kế thử nghiệm	Đội liên chức năng	Research, Legal, Safety, Finance khi cần
Định nghĩa chỉ số	Product và Data	Engineering, Finance
Phê duyệt rủi ro pháp lý, an toàn hoặc tuân thủ	Chuyên gia hoặc người được ủy quyền	Đội thử nghiệm
Tiếp tục trong ngân sách đã duyệt	Đội sản phẩm	Nhà tài trợ nhận thông tin
Tăng vốn, đổi chiến lược hoặc dừng	Người có quyền ngân sách hoặc Investment Committee	Đội trình bày khuyến nghị
Gia hạn ngoài Appetite	Người có quyền đặt cược	Đội cung cấp phần còn lại và chi phí

Tự chủ không có nghĩa thiếu trách nhiệm giải trình. Lãnh đạo đặt hướng, ràng buộc, quyền truy cập, ngân sách và cổng quyết định. Đội sở hữu cách học và cách thực thi trong ranh giới.

Nhận xét mơ hồ từ người có quyền lực thường bị hiểu thành lệnh. Lãnh đạo cần phân biệt rõ:

• Câu hỏi.
• Ý kiến.
• Khuyến nghị.
• Quyết định bắt buộc.

Escalate khi:

• Rủi ro vượt quyền hoặc ngân sách của đội.
• Có nguy cơ pháp lý, an toàn, quyền riêng tư hoặc dữ liệu.
• Phạm vi thay đổi chiến lược.
• Cần tăng vốn hoặc gia hạn ngoài Appetite.
• Các chỉ số mâu thuẫn và không có người sở hữu quyết định.
• Quyết định khó đảo ngược hoặc gây tác động rộng.

Escalation không phải chuyển trách nhiệm. PM phải đưa vấn đề, lựa chọn, tiêu chí, khuyến nghị, rủi ro và quyết định cần cấp trên đưa ra.

2. Quản trị danh mục theo mức bất định

Không cấp cùng mức vốn cho mọi giai đoạn:

• Bất định cao: đội nhỏ, vốn nhỏ, mục tiêu học.
• Bằng chứng tăng: tăng độ chân thực, người và vốn.
• Mô hình rõ: chuyển trọng tâm sang thực thi, độ tin cậy và hiệu quả.
• Bằng chứng yếu kéo dài: dừng hoặc tái định hình, không giữ dự án sống để bảo vệ hình ảnh.

Investment Committee (ủy ban đầu tư) cần:

• Quyền ngân sách thật.
• Nhịp rà soát rõ.
• Quy tắc quyết định trong cuộc họp.
• Bằng chứng thuận và nghịch.
• Khuyến nghị từ đội trước khi tranh luận.
• Hồ sơ quyết định.

Ủy ban không có quyền ngân sách chỉ là diễn đàn tư vấn.

Betting Table phù hợp chọn dự án cho chu kỳ. Investment Committee phù hợp cấp vốn tăng dần cho danh mục đổi mới. Tổ chức có thể dùng cả hai: ủy ban quyết định vốn và giai đoạn; bàn cược chọn công việc cụ thể.

3. Nhịp vận hành tối thiểu

Đội có thể dùng:

• Rà soát học hỏi hằng tuần.
• Lập thử nghiệm sau phiên học hỏi.
• Rà soát bên liên quan hằng tháng.
• Quyết định vốn theo quý hoặc theo cổng bằng chứng.

Experiment Board (bảng luồng thử nghiệm) gồm:

• Tồn đọng.
• Chuẩn bị.
• Đang chạy.
• Học hỏi.

Giới hạn việc đang làm giúp giảm nhiều thử nghiệm nửa hoàn thành. Giới hạn cần điều chỉnh theo điểm nghẽn thực tế, không phải luật bất biến.

Sau mỗi vòng, đội phải cập nhật ít nhất một trong các artifact:

• Bản đồ giả định.
• Ngưỡng.
• Mức tin cậy.
• Mô hình kinh doanh.
• Chiến lược.
• Hồ sơ quyết định.
• Điều kiện xem xét lại.

Tổng hợp bài học mà không cập nhật quyết định là hoạt động báo cáo, không phải học hỏi.

4. Đạo đức, pháp lý và an toàn là ràng buộc thiết kế

Phân biệt thử nghiệm cùng khách hàng và thử nghiệm lên khách hàng. Tốc độ không cho phép lừa dối, lấy tiền khi chưa thể cung cấp hoặc gây rủi ro không được đồng ý.

Experiment Guidelines cần ghi:

• Phân khúc.
• Số người tối đa.
• Thời lượng.
• Dữ liệu hoặc cam kết thu thập.
• Cách dùng thương hiệu.
• Mức phơi nhiễm tài chính.
• Điều kiện pháp lý và an toàn.
• Kill Switch.
• Người có quyền dừng.

Không dùng nút giả cho chức năng tối quan trọng. Không chạy bán trước nếu chưa có khả năng cung cấp và điều khoản rõ. Không đưa mã Spike vào sản xuất. Quyết định có hệ quả pháp lý, tài chính, an toàn hoặc quyền riêng tư cần chuyên gia phù hợp.

5. Quy tắc theo tính đảo ngược và chi phí sai

Quyết định rẻ, dễ đảo ngược và ít rủi ro cần ít nghi thức hơn. Đội có thể hành động nhanh trong quyền được giao.

Quyết định khó đảo ngược, chi phí lớn, ảnh hưởng rộng hoặc có rủi ro an toàn cần:

• Bằng chứng mạnh hơn.
• Rà soát độc lập.
• Chỉ số bảo vệ.
• Điều kiện dừng.
• Người có quyền rõ.
• Artifact có thể truy vết.

Không dùng “cần thêm dữ liệu” để trì hoãn mọi quyết định đảo ngược được. Không dùng “học nhanh” để bỏ qua kiểm soát bắt buộc.

6. Data-driven và data-informed

Data-Driven (để dữ liệu điều khiển) phù hợp với tối ưu lặp lại trong ranh giới rõ. Data-Informed (dùng dữ liệu hỗ trợ phán đoán) cần thiết khi quyết định liên quan:

• Thương hiệu.
• Đạo đức.
• Tác động dài hạn.
• Định khung lại thị trường.
• Mẫu dữ liệu yếu.
• Cực đại cục bộ.

Con người đặt mục tiêu và ràng buộc. Máy tối ưu trong không gian được phép. Dữ liệu không tự quyết định điều đáng làm.

7. Tầm nhìn, thử nghiệm và Shape Up

Tầm nhìn chọn hướng và mức tham vọng. Thử nghiệm kiểm tra cơ chế, trình tự và giả định. Bước nhảy chiến lược vẫn cần mục tiêu cận kề, tín hiệu cảnh báo và giới hạn thua lỗ.

Shape Up tối ưu rủi ro giao hàng và quyền tự chủ trong chu kỳ. Testing Business Ideas tối ưu rủi ro thị trường và mô hình kinh doanh. Khi bất định vấn đề cao, thử nghiệm trước đặt cược xây dựng. Khi vấn đề rõ nhưng giao hàng rủi ro, định hình công việc và đặt Appetite.

Không ép mọi hoạt động khám phá vào chu kỳ xây sáu tuần.

8. Anti-pattern và cách sửa

Anti-pattern	Tín hiệu	Cách sửa
Nhầm mục tiêu với chiến lược	“Tăng trưởng 20%” không có trở ngại và cách vượt	Viết chẩn đoán, chính sách và hành động
Ngôn ngữ sáo rỗng	“Lấy khách hàng làm trung tâm” không giới hạn lựa chọn	Nêu vấn đề, đánh đổi và phần không làm
Bám giải pháp đầu tiên	Mọi thử nghiệm nhằm chứng minh ý tưởng lãnh đạo	Viết giả thuyết đối nghịch
Thử điều dễ	Danh sách thử nghiệm dài nhưng rủi ro lớn chưa chạm	Ưu tiên giả định có thể giết ý tưởng
Một thử nghiệm rồi quyết định lớn	Phỏng vấn tốt dẫn thẳng tới xây đầy đủ	Xâu chuỗi bằng chứng tăng dần
Dùng lời nói như hành vi	“Khách nói sẽ mua”	Yêu cầu hành động, thời gian, tiền hoặc uy tín
Chỉ số phù phiếm	Lượt xem, tải, đăng ký không nối giá trị	Đo hành vi cốt lõi, giữ chân hoặc doanh thu
Hạ ngưỡng	Thấy kết quả thấp rồi đổi định nghĩa thành công	Khóa ngưỡng trước
Chỉ số chính phá hệ thống	Chuyển đổi tăng nhưng khiếu nại tăng	Thêm chỉ số bảo vệ
Gọi tương quan là nhân quả	Nhóm dùng tính năng có giữ chân cao hơn	Chạy thử nghiệm hoặc kiểm soát khác biệt
Xây trong vùng không có khách	Prototype hoàn thiện nhưng chưa tiếp xúc người dùng	Thử trong bối cảnh thật với chi phí thấp
Tự động hóa sớm	Xây hệ thống trước khi rõ nhu cầu và chi phí	Dùng dịch vụ thủ công
Gia hạn mặc định	“Thêm một tuần” lặp lại	Gọt phạm vi hoặc ngắt mạch
Tự chủ giả	Đội thiếu khách hàng, ngân sách hoặc quyền	Cấp quyền truy cập và ranh giới
Thưởng sản lượng tính năng	Đội né thử nghiệm có thể bác bỏ ý tưởng	Thưởng chất lượng học và giảm rủi ro
Yêu cầu bằng chứng hoàn hảo	Quyết định nhỏ vẫn chờ vô hạn	Đặt mức bằng chứng theo chi phí sai
Bỏ qua đạo đức	Nút giả, bán trước hoặc tự động hóa gây hiểu lầm	Minh bạch, đồng ý, giới hạn và cơ chế dừng

Quick reference

Decision rule

1. Xác định thách thức, không chấp nhận yêu cầu giải pháp.
2. Viết Kernel.
3. Đặt Proximate Objective.
4. Đặt Appetite.
5. Liệt kê Desirability, Feasibility và Viability Risk.
6. Kiểm tra rủi ro pháp lý, an toàn hoặc quyền dữ liệu có thể giết ý tưởng.
7. Chọn giả định quan trọng nhất đang thiếu bằng chứng.
8. Viết giả thuyết thuận và đối nghịch.
9. Chọn One Metric That Matters.
10. Đặt Line in the Sand, mẫu, thời gian và dữ liệu hợp lệ.
11. Chọn Guardrail Metrics.
12. Chọn thử nghiệm rẻ nhất tạo bằng chứng đủ mạnh.
13. Tách dữ liệu, bằng chứng, nhận định và hành động.
14. Quyết định Persevere, Pivot, Kill hoặc tiếp tục kiểm tra.
15. Ghi quyền quyết định, artifact và hậu quả.
16. Chỉ tăng vốn khi mức tin cậy tăng.

Bộ artifact tối thiểu

Artifact	Mục đích
Kernel	Nối thách thức, chính sách và hành động
Pitch	Giới hạn giải pháp, thời gian, hố thỏ và phần không làm
Assumptions Map	Ưu tiên giả định quan trọng, thiếu bằng chứng
Test Card	Khóa giả thuyết, thử nghiệm, chỉ số và ngưỡng
Learning Card	Chuyển quan sát thành nhận định
Decision Record	Ghi quyền, căn cứ, hành động và điều kiện xem xét lại
Experiment Board	Trực quan hóa luồng thử nghiệm
Innovation Portfolio	Nối giai đoạn, vốn, đội, bằng chứng và quyết định kế tiếp
Experiment Guidelines	Kiểm soát đạo đức, pháp lý, tài chính và dừng nhanh

Mẫu hồ sơ quyết định

Trường	Nội dung cần ghi
Facts	Dữ kiện có nguồn và thời điểm
Current behavior	Hành vi đang xảy ra
Underlying need	Nhu cầu hoặc cơ chế nền
Options	Các lựa chọn thực tế
Decision criteria	Tiêu chí và đánh đổi
Decision	Hành động được chọn
Authority	Người có quyền quyết định
Artifact	Nơi lưu căn cứ
Consequence if wrong	Hậu quả và tín hiệu cảnh báo
Review condition	Điều kiện xem xét lại
Owner	Người sở hữu hành động tiếp theo

Câu hỏi rà soát

• Thách thức thật là gì?
• Điều gì phải đúng để ý tưởng hoạt động?
• Giả định nào sai sẽ giết ý tưởng?
• Bằng chứng là lời nói hay hành vi?
• Bối cảnh thử có gần thực tế không?
• Khách đã cam kết thời gian, tiền hoặc uy tín chưa?
• Chỉ số nào đổi quyết định?
• Ngưỡng đã đặt trước chưa?
• Chỉ số bảo vệ nào có thể bị phá?
• Dữ liệu có vấn đề về mẫu, mùa vụ, phân khúc hoặc đo lường không?
• Bằng chứng nào chống lại khuyến nghị?
• Quyết định có đảo ngược được không?
• Ai có quyền tiếp tục, tăng vốn, đổi hướng hoặc dừng?
• Sau đổi hướng, bằng chứng nào mất hiệu lực?
• Điều kiện dừng nhanh là gì?

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

Thuật ngữ	Giải nghĩa
Kernel	Hạt nhân chiến lược gồm chẩn đoán, chính sách định hướng và chuỗi hành động
Diagnosis	Chẩn đoán bản chất thách thức và cơ chế gây ra kết quả
Guiding Policy	Chính sách định hướng và giới hạn hành động
Coherent Actions	Chuỗi hành động phối hợp để thực hiện chính sách
Leverage	Đòn bẩy tạo tác động lớn từ nguồn lực tập trung
Proximate Objective	Mục tiêu cận kề, khả thi với năng lực hiện tại
Appetite	Ngân sách thời gian tối đa cho một ý tưởng
Pitch	Bản đề xuất đã định hình để xin đặt cược
Assumptions Map	Bản đồ giả định theo tầm quan trọng và mức bằng chứng
Desirability Risk	Rủi ro khách không muốn, không tiếp cận hoặc không đổi hành vi
Feasibility Risk	Rủi ro tổ chức không thể xây hoặc vận hành
Viability Risk	Rủi ro doanh thu không vượt chi phí hoặc mô hình không bền
Test Card	Thẻ ghi giả thuyết, thử nghiệm, chỉ số và tiêu chí
Decision Contract	Cam kết trước về cách thử và cách hành động
Discovery	Hoạt động khám phá vấn đề, động cơ, phân khúc và hướng giải pháp
Validation	Hoạt động xác thực hành vi, thanh toán, cung cấp và kinh tế
One Metric That Matters	Chỉ số quan trọng nhất với nút thắt hiện tại
Line in the Sand	Ngưỡng quyết định đặt trước khi xem kết quả
Guardrail Metric	Chỉ số bảo vệ phát hiện tác hại ngoài chỉ số chính
Evidence Strength	Độ mạnh bằng chứng theo hành vi, bối cảnh và cam kết
Confidence Level	Mức tin cậy của một giả thuyết
Learning Card	Thẻ nối điều tin, quan sát, học được và hành động
Decision Record	Hồ sơ nối giả thuyết, bằng chứng, quyền và hành động
Pivot	Đổi hướng lớn về khách hàng, vấn đề, giải pháp, giá trị hoặc mô hình
Persevere	Tiếp tục kiểm tra hoặc tăng đầu tư theo bằng chứng
Kill	Dừng ý tưởng và tái phân bổ nguồn lực
Circuit Breaker	Cơ chế ngắt mạch ngăn gia hạn mặc định
Betting Table	Bàn cược chọn dự án cho chu kỳ
Investment Committee	Ủy ban có quyền cấp vốn hoặc dừng đầu tư
Vanity Metric	Chỉ số đẹp nhưng không đổi quyết định hoặc phản ánh giá trị
Outside View	Cái nhìn từ trường hợp tương tự bên ngoài đội
Create-Destroy	Tạo phương án rồi chủ động tìm cách bác bỏ
Feature Stub	Thành phần giao diện đo nhu cầu trước khi xây đầy đủ
Concierge	Dịch vụ thủ công mà khách biết có người thực hiện
Wizard of Oz	Trải nghiệm có vẻ tự động nhưng được xử lý thủ công phía sau
Extreme Programming Spike	Thử nghiệm kỹ thuật có giới hạn thời gian
Kill Switch	Cơ chế dừng thử nghiệm nhanh khi xuất hiện rủi ro
Data-Driven	Để dữ liệu điều khiển tối ưu trong ranh giới rõ
Data-Informed	Dùng dữ liệu hỗ trợ phán đoán và quyết định
Appetite	Ngân sách thời gian với phạm vi linh hoạt
Artifact	Tài liệu hoặc sản phẩm trung gian ghi lại suy luận, hành động và quyền

Nguồn và giới hạn

Đóng góp của nguồn

• Good Strategy Bad Strategy cung cấp Kernel, chẩn đoán, chính sách định hướng, mục tiêu cận kề, đòn bẩy và kỹ thuật chống thiên kiến.
• Testing Business Ideas cung cấp bản đồ giả định, thẻ thử nghiệm, thẻ học hỏi, thang bằng chứng, mức tin cậy, thư viện thử nghiệm, đạo đức và quản trị danh mục.
• Lean Analytics cung cấp logic mô hình kinh doanh, giai đoạn, One Metric That Matters, ngưỡng quyết định, chỉ số bảo vệ và văn hóa dùng dữ liệu hỗ trợ phán đoán.
• Shape Up cung cấp Appetite, định hình công việc, Pitch, Betting Table, phạm vi linh hoạt và cơ chế ngắt mạch.

Chương tổng hợp các khung trên cho thực hành Product Management. Các định nghĩa trong chương không phải trích dẫn nguyên văn từ nguồn. Người đọc cần kiểm tra ấn bản gốc khi cần hiểu lập luận và ngữ cảnh đầy đủ.

Giới hạn áp dụng

• Benchmark trong Lean Analytics và Testing Business Ideas phần lớn phản ánh dữ liệu giai đoạn 2012–2013 hoặc kinh nghiệm tác giả. Dùng làm mốc tham khảo, không dùng như chuẩn phổ quát.
• Một số công thức chỉ số trong Testing Business Ideas có thể mô tả tử số và mẫu số khác nhau. Tổ chức phải duy trì từ điển chỉ số riêng, ghi rõ định nghĩa.
• Shape Up hình thành trong môi trường đội nhỏ, giàu kinh nghiệm, ít phụ thuộc và tự chủ cao. Tổ chức lớn cần thêm quản trị phụ thuộc, an toàn, pháp lý, dữ liệu và vận hành.
• Chuỗi khám phá rồi xác thực không luôn tuyến tính. Bằng chứng mới có thể buộc đội quay lại thiết kế kinh doanh hoặc chiến lược.
• Bằng chứng mạnh về Desirability không chứng minh Feasibility hoặc Viability.
• A/B test ngắn hạn không tự quyết định thương hiệu, công bằng, đạo đức hoặc chiến lược dài hạn.
• Quy trình đầy đủ không cần cho mọi quyết định. Việc rẻ, đảo ngược được và ít rủi ro nên xử lý nhanh. Việc khó đảo ngược, có tác động pháp lý, tài chính, an toàn hoặc dữ liệu cần kiểm soát mạnh hơn.
• Bằng chứng không tự có giá trị nếu dữ liệu sai, mẫu không phù hợp, quyền sử dụng không rõ hoặc bối cảnh thử khác xa bối cảnh quyết định.
• Mức tin cậy không phải xác suất sản phẩm chắc chắn thành công. Nó là đánh giá chất lượng tập bằng chứng đối với một giả thuyết cụ thể.
• Mục tiêu không phải loại bỏ bất định. Mục tiêu là giảm bất định đủ để quyết định kế tiếp có tỷ lệ lợi ích–rủi ro chấp nhận được.
• Đọc chương không tạo năng lực phán đoán hoàn chỉnh. Năng lực senior cần trải nghiệm chịu trách nhiệm với quyết định, quan sát hậu quả, nhận phản biện và sửa khung khi thực tế không khớp.