Bài 33 — OKRs cho Product Teams — PSPO II Advanced Product Ownership

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là Product Owner của một đội đang chạy nước rút Sprint nối Sprint. Mọi người bận rộn, velocity ổn định, demo Sprint Review nào cũng có cái để khoe. Nhưng đến cuối quý, khi sếp hỏi "Sản phẩm của em năm nay tạo ra giá trị gì cho công ty?", bạn lúng túng. Bạn kể ra được 47 tính năng đã ship, nhưng không trả lời được câu hỏi quan trọng nhất: những thứ đó có thực sự dịch chuyển kim chỉ nam kinh doanh hay không?

Đây chính là khoảng trống mà OKRs (Objectives and Key Results) ra đời để lấp đầy. Ở cấp độ PSPO II, bạn không còn được đánh giá bằng việc "đội chạy Scrum đúng quy trình" nữa. Bạn được đánh giá bằng outcome — kết quả thực sự cho khách hàng và doanh nghiệp. OKRs là công cụ ngôn ngữ chung giúp bạn dịch chiến lược sản phẩm thành những mục tiêu đo đếm được, gắn kết đội phát triển với mục tiêu công ty, và quan trọng nhất, giúp bạn nói "không" với những thứ không quan trọng một cách có lý lẽ.

Trong khóa học này, bạn đã học về Evidence-Based Management và Product Goal. OKRs là mảnh ghép giúp bạn vận hành những khái niệm đó theo nhịp quý (quarterly cadence), biến triết lý đo lường giá trị thành một thói quen điều hành cụ thể của đội. Bài học này tập trung riêng vào cách một Product Team thiết kế, vận hành và tránh bẫy khi dùng OKRs — không lan sang OKR cấp công ty hay phân biệt outcome/output (đã có bài riêng).

Khái niệm cốt lõi

OKRs là gì

OKRs gồm hai thành phần:

Objective (Mục tiêu) — một câu mô tả định tính (qualitative), mang tính truyền cảm hứng, trả lời câu hỏi "Chúng ta muốn đạt được điều gì?". Objective tốt thường không có con số, nó vẽ ra một bức tranh đáng để phấn đấu. Ví dụ: "Biến trải nghiệm thanh toán thành lý do khách hàng quay lại".
Key Results (Kết quả then chốt) — thường 3 đến 5 kết quả đo lường được (measurable), trả lời câu hỏi "Làm sao chúng ta biết mình đã đạt được Objective?". Key Result luôn có con số, có baseline (điểm xuất phát) và target (đích đến). Ví dụ: "Tỷ lệ thanh toán thành công tăng từ 82% lên 92%".

Cách dễ nhớ nhất: Objective là điểm đến trên bản đồ; Key Results là những cột mốc trên đường đi cho bạn biết bạn đang tiến gần đích hay đi lạc.

Key Result đo outcome, không đo công việc

Đây là phần khó nhất và cũng quan trọng nhất với Product Owner. Một Key Result đúng phải đo kết quả (outcome), không đo việc đã làm (output) hay hoạt động (activity).

So sánh:

Sai (đo output): "Ra mắt tính năng đăng nhập bằng sinh trắc học". → Đây chỉ là một dòng trong Backlog. Ship xong không có nghĩa là tạo ra giá trị.
Đúng (đo outcome): "Tỷ lệ đăng nhập thành công ngay lần đầu tăng từ 70% lên 88%". → Đây mới là thứ khách hàng cảm nhận được.

Lý do triết học: nếu Key Result của bạn là "ship tính năng X", bạn đã commit kết quả trước khi học được điều gì. Còn nếu Key Result là một chỉ số outcome, bạn được tự do thử nhiều giải pháp khác nhau để đạt nó — đúng tinh thần empirical của Scrum. Đội phát triển trở thành đội giải quyết vấn đề, không phải nhà máy sản xuất tính năng theo đơn đặt hàng.

Aspirational vs Committed — hai loại OKR

Google phân biệt hai loại, và PO cần hiểu rõ để đặt kỳ vọng đúng:

Committed OKR — cam kết phải đạt 100%, thường là những thứ vận hành sống còn (ví dụ uptime, tuân thủ pháp lý).
Aspirational / Stretch OKR — đặt mục tiêu cao đến mức đạt 60–70% đã là xuất sắc. Nếu quý nào bạn cũng đạt 100% OKR, đó là dấu hiệu bạn đặt mục tiêu quá an toàn (sandbagging).

