P0.4 — Product lifecycle và ra quyết định trong bất định

Module: P0 - Nền tảng nghề Product Mục tiêu đọc: Sau chương này, bạn có thể dẫn dắt sản phẩm qua toàn bộ vòng đời; xác định giả định rủi ro; thiết kế phép thử; đo tiến bộ; quyết định tiếp tục, xoay trục hoặc khai tử; thiết lập quyền quyết định và cơ chế quản trị phù hợp từng giai đoạn. Nguồn tổng hợp: The Lean Startup, Product Leadership, The Product Book

Mental model — vòng đời là hệ thống học, không phải dây chuyền giao tính năng

Product Development Life Cycle (vòng đời phát triển sản phẩm) có năm giai đoạn:

Tìm cơ hội và lập kế hoạch.
Thiết kế giải pháp.
Xây dựng.
Ra mắt.
Đánh giá và lặp lại.

Đây là bản đồ công việc, không phải đường thẳng. Giai đoạn chồng lấp, lặp lại. Shipping (phát hành) mở vòng học mới, không kết thúc sản phẩm.

Trong extreme uncertainty (bất định cực đoan), đội chưa biết:

Ai có vấn đề đủ lớn.
Giải pháp nào tạo giá trị.
Hành vi nào chứng minh giá trị.
Kênh nào tạo tăng trưởng.
Mô hình kinh doanh nào bền vững.
Công nghệ, vận hành, pháp lý có khả thi không.

Câu hỏi đầu tiên: "Có nên xây không?". Không phải "Có xây được không?". Làm nhanh kế hoạch sai vẫn là thất bại.

Ba tầng ổn định khác nhau

Tầng	Vai trò	Nhịp thay đổi
`Vision (tầm nhìn)`	Trạng thái tương lai hoặc mục đích lâu dài	Hiếm khi đổi
`Strategy (chiến lược)`	Mô hình kinh doanh, phân khúc, kênh, cách đạt tầm nhìn	Đổi qua `Pivot`
`Product (sản phẩm)`	Biểu hiện hiện tại của chiến lược	Đổi thường xuyên qua tối ưu hóa

Quy tắc quyết định:

Một thử nghiệm thất bại không đổi Vision.
Bằng chứng khách hàng đổi, Roadmap đổi.
Giả định nền tảng sai, đổi Strategy.
Product đổi liên tục để tối ưu Strategy đã chọn.

Động cơ điều hướng bất định

Build-Measure-Learn (Xây dựng-Đo lường-Học hỏi) là vòng phản hồi cốt lõi.

Build (Xây dựng): tạo phép thử hoặc sản phẩm.
Measure (Đo lường): quan sát hành vi thật.
Learn (Học hỏi): xác nhận hoặc bác bỏ giả thuyết, quyết định bước tiếp.

Thực thi đi theo thứ tự: Xây dựng → Đo lường → Học hỏi. Lập kế hoạch phải đi ngược:

Học: Cần học điều gì?
Đo: Bằng chứng nào đủ để học?
Xây: Cần xây thứ nhỏ nhất nào để tạo bằng chứng đó?

P0.4 - Product lifecycle và ra quyết định trong bất định — diagram 1

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

flowchart TB
    subgraph "Lập kế hoạch ngược"
        direction TB
        L["1. Learn: cần học gì?"]
        M["2. Measure: bằng chứng nào đủ?"]
        B["3. Build: phép thử nhỏ nhất?"]
        L --> M --> B
    end

    subgraph "Thực thi"
        direction TB
        B_Run["Build"]
        O["Quan sát hành vi thật"]
        M_Run["Measure"]
        L_Run["Learn"]
        D{"Quyết định"}
        C["Tiếp tục hoặc xoay trục"]
        S["Dừng"]
        B_Run --> O --> M_Run --> L_Run --> D
        D --> C
        D --> S
    end

    B --> B_Run
    C --> L

Sơ đồ 1: Lập kế hoạch ngược để rút ngắn toàn bộ vòng học.

Validated Learning (học hỏi đã được xác thực) là bằng chứng thực nghiệm đội đã khám phá ra điều có giá trị. Đây là thước đo tiến bộ trong bất định. Code đã viết, tính năng đã giao là Output (đầu ra). Vấn đề khách hàng được giải, hành vi thay đổi là Outcome (kết quả).

Core — vận hành năm giai đoạn bằng bằng chứng

Giai đoạn 1: Tìm cơ hội và lập kế hoạch

