P5.7 — Technical Product Management cho architecture, API, platform, data và AI

Module: P5 - Prioritization, Roadmap và Delivery

Mục tiêu đọc: Đọc xong có thể tham gia quyết định kỹ thuật mà không chiếm quyền thiết kế của kỹ thuật; mô hình hóa hệ thống, dữ liệu và phụ thuộc; định hình sản phẩm API, platform, data và AI; cân bằng giá trị, reliability, chi phí, technical debt và roadmap; tạo artifact đủ rõ để Product, Engineering, Data, Security và lãnh đạo cùng quyết định.

Nguồn nền và chuẩn bổ sung: Team Topologies; OpenAPI Specification; Google Site Reliability Engineering; NIST AI Risk Management Framework; DORA research program.

Mental model

Technical Product Management là thực hành quản trị sản phẩm có hàm lượng kỹ thuật cao. Nó không biến Product Manager (PM) thành kỹ sư bán thời gian. Nó giúp PM hiểu đủ cơ chế kỹ thuật để đặt đúng câu hỏi, so sánh phương án, quản trị rủi ro và nối đầu tư kỹ thuật với outcome.

Đọc chương không thay thế kinh nghiệm vận hành hệ thống, thiết kế kiến trúc, xử lý incident, quản trị dữ liệu, bảo mật hoặc phát triển mô hình AI. Người đọc cần làm việc cùng chuyên gia và quan sát hệ thống thật trước khi tự chịu trách nhiệm cho quyết định có hậu quả lớn.

PM cần làm rõ:

Người dùng hoặc hệ thống nào nhận giá trị.
Hành vi hoặc kết quả nào phải thay đổi.
Hệ thống chịu trách nhiệm tới đâu.
Các phần trao đổi dữ liệu và trạng thái thế nào.
Chất lượng nào cần bảo đảm.
Rủi ro nào có thể xảy ra.
Chi phí nào phát sinh trong toàn bộ vòng đời.
Ai có quyền đề xuất, quyết định, chặn hoặc chấp nhận rủi ro.
Artifact nào ghi lại quyết định.
Bằng chứng nào mở lại quyết định.

Năm lớp sản phẩm kỹ thuật thường giao nhau:

Architecture — cấu trúc hệ thống, trách nhiệm từng phần và cách thay đổi lan truyền.
API (Application Programming Interface) — hợp đồng cho phép hệ thống hoặc đội tương tác.
Platform product — sản phẩm nền tảng phục vụ sản phẩm hoặc đội khác, thường qua cơ chế tự phục vụ.
Data product — sản phẩm dữ liệu có user, outcome, contract, owner và chất lượng được quản trị.
AI product — sản phẩm dùng mô hình có hành vi xác suất, có thể sai và thay đổi theo dữ liệu.

Ba lực tác động lên mọi lớp:

Value: giá trị người dùng, kinh doanh hoặc vận hành.
Risk: khả năng xảy ra và hậu quả của lỗi, lạm dụng, mất dữ liệu, chi phí hoặc vi phạm.
Flow: khả năng đưa thay đổi từ ý tưởng đến vận hành.

Thiết kế kỹ thuật mạnh nhưng không có người dùng vẫn là đầu tư yếu. Sản phẩm có nhu cầu lớn nhưng reliability thấp có thể tạo thiệt hại lớn hơn giá trị tạo ra.

P5.7 - Technical Product Management cho architecture, API, platform, data và AI — diagram 1

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

