Mở đầu — vì sao bài này quan trọng
Nếu bạn đang ôn thi PSM I, có một khái niệm mà người ra đề rất thích "gài bẫy": Product Goal. Lý do đơn giản — đây là một khái niệm mới toanh được Scrum Guide thêm vào phiên bản 2020. Trước đó, từ 2010 đến 2017, Scrum Guide hoàn toàn không nhắc đến Product Goal. Vì vậy, nhiều người học từ tài liệu cũ, từ kinh nghiệm đi làm thực tế (nơi mọi người hay nói "roadmap", "OKR", "vision") thường trả lời sai khi gặp câu hỏi về Product Goal trong đề thi.
Trong bài này, chúng ta sẽ không nói lan man về toàn bộ Product Backlog (đó là việc của Bài 17), cũng không bàn sâu về Sprint Goal (đó là Bài 22). Chúng ta tập trung đúng một thứ: Product Goal là gì, vì sao Scrum Guide 2020 lại thêm nó, mối quan hệ commitment giữa nó và Product Backlog, và làm sao trả lời "by the book" trong phòng thi.
Hãy nhớ một câu thần chú ngay từ đầu: trong Scrum Guide 2020, mỗi Artifact có đúng một Commitment. Product Backlog → Product Goal. Sprint Backlog → Sprint Goal. Increment → Definition of Done. Product Goal chính là commitment gắn liền với Product Backlog. Nắm chắc cặp đôi này, bạn đã giải quyết được một phần lớn các câu hỏi liên quan.
Khái niệm cốt lõi
Định nghĩa "by the book"
Theo Scrum Guide 2020:
> "The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define 'what' will fulfill the Product Goal."
Dịch sát ý: Product Goal mô tả một trạng thái tương lai của sản phẩm, đóng vai trò làm mục tiêu để Scrum Team lập kế hoạch hướng tới. Có ba điểm cực kỳ quan trọng nằm trong định nghĩa này mà bạn phải khắc cốt ghi tâm:
- Product Goal là một "future state" (trạng thái tương lai) — không phải một danh sách công việc, không phải một feature, mà là một điểm đến, một bức tranh về sản phẩm khi nó đã tiến hóa tới đâu đó.
- Product Goal nằm trong Product Backlog ("The Product Goal is in the Product Backlog"). Đây là một câu thường xuất hiện trong đề thi. Nó không phải một tài liệu riêng treo trên tường, không phải một artifact thứ tư. Nó nằm bên trong Product Backlog.
- Phần còn lại của Product Backlog "emerges" (nổi lên, hình thành dần) để định nghĩa cái gì sẽ hoàn thành Product Goal. Nghĩa là Product Goal định hướng cho việc các Product Backlog Item được thêm vào, sắp xếp, tinh chỉnh.
Product Goal là Commitment của Product Backlog
Scrum Guide 2020 giới thiệu khái niệm Commitment gắn với từng Artifact. Commitment không có nghĩa là "lời hứa sẽ giao đúng hạn" (đây là một hiểu lầm chết người mà chúng ta sẽ nói ở phần lỗi thường gặp). Commitment ở đây mang nghĩa: một thứ giúp tăng tính minh bạch (transparency) và giúp đo lường sự tiến bộ (focus/progress) của Artifact đó.
- Product Backlog cam kết với Product Goal.
- Sprint Backlog cam kết với Sprint Goal.
- Increment cam kết với Definition of Done.
Vì sao empirical product management cần Product Goal?
Đây là phần "tại sao" mà bài gốc gợi ý, và cũng là phần giúp bạn hiểu sâu thay vì học vẹt.
Scrum đứng trên nền tảng empiricism (chủ nghĩa thực nghiệm) với ba trụ cột: Transparency, Inspection, Adaptation (bạn đã học ở Bài 6). Empiricism nói rằng: bạn ra quyết định dựa trên những gì đã quan sát được, rồi liên tục thanh tra và thích nghi.
Nhưng có một vấn đề: bạn không thể inspect và adapt nếu không có một mục tiêu để so sánh. Inspection là so sánh trạng thái hiện tại với một cái gì đó. Adaptation là điều chỉnh để tiến gần hơn tới một cái gì đó. "Cái gì đó" ở cấp độ sản phẩm dài hạn — chính là Product Goal.
Trước 2020, Scrum có Sprint Goal cho từng Sprint, có Definition of Done cho chất lượng, nhưng thiếu một mục tiêu định hướng ở cấp độ sản phẩm xuyên suốt nhiều Sprint. Các đội Scrum dễ rơi vào trạng thái "feature factory" — cứ làm hết PBI này đến PBI khác mà không rõ tất cả những việc đó đang dẫn sản phẩm tới đâu. Product Goal lấp đúng khoảng trống đó: nó là target dài hạn để Scrum Team plan against qua nhiều Sprint.
Một Product Goal tại một thời điểm
Scrum Guide nói rõ: "A Product Backlog reflects the Product Goal. The Scrum Team must fulfill (or abandon) one Product Goal before taking on the next."
Hai chữ quan trọng: fulfill (hoàn thành) hoặc abandon (từ bỏ). Một Scrum Team làm việc hướng tới một Product Goal tại một thời điểm. Họ không nhảy lung tung giữa nhiều Product Goal song song. Khi đã đạt được, hoặc khi nhận ra mục tiêu đó không còn hợp lý nữa và quyết định từ bỏ, họ mới lấy một Product Goal mới.
Điều này rất hay bị hỏi trong đề: "How many Product Goals can a Scrum Team work on at a time?" → One (một).
Ai chịu trách nhiệm về Product Goal?
Product Owner chịu trách nhiệm (accountable) cho việc phát triển và truyền đạt rõ ràng Product Goal — vì Product Owner accountable cho việc tối đa hóa giá trị của sản phẩm và quản trị Product Backlog hiệu quả. Tuy nhiên — và đây là điểm tinh tế — cả Scrum Team đều "plan against" Product Goal đó. Product Goal là mục tiêu chung mà mọi người hướng tới, dù trách nhiệm sở hữu thuộc về PO.
Tình huống thực tế
Ví dụ 1 — Ứng dụng gọi xe Be (Việt Nam): từ "feature factory" sang có Product Goal
Hãy hình dung một đội phát triển trong một công ty công nghệ gọi xe tại Việt Nam, tạm gọi theo bối cảnh giống Be. Trước đây, Product Backlog của họ là một danh sách dài 240 item: "thêm nút chia sẻ chuyến", "đổi màu icon", "thêm phương thức thanh toán ví X", "tối ưu màn hình chờ"... Mỗi Sprint họ làm 8–10 item, nhưng khi ban lãnh đạo hỏi "ba tháng qua sản phẩm đi tới đâu rồi?", không ai trả lời được mạch lạc.
Product Owner quyết định đặt một Product Goal rõ ràng: "Trở thành lựa chọn số 1 cho khách hàng đặt xe ở các tỉnh thành cấp 2 (Cần Thơ, Đà Nẵng, Hải Phòng) — đo bằng tỷ lệ chuyến hoàn thành đạt 95% và thời gian chờ trung bình dưới 4 phút."
Diễn giải: Ngay lập tức, Product Backlog được "lọc" lại quanh Product Goal này. Item "đổi màu icon" bị đẩy xuống đáy vì nó chẳng giúp gì cho mục tiêu mở rộng tỉnh thành. Item "tối ưu thuật toán ghép tài xế ở khu vực mật độ thấp" được kéo lên đầu. Mỗi Sprint Review, đội inspect Increment và hỏi: "Chúng ta đã tiến gần hơn tới 95% chuyến hoàn thành ở các tỉnh đó chưa?"
Bài học rút ra: Product Goal biến một danh sách công việc rời rạc thành một hành trình có hướng. Nó là cái cho phép inspection và adaptation ở cấp sản phẩm — đúng tinh thần empiricism. Và lưu ý: Product Goal này nằm trong Product Backlog, là item ở trên cùng định hướng cho mọi thứ phía dưới.
Ví dụ 2 — Startup fintech Singapore: fulfill rồi mới sang Product Goal mới
Một startup fintech ở Singapore xây ví điện tử cho người lao động nhập cư. Product Goal đầu tiên của họ: "Cho phép người dùng gửi tiền về quê (remittance) sang 5 quốc gia Đông Nam Á với phí dưới 1% và thời gian dưới 10 phút."
Họ làm việc với Product Goal này suốt 6 Sprint. Đến Sprint thứ 6, Increment đã hỗ trợ đủ 5 quốc gia, phí 0.8%, thời gian trung bình 7 phút. Product Goal đã được fulfill.
Lúc này, Product Owner mới đặt Product Goal tiếp theo: "Trở thành nơi người dùng quản lý toàn bộ thu chi hàng tháng, không chỉ gửi tiền — đo bằng tỷ lệ người dùng quay lại hàng tuần (WAU) đạt 40%."
Có một thời điểm giữa chừng, đội nhận ra một Product Goal phụ họ từng cân nhắc — "tích hợp đầu tư chứng khoán" — không còn phù hợp với thị trường nữa do quy định pháp lý thay đổi. Họ abandon nó thẳng tay thay vì cố theo đuổi.
Diễn giải và bài học: Đây minh họa chính xác nguyên tắc "fulfill or abandon one Product Goal before taking on the next". Đội không chạy hai Product Goal song song. Họ hoàn thành cái này, hoặc dứt khoát bỏ, rồi mới sang cái kế tiếp. Điều này giữ cho focus (một trong 5 Scrum Values) luôn rõ ràng.
Ví dụ 3 — Hiểu lầm "Product Goal = ngày release" tại một ngân hàng
Tại một ngân hàng lớn ở TP.HCM, một đội mới chuyển sang Scrum. Khi được hỏi Product Goal là gì, Project Manager (đã được đổi danh thành "Product Owner" trên giấy tờ) trả lời: "Product Goal của chúng tôi là go-live ứng dụng mobile banking vào ngày 30/9, đúng deadline ban giám đốc giao."
Diễn giải: Đây là một hiểu lầm phổ biến và sai. "Go-live ngày 30/9" là một deadline / mốc thời gian giao hàng, không phải một future state of the product. Một Product Goal đúng nên mô tả sản phẩm sẽ ở trạng thái nào — ví dụ: "Khách hàng có thể thực hiện 90% giao dịch ngân hàng thường ngày (chuyển khoản, thanh toán hóa đơn, mở sổ tiết kiệm) hoàn toàn trên mobile mà không cần ra quầy." Cái này mới là điểm đến để inspect và adapt; ngày tháng chỉ là ràng buộc bên ngoài.
Bài học rút ra: Trong phòng thi PSM I, nếu một đáp án mô tả Product Goal như một "deadline", một "ngày release", hay một "lời cam kết sẽ giao đúng hạn" — gần như chắc chắn đó là đáp án sai. Product Goal là trạng thái tương lai của sản phẩm, không phải mốc lịch.
Hướng dẫn từng bước
Nếu bạn muốn áp dụng (và cũng để trả lời câu hỏi tình huống trong đề), đây là cách một Scrum Team làm việc với Product Goal:
- Product Owner xác định một Product Goal dựa trên tầm nhìn sản phẩm và giá trị mong muốn cho khách hàng/tổ chức. Goal này phải mô tả một trạng thái tương lai cụ thể, lý tưởng là có thể đo lường được để biết khi nào đã đạt.
- Đặt Product Goal vào Product Backlog. Nhớ: nó nằm trong Product Backlog, không phải một tài liệu tách rời. Thông thường nó đứng ở vị trí cao nhất, định hướng cho mọi PBI bên dưới.
- Để phần còn lại của Product Backlog "emerge" quanh Product Goal. Khi refinement (Bài 33), đội thêm/bớt/sắp xếp PBI sao cho chúng phục vụ Product Goal. PBI nào không đóng góp cho Goal thì cân nhắc loại bỏ hoặc hạ ưu tiên.
- Mỗi Sprint, Scrum Team "plan against" Product Goal. Trong Sprint Planning (Bài 13), đội chọn các PBI và tạo ra một Sprint Goal — Sprint Goal này phải là một bước tiến hướng tới Product Goal. Đây là chỗ Product Goal (dài hạn) kết nối với Sprint Goal (ngắn hạn).
- Inspect tiến độ tại Sprint Review. Tại Sprint Review, stakeholder và Scrum Team xem Increment và đánh giá tiến độ hướng tới Product Goal, rồi điều chỉnh Product Backlog cho phù hợp. Đây chính là Adaptation ở cấp sản phẩm.
- Fulfill hoặc abandon, rồi mới sang Goal mới. Khi Product Goal đã đạt được (hoặc được quyết định từ bỏ vì không còn hợp lý), Product Owner mới giới thiệu Product Goal tiếp theo. Một Goal tại một thời điểm.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ Product Goal là một Artifact thứ tư. Sai. Scrum chỉ có ba Artifact: Product Backlog, Sprint Backlog, Increment. Product Goal là Commitment của Product Backlog, nằm trong Product Backlog. Nếu đề hỏi "How many artifacts are there in Scrum?" → three.
Lỗi 2 — Nhầm Product Goal là "lời cam kết giao đúng hạn". Chữ "commitment" trong Scrum Guide 2020 KHÔNG mang nghĩa cam kết deadline. Nó mang nghĩa một thứ tăng cường minh bạch và làm điểm tham chiếu để đo tiến độ. Đừng để chữ "commitment" lừa bạn liên tưởng tới "hứa giao hàng đúng hẹn".
Lỗi 3 — Lẫn Product Goal với Sprint Goal. Product Goal là dài hạn, xuyên nhiều Sprint, thuộc Product Backlog. Sprint Goal là ngắn hạn, cho một Sprint, thuộc Sprint Backlog. (Bài 22 và Bài 46 sẽ đào sâu chỗ này — ở đây chỉ cần nhớ Product Goal ≠ Sprint Goal.)
Lỗi 4 — Cho rằng đội có thể theo đuổi nhiều Product Goal cùng lúc. Sai. Một Product Goal tại một thời điểm. Phải fulfill hoặc abandon trước khi nhận cái tiếp theo.
Lỗi 5 — Nghĩ Product Goal có trước cả 2020 trong Scrum Guide. Trong đề có thể có câu về lịch sử/thay đổi (liên quan Bài 5). Hãy nhớ: Product Goal là mới trong Scrum Guide 2020.
Mẹo ghi nhớ cặp Artifact–Commitment: Học thuộc ba cặp như một khối:
- Product Backlog → Product Goal
- Sprint Backlog → Sprint Goal
- Increment → Definition of Done
Bài tập thực hành
- Điền vào chỗ trống (theo Scrum Guide): "The Product Goal is in the ______." → Bạn tự trả lời rồi đối chiếu phần Khái niệm cốt lõi.
- Phân loại đúng/sai Product Goal. Với mỗi phát biểu, xác định nó có phải Product Goal hợp lệ không và giải thích:
- Câu hỏi kiểu PSM I: "Who is accountable for developing and explicitly communicating the Product Goal?" Chọn: (A) The Scrum Master, (B) The Developers, (C) The Product Owner, (D) The Stakeholders.
- Tình huống áp dụng: Đội của bạn vừa fulfill Product Goal hiện tại ở Sprint Review tuần này. Hãy viết ra ba bước tiếp theo mà Product Owner và Scrum Team nên làm liên quan đến Product Goal.
- Viết một Product Goal cho sản phẩm của chính bạn (hoặc một sản phẩm giả định). Đảm bảo nó mô tả trạng thái tương lai, đo lường được, và đủ rộng để kéo dài qua nhiều Sprint — không phải một feature đơn lẻ hay một deadline.
Tóm tắt
- Product Goal mô tả một trạng thái tương lai của sản phẩm, làm target để Scrum Team lập kế hoạch hướng tới qua nhiều Sprint.
- Nó là Commitment của Product Backlog, và nằm trong Product Backlog — không phải một artifact thứ tư.
- Scrum Guide 2020 thêm Product Goal vì empirical product management cần một future-state target để có thể inspect và adapt ở cấp sản phẩm dài hạn, tránh "feature factory".
- Scrum Team làm việc với một Product Goal tại một thời điểm; phải fulfill hoặc abandon trước khi nhận cái tiếp theo.
- Product Owner accountable cho việc phát triển và truyền đạt rõ ràng Product Goal.
- Đừng nhầm "commitment" với "cam kết giao đúng deadline"; đừng nhầm Product Goal với Sprint Goal hay với ngày release.
- Cặp ghi nhớ vàng cho phòng thi: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.