Claude cho PM: Cập nhật Product Roadmap

Roadmap là công cụ giao tiếp, không phải kế hoạch dự án

Sai lầm phổ biến nhất là PM quản lý roadmap như một Gantt chart chi tiết. Roadmap hiệu quả truyền đạt hướng chiến lược và thứ tự ưu tiên — không phải ngày giờ chính xác. Claude giúp bạn duy trì sự cân bằng này trong khi cập nhật roadmap.

Bước 1: Nắm trạng thái hiện tại của Roadmap

Prompt cung cấp context:

Đây là roadmap hiện tại của chúng tôi (format bất kỳ):
[paste roadmap hiện tại — có thể là list, bảng, hoặc mô tả]

Thông tin bổ sung:
- Team size: [X engineers, Y designers]
- Sprint length: [2 tuần]
- Thời điểm hiện tại trong quarter: [tuần X của Q2]
- OKRs hiện tại: [list OKRs]

Trạng thái các item:
- Đã hoàn thành gần đây: [list]
- Đang bị trễ/at risk: [list + lý do]
- Bị block: [list + nguyên nhân]

Hãy phân tích trạng thái roadmap và cho tôi biết: Điểm nào đang ổn? Rủi ro nào cần chú ý?

Bước 2: Chọn format roadmap phù hợp

Now / Next / Later (được dùng nhiều nhất):

Hãy tái cấu trúc roadmap theo format Now/Next/Later:

NOW (đang làm, sprint hiện tại đến 1 tháng tới):
- Committed work, high confidence về scope và timeline
- Cần: Tên item, owner, expected completion

NEXT (1-3 tháng tới):
- Planned work, good confidence về "what", less về "when"
- Cần: Tên item, estimate effort, key dependency

LATER (3-6+ tháng):
- Strategic bets, flexible scope và timing
- Cần: Tên item, strategic rationale

Ưu điểm format này: Tránh false precision về ngày cụ thể, phù hợp communicate với leadership và external stakeholders.

OKR-Aligned Roadmap (khi cần chứng minh strategic alignment):

Hãy tái cấu trúc roadmap theo OKRs:

OKR 1: [Objective]
  KR 1.1: [Key Result]
    - Initiative A (expected impact: +X% KR 1.1)
    - Initiative B (expected impact: +Y% KR 1.1)
  KR 1.2: [Key Result]
    - Initiative C (expected impact: ...)

OKR 2: [Objective]
  ...

Items chưa map được vào OKR nào: [list — đây là signal cần review]

Mục đích: Mỗi initiative phải có lý do "tại sao build" rõ ràng tied to measurable outcomes.

Bước 3: Ưu tiên hóa với frameworks

RICE Scoring:

Hãy tính RICE score cho các initiatives sau:
RICE = (Reach x Impact x Confidence) / Effort

[Initiative 1]: [mô tả ngắn]
[Initiative 2]: [mô tả ngắn]
[Initiative 3]: [mô tả ngắn]

Với mỗi initiative, help tôi estimate:
- REACH: Bao nhiêu users bị ảnh hưởng trong 1 quarter? (con số cụ thể)
- IMPACT: Mức tác động với mỗi user? (3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal)
- CONFIDENCE: Độ chắc chắn của estimate? (100%=data-backed, 80%=some evidence, 50%=gut)
- EFFORT: Person-months cần thiết?

Sau khi tính, sắp xếp theo RICE score và cho biết: Đây có phản ánh đúng intuition của bạn không? Nếu không, tại sao?

Value vs Effort Matrix (nhanh hơn, cho team planning):

Hãy sắp xếp các items sau vào Value vs Effort Matrix:

[list các items cần ưu tiên]

Phân loại theo 4 ô:
- HIGH VALUE + LOW EFFORT → Quick wins: Làm ngay
- HIGH VALUE + HIGH EFFORT → Big bets: Lên kế hoạch cẩn thận
- LOW VALUE + LOW EFFORT → Fill-ins: Làm khi có capacity thừa
- LOW VALUE + HIGH EFFORT → Money pits: Không nên làm

Giải thích logic phân loại từng item.

Bước 4: Quản lý thay đổi roadmap

Roadmap thay đổi là bình thường — nhưng cần có lý do rõ ràng, không phải "vì leadership yêu cầu."

Prompt xử lý thay đổi đột xuất:

Tình huống: [mô tả thay đổi — vd: "cần thêm Feature X vào Q2 theo yêu cầu của khách hàng lớn"]

Giúp tôi phân tích:
1. ĐIỀU GÌ ĐÃ THAY ĐỔI: Thông tin mới nào dẫn đến yêu cầu này?
2. ĐÁNH ĐỔI (TRADEOFF): Nếu thêm X vào, cần bỏ/trễ gì?
3. TÁC ĐỘNG: Items nào bị ảnh hưởng downstream?
4. CÁC PHƯƠNG ÁN:
   - Option A: Thêm X, bỏ/trễ Y
   - Option B: Thu hẹp scope của X để fit
   - Option C: Đẩy X sang Next quarter
