Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua Bài 8 (Product Vision), Bài 9 (Product Strategy) và Bài 10 (OKRs cấp tổ chức), thì lúc này trong tay bạn đã có một tầm nhìn dài hạn, một chiến lược với North Star rõ ràng, và một bộ mục tiêu được cascade xuống các team. Nhưng có một câu hỏi mà mọi giám đốc sản phẩm (Senior Product Leader, CPO) đều phải trả lời, không phải mỗi năm một lần mà gần như mỗi tuần: "Vậy quý tới chúng ta làm gì, và tại sao lại là việc đó chứ không phải việc khác?"
Roadmap chính là cây cầu nối giữa tầm nhìn trừu tượng và công việc cụ thể mà đội ngũ engineer gõ code mỗi sáng. Đây là tài liệu mà CEO mở ra để biết sản phẩm đang đi đâu, mà đội sales dùng để hứa với khách hàng, mà mỗi PM trong team nhìn vào để hiểu việc của mình ăn khớp thế nào với bức tranh lớn.
Vấn đề là phần lớn roadmap ngoài kia bị làm sai. Chúng biến thành một danh sách tính năng kèm ngày tháng cứng nhắc — một lời hứa mà không ai giữ được, một bản kế hoạch lỗi thời ngay khi vừa in ra. Là một product leader, kỹ năng bạn cần không phải là "vẽ đẹp cái Gantt chart", mà là biến tầm nhìn thành một kế hoạch quý có thể thực thi, đủ linh hoạt để thích nghi nhưng đủ rõ ràng để cả tổ chức cùng chuyển động. Bài này dạy bạn đúng kỹ năng đó: đi từ Vision xuống Quarterly Plan.
Khái niệm cốt lõi
Roadmap không phải là danh sách tính năng có ngày tháng
Đây là hiểu lầm tai hại nhất. Một roadmap tốt trả lời câu hỏi "chúng ta sẽ giải quyết vấn đề gì và đạt kết quả gì", chứ không phải "chúng ta sẽ ship tính năng gì vào ngày nào". Khi bạn cam kết "tính năng X ra mắt 15/8", bạn đang đánh cược uy tín của mình vào một dự đoán mà bản chất công việc sản phẩm không cho phép chính xác. Khi bạn cam kết "trong quý này chúng ta sẽ giảm tỷ lệ rời bỏ ở bước thanh toán", bạn đang cam kết vào một outcome — và để ngỏ không gian cho team tìm ra cách tốt nhất.
Các horizon của roadmap: Now / Next / Later
Cách tổ chức roadmap phổ biến và hiệu quả nhất cho cấp lãnh đạo là chia theo ba khung thời gian (horizon), thường gọi là Now / Next / Later:
- Now (0–3 tháng): Đây là những việc team đang làm hoặc sắp bắt tay ngay trong quý hiện tại. Mức độ chi tiết cao, đã qua discovery, đã có sự đồng thuận. Đây gần như là một cam kết.
- Next (3–6 tháng): Những hướng đi tiếp theo đã được xác định nhưng chưa đào sâu. Bạn biết "vấn đề" nhưng chưa chốt "giải pháp". Mức cam kết trung bình.
- Later (6–12 tháng): Những cơ hội lớn, những đặt cược chiến lược đang nằm trên radar. Đây là định hướng, không phải cam kết. Nó tồn tại để mọi người hiểu hướng đi, không phải để lập lịch.
Roadmap theo theme, không theo feature
Thay vì liệt kê "đăng nhập bằng Google", "thêm dark mode", "tích hợp ZaloPay" — hãy nhóm công việc theo theme (chủ đề/sáng kiến). Ví dụ: theme "Giảm ma sát onboarding", theme "Mở rộng kênh thanh toán nội địa", theme "Tăng độ tin cậy hệ thống".
Tại sao theme thắng feature?
- Theme gắn với outcome. "Giảm ma sát onboarding" hướng tới một kết quả (tăng activation), còn "đăng nhập bằng Google" chỉ là một giải pháp có thể có hoặc không hiệu quả.
- Theme cho team không gian sáng tạo. Bạn giao vấn đề, không giao giải pháp. Team empowered (Bài 18) sẽ tự discovery ra giải pháp tốt nhất.
- Theme ổn định hơn feature. Giải pháp có thể thay đổi sau discovery, nhưng chủ đề chiến lược thì bền vững hơn nhiều — nên roadmap ít bị lỗi thời.
Roadmap theo quý (Quarterly): nhịp đập của tổ chức
Quý là đơn vị thời gian vàng cho product leader: đủ dài để hoàn thành thứ có ý nghĩa, đủ ngắn để điều chỉnh hướng đi khi thị trường thay đổi. Roadmap quý thường gắn chặt với OKRs quý (Bài 10): mỗi theme trong "Now" nên ánh xạ tới một hoặc nhiều Key Result. Đây là chỗ Vision → Strategy → OKRs → Roadmap khép thành một vòng mạch lạc.
Theo dõi confidence và effort, không chỉ deadline
Một roadmap trưởng thành gắn mỗi theme với hai thông tin: mức độ tin cậy (confidence — ta có chắc đây là việc đáng làm không) và quy mô công sức (effort — T-shirt size: S/M/L/XL). Điều này giúp cuộc trò chuyện với stakeholder chuyển từ "khi nào xong?" sang "đáng làm cỡ nào và tốn cỡ nào?" — đúng tầm tư duy của lãnh đạo.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "roadmap là danh sách lời hứa"
Hãy hình dung một sàn thương mại điện tử lớn tại Việt Nam, giả định lấy bối cảnh giống Tiki. Đội product từng duy trì một roadmap dạng bảng Excel với 40 dòng tính năng, mỗi dòng có một deadline cứng theo tháng. Đội sales lấy bảng này đi hứa với các nhãn hàng đối tác: "Tính năng livestream bán hàng sẽ có vào tháng 9."
Đến tháng 9, sau khi discovery, team phát hiện vấn đề thực sự khiến nhãn hàng rời đi không phải là thiếu livestream, mà là tốc độ xử lý đơn và độ chính xác tồn kho. Nhưng vì đã hứa livestream, team buộc phải ship một phiên bản livestream nửa vời để "giữ lời", tiêu tốn cả quý mà chẳng cải thiện chỉ số giữ chân nhãn hàng.
Diễn giải: Vấn đề không nằm ở việc team làm dở, mà ở chính cấu trúc roadmap. Một roadmap feature-based với deadline cứng đã khóa cứng quyết định trước khi có dữ liệu, và biến sales thành người bán những lời hứa mà product không kiểm soát được.
Bài học: Roadmap nên trình bày theo theme và outcome. Nếu theme là "Giữ chân nhãn hàng đối tác" thay vì "Ra mắt livestream", team sẽ tự do xoay sang giải quyết tốc độ xử lý đơn khi dữ liệu chỉ ra đó mới là gốc rễ — mà không phá vỡ bất kỳ cam kết nào.
Tình huống 2 — Một startup SaaS B2B tại TP.HCM áp dụng Now/Next/Later
Một startup SaaS B2B (giả định) làm phần mềm quản lý nhân sự cho doanh nghiệp vừa và nhỏ, khoảng 30 người, vừa gọi vốn vòng Series A. CPO mới về thay thế bảng roadmap-theo-tháng cũ bằng mô hình Now/Next/Later, công khai trên Notion cho cả công ty:
- Now (Q3): Theme "Tăng activation cho khách mới" (mapped tới KR: nâng tỷ lệ doanh nghiệp hoàn tất thiết lập trong 7 ngày từ 38% lên 60%). Effort: L. Confidence: cao.
- Next (Q4–đầu Q1): Theme "Mở rộng tích hợp chấm công" và theme "Tự phục vụ nâng cấp gói". Mới ở mức vấn đề, chưa chốt giải pháp.
- Later (6–12 tháng): Theme "Tính lương tự động theo luật BHXH Việt Nam" và "Mở rộng sang thị trường Indonesia". Định hướng, chưa cam kết.
Bài học: Now/Next/Later không chỉ là cách trình bày — nó là một công cụ đàm phán và quản trị kỳ vọng. Nó buộc mọi yêu cầu mới phải cạnh tranh sòng phẳng với những việc đang làm, thay vì cứ chen ngang.
Tình huống 3 — Grab và việc ánh xạ theme xuống nhiều team
Lấy bối cảnh một super-app quy mô Đông Nam Á như Grab. Ở quy mô này, một theme cấp tổ chức như "Tăng tần suất sử dụng đa dịch vụ" (khiến người dùng GrabFood cũng dùng GrabMart, GrabPay) phải được "dịch" xuống nhiều squad khác nhau: team Food, team Payments, team Rewards.
Product leader ở đây không vẽ một roadmap tính năng. Họ giữ một roadmap cấp portfolio theo theme, rồi mỗi squad tự xây roadmap chi tiết riêng cho phần của mình trong theme đó. Theme "Tăng tần suất đa dịch vụ" được team Rewards diễn giải thành "điểm thưởng dùng chéo dịch vụ", còn team Payments diễn giải thành "ví thống nhất giảm ma sát thanh toán". Mỗi quý, các squad báo cáo tiến độ theo outcome (số người dùng dùng ≥2 dịch vụ/tháng), không theo số tính năng ship được.
Diễn giải: Ở quy mô lớn, roadmap của lãnh đạo cấp cao càng phải trừu tượng theo theme và outcome; chi tiết feature là việc của các team. Nếu CPO cố ôm danh sách feature của hàng chục squad, roadmap sẽ vừa lỗi thời vừa biến lãnh đạo thành micro-manager.
Bài học: Theme là ngôn ngữ chung để align nhiều team quanh một outcome mà không cần kiểm soát từng giải pháp — đây chính là tinh thần kết nối với cascade OKRs ở Bài 10.
Hướng dẫn từng bước
Đây là quy trình thực dụng để xây một roadmap đi từ Vision xuống Quarterly Plan:
Bước 1 — Bắt đầu từ Vision và Strategy, không từ danh sách yêu cầu. Mở lại tầm nhìn (Bài 8) và North Star + các levers (Bài 9). Mọi theme trên roadmap phải truy ngược được về một lever chiến lược. Nếu một ý tưởng không phục vụ lever nào, nó không thuộc về roadmap quý này.
Bước 2 — Thu thập và phân cụm thành theme. Gom mọi đầu vào (phản hồi khách hàng, dữ liệu, ý tưởng nội bộ, yêu cầu sales) rồi nhóm chúng thành 5–8 theme. Đặt tên theme theo vấn đề/outcome, không theo giải pháp. Ví dụ: "Giảm thời gian thanh toán" chứ không phải "Thêm Apple Pay".
Bước 3 — Đánh giá mỗi theme theo Impact và Effort. Ước lượng tác động kỳ vọng lên North Star và lever, kèm T-shirt size cho effort. Đây là lúc ra quyết định ưu tiên: theme nào impact cao, effort hợp lý, và phục vụ lever quan trọng nhất.
Bước 4 — Phân bổ vào Now / Next / Later. Chỉ đưa vào "Now" số theme mà team thực sự có năng lực hoàn thành trong quý (thường 2–4 theme cho một team). Đừng nhồi nhét — một "Now" quá tải là dấu hiệu của roadmap không trung thực.
Bước 5 — Ánh xạ "Now" sang OKRs quý. Mỗi theme trong Now nên gắn với ít nhất một Key Result đo được. Đây là khớp nối biến roadmap thành thứ có thể đo lường, không chỉ là danh sách dự định.
Bước 6 — Gắn confidence và để team discovery. Đối với theme trong Now, ghi rõ mức tin cậy. Theme confidence thấp cần discovery (Bài 12, Bài 19) trước khi cam kết delivery.
Bước 7 — Truyền đạt và lặp lại theo nhịp. Công khai roadmap cho cả tổ chức. Review lại vào cuối mỗi quý: theme nào hoàn thành, theme nào dịch chuyển từ Next lên Now, cơ hội mới nào xuất hiện ở Later. Roadmap là tài liệu sống, không phải bản in một lần.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến roadmap thành Gantt chart với deadline cứng. Đây là lỗi phổ biến nhất. Mẹo: thay cột "ngày ra mắt" bằng cột "horizon" (Now/Next/Later). Nếu stakeholder đòi ngày, hãy giải thích rằng bạn cam kết outcome theo quý, và ngày cụ thể chỉ chốt sau discovery.
Lỗi 2 — Roadmap quá tải ở "Now". Một "Now" với 10 theme là lời hứa rằng không gì sẽ thực sự hoàn thành. Mẹo: giới hạn cứng số theme đang làm song song; mọi theme mới muốn vào Now phải đẩy một theme cũ ra.
Lỗi 3 — Để sales/CEO biến mỗi yêu cầu khách thành một dòng roadmap. Mẹo: dùng chính roadmap làm công cụ đàm phán — "việc này đang ở Later, để đưa lên Now ta phải đánh đổi cái gì?" Buộc mọi yêu cầu cạnh tranh trên cùng một bảng.
Lỗi 4 — Roadmap theo feature thay vì theme. Mẹo: với mỗi dòng, tự hỏi "đây là vấn đề hay giải pháp?" Nếu là giải pháp, lùi một bước về vấn đề nó phục vụ và đặt tên theme theo vấn đề đó.
Lỗi 5 — Roadmap "đóng băng" — làm xong rồi quên. Mẹo: đặt nhịp review cố định cuối mỗi quý; coi roadmap như sản phẩm sống cần cập nhật, không phải tài liệu lưu trữ.
Mẹo nâng cao: Duy trì hai phiên bản roadmap — một bản nội bộ (chi tiết theme, confidence, effort, mapping OKR) và một bản đối ngoại cho khách hàng/đối tác (chỉ Now/Next/Later theo theme, không số liệu nhạy cảm, không ngày tháng cam kết). Việc tách biệt này tránh được vô số rắc rối khi bản roadmap nội bộ vô tình lọt ra ngoài.
Bài tập thực hành
- Chuyển đổi feature → theme: Lấy roadmap hiện tại của sản phẩm bạn đang phụ trách (hoặc một sản phẩm bạn quen thuộc). Liệt kê 10 mục bất kỳ. Với mỗi mục, viết lại dưới dạng theme gắn outcome. So sánh: bao nhiêu mục thực ra chỉ là giải pháp đang giả vờ là chiến lược?
- Dựng roadmap Now/Next/Later: Chọn một sản phẩm và xây bản roadmap ba horizon với 2–3 theme cho Now, 2–3 cho Next, 2–3 cho Later. Với mỗi theme trong Now, ghi: outcome kỳ vọng, một Key Result đo được, T-shirt size effort, mức confidence.
- Tình huống đàm phán: Giả sử CEO yêu cầu gấp một tính năng đang nằm ở "Later". Viết ra (3–5 câu) cách bạn sẽ phản hồi bằng chính roadmap — nêu rõ đánh đổi nào trong "Now" sẽ phải hy sinh, và đặt câu hỏi để CEO tự cân nhắc ưu tiên.
- Ánh xạ xuống team: Lấy một theme cấp tổ chức và mô tả nó được "dịch" thành công việc cụ thể ở hai team khác nhau như thế nào (ví dụ team A và team B diễn giải cùng một theme theo cách khác nhau nhưng cùng phục vụ một outcome).
Tóm tắt
Roadmap là cây cầu nối tầm nhìn với công việc hằng ngày, và là một trong những công cụ giao tiếp quyền lực nhất của một product leader. Những điều cốt lõi cần khắc ghi:
- Roadmap trả lời "vấn đề và outcome gì", không phải "tính năng và ngày nào". Cam kết outcome, để ngỏ giải pháp.
- Tổ chức theo Now / Next / Later (0–3 / 3–6 / 6–12 tháng), với độ chắc chắn giảm dần theo horizon — đây là cách quản trị kỳ vọng stakeholder trung thực nhất.
- Nhóm theo theme, không theo feature. Theme gắn outcome, ổn định hơn, và trao cho team empowered không gian discovery.
- Lấy quý làm nhịp đập, ánh xạ mỗi theme trong "Now" sang OKRs quý để roadmap đo lường được.
- Dùng roadmap làm công cụ đàm phán: mọi yêu cầu mới phải cạnh tranh sòng phẳng với việc đang làm.
- Roadmap là tài liệu sống, review theo nhịp quý, không bao giờ đóng băng.