Với Product Team, phần lớn OKR nên là aspirational. Điểm số 0.7 không phải là thất bại — nó là tín hiệu bạn đã dám với tới điều khó.

Mối quan hệ với Product Goal và Sprint

OKRs vận hành theo quý (thường 3 tháng), nằm giữa Product Vision (dài hạn) và Sprint Goal (ngắn hạn). Một cách sắp xếp lành mạnh:

Product Vision → định hướng nhiều năm.
Product Goal → mục tiêu trung hạn của sản phẩm (theo Scrum Guide).
OKR quý → cụ thể hóa Product Goal thành kết quả đo được trong 3 tháng.
Sprint Goal → từng bước đóng góp vào Key Results.

Lưu ý quan trọng: OKR không thay thế Product Goal hay Sprint Goal. Nó là lớp đo lường outcome bổ trợ. Đừng biến Sprint Backlog thành danh sách "task để tick OKR".

Tình huống thực tế

Ví dụ 1 — Tiki và bài toán giỏ hàng bị bỏ rơi

Giả định một đội sản phẩm tại sàn thương mại điện tử như Tiki phụ trách luồng checkout. Quý trước họ ship rất nhiều: gợi ý sản phẩm, đổi màu nút, thêm phương thức thanh toán. Velocity đẹp, nhưng tỷ lệ bỏ giỏ hàng (cart abandonment) vẫn 68%.

PO ngồi lại cùng đội và đặt OKR quý:

Objective: "Khiến việc hoàn tất đơn hàng trở nên dễ dàng đến mức khách hàng không có lý do để bỏ cuộc."
KR1: Giảm tỷ lệ bỏ giỏ hàng từ 68% xuống 55%.
KR2: Giảm thời gian trung bình từ giỏ hàng đến xác nhận đơn từ 4 phút 20 giây xuống 2 phút 30 giây.
KR3: Tăng tỷ lệ thanh toán thành công ngay lần đầu từ 79% lên 90%.

Điều thú vị xảy ra: vì Key Results đo outcome chứ không phải "ship tính năng A", đội được tự do điều tra. Họ phát hiện qua phân tích dữ liệu rằng phần lớn người bỏ giỏ vì bị bắt tạo tài khoản trước khi thanh toán. Giải pháp không phải là tính năng hào nhoáng nào cả — chỉ là cho phép "guest checkout". Cuối quý: tỷ lệ bỏ giỏ còn 57% (đạt 0.85 trên KR1).

Bài học: OKR đặt đúng giải phóng đội khỏi việc "ship cho có". Khi mục tiêu là con số outcome, đôi khi giải pháp tốt nhất lại là thứ đơn giản nhất, và bạn chỉ tìm ra nó khi không bị khóa cứng vào một output định trước.

Ví dụ 2 — Một startup SaaS B2B ở TP.HCM đặt OKR quá tham vọng

Một startup phần mềm quản lý nhà hàng (giả định tên KitchenOS) có 400 khách hàng trả phí. PO mới về, hào hứng áp OKR và đặt:

Objective: "Trở thành nền tảng không thể thiếu của mọi chủ nhà hàng."
KR1: Tăng số khách hàng trả phí từ 400 lên 2.000.
KR2: Tăng tỷ lệ giữ chân (retention) từ 80% lên 95%.
KR3: Ra mắt 6 module mới.

Cuối quý, đội cháy sạch năng lượng, đạt 600 khách (0.2 trên KR1), retention nhích lên 83%, và chỉ ra mắt được 2 module. Cả đội nản, cảm thấy thất bại dù thực ra đã làm việc rất chăm chỉ.

Có ba lỗi ở đây. Thứ nhất, KR1 đặt mục tiêu x5 trong một quý — không phải stretch, mà là ảo tưởng, làm mất động lực thay vì tạo động lực. Thứ hai, KR3 "ra mắt 6 module" là output trá hình thành Key Result — nó đo việc làm, không đo giá trị. Thứ ba, ba Key Result kéo đội theo ba hướng khác nhau (tăng trưởng, giữ chân, mở rộng tính năng) khiến không có trọng tâm.

Quý sau PO sửa lại: chỉ giữ một Objective về retention, với KR đo outcome như "Tăng tỷ lệ nhà hàng dùng tính năng cốt lõi mỗi tuần (weekly active) từ 45% lên 65%". Đội tập trung, đạt 0.75, và tinh thần phục hồi.