flowchart TB
    V["Tiêu chí xuyên suốt: Value, Risk và Flow"]

    A["Xác định capability: consumer, outcome và owner"]
    B["Xác định system boundary và bên chịu trách nhiệm"]
    C["Xác định contract, data flow và bên chịu trách nhiệm"]
    D["Xác định quality target, failure mode và risk acceptor"]
    E["Đánh giá phương án: build, buy, partner hoặc giữ nguyên"]
    F["Ghi quyết định: trade-off, guardrail và decision owner"]
    G["Delivery: release nhỏ và operational owner"]
    H["Đo và học: outcome gap, adoption gap, quality gap, incident, cost, drift và debt"]
    J{"Outcome, adoption và quality đạt target;<br/>risk, cost và failure trong giới hạn?"}
    K["Điều chỉnh: giảm phạm vi, sửa boundary, đổi phương án hoặc tăng human oversight"]
    I["Roadmap review: decision owner chọn tiếp tục, mở rộng, sửa, thay thế hoặc dừng"]
    P["Dừng: decision owner phê duyệt; risk acceptor chấp nhận residual risk;<br/>operational owner quản lý contract, data, consumer và rủi ro khi dừng"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> J

    V -.->|tiêu chí đánh giá| E
    V -.->|tiêu chí đánh giá| F
    V -.->|tiêu chí đánh giá| H
    V -.->|tiêu chí đánh giá| J
    V -.->|tiêu chí đánh giá| I

    J -->|Có| I
    J -->|Không| K

    K -->|Giảm phạm vi| A
    K -->|Sửa boundary| B
    K -->|Đổi phương án| E
    K -->|Tăng human oversight| D
    K -->|Dừng| P

    I -->|Tiếp tục hoặc mở rộng| G
    I -->|Sửa boundary| B
    I -->|Sửa quality target| D
    I -->|Thay thế hoặc đổi phương án| E
    I -->|Dừng| P

Đây không phải stage gate, tức quy trình phê duyệt tuần tự cứng. Khi latency không đạt, đội có thể sửa boundary. Khi AI evaluation cho thấy chất lượng thấp, đội có thể giảm phạm vi, chuyển sang rule-based hoặc tăng human oversight.

Đơn vị quyết định: capability có contract và quality target

Capability là khả năng hệ thống cung cấp cho người dùng hoặc hệ thống khác. Capability hữu ích hơn tên công nghệ vì nó mô tả kết quả cần có, không khóa đội vào giải pháp sớm.

“Dùng event streaming” là giải pháp.
“Thông báo thay đổi trạng thái đơn hàng cho hệ thống đối tác trong giới hạn độ trễ đã thống nhất” là capability.

Capability đủ rõ cần có:

Consumer.
Kết quả cần tạo.
System boundary.
Contract.
Quality attributes.
Owner.
Giới hạn và failure mode.
Cách đo adoption, quality, cost và outcome.

Core

1. Technical literacy và ranh giới vai trò

Technical literacy là năng lực hiểu, đặt câu hỏi và suy luận về hệ thống kỹ thuật. PM không cần viết mọi thành phần, nhưng phải nhận ra cách lựa chọn kỹ thuật ảnh hưởng đến outcome.

Bốn mức năng lực:

Đọc mô hình hệ thống: nhận ra component, flow, dependency, điểm lỗi và owner.
Hiểu trade-off: hỏi phương án tối ưu điều gì, hy sinh điều gì, dễ đảo ngược không.
Chuyển kỹ thuật thành quyết định sản phẩm: hiểu eventual consistency ảnh hưởng tới trải nghiệm thế nào; hiểu rate limit ảnh hưởng tới partner ra sao.
Tham gia governance: giúp thiết lập quyền quyết định, release criteria, guardrail và điều kiện dừng hoặc thay thế.

Technical literacy không trao quyền cho PM tự chọn database, framework hoặc deployment model. PM sở hữu vấn đề, outcome, ưu tiên và trade-off sản phẩm. Tech Lead, Architect hoặc Data/ML Lead sở hữu thiết kế chuyên môn trong phạm vi tương ứng.

Vai trò	Quyền chính	Input phải nhận	Không nên làm
Product Manager	Problem, outcome, persona, adoption, ưu tiên và trade-off sản phẩm	Kỹ thuật, dữ liệu, vận hành, bảo mật, pháp lý, tài chính	Tự chốt thiết kế kỹ thuật hoặc cam kết hiệu năng không có xác nhận
Tech Lead	Thiết kế kỹ thuật trong phạm vi đội, tính khả thi, chất lượng triển khai	Product constraint, kiến trúc chung, yêu cầu vận hành	Tự quyết roadmap hoặc giá trị khách hàng
Architect	Ranh giới hệ thống, nguyên tắc kiến trúc, quyết định xuyên đội	Chiến lược sản phẩm, topology đội, security và operations	Biến mọi quyết định thành phê duyệt tập trung
Engineering Manager	Staffing, năng lực đội, delivery health, vận hành và phát triển con người	Roadmap, technical risk, tổ chức và ngân sách	Dùng utilization làm mục tiêu duy nhất
Data/ML Lead	Phương pháp dữ liệu, đánh giá mô hình, chất lượng, lifecycle và rủi ro mô hình	Use case, harm analysis, data access, cost constraint	Tuyên bố sản phẩm thành công chỉ bằng metric mô hình
Security/Privacy Lead	Control bắt buộc, risk acceptance trong thẩm quyền	Data flow, threat, luật và chính sách áp dụng	Chặn mơ hồ không nêu control hoặc risk
Business Owner	Giá trị đầu tư, risk appetite và cam kết thương mại	Product, Engineering, Finance, Legal	Ép ngày giao hoặc scope chưa qua feasibility review

Decision rule: Người gần chuyên môn nhất đề xuất phương án. Người sở hữu hậu quả quyết định trong thẩm quyền. Quyết định xuyên nhiều miền phải ghi rõ người có quyền chốt cuối. PM phản biện bằng câu hỏi và bằng chứng, không bằng quyền chọn giải pháp.

2. Đọc hệ thống: boundary, component, dependency, data flow và state

System boundary

System boundary xác định phần hệ thống kiểm soát trực tiếp và phần thuộc môi trường bên ngoài.

Boundary quá rộng làm tăng tải nhận thức, phạm vi thay đổi và số team cần phối hợp. Boundary quá hẹp khiến một hành vi người dùng phụ thuộc vào nhiều đội nhưng không có owner duy nhất.

PM cần hỏi:

Hệ thống cam kết hành vi nào.
Hệ thống nào tạo dữ liệu gốc.
Phần nào do vendor hoặc team khác kiểm soát.
Khi thành phần ngoài boundary lỗi, sản phẩm fallback thế nào.
Ai chịu trách nhiệm thông báo cho người dùng.

Component

Component là phần có trách nhiệm kỹ thuật xác định. Nó có thể là service, module, database hoặc model. Mỗi component trên sơ đồ cần có:

Trách nhiệm.
Owner.
Input và output.
State.
Dependency.
Failure mode.
Cách giám sát.

Component không đồng nghĩa với microservice. Modular monolith có thể phù hợp hơn khi đội nhỏ, miền chưa ổn định hoặc chi phí vận hành distributed system chưa đáng giá.

Dependency

Dependency là quan hệ một phần cần phần khác để hoàn thành hành vi. Các dạng thường gặp:

Runtime.
Data.
Delivery.
Organizational.
Commercial.
Knowledge.

Dependency tạo rủi ro khi không có contract, không có owner, thường xuyên chặn flow, hoặc tạo lỗi lan truyền.

Data flow

Data flow mô tả dữ liệu được tạo, biến đổi, lưu trữ và truyền đi. Nó quan trọng hơn danh sách database khi quyết định về privacy, consistency, latency và ownership.

Flow cần ghi:

Nguồn.
Cơ chế truyền.
Biến đổi.
Nơi lưu.
Consumer.
Độ nhạy cảm.
Hành vi khi dữ liệu lỗi hoặc đến muộn.

State

State là thông tin hệ thống phải nhớ qua thời gian. State thường tạo lỗi phức tạp hơn giao diện.

Câu hỏi bắt buộc:

Nguồn nào là source of truth.
Ai được phép chuyển trạng thái.
Trạng thái nào hợp lệ.
Chuyển trạng thái có thể lặp lại an toàn không.
Hai thay đổi đồng thời xử lý thế nào.
Consumer thấy trạng thái tạm thời hay cuối cùng.

Idempotency là khả năng gửi cùng một thao tác nhiều lần nhưng hiệu ứng cuối tương đương một lần. Nó quan trọng với thanh toán, tạo đơn, gửi webhook và retry.

Artifact: System Context and Flow Map

Trường	Nội dung
Outcome	Hành vi hoặc kết quả cần hỗ trợ
Actors	Người dùng và hệ thống bên ngoài
Boundary	Trong phạm vi và ngoài phạm vi
Components	Trách nhiệm và owner từng phần
Data flows	Dữ liệu, hướng truyền, tần suất, độ nhạy cảm
State	Source of truth và state transition chính
Dependencies	Runtime, data, delivery, organization, vendor
Failure modes	Điều gì hỏng và ai chịu tác động
Quality targets	Consistency, latency, throughput, availability
Unknowns	Điều chưa biết và cách giảm bất định

Quality criteria: Kỹ sư mới, người vận hành và PM cùng đọc được. Mỗi flow quan trọng có owner. Sơ đồ không che giấu dependency bên ngoài.

3. Quality attributes

Quality attributes mô tả hệ thống hoạt động tốt đến mức nào ngoài chức năng chính. Chúng tạo trade-off; không thể mặc định mức cao nhất cho mọi thuộc tính.

Consistency

Consistency là mức các thành phần nhìn thấy dữ liệu giống nhau.

Strong consistency phù hợp với giao dịch cần kết quả chính xác ngay.
Eventual consistency phù hợp với dashboard hoặc thông báo tổng hợp nếu có giới hạn trễ rõ ràng.

Nếu dùng eventual consistency, sản phẩm cần mô tả trạng thái đang xử lý, thời điểm cập nhật cuối và cách xử lý dữ liệu đến muộn.

Latency

Latency là thời gian từ request tới response hoặc từ sự kiện tới trạng thái người dùng thấy. PM phải gắn latency với hành trình người dùng, không chỉ với số kỹ thuật.

Phân bố quan trọng hơn average. Đuôi phân bố chậm có thể ảnh hưởng nghiêm trọng tới nhóm người dùng hoặc giao dịch quan trọng.

Throughput

Throughput là khối lượng xử lý trong một đơn vị thời gian. Cần biết:

Tải bình thường.
Tải đỉnh.
Burst.
Payload size.
Cách xử lý quá tải.
Backpressure, tức cơ chế làm chậm producer hoặc xếp hàng khi consumer không theo kịp.

Availability

Availability là khả năng cung cấp hành vi cần thiết khi người dùng cần. Trang mở được nhưng không thanh toán được vẫn là không sẵn sàng theo góc nhìn người dùng.

Google Site Reliability Engineering dùng:

SLI: chỉ số đo hành vi dịch vụ.
SLO: mục tiêu cho SLI.
Error budget: mức lỗi cho phép trong một khoảng thời gian.

SLO phải gắn với hành vi quan trọng, owner và cách phản ứng khi không đạt.

Scalability

Scalability là khả năng xử lý tải tăng mà chất lượng và chi phí còn chấp nhận được. Không đồng nghĩa với mua thêm máy chủ. Có thể cần thay đổi kiến trúc, giảm độ chính xác, giới hạn phạm vi hoặc trì hoãn nhu cầu chưa chắc xảy ra.

Decision rule: Chỉ đầu tư scalability trước khi có tải khi chi phí thất bại rất cao hoặc lead time nâng cấp dài hơn thời gian tăng trưởng. Nếu chưa đủ bằng chứng, thiết kế đường nâng cấp rõ ràng và tránh xây cho quy mô tưởng tượng.

Reliability risk là rủi ro sản phẩm. Nghiên cứu DORA nhấn mạnh tốc độ giao hàng và ổn định vận hành cần được xem cùng nhau, không đánh đổi mù quáng.

4. API như một sản phẩm

API là bề mặt tương tác có contract. Consumer có thể là frontend, mobile app, service nội bộ, partner hoặc khách hàng trả tiền.

OpenAPI Specification giúp mô tả HTTP API theo dạng machine-readable. Nó không tự bảo đảm API dễ dùng, an toàn, ổn định hoặc tương thích ngược.

API contract

Contract cần mô tả:

Request.
Response.
Schema.
Error.
Side effect.
Idempotency.
Pagination.
Rate limit.
Timeout.
Retry.
Versioning.
Deprecation.
Authentication và authorization.
Kênh hỗ trợ.

Backward compatibility

Backward compatibility là khả năng consumer cũ tiếp tục hoạt động sau thay đổi. Breaking change gồm xóa field, đổi kiểu dữ liệu, đổi ý nghĩa field hoặc thay đổi behavior đã được consumer dựa vào.

Breaking change cần có:

Version hoặc migration path.
Consumer inventory.
Thời gian deprecation.
Thông báo.
Telemetry.
Điều kiện kết thúc phiên bản cũ.

Pagination

Pagination chia tập kết quả lớn thành nhiều phần để bảo vệ hiệu năng. Offset-based pagination dễ hiểu nhưng dễ bỏ sót hoặc lặp khi dữ liệu thay đổi. Cursor-based pagination ổn định hơn cho dòng dữ liệu thay đổi nhưng khó triển khai và debug hơn.

Quyết định phải dựa trên:

Cách dữ liệu thay đổi.
Consumer cần nhảy tới trang bất kỳ hay không.
Kích thước tập kết quả.
Chi phí truy vấn.
Yêu cầu ordering.

Rate limit

Rate limit bảo vệ tài nguyên và phân phối công bằng. Contract cần nêu giới hạn, phạm vi, response khi vượt ngưỡng và cách retry.

Webhook

Webhook cho phép hệ thống gửi callback khi có sự kiện. Consumer nên giả định webhook có thể đến lặp, trễ hoặc sai thứ tự, trừ khi contract bảo đảm khác.

Developer experience

Developer experience (DX) là mức dễ dàng và hiệu quả khi lập trình viên dùng API. DX thấp làm tăng lỗi tích hợp, thời gian adoption và chi phí hỗ trợ.

Artifact: API Product Brief

Trường	Nội dung
Consumer và job	Ai dùng và để hoàn thành việc gì
Contract	Operation, schema, error, side effect
Reliability	SLI, SLO, timeout, retry
Scale	Volume, burst, payload, rate limit
Evolution	Versioning, compatibility, deprecation
Safety	Authentication, authorization, audit, privacy
DX	Quickstart, sandbox, example, support
Adoption	Active consumer, successful call, integration time
Ownership	Product, technical và operations owner
Exit	Điều kiện thay thế, dừng hoặc rút API

5. Platform product và internal product

Internal product là sản phẩm phục vụ người dùng bên trong tổ chức. Platform product là sản phẩm cung cấp capability dùng chung cho các team hoặc sản phẩm khác.

Platform cần có:

Persona nội bộ.
Outcome.
Self-service.
Contract.
Reliability target.
Documentation.
Support boundary.
Roadmap.
Adoption measurement.

Theo Team Topologies, platform team tồn tại để giảm cognitive load cho stream-aligned team. Platform không thành công chỉ vì có nhiều capability.

Không phải mọi shared service đều là platform. Shared service yêu cầu ticket và phê duyệt cho mọi thao tác có thể tăng tải thay vì giảm tải. Platform thật sự cung cấp paved path, tức con đường thuận tiện và an toàn để consumer tự phục vụ.

Adoption cần đo:

Số team dùng capability.
Tỷ lệ thao tác self-service.
Thời gian từ nhu cầu tới sử dụng.
Tỷ lệ lỗi.
Ticket tránh được.
Tác động tới delivery flow và outcome consumer.

Decision rule: Chỉ bắt buộc platform khi có lý do cấp tổ chức đủ lớn như security hoặc compliance. Nếu mục tiêu chỉ là tiện lợi, tạo paved path tốt hơn ép buộc.

Anti-pattern:

Xây platform trước khi có consumer.
Đo capability đã xây thay vì outcome consumer.
Mọi yêu cầu đều cần ticket.
Chuyển cognitive load từ hạ tầng sang công cụ và quy trình phức tạp.
Platform team nhận ownership vĩnh viễn nhưng không có exit hoặc service boundary.

6. Data product

Data product là dataset, metric hoặc data service có user, outcome, owner, contract, quality target và lifecycle. Gắn nhãn “data product” cho kho dữ liệu không tạo ra sản phẩm.

Data contract

Data contract cam kết về schema, semantics, quality và cách thay đổi. Định nghĩa “active customer” cần ghi rõ cửa sổ thời gian, sự kiện đủ điều kiện, timezone, dữ liệu đến muộn và cách xử lý record thiếu.

Data lineage

Data lineage ghi đường đi từ nguồn qua biến đổi tới consumer. Nó hỗ trợ:

Phân tích tác động.
Truy nguyên lỗi.
Kiểm soát dữ liệu nhạy cảm.
Xác định owner.
Đánh giá migration.

Data quality

Data quality là mức dữ liệu phù hợp với use case. Cần đo theo hậu quả:

Completeness.
Accuracy.
Timeliness.
Consistency.
Uniqueness.
Validity.

Không có ngưỡng “chất lượng tốt” chung cho mọi use case. Dữ liệu dùng để gửi tiền cần ngưỡng khác dashboard xu hướng.

Data ownership

Data ownership là quyền và trách nhiệm quyết định về dữ liệu. Producer thường phải chịu trách nhiệm về nguồn và semantics; platform team cung cấp cơ chế; business owner chịu trách nhiệm use case; privacy và security xác nhận control.

Mô hình Data team sở hữu mọi dữ liệu dễ tạo bottleneck và tách nguồn dữ liệu khỏi trách nhiệm chất lượng.

Privacy

Privacy phải được thiết kế trong data flow từ đầu. PM không tự diễn giải nghĩa vụ pháp lý. Legal, Privacy và Security phải xác nhận mục đích sử dụng, quyền truy cập, retention, deletion, audit và các control áp dụng.

Artifact: Data Product Card

Trường	Nội dung
User và decision	Ai dùng dữ liệu để quyết định gì
Source	Hệ thống tạo và source of truth
Semantics	Định nghĩa field, metric và grain
Contract	Schema, quality, freshness, version
Lineage	Upstream, transform, downstream
Ownership	Business, producer, platform, privacy
Access	Role, purpose, audit
Lifecycle	Retention, deletion, archive
Monitoring	Quality check và incident path
Consumer promise	Điều dữ liệu bảo đảm và không bảo đảm

Quality criteria: Consumer hiểu semantics không cần hỏi riêng tác giả. Quality target gắn với use case. Owner có quyền sửa nguồn. Privacy control được xác nhận.

7. AI product

AI product dùng mô hình có hành vi xác suất. Output có thể sai dù hệ thống chạy đúng. Mô hình, prompt, retrieval source hoặc dữ liệu thay đổi đều có thể làm behavior thay đổi.

Use case trước model

Không bắt đầu bằng “cần AI”. Bắt đầu bằng:

Quyết định hoặc task cần hỗ trợ.
User.
Baseline hiện tại.
Giá trị khi đúng.
Tổn thất khi sai.
Mức có thể đảo ngược.
Quyền can thiệp của con người.

Evaluation set

Evaluation set là tập tình huống đại diện để đo chất lượng AI. Tập này cần gồm:

Use case phổ biến.
Trường hợp khó.
Nhóm người dùng khác nhau.
Harm scenario.
Input bất thường.
Trường hợp thiếu dữ liệu.
Phiên bản nguồn và cách tạo dữ liệu.

Metric tổng hợp có thể che giấu lỗi nghiêm trọng ở nhóm nhỏ. Model metric không thay thế product outcome hoặc harm metric.

Human oversight

Human oversight có thể là:

Duyệt mọi output.
Duyệt mẫu.
Xem xét trường hợp rủi ro cao.
Override.
Appeal.
Dừng hệ thống.

Người giám sát phải có đủ thông tin, thời gian và thẩm quyền. Gọi tên con người nhưng giao quá nhiều output để họ chỉ bấm duyệt là oversight giả.

Drift

Drift là suy giảm chất lượng khi dữ liệu, môi trường hoặc hành vi người dùng thay đổi. Cần theo dõi input distribution, output quality proxy, feedback, incident và thay đổi source.

Latency và cost

Chi phí AI gồm inference, storage, retrieval, evaluation, monitoring và human review. Cần đo cost theo task hoặc outcome thành công, không chỉ theo request.

Model lifecycle

Lifecycle gồm chọn, đánh giá, phát hành, giám sát, rollback, thay thế và retirement. Mọi thay đổi model, prompt hoặc data source cần versioning và evaluation lại.

NIST AI Risk Management Framework mô tả bốn chức năng:

Govern: chính sách, trách nhiệm và risk tolerance.
Map: bối cảnh, stakeholder và harm.
Measure: đánh giá quality, risk và limitation.
Manage: xử lý, ưu tiên và theo dõi rủi ro.

Artifact: AI Product Evaluation Card

Trường	Nội dung
Use case	Tác vụ, user, outcome
Decision role	Assist, recommend, decide hoặc act
Harm	Ai có thể bị hại và mức độ đảo ngược
Baseline	Quy trình hiện tại hoặc phương án không dùng AI
Evaluation set	Coverage, source, version, contamination control
Metrics	Model, product, business, harm
Oversight	Review, override, appeal, stop
Runtime	Latency, availability, fallback
Economics	Cost theo task hoặc outcome
Monitoring	Drift, quality proxy, incident
Lifecycle	Version, release, rollback, retirement
Authority	Người phê duyệt phạm vi và người dừng hệ thống

8. Technical debt, build-buy-partner và ADR

Technical debt

Technical debt là chi phí hoặc rủi ro tương lai do lựa chọn hiện tại. Debt không chỉ là code xấu. Nó gồm:

Delivery debt.
Reliability debt.
Security debt.
Data debt.
Architecture debt.
Observability debt.
Vendor debt.
Knowledge debt.

PM nên ghi:

Debt tạo ra.
Lợi ích ngắn hạn.
Chi phí trả nợ.
Hậu quả nếu giữ.
Owner.
Trigger hoặc deadline.
Cách đo.

Decision rule: Sửa debt ngay khi có nguy cơ mất dữ liệu, lỗ hổng bảo mật, vi phạm control hoặc chặn mọi thay đổi mới. Debt khác có thể gộp vào feature, cấp bet riêng hoặc chấp nhận có thời hạn.

Không ưu tiên debt chỉ vì code “không đẹp”. Ưu tiên theo hậu quả và xác suất.

Build-buy-partner

Build-buy-partner so sánh tự xây, mua, hợp tác và giữ nguyên. Không chỉ so sánh giá mua với effort xây. Cần xét:

Khác biệt chiến lược.
Kiểm soát behavior.
TCO.
Chi phí tích hợp.
Chi phí migration.
Vendor lock-in.
Data portability.
Security và privacy.
SLA.
Khả năng thoát.
Năng lực vận hành.
Tốc độ học hỏi.

Decision rule:

Build khi capability tạo khác biệt chiến lược hoặc thị trường không cung cấp phù hợp.
Buy khi capability phổ thông và vendor có economics, reliability, security phù hợp.
Partner khi hai bên có tài sản bổ sung và contract phân bổ trách nhiệm rõ.
Keep khi vấn đề chưa đủ quan trọng hoặc evidence chưa đủ.

Architecture Decision Record

ADR ghi lại quyết định kiến trúc quan trọng, bối cảnh, lựa chọn, trade-off và hậu quả. ADR không phải biên bản để hợp thức hóa quyết định đã chốt.

ADR tối thiểu gồm:

Context.
Decision.
Options considered.
Decision criteria.
Consequences.
Rejected options.
Owner.
Date.
Review trigger.
Reversal hoặc migration path.

PM đóng góp problem, outcome, user impact, economics và risk. Tech Lead hoặc Architect sở hữu quyết định kỹ thuật. Không viết ADR cho lựa chọn nhỏ, dễ đảo ngược.

9. Roadmap trade-off cho đầu tư kỹ thuật

Mỗi đầu tư kỹ thuật cần nối với ít nhất một mục đích:

Tạo capability mới.
Giảm rủi ro.
Tăng flow.
Giảm chi phí vòng đời.

Roadmap không nên tách “feature work” và “technical work” thành hai thế giới không liên quan. Một thay đổi kỹ thuật đáng ưu tiên khi nó bảo vệ outcome, mở capability, giảm lead time hoặc giảm hậu quả sự cố.

Artifact: Technical Product Decision Brief

Phần	Nội dung bắt buộc
Problem và outcome	Ai gặp vấn đề và thay đổi nào cần tạo
System context	Boundary, component, dependency, data flow, state
Consumers	User, developer, đội, partner, model hoặc report
Contract	API, data hoặc behavior contract
Quality attributes	Consistency, latency, throughput, availability, scalability
Risk	Reliability, security, privacy, data, AI, vendor
Options	Keep, build, buy, partner và phương án bị loại
Economics	Chi phí xây, vận hành, migration và exit
Technical debt	Debt tạo mới, trả bớt hoặc chấp nhận
Decision rights	Người đề xuất, quyết định, veto và tư vấn
Delivery	Vertical slice, rollout, fallback, rollback
Measurement	Adoption, SLI, SLO, quality, cost, outcome
Review trigger	Sự kiện hoặc bằng chứng mở lại quyết định
Consequence	Điều xảy ra nếu quyết định sai

Quality criteria: Có một outcome chính. Fact và assumption tách biệt. Có phương án giữ nguyên. Downside được nêu. Có operations owner. Có điều kiện dừng. Có authority rõ.

Applied

Tình huống mô phỏng: API trạng thái đơn hàng, dashboard và trợ lý AI

Đây là tình huống mô phỏng. Các dữ kiện dưới đây phục vụ học tập, không phải số liệu thực tế hay tuyên bố về doanh nghiệp cụ thể.

Doanh nghiệp B2B muốn cung cấp trạng thái đơn hàng qua API và webhook, dashboard gần thời gian thực cho đội vận hành, và trợ lý AI giải thích đơn hàng chậm. Hệ thống hiện tại là monolith với database dùng chung. Các job batch cập nhật dữ liệu theo chu kỳ. Nhiều consumer dùng cùng field nhưng hiểu semantics khác nhau.

Case 1: Có nên xây event platform trước không?

Facts

Đối tác muốn nhận thay đổi trạng thái đơn hàng.
Đội vận hành muốn dashboard cập nhật nhanh hơn batch hiện tại.
Hệ thống hiện tại có state đơn hàng không nhất quán.
Chưa có consumer inventory hoàn chỉnh.
Chưa có data contract chung cho event.
Chưa biết mọi consumer cần latency bao nhiêu.
Event platform là giải pháp được đề xuất, chưa phải outcome.

Current behavior

Batch job tạo bản tổng hợp theo chu kỳ.
Một số consumer đọc trực tiếp database dùng chung.
Hai hệ thống có thể hiển thị trạng thái khác nhau.
Khi job lỗi, consumer thường phát hiện muộn.
Đội hỗ trợ phải kiểm tra thủ công.

Underlying need

Partner cần biết trạng thái đơn hàng để đồng bộ quy trình của họ.
Operations cần phát hiện đơn chậm và xử lý ngoại lệ.
Doanh nghiệp cần một nguồn trạng thái có semantics rõ.
Các consumer cần behavior có thể dự đoán khi dữ liệu trễ hoặc lỗi.

Options

Giữ batch và cải thiện monitoring.
Chuẩn hóa order state trong monolith rồi cung cấp API đọc.
Tạo event delivery nhỏ cho một use case partner.
Xây event platform dùng chung trước khi xác nhận consumer.
Mua hoặc hợp tác với vendor event delivery.

Decision criteria

Giá trị outcome trong 6 tháng.
Số consumer có nhu cầu thật.
Độ quan trọng của latency.
Chi phí vận hành.
Khả năng rollback.
Rủi ro contract sai.
Khả năng mở rộng sau vertical slice.
Năng lực đội vận hành.
TCO và exit cost.

Decision

Không xây event platform tổng quát trước. Chuẩn hóa order state và data contract trước; sau đó phát hành một vertical slice cho một partner có nhu cầu đã xác nhận. Giữ batch cho dashboard nếu latency mục tiêu chưa cần thấp hơn. Chỉ mở rộng event capability khi consumer, volume và failure behavior có bằng chứng.

Authority

PM quyết định problem framing, outcome, scope và ưu tiên.
Tech Lead quyết định thiết kế triển khai trong slice.
Architect quyết định nguyên tắc boundary nếu thay đổi xuyên đội.
Partner owner xác nhận consumer contract.
Security/Privacy xác nhận data exposure.
Business Owner quyết định đầu tư nếu TCO vượt thẩm quyền team.

Artifact

System Context and Flow Map.
API Product Brief.
Data Product Card cho Order State History.
ADR cho event delivery scope.
Release checklist có fallback.

Consequence if wrong

Nếu xây platform quá sớm, đội có thể tạo capability không ai dùng, tăng chi phí vận hành và khóa contract sai. Nếu chỉ giữ batch khi partner cần cập nhật nhanh, partner có thể tự xây workaround, tạo thêm dependency khó gỡ. Review trigger là consumer adoption thấp, incident lặp lại, latency vượt target hoặc volume tăng ngoài giả định.

Case 2: API contract cho trạng thái đơn hàng

Facts

Partner cần nhận event trạng thái.
Webhook có thể được retry khi network lỗi.
Order state có thể đến muộn từ hệ thống nguồn.
Consumer chưa thống nhất việc xử lý event trùng.
API chưa có versioning và deprecation policy.
OpenAPI Specification có thể mô tả schema nhưng không định nghĩa toàn bộ behavior.

Current behavior

Consumer đọc database trực tiếp.
Field status có nhiều cách hiểu.
Không có cam kết ordering.
Không có idempotency key.
Khi lỗi, mỗi consumer tự retry.

Underlying need

Partner cần tích hợp ổn định, không tạo đơn hoặc hành động hai lần, và biết khi nào event chỉ là trạng thái tạm thời.

Options

Cung cấp API đọc, không webhook.
Webhook at-least-once, consumer xử lý duplicate.
Webhook cố gắng exactly-once.
Partner tiếp tục đọc database.
Dùng vendor quản lý delivery.

Decision criteria

Khả năng bảo đảm behavior thật.
Tác động của duplicate.
Chi phí và độ phức tạp retry.
Recovery khi consumer down.
Backward compatibility.
Observability.
TCO và khả năng thay vendor.
Thời gian tích hợp partner.

Decision

Phát hành API đọc và webhook at-least-once. Mỗi event có event ID, aggregate ID, event type, version, occurred time và source. Consumer phải deduplicate bằng event ID. Contract không cam kết ordering toàn cục; nếu cần ordering trong một order, contract ghi rõ partition hoặc sequence. API có versioning, deprecation window, rate limit, timeout và error behavior.

Authority

Product Manager quyết định consumer promise và rollout scope.
Tech Lead quyết định delivery mechanism và retry implementation.
Architect quyết định contract boundary nếu có nhiều producer.
Security Lead quyết định authentication, authorization và audit control.
Partner owner chấp nhận migration effort.
Người sở hữu hậu quả production quyết định go/no-go trong release review.

Artifact

API Product Brief ghi consumer, contract, SLO, error, retry, versioning, security, DX và support owner. OpenAPI Specification mô tả schema. ADR ghi at-least-once thay vì cố gắng exactly-once.

Consequence if wrong

Nếu contract ngầm cam kết ordering hoặc exactly-once nhưng hệ thống không bảo đảm, partner có thể ghi sai trạng thái hoặc tạo hành động lặp. Nếu rate limit không phù hợp, partner bị gián đoạn hoặc hệ thống nội bộ bị quá tải. Nếu deprecation không có telemetry, breaking change có thể làm hỏng consumer cũ.

Case 3: Data product cho `Order State History`

Facts

Dashboard và AI đều cần lịch sử trạng thái.
Nguồn hiện tại có record thiếu và đến muộn.
Nhiều team định nghĩa “delayed order” khác nhau.
Dữ liệu có thể chứa thông tin khách hàng và đơn hàng.
Chưa có owner duy nhất cho semantics.
Không có freshness hoặc completeness target.

Current behavior

Mỗi team tạo query riêng.
Metric dashboard và report không khớp.
AI lấy dữ liệu từ các nguồn không đồng nhất.
Khi dữ liệu sai, không biết sửa source nào.
Quyền truy cập được cấp theo cách khác nhau.

Underlying need

Các team cần một nguồn lịch sử trạng thái có semantics, quality target, lineage, access control và incident path rõ để ra quyết định vận hành.

Options

Mỗi team tiếp tục tự tạo dataset.
Data team làm dataset tập trung nhưng sở hữu toàn bộ semantics.
Producer sở hữu nguồn và semantics; platform cung cấp pipeline, contract và monitoring.
Mua data platform.
Tạm thời giữ report hiện tại và chỉ sửa metric quan trọng.

Decision criteria

Use case và hậu quả dữ liệu sai.
Quyền sửa source.
Tính minh bạch semantics.
Freshness và completeness cần thiết.
Privacy và access control.
Chi phí vận hành.
Lineage và impact analysis.
Khả năng phục hồi khi source thay đổi.

Decision

Tạo data product Order State History. Producer sở hữu source và event semantics. Business owner xác nhận định nghĩa delayed order. Platform team cung cấp cơ chế ingest, validation, lineage và access. Data Product Card ghi grain, source of truth, schema, freshness, quality, retention, access và incident path. Dashboard dùng data product trước; AI chỉ dùng phiên bản đã đánh giá.

Authority

Business Owner quyết định định nghĩa business metric.
Producer owner chịu trách nhiệm source quality.
Data/ML Lead quyết định validation và evaluation method.
Platform team quyết định pipeline implementation.
Privacy/Security xác nhận purpose, access và retention.
PM quyết định use case ưu tiên và adoption target.

Artifact

Data Product Card.
Data contract.
Lineage map.
Quality monitor.
Metric definition.
Access review record.

Consequence if wrong

Nếu data product không có semantics rõ, dashboard tiếp tục mâu thuẫn và AI học từ nhãn sai. Nếu access quá rộng, privacy risk tăng. Nếu owner không có quyền sửa source, incident chỉ được che bằng downstream patch. Nếu freshness target quá cao so với outcome, chi phí tăng mà quyết định không tốt hơn.

Case 4: Có nên phát hành trợ lý AI giải thích đơn hàng chậm?

Facts

Operations muốn biết nguyên nhân đơn hàng chậm.
Dữ liệu trạng thái hiện đang được chuẩn hóa.
Output AI có thể giải thích sai hoặc bịa nguyên nhân.
Chưa có evaluation set.
Chưa xác định AI assist, recommend, decide hay act.
Một giải thích sai có thể dẫn tới xử lý sai partner hoặc khách hàng.
Rule-based explanation có thể bao phủ các nguyên nhân đã biết.

Current behavior

Nhân viên mở nhiều màn hình và kiểm tra thủ công.
Một số nguyên nhân được xác định bằng rule nội bộ.
Khi dữ liệu thiếu, nhân viên ghi nhận “unknown”.
Chưa có cơ chế đo thời gian điều tra hoặc lỗi xử lý.

Underlying need

Operations cần giảm thời gian tìm nguyên nhân và biết khi nào thông tin không đủ. Họ không cần AI tự quyết định thay đổi đơn hàng.

Options

Giữ quy trình thủ công.
Xây rule-based explanation.
Phát hành AI assist với human review.
Cho AI recommend action.
Cho AI tự act trên đơn hàng.

Decision criteria

Giá trị của thời gian tiết kiệm.
Accuracy theo từng harm scenario.
Khả năng phát hiện uncertainty.
Mức độ đảo ngược khi sai.
Chất lượng evaluation set.
Human oversight thực tế.
Latency và cost theo task thành công.
Fallback.
Quyền dừng và rollback.
Tác động tới nhóm người dùng khác nhau.

Decision

Phát hành rule-based explanation trước trong phạm vi assist. Khi dữ liệu đủ ổn định, xây evaluation set gồm case phổ biến, case khó, dữ liệu thiếu, trạng thái đến muộn và nguyên nhân gây hại. AI chỉ được thử nghiệm với human review, hiển thị nguồn dữ liệu và mức không chắc chắn phù hợp. AI không được tự thay đổi order state hoặc gửi cam kết tới khách hàng.

Authority

PM quyết định use case, phạm vi và outcome.
Data/ML Lead quyết định evaluation design và model lifecycle.
Operations owner quyết định workflow review.
Security/Privacy/Legal xác nhận data use và risk control.
Tech Lead quyết định runtime, fallback và observability.
Business Owner chấp nhận residual risk trong thẩm quyền.
Người được chỉ định có quyền stop system khi harm hoặc quality vượt ngưỡng.

Artifact

AI Product Evaluation Card.
Baseline workflow measurement.
Evaluation set có version.
Prompt/model/data-source version.
Human oversight procedure.
Incident và rollback runbook.
Release decision record.

Consequence if wrong

Nếu demo tốt nhưng evaluation set yếu, hệ thống có thể sai trong case quan trọng. Nếu human review không đủ năng lực, oversight trở thành hình thức. Nếu AI bịa nguyên nhân, operations có thể xử lý sai và làm tăng delay. Nếu không có rollback, incident kéo dài. Nếu AI tự act quá sớm, hậu quả có thể khó đảo ngược.

Roadmap decision

Roadmap chia thành vertical slice:

Chuẩn hóa order state và source of truth.
Cung cấp API đọc cho một consumer xác nhận.
Cung cấp webhook at-least-once với contract rõ.
Tạo Order State History data product.
Cải thiện dashboard dựa trên data product.
Phát hành rule-based explanation.
Xây evaluation set và thử nghiệm AI assist.
Đánh giá adoption, reliability, quality, cost và harm.
Mở rộng, sửa, thay thế hoặc dừng theo review trigger.

Thứ tự này không phải quy tắc “luôn xây nền tảng trước feature”. Nó phản ánh dependency và risk của tình huống mô phỏng. Nếu outcome khác, thứ tự có thể đổi.

Senior Lens

1. Khi nào PM phải đi sâu

PM cần đi sâu hơn khi quyết định:

Khó đảo ngược.
Ảnh hưởng nhiều team.
Tạo public contract.
Di chuyển hoặc xóa dữ liệu.
Gắn với vendor dài hạn.
Ảnh hưởng reliability hoặc privacy.
Tạo model behavior mới.
Thay đổi cost curve.
Có thể gây harm cho người dùng.
Cần business hoặc executive risk acceptance.

PM không cần tự thiết kế chi tiết. PM cần bảo đảm decision brief có đủ context, options, criteria, owner, authority, risk, artifact và review trigger.

2. Veto phải hẹp và rõ

Veto hợp lệ phải gắn với chuyên môn và hậu quả cụ thể.

Security có thể chặn khi control bắt buộc chưa đạt.
Privacy có thể chặn khi purpose hoặc data handling chưa được xác nhận.
Operations có thể chặn khi không có khả năng giám sát hoặc phục hồi.
Engineering có thể chặn khi không thể bảo đảm quality target trong constraint hiện tại.
Product không nên dùng veto để ép một công nghệ.
Business không nên dùng ngày giao để phủ nhận feasibility hoặc risk.

Người dùng veto phải nêu:

Rủi ro.
Control hoặc bằng chứng còn thiếu.
Phạm vi veto.
Điều kiện gỡ chặn.
Người có thẩm quyền chấp nhận residual risk nếu vẫn muốn tiếp tục.

3. Reliability và error budget

Khi error budget cạn, lựa chọn không còn đơn giản là feature hay technical work. Đội cần chọn giữa:

Giảm tốc độ release.
Sửa failure mode.
Giảm scope.
Tăng capacity hoặc redundancy.
Thay đổi SLO nếu target không còn phù hợp.
Chấp nhận risk với authority phù hợp.

Giảm SLO chỉ để làm đẹp dashboard không phải xử lý reliability. Nếu user journey quan trọng vẫn lỗi, sản phẩm vẫn không đáng tin.

4. Khi technical debt thắng roadmap

Debt nên thắng roadmap khi:

Có nguy cơ mất dữ liệu.
Có lỗ hổng bảo mật.
Vi phạm control bắt buộc.
Incident lặp lại.
Không thể rollback.
Chặn thay đổi quan trọng.
Làm chi phí vận hành tăng vượt ngưỡng.
Không còn owner hiểu hệ thống.

Debt không tự động thắng vì code cũ hoặc kiến trúc không hợp gu. PM và Engineering cần lượng hóa hậu quả, xác suất, chi phí trả nợ và cost of delay.

5. Red flags

Sản phẩm	Dấu hiệu	Câu hỏi senior
API	“API xong” nhưng chưa có consumer chạy	Consumer nào đạt outcome nào?
API	Schema có nhưng chưa ghi error, retry, idempotency	Behavior nào consumer đang tự đoán?
Platform	Nhiều ticket hơn self-service action	Platform giảm hay chuyển cognitive load?
Platform	Nhiều capability nhưng adoption thấp	Consumer nào cần capability này?
Data	Một metric có nhiều định nghĩa	Business owner nào chốt semantics?
Data	Data team sửa mọi lỗi downstream	Producer có quyền và trách nhiệm sửa source không?
AI	Demo tốt nhưng không có evaluation set	Case khó và harm scenario nào được đo?
AI	Có human review nhưng không có quyền stop	Reviewer thật sự có authority không?
Architecture	Công nghệ được chọn trước use case	Outcome nào biện minh cho lựa chọn?
Debt	Đề xuất rewrite toàn bộ	Có thể sửa, thay thế hoặc migrate từng phần không?
Vendor	Giá mua thấp nhưng exit chưa rõ	TCO, portability và migration cost là gì?
Reliability	Dùng average latency hoặc uptime trang	Hành vi quan trọng nào user thực sự nhận được?

6. Anti-pattern tổng quát

Solution-first architecture

Đội bắt đầu bằng công nghệ rồi tìm use case. Cách này tạo sunk cost và làm PM bảo vệ giải pháp thay vì outcome.

Contract by accident

Client phụ thuộc vào behavior không được cam kết. Khi producer thay đổi implementation, consumer hỏng dù không có breaking change được ghi nhận.

Data lake as strategy

Đội gom dữ liệu trước khi có user, decision, semantics và owner. Kết quả là kho đắt tiền, khó tin cậy và không ai chịu trách nhiệm.

Rewrite as debt payment

Đội viết lại toàn bộ để “giải quyết debt”, nhưng làm mất learning, tăng migration risk và trì hoãn outcome. Sửa, cô lập hoặc thay từng phần thường an toàn hơn.

Platform as ticket queue

Platform gọi mình là self-service nhưng mọi thao tác cần người duyệt. Consumer không có autonomy và platform trở thành bottleneck.

AI metric theater

Đội tối ưu metric model đẹp nhưng không đo task success, harm, adoption, cost hoặc fallback. Model tốt không đồng nghĩa sản phẩm tốt.

7. Bất định và cách xử lý

Phân loại bất định trước khi chọn phương án:

Loại bất định	Cách giảm	Quyết định phù hợp
Có thể đo bằng instrumentation	Thêm telemetry hoặc baseline	Đo trước khi mở rộng
Có thể thử bằng vertical slice	Release phạm vi nhỏ	Học với blast radius thấp
Liên quan contract hoặc migration	Consumer inventory, compatibility test	Chốt owner và rollback trước
Liên quan harm	Evaluation set, review, risk limit	Giảm scope và tăng oversight
Không thể đảo ngược	Escalate, review nhiều miền	Chậm hơn, ghi authority rõ
Liên quan vendor	TCO, exit test, portability review	Không khóa trước khi có exit path

Không phải bất định nào cũng cần nghiên cứu thêm. Khi chi phí học cao và hậu quả thấp, có thể thử nhỏ. Khi hậu quả cao và khó đảo ngược, cần giảm scope, đặt risk limit và escalates tới người có authority.

8. Không dùng framework máy móc

Team Topologies giúp suy nghĩ về cognitive load, team boundary và platform interaction. Nó không quy định mọi tổ chức phải có cùng loại team.

OpenAPI Specification giúp mô tả HTTP API. Nó không thay thế product contract, security review hoặc consumer research.

Google Site Reliability Engineering cung cấp khái niệm SLI, SLO và error budget. Target phải dựa trên user journey, cost và risk của sản phẩm.

NIST AI Risk Management Framework cung cấp ngôn ngữ quản trị rủi ro AI. Nó không tự xác định nghĩa vụ pháp lý hoặc ngưỡng chấp nhận cho mọi ngành.

DORA research program cung cấp góc nhìn về software delivery và operational performance. Không dùng benchmark như quota hoặc mục tiêu duy nhất.

Quick reference

Bộ câu hỏi trước quyết định kỹ thuật lớn

Miền	Câu hỏi
Outcome	Ai nhận giá trị? Hành vi nào đổi?
Problem	Bằng chứng nào cho thấy vấn đề tồn tại?
Consumer	Người dùng hoặc hệ thống nào tiêu thụ capability?
Boundary	Hệ thống và đội chịu trách nhiệm tới đâu?
State	Source of truth là gì? Ai được chuyển trạng thái?
Dependency	Dependency nào có thể chặn flow hoặc lan truyền lỗi?
Contract	Consumer dựa vào schema và behavior nào?
Consistency	Dữ liệu cần mạnh ngay hay có thể eventual?
Latency	User cần phản hồi trong bao lâu? Đo percentile nào?
Throughput	Tải thường, tải đỉnh và burst là gì?
Availability	Hành vi quan trọng nào cần luôn dùng được?
Scalability	Tăng trưởng nào có bằng chứng? Có thể nâng cấp sau không?
Security	Authentication, authorization, audit và threat là gì?
Privacy	Mục đích, access, retention và deletion thế nào?
Data	Semantics, lineage, quality và owner là gì?
AI	AI assist, recommend, decide hay act?
Harm	Ai chịu hậu quả nếu output sai? Có thể đảo ngược không?
Economics	TCO, cost theo task và exit cost là gì?
Options	Keep, build, buy và partner đã được xét chưa?
Debt	Debt nào tạo mới, trả bớt hoặc chấp nhận?
Delivery	Vertical slice, rollout, fallback và rollback là gì?
Measurement	Adoption, quality, SLI, SLO, cost và outcome đo thế nào?
Authority	Ai đề xuất, quyết định, veto, tư vấn và chấp nhận risk?
Escalation	Khi nào cần Architect, Security, Legal, Finance hoặc executive?
Review	Bằng chứng hoặc sự kiện nào mở lại quyết định?

Quality floor trước release

Capability kỹ thuật không nên phát hành nếu thiếu các điều kiện bắt buộc sau:

Owner sản phẩm, kỹ thuật và vận hành rõ.
Consumer và outcome xác định.
Contract được viết và version.
Failure behavior được mô tả.
Authentication, authorization và privacy control phù hợp.
Observability đủ để biết hệ thống có hoạt động đúng.
SLI và SLO phù hợp với user journey nếu reliability quan trọng.
Rollout có phạm vi và blast radius kiểm soát.
Fallback hoặc rollback khả thi.
Support và incident path rõ.
Cost được theo dõi.
Data quality hoặc AI evaluation đạt ngưỡng đã quyết định.
Điều kiện dừng được ghi.
Authority phê duyệt đã được xác định.

Không phải mọi capability cần cùng quality target. Quality floor bảo đảm rủi ro bắt buộc được xử lý; decision brief xác định mức cao hơn cần thiết cho use case.

Artifact map

Câu hỏi	Artifact
Hệ thống gồm gì và phụ thuộc ra sao?	System Context and Flow Map
API cam kết behavior nào?	API Product Brief và OpenAPI Specification
Dữ liệu có nghĩa gì và ai chịu trách nhiệm?	Data Product Card và data contract
AI có thể sai ở đâu?	AI Product Evaluation Card
Vì sao chọn kiến trúc này?	ADR
Quyết định sản phẩm kỹ thuật tổng thể là gì?	Technical Product Decision Brief
Khi nào phải dừng hoặc mở lại?	Review trigger, runbook và release record

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
Product Manager	PM	Người chịu trách nhiệm giá trị và kết quả sản phẩm	Quyền quyết định sản phẩm
Technical literacy	—	Năng lực hiểu và suy luận về kỹ thuật	Năng lực PM
Architecture	—	Cấu trúc hệ thống và quan hệ giữa các phần	Quyết định hệ thống
System boundary	—	Ranh giới trách nhiệm của hệ thống	Phân tích phạm vi
Component	—	Phần có trách nhiệm kỹ thuật xác định	Mô hình hệ thống
Dependency	—	Quan hệ một phần cần phần khác	Phân tích rủi ro delivery và runtime
Data flow	—	Đường dữ liệu được tạo, biến đổi, lưu và truyền	Privacy, ownership, consistency
State	—	Thông tin hệ thống nhớ qua thời gian	State transition và source of truth
Source of truth	—	Nguồn có thẩm quyền cho dữ liệu	Xử lý xung đột dữ liệu
Capability	—	Khả năng hệ thống cung cấp	Đơn vị roadmap
Contract	—	Cam kết có thể kiểm tra giữa provider và consumer	API, data và behavior
Quality attributes	—	Thuộc tính chất lượng ngoài chức năng	Latency, availability, privacy
Reliability	—	Khả năng cung cấp hành vi đúng và ổn định	Rủi ro vận hành
Consistency	—	Mức các thành phần nhìn thấy dữ liệu giống nhau	Strong hoặc eventual
Strong consistency	—	Dữ liệu được đồng bộ nhất quán ngay theo mô hình cam kết	Giao dịch quan trọng
Eventual consistency	—	Dữ liệu đạt nhất quán sau khoảng trễ	Dashboard và tổng hợp
Latency	—	Thời gian từ request tới response hoặc từ event tới trạng thái thấy được	Trải nghiệm và SLO
Throughput	—	Khối lượng xử lý trong một đơn vị thời gian	Tải hệ thống
Backpressure	—	Cơ chế làm chậm producer khi consumer không theo kịp	Xử lý quá tải
Availability	—	Khả năng cung cấp hành vi cần thiết khi cần	Sẵn sàng dịch vụ
Scalability	—	Khả năng xử lý tải tăng với chất lượng và chi phí chấp nhận được	Tăng trưởng
API	—	Giao diện lập trình ứng dụng	Sản phẩm kỹ thuật
API contract	—	Cam kết request, response và behavior của API	Tích hợp
OpenAPI Specification	—	Chuẩn mô tả machine-readable cho HTTP API	Schema và documentation
Backward compatibility	—	Khả năng consumer cũ tiếp tục hoạt động	Evolution
Breaking change	—	Thay đổi có thể làm consumer cũ hỏng	Versioning
Deprecation	—	Quy trình ngừng hỗ trợ capability hoặc version	Migration
Idempotency	—	Gửi thao tác lặp nhưng hiệu ứng cuối tương đương một lần	Payment, webhook, retry
Pagination	—	Chia tập kết quả thành nhiều phần	API query
Rate limit	—	Giới hạn số request trong khoảng thời gian	Bảo vệ tài nguyên
Webhook	—	Callback do hệ thống gửi khi có event	Event delivery
Developer experience	DX	Mức dễ dàng và hiệu quả khi dùng sản phẩm kỹ thuật	API adoption
Platform product	—	Sản phẩm nền tảng phục vụ team hoặc sản phẩm khác	Internal product
Internal product	—	Sản phẩm phục vụ người dùng nội bộ	Platform
Self-service	—	Người dùng tự thực hiện thao tác không cần hỗ trợ thủ công	Platform adoption
Paved path	—	Con đường thuận tiện, an toàn và được hỗ trợ	Platform governance
Cognitive load	—	Tải nhận thức cần để hiểu và sử dụng hệ thống	Team Topologies
Data product	—	Dữ liệu có user, outcome, contract, owner và lifecycle	Analytics, operations, AI
Data contract	—	Cam kết về schema, semantics, quality và thay đổi dữ liệu	Data integration
Semantics	—	Ý nghĩa nghiệp vụ của field hoặc metric	Data quality
Grain	—	Đơn vị quan sát của record hoặc metric	Data modeling
Data lineage	—	Dấu vết từ nguồn qua biến đổi tới consumer	Impact analysis
Data quality	—	Mức dữ liệu phù hợp với use case	Completeness, accuracy, timeliness
Data ownership	—	Quyền và trách nhiệm quyết định về dữ liệu	Governance
Privacy	—	Bảo vệ quyền riêng tư trong data flow và use case	Legal và control
AI product	—	Sản phẩm dùng mô hình có hành vi xác suất	AI product management
Probabilistic behavior	—	Hành vi có thể cho output khác hoặc sai	AI risk
Evaluation set	—	Tập tình huống dùng để đánh giá AI	Model và product evaluation
Human oversight	—	Giám sát, can thiệp hoặc phê duyệt của con người	AI safety
Drift	—	Suy giảm chất lượng khi dữ liệu hoặc môi trường đổi	Model monitoring
Model lifecycle	—	Chọn, đánh giá, phát hành, giám sát, rollback và retirement	AI operations
Assist	—	AI hỗ trợ người dùng nhưng không tự quyết định cuối	Decision role
Recommend	—	AI đưa khuyến nghị cho người dùng xem xét	Decision role
Decide	—	AI đưa quyết định trong phạm vi được giao	Decision role
Act	—	AI tự thực hiện hành động	Risk cao hơn
Technical debt	—	Chi phí hoặc rủi ro tương lai do lựa chọn hiện tại	Roadmap trade-off
Total Cost of Ownership	TCO	Tổng chi phí sở hữu trong vòng đời	Build-buy-partner
Build-buy-partner	—	Tự xây, mua hoặc hợp tác	Sourcing decision
Vendor lock-in	—	Phụ thuộc khó gỡ vào nhà cung cấp	Commercial và architecture risk
Architecture Decision Record	ADR	Bản ghi bối cảnh, lựa chọn, quyết định và hậu quả kiến trúc	Governance
Service Level Indicator	SLI	Chỉ số đo hành vi dịch vụ	SRE
Service Level Objective	SLO	Mục tiêu cho SLI	Reliability planning
Error budget	—	Mức lỗi cho phép trong khoảng thời gian	Release trade-off
Adoption	—	Mức chấp nhận và sử dụng capability	Platform, API, data
Outcome	—	Thay đổi có giá trị sau hành động hoặc phát hành	Product decision
Rollout	—	Mở rộng phát hành theo phạm vi hoặc giai đoạn	Release control
Rollback	—	Đưa hệ thống về phiên bản hoặc behavior an toàn trước đó	Incident response
Fallback	—	Cơ chế thay thế khi capability chính lỗi	Reliability
Risk appetite	—	Mức rủi ro tổ chức sẵn sàng chấp nhận	Governance
Guardrail	—	Giới hạn ngăn hành vi hoặc hậu quả không chấp nhận được	Product và AI safety

Nguồn và giới hạn

Nguồn tham khảo

Team Topologies cung cấp ngôn ngữ về team boundary, cognitive load, platform team và interaction giữa các team. Nguồn này hỗ trợ suy nghĩ về ownership và flow, nhưng không quy định cơ cấu tổ chức duy nhất.

OpenAPI Specification cung cấp cách mô tả HTTP API bằng schema machine-readable. Nó hỗ trợ documentation, tooling và contract review, nhưng không thay thế quyết định về outcome, error behavior, security, support hoặc adoption.

Google Site Reliability Engineering cung cấp các khái niệm SLI, SLO và error budget để quản trị reliability theo dữ liệu. Target phải dựa trên hành vi người dùng, chi phí và risk của sản phẩm; không sao chép benchmark máy móc.

NIST AI Risk Management Framework cung cấp khung ngôn ngữ và chức năng Govern, Map, Measure, Manage cho rủi ro AI. Khung này không tự xác định nghĩa vụ pháp lý, mức risk chấp nhận được hoặc control phù hợp cho mọi ngành.

DORA research program cung cấp nghiên cứu về software delivery và operational performance. DORA metrics không phải quota cho từng team và không nên tối ưu riêng lẻ bằng cách hy sinh chất lượng hoặc user outcome.

Giới hạn áp dụng

PM không tự xác định nghĩa vụ Legal, Privacy, Security, Finance hoặc compliance. Các miền này cần chuyên gia có thẩm quyền xác nhận.

PM không tự cam kết latency, availability, throughput, retention, privacy protection hoặc model quality. Các cam kết này cần owner kỹ thuật, vận hành, Data/ML, Security và Privacy xác nhận.

Framework không thay thế bằng chứng production. Sơ đồ có thể đúng nhưng chưa chứng minh behavior. Evaluation set có thể tốt nhưng chưa chứng minh adoption. SLO có thể đạt nhưng outcome vẫn không cải thiện.

Đọc chương không tạo ra kinh nghiệm xử lý incident, migration, vendor failure, data deletion, model rollback hoặc thay đổi contract xuyên tổ chức. Người đọc chỉ nên chịu trách nhiệm trong authority đã được giao và cần escalate khi hậu quả vượt phạm vi đó.

Đường nối với chương hiện có

P5.3 — Shaping, appetite và delivery: Technical Product Decision Brief là input cho pitch; technical risk là một loại rabbit hole cần được nhận diện và giới hạn.
P5.4 — Team topology, cognitive load: System boundary và platform contract là cơ sở thiết kế Team API và ranh giới đội.
P9.2 — Executive review, portfolio governance: Reliability risk, technical debt, build-buy-partner, vendor commitment và AI risk là input cho quản trị danh mục đầu tư.

Kết luận vận hành: PM không cần tự thiết kế hệ thống. PM cần bảo đảm hệ thống được thiết kế cho outcome thật, với contract rõ, quality phù hợp, rủi ro có owner, chi phí được quản lý, authority được ghi nhận và roadmap phản ánh trade-off có chủ đích.

Boundary capability thông báo trạng thái

Sơ đồ trả lời capability thông báo thay đổi trạng thái chịu trách nhiệm tới đâu và phụ thuộc vào ai. Nó tách hệ thống tạo trạng thái gốc khỏi capability truyền thông báo cho consumer.

Boundary capability thông báo trạng thái

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

@startuml
left to right direction
skinparam shadowing false
skinparam componentStyle rectangle
skinparam defaultTextAlignment center
skinparam wrapWidth 180

actor "Consumer\n(hệ thống đối tác)" as consumer

node "Ngoài boundary capability" {
  node "Hệ thống producer\nOwner: phải ghi rõ" as producer {
    database "State gốc\nsource of truth\nOwner: producer" as state
  }
}

node "Boundary capability: thông báo\nthay đổi trạng thái" as boundary {
  component "Capability thông báo\nOwner: phải ghi rõ" as capability
  artifact "Contract\nEvent hoặc webhook; schema; error;\nidempotency; timeout; retry;\nrate limit; versioning" as contract
  artifact "Quality target\nLatency; availability;\nthroughput; failure mode" as quality
}

producer --> state : Tạo hoặc đổi\ntrạng thái
producer --> capability : Trigger thay đổi trạng thái\nCơ chế theo contract
capability --> consumer : Thông báo trạng thái\nCơ chế theo contract
capability ..> contract : Tuân theo
capability ..> quality : Đo và phản ứng
consumer ..> contract : Dùng contract

note bottom of state
State transition và source of truth
nằm ngoài boundary capability,
nếu contract không giao capability trách nhiệm này.
end note

note bottom of consumer
Nếu dùng webhook, consumer nên giả định
callback có thể lặp, trễ hoặc sai thứ tự,
trừ khi contract bảo đảm khác.
end note

note bottom of contract
Contract phải ghi owner cho flow quan trọng
và hành vi khi dữ liệu lỗi hoặc đến muộn.
end note
@enduml

Producer tạo trigger từ thay đổi trạng thái. State gốc thuộc producer, không mặc nhiên thuộc capability thông báo. Boundary hẹp giúp tránh giao capability trách nhiệm kiểm tra quyền chuyển trạng thái hoặc quản lý state khi chưa có quyết định rõ.

Contract quyết định cơ chế truyền và cam kết cho consumer. Nếu chọn webhook, consumer phải xử lý callback lặp, trễ hoặc sai thứ tự, trừ khi contract bảo đảm khác.

Owner, quality target và failure mode phải ghi cho capability cùng flow quan trọng. Chúng tạo cơ sở đo latency, availability, throughput và xử lý dependency ngoài boundary.

P5.7 — Technical Product Management cho architecture, API, platform, data và AI

Mental model

Đơn vị quyết định: capability có contract và quality target

Core

1. Technical literacy và ranh giới vai trò

2. Đọc hệ thống: boundary, component, dependency, data flow và state

System boundary

Component

Dependency

Data flow

State

Artifact: System Context and Flow Map

3. Quality attributes

Consistency

Latency

Throughput

Availability

Scalability

4. API như một sản phẩm

API contract

Backward compatibility

Pagination

Rate limit

Webhook

Developer experience

Artifact: API Product Brief

5. Platform product và internal product

6. Data product

Data contract

Data lineage

Data quality

Data ownership

Privacy

Artifact: Data Product Card

7. AI product

Use case trước model

Evaluation set

Human oversight

Drift

Latency và cost

Model lifecycle

Artifact: AI Product Evaluation Card

8. Technical debt, build-buy-partner và ADR

Technical debt

Build-buy-partner

Architecture Decision Record

9. Roadmap trade-off cho đầu tư kỹ thuật

Artifact: Technical Product Decision Brief

Applied

Tình huống mô phỏng: API trạng thái đơn hàng, dashboard và trợ lý AI

Case 1: Có nên xây event platform trước không?

Facts

Current behavior

Underlying need

Options

Decision criteria

Decision

Authority

Artifact

Consequence if wrong

Case 2: API contract cho trạng thái đơn hàng

Facts

Current behavior

Underlying need

Options

Decision criteria

Decision

Authority

Artifact

Consequence if wrong

Case 3: Data product cho Order State History

Facts

Current behavior

Underlying need

Options

Decision criteria

Decision

Authority

Artifact

Consequence if wrong

Case 3: Data product cho `Order State History`