Bảng phân hạng ra mắt
Mẫu & ví dụ Launch TemplatesXếp mọi lần ra mắt trong quý vào Tier 1, 2, 3 theo tiêu chí viết sẵn, để mỗi thứ nhận đúng mức chuẩn bị — không thừa, không thiếu.
Mẫu này giúp bạn
Hiểu rằng không phải lần ra mắt nào cũng cần cùng một mức chuẩn bị, và tier được quyết bởi tác động lên khách hàng và rủi ro chứ không bởi công sức kỹ thuật.
Viết được bộ tiêu chí tier kiểm được bằng có hoặc không cùng các trưởng bộ phận, xếp mọi lần ra mắt trong quý kể cả đổi giá, ghi lý do và phần không đảo ngược được cho từng dòng, giữ bảng sống qua các kickoff và sửa tiêu chí sau mỗi retro.
Mẫu, ví dụ đã điền và cách dùng
Bảng phân hạng ra mắt dùng để làm gì?
Mỗi quý một đội sản phẩm có thể đưa ra mười mấy thay đổi. Nếu tất cả được chuẩn bị như nhau, có hai kết cục: hoặc mọi thứ đều làm kỹ và đội kiệt sức vì những thay đổi nhỏ, hoặc mọi thứ đều làm qua loa và một lần đổi giá rơi vào tay support lúc 9 giờ sáng thứ Hai mà không ai báo trước. Bảng phân hạng ra mắt là nơi đội quyết, một lần, mỗi thứ sắp ra mắt đáng bao nhiêu chuẩn bị.
Bảng xếp từng lần ra mắt vào Tier 1, 2 hoặc 3 dựa trên tác động lên khách hàng và rủi ro — không dựa trên công sức kỹ thuật hay mức độ tự hào của đội. Mỗi tầng kéo theo một gói chuẩn bị cố định: ai được mời, checklist dài hay ngắn, có go/no-go không, có readout không, cần bao nhiêu tuần.
Giá trị lớn nhất của bảng không nằm ở nhãn tier mà ở cột lý do. Khi một trưởng nhóm sales hỏi "sao tính năng khách tôi chờ chỉ là tier 3?", câu trả lời đã được viết sẵn, theo tiêu chí cả công ty đã đồng ý, chứ không phải ý kiến của PM ngày hôm đó.
Dành cho: PM · Product Owner · Head of Product · Growth PM · Product Marketing
Dùng khi: Đầu mỗi quý khi chốt roadmap, và ở buổi kickoff của từng tính năng — tier được chốt trước khi viết dòng code đầu tiên, vì nó quyết định ai cần có mặt và cần bao nhiêu tuần chuẩn bị.
Khác gì với roadmap và bảng ưu tiên?
| Trả lời câu hỏi | Không trả lời | |
|---|---|---|
| Roadmap | Làm gì, theo thứ tự nào, khi nào | Mỗi thứ cần chuẩn bị ra mắt nặng hay nhẹ |
| Bảng ưu tiên (RICE và tương tự) | Cái gì đáng làm trước | Một tính năng giá trị thấp vẫn có thể rủi ro cao khi ra mắt |
| Bảng phân hạng ra mắt | Mỗi thứ đã quyết làm cần bao nhiêu chuẩn bị, ai tham gia, ai quyết go/no-go | Có nên làm hay không — việc đó đã quyết ở chỗ khác |
Một tính năng có thể đứng cuối bảng ưu tiên mà vẫn là tier 1 — ví dụ đổi điều khoản thanh toán theo yêu cầu pháp lý. Giá trị và rủi ro ra mắt là hai trục khác nhau; trộn chúng là nguồn gốc của câu "cái này nhỏ thôi, không cần báo ai".
Bản trắng — copy và dán vào tài liệu của bạn
Hai phần. Phần A là tiêu chí — viết một lần, cả công ty dùng chung, chỉ sửa khi một retro chỉ ra nó sai. Phần B là bảng của quý, mỗi lần ra mắt một dòng.
BẢNG PHÂN HẠNG RA MẮT — Quý ...... — Người giữ bảng: ......
Cập nhật lần cuối: ......
PHẦN A — TIÊU CHÍ (dùng chung, sửa sau retro)
Một lần ra mắt là TIER 1 nếu có ít nhất một điều sau:
[ ] Đổi giá, gói cước, phí, điều khoản hoặc chính sách dữ liệu
[ ] Khách hàng phải làm gì đó: đào tạo lại, cấu hình lại, đổi quy trình
[ ] Chạm vào tiền, dữ liệu cá nhân, hoặc luồng doanh thu chính
[ ] Có truyền thông ra ngoài: báo chí, sự kiện, chiến dịch trả tiền
[ ] Không đảo ngược được bằng cách tắt flag
Là TIER 2 nếu không phải tier 1 và có ít nhất một điều sau:
[ ] Tính năng mới người dùng nhìn thấy, cho một nhóm đáng kể
[ ] Đổi một luồng mà support thường được hỏi
[ ] Sales hoặc CS cần biết để nói với khách
Còn lại là TIER 3.
GÓI CHUẨN BỊ THEO TẦNG
Tier 1: checklist đủ | go/no-go do ...... quyết | rollout theo nấc |
truyền thông nội bộ + khách | phòng điều phối |
readout 2 và 6 tuần | chuẩn bị ...... tuần
Tier 2: checklist rút gọn | go/no-go do PM quyết | rollout theo nấc |
hướng dẫn support + release note | readout 2 tuần |
chuẩn bị ...... tuần
Tier 3: release note | báo support qua kênh chung | theo dõi lỗi 48 giờ
PHẦN B — CÁC LẦN RA MẮT TRONG QUÝ
(mỗi lần ra mắt một khối)
#. Tên: ......
Ai bị ảnh hưởng (bao nhiêu): ......
Tiêu chí chạm (dòng nào của phần A): ......
TIER: ...... Lý do một câu: ......
Người quyết go/no-go: ...... Ngày release dự kiến: ......
Đảo ngược được? có / không / một phần — phần nào: ......
ĐỔI TIER GIỮA CHỪNG (ghi lại, không xoá)
Số ...... từ tier ...... sang tier ...... vì ...... ngày ......
Duyệt: ...... Ngày: ......Từng ô điền gì, và vì sao ô đó tồn tại
| Ô | Điền gì | Bỏ trống thì hỏng ở đâu |
|---|---|---|
| Tiêu chí tier 1 và tier 2 (phần A) | Danh sách điều kiện kiểm được bằng có hoặc không — không phải "quan trọng" hay "lớn". | Không có tiêu chí viết sẵn thì tier được quyết theo người nói to nhất, và dần dần mọi thứ đều thành tier 1. |
| Gói chuẩn bị theo tầng | Mỗi tier kéo theo việc gì, ai quyết go/no-go, cần bao nhiêu tuần. | Nhãn tier không kèm gói chuẩn bị chỉ là nhãn. Người đọc thấy "tier 2" mà không biết thế nghĩa là phải làm gì. |
| Ai bị ảnh hưởng (bao nhiêu) | Nhóm người dùng hoặc khách hàng cụ thể, kèm con số ước lượng. | Không có số thì một thay đổi cho 40 khách doanh nghiệp và một thay đổi cho 2 triệu người dùng trông giống hệt nhau trên bảng. |
| Tiêu chí chạm | Dòng nào của phần A khiến lần ra mắt này lên tier. | Đây là bằng chứng cho tier. Thiếu nó thì lần sau ai hỏi lại cũng phải tranh luận lại từ đầu. |
| Lý do một câu | Câu bạn sẽ nói với người phản đối tier. | Người hỏi "sao chỉ tier 3" cần một câu trả lời, không cần một bảng tiêu chí. |
| Người quyết go/no-go | Một cái tên, không phải một phòng ban. | "Ban lãnh đạo quyết" nghĩa là không ai quyết; đến hôm go/no-go mọi người nhìn nhau. |
| Đảo ngược được? | Có, không, hoặc một phần — kèm phần nào không. | Phần không đảo ngược được (email đã gửi, giá đã đổi, dữ liệu đã chuyển) là lý do phổ biến nhất để đẩy một thay đổi "nhỏ" lên tier 1. Bỏ ô này là bỏ qua đúng chỗ nguy hiểm nhất. |
| Đổi tier giữa chừng | Nhật ký mỗi lần tier thay đổi và vì sao. | Phạm vi đổi trong lúc xây là chuyện thường. Không ghi lại thì gói chuẩn bị vẫn chạy theo tier cũ và support vẫn không được báo. |
Cách dùng — 45 phút đầu quý, 5 phút ở mỗi kickoff
- Viết phần A một lần, cùng các trưởng bộ phận. Mời support, sales, marketing, pháp chế và tech lead. Mỗi người thêm một điều kiện mà lần ra mắt hỏng gần nhất của họ lẽ ra đã bắt được. Tiêu chí tốt nhất đến từ sự cố thật, không đến từ sách.
- Liệt kê mọi thứ sẽ ra mắt trong quý, kể cả thay đổi cấu hình, đổi giá và thay đổi do đối tác. Đổi giá thường không có trong roadmap sản phẩm vì nó "chỉ là cấu hình" — và đó chính là lý do nó hay gây sự cố.
- Với từng dòng, đi qua phần A từ trên xuống và dừng ở điều kiện đầu tiên khớp. Ghi điều kiện đó vào ô tiêu chí chạm. Đừng tranh luận về cảm giác; chỉ tranh luận điều kiện có khớp hay không.
- Điền ô "đảo ngược được?" trước khi chốt tier. Một thay đổi trông như tier 3 mà có phần không đảo ngược được thì đưa lên ít nhất tier 2.
- Gửi bảng cho support, sales và marketing trong ngày. Họ cần biết tier 1 nào đang tới để giữ người và thời gian. Bảng nằm trong ổ của PM là bảng chưa tồn tại.
- Ở kickoff từng tính năng, mở lại dòng của nó. Phạm vi đã đổi chưa? Nếu đổi, ghi vào mục đổi tier giữa chừng và báo lại các bên.
- Sau mỗi retro, hỏi: tier có đúng không? Nếu một tier 3 gây ra 200 ticket, phần A đang thiếu một điều kiện. Thêm nó vào, ghi ngày sửa.
Ví dụ đã điền đầy đủ
Bếp Số (giả định) bán phần mềm quản lý nhà hàng cho khoảng 3.200 quán ăn và chuỗi nhỏ, thu phí theo tháng. Đây là bảng quý 1/2027, sau khi đội đã sửa phần A hai lần dựa trên retro năm trước.
BẢNG PHÂN HẠNG RA MẮT — Quý 1/2027 — Người giữ bảng: Thảo (Senior PM)
Cập nhật lần cuối: 20/01/2027
PHẦN A — dùng bản chung của công ty, sửa lần cuối 05/12/2026
(thêm điều kiện "quán phải in lại menu, hoá đơn hoặc mã QR" sau sự cố
đổi mẫu hoá đơn tháng 10)
GÓI CHUẨN BỊ
Tier 1: go/no-go do anh Quân (Head of Product) quyết, chuẩn bị 5 tuần
Tier 2: go/no-go do PM phụ trách quyết, chuẩn bị 2 tuần
Tier 3: release note, báo kênh #support-updates, theo dõi 48 giờ
PHẦN B — CÁC LẦN RA MẮT TRONG QUÝ
1. Gói Pro tăng giá từ 450.000đ lên 520.000đ/tháng
Ảnh hưởng: 1.150 khách gói Pro
Tiêu chí chạm: đổi giá
TIER 1 — khách trả nhiều hơn; mỗi khách phải được báo trước 30 ngày
Go/no-go: anh Quân Release: 01/03
Đảo ngược: một phần — email đã gửi thì không rút lại được; có thể
giữ giá cũ cho khách hiện tại
2. Thanh toán bằng QR động tại bàn
Ảnh hưởng: khoảng 900 quán đang dùng gọi món tại bàn
Tiêu chí chạm: chạm vào tiền; quán phải in lại mã QR trên bàn
TIER 1 — lỗi ở đây là khách ăn xong không trả được tiền
Go/no-go: anh Quân Release: 15/02 (5%)
Đảo ngược: một phần — tắt flag được, nhưng mã QR đã in vẫn nằm trên bàn
3. Báo cáo món bán chạy theo khung giờ
Ảnh hưởng: chủ quán của cả 3.200 khách, chủ yếu xem trên điện thoại
Tiêu chí chạm: tính năng mới người dùng nhìn thấy
TIER 2 — không chạm tiền, không bắt khách làm gì; support sẽ được
hỏi "số này tính thế nào"
Go/no-go: Thảo Release: 10/02 Đảo ngược: có
4. Đồng bộ đơn từ hai ứng dụng giao đồ ăn đối tác
Ảnh hưởng: 640 quán đang nhập tay đơn giao đồ ăn
Tiêu chí chạm: quán phải cấu hình lại tài khoản đối tác
TIER 2 — phải cấu hình nhưng không bắt buộc; vẫn nhập tay như cũ được
Go/no-go: Thảo Release: 20/03 Đảo ngược: có
5. Đổi màu và vị trí nút "In tạm tính"
Ảnh hưởng: mọi thu ngân
Tiêu chí chạm: không có
TIER 3 — không đổi luồng; thu ngân tìm thấy trong vài giây
Release: 25/01 Đảo ngược: có
6. Sửa lỗi làm tròn tiền thừa khi chia hoá đơn
Ảnh hưởng: khoảng 70 quán gặp lỗi tháng trước
Tiêu chí chạm: chạm vào tiền
TIER 2 — nhỏ về kỹ thuật nhưng là tiền; CS phải gọi trước cho 70 quán
Go/no-go: Thảo Release: 18/01 Đảo ngược: có
ĐỔI TIER GIỮA CHỪNG
Số 4 từ tier 3 lên tier 2, ngày 14/01 — một đối tác yêu cầu quán nhập
lại mã cửa hàng, nên support chắc chắn sẽ bị hỏi.
Duyệt: anh Quân Ngày: 08/01/2027Chú ý dòng số 6. Một sửa lỗi ba dòng code, theo cảm giác là tier 3. Nhưng nó chạm vào tiền, và CS phải chủ động gọi 70 quán đã bị tính sai — nếu không, quán sẽ thấy số liệu đổi mà không ai giải thích. Phần A bắt được điều đó mà không ai cần nhớ. Ngược lại, dòng số 5 thay đổi thứ mọi thu ngân nhìn thấy hằng ngày, nhưng không đổi luồng và không cần báo trước ai — đội không lãng phí một buổi go/no-go cho nó.
Hiccups thường gặp và cách xử lý
| Hiccup | Vì sao xảy ra | Xử lý |
|---|---|---|
| Mọi thứ đều là tier 1 | Mỗi PM muốn việc của mình được coi trọng; tier bị dùng như nhãn tầm quan trọng | Tier quyết bằng tiêu chí ở phần A, kiểm được bằng có hoặc không. Quá ba tier 1 trong một quý thì xem lại tiêu chí, hoặc xem lại roadmap. |
| Đổi giá không có trên bảng | Đổi giá do kinh doanh hoặc tài chính làm, "chỉ là cấu hình" | Liệt kê từ mọi nguồn: roadmap, kế hoạch giá, kế hoạch của đối tác, yêu cầu pháp lý. |
| Tier theo công sức kỹ thuật | Đội quen ước lượng bằng story point | Hỏi "khách hàng thấy gì khác, và nếu hỏng thì ai chịu", không hỏi "mất bao lâu để làm". |
| Bảng lập xong không ai đọc | Gửi một lần đầu quý rồi thôi | Đưa link bảng vào mọi lời mời kickoff và go/no-go; support và sales đọc nó mỗi sáng thứ Hai. |
| Tier không đổi khi phạm vi đổi | Tier chốt ở kickoff rồi quên | Mỗi lần phạm vi thay đổi, mở lại dòng đó và ghi vào mục đổi tier giữa chừng. |
| Tiêu chí không bao giờ được sửa | Coi phần A là văn bản cố định | Mỗi retro hỏi tier có đúng không; một sự cố đến từ tier 3 nghĩa là phần A thiếu một điều kiện. |
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| PM | Chốt tier ở kickoff, và có câu trả lời viết sẵn khi bị hỏi vì sao một thay đổi nhỏ không cần đủ checklist — hoặc vì sao một thay đổi nhỏ lại cần |
| Product Owner | Biết dòng nào trong backlog sẽ cần thêm việc ngoài code — hướng dẫn, đào tạo, thông báo — để đưa vào sprint từ sớm |
| Head of Product | Giữ phần A, quyết go/no-go tier 1, và nhìn bảng để thấy quý nào đang dồn quá nhiều rủi ro vào cùng một tháng |
| Growth PM | Biết lần ra mắt nào đủ lớn để gắn chiến dịch, và lần nào nên đi lặng lẽ để không làm loãng thông điệp |
| Support / Sales lead | Biết trước tier 1 nào đang tới để giữ người trực và chuẩn bị câu trả lời cho khách |
Definition of done
- Phần A có tiêu chí kiểm được bằng có hoặc không, và có ngày sửa gần nhất.
- Mọi lần ra mắt trong quý có trên bảng, kể cả đổi giá và thay đổi cấu hình.
- Mỗi dòng có tiêu chí chạm, lý do một câu và một người quyết go/no-go có tên.
- Ô "đảo ngược được?" được điền cho mọi dòng tier 1 và tier 2.
- Support, sales và marketing đã nhận link bảng trong tuần đầu quý.
- Mỗi lần đổi tier giữa chừng được ghi lại kèm lý do.
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.