Bài học: Stretch khác với phi thực tế. Và đừng lén nhét output ("ra mắt N tính năng") vào ô Key Result — đó là cái bẫy phổ biến nhất của PO mới dùng OKR.

Ví dụ 3 — Grab và sự liên kết (alignment) giữa nhiều đội

Ở quy mô lớn như Grab, một Objective cấp công ty kiểu "Tăng tần suất sử dụng của người dùng đa dịch vụ" cần nhiều Product Team cùng góp sức. Đội GrabFood, đội GrabMart và đội Payments mỗi đội có OKR riêng nhưng cùng đóng góp lên một Objective chung.

Objective công ty: "Khách hàng dùng Grab cho nhiều nhu cầu hơn trong ngày."
OKR đội Payments: KR "Tăng tỷ lệ giao dịch dùng GrabPay từ 40% lên 55%".
OKR đội GrabFood: KR "Tăng tỷ lệ khách đặt món lần thứ hai trong tháng từ 30% lên 42%".

Điểm mấu chốt PO cần thấy: OKR của đội không phải do cấp trên áp xuống nguyên văn (top-down cứng nhắc), cũng không phải đội tự nghĩ ra trong chân không (bottom-up rời rạc). Nó là kết quả của một cuộc đối thoại hai chiều — đội đề xuất KR mà họ tin có thể dịch chuyển, lãnh đạo xác nhận nó phục vụ Objective chung. Đây là alignment thực sự, không phải kiểm soát.

Bài học: OKR ở scale là công cụ tạo liên kết theo chiều dọc (đội ↔ công ty) và chiều ngang (đội ↔ đội), miễn là quá trình thiết lập có đối thoại chứ không phải áp đặt.

Hướng dẫn từng bước

Đây là quy trình thực dụng để một Product Team thiết lập OKR cho một quý:

Bắt đầu từ chiến lược, không từ tính năng. Trước khi viết OKR, xem lại Product Goal và Product Vision. Hỏi: quý này đâu là một bước tiến quan trọng nhất hướng tới đó? OKR phải phục vụ chiến lược, không phải hợp thức hóa Backlog có sẵn.

Viết Objective trước, định tính và truyền cảm hứng. Một Objective tốt làm cả đội muốn thức dậy đi làm. Tránh con số ở bước này. Giới hạn 1–2 Objective mỗi đội mỗi quý — nhiều hơn là mất tập trung.

Đặt 3–5 Key Results đo outcome. Mỗi KR phải có dạng "Đưa chỉ số X từ [baseline] lên [target]". Nếu bạn không biết baseline, đó là tín hiệu bạn chưa đo lường đủ — hãy thêm việc thiết lập đo lường vào Sprint đầu.

Kiểm tra "phép thử lười biếng". Với mỗi KR, tự hỏi: "Liệu có thể đạt KR này mà không thực sự tạo ra giá trị cho khách hàng không?". Nếu câu trả lời là có (ví dụ KR là "ship tính năng"), viết lại.

Cân chỉnh độ tham vọng. Đặt mục tiêu sao cho đạt 70% là một thành công đáng tự hào. Tránh cả hai thái cực: an toàn quá (luôn 100%) và ảo tưởng (x5 trong một quý).

Đối thoại để liên kết. Chia sẻ OKR với các đội liên quan và lãnh đạo. Kiểm tra: KR của bạn có phục vụ Objective chung không? Có đội nào đang đặt KR trùng lặp hoặc mâu thuẫn không?

Theo dõi nhịp tuần (weekly check-in). Mỗi tuần cập nhật điểm tiến độ (confidence score 0–1) cho từng KR. Đây không phải họp báo cáo thành tích, mà là buổi để phát hiện sớm KR nào đang chệch hướng và điều chỉnh chiến thuật.

Đóng quý bằng review và retro. Cuối quý chấm điểm trung thực, hỏi "Chúng ta học được gì?" thay vì "Ai có lỗi?". OKR là công cụ học hỏi, không phải công cụ trừng phạt.

Lỗi thường gặp & mẹo

Lỗi 1 — Biến OKR thành danh sách công việc. Triệu chứng: Key Results của bạn toàn động từ "ship", "ra mắt", "xây dựng", "tích hợp". Mẹo: ép mỗi KR phải có một danh từ chỉ chỉ số (tỷ lệ, thời gian, số lượng người dùng) kèm hướng thay đổi.

