Mở đầu — vì sao bài này quan trọng
Nếu bạn từng đọc Scrum Guide phiên bản cũ (trước 2020), bạn sẽ không tìm thấy hai chữ "Product Goal" ở đâu cả. Đây là một trong những bổ sung quan trọng nhất của Scrum Guide 2020 — và cũng là khái niệm bị nhiều Product Owner Việt Nam hiểu sai hoặc bỏ qua nhất.
Tại sao nó quan trọng đến vậy? Bởi vì trước khi có Product Goal, rất nhiều nhóm Scrum rơi vào tình trạng mà tôi hay gọi là "chạy Sprint như chạy bộ trên máy" — đều đặn, có nhịp, nhưng không đi tới đâu cả. Mỗi Sprint hoàn thành một mớ tính năng rời rạc, demo xong rồi quên, và sau sáu tháng không ai trả lời được câu hỏi đơn giản: "Rốt cuộc chúng ta đang cố đạt được điều gì?"
Product Goal chính là câu trả lời cho khoảng trống đó. Nó là chiếc neo giữ cho mọi Sprint hướng về một đích đến chung trong trung hạn. Với vai trò Product Owner, đây không phải kiến thức "biết thì tốt" — đây là công cụ trung tâm để bạn lèo lái sản phẩm. Nếu bạn định thi PSPO hoặc làm việc trong môi trường Scrum nghiêm túc, hiểu sai Product Goal sẽ khiến bạn vừa mất điểm trong bài thi, vừa quản lý backlog một cách thiếu định hướng ngoài thực tế.
Trong bài này, chúng ta sẽ đào sâu đúng một khái niệm: Product Goal là gì, nó nằm ở đâu trong cấu trúc Scrum, và làm sao để viết một Product Goal thực sự dẫn dắt được cả nhóm.
Khái niệm cốt lõi
Product Goal là gì?
Theo Scrum Guide 2020, Product Goal mô tả trạng thái tương lai của sản phẩm — một mục tiêu mà nhóm Scrum hướng tới để lập kế hoạch. Hãy để ý cụm "trạng thái tương lai của sản phẩm" (future state of the product). Product Goal không phải là một tính năng, không phải một danh sách việc cần làm, mà là một đích đến — một bức tranh về việc sản phẩm sẽ trở thành cái gì sau một khoảng thời gian.
Về mặt thời gian, Product Goal thường mang tính trung và dài hạn — khoảng 3 đến 12 tháng. Nó dài hơn một Sprint rất nhiều, nhưng lại ngắn hơn và cụ thể hơn Tầm nhìn sản phẩm (Product Vision). Bạn có thể hình dung theo tầng bậc:
- Product Vision — tầm nhìn nhiều năm, mang tính khát vọng, gần như không bao giờ "hoàn thành".
- Product Goal — một bước trung gian cụ thể trên con đường tiến tới Vision, có thể đạt được trong 3–12 tháng.
- Sprint Goal — mục tiêu của riêng một Sprint, là một bước nhỏ tiến về phía Product Goal.
Product Goal là "commitment" của Product Backlog
Đây là điểm cốt lõi nhất và cũng dễ quên nhất. Scrum Guide 2020 giới thiệu khái niệm commitment (cam kết) gắn với từng artifact (vật phẩm) để tăng tính minh bạch và tập trung. Mỗi artifact có một commitment riêng:
- Product Backlog → commitment là Product Goal.
- Sprint Backlog → commitment là Sprint Goal.
- Increment → commitment là Definition of Done.
Quy tắc "một Product Goal tại một thời điểm"
Đây là nguyên tắc mà ghi chú gốc của bài đã nhắc tới và rất đáng nhấn mạnh: Tại một thời điểm, nhóm Scrum chỉ nên tập trung vào MỘT Product Goal.
Scrum Guide diễn đạt rằng nhóm phải hoàn thành (hoặc từ bỏ) một Product Goal trước khi nhận lấy mục tiêu tiếp theo. Logic đằng sau là gì? Tập trung. Toàn bộ triết lý Scrum xoay quanh việc tạo ra focus. Nếu một nhóm cùng lúc đuổi theo ba bốn Product Goal, họ thực chất không có mục tiêu nào cả — nỗ lực bị phân mảnh, và không artifact nào đủ rõ ràng để dẫn dắt quyết định hàng ngày.
Điều này không có nghĩa sản phẩm chỉ có đúng một Product Goal mãi mãi. Sản phẩm sống qua một chuỗi tuần tự các Product Goal: đạt được mục tiêu này, ăn mừng, rồi đặt mục tiêu kế tiếp. Giống như leo núi theo từng chặng — bạn chinh phục trạm nghỉ này xong mới nhắm tới trạm tiếp theo, chứ không cố chạm vào ba trạm cùng một lúc.
Ai sở hữu Product Goal?
Product Owner là người chịu trách nhiệm (accountable) về Product Goal, đúng như họ chịu trách nhiệm về Product Backlog. PO là người định hình, làm rõ và truyền đạt Product Goal. Tuy nhiên — và đây là sắc thái quan trọng — PO không "phát minh" Product Goal trong phòng kín. Một Product Goal tốt được hình thành từ đối thoại với stakeholder, từ dữ liệu, từ Vision, và thường được tinh chỉnh cùng cả nhóm để đảm bảo nó vừa tham vọng vừa khả thi.
Đặc tính của một Product Goal tốt
Một Product Goal viết tốt thường có những đặc điểm sau:
- Hướng về kết quả (outcome), không phải đầu ra (output). Không phải "xây xong tính năng X", mà là "đạt được sự thay đổi Y trong hành vi người dùng hoặc kết quả kinh doanh".
- Có thể đo lường được — để cả nhóm biết khi nào thì đã đạt.
- Đủ cụ thể để dẫn dắt nhưng đủ rộng để không khóa cứng giải pháp.
- Truyền cảm hứng và rõ ràng — ai đọc cũng hiểu và thấy đáng làm.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử "ChợViệt" — từ làm tính năng sang theo đuổi outcome
Giả định một startup thương mại điện tử tại TP.HCM tên ChợViệt, quy mô khoảng 40 người, hai nhóm phát triển. Trước đây, backlog của họ là một danh sách dài hơn 300 item: thêm cổng thanh toán, làm trang khuyến mãi, sửa giao diện giỏ hàng, tích hợp ví điện tử... Mỗi Sprint Review demo vài thứ, stakeholder gật gù, rồi mọi người lại quay về với một danh sách mới. Sau hai quý, doanh thu không nhúc nhích, và CEO bắt đầu hỏi những câu khó.
Vấn đề không phải nhóm lười — họ rất bận. Vấn đề là không có Product Goal. Anh PO mới về quyết định đặt một Product Goal duy nhất cho quý tới:
> "Nâng tỷ lệ khách hàng mua lần thứ hai trong vòng 30 ngày từ 12% lên 25% trước cuối Q3."
Ngay lập tức, backlog 300 item bị soi chiếu qua lăng kính này. Tính năng "đổi giao diện trang chủ" — không rõ liên quan, đẩy xuống. Tính năng "gợi ý sản phẩm dựa trên lịch sử mua", "email nhắc giỏ hàng bỏ quên", "chương trình tích điểm thân thiết" — trực tiếp phục vụ mục tiêu, kéo lên đầu. Sau 11 tuần, tỷ lệ mua lại đạt 23% — chưa chạm đích nhưng gần sát, và quan trọng hơn, lần đầu tiên cả nhóm biết rõ họ đang đánh đổi vì điều gì.
Bài học: Product Goal không tạo thêm việc. Nó giúp bạn loại bớt việc. Sức mạnh lớn nhất của nó là khả năng nói "không" với những thứ không phục vụ mục tiêu.
Ví dụ 2: App ngân hàng số — sai lầm "Product Goal" là một danh sách tính năng
Một ngân hàng số tại Hà Nội (gọi là NeoBank) ra mắt phiên bản nội bộ "Product Goal" cho quý như sau:
> "Hoàn thành: mở thẻ tín dụng online, tích hợp QR thanh toán, làm xong màn hình lịch sử giao dịch, ra mắt tính năng chia hóa đơn."
Nhìn qua thì có vẻ ổn — rõ ràng, cụ thể. Nhưng đây thực chất không phải Product Goal, mà là một danh sách output trá hình. Nó liệt kê những gì sẽ xây, chứ không nói được sản phẩm sẽ đạt trạng thái gì hay tạo ra giá trị nào. Hệ quả: nhóm "hoàn thành" cả bốn hạng mục đúng hạn, ăn mừng, nhưng tỷ lệ người dùng kích hoạt thẻ tín dụng chỉ 4%, và tính năng chia hóa đơn gần như không ai dùng. Họ đạt mục tiêu trên giấy nhưng thất bại về giá trị.
Sau khi được tư vấn, NeoBank viết lại Product Goal hướng outcome:
> "Trở thành ví chi tiêu chính của 50.000 người dùng trẻ — đo bằng việc họ thực hiện tối thiểu 8 giao dịch/tháng qua app — vào cuối Q4."
Với cách viết này, các tính năng như mở thẻ hay chia hóa đơn không còn là đích đến, mà trở thành giả thuyết về cách đạt mục tiêu. Nếu chia hóa đơn không kéo được giao dịch lên, nhóm có quyền bỏ nó giữa chừng mà không cảm thấy "thất bại" — vì đích thực sự là số giao dịch, không phải tính năng.
Bài học: Nếu Product Goal của bạn có thể viết lại thành một checklist tính năng, gần như chắc chắn bạn đang nhầm output với outcome.
Ví dụ 3: Đội nội bộ tại một công ty logistics — chuỗi Product Goal tuần tự
Một công ty logistics ở Đông Nam Á có đội phần mềm nội bộ làm hệ thống điều phối tài xế. Họ áp dụng đúng nguyên tắc một Product Goal tại một thời điểm, theo chuỗi:
- Goal 1 (Q1): "Giảm thời gian trung bình từ lúc đơn được tạo đến lúc tài xế nhận đơn xuống dưới 90 giây." → Đạt được sau 10 tuần.
- Goal 2 (Q2): "Giảm tỷ lệ đơn bị hủy do tài xế từ chối từ 18% xuống dưới 8%." → Đang theo đuổi.
Bài học: Tính tuần tự không phải sự chậm chạp, mà là sự tập trung. Một nhóm hoàn thành dứt điểm bốn Product Goal trong một năm thường tạo ra nhiều giá trị hơn nhóm đuổi theo bốn mục tiêu song song và không kết thúc cái nào.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để bạn — với vai trò Product Owner — thiết lập và sử dụng Product Goal.
Bước 1 — Bắt đầu từ Vision và bối cảnh. Trước khi viết Product Goal, hãy nhìn lên Product Vision và nhìn xuống dữ liệu hiện tại. Product Goal phải là một bước hợp lý nối giữa "chúng ta đang ở đâu" và "chúng ta muốn đến đâu trong dài hạn".
Bước 2 — Xác định outcome trung hạn, không phải tính năng. Tự hỏi: "Sau 3–12 tháng nữa, sản phẩm này khác đi như thế nào? Hành vi người dùng hay con số kinh doanh nào sẽ thay đổi?" Câu trả lời đó là phôi thai của Product Goal.
Bước 3 — Viết thành một câu rõ ràng, có thể đo. Một công thức gợi ý: "[Đạt được trạng thái/kết quả gì] — đo bằng [chỉ số cụ thể] — trước [mốc thời gian]." Tránh động từ kiểu "xây", "làm", "tích hợp" ở vị trí trung tâm; ưu tiên "đạt", "tăng", "giảm", "trở thành".
Bước 4 — Kiểm tra nguyên tắc "một mục tiêu". Đảm bảo cả nhóm chỉ đang theo đuổi một Product Goal. Nếu bạn thấy mình có hai, hãy chọn cái quan trọng hơn và xếp cái kia vào hàng chờ.
Bước 5 — Gắn Product Goal vào Product Backlog. Đặt Product Goal ở vị trí dễ thấy (đầu backlog, trên bảng nhóm). Rà soát backlog: item nào phục vụ Goal thì giữ và sắp xếp lên trên; item nào không liên quan thì đánh dấu để xem xét sau.
Bước 6 — Dùng Product Goal để dẫn dắt mọi sự kiện Scrum. Trong Sprint Planning, mỗi Sprint Goal nên là một bước tiến về Product Goal. Trong Sprint Review, hãy luôn kiểm tra "chúng ta tiến gần Product Goal đến đâu rồi?".
Bước 7 — Theo dõi tiến độ và quyết định. Khi Product Goal đạt được, hãy ăn mừng và chính thức "đóng" nó trước khi mở mục tiêu mới. Nếu dữ liệu cho thấy Goal không còn phù hợp, bạn hoàn toàn có quyền từ bỏ nó — đó là quyết định hợp lệ và đôi khi rất dũng cảm.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Product Goal với Product Vision. Nhiều PO viết Product Goal kiểu "trở thành nền tảng số một Việt Nam". Đó là Vision, quá rộng và không có mốc hoàn thành. Product Goal phải đạt được trong 3–12 tháng và phải biết được khi nào thì xong.
Lỗi 2 — Biến Product Goal thành danh sách tính năng (output). Như ví dụ NeoBank. Mẹo kiểm tra: nếu bạn có thể tick checkbox "xong" cho từng phần mà người dùng chẳng được lợi gì hơn, đó là output, không phải Goal.
Lỗi 3 — Đặt nhiều Product Goal cùng lúc. Phá vỡ sự tập trung. Mẹo: dán đúng một câu Product Goal lên đầu bảng nhóm. Nếu ai đó đề xuất việc không phục vụ câu đó, đặt câu hỏi thẳng thắn.
Lỗi 4 — Viết Product Goal rồi để đó. Một Product Goal không được nhắc tới trong các sự kiện Scrum thì cũng như không tồn tại. Mẹo: mở đầu mỗi Sprint Planning bằng việc đọc to Product Goal và hỏi "Sprint này đưa chúng ta gần đích thêm bao nhiêu?".
Lỗi 5 — Product Goal không đo được. "Cải thiện trải nghiệm người dùng" nghe hay nhưng vô dụng vì không ai biết khi nào đạt. Luôn gắn một chỉ số.
Mẹo bổ sung: Đừng sợ đặt Product Goal hơi tham vọng. Một mục tiêu quá an toàn không tạo ra sự tập trung hay động lực. Nhưng cũng đừng đặt nó viển vông tới mức cả nhóm biết ngay là bất khả thi — khi đó nó mất hết sức dẫn dắt.
Bài tập thực hành
Bài 1 — Phân loại. Với mỗi phát biểu dưới đây, xác định nó là Vision, Product Goal, Sprint Goal hay chỉ là một output (tính năng): a) "Tích hợp xong cổng thanh toán VNPay." b) "Tăng tỷ lệ thanh toán thành công ở bước checkout từ 70% lên 90% trước cuối tháng 9." c) "Trở thành ứng dụng tài chính được tin dùng nhất của người Việt trẻ." d) "Sprint này hoàn thiện luồng đăng nhập bằng sinh trắc học để chuẩn bị cho mục tiêu giảm tỷ lệ bỏ cuộc khi mở tài khoản."
Bài 2 — Viết lại. Lấy "Product Goal" sai sau đây và viết lại theo hướng outcome, có thể đo, có mốc thời gian: "Quý này làm xong tính năng chat hỗ trợ, thông báo đẩy và trang câu hỏi thường gặp."
Bài 3 — Áp dụng vào sản phẩm của bạn. Hãy nghĩ về một sản phẩm bạn đang làm (hoặc một app bạn dùng hàng ngày). Viết một Product Goal duy nhất cho 6 tháng tới theo công thức "[kết quả] — đo bằng [chỉ số] — trước [mốc thời gian]." Sau đó liệt kê 3 item trong backlog mà bạn sẽ ưu tiên, và 2 item bạn sẽ tạm gác lại vì không phục vụ Goal đó.
Gợi ý đáp án Bài 1: a) output; b) Product Goal; c) Vision; d) Sprint Goal.
Tóm tắt
Product Goal là khái niệm được Scrum Guide 2020 bổ sung để lấp khoảng trống định hướng trung hạn cho nhóm Scrum. Những điều cốt lõi cần ghi nhớ:
- Product Goal mô tả trạng thái tương lai của sản phẩm, là một đích đến cụ thể trong khoảng 3–12 tháng, nằm giữa Vision (dài hạn) và Sprint Goal (một Sprint).
- Nó là commitment của Product Backlog — toàn bộ backlog tồn tại để phục vụ việc đạt Product Goal, và đây là tiêu chí lọc mạnh để quyết định item nào quan trọng.
- Nguyên tắc vàng: một Product Goal tại một thời điểm. Sản phẩm sống qua một chuỗi Product Goal tuần tự, hoàn thành (hoặc từ bỏ) cái này rồi mới nhận cái tiếp theo.
- Product Goal tốt hướng về outcome, đo được, đủ rõ để dẫn dắt — không phải một danh sách tính năng trá hình.
- Product Owner chịu trách nhiệm về Product Goal, nhưng nên hình thành nó qua đối thoại với stakeholder và cả nhóm, rồi dùng nó để dẫn dắt mọi sự kiện Scrum.