Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua những bài đầu của khóa PSPO II, bạn hẳn đã quen với khái niệm Product Goal — mục tiêu sản phẩm mà Scrum Guide 2020 đưa vào như một "cam kết" (commitment) gắn với Product Backlog. Product Goal trả lời câu hỏi: "Trong vài tháng tới, đội sản phẩm đang hướng tới điều gì cụ thể?" Đó là một công cụ tuyệt vời để giữ team tập trung.
Nhưng đây chính là cái bẫy mà rất nhiều Product Owner ở Việt Nam mắc phải: họ dừng lại ở Product Goal. Họ giỏi sắp xếp backlog, giỏi viết user story, giỏi chạy Sprint — nhưng khi sếp hoặc nhà đầu tư hỏi "Sản phẩm này sẽ đi về đâu trong 3 năm tới, và vì sao chúng ta tin con đường đó là đúng?", họ lúng túng. Họ có chiến thuật (tactics) nhưng thiếu chiến lược (strategy).
Ở cấp độ PSPO II, một Product Owner được kỳ vọng là người định hình chiến lược sản phẩm, chứ không chỉ thực thi nó. Bạn phải hiểu rằng Product Goal chỉ là một mảnh nhỏ nằm trong một hệ thống lớn hơn nhiều: từ Mission của tổ chức, xuống Vision của sản phẩm, qua Strategy, rồi mới tới những Product Goal nối tiếp nhau. Bài học này sẽ giúp bạn nhìn thấy toàn bộ bức tranh phân tầng đó, hiểu Product Strategy thực sự là gì, và biết cách dùng nó để dẫn dắt — thay vì chỉ "chạy theo" — sản phẩm của mình.
Khái niệm cốt lõi
Bốn tầng: Mission → Vision → Strategy → Goal
Hãy hình dung một kim tự tháp lật ngược, mỗi tầng cụ thể và ngắn hạn dần:
Mission — Tổ chức tồn tại để làm gì? (vô thời hạn)
↓
Vision — Sản phẩm sẽ trở thành gì trong 3-5 năm? (dài hạn)
↓
Strategy — Bằng cách nào ta đến được Vision? (1-2 năm, gồm bets + principles)
↓
Product Goal — Đích cụ thể tiếp theo phải đạt? (vài tháng)
↓
Sprint Goal — Trong Sprint này ta chứng minh điều gì? (1-4 tuần)
Mission là lý do tồn tại của cả tổ chức. Ví dụ, mission của Grab là "drive Southeast Asia forward" — thúc đẩy Đông Nam Á tiến lên. Mission gần như không đổi theo thời gian; nó là ngôi sao Bắc Đẩu.
Vision là hình ảnh tương lai mong muốn của riêng sản phẩm bạn phụ trách, trong khung 3-5 năm. Vision không phải là tính năng; nó mô tả một trạng thái thế giới khi sản phẩm thành công. Ví dụ: "Mọi tiểu thương ở Việt Nam đều có thể bán hàng online chỉ trong 5 phút mà không cần biết gì về công nghệ."
Strategy — đây là tầng mà bài học hôm nay nhấn mạnh, và cũng là tầng bị bỏ quên nhiều nhất. Strategy là cách bạn đi từ hiện tại đến Vision. Nó không phải một danh sách tính năng, mà là một tập hợp các lựa chọn có chủ đích: ta đánh cược (bets) vào đâu, ta phục vụ phân khúc khách hàng nào trước, ta KHÔNG làm gì, và những nguyên tắc (principles) nào dẫn dắt quyết định hằng ngày.
Product Goal là cột mốc cụ thể, đo lường được tiếp theo trên con đường chiến lược. Nó là cầu nối giữa Strategy trừu tượng và công việc thực thi trong Sprint.
Strategy không phải là plan, cũng không phải là roadmap
Đây là điểm khiến nhiều PO nhầm lẫn. Một bản kế hoạch (plan) liệt kê "làm gì, khi nào". Một roadmap sắp xếp các hạng mục theo thời gian. Nhưng Strategy là về lựa chọn dưới điều kiện bất định — nó trả lời "vì sao ta tin con đường này khả thi và đáng đi" và "ta chấp nhận hy sinh điều gì để thắng".
Roger Martin, một trong những nhà tư duy chiến lược lớn, định nghĩa strategy là "một tập hợp các lựa chọn tích hợp đặt bạn vào vị thế thắng". Ông nhấn mạnh hai câu hỏi: Where to play (chơi ở đâu — phân khúc, thị trường, kênh nào) và How to win (thắng bằng cách nào — lợi thế khác biệt nào). Nếu bản "chiến lược" của bạn đúng với bất kỳ công ty nào trong ngành thì đó không phải chiến lược — đó chỉ là khẩu hiệu.
Strategy gồm Bets và Principles
Ý định gốc của bài đã gợi ra hai thành phần quan trọng:
- Bets (những cú đặt cược): Trong môi trường bất định, bạn không thể biết chắc điều gì đúng. Vì vậy chiến lược tốt được diễn đạt như những giả thuyết có thể sai: "Chúng ta đặt cược rằng tiểu thương sẽ chọn nền tảng nào tích hợp sẵn ví điện tử, nên ta ưu tiên tích hợp thanh toán trước khi mở rộng catalog." Mỗi bet đi kèm một niềm tin và một cách kiểm chứng.
- Principles (nguyên tắc dẫn dắt): Đây là những "luật chơi" giúp cả team ra quyết định nhất quán khi PO không có mặt. Ví dụ: "Ưu tiên giữ chân khách hàng hiện tại hơn thâu tóm khách mới", hay "Không bao giờ đánh đổi độ tin cậy thanh toán để lấy tốc độ ra tính năng." Principles biến chiến lược thành thứ có thể thực thi hằng ngày, không chỉ nằm trên slide.
Vì sao Product Goal cần được "neo" vào Strategy
Khi Strategy rõ ràng, mỗi Product Goal trở thành một bước đi có lý do. Bạn có thể nhìn một Product Goal và nói: "Mục tiêu này phục vụ bet số 2 trong chiến lược của ta." Khi Strategy mơ hồ, Product Goal trở thành những mục tiêu rời rạc — team chạy hết Goal này sang Goal khác mà không ai biết tổng thể đang tiến tới đâu. Đó chính là triệu chứng của "feature factory": nhà máy sản xuất tính năng không ngừng nghỉ mà không tạo ra outcome.
Tình huống thực tế
Tình huống 1 — Tiki và cú xoay chiến lược từ "sách" sang "marketplace"
Tiki khởi đầu năm 2010 với một vision khá hẹp: bán sách trực tuyến tử tế, giao nhanh, hàng thật. Mission ngầm là phục vụ người đọc Việt Nam một trải nghiệm mua sách đáng tin cậy. Ở giai đoạn đó, Product Goal của họ rất hợp lý: tối ưu kho sách, tốc độ giao hàng, độ chính xác đơn.
Nhưng khi thị trường e-commerce bùng nổ và Shopee, Lazada đổ tiền vào, ban lãnh đạo Tiki đối mặt một câu hỏi chiến lược, không phải chiến thuật: "Vision của chúng ta trong 5 năm là gì — vẫn là hiệu sách online, hay là một sàn thương mại?" Họ chọn xoay sang marketplace, và điều quan trọng là họ chọn một How to win khác biệt: thay vì đua giá rẻ nhất (sân chơi của Shopee), họ đặt cược vào TikiNOW giao nhanh 2 giờ và cam kết hàng chính hãng — đánh vào nỗi đau "sợ mua phải hàng giả" của người tiêu dùng Việt.
Đó là một bet rõ ràng: "Chúng tôi tin một nhóm khách hàng sẵn sàng trả nhiều hơn để chắc chắn hàng thật và nhận nhanh." Principle đi kèm: ưu tiên kiểm soát chất lượng nguồn hàng hơn là mở rộng số lượng người bán bằng mọi giá.
Bài học rút ra: Nếu Tiki chỉ dừng ở Product Goal ("bán nhiều sách hơn"), họ đã chết trong cuộc đua. Chính việc nâng tầm tư duy lên Vision và Strategy — chọn nơi để chơi và cách để thắng — mới giúp họ tồn tại. Là PO, bạn phải biết khi nào câu hỏi đặt ra không thể giải bằng một Product Goal mới, mà cần xem lại cả tầng chiến lược.
Tình huống 2 — Startup SaaS "PayLite" và chiến lược không có sự hy sinh
Hãy lấy một ví dụ giả định nhưng rất điển hình. PayLite là startup fintech Việt làm phần mềm kế toán cho doanh nghiệp nhỏ. PO của họ — tạm gọi là anh Minh — có một "chiến lược" dán trên tường: "Trở thành phần mềm kế toán tốt nhất cho mọi doanh nghiệp Việt Nam."
Vấn đề: chiến lược này không có lựa chọn nào cả. "Mọi doanh nghiệp" nghĩa là không có Where to play. "Tốt nhất" không nói được How to win. Hệ quả thực tế: mỗi Sprint team làm một thứ cho một nhóm khách khác nhau — tuần này thêm tính năng cho quán cà phê, tuần sau cho công ty xây dựng, tuần sau nữa cho phòng khám. Backlog phình to, không có chủ đề, và không phân khúc nào thấy sản phẩm thực sự "dành cho mình".
Sau sáu tháng tăng trưởng phẳng, anh Minh buộc phải làm lại. Chiến lược mới sắc bén hơn: "Trong 18 tháng tới, trở thành lựa chọn số 1 cho chuỗi F&B 3-20 cửa hàng ở TP.HCM và Hà Nội, bằng cách là phần mềm kế toán duy nhất tự động đồng bộ với máy POS và ví điện tử phổ biến tại Việt Nam." Có Where to play (chuỗi F&B vừa), có How to win (tích hợp POS + ví), có hy sinh rõ ràng (tạm bỏ qua công ty xây dựng, phòng khám).
Chỉ sau đó các Product Goal mới trở nên mạch lạc: Goal quý này là "đạt tích hợp 2 chiều với 3 hệ thống POS phổ biến nhất ngành F&B." Mọi story trong Sprint đều phục vụ một bet rõ ràng.
Bài học rút ra: Một chiến lược mà không loại bỏ điều gì thì không phải chiến lược. Dấu hiệu nhận biết PO chưa có chiến lược thật: backlog của họ không thể hiện một sự hy sinh nào.
Tình huống 3 — Grab và sự phân tầng Mission–Vision–Strategy
Grab là ví dụ đẹp về việc bốn tầng ăn khớp với nhau. Mission: "Drive Southeast Asia forward" — thúc đẩy khu vực phát triển. Vision cho mảng siêu ứng dụng: trở thành "everyday app" mà người Đông Nam Á mở ra cho mọi nhu cầu hằng ngày. Strategy cụ thể: dùng dịch vụ gọi xe làm cửa ngõ thu hút người dùng, rồi đặt cược vào việc cross-sell GrabFood và GrabPay lên chính tập người dùng đó, với principle "tăng tần suất mở app quan trọng hơn tối đa hóa lợi nhuận từng dịch vụ riêng lẻ."
Từ đó, từng Product Goal của đội GrabFood (ví dụ "rút thời gian từ đặt món đến giao xuống dưới 30 phút ở khu vực trung tâm") đều có thể truy ngược lên tới Mission. Mỗi người trong team hiểu vì sao mình làm việc đó.
Bài học rút ra: Khi bốn tầng được căn chỉnh, mọi quyết định nhỏ đều có "lý do lớn" đứng sau. Đây là điều một Senior PO cần tạo ra cho team của mình — một "đường truyền ý nghĩa" liền mạch từ Sprint Goal lên tới Mission.
Hướng dẫn từng bước
Dưới đây là cách bạn tự xây dựng và kiểm tra Product Strategy cho sản phẩm của mình.
Bước 1 — Viết rõ Mission và Vision trước. Trước khi nói tới chiến lược, hãy chắc chắn bạn diễn đạt được Mission của tổ chức (một câu) và Vision sản phẩm 3-5 năm (một đoạn ngắn, mô tả trạng thái thế giới khi thành công, không chứa tính năng cụ thể).
Bước 2 — Trả lời "Where to play". Liệt kê các phân khúc khách hàng, thị trường, kênh khả dĩ. Khoanh tròn nơi bạn sẽ tập trung trước. Quan trọng không kém: gạch chéo rõ ràng những nơi bạn chọn không phục vụ trong giai đoạn này.
Bước 3 — Trả lời "How to win". Với phân khúc đã chọn, lợi thế khác biệt của bạn là gì? Vì sao khách chọn bạn thay vì đối thủ? Nếu câu trả lời đúng với cả đối thủ thì bạn chưa có lợi thế — quay lại tìm tiếp.
Bước 4 — Phát biểu các Bets dưới dạng giả thuyết. Viết 2-4 cú đặt cược cốt lõi theo cấu trúc: "Chúng tôi tin rằng [niềm tin], vì vậy chúng tôi sẽ [hành động], và sẽ biết mình đúng nếu [bằng chứng đo được]." Cách viết này khiến chiến lược của bạn có thể được kiểm chứng, đúng tinh thần Evidence-Based Management.
Bước 5 — Định nghĩa Principles. Viết 3-5 nguyên tắc dẫn dắt quyết định để team tự ra quyết định nhất quán khi không có bạn. Mỗi principle nên ngụ ý một sự đánh đổi.
Bước 6 — Phái sinh Product Goal từ chiến lược. Với chiến lược trong tay, đặt câu hỏi: "Đích cụ thể, đo lường được tiếp theo nào sẽ chứng minh hoặc đẩy mạnh nhất một trong các bets của ta?" Đó chính là Product Goal kế tiếp. Mỗi Product Goal phải truy ngược được tới ít nhất một bet.
Bước 7 — Đóng vòng lặp. Sau mỗi vài Product Goal, nhìn lại bằng chứng thu được: bet nào được xác nhận, bet nào bị bác bỏ? Chiến lược không phải tài liệu viết một lần — nó là giả thuyết sống, được cập nhật khi học hỏi.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Vision với Strategy. Vision mô tả "đến đâu"; Strategy mô tả "đi bằng cách nào và hy sinh gì". Nhiều PO viết một câu vision đẹp rồi tưởng đã có chiến lược. Mẹo: nếu phát biểu của bạn không chứa một lựa chọn loại trừ nào, đó là vision (hoặc khẩu hiệu), chưa phải strategy.
Lỗi 2 — Chiến lược không có sự hy sinh. Như tình huống PayLite, "phục vụ mọi người" là dấu hiệu chết. Mẹo: trong workshop chiến lược, bắt buộc team viết một danh sách "Những điều chúng ta chủ động KHÔNG làm trong giai đoạn này."
Lỗi 3 — Dừng ở Product Goal, không ngước lên tầng trên. PO chỉ quản backlog mà không bao giờ chất vấn chiến lược sẽ biến team thành feature factory. Mẹo: trong mỗi buổi Product Backlog refinement quan trọng, hỏi một câu: "Hạng mục này phục vụ bet chiến lược nào?" Nếu không trả lời được, hãy nghi ngờ.
Lỗi 4 — Chiến lược cứng nhắc, coi như cam kết bất biến. Ở môi trường bất định, bám chặt một chiến lược đã bị bằng chứng bác bỏ là tự sát. Mẹo: diễn đạt mọi bet dưới dạng giả thuyết có thể sai, và định kỳ review để pivot khi cần — giống cú xoay của Tiki.
Lỗi 5 — Giữ chiến lược trong đầu PO, không chia sẻ. Nếu chiến lược chỉ tồn tại trong đầu bạn, team sẽ ra quyết định lệch hướng. Mẹo: dán Vision, Bets và Principles ở nơi team nhìn thấy mỗi ngày (vật lý hoặc trong công cụ chung), và nhắc lại chúng trong Sprint Review để stakeholder cũng đồng bộ.
Mẹo tổng: Một bài kiểm tra nhanh độ tốt của chiến lược — đưa nó cho một đồng nghiệp và hỏi: "Dựa vào cái này, bạn có thể tự quyết nên ưu tiên A hay B không?" Nếu họ có thể, chiến lược của bạn đủ sắc. Nếu họ vẫn phải hỏi bạn, nó còn quá mơ hồ.
Bài tập thực hành
Hãy chọn một sản phẩm bạn đang làm (hoặc một sản phẩm Việt Nam bạn quen thuộc như MoMo, ZaloPay, Tiki, hay một app nội bộ công ty) và thực hiện:
- Vẽ kim tự tháp bốn tầng cho sản phẩm đó: viết một câu Mission, một đoạn Vision 3-5 năm, phần Strategy, và Product Goal hiện tại. Để trống tầng nào bạn không trả lời được — chính chỗ trống đó cho thấy điểm yếu cần lấp.
- Phát biểu Where to play / How to win. Viết một câu cho mỗi vế. Sau đó tự chấm: phát biểu How to win của bạn có đúng luôn cho đối thủ chính không? Nếu có, viết lại cho sắc hơn.
- Viết 3 Bets theo cấu trúc "Chúng tôi tin rằng… vì vậy chúng tôi sẽ… và sẽ biết mình đúng nếu…". Với mỗi bet, chỉ rõ một metric kiểm chứng.
- Viết 3 Principles, mỗi cái phải ngụ ý một sự đánh đổi rõ ràng (dạng "ưu tiên X hơn Y").
- Liên kết ngược. Lấy Product Goal hiện tại của sản phẩm và chỉ ra nó phục vụ bet nào trong số 3 bet bạn vừa viết. Nếu không liên kết được, hãy đề xuất một Product Goal mới phù hợp hơn với chiến lược.
Tóm tắt
- Product Goal là công cụ tốt nhưng chỉ là một tầng thấp trong hệ thống: Mission → Vision → Strategy → Product Goal → Sprint Goal. PSPO II kỳ vọng bạn làm chủ cả bốn tầng, đặc biệt là tầng Strategy thường bị bỏ quên.
- Strategy không phải plan hay roadmap. Nó là tập hợp các lựa chọn có chủ đích dưới điều kiện bất định, trả lời Where to play và How to win, và luôn kèm theo một sự hy sinh.
- Strategy được cấu thành từ Bets (giả thuyết có thể sai, kèm cách kiểm chứng) và Principles (nguyên tắc giúp team ra quyết định nhất quán).
- Mỗi Product Goal phải truy ngược được lên một bet chiến lược. Nếu không, bạn đang vận hành một feature factory.
- Chiến lược là giả thuyết sống, được cập nhật theo bằng chứng — như cú xoay từ "hiệu sách" sang "marketplace giao nhanh, hàng thật" của Tiki.
- Bài kiểm tra vàng: nếu chiến lược không loại bỏ điều gì, và không giúp đồng nghiệp tự quyết A hay B, thì nó chưa phải chiến lược thật.