5. KHUYẾN NGHỊ: Bạn recommend option nào và tại sao?
6. COMMUNICATION PLAN: Cần thông báo cho ai về thay đổi này?

Prompt viết communication về roadmap changes:

Roadmap vừa thay đổi: [mô tả thay đổi]
Lý do: [nguyên nhân cụ thể]
Tác động: [ai bị ảnh hưởng, cái gì bị trễ]

Hãy viết communication cho các đối tượng sau:
1. ENGINEERING TEAM: Cụ thể, technical, giải thích lý do rõ ràng
2. LEADERSHIP: Ngắn gọn, outcome-focused, highlight strategic rationale
3. CROSS-FUNCTIONAL PARTNERS (design, marketing, sales): Những gì cần họ biết và chuẩn bị lại

Bước 5: Quản lý Dependencies

Prompt mapping dependencies:

Với roadmap hiện tại, hãy giúp tôi map các dependencies:

1. TECHNICAL DEPENDENCIES: Feature B cần infrastructure từ Feature A
2. TEAM DEPENDENCIES: Feature nào cần team khác tham gia (design, platform, data)?
3. EXTERNAL DEPENDENCIES: Vendor, partner, third-party integration nào cần chờ?
4. SEQUENTIAL DEPENDENCIES: Cái gì phải ship trước khi bắt đầu cái khác?

Với mỗi dependency:
- Owner: Ai chịu trách nhiệm resolve?
- Need-by date: Cần resolve trước khi nào?
- Risk level: Cao / Trung bình / Thấp
- Contingency plan: Nếu dependency slip, sẽ làm gì?

Bước 6: Capacity Planning thực tế

Prompt tính capacity:

Giúp tôi tính team capacity cho [Q3 2025]:

Team: [X] engineers full-time
Thời gian: [13 tuần]

Trừ đi:
- Holidays: [list ngày nghỉ lễ Việt Nam trong period]
- Estimated PTO: [X% average]
- Overhead (meetings, interviews, on-call): [ước tính 25-30%]

Allocation mục tiêu:
- 70% planned features (roadmap items)
- 20% tech health (debt, reliability, performance)
- 10% buffer (urgent issues, quick wins)

Kết quả: Total person-weeks available cho feature work là bao nhiêu?

Sau đó compare với estimated effort của các roadmap items để xem có overcommit không.

Template Roadmap Summary hoàn chỉnh

Prompt tạo Roadmap Summary:

Hãy tạo Roadmap Summary sau khi update, bao gồm:

STATUS OVERVIEW:
- X items in progress | Y completed this period | Z at risk

ROADMAP ITEMS (format bảng):
| Item | Status | Timeframe | Owner | Key Dependencies |
(dùng: ✅ On Track | ⚠️ At Risk | 🔴 Blocked | ✓ Done | ○ Not Started)

RISKS & DEPENDENCIES:
- Items blocked/at risk với details
- Cross-team dependencies và status
- Items gần hard deadlines

CHANGES THIS UPDATE:
- Items added/removed/reprioritized
- Timeline shifts và lý do

Audience: PM team + Engineering leads
Format: Scannable, dùng emoji status indicators, có thể đọc trong 2 phút

Lỗi phổ biến trong roadmap management

• Roadmap là wishlist không giới hạn: Khi thêm item, luôn hỏi "Cái gì ra đi?" Roadmap là zero-sum against capacity.
• Thay đổi quá thường xuyên: Track tần suất thay đổi. Roadmap thay đổi hàng tuần là dấu hiệu chiến lược không rõ ràng.
• False precision về ngày: Commit date chính xác tạo expectation không thực tế. Dùng timeframe (Q3, "trong 6 tuần tới") thay vì ngày cụ thể.
• Dependency không được surface sớm: Dependency cross-team cần được flagged ngay khi item vào roadmap, không phải khi sắp đến lúc làm.

Bước tiếp theo

Sau khi có roadmap rõ ràng, bước tiếp theo là lên kế hoạch sprint cụ thể để execute. Xem Claude cho PM: Sprint Planning hiệu quả để biết cách chuyển roadmap thành sprint backlog có thể thực thi được.

Bài viết liên quan

• Claude cho PM: Brainstorming ý tưởng sản phẩm
• Claude cho Quản lý Sản phẩm: Tổng quan Plugin
• Claude cho PM: Competitive Brief sản phẩm
• Claude cho Engineering: Standup và báo cáo tiến độ
• Claude Productivity: Bắt đầu ngày làm việc hiệu quả