1. Bắt đầu từ tầm nhìn, không từ danh sách tính năng

Mọi thứ phải truy nguyên được: Vision → Mục tiêu kinh doanh → Product Goal → Roadmap Theme → Giả thuyết → Công việc.

Quy tắc quyết định: - Tính năng không nối với Product Goal: không ưu tiên. - Product Goal không nối với Vision: xem lại mục tiêu. - Chân trời càng xa: chi tiết càng ít, linh hoạt càng nhiều. - Roadmap (lộ trình sản phẩm) là lời hứa giải quyết vấn đề, không phải Release Plan (kế hoạch phát hành) có ngày cố định.

Dùng Theme-based Roadmap (lộ trình theo chủ đề) với ba chân trời:

Chân trời	Mức chắc chắn	Nội dung phù hợp
Hiện tại	Cao	Vấn đề đang giải, chỉ số, phép thử đang chạy
Tiếp theo	Trung bình	Chủ đề đã xếp hàng, chi tiết còn đổi
Tương lai	Thấp	Cơ hội lớn, chưa có chi tiết

2. Xác định giả định mang tính bước ngoặt

Chiến lược mới dựa trên Leap-of-Faith Assumptions (các giả định mang tính bước ngoặt). Hai giả thuyết nền tảng: - Value Hypothesis (giả thuyết giá trị): khách hàng có nhận giá trị không? - Growth Hypothesis (giả thuyết tăng trưởng): khách hàng mới tìm thấy sản phẩm bằng cách nào?

Ngoài ra, phải kiểm tra bốn rủi ro lớn của Marty Cagan: - Valuable (có giá trị): khách hàng có cần, doanh nghiệp có lợi không? - Usable (dễ sử dụng): khách hàng có hiểu và dùng được không? - Feasible (khả thi): đội có thể xây, vận hành, hỗ trợ không? - Viable (bền vững): mô hình kinh doanh có phù hợp chiến lược, chi phí không?

Bet Statement (tuyên bố cược thử nghiệm) có cấu trúc:

Nếu thực hiện X cho nhóm Y, chúng ta kỳ vọng hành vi Z thay đổi từ A lên B trong thời gian T, vì giả định C.

Thử nghiệm không thể thất bại không phải thử nghiệm. Phải ghi trước tín hiệu bác bỏ. Không ghi, đội dễ diễn giải mọi kết quả thành thành công.

3. Theo vấn đề lớn nhất, không theo vấn đề dễ xây nhất

Case GearCommons: người dùng thiếu thời gian nghiêm trọng hơn thiếu thiết bị. Đội vẫn xây chợ cho thuê vì dễ làm. Thuê đồ tốn thêm thời gian, làm vấn đề chính nặng hơn. Sản phẩm chết.

Quy tắc: ưu tiên Problem #1. Không chọn Problem #2 vì giải pháp quen thuộc.

4. Đi tới hiện trường

Genchi Gembutsu (đến tận nơi thấy sự thật). Quan sát bối cảnh, vật thể, hành vi thật. Báo cáo, khảo sát không thay được quan sát trực tiếp.

Persona là giả thuyết. Trong B2B, tách rõ: - Người mua (Buyer). - Người trả tiền (Payer). - Người dùng (User). - Người ảnh hưởng (Influencer). - Người ủng hộ (Champion).

Khi phỏng vấn, hỏi về hành vi quá khứ, không hỏi ý định tương lai: - "Lần gần nhất vấn đề xảy ra là khi nào?" - "Bạn đã xử lý thế nào?" - "Bạn mất bao nhiêu thời gian hoặc tiền?" - "Bạn đang dùng cách thay thế nào?"

Hành vi thật, cam kết thời gian, tiền đặt cọc mạnh hơn câu trả lời "Tôi sẽ mua".

5. Chọn phép thử theo quy mô bất định

Tình huống	Cách kiểm chứng
Tối ưu nhỏ trên sản phẩm trưởng thành	`A/B Test`
Giả định nền tảng chưa rõ	`Riskiest Assumption Test — RAT`
Cần học quy trình dịch vụ trọn vẹn	`Concierge MVP` (vận hành thủ công)
Cần kiểm tra trải nghiệm tự động	`Wizard of Oz MVP` (giao diện tự động, ruột thủ công)
Cần kiểm tra mức quan tâm	`Fake Door MVP` (nút bấm giả)
Cần kiểm tra ý định mua	`Preorder MVP` (nhận đặt trước)
Giá trị khó mô tả bằng giao diện	`Video MVP`

