Mở đầu — vì sao bài này quan trọng
Bạn đã từng dự một buổi họp đầu quý, nơi sếp tổng đứng lên hô vang "Năm nay chúng ta phải tăng trưởng mạnh, phải làm khách hàng hài lòng hơn, phải dẫn đầu thị trường" — rồi ba tháng sau không ai biết chính xác mình đã đạt được gì? Đó chính là khoảng trống mà OKR sinh ra để lấp đầy. Và với một Product Owner, khoảng trống này còn nguy hiểm hơn nhiều người tưởng.
Là PO, bạn ngồi ở điểm giao nhau giữa hai thế giới. Một bên là chiến lược công ty — những con số doanh thu, thị phần, tham vọng của ban lãnh đạo. Một bên là team phát triển — những User Story, Sprint, và đống công việc kỹ thuật hằng ngày. Nếu bạn không có một cơ chế để "dịch" tham vọng cấp công ty thành mục tiêu cụ thể cho sản phẩm, bạn sẽ rơi vào một trong hai cái bẫy kinh điển: hoặc team của bạn cắm đầu làm ra rất nhiều tính năng nhưng không tính năng nào di chuyển kim đồng hồ kinh doanh, hoặc bạn liên tục bị stakeholder chất vấn "việc team đang làm thì liên quan gì đến mục tiêu của công ty?".
OKR (Objectives and Key Results) là khung công cụ giúp bạn trả lời câu hỏi đó một cách rõ ràng, đo lường được và có thể bảo vệ trước bất kỳ ai. Quan trọng hơn, OKR không phải là công cụ quản lý nhân sự để chấm điểm bạn — nó là công cụ tạo sự liên kết (alignment) giữa Product Goal mà bạn theo đuổi với chiến lược cấp trên. Bài học này tập trung đúng vào điều đó: làm sao một PO sử dụng OKR để gắn kết công việc của team với mục tiêu lớn, mà không biến nó thành một bài tập điền vào ô trống vô hồn.
Khái niệm cốt lõi
OKR gồm những gì
OKR có cấu trúc rất đơn giản, và chính sự đơn giản đó là sức mạnh của nó.
Objective (Mục tiêu) là phần định tính, mang tính truyền cảm hứng. Nó trả lời câu hỏi "Chúng ta muốn đạt được điều gì?". Một Objective tốt phải ngắn gọn, dễ nhớ, đủ tham vọng để khiến người ta thấy hứng khởi, và quan trọng nhất là không chứa con số. Ví dụ: "Trở thành lựa chọn đầu tiên của người Việt khi muốn mua sách online". Bạn đọc lên thấy có cảm xúc, thấy có hướng đi, nhưng chưa biết đo bằng gì — đó đúng là vai trò của Objective.
Key Results (Kết quả then chốt) là phần định lượng. Mỗi Objective thường đi kèm 3–5 Key Results, mỗi cái là một con số đo được, cho phép bạn biết chắc chắn mình đã đạt mục tiêu hay chưa. Key Result không mô tả việc bạn làm gì, mà mô tả kết quả bạn tạo ra. Đây là điểm cực kỳ nhiều PO nhầm lẫn, tôi sẽ quay lại sâu hơn ở phần lỗi thường gặp.
Một cách diễn đạt dễ nhớ: Objective là điểm đến trên bản đồ, Key Results là những cột mốc giúp bạn biết mình đang đi đúng đường và sắp tới nơi.
Outcome chứ không phải Output
Linh hồn của OKR nằm ở chỗ nó buộc bạn đo bằng outcome (kết quả tác động) thay vì output (sản phẩm đầu ra). "Ra mắt tính năng thanh toán bằng ví điện tử" là output — bạn làm xong là xong, nhưng nó chưa nói gì về giá trị. "Tăng tỷ lệ đơn hàng thanh toán thành công từ 78% lên 90%" là outcome — nó đo điều thực sự quan trọng với business. Một PO trưởng thành luôn viết Key Result theo ngôn ngữ outcome, vì đó là cách duy nhất để chứng minh team tạo ra giá trị thật chứ không chỉ bận rộn.
OKR liên kết với Product Goal như thế nào
Trong Scrum, bạn đã quen với Product Goal — đích đến dài hạn của sản phẩm. OKR không thay thế Product Goal; nó bổ trợ. Hãy hình dung một hệ thống ba tầng. Tầng trên cùng là OKR công ty (company-level), do ban lãnh đạo đặt ra. Tầng giữa là OKR sản phẩm/team của bạn, được rút ra và đóng góp vào OKR công ty. Product Goal của bạn thường chính là hiện thân của Objective ở tầng sản phẩm, còn Key Results là thước đo để biết Product Goal có đang tiến triển hay không.
Điều then chốt cần khắc cốt ghi tâm: alignment không có nghĩa là cascade máy móc. Không phải cứ lấy OKR công ty rồi chia nhỏ xuống từng người. Cách làm đúng là mỗi Key Result của công ty trở thành một Objective mà team bạn có thể đóng góp, và team tự đề xuất Key Results phù hợp với năng lực, ngữ cảnh sản phẩm của mình. Đây gọi là alignment hai chiều: vừa hướng xuống (chiến lược từ trên) vừa hướng lên (cam kết và đề xuất từ team).
Stretch goal và cách chấm điểm
OKR thường được đặt ở mức tham vọng. Theo triết lý của Google — nơi phổ biến OKR rộng rãi — bạn nên đặt mục tiêu sao cho đạt khoảng 0.7 trên thang 1.0 là tốt. Nếu lúc nào cũng đạt 1.0, nghĩa là bạn đặt mục tiêu quá an toàn. Tuy nhiên cần phân biệt: có loại OKR cam kết (committed — phải đạt 1.0, như tuân thủ pháp lý) và OKR khát vọng (aspirational — đạt 0.7 đã là xuất sắc). PO cần biết mình đang chơi loại nào để đặt kỳ vọng cho đúng với stakeholder.
Tình huống thực tế
Ví dụ 1 — PO mảng Sách của Tiki
Hãy bắt đầu bằng ví dụ trong dàn ý gốc và đẩy nó đi xa hơn. Lan là PO phụ trách mảng Tiki Books (sách). Đầu quý, OKR cấp công ty của Tiki có một Key Result là "Tăng tổng GMV (tổng giá trị giao dịch) lên 20% so với quý trước". Đây là con số khổng lồ ở tầng công ty, và Lan không thể một mình gánh nó. Nhưng cô có thể đóng góp một phần.
Lan ngồi với team và Product Goal hiện tại — "Biến Tiki thành nơi người yêu sách quay lại mỗi tháng" — để dựng OKR cấp sản phẩm:
Objective: Trở thành điểm đến quen thuộc của người đọc sách tại Việt Nam.
Key Results:
- KR1: Tăng tỷ lệ khách mua sách quay lại trong vòng 30 ngày từ 22% lên 35%.
- KR2: Tăng số đầu sách mỗi đơn hàng trung bình từ 1.4 lên 2.0.
- KR3: Giảm tỷ lệ hủy đơn sách do hết hàng từ 9% xuống dưới 4%.
Bài học rút ra: PO giỏi không nhận nguyên con số khổng lồ của công ty rồi hoảng loạn. Họ tách ra phần mà sản phẩm của mình có đòn bẩy để tác động, rồi biến nó thành Key Results cụ thể, đo được — đó chính là nghệ thuật của alignment.
Ví dụ 2 — Startup fintech và cái bẫy đo bằng số tính năng
Minh là PO tại một startup fintech ở TP.HCM làm app quản lý chi tiêu cá nhân. Quý trước, OKR của team Minh trông như thế này:
Objective: Cải thiện app. Key Results: Ra mắt 5 tính năng mới; sửa 40 bug; release 6 lần.
Cuối quý, team đạt đủ mọi con số, ăn mừng tưng bừng. Nhưng khi CEO hỏi "Người dùng có dùng app nhiều hơn không? Doanh thu gói premium có tăng không?" thì cả phòng im lặng. Số người dùng hoạt động hằng ngày (DAU) thậm chí còn giảm nhẹ. Họ đã hoàn thành OKR mà công ty không tiến lên một bước nào.
Sang quý sau, được mentor góp ý, Minh viết lại:
Objective: Giúp người dùng kiểm soát tài chính tốt đến mức họ không muốn rời app. Key Results:
- KR1: Tăng tỷ lệ người dùng quay lại sau 7 ngày (D7 retention) từ 18% lên 30%.
- KR2: Tăng số người liên kết tài khoản ngân hàng thành công từ 12% lên 25% số người đăng ký.
- KR3: Tăng tỷ lệ chuyển đổi lên gói premium từ 1.5% lên 3%.
Bài học rút ra: Một OKR toàn output là OKR vô dụng, thậm chí nguy hiểm vì nó tạo ảo giác thành công. PO phải dũng cảm viết KR bằng outcome ngay cả khi nó khó đạt hơn — vì đó mới là điều stakeholder thực sự quan tâm.
Ví dụ 3 — Khi alignment ngang hàng quan trọng không kém
Tại một công ty SaaS B2B ở Singapore, Hương là PO của module báo cáo (reporting). OKR công ty quý đó là "Tăng tỷ lệ gia hạn hợp đồng (renewal rate) từ 82% lên 90%". Ban đầu Hương định viết KR riêng cho module của mình, nhưng cô nhận ra một vấn đề: khách hàng không gia hạn không phải vì báo cáo kém, mà vì quá trình onboarding ban đầu quá rối, họ chưa kịp thấy giá trị đã nản.
Thay vì làm OKR trong "ốc đảo" của mình, Hương ngồi lại với PO của team Onboarding. Hai người cùng thống nhất một Objective chung và chia Key Results: team Onboarding lo KR về "tỷ lệ khách hoàn tất setup trong 7 ngày", còn team của Hương lo KR "tỷ lệ khách mở báo cáo ít nhất 3 lần trong tháng đầu" — vì dữ liệu cho thấy khách dùng báo cáo sớm thì gắn bó hơn nhiều.
Kết quả, renewal rate quý đó lên 88%. Không hoàn hảo, nhưng tiến bộ lớn — và điều đẹp nhất là không có chuyện hai team đổ lỗi cho nhau.
Bài học rút ra: Alignment không chỉ là chiều dọc (lên ban lãnh đạo). Nó còn là chiều ngang — giữa các team cùng đóng góp vào một mục tiêu. PO cần chủ động tìm các điểm phụ thuộc và phối hợp OKR với team khác, thay vì tối ưu cục bộ cho riêng module mình.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay khi đến kỳ đặt OKR (thường mỗi quý):
Bước 1 — Đọc và thấu hiểu OKR cấp trên. Trước khi viết gì, hãy lấy OKR công ty hoặc OKR của bộ phận sản phẩm. Đọc kỹ để hiểu vì sao lãnh đạo chọn những mục tiêu đó. Nếu không rõ, hãy hỏi. Bạn không thể align với thứ bạn không hiểu.
Bước 2 — Xác định đòn bẩy của sản phẩm bạn. Tự hỏi: "Trong các Key Results của công ty, sản phẩm của tôi có thể tác động trực tiếp đến cái nào? Bằng cơ chế gì?". Đây là bước tư duy quan trọng nhất, đừng vội.
Bước 3 — Viết Objective truyền cảm hứng. Một câu, định tính, không có số, đủ khiến team thấy đáng làm. Đọc lên mà thấy nhàm chán thì viết lại.
Bước 4 — Đề xuất 3–5 Key Results bằng outcome. Mỗi KR có giá trị khởi điểm (baseline), giá trị mục tiêu, và mốc thời gian. Công thức hữu ích: "Tăng/Giảm [chỉ số] từ [X] đến [Y] vào [thời điểm]". Nếu một KR không có baseline, hãy đo baseline trước.
Bước 5 — Kiểm tra ngược. Với mỗi KR, hỏi: "Nếu đạt KR này mà Objective vẫn không thành thì sao?". Nếu câu trả lời là "vẫn có thể", thì KR đó chưa đủ tốt — bạn đang đo nhầm thứ.
Bước 6 — Đồng bộ với team và các team liên quan. Mang OKR nháp ra cho Developers và các PO khác. Team phải thấy nó khả thi và đồng thuận, nếu không OKR chỉ là mong muốn của riêng bạn.
Bước 7 — Kết nối OKR với Product Backlog. Đây là lúc OKR trở nên sống động. Mỗi item lớn trong Backlog nên truy ngược được về một Key Result. Khi sắp xếp thứ tự Backlog, KR là một trong những la bàn chính.
Bước 8 — Theo dõi và cập nhật định kỳ. Đừng để OKR "ngủ đông" đến cuối quý. Mỗi 2 tuần (thường gắn với Sprint Review), cập nhật tiến độ từng KR và điều chỉnh hành động nếu một KR đang đứng yên.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến Key Results thành danh sách công việc. Đây là lỗi phổ biến nhất. "Hoàn thành tích hợp API thanh toán" không phải KR, đó là task. KR phải là kết quả. Mẹo: đọc KR của bạn và hỏi "đây là việc tôi làm hay kết quả tôi tạo ra?". Nếu là việc làm, viết lại.
Lỗi 2 — Đặt quá nhiều OKR. Một team ôm 6 Objective với 25 KR là dấu hiệu chưa biết ưu tiên. OKR là để tập trung. Mẹo: mỗi team một quý nên có tối đa 2–3 Objective. Ít mà sâu hơn nhiều mà loãng.
Lỗi 3 — Cascade máy móc từ trên xuống. Lấy OKR sếp rồi sao chép xuống mọi cấp khiến OKR mất ý nghĩa và team không có quyền sở hữu. Mẹo: để team tự đề xuất Key Results trong khuôn khổ Objective được giao. Alignment đến từ đối thoại, không từ mệnh lệnh.
Lỗi 4 — Dùng OKR để chấm KPI lương thưởng. Khi OKR gắn với thưởng, ai cũng đặt mục tiêu thấp cho dễ đạt, triệt tiêu tinh thần stretch goal. Mẹo: tách bạch OKR (định hướng, học hỏi) với đánh giá hiệu suất cá nhân.
Lỗi 5 — Đặt rồi để đó. OKR viết đầu quý, đến cuối quý mới mở ra xem là cách chắc chắn để thất bại. Mẹo: gắn việc review OKR vào nhịp sẵn có như Sprint Review để nó luôn sống.
Lỗi 6 — KR không có baseline. "Tăng retention lên 30%" mà không biết hiện tại bao nhiêu thì vô nghĩa. Mẹo: không có baseline thì việc đầu tiên của quý là đo baseline.
Bài tập thực hành
Hãy chọn sản phẩm bạn đang phụ trách (hoặc một sản phẩm bạn quen thuộc như một app gọi xe, một sàn TMĐT) và thực hiện:
- Giả lập OKR công ty. Viết ra một Objective và một Key Result cấp công ty mà bạn nghĩ lãnh đạo có thể đặt cho quý này (ví dụ về tăng trưởng doanh thu hoặc thị phần).
- Dựng OKR sản phẩm align với nó. Viết một Objective truyền cảm hứng và 3 Key Results cho sản phẩm của bạn, sao cho khi đạt được chúng sẽ đóng góp vào KR công ty ở bước 1. Bắt buộc cả 3 KR phải là outcome, mỗi cái có baseline → target.
- Kiểm tra ngược. Với từng KR, viết một câu trả lời cho câu hỏi: "Nếu đạt KR này mà Objective vẫn không thành thì sao?". Nếu phát hiện KR yếu, sửa lại.
- Nối với Backlog. Liệt kê 3 hạng mục lớn trong Product Backlog và chỉ rõ mỗi cái phục vụ Key Result nào. Nếu có hạng mục không nối được vào KR nào, hãy tự hỏi vì sao nó vẫn nằm trong Backlog.
- Tự phản biện. Đếm xem bạn có bao nhiêu Objective. Nếu nhiều hơn 3, hãy cắt xuống còn 2–3 và giải thích lý do giữ lại những cái đó.
Tóm tắt
OKR là cây cầu nối giữa tham vọng cấp công ty và công việc hằng ngày của team — và với PO, đó là công cụ để chứng minh mỗi Sprint đều phục vụ một mục tiêu lớn hơn. Hãy nhớ những điểm cốt lõi: Objective định tính và truyền cảm hứng; Key Results định lượng, 3–5 cái mỗi Objective, luôn viết bằng outcome chứ không phải output. Alignment thật sự là đối thoại hai chiều — nhận định hướng từ trên, đề xuất cam kết từ team — chứ không phải cascade máy móc, và nó còn bao gồm cả phối hợp ngang giữa các team. Đừng đặt quá nhiều, đừng gắn với thưởng phạt, đừng quên cập nhật, và luôn nối được mỗi Key Result với Product Backlog của bạn. Khi làm đúng, OKR biến bạn từ một PO chỉ "quản lý danh sách công việc" thành một PO dẫn dắt sản phẩm bằng giá trị đo lường được — và đó chính là khác biệt giữa một PO bình thường và một PO mà mọi stakeholder muốn làm việc cùng.