Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được nhận vào vị trí Product Manager đầu tiên. Sếp gọi bạn vào phòng họp và nói: "Tuần sau họp toàn công ty, em chuẩn bị roadmap sản phẩm cho sáu tháng tới nhé." Bạn gật đầu tự tin, về bàn mở một file Excel, rồi... đứng hình. Roadmap là cái gì? Nó khác gì với cái bảng deadline mà Project Manager vẫn gửi? Mình liệt kê tính năng theo tuần là xong, hay phải làm gì hơn thế?
Đây là một trong những hiểu lầm phổ biến nhất với người mới làm PM ở Việt Nam, và nói thật, kể cả nhiều PM đã đi làm vài năm vẫn chưa thực sự hiểu đúng. Roadmap không phải là một danh sách tính năng kèm ngày tháng. Nó cũng không phải là lời cam kết bằng máu rằng "ngày 15/9 chắc chắn ra mắt". Roadmap là một công cụ giao tiếp (communication tool) — và nếu bạn dùng sai mục đích, nó sẽ trở thành sợi dây thòng lọng tự buộc vào cổ mình.
Trong bài này, chúng ta sẽ làm rõ những điều nền tảng nhất về roadmap: nó dùng để làm gì, nó KHÔNG phải là gì, và làm sao để xây dựng một roadmap khiến cả công ty hiểu hướng đi mà không biến nó thành một bản hợp đồng cứng nhắc. Đây là kiến thức nền — những kỹ thuật chi tiết hơn (định dạng theo theme, theo timeline, theo "now-next-later"…) bạn sẽ gặp lại và đào sâu ở các bài chuyên về roadmapping sau. Còn ở đây, ta nắm cho chắc cái gốc.
Khái niệm cốt lõi
Roadmap thực chất là gì?
Product roadmap là một tài liệu trình bày trực quan, thể hiện hướng đi của sản phẩm theo thời gian và lý do tại sao chúng ta đi theo hướng đó. Từ khóa quan trọng nhất ở đây là "hướng đi" và "lý do" — chứ không phải "danh sách việc cần làm".
Một roadmap tốt trả lời được ba câu hỏi:
- Chúng ta đang cố giải quyết vấn đề gì cho người dùng và cho doanh nghiệp?
- Chúng ta dự định giải quyết theo thứ tự ưu tiên nào?
- Vì sao thứ tự đó hợp lý vào thời điểm hiện tại?
Bốn mục đích thật sự của roadmap
1. Truyền đạt hướng đi của sản phẩm (Communicate direction). Đây là lý do tồn tại số một. Roadmap giúp mọi người trong và ngoài team trả lời được câu hỏi "Sản phẩm này đang đi về đâu?". Khi một kỹ sư mới vào, khi một nhân viên sales gặp khách hàng, khi CEO trình bày với nhà đầu tư — tất cả đều cần một bức tranh chung về hướng đi. Roadmap chính là bức tranh đó.
2. Đồng bộ các team nội bộ (Align internal teams). Sản phẩm không phải do một mình PM làm ra. Có engineering, design, marketing, sales, customer support, vận hành… Mỗi team có việc riêng nhưng phải chèo về cùng một hướng. Roadmap là điểm tham chiếu chung để Marketing biết khi nào nên chuẩn bị chiến dịch, để Sales biết tính năng nào sắp có mà hứa với khách, để Support biết điều gì sắp thay đổi để đào tạo trước.
3. Thiết lập kỳ vọng với các bên liên quan (Set expectations with stakeholders). Sếp, nhà đầu tư, đối tác, khách hàng lớn — họ đều muốn biết "khi nào tôi có cái tôi cần?". Roadmap giúp bạn quản lý kỳ vọng một cách có hệ thống thay vì hứa hẹn ngẫu hứng. Lưu ý chữ "kỳ vọng" — không phải "cam kết". Kỳ vọng là "chúng tôi đang hướng tới việc làm X trong quý này", chứ không phải "X sẽ giao đúng ngày 30/6".
4. Hỗ trợ ra quyết định ưu tiên (Support prioritization). Khi mọi người nhìn thấy bức tranh lớn, các cuộc tranh luận "cái này có nên làm trước không?" trở nên dễ hơn nhiều, vì bạn có một khung tham chiếu để soi vào: "Việc này có phục vụ hướng đi đã thống nhất trên roadmap không?".
Roadmap KHÔNG phải là gì — ranh giới cực kỳ quan trọng
Đây là phần mà nếu bạn nhớ duy nhất một thứ trong bài, hãy nhớ phần này.
Roadmap KHÔNG phải là project plan. Project plan (kế hoạch dự án) là tài liệu chi tiết: ai làm gì, mất bao lâu, phụ thuộc vào cái gì, deadline cụ thể từng đầu việc nhỏ. Project plan sống ở cấp độ "thực thi" (execution), tính bằng ngày và tuần, do team trực tiếp quản lý. Roadmap sống ở cấp độ "chiến lược" và "kết quả" (outcomes), tính bằng quý hoặc tháng, và trả lời câu hỏi "tại sao". Nhầm hai cái này là sai lầm kinh điển: bạn sẽ biến roadmap thành một bảng Gantt chi chít deadline, rồi mỗi lần dev trượt một task là cả roadmap "sai" và bạn mất uy tín.
Roadmap KHÔNG phải là một lời cam kết (commitment). Roadmap là tuyên bố về ý định (statement of intent), dựa trên những gì ta biết tại thời điểm này. Thị trường thay đổi, dữ liệu mới xuất hiện, đối thủ ra chiêu mới — roadmap phải thay đổi theo. Một roadmap không bao giờ đổi trong sáu tháng không phải là roadmap kỷ luật, mà là roadmap không ai thèm cập nhật. Càng nhìn xa về tương lai, độ chắc chắn càng giảm — đó là quy luật tự nhiên, không phải lỗi của bạn.
Roadmap KHÔNG phải là danh sách tính năng (feature list). Roadmap nói về vấn đề cần giải quyết và kết quả mong muốn, không phải về giải pháp cụ thể. "Giảm tỷ lệ bỏ giỏ hàng ở bước thanh toán" là một mục roadmap tốt. "Thêm nút thanh toán bằng MoMo" chỉ là một giải pháp khả dĩ — có thể đúng, có thể không, sẽ được quyết khi đào sâu hơn.
Tình huống thực tế
Ví dụ 1: Roadmap bị biến thành "hợp đồng" tại một startup fintech Việt Nam
Một startup fintech ở TP.HCM (tạm gọi là PayFast) có khoảng 25 nhân sự. PM mới — anh Long — xây roadmap đầu tiên của mình thành một bảng Excel với 18 tính năng, mỗi tính năng gắn một ngày ra mắt cụ thể: "Tích hợp VietQR — 12/3", "Chia hóa đơn nhóm — 28/3", "Đầu tư chứng chỉ quỹ — 15/4"…
Anh trình bày cho CEO, CEO gật gù, rồi đem nguyên bảng đó đi gặp một quỹ đầu tư để gọi vốn vòng tiếp theo. Nhà đầu tư chốt deal với kỳ vọng những mốc đó là cam kết. Vấn đề bắt đầu khi đội engineering phát hiện tích hợp VietQR phải qua quy trình thẩm định của ngân hàng đối tác mất thêm sáu tuần — điều không ai lường được lúc lập bảng. Hệ quả dây chuyền: mọi mốc sau đó đều trượt. Đến cuộc họp cập nhật với nhà đầu tư, anh Long phải giải trình tại sao "cam kết" bị phá vỡ, và niềm tin sứt mẻ.
Bài học rút ra: Roadmap bị dùng sai mục đích — nó được trình bày như một bản cam kết về ngày tháng, trong khi bản chất nó chỉ là ý định dựa trên thông tin tại thời điểm lập. Giá như anh Long trình bày theo dạng "Quý 1 chúng tôi tập trung vào trải nghiệm thanh toán nhanh (gồm VietQR và chia hóa đơn); Quý 2 mở rộng sang sản phẩm đầu tư" — kèm ghi chú rõ ràng rằng càng xa thì càng ít chắc chắn — thì khi VietQR trượt, đó vẫn nằm gọn trong "Quý 1", không ai cảm thấy bị thất hứa.
Ví dụ 2: Roadmap như "chất keo" gắn kết các phòng ban tại một sàn TMĐT
Một sàn thương mại điện tử quy mô vừa ở Đông Nam Á (tạm gọi ShopVerse, khoảng 200 nhân sự) áp dụng roadmap theo định hướng kết quả, chia làm ba khung thời gian thay vì ngày cụ thể: "Đang làm / Sắp tới / Tương lai". Mỗi mục được mô tả bằng vấn đề người dùng, chẳng hạn: "Giảm thời gian từ lúc đặt hàng đến lúc nhận hàng cho khu vực tỉnh".
Điều thú vị là cách roadmap này được dùng hằng tuần. Đội Marketing nhìn vào mục "Đang làm" thấy tính năng "theo dõi đơn hàng theo thời gian thực" sắp xong, nên họ chủ động lên kế hoạch chiến dịch email cho người dùng tỉnh. Đội Sales (mảng bán hàng cho nhà bán lớn) nhìn mục "Sắp tới" để biết tính năng nào nên hứa với đối tác, tính năng nào chưa nên đề cập. Đội Customer Support nhìn vào để chuẩn bị tài liệu hướng dẫn trước khi tính năng ra mắt, thay vì bị động xử lý khiếu nại sau đó.
Một con số cụ thể: sau khi chuẩn hóa roadmap theo cách này, ShopVerse báo cáo số lần "tính năng ra mắt mà Support không hề biết trước" giảm từ trung bình 3-4 lần/quý xuống gần như bằng không.
Bài học rút ra: Đây là minh họa sống động cho mục đích "đồng bộ team nội bộ" và "thiết lập kỳ vọng". Roadmap không nằm chết trong một file, mà trở thành điểm tham chiếu chung mà mọi phòng ban chủ động soi vào. Giá trị của nó không nằm ở độ chính xác từng ngày, mà ở khả năng giúp mọi người đi cùng nhịp.
Ví dụ 3: Roadmap không có "lý do" — câu chuyện của một app giao đồ ăn
Một app giao đồ ăn (tạm gọi FoodNow) có roadmap liệt kê rất nhiều tính năng hấp dẫn: chat trong app, gamification tích điểm, đặt món theo nhóm, gợi ý món bằng AI… Nhưng khi một kỹ sư backend hỏi PM "Tại sao chúng ta làm gamification trước chat? Em thấy khách than phiền về việc không liên lạc được với tài xế nhiều hơn cơ mà?", PM không trả lời được. Roadmap chỉ có "cái gì" và "khi nào", thiếu hoàn toàn "tại sao".
Hệ quả là cả team thực thi một cách máy móc, không ai thực sự tin vào thứ tự ưu tiên, và mỗi lần có ý kiến từ sếp lớn là roadmap lại bị xáo trộn vì chẳng có cơ sở nào để phản biện.
Bài học rút ra: Một roadmap thiếu phần "lý do" (rationale) sẽ mất đi sức mạnh quan trọng nhất — khả năng tạo sự đồng thuận và hỗ trợ ra quyết định. Khi mỗi mục gắn với một vấn đề rõ ràng của người dùng hoặc doanh nghiệp, cả team mới có thể vừa thực thi vừa phản biện một cách lành mạnh.
Hướng dẫn từng bước
Đây là quy trình nền tảng để xây dựng một roadmap cơ bản. Chưa cần công cụ phức tạp — một slide hoặc một bảng đơn giản là đủ.
Bước 1 — Xác định rõ mục tiêu sản phẩm trong giai đoạn tới. Trước khi nói "làm gì", hãy chốt "muốn đạt được điều gì". Ví dụ: "Trong sáu tháng tới, mục tiêu chính là tăng tỷ lệ người dùng quay lại trong tuần đầu (retention tuần 1)". Mọi thứ trên roadmap sau đó phải phục vụ mục tiêu này.
Bước 2 — Liệt kê các vấn đề/cơ hội, không phải giải pháp. Thu thập từ phản hồi khách hàng, dữ liệu, ý kiến nội bộ. Diễn đạt dưới dạng vấn đề: "Người dùng mới bị bối rối ở màn hình onboarding", "Khách tỉnh phải chờ giao hàng quá lâu". Tránh nhảy thẳng vào "thêm nút X".
Bước 3 — Sắp xếp ưu tiên. Dựa trên mức độ ảnh hưởng đến mục tiêu (Bước 1) và mức độ khả thi. Bạn không cần khung phức tạp ở giai đoạn này — chỉ cần trả lời được: "Cái nào tác động mạnh nhất tới mục tiêu và làm được sớm nhất?".
Bước 4 — Nhóm theo khung thời gian, không phải ngày cụ thể. Với người mới, mình khuyên dùng ba cột đơn giản: Đang làm — Sắp tới — Tương lai (Now — Next — Later). Cách này tránh được cái bẫy "ngày tháng = cam kết" mà ví dụ PayFast đã mắc phải. Càng về cột "Tương lai", mô tả càng mơ hồ, và điều đó hoàn toàn bình thường.
Bước 5 — Gắn "lý do" cho từng nhóm. Với mỗi mục, viết một câu ngắn giải thích nó phục vụ mục tiêu gì. Đây chính là thứ phân biệt roadmap với danh sách việc.
Bước 6 — Chia sẻ và lấy phản hồi. Đưa cho engineering, design, marketing, sales xem trước. Họ sẽ chỉ ra những điểm bất khả thi hoặc thiếu sót mà bạn không thấy. Roadmap là tài liệu sống, được hoàn thiện qua đối thoại.
Bước 7 — Đặt nhịp cập nhật. Quyết định bao lâu rà soát lại một lần (thường mỗi 2-4 tuần hoặc theo chu kỳ quý). Một roadmap không có nhịp cập nhật sẽ nhanh chóng lỗi thời và mất uy tín.
Lỗi thường gặp & mẹo
Lỗi 1: Biến roadmap thành lịch giao hàng theo ngày. Khi mỗi mục có một ngày cứng, bạn tự biến ý định thành cam kết. Mẹo: dùng khung thời gian (quý, hoặc Now/Next/Later) thay cho ngày cụ thể, đặc biệt cho những thứ ở xa.
Lỗi 2: Roadmap chỉ liệt kê tính năng, thiếu "tại sao". Mẹo: với mỗi mục, ép bản thân viết một câu "Việc này giúp đạt được… vì…". Nếu không viết nổi, có thể mục đó chưa nên nằm trên roadmap.
Lỗi 3: Quá nhiều chi tiết. Roadmap không phải backlog. Nếu nó dài như một bảng kê công việc của team, bạn đang nhầm cấp độ. Mẹo: nếu một mục có thể vỡ thành mười task nhỏ, hãy gói nó lại thành một mục lớn theo vấn đề.
Lỗi 4: Làm roadmap một lần rồi để đó. Roadmap "đông cứng" mất hết giá trị. Mẹo: lên lịch rà soát định kỳ, và mỗi lần thị trường/dữ liệu thay đổi đáng kể thì cập nhật ngay, đồng thời thông báo cho các bên liên quan vì sao thay đổi.
Lỗi 5: Một roadmap cho mọi đối tượng. Cách bạn trình bày cho CEO khác với cho đội engineering, khác với cho khách hàng. Mẹo: giữ một "nguồn sự thật" chung về hướng đi, nhưng điều chỉnh mức độ chi tiết và ngôn ngữ tùy người nghe. Với khách hàng bên ngoài, càng ít cam kết ngày tháng càng an toàn.
Mẹo vàng: Mỗi khi ai đó hỏi "khi nào có tính năng X?", hãy tập phản xạ trả lời bằng vấn đề và khung thời gian thay vì ngày: "Việc cải thiện tốc độ giao hàng cho khu vực tỉnh đang nằm trong nhóm ưu tiên của quý này" — thay vì "ngày 20 sẽ xong". Phản xạ này bảo vệ uy tín của bạn về lâu dài.
Bài tập thực hành
Hãy chọn một sản phẩm bạn quen thuộc — có thể là app bạn đang dùng hằng ngày (một ví Việt Nam như MoMo, một app gọi xe, hay một sàn TMĐT), hoặc một sản phẩm giả định bạn muốn xây.
- Viết một mục tiêu sản phẩm cho sáu tháng tới (một câu duy nhất, đo lường được). Ví dụ: "Tăng tỷ lệ người dùng hoàn tất thanh toán lần đầu".
- Liệt kê 5-6 vấn đề/cơ hội dưới dạng vấn đề của người dùng hoặc doanh nghiệp, KHÔNG viết thành tên tính năng.
- Sắp xếp chúng vào ba cột: Đang làm — Sắp tới — Tương lai. Tự hỏi cái nào tác động mạnh nhất tới mục tiêu ở bước 1.
- Gắn một câu "lý do" cho mỗi mục.
- Tự kiểm tra: Đọc lại bản roadmap của bạn và trả lời ba câu hỏi: (a) Một người ngoài team có hiểu được "sản phẩm này đang đi về đâu" không? (b) Có chỗ nào bạn đang vô tình cam kết một ngày cụ thể không? (c) Có mục nào thực ra chỉ là một giải pháp/tính năng được trá hình thành mục tiêu không?
Tóm tắt
Roadmap, ở cấp độ nền tảng, là một công cụ giao tiếp thể hiện hướng đi của sản phẩm theo thời gian và lý do đằng sau hướng đi đó. Bốn mục đích cốt lõi của nó là: truyền đạt hướng đi, đồng bộ các team nội bộ, thiết lập kỳ vọng với stakeholder, và hỗ trợ ra quyết định ưu tiên.
Quan trọng không kém là hiểu roadmap KHÔNG phải là gì: nó không phải project plan (kế hoạch thực thi chi tiết), không phải một cam kết cứng về ngày tháng, và không phải một danh sách tính năng vô hồn. Ba ví dụ — PayFast biến roadmap thành "hợp đồng" và mất uy tín, ShopVerse dùng roadmap làm chất keo gắn kết phòng ban, FoodNow có roadmap thiếu "lý do" — đều xoay quanh một chân lý: giá trị của roadmap nằm ở việc nó giúp mọi người đi cùng một hướng, chứ không nằm ở độ chính xác từng ngày.
Khi xây roadmap, hãy bắt đầu từ mục tiêu, diễn đạt theo vấn đề thay vì giải pháp, nhóm theo khung thời gian thay vì ngày cụ thể (Now/Next/Later là một khởi đầu an toàn), luôn gắn "tại sao", và coi nó là tài liệu sống cần cập nhật đều đặn. Nắm chắc cái gốc này, bạn sẽ sẵn sàng cho những kỹ thuật roadmapping chuyên sâu hơn ở phía trước.