Small Bet (cược nhỏ) tối ưu cục bộ. Dễ kẹt ở Local Maximum (cực đại cục bộ). Riskiest Assumption Test (thử giả định rủi ro nhất) dùng khi đổi lớn hoặc chưa biết vấn đề/phân khúc/mô hình có đúng không.

6. Dùng tài liệu để căn chỉnh, không để đóng băng giải pháp

Product Requirements Document (PRD) là tài liệu sống. Nội dung tối thiểu: - Vấn đề, bối cảnh, liên kết chiến lược. - Khách hàng mục tiêu, giả thuyết. - Kịch bản người dùng, phạm vi (làm và không làm). - Chỉ số thành công, rủi ro, vấn đề mở. - Quyền quyết định, kế hoạch kiểm chứng, kế hoạch phát hành.

Experiment Brief (bản mô tả thử nghiệm) phải ghi: - Giả thuyết: Điều cần xác nhận/bác bỏ. - Đối tượng: Phân khúc khách hàng. - Phép thử: Thứ nhỏ nhất cần tạo. - Bằng chứng: Số liệu và quan sát. - Ngưỡng: Điều kiện tiếp tục/xoay trục/dừng. - Chủ quyết định: Ai chịu trách nhiệm cuối. - Ràng buộc: Pháp lý, thương hiệu, bảo mật, vận hành.

Giai đoạn 2: Thiết kế giải pháp để học

MVP không đồng nghĩa sản phẩm sơ sài

Minimum Viable Product (MVP) là phiên bản cho phép học một vòng nhanh nhất.

Phân biệt hai loại: 1. MVP để học: Có thể là phép thử, không phải sản phẩm chạy thật. Ví dụ: landing page. 2. MVP để phát hành: Phải đủ Viable (khả dụng) trong phạm vi hẹp.

Viable không cho phép bỏ: - Bảo mật, quyền riêng tư. - Toàn vẹn dữ liệu. - Tuân thủ pháp lý. - Khả năng tiếp cận (Accessibility). - Trải nghiệm cốt lõi.

Chất lượng phụ thuộc mục tiêu học. Giao diện thô chấp nhận được trong thử nghiệm kín. Mất dữ liệu khách hàng thì không.

Các mẫu MVP và giới hạn

Concierge MVP: Học sâu, mẫu nhỏ. Khó chứng minh khả năng mở rộng.
Wizard of Oz MVP: Kiểm tra luồng tốt. Phải quản lý rủi ro minh bạch dữ liệu.
Fake Door MVP: Đo quan tâm. Không chứng minh ý định trả tiền.
Video MVP: Đo sức hút thông điệp. Không chứng minh khả năng sử dụng.
Preorder MVP: Tín hiệu mạnh hơn lượt nhấp. Cần điều khoản hoàn tiền rõ.

Case Zappos: phép thử xác nhận hành vi mua giày online. Nó chưa xác nhận kinh tế kho vận ở quy mô lớn.

Thiết kế tập trung để giảm rủi ro

Design Sprint phù hợp vấn đề quan trọng, bất định cao, cần căn chỉnh nhanh. Luồng: Thấu hiểu → Định nghĩa → Phác thảo → Quyết định → Nguyên mẫu → Kiểm thử.

Không dùng Sprint để thay nghiên cứu liên tục. Collaboration (cộng tác) không phải Consensus (đồng thuận tuyệt đối). Cần một người có quyền quyết định cuối cùng khi bằng chứng chưa đủ.

Giai đoạn 3: Xây dựng theo lô nhỏ

Small Batches (lô nhỏ) giúp phát hiện lỗi sớm, giảm công làm lại, đưa bằng chứng về nhanh. Đơn vị đúng là một lát cắt dọc có thể kiểm thử hoặc phát hành, không phải chia nhỏ vé công việc.

Pull System (hệ thống kéo) chỉ bắt đầu việc khi có tín hiệu cần kiểm chứng. Ngược với Push System (hệ thống đẩy) tạo tính năng theo dự báo.

Cảnh báo Large-Batch Death Spiral (vòng xoáy tử thần của lô lớn): Phát hành lớn bị trễ → Gộp thêm việc → Phạm vi và phụ thuộc tăng → Chu kỳ dài hơn → Bằng chứng về muộn hơn → Mất khả năng phát hành an toàn.

Quan hệ với kỹ thuật

Product Manager sở hữu vấn đề và tại sao. Kỹ sư sở hữu cách làm.

