Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa nhậm chức Product Owner cho một sản phẩm fintech tại TP.HCM. Trong tuần đầu tiên, sếp hỏi: "Roadmap quý tới đâu rồi em?". Bạn mở file Excel cũ ra, thấy một bảng Gantt dài với hàng chục tính năng được gắn deadline cứng theo từng tháng. Sales đã hứa với khách rằng "tháng 9 có tính năng X". Marketing đã lên kế hoạch chiến dịch dựa trên ngày ra mắt đó. Và rồi development team nói với bạn rằng tính năng X phụ thuộc vào một phần tích hợp với ngân hàng mà chưa ai biết khi nào xong.
Đây là tình huống kinh điển mà gần như mọi PO đều gặp. Roadmap không chỉ là một tài liệu — nó là lời hứa. Và cách bạn trình bày roadmap quyết định bạn đang hứa cái gì: hứa về ngày tháng (date) hay hứa về kết quả (outcome).
Bài học này tập trung vào một quyết định nền tảng của nghề PO: chọn định dạng roadmap nào, và đặc biệt là so sánh hai trường phái đối lập — Timeline Roadmap kiểu Gantt và Now/Next/Later. Đây không phải chuyện thẩm mỹ. Chọn sai định dạng, bạn sẽ liên tục bị kéo vào các cuộc họp giải trình vì sao trễ deadline, thay vì tập trung tạo ra giá trị. Chọn đúng, roadmap trở thành công cụ giao tiếp chiến lược giúp cả tổ chức cùng nhìn về một hướng mà vẫn giữ được sự linh hoạt mà Agile đòi hỏi.
Khái niệm cốt lõi
Roadmap là bản trình bày trực quan về hướng đi của sản phẩm theo thời gian. Nhưng "theo thời gian" có thể hiểu theo hai cách rất khác nhau, và đó chính là gốc rễ của hai trường phái.
Loại 1: Timeline Roadmap (kiểu Gantt)
Đây là định dạng truyền thống, có lẽ bạn đã quá quen:
Q1 2026 | Q2 2026 | Q3 2026 | Q4 2026
Feature A | Feature B | Feature C | Feature D
Mỗi tính năng được đặt vào một ô thời gian cụ thể. Trục ngang là thời gian (tháng, quý), các thanh ngang biểu diễn thời lượng dự kiến của từng hạng mục, đôi khi có cả mũi tên thể hiện phụ thuộc giữa các hạng mục.
Điểm mạnh: Dễ đọc với người ngoài. Ban lãnh đạo, sales, đối tác đều hiểu ngay "cái gì làm khi nào". Nó tạo cảm giác chắc chắn và kiểm soát. Với những dự án có ràng buộc cứng thật sự — ví dụ tuân thủ quy định pháp lý phải xong trước ngày luật có hiệu lực — thì timeline là cần thiết.
Điểm yếu — và đây là vấn đề lớn: Timeline Roadmap biến dự báo thành cam kết. Trong môi trường phát triển sản phẩm, nơi mọi thứ đều bất định (đặc tính empirical mà Scrum nhấn mạnh), việc gắn deadline cứng cho những thứ ta chưa hiểu rõ là tự đặt bẫy cho chính mình. Nó khuyến khích tư duy "output" (làm xong tính năng) thay vì "outcome" (tạo ra giá trị). Khi thực tế thay đổi — và nó luôn thay đổi — mọi sai lệch so với timeline đều bị coi là "thất bại", dù việc thay đổi đó là quyết định đúng đắn.
Loại 2: Now / Next / Later
Đây là định dạng được cộng đồng Product hiện đại ưa chuộng, phổ biến hóa bởi Janna Bastow (đồng sáng lập ProductPlan/Prodpad). Thay vì trục thời gian tuyến tính, roadmap được chia thành ba cột theo mức độ chắc chắn và độ gần:
- Now — Những gì đội đang làm hoặc sắp làm ngay. Độ chắc chắn cao, đã được định nghĩa khá rõ.
- Next — Những gì sẽ làm tiếp theo. Có hướng nhưng chi tiết còn mở.
- Later — Những ý tưởng, cơ hội xa hơn. Mức độ chắc chắn thấp, có thể thay đổi nhiều.
Một điểm mạnh khác: Now/Next/Later thường được tổ chức theo problem/outcome (vấn đề cần giải, kết quả cần đạt) thay vì theo feature. Ví dụ thay vì viết "Làm tính năng chat", ta viết "Giảm thời gian phản hồi hỗ trợ khách hàng". Điều này giải phóng đội phát triển khỏi giải pháp định sẵn và mở đường cho discovery.
Outcome-based vs Feature-based — trục phân loại thứ hai
Ngoài trục "có timeline hay không", roadmap còn khác nhau ở chỗ nó liệt kê cái gì:
- Feature-based roadmap: liệt kê các tính năng cụ thể. Dễ hình dung nhưng dễ biến đội thành "feature factory".
- Outcome-based / theme-based roadmap: liệt kê các mục tiêu, vấn đề, theme. Linh hoạt hơn, gắn với chiến lược, nhưng đòi hỏi tổ chức trưởng thành để chấp nhận.
Roadmap không phải là kế hoạch giao hàng
Đây là ranh giới quan trọng cần khắc cốt ghi tâm: roadmap là công cụ chiến lược và giao tiếp, không phải lịch giao hàng chi tiết. Việc "khi nào item nào vào Sprint" thuộc về cách quản lý Backlog và Sprint Planning. Roadmap đứng ở tầng cao hơn — nó trả lời "chúng ta đang đi đâu và vì sao", chứ không phải "ngày 15 tháng 3 ship cái gì".
Tình huống thực tế
Ví dụ 1: Startup giao đồ ăn ở Việt Nam thoát khỏi "địa ngục Gantt"
Một startup giao đồ ăn (gọi là FoodFast, ~40 người, Series A) từng quản lý roadmap bằng một Gantt chart khổng lồ trên Google Sheets. CEO thường mở nó trong họp hội đồng quản trị để cho nhà đầu tư thấy "lộ trình rõ ràng".
Vấn đề bắt đầu khi thị trường thay đổi: một đối thủ tung chương trình freeship khiến tỷ lệ rời bỏ (churn) của FoodFast tăng vọt. Đội cần xoay sang giải quyết retention gấp. Nhưng roadmap Gantt đã ghi rõ "Q2: tính năng đặt bàn nhà hàng", và CEO đã hứa với nhà đầu tư. Suốt hai tháng, PO bị kẹt giữa việc làm đúng cam kết roadmap và việc làm đúng cho doanh nghiệp. Cuối cùng họ làm cả hai nửa vời, và cả hai đều ra trễ.
Sau cú đó, PO chuyển sang Now/Next/Later, tổ chức theo outcome:
- Now: "Giảm churn khách hàng mới trong 30 ngày đầu"
- Next: "Tăng giá trị đơn hàng trung bình"
- Later: "Mở rộng sang phân khúc nhà hàng cao cấp"
Ví dụ 2: Khi Gantt thật sự là lựa chọn đúng — dự án ngân hàng
Không phải lúc nào Now/Next/Later cũng thắng. Một ngân hàng tại Việt Nam triển khai hệ thống tuân thủ chuẩn báo cáo mới của Ngân hàng Nhà nước, với hạn chót pháp lý cố định là ngày 30/6. Ở đây, deadline không phải do PO bịa ra — nó là ràng buộc thật, vi phạm thì bị phạt.
Trong bối cảnh này, một PO khôn ngoan vẫn dùng Timeline Roadmap kiểu Gantt cho phần công việc bắt buộc tuân thủ, với các mốc rõ ràng: tích hợp dữ liệu xong tháng 4, kiểm thử tháng 5, đệ trình tháng 6. Lý do: khi tồn tại một ràng buộc thời gian cứng và phạm vi tương đối ổn định, timeline giúp phối hợp nhiều bên (legal, vận hành, đối tác) hiệu quả hơn.
Bài học: Định dạng roadmap phải khớp với bản chất của sự bất định. Bất định cao → Now/Next/Later. Ràng buộc cứng, phạm vi rõ → Timeline có chỗ đứng hợp lý. PO trưởng thành không tôn sùng một định dạng; họ chọn công cụ theo bối cảnh. Thậm chí có thể dùng Now/Next/Later cho phần khám phá sản phẩm, và một timeline nhỏ riêng cho phần tuân thủ.
Ví dụ 3: Đội SaaS ở Singapore và roadmap "lai"
Một công ty SaaS B2B ở Singapore phục vụ khách doanh nghiệp lớn gặp tình thế tế nhị: nội bộ họ muốn linh hoạt kiểu Now/Next/Later, nhưng khách hàng doanh nghiệp khi ký hợp đồng lại đòi "cam kết roadmap" để yên tâm.
Giải pháp họ chọn là roadmap hai lớp:
- Roadmap nội bộ: Now/Next/Later theo outcome, cập nhật mỗi tháng, dùng cho đội phát triển và lãnh đạo.
- Roadmap đối ngoại (customer-facing): chỉ chia sẻ phần "Now" và một phần "Next" đã đủ chắc chắn, diễn đạt bằng ngôn ngữ giá trị, kèm câu disclaimer rõ ràng "định hướng, không phải cam kết ngày cụ thể".
Bài học: Một PO thường cần nhiều phiên bản roadmap cho các đối tượng khác nhau. Sai lầm là dùng cùng một timeline chi tiết cho cả nội bộ lẫn khách hàng — vừa cứng nhắc với đội, vừa rủi ro với khách. Hãy tách lớp khán giả.
Hướng dẫn từng bước
Đây là quy trình để bạn thiết lập hoặc cải tổ roadmap sản phẩm của mình.
Bước 1 — Xác định khán giả và mục đích. Trước khi chọn định dạng, hỏi: roadmap này phục vụ ai? Đội phát triển cần độ rõ chiến lược; ban lãnh đạo cần thấy roadmap gắn với mục tiêu kinh doanh; khách hàng cần niềm tin nhưng không cần (và không nên có) ngày tháng cứng. Một roadmap không thể tối ưu cho mọi khán giả.
Bước 2 — Quyết định trục tổ chức: outcome hay feature. Khuyến nghị mạnh: tổ chức theo outcome/problem ở các tầng xa, và chỉ cụ thể hóa thành feature ở phần gần nhất. Ví dụ outcome "Tăng tỷ lệ kích hoạt tài khoản" thay vì feature "Thêm hướng dẫn onboarding".
Bước 3 — Chọn định dạng theo mức độ bất định.
- Bất định cao, sản phẩm đang khám phá thị trường → Now/Next/Later.
- Có ràng buộc thời gian cứng thật sự (pháp lý, sự kiện, hợp đồng) → cân nhắc Timeline cho phần đó.
- Phần lớn trường hợp sản phẩm số → mặc định nên là Now/Next/Later.
Bước 5 — Gắn mỗi hạng mục với một thước đo giá trị. Mỗi outcome nên có ít nhất một chỉ số (ví dụ: giảm churn từ 8% xuống 5%). Điều này biến roadmap từ danh sách việc thành công cụ chiến lược, và giúp bạn giải thích ưu tiên với stakeholder dựa trên dữ liệu thay vì cảm tính.
Bước 6 — Đặt nhịp cập nhật (review cadence). Roadmap là tài liệu sống. Hãy rà soát định kỳ — nhiều đội chọn hàng tháng, hoặc gắn với chu kỳ lập kế hoạch quý. Khi học được điều mới từ thị trường, hãy dịch chuyển các hạng mục giữa Now/Next/Later. Một roadmap không bao giờ thay đổi là dấu hiệu nó đang bị bỏ quên hoặc bị coi là cam kết bất khả xâm phạm.
Bước 7 — Truyền đạt rõ ranh giới cam kết. Với mọi khán giả, nói rõ: phần nào là cam kết, phần nào là định hướng. Một câu disclaimer đơn giản trên roadmap đối ngoại có thể cứu bạn khỏi vô số rắc rối sau này.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến roadmap thành lịch giao hàng có deadline cho mọi thứ. Đây là lỗi phổ biến nhất. Khi mọi hạng mục đều có ngày, bạn đã cam kết những thứ mình chưa hiểu. Mẹo: chỉ gắn ngày cho thứ có ràng buộc cứng thật và đã đủ rõ ràng để cam kết.
Lỗi 2 — Nhồi quá nhiều chi tiết vào phần xa (Later). PO mới hay viết Later với độ chi tiết ngang Now, tạo ảo giác chắc chắn. Mẹo: Later chỉ nên là các cơ hội ở mức tiêu đề. Nếu bạn thấy mình viết user story cho Later, hãy dừng lại.
Lỗi 3 — Roadmap toàn feature, không có "vì sao". Một danh sách tính năng không kể được câu chuyện chiến lược. Mẹo: với mỗi mục, tự hỏi "vấn đề khách hàng hoặc mục tiêu kinh doanh đằng sau là gì?". Nếu không trả lời được, mục đó chưa nên lên roadmap.
Lỗi 4 — Một roadmap dùng cho mọi khán giả. Dùng timeline kỹ thuật chi tiết để trình bày với khách hàng, hoặc dùng roadmap mơ hồ để phối hợp nội bộ — cả hai đều hỏng. Mẹo: duy trì một nguồn sự thật, nhưng xuất ra các "view" khác nhau cho từng khán giả.
Lỗi 5 — Coi roadmap là bất biến. Khi roadmap không bao giờ được sửa, nó trở thành xiềng xích. Mẹo: công khai lịch review roadmap, và xem việc thay đổi roadmap dựa trên học hỏi là dấu hiệu của một đội khỏe mạnh, không phải thất bại.
Lỗi 6 — Để sales/lãnh đạo biến mũi tên gợi ý thành lời hứa với khách. Mẹo: thiết lập quy tắc rõ: chỉ PO mới được cam kết ngày, và chỉ sau khi tham vấn đội phát triển.
Mẹo công cụ: Bạn không cần phần mềm đắt tiền. Một bảng Now/Next/Later trên Miro, Trello, Notion hay thậm chí Google Slides là đủ để bắt đầu. Sự rõ ràng về tư duy quan trọng hơn công cụ.
Bài tập thực hành
- Chẩn đoán roadmap hiện tại. Lấy roadmap đang dùng tại nơi bạn làm (hoặc một roadmap mẫu). Phân loại nó theo hai trục: (a) có timeline hay không, (b) feature-based hay outcome-based. Viết 3 câu nhận xét về rủi ro của định dạng đó.
- Chuyển đổi định dạng. Lấy một Gantt-style roadmap với ít nhất 6 hạng mục có deadline. Chuyển nó thành Now/Next/Later, đồng thời viết lại ít nhất 3 hạng mục từ ngôn ngữ feature sang ngôn ngữ outcome (ví dụ "Làm app mobile" → "Giúp khách hàng đặt hàng mọi lúc mọi nơi").
- Gắn thước đo. Với mỗi outcome ở cột Now và Next của bài tập 2, gắn một chỉ số đo lường giá trị cụ thể kèm con số mục tiêu.
- Tình huống stakeholder. Sales đến gặp bạn và nói: "Khách lớn đòi cam kết tính năng Y ra mắt tháng 9, nếu không họ không ký". Tính năng Y hiện đang ở cột Later. Viết một đoạn phản hồi 5–7 câu thể hiện cách bạn xử lý mà không hy sinh tính toàn vẹn của roadmap.
- Thiết kế hai lớp. Cho sản phẩm bạn chọn, phác thảo hai phiên bản roadmap: một bản nội bộ (đầy đủ Now/Next/Later) và một bản đối ngoại cho khách hàng (đã lọc, có disclaimer). Chỉ ra điểm khác biệt giữa hai bản.
Tóm tắt
Roadmap là một trong những công cụ giao tiếp quyền lực nhất của Product Owner, và định dạng bạn chọn định hình cả văn hóa kỳ vọng quanh sản phẩm. Timeline Roadmap kiểu Gantt tạo cảm giác chắc chắn và phù hợp khi có ràng buộc thời gian cứng thật sự, nhưng dễ biến dự báo thành cam kết và đẩy đội vào tư duy "feature factory". Now/Next/Later chấp nhận sự bất định một cách trung thực — càng xa tương lai càng ít chi tiết — và khi kết hợp với tổ chức theo outcome, nó biến roadmap thành công cụ chiến lược linh hoạt thay vì lịch giao hàng cứng nhắc.
Nguyên tắc cốt lõi để mang theo: chọn định dạng theo mức độ bất định, tổ chức theo outcome, gắn mỗi mục với một thước đo giá trị, và luôn nói rõ đâu là cam kết đâu là định hướng. Một PO trưởng thành không tôn sùng một định dạng duy nhất — họ làm chủ cả hai, duy trì nhiều "view" cho các khán giả khác nhau, và xem việc roadmap thay đổi theo học hỏi là dấu hiệu của sức khỏe, chứ không phải thất bại.