Lỗi 2 — Quá nhiều OKR. Một đội ôm 5 Objective với 20 Key Results sẽ không tập trung được vào gì. Mẹo: một Product Team nên có tối đa 1–2 Objective mỗi quý. OKR là về việc chọn cái gì không làm.

Lỗi 3 — Gắn lương thưởng trực tiếp vào điểm OKR. Đây là lỗi giết chết OKR nhanh nhất. Khi tiền gắn vào điểm số, mọi người sẽ đặt mục tiêu thấp để dễ đạt (sandbagging), và sự trung thực biến mất. Mẹo: tách bạch OKR (công cụ định hướng, được phép thất bại) khỏi đánh giá hiệu suất cá nhân.

Lỗi 4 — Đặt rồi quên. Viết OKR đầu quý, treo lên tường, ba tháng sau mới nhìn lại. Mẹo: weekly check-in 15 phút là tối thiểu. OKR phải sống trong nhịp làm việc hàng tuần.

Lỗi 5 — Sao chép OKR công ty xuống đội nguyên văn. Nếu Objective của đội y hệt của CEO, bạn đang làm cascade máy móc. Mẹo: đội nên dịch Objective cấp trên thành KR cụ thể của riêng phạm vi sản phẩm mình.

Mẹo vàng cho PO: Dùng OKR như một "tấm khiên" để từ chối yêu cầu lạc đề. Khi một stakeholder đẩy một tính năng không phục vụ KR nào của quý, bạn có cơ sở khách quan để nói "Cái này không nằm trong trọng tâm quý này, ta để vào Next nhé" — thay vì tranh cãi cảm tính.

Bài tập thực hành

Chẩn đoán KR sai. Lấy ba dòng sau và viết lại thành Key Result đo outcome: (a) "Ra mắt ứng dụng mobile", (b) "Hoàn thành tích hợp cổng thanh toán VNPay", (c) "Tổ chức 5 buổi phỏng vấn khách hàng". Với mỗi cái, hãy chỉ ra outcome thực sự mà công việc đó nhắm tới.

Tự viết một bộ OKR. Chọn một sản phẩm bạn đang làm (hoặc một app bạn dùng hàng ngày như một ngân hàng số Việt Nam). Viết 1 Objective định tính + 3 Key Results đo outcome có baseline và target giả định hợp lý. Áp "phép thử lười biếng" cho từng KR.

Phân tích độ tham vọng. Nhìn lại bộ OKR vừa viết. Với mỗi KR, tự đánh giá: nếu đội làm việc cật lực một quý, xác suất đạt 100% là bao nhiêu? Điều chỉnh target sao cho xác suất đạt trọn vẹn rơi vào khoảng 50–70% (vùng stretch lành mạnh).

Thiết kế nhịp check-in. Phác thảo agenda cho một buổi weekly OKR check-in 15 phút cho đội bạn: ai nói gì, cập nhật cái gì, và quyết định gì được đưa ra. Mục tiêu là buổi họp tạo ra hành động, không phải báo cáo.

Tóm tắt

OKRs là công cụ giúp Product Owner ở cấp PSPO II dịch chiến lược thành kết quả đo được theo nhịp quý. Objective là mục tiêu định tính truyền cảm hứng; Key Results là 3–5 kết quả đo lường được chứng minh bạn đã đạt Objective. Nguyên tắc sống còn: Key Result phải đo outcome (giá trị khách hàng cảm nhận), không đo output (tính năng đã ship).

Hãy đặt tối đa 1–2 Objective mỗi quý để giữ trọng tâm, đặt mục tiêu đủ tham vọng để 70% là thành công, và quan trọng nhất — đừng gắn OKR vào lương thưởng, nếu không sự trung thực sẽ biến mất. OKR không thay thế Product Goal hay Sprint Goal; nó là lớp đo lường outcome bổ trợ, sống trong nhịp check-in hàng tuần.

Ba ví dụ về Tiki, KitchenOS và Grab cho thấy: OKR đặt đúng giải phóng đội khỏi việc "ship cho có", OKR đặt sai (output trá hình, tham vọng ảo) làm đội kiệt sức và mất tinh thần, còn OKR ở quy mô lớn là công cụ liên kết hai chiều giữa đội và công ty. Với tư cách PO, hãy dùng OKR như chiếc la bàn outcome và tấm khiên để bảo vệ trọng tâm của đội mình.