Khi ước lượng cao: 1. Hỏi phần phức tạp nằm đâu. 2. Tách ràng buộc bắt buộc khỏi giả định. 3. Giảm phạm vi hoặc đổi phép thử. 4. Ghi đánh đổi (thời gian, chất lượng, chi phí, rủi ro). 5. Để kỹ thuật quyết định giải pháp kỹ thuật.

Không hỏi "Không thể làm đơn giản hơn sao?". Câu đó phủ nhận độ phức tạp chưa được hiểu.

Nợ kỹ thuật và nợ sản phẩm

Technical Debt (nợ kỹ thuật) là chi phí tương lai do quyết định kỹ thuật hiện tại. Product Debt (nợ sản phẩm) là các luồng cũ, cam kết cũ làm giảm tốc độ thay đổi.

Lối tắt có chủ đích là hợp lý. Cần ghi lại: - Lợi ích học hỏi. - Phạm vi ảnh hưởng. - Người sở hữu, ngày rà soát. - Tín hiệu phải trả nợ.

Kỹ thuật có quyền kéo Andon Cord (dây dừng hệ thống) khi có rủi ro chất lượng hoặc bảo mật. Tốc độ học không biện minh cho việc xây trên nền lỗi.

Hoàn thành nghĩa là đã kiểm chứng

Kanban for Validated Learning có thể có các cột: Giả thuyết → Đang xây → Đã xây → Đang kiểm chứng → Đã học. Công việc chỉ hoàn thành khi đội biết tác động và quyết định bước tiếp theo. Done là đã học, không phải đã giao.

Giai đoạn 4: Ra mắt để tạo bằng chứng

Go-to-Market (GTM) là kế hoạch ra mắt. Gồm: phân khúc, thông điệp, giá, kênh, chỉ số, quy trình phản ứng sự cố. Thông điệp nói khách hàng được gì, không liệt kê tính năng.

Checklist trước phát hành: - Có theo dõi sự kiện đã kiểm tra. - Có đường cơ sở. - Có khả năng quay lui (rollback) hoặc giới hạn phạm vi. - Có kênh phản hồi định tính. - Có người trực giám sát, có điều kiện dừng. - Có kế hoạch xử lý dữ liệu và hỗ trợ khách hàng.

Anti-pattern "ra mắt hoàn hảo": trì hoãn để đợi sản phẩm và truyền thông hoàn chỉnh, trong khi chưa có bằng chứng nhu cầu. Sửa bằng cách phát hành giới hạn (canary release, beta) cho Early Adopters trong phạm vi an toàn.

Giai đoạn 5: Đo lường, học và quyết định

Kế toán đổi mới

Innovation Accounting (kế toán đổi mới) đo tiến bộ trong bất định. Ba cột mốc: 1. Thiết lập đường cơ sở: Dùng MVP lấy số liệu thực tế đầu tiên. 2. Tinh chỉnh động cơ: Thay đổi sản phẩm/tiếp thị, kiểm tra chỉ số có cải thiện không. 3. Xoay trục hoặc kiên trì: Quyết định chiến lược tiếp theo dựa trên xu hướng bằng chứng.

Một thay đổi không làm chỉ số mục tiêu tốt hơn không phải tiến bộ.

Chỉ số phải dùng được, hiểu được, kiểm tra được

Vanity Metrics (chỉ số phù phiếm) (tổng người dùng, tổng lượt tải) không chỉ ra nguyên nhân.

Actionable Metrics (chỉ số có thể hành động) cần ba thuộc tính (AAA): - Actionable: Nối thay đổi với kết quả. - Accessible: Đội tự đọc và hiểu được. - Auditable: Truy về dữ liệu gốc và kiểm tra được.

Cohort Analysis (phân tích nhóm) so sánh hành vi giữa các nhóm theo thời gian. Mỗi nhóm mới là một phép thử độc lập, tốt hơn số tổng tích lũy.

Bộ chỉ số tốt phải ghép cặp: chỉ số hành động và chỉ số bảo vệ (ví dụ: tăng doanh thu nhưng không làm giảm tỷ lệ giữ chân).

Chọn động cơ tăng trưởng

Xác định một Engine of Growth (động cơ tăng trưởng) chính để tập trung.

