Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn bước lên một chiếc taxi và nói với bác tài: "Cho tôi đi đâu đó, miễn là nhanh." Bác tài sẽ nhìn bạn với ánh mắt khó hiểu, vì không có điểm đến thì mọi tốc độ đều vô nghĩa. Một Scrum Team không có Product Vision và Product Goal rõ ràng cũng y hệt như vậy: họ chạy Sprint này qua Sprint khác, hoàn thành rất nhiều story, tốc độ velocity nhìn rất đẹp trên biểu đồ — nhưng không ai biết rốt cuộc sản phẩm đang đi về đâu.
Trong vai trò Product Owner, đây có lẽ là phần "ít kỹ thuật" nhất nhưng lại quyết định nhiều nhất đến thành bại. Bạn có thể viết user story chuẩn chỉnh, refine backlog mượt mà, ước lượng story point chính xác — nhưng nếu cả những việc đó đang phục vụ cho một hướng đi sai, thì bạn chỉ đang "làm sai một cách hiệu quả". Product Vision và Product Goal chính là chiếc la bàn giúp bạn — và cả team — biết mình đang chèo thuyền về phía nào.
Bài này tập trung làm rõ hai khái niệm dễ bị nhầm lẫn: Product Vision (tầm nhìn dài hạn, mang tính khát vọng) và Product Goal (mục tiêu trung hạn, cụ thể, đo lường được). Hiểu đúng và phân biệt được hai thứ này là nền tảng để bạn dẫn dắt sản phẩm một cách có chủ đích, thay vì để mọi thứ trôi theo quán tính.
Khái niệm cốt lõi
Product Vision — tầm nhìn dài hạn
Product Vision là bức tranh khát vọng về tương lai mà sản phẩm của bạn muốn tạo ra, thường nhìn xa 3 đến 10 năm. Có ba đặc tính quan trọng cần ghi nhớ:
- Là hướng đi, không phải đích đến (direction, not destination). Vision không mô tả chính xác sản phẩm sẽ trông như thế nào ở năm thứ năm, mà mô tả thế giới sẽ thay đổi ra sao nhờ có sản phẩm của bạn. Nó giống như sao Bắc Đẩu: bạn không bao giờ "đến được" ngôi sao đó, nhưng nó luôn chỉ cho bạn biết hướng Bắc.
- Mang tính truyền cảm hứng (inspirational). Một vision tốt khiến người nghe muốn tham gia. Nó trả lời câu hỏi "Vì sao công việc này đáng để chúng ta dành nhiều năm cuộc đời?" Khi một developer mệt mỏi lúc 9 giờ tối vẫn cố sửa nốt một con bug, chính vision là thứ nhắc họ nhớ lý do.
- Ổn định nhưng không bất biến. Vision thay đổi rất chậm. Nếu bạn phải đổi vision mỗi quý thì đó không phải vision, mà chỉ là khẩu hiệu marketing.
Product Goal — mục tiêu trung hạn
Nếu Vision là chân trời, thì Product Goal là cột mốc gần nhất trên con đường đi tới chân trời đó. Theo Scrum Guide 2020, Product Goal là một artifact gắn liền với Product Backlog: nó mô tả trạng thái tương lai của sản phẩm mà team đang hướng tới, và đóng vai trò là mục tiêu để team lập kế hoạch.
Khác biệt cốt lõi so với Vision:
| Tiêu chí | Product Vision | Product Goal |
|---|---|---|
| Khung thời gian | 3–10 năm | 3–12 tháng (thường) |
| Tính chất | Khát vọng, định hướng | Cụ thể, đo lường được |
| Số lượng tại một thời điểm | Một (ổn định) | Một (đang hoạt động) |
| Trả lời câu hỏi | "Vì sao chúng ta tồn tại?" | "Điều gì tiếp theo cần đạt được?" |
Mối quan hệ phân tầng
Hãy hình dung một kim tự tháp gồm bốn tầng, từ trừu tượng đến cụ thể:
- Product Vision — khát vọng nhiều năm.
- Product Goal — cột mốc vài tháng tới, gắn với backlog.
- Sprint Goal — mục tiêu của một Sprint (sẽ học kỹ ở Bài 27).
- Product Backlog Items / User Stories — công việc cụ thể từng ngày.
Tình huống thực tế
Ví dụ 1 — Tiki và tầm nhìn "mọi thứ trong 2 giờ"
Khi Tiki bắt đầu, họ chỉ là một cửa hàng bán sách online. Nhưng tầm nhìn dài hạn dần định hình quanh ý tưởng: "Trở thành nền tảng thương mại điện tử nơi người Việt nhận được mọi thứ họ cần một cách nhanh nhất và đáng tin cậy nhất." Đây là một Vision điển hình — nó không nói "bán 50.000 đầu sách" mà nói về một trạng thái thế giới: khách hàng tin tưởng và nhận hàng cực nhanh.
Từ vision đó, đội sản phẩm có thể chia thành các Product Goal cụ thể qua từng giai đoạn. Giả định một chuỗi như sau:
- Product Goal năm 1: "Đạt tỷ lệ giao hàng đúng hẹn 95% tại Hà Nội và TP.HCM."
- Product Goal năm 2: "Ra mắt dịch vụ giao trong 2 giờ (TikiNOW) cho 80% mặt hàng ở khu vực nội thành."
Ví dụ 2 — Startup SaaS "QuanLyKho" lạc lối vì thiếu Product Goal
Một startup giả định ở TP.HCM tên QuanLyKho làm phần mềm quản lý kho cho các shop bán hàng online. Họ có Vision khá rõ: "Giúp mọi chủ shop nhỏ ở Việt Nam quản lý kho dễ như dùng Excel nhưng mạnh như doanh nghiệp lớn." Nghe rất hay. Nhưng họ không có Product Goal trung hạn.
Hệ quả: mỗi khi một khách hàng lớn yêu cầu tính năng, team lao vào làm. Quý 1 làm tính năng quản lý nhiều chi nhánh (vì một khách yêu cầu), quý 2 làm tích hợp sàn Shopee (vì khách khác yêu cầu), quý 3 làm báo cáo tài chính phức tạp. Velocity cao, team bận rộn, nhưng sau một năm: tỷ lệ khách hàng nhỏ — đối tượng cốt lõi trong vision — rời bỏ tới 45%, vì sản phẩm ngày càng phức tạp, đi ngược lại tinh thần "dễ như Excel".
Khi thuê một PO mới, người này đặt một Product Goal duy nhất cho 6 tháng: "Một chủ shop mới có thể tự cài đặt và nhập 100 sản phẩm đầu tiên trong vòng 15 phút mà không cần hỗ trợ." Đột nhiên mọi tranh luận về backlog trở nên dễ dàng: tính năng nào không phục vụ mục tiêu onboarding 15 phút đều bị hạ ưu tiên. Sáu tháng sau, tỷ lệ kích hoạt tài khoản mới tăng gấp đôi.
Bài học rút ra: Vision mà thiếu Product Goal sẽ biến PO thành "người nhận đơn đặt hàng" (order taker) chạy theo từng yêu cầu rời rạc. Product Goal chính là bộ lọc giúp bạn nói "không" một cách có cơ sở.
Ví dụ 3 — Grab và sự dịch chuyển Product Goal theo từng giai đoạn
Grab là minh họa tốt cho việc Vision ổn định nhưng Product Goal tiến hóa. Vision của họ xoay quanh ý tưởng "Driving Southeast Asia forward" — trở thành siêu ứng dụng phục vụ nhu cầu hàng ngày của người Đông Nam Á. Vision này gần như không đổi.
Nhưng Product Goal thì dịch chuyển rõ rệt theo từng chặng: giai đoạn đầu là chiếm lĩnh thị trường gọi xe (GrabTaxi, GrabBike); sau đó là giao đồ ăn (GrabFood); rồi đến thanh toán và tài chính số (GrabPay, ví điện tử). Mỗi lần mở rộng là một Product Goal mới, được đặt khi goal trước đã đạt tới độ chín.
Bài học rút ra: Khi một Product Goal đã hoàn thành hoặc không còn phù hợp, PO cần can đảm "đóng" nó lại và đặt goal mới — chứ không phải giữ team mãi ở một mục tiêu đã cũ. Đây là nhịp điệu lành mạnh: Vision soi đường, còn Product Goal được thay thế tuần tự khi từng cột mốc được chinh phục.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để bạn xây dựng và vận hành Vision cùng Product Goal.
Bước 1 — Soạn thảo Product Vision. Dùng một khuôn mẫu để khỏi viết lan man. Một template phổ biến là của Geoffrey Moore:
> FOR [đối tượng khách hàng mục tiêu] > WHO [nhu cầu hoặc nỗi đau cốt lõi] > THE [tên sản phẩm] IS A [loại sản phẩm] > THAT [lợi ích chính, lý do tồn tại] > UNLIKE [đối thủ / cách làm cũ] > OUR PRODUCT [điểm khác biệt then chốt].
Viết xong, kiểm tra ba tiêu chí: dài hạn (3–10 năm), truyền cảm hứng, và là hướng đi chứ không phải danh sách tính năng.
Bước 2 — Kiểm tra độ "đủ tham vọng". Nếu cả team đọc vision mà gật gù "ờ, hiển nhiên rồi" thì vision đó quá an toàn. Vision tốt nên hơi khiến người ta thấy "khó mà làm được" — đủ tham vọng để truyền cảm hứng, nhưng vẫn có thật một con đường khả thi.
Bước 3 — Phái sinh Product Goal từ Vision. Hỏi: "Trong 6–12 tháng tới, cột mốc quan trọng nhất đưa chúng ta gần Vision hơn là gì?" Chỉ chọn một Product Goal hoạt động tại một thời điểm. Đặt nó ở dạng đo lường được (gắn với một chỉ số kết quả, không phải chỉ số sản lượng).
Bước 4 — Gắn Product Goal vào Product Backlog. Theo Scrum Guide, Product Goal nằm trong Product Backlog và là đối tượng mà team lập kế hoạch hướng tới. Hãy ghi Product Goal ở vị trí trên cùng, dễ thấy, trong công cụ quản lý backlog của bạn (Jira, Linear...).
Bước 5 — Liên kết xuống Sprint Goal. Trong mỗi Sprint Planning, đặt câu hỏi: "Sprint Goal lần này đóng góp gì cho Product Goal?" Nếu không trả lời được, hoặc backlog cần điều chỉnh, hoặc Product Goal cần xem lại.
Bước 6 — Truyền thông liên tục. Vision và Product Goal không phải tài liệu cất trong ngăn kéo. Nhắc lại chúng ở mỗi Sprint Review, mỗi buổi onboarding thành viên mới, mỗi cuộc họp với stakeholder. Một vision chỉ sống nếu được nói ra thường xuyên.
Bước 7 — Rà soát định kỳ. Mỗi quý, đánh giá: Product Goal hiện tại đã đạt chưa? Có cần thay không? Vision còn đúng với thực tế thị trường không? Vision thay đổi rất hiếm, nhưng không có nghĩa là không bao giờ.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Vision với khẩu hiệu marketing. "Sản phẩm số 1 Việt Nam" không phải vision, đó là slogan. Vision phải mô tả thế giới thay đổi ra sao cho khách hàng, không phải vị trí của bạn trên bảng xếp hạng.
Lỗi 2 — Đặt Product Goal là danh sách tính năng. "Ra mắt tính năng A, B, C" là output, không phải goal. Goal nên là outcome: kết quả thay đổi ở hành vi khách hàng hoặc chỉ số kinh doanh. "Ra mắt tính năng chat" yếu; "Giảm thời gian phản hồi khách hàng trung bình xuống dưới 2 phút" mạnh.
Lỗi 3 — Có nhiều Product Goal cùng lúc. Khi mọi thứ đều ưu tiên thì chẳng có gì ưu tiên. Hãy giữ một Product Goal hoạt động; chỉ khi nó hoàn thành hoặc bị bỏ thì goal kế tiếp mới lên thay.
Lỗi 4 — Vision quá xa rời thực tế hoặc quá tầm thường. Quá viển vông thì không ai tin; quá tầm thường thì không ai được truyền cảm hứng. Hãy tìm điểm cân bằng "khó nhưng có thật một con đường".
Lỗi 5 — Viết xong rồi để đó. Vision và Goal bị quên lãng là lỗi phổ biến nhất. Mẹo: dán chúng lên đầu kênh Slack của team, in ra treo ở khu vực làm việc, mở đầu mỗi Sprint Review bằng việc đọc lại Product Goal.
Mẹo nâng cao: Khi tranh luận ưu tiên backlog đi vào ngõ cụt, hãy kéo mọi người về câu hỏi "việc này phục vụ Product Goal như thế nào?". Product Goal là trọng tài khách quan giúp cuộc tranh luận thoát khỏi cảm tính và quyền lực phòng ban.
Bài tập thực hành
- Viết Vision cho một sản phẩm bạn biết. Chọn một ứng dụng bạn dùng hàng ngày (ví dụ ZaloPay, Shopee, một app nội bộ công ty bạn). Dùng template Geoffrey Moore ở Bước 1 để viết một Product Vision cho nó. Tự chấm: nó có dài hạn, truyền cảm hứng, và là hướng đi không?
- Phái sinh ba Product Goal. Từ vision vừa viết, đề xuất ba Product Goal khả dĩ cho ba năm liên tiếp. Mỗi goal phải gắn với một chỉ số đo lường được (con số cụ thể + mốc thời gian). Sau đó chọn ra một goal mà bạn cho là cấp thiết nhất nếu phải bắt đầu ngay năm nay, và viết hai câu giải thích vì sao.
- Soi chiếu sản phẩm hiện tại của bạn. Nếu bạn đang đi làm: viết ra Product Goal hiện tại của team (nếu không có, đó cũng là một phát hiện quan trọng). Sau đó lấy 5 story gần nhất trong Sprint và đánh dấu story nào thực sự phục vụ Product Goal đó. Tỷ lệ phục vụ là bao nhiêu? Đây chính là thước đo mức độ "đi đúng hướng" của team bạn.
Tóm tắt
- Product Vision là khát vọng dài hạn (3–10 năm), mang tính truyền cảm hứng, là hướng đi chứ không phải đích đến. Nó trả lời câu hỏi "vì sao chúng ta tồn tại" và thay đổi rất chậm.
- Product Goal là cột mốc trung hạn (thường 3–12 tháng), cụ thể và đo lường được, gắn liền với Product Backlog. Tại một thời điểm chỉ nên có một Product Goal hoạt động.
- Hai khái niệm này nằm trong một kim tự tháp nhất quán: Vision → Product Goal → Sprint Goal → User Stories. Nhiệm vụ cốt lõi của Product Owner là giữ cho bốn tầng này không đứt gãy.
- Vision ổn định trong khi Product Goal tiến hóa: khi một goal đạt được, PO can đảm đóng nó lại và đặt goal mới, như cách Grab dịch chuyển từ gọi xe sang giao đồ ăn rồi tài chính số.
- Lỗi nguy hiểm nhất là viết Vision/Goal cho có rồi để quên, hoặc đặt goal dưới dạng danh sách tính năng thay vì kết quả. Hãy biến Product Goal thành bộ lọc ưu tiên và trọng tài khách quan trong mọi cuộc tranh luận về backlog.