Động cơ	Cơ chế	Chỉ số lõi	Điều kiện tăng trưởng
`Sticky`	Giữ chân khách hàng	`Churn Rate` (tỷ lệ rời bỏ)	Thu hút > Rời bỏ
`Viral`	Người dùng kéo người dùng mới	`Viral Coefficient` (hệ số lan truyền)	Hệ số > 1 (để tăng trưởng)
`Paid`	Lợi nhuận tài trợ quảng cáo	`LTV > CPA`	Giá trị vòng đời > Chi phí thu hút

Tối ưu mọi động cơ cùng lúc làm mất trọng tâm. Product/Market Fit thể hiện qua cải thiện bền vững của một động cơ, không chỉ qua phản hồi tích cực.

Quy tắc tiếp tục, xoay trục hoặc dừng

P0.4 - Product lifecycle và ra quyết định trong bất định — diagram 2

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

flowchart TB
    A["Ghi trước giả thuyết và ngưỡng"] --> B["Chạy phép thử an toàn"]
    B --> C{"Dữ liệu đạt ngưỡng tin cậy đã ghi trước?"}
    C -- "Có" --> D{"Chỉ số lõi cải thiện bền vững?"}
    D -- "Có" --> E["Persevere: Tăng quy mô có kiểm soát"]
    D -- "Không" --> F{"Giả định nền tảng còn đúng?"}
    F -- "Có" --> G["Cải thiện thực thi / Sửa phép thử"] --> B
    F -- "Không" --> H["Pivot: Kiểm thử giả thuyết mới"] --> A
    F -- "Không rõ; sắp hết runway" --> I{"Giá trị kỳ vọng > chi phí + rủi ro?"}
    C -- "Không" --> J["Thu thêm dữ liệu / Sửa phép đo"]
    J --> K{"Còn runway để đo lại?"}
    K -- "Có" --> B
    K -- "Không" --> I
    I -- "Có" --> H
    I -- "Không" --> L["Lập kế hoạch khai tử: lý do, thời hạn, xuất dữ liệu, phương án thay thế, hỗ trợ, pháp lý"] --> M["Sunset/Stop: Khai tử hoặc dừng"]

Sơ đồ 2: Luồng quyết định dựa trên bằng chứng, xu hướng và nguồn lực.

Pivot (xoay trục) là thay đổi chiến lược có cấu trúc để kiểm tra giả thuyết nền tảng mới. Nó giữ lại phần đã học, không phải phản ứng tùy hứng. Mười dạng xoay trục của Eric Ries bao gồm: Zoom-in, Zoom-out, Customer Segment, Customer Need, Platform, Business Architecture, Value Capture, Engine of Growth, Channel, Technology.

Runway (đường băng) là số lần xoay trục còn lại, không chỉ là số tháng tiền mặt. Vòng học chậm làm đường băng ngắn đi.

Sunset (khai tử) khi giá trị kỳ vọng không còn vượt chi phí và rủi ro. Kế hoạch khai tử phải có: lý do, thời hạn, cách xuất dữ liệu, phương án thay thế, hỗ trợ, nghĩa vụ pháp lý.

Applied — Fridge-to-Table (Case giả lập)

Một đội muốn giảm lãng phí thực phẩm bằng dịch vụ gợi ý món ăn.

Vòng 1: Kiểm tra cơ chế nhập liệu

Sự thật: Đội muốn giảm lãng phí thực phẩm. Người dùng có nguyên liệu thừa.
Hành vi giả định: Người dùng sẽ nhập nguyên liệu trong tủ lạnh để nhận công thức.
Nhu cầu giả định: Cần gợi ý món ăn từ đồ có sẵn.
Lựa chọn: Xây app AI nhận diện ảnh / Vận hành thủ công qua Zalo.
Tiêu chí quyết định: Học nhanh nhất, rẻ nhất.
Quyết định: Dùng Concierge MVP (thủ công qua Zalo) với 12 người lạ.
Thẩm quyền: Đội sản phẩm tự quyết.
Hiện vật: Nhóm Zalo, Google Form để nhận danh sách nguyên liệu.
Hậu quả nếu sai: Mất vài ngày công, không mất vốn lớn.

Kết quả: - Nhiều người bỏ ở bước nhập liệu. - Người hoàn thành thích gợi ý nhưng không muốn nhập lại. - Phỏng vấn cho thấy vấn đề thật là lập kế hoạch mua sắm.

Kết luận: Giả thuyết về cơ chế nhập liệu bị bác bỏ. Nhu cầu thật lộ ra.

Vòng 2: Xoay trục sang nhu cầu khách hàng

Sự thật: Vòng 1 cho thấy lập kế hoạch mua sắm là nhu cầu lớn hơn.
Hành vi giả định mới: Người dùng sẽ trả tiền cho kế hoạch bữa ăn tuần.
Nhu cầu giả định mới: Cần kế hoạch mua đúng và dùng hết.
Lựa chọn: Xây hệ thống hoàn chỉnh / Dùng trang đặt trước.
Tiêu chí quyết định: Cần bằng chứng cam kết mạnh (tiền).
Quyết định: Dùng Preorder MVP với trang giới thiệu có nút thanh toán thật.
Thẩm quyền: Đội sản phẩm đề xuất, lãnh đạo duyệt chi phí marketing nhỏ.
Hiện vật: Landing page, cổng thanh toán Stripe, email gửi kế hoạch thủ công.
Hậu quả nếu sai: Mất chi phí marketing nhỏ, nhưng có bằng chứng về ý định mua.

Kết quả: - Tỷ lệ đặt trước xác nhận ý định mua. - Tỷ lệ gia hạn xác nhận giá trị dài hạn. - Thời gian làm thủ công cho biết chi phí phục vụ ban đầu.

Kết luận: Nếu có đặt trước nhưng không gia hạn, giả thuyết thu hút đúng nhưng giá trị sai. Phải tách hai kết luận này.

Senior Lens — quản trị quyền quyết định và danh mục đầu tư

1. Quyền tự chủ cần hàng rào

Autonomy (quyền tự chủ) không phải độc lập tuyệt đối. Lãnh đạo đặt cái gì và tại sao. Đội quyết định thế nào.

Đội có quyền: - Khám phá vấn đề, chọn phép thử, chọn cách xây. - Phát hành trong phạm vi an toàn, sắp xếp công việc. - Chịu trách nhiệm về chỉ số kết quả.

Lãnh đạo giữ quyền: - Đặt tầm nhìn, giới hạn chiến lược. - Phân bổ vốn. - Đặt hàng rào (pháp lý, bảo mật, thương hiệu). - Quyết định thay đổi danh mục lớn (đầu tư, khai tử). - Giải quyết xung đột xuyên đội.

Team Mission and Guardrails (Sứ mệnh đội và Hàng rào) phải ghi rõ: Sứ mệnh, Kết quả mục tiêu, Quyền tự quyết, Hàng rào không được vi phạm, Kênh leo thang.

2. Ai quyết định xoay trục?

Không cần đồng thuận tuyệt đối. Mô hình thực dụng: - Người đề xuất: Đội sản phẩm (dựa trên bằng chứng). - Người tư vấn: Kỹ thuật, thiết kế, kinh doanh, pháp lý (cung cấp đánh đổi). - Người quyết định: Chủ sở hữu P&L hoặc vốn đầu tư. - Người được thông báo: Các bên liên quan khác.

Quyết định, bằng chứng, ý kiến phản đối phải được ghi lại. Chức danh không tạo ra bằng chứng. Nhưng loại bỏ quyền quyết định rõ ràng nhân danh "dựa trên dữ liệu" sẽ gây tê liệt.

3. Hộp cát đổi mới trong doanh nghiệp lớn

Innovation Sandbox (hộp cát đổi mới) hiệu quả cần: 1. Nguồn lực nhỏ nhưng được bảo đảm. 2. Đội liên chức năng có thẩm quyền. 3. Phạm vi khách hàng, rủi ro giới hạn. 4. Đo lường bằng Innovation Accounting, không phải doanh thu ngắn hạn. 5. Điều kiện rõ ràng để mở rộng, dừng, hoặc chuyển giao.

Khi sản phẩm được xác thực và chuyển sang giai đoạn tối ưu, giao nó cho đội vận hành khác. Nhóm đổi mới đi tìm cơ hội tiếp theo.

4. Phù hợp theo giai đoạn

Quy trình phải phù hợp bối cảnh, không phải giáo điều.

Bối cảnh	Trọng tâm	Cơ chế phù hợp	Cảnh báo
Startup	Tìm mô hình kinh doanh	`RAT`, đội đa năng, vòng học ngắn	Founder giữ quyết định chi tiết quá lâu
Tăng trưởng	Mở rộng có kiểm soát	Chỉ số tin cậy, vai trò rõ, quản nợ	Tạo quy trình rườm rà trước khi cần
Doanh nghiệp lớn	Đổi mới có kiểm soát	`Sandbox`, quản trị danh mục	Dự án yếu sống dai vì còn ngân sách

5. Quản trị danh mục

Doanh nghiệp cần các trạng thái rõ cho từng sáng kiến: Ý tưởng → Cần xác thực → Sẵn sàng phát triển → Sẵn sàng tăng trưởng → Trưởng thành → Khai tử.

Chỉ ý tưởng đã xác thực mới nhận vốn phát triển. Chỉ sản phẩm đã xác thực mới nhận ngân sách tăng trưởng. Nguồn lực còn không phải lý do để tiếp tục.

6. Tín hiệu cảnh báo

Success Theater: Dùng số đẹp che việc hành vi lõi không đổi.
HiPPO: Ý kiến của người lương cao nhất thay thế bằng chứng.
Feature Factory: Giao nhiều nhưng không tạo kết quả.
Process Theater: Đủ nghi thức nhưng thiếu học hỏi.
Land of the Living Dead: Sản phẩm sống dở chết dở, không đủ tăng trưởng nhưng không bị khai tử.
Dùng MVP làm giấy phép giao chất lượng thấp.
Để khách hàng lớn nhất quyết định lộ trình.
Chỉ đo doanh số, không đo mức dùng, giữ chân, hài lòng.
Tối ưu chỉ số ngắn hạn bằng cách phá hoại hệ sinh thái dài hạn.

Quick reference

Phiếu quyết định trong bất định

Mục	Cần ghi
Vấn đề	Vấn đề số một, cho ai, trong bối cảnh nào?
Liên kết	Nối với mục tiêu và chiến lược nào?
Giả định	Giá trị, tăng trưởng, khả thi, khả dụng, kinh doanh.
Rủi ro lớn nhất	Điều gì chưa biết có thể giết chết kế hoạch?
Phép thử	Cách nhỏ nhất tạo bằng chứng là gì?
Chỉ số	Đường cơ sở, chỉ số hành động, chỉ số bảo vệ.
Ngưỡng	Điều kiện để tiếp tục, xoay trục, hoặc dừng.
Quyền	Ai đề xuất, ai tư vấn, ai quyết định?
Ràng buộc	Pháp lý, bảo mật, thương hiệu, vận hành.
Thời hạn	Ngày nào phải ra quyết định?
Bước tiếp	Mở rộng, thử lại, xoay trục, hay khai tử?

Quy tắc ngắn

Chưa biết cần học gì: chưa xây.
Thử nghiệm phải có cửa thua.
Không có đường cơ sở: không biết có cải thiện không.
Chỉ có số tổng: không thấy quan hệ nhân quả.
Chỉ số cải thiện bền vững: tiếp tục có kiểm soát.
Chỉ số dậm chân sau nhiều thử nghiệm: xem xét xoay trục.
Giá trị kỳ vọng < chi phí + rủi ro: khai tử.
Rủi ro pháp lý, bảo mật, dữ liệu nghiêm trọng: dừng lại.

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

Thuật ngữ	Giải nghĩa
Build-Measure-Learn	Vòng phản hồi Xây dựng-Đo lường-Học hỏi.
Cohort Analysis	Phân tích hành vi theo nhóm người dùng.
Engine of Growth	Cơ chế tạo tăng trưởng bền vững (bám dính, lan truyền, trả phí).
Innovation Accounting	Hệ thống đo tiến bộ trong bất định bằng học hỏi đã xác thực.
Innovation Sandbox	Hộp cát đổi mới: không gian tự chủ có hàng rào để thử nghiệm.
Minimum Viable Product (MVP)	Phiên bản nhỏ nhất của sản phẩm để hoàn thành một vòng học.
Persevere	Kiên trì: tiếp tục chiến lược hiện tại khi có bằng chứng cải thiện.
Pivot	Thay đổi chiến lược có cấu trúc để kiểm tra giả thuyết nền tảng mới.
Product Requirements Document (PRD)	Tài liệu sống căn chỉnh vấn đề, phạm vi, chỉ số và quyết định.
Riskiest Assumption Test (RAT)	Phép thử giả định rủi ro nhất.
Sunset	Khai tử sản phẩm có kế hoạch và hỗ trợ.
Theme-based Roadmap	Lộ trình theo chủ đề (vấn đề), không theo danh sách tính năng.
Validated Learning	Học hỏi được chứng minh bằng dữ liệu thực nghiệm về hành vi khách hàng.

Nguồn và giới hạn

Nguồn

The Lean Startup (Eric Ries): Cung cấp nền tảng về vòng học, MVP, kế toán đổi mới, pivot, và động cơ tăng trưởng.
Product Leadership (Richard Banfield, Martin Eriksson, Nate Walkingshaw): Cung cấp góc nhìn về quản trị, vai trò lãnh đạo, và vận hành sản phẩm ở quy mô lớn.
The Product Book (Product School, Josh Anon): Cung cấp cấu trúc vòng đời, các mẫu tài liệu và quy trình thực tiễn.

Giới hạn

Bối cảnh: Hầu hết case đến từ phần mềm B2C. B2B có chu kỳ bán dài, nhiều bên liên quan, làm tín hiệu về chậm hơn.
Ngành: Ngành bị quản lý chặt (y tế, tài chính, phần cứng) không thể tối giản an toàn, pháp lý, chuỗi cung ứng. Phép thử cần dùng mô phỏng, nguyên mẫu thành phần, hoặc thử nghiệm giới hạn.
Công cụ: Thử nghiệm A/B có thể dẫn đến cực đại cục bộ. Mẫu nhỏ chỉ cho tín hiệu định tính, không có ý nghĩa thống kê.
Con người: Khung tư duy không thay thế phán đoán. Quy trình phải phục vụ kết quả, không phải giáo điều. Việc đọc không thay thế kinh nghiệm thực chiến.

Quyết định tiếp tục, xoay trục hoặc dừng

Sơ đồ trả lời: sau một phép thử, đội nên tiếp tục, xoay trục hay khai tử sản phẩm? Quyết định dựa trên độ tin cậy dữ liệu, xu hướng chỉ số lõi, giả định nền tảng và nguồn lực còn lại.

Quyết định tiếp tục, xoay trục hoặc dừng

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

@startuml
skinparam shadowing false
skinparam backgroundColor white
skinparam state {
  BackgroundColor #F8FAFC
  BorderColor #334155
  FontColor #0F172A
}

[*] --> GhiNguong

state "Ghi giả thuyết\nvà ngưỡng" as GhiNguong
state "Chạy phép thử\nan toàn" as ChayThu
state "Dữ liệu đủ\ntin cậy?" as DuLieuDu <<choice>>
state "Bổ sung dữ liệu\nhoặc sửa phép đo" as BoSungDuLieu
state "Chỉ số lõi cải thiện\nbền vững?" as ChiSoCaiThien <<choice>>
state "Tăng quy mô\ncó kiểm soát" as TiepTuc
state "Giả định nền tảng\ncòn đúng?" as GiaDinhDung <<choice>>
state "Kiểm tra lại\nthực thi" as KiemTraThucThi
state "Kiểm thử giả thuyết\nmới" as Pivot
state "Giá trị kỳ vọng >\nchi phí + rủi ro?" as GiaTriKyVong <<choice>>
state "Khai tử hoặc dừng" as Dung

GhiNguong --> ChayThu
ChayThu --> DuLieuDu
DuLieuDu --> BoSungDuLieu : [Không]
BoSungDuLieu --> ChayThu : [Đã bổ sung dữ liệu\nhoặc sửa phép đo]
DuLieuDu --> ChiSoCaiThien : [Có]

ChiSoCaiThien --> TiepTuc : [Có]
TiepTuc --> [*]

ChiSoCaiThien --> GiaDinhDung : [Không]
GiaDinhDung --> KiemTraThucThi : [Có; thực thi chưa tốt]
KiemTraThucThi --> ChayThu
GiaDinhDung --> Pivot : [Không]
GiaDinhDung --> GiaTriKyVong : [Không rõ và sắp hết nguồn lực]
GiaTriKyVong --> Pivot : [Có]
GiaTriKyVong --> Dung : [Không]
Dung --> [*]
Pivot --> GhiNguong
@enduml

Đội ghi trước giả thuyết và ngưỡng rồi chạy phép thử an toàn. Nếu dữ liệu chưa đủ tin cậy, đội bổ sung dữ liệu hoặc sửa phép đo trước khi đánh giá lại.

Chỉ số lõi cải thiện bền vững thì đội tăng quy mô có kiểm soát. Nếu chưa cải thiện nhưng giả định nền tảng còn đúng, đội kiểm tra lại thực thi và chạy phép thử tiếp.

Giả định nền tảng sai thì đội Pivot — xoay trục để kiểm thử giả thuyết mới. Khi giả định không rõ và nguồn lực sắp hết, đội chỉ xoay trục nếu giá trị kỳ vọng vượt chi phí và rủi ro; nếu không, đội khai tử hoặc dừng.