Backlog của tôi chưa bao giờ chỉ có 200 ý tưởng thông thường. Nó có tới 200 cuộc tranh luận gay gắt đang chờ một cuộc họp để bùng nổ. Bộ phận Bán hàng muốn tính năng dành cho doanh nghiệp lớn, bộ phận Hỗ trợ muốn sửa các cụm lỗi phát sinh, tôi thì muốn một "thay đổi nhỏ" mà bằng cách nào đó không bao giờ là nhỏ, và một khách hàng đã đề cập điều gì đó một lần nên nó cũng mang trọng lượng chính trị đáng kể. Sau đó, lộ trình phát triển (roadmap) đi theo tiếng nói lớn nhất trong phòng — hoặc tệ hơn, ý kiến của người được trả lương cao nhất.
Đây là lúc các khung xác định thứ tự ưu tiên sản phẩm (product prioritization frameworks) cứu nguy cho tôi. Không phải vì chúng biến những quyết định khó khăn trở nên dễ dàng, mà vì chúng buộc cả nhóm phải tranh luận dựa trên các tiêu chí rõ ràng thay vì cảm tính. Tôi vẫn đang học hỏi điều này, vì vậy hãy coi bài viết này như những ghi chép từ một người đang tìm tòi thực tế, không phải là phán quyết từ một chuyên gia.
Đọc qua các tài liệu hướng dẫn tham khảo, bài học thực tế đọng lại rất đơn giản: đừng thu thập 15 khung ưu tiên giống như thu thập các Pokémon năng suất. Hãy chọn khung phù hợp với giai đoạn sản phẩm của bạn. Một sản phẩm ở giai đoạn khám phá ý tưởng (discovery) không nên ưu tiên giống như một sản phẩm đang tăng trưởng nhanh (scaling), và một đội ngũ chưa có dữ liệu khách hàng không nên giả vờ chạy một mô hình giàu dữ liệu. Các nguồn tài liệu chính thống cũng định hình việc xác định thứ tự ưu tiên theo cùng một cách — đó là chọn phương pháp phù hợp với ngữ cảnh của bạn thay vì một khung "tốt nhất" duy nhất. Bài viết này cung cấp cho bạn một cách lựa chọn dựa trên từng giai đoạn.
Câu trả lời nhanh: chọn theo giai đoạn sản phẩm
Dưới đây là bản đồ thực tế.
| Giai đoạn sản phẩm | Khung phù hợp nhất | Lý do phù hợp |
|---|---|---|
| Khám phá / ý tưởng sớm | Tác động–Nỗ lực (Impact–Effort) hoặc Giá trị vs Độ phức tạp | Bạn cần sự rõ ràng nhanh chóng với dữ liệu hạn chế |
| Lập kế hoạch MVP | MoSCoW | Bạn cần quyết định những gì bắt buộc phải có bây giờ so với để sau |
| Sau MVP / có sức hút sớm | RICE | Bạn có đủ tín hiệu để so sánh phạm vi tiếp cận, tác động, độ tự tin và nỗ lực |
| Giai đoạn tăng trưởng | Điểm số có trọng số (Weighted Scoring) hoặc DVF | Bạn cần cân bằng giữa giá trị khách hàng, giá trị kinh doanh và khả năng thực thi |
| Sản phẩm trưởng thành | Mô hình Kano hoặc Điểm số cơ hội | Bạn cần cải thiện sự hài lòng, chứ không chỉ là giao thêm tính năng |
Đây là điểm cốt lõi. Câu hỏi không phải là "khung ưu tiên nào là tốt nhất?" Câu hỏi tốt hơn là: loại không chắc chắn nào chúng ta đang đối mặt ngay bây giờ? Các khung khác nhau sẽ làm giảm bớt các loại không chắc chắn khác nhau.
So sánh các khung: khi nào sử dụng, độ phức tạp, đội ngũ phù hợp nhất
| Khung ưu tiên | Khi nào sử dụng | Độ phức tạp | Đội ngũ phù hợp nhất |
|---|---|---|---|
| Tác động–Nỗ lực / Giá trị vs Độ phức tạp | Phân loại sớm khi bạn cần cái nhìn nhanh về giá trị so với độ khó khi xây dựng | Thấp | Nhà sáng lập, nhóm sản phẩm nhỏ, nhóm khám phá ý tưởng |
| MoSCoW | Lập kế hoạch phát hành hoặc MVP với phạm vi cố định hoặc có hạn chót | Thấp | Nhóm cần sự thống nhất nhanh chóng từ các bên liên quan |
| RICE | So sánh các mục backlog khi đã có một số dữ liệu về người dùng, nỗ lực và độ tự tin | Trung bình | PM quản lý backlog đang phát triển lớn |
| ICE | Chấm điểm nhanh khi tốc độ quan trọng hơn độ chính xác tuyệt đối | Thấp | Nhóm tăng trưởng, nhóm thử nghiệm, nhóm nhỏ di chuyển nhanh |
| Điểm số có trọng số (Weighted Scoring) | Khi nhiều tiêu chí kinh doanh và sản phẩm cùng quan trọng | Trung bình–Cao | Nhóm liên chức năng với các mục tiêu chiến lược rõ ràng |
| Bảng điểm DVF | Khi bạn phải cân bằng giữa tính mong muốn, tính khả thi và tính bền vững | Trung bình | Nhóm quyết định giữa các ván cược sản phẩm lớn, không chỉ là nhiệm vụ |
| Mô hình Kano | Khi sự hài lòng của khách hàng và nhận thức về tính năng là quan trọng | Trung bình–Cao | Nhóm có quyền truy cập vào nghiên cứu khách hàng |
| Điểm số cơ hội (Opportunity Scoring) | Tìm kiếm các nhu cầu quan trọng của khách hàng nhưng chưa được đáp ứng tốt | Trung bình–Cao | Nhóm trưởng thành có dữ liệu khảo sát hoặc phản hồi |
| Chi phí trì hoãn (Cost of Delay) | Khi việc chậm trễ có tác động rõ ràng về mặt tiền bạc | Cao | Nhóm có dữ liệu doanh thu, chi phí hoặc thời gian rõ ràng |
| Cây sản phẩm / Mua tính năng | Ưu tiên hợp tác với các bên liên quan hoặc khách hàng | Trung bình | Nhóm thiên về hội thảo, nhóm tư vấn khách hàng |
Giai đoạn 1: Khám phá ý tưởng — sử dụng Tác động–Nỗ lực hoặc Giá trị vs Độ phức tạp
Trong giai đoạn khám phá, bạn thường không có đủ dữ liệu cho việc chấm điểm phức tạp, và điều đó hoàn toàn ổn — đừng làm giả độ chính xác. Một ma trận 2x2 đơn giản sẽ hoạt động hiệu quả: giá trị cao/thấp đối đầu với nỗ lực cao/thấp. Điều này phản ánh góc phần tư giá trị so với nỗ lực mà nhiều nhóm bắt đầu sử dụng, so sánh lợi ích mong đợi với chi phí để bàn giao nó. Mục tiêu không phải là một lộ trình hoàn hảo — mà là tách biệt "các thử nghiệm rõ ràng tiếp theo" khỏi "các ý tưởng thú vị nhưng quá nặng nề lúc này."
Ví dụ
Khi xây dựng một sản phẩm CRM trên Notion, các ý tưởng của tôi có thể là: một trường nhắc nhở liên hệ lại, một công cụ tự động hóa email đầy đủ, các mẫu đường ống bán hàng theo ngành, và tùy chỉnh màu sắc dashboard. Chế độ xem Tác động–Nỗ lực nhanh chóng thường cho thấy nhắc nhở liên hệ lại là giá trị cao / nỗ lực thấp, tự động hóa email là giá trị cao / nỗ lực cao, mẫu theo ngành là trung bình/trung bình, và màu sắc là thấp/thấp. Kẻ chiến thắng không phải lúc nào cũng là ý tưởng lớn nhất — thường là ý tưởng dạy cho bạn nhanh nhất.
Giai đoạn 2: MVP — sử dụng MoSCoW để ngăn chặn lạm phát phạm vi
Lập kế hoạch MVP có một kẻ thù duy nhất: "chỉ một tính năng nữa thôi." MoSCoW phân loại các tính năng thành Must have (Bắt buộc phải có), Should have (Nên có), Could have (Có thể có) và Won't have (Chưa phải lúc này). Nó hoạt động tốt với một hạn chót cố định và nhu cầu về ngôn ngữ chung về phạm vi công việc. Mối nguy hiểm là mọi người đều cố gắng biến mọi thứ thành Must Have, vì vậy tôi sử dụng một bài kiểm tra nghiêm ngặt hơn:
Nếu sản phẩm vẫn có thể mang lại kết quả cốt lõi cho người dùng mà không có tính năng đó, thì đó không phải là Must Have.
Đau lòng? Có. Hữu ích? Chắc chắn rồi.
Ví dụ MVP
Đối với một template CRM — Must Have: database cơ hội, pipeline thương vụ, Bước tiếp theo, Ngày hành động tiếp theo, ghi chú hội thoại cơ bản. Should Have: giá trị thương vụ, database liên hệ, chế độ xem follow-up, lý do thất bại. Could Have: mẫu email viết sẵn, biểu đồ dashboard, ví dụ pipeline theo ngành. Won't Have: tự động hóa email phức tạp, dự báo doanh thu nâng cao, phân quyền nhiều nhóm. MoSCoW không hào nhoáng, nhưng nó bảo vệ phiên bản đầu tiên không trở thành một buffet tính năng hỗn độn.
Giai đoạn 3: Sau MVP — sử dụng RICE khi bạn có đủ tín hiệu
Một khi sản phẩm đã có người dùng, RICE bắt đầu phát huy tác dụng. Nó so sánh bốn yếu tố:
- Reach (Tầm tiếp cận) — bao nhiêu người dùng hoặc tài khoản sẽ bị ảnh hưởng bởi tính năng này?
- Impact (Tác động) — nó sẽ cải thiện kết quả ở mức độ nào?
- Confidence (Độ tự tin) — chúng ta chắc chắn đến mức nào, dựa trên các bằng chứng thu được?
- Effort (Nỗ lực) — việc này sẽ tốn bao nhiêu thời gian/công sức thiết lập?
Công thức phổ biến là Điểm RICE = (Reach × Impact × Confidence) / Effort. Vẻ đẹp của RICE là nó trừng phạt những ảo tưởng thông qua Độ tự tin (Confidence) và Nỗ lực (Effort) — một tính năng được hứa hẹn có tác động lớn nhưng bằng chứng yếu ớt sẽ không thể dễ dàng giành chiến thắng.
Ví dụ RICE từ đầu đến cuối
Chấm điểm ba ý tưởng CRM giả tưởng trong một tháng làm việc của nhóm:
| Tính năng | Tầm tiếp cận (Reach) | Tác động (Impact) | Độ tự tin (Confidence) | Nỗ lực (Effort) | Điểm RICE |
|---|---|---|---|---|---|
| Chế độ xem nhắc nhở follow-up | 800 người dùng | 2.0 | 80% | 2 tuần-người | 640 |
| Tùy chỉnh theme dashboard | 500 người dùng | 0.5 | 70% | 1 tuần-người | 175 |
| Trình tự động hóa email | 300 người dùng | 3.0 | 50% | 6 tuần-người | 75 |
Cách tính: nhắc nhở follow-up = (800 × 2.0 × 0.8) / 2 = 640; theme dashboard = (500 × 0.5 × 0.7) / 1 = 175; tự động hóa email = (300 × 3.0 × 0.5) / 6 = 75. Trình tự động hóa email nghe có vẻ rất ấn tượng, nhưng RICE đã phơi bày vấn đề — tầm tiếp cận thấp hơn, độ tự tin thấp hơn, và tốn nỗ lực lớn hơn nhiều. Điều đó không có nghĩa là không bao giờ xây dựng nó; điều đó có nghĩa là nó không nên ngẫu nhiên chiếm lấy lộ trình phát triển trước mắt.
Giai đoạn 4: Tăng trưởng — sử dụng Điểm số có trọng số hoặc DVF
Các sản phẩm ở giai đoạn tăng trưởng phải đối mặt với những đánh đổi khó khăn hơn. Bạn không còn chỉ hỏi "chúng ta có thể xây dựng cái này không?" mà còn phải hỏi xem khách hàng có muốn nó không, nó có hỗ trợ doanh nghiệp không, có phù hợp chiến lược không, và có giảm churn (tỷ lệ bỏ dịch vụ) không. Điểm số có trọng số (Weighted Scoring) cho phép bạn xác định các tiêu chí và trọng số — ví dụ: tác động khách hàng 30%, giá trị kinh doanh 30%, sự phù hợp chiến lược 20%, nỗ lực thực hiện 20%. DVF tập trung vào ba lăng kính:
- Desirability (Tính mong muốn): khách hàng có thực sự muốn nó không?
- Viability (Tính bền vững): nó có mang lại ý nghĩa kinh doanh cho chúng ta không?
- Feasibility (Tính khả thi): chúng ta có thể xây dựng nó với nguồn lực hiện có không?
Sử dụng Điểm số có trọng số khi nhóm của bạn có các tiêu chí chiến lược rõ ràng. Sử dụng DVF khi mọi người liên tục tranh luận từ các lăng kính khác nhau — một nhà thiết kế bảo vệ tính mong muốn, một nhà sáng lập bảo vệ tính bền vững, bộ phận kỹ thuật bảo vệ tính khả thi — và bạn cần cả ba trên cùng một bảng so sánh.
Giai đoạn 5: Sản phẩm trưởng thành — sử dụng Kano hoặc Điểm số cơ hội
Các sản phẩm trưởng thành thường cần sự đánh giá tốt hơn là cần thêm tính năng mới. Việc thêm hết tính năng này đến tính năng khác có thể làm sản phẩm trở nên nặng nề hơn trong khi mức độ hài lòng hầu như không thay đổi. Khung Kano giúp bạn thấy cách khách hàng cảm nhận về các tính năng — những kỳ vọng cơ bản, tính năng hiệu suất và những yếu tố gây bất ngờ thú vị — và nhắc nhở bạn rằng một số tính năng chỉ ngăn chặn sự bất mãn chứ không làm tăng sự hài lòng.
Điểm số cơ hội đi theo một góc độ khác: hỏi xem một nhu cầu quan trọng thế nào đối với khách hàng và họ hài lòng ra sao với giải pháp hiện tại. Cơ hội xuất hiện ở nơi tầm quan trọng thì cao mà mức độ hài lòng thì thấp. Công thức phổ biến là Cơ hội = Tầm quan trọng + (Tầm quan trọng - Sự hài lòng). Nếu khách hàng đánh giá "tìm nhanh các thương vụ bị đình trệ" ở tầm quan trọng 9 và mức hài lòng 4, phép tính sẽ là 9 + (9 - 4) = 14 — một khoảng cách cơ hội rất lớn. Hãy sử dụng những khung này khi bạn có phản hồi thực tế từ khách hàng; nếu chưa có, hãy đi thu thập trước khi giả vờ chấm điểm.
Thế còn các khung ICE, Chi phí trì hoãn, Cây sản phẩm và Mua tính năng?
Chúng hữu ích, nhưng tôi không coi chúng là lựa chọn mặc định cho mọi đội ngũ.
ICE
ICE chấm điểm Tác động (Impact), Độ tự tin (Confidence) và Độ dễ dàng (Ease) từ 1–10. Hãy sử dụng nó khi tốc độ quan trọng hơn và một chút thiếu chính xác là chấp nhận được — rất tuyệt cho các thử nghiệm tăng trưởng nhanh, nhưng yếu hơn cho các cam kết lộ trình dài hạn nghiêm túc.
Chi phí trì hoãn (Cost of Delay)
Khung này tập trung vào chi phí của việc không thực hiện tính năng ngay bây giờ. Hãy sử dụng khi thời điểm có rủi ro thực tế về tiền bạc — hợp đồng sắp hết hạn, cơ hội doanh thu theo mùa, hạn chót tuân thủ pháp luật. Bỏ qua nếu không ai có thể đưa ra ước tính tiền bạc thuyết phục, vì tiền giả định sẽ tạo ra sự chắc chắn giả tạo.
Cây sản phẩm (Product Tree)
Hoạt động tốt trong các buổi hội thảo (workshops): các bên liên quan đặt các ý tưởng như rễ, thân, cành hoặc lá để thảo luận về cách sản phẩm nên phát triển. Hãy sử dụng khi sự đồng thuận và mô hình tư duy chung quan trọng hơn việc xếp hạng số học.
Mua tính năng (Buy a Feature)
Khung này biến việc xác định thứ tự ưu tiên thành một bài tập giới hạn ngân sách — những người tham gia "tiêu" nguồn tài nguyên hạn chế vào các tính năng họ đánh giá cao. Hãy sử dụng khi bạn muốn các bên liên quan hoặc khách hàng bộc lộ sự đánh đổi thực sự, chứ không chỉ là sở thích. Mọi người đều nói mọi thứ đều quan trọng cho đến khi ngân sách của họ bị giới hạn.
Đề xuất thực tế của tôi
Nếu đội ngũ của bạn đang chìm nghỉm trong các khung ưu tiên, hãy đơn giản hóa. Trình tự tôi cố gắng thực hiện:
- Tác động–Nỗ lực để phân loại thô ban đầu
- MoSCoW để xác định phạm vi MVP hoặc bản phát hành cụ thể
- RICE để xếp hạng backlog một khi đã có đủ tín hiệu thực tế
- Điểm số có trọng số hoặc DVF cho các đánh đổi chiến lược lớn hơn
- Kano hoặc Điểm số cơ hội cho các sản phẩm trưởng thành đã có dữ liệu người dùng
Đừng sử dụng cả năm cùng một lúc, nếu không khung ưu tiên sẽ ngừng giúp đỡ và trở thành một lớp công việc hành chính khác. Hãy chọn một khung chính cho quyết định trước mắt của bạn, và chỉ thêm khung thứ hai nếu nó giúp vạch trần một loại rủi ro khác — RICE + MoSCoW để xếp hạng rồi khoanh vùng phạm vi, Kano + Chi phí trì hoãn để cân bằng giữa sự thích thú khách hàng và áp lực thời gian, Điểm số có trọng số + Tác động–Nỗ lực để căn chỉnh chiến lược rồi kiểm tra thực tế nỗ lực. Khung ưu tiên nên làm cho các quyết định rõ ràng hơn, chứ không tạo ra một cuộc họp khác bàn về chính cái khung đó.
Cách chạy quy trình ưu tiên trong Notion
Để có một hệ thống sản phẩm thực tế, hãy tạo một database tính năng với các thuộc tính này:
- Tên tính năng (Feature name)
- Vấn đề giải quyết (Problem)
- Nguồn (Source) (phản hồi khách hàng, bên liên quan, dữ liệu, chiến lược)
- Giai đoạn sản phẩm (Product stage)
- Khung ưu tiên áp dụng (Framework)
- Các trường Reach, Impact, Confidence, Effort
- Điểm RICE (RICE score)
- Danh mục MoSCoW (MoSCoW category)
- Trạng thái (Status)
- Quý lộ trình (Roadmap quarter)
- Ghi chú quyết định (Decision note)
Sau đó, tạo các chế độ xem: backlog sắp xếp theo điểm RICE, phạm vi MVP lọc theo MoSCoW, ma trận tác động cao / nỗ lực thấp, yêu cầu của các bên liên quan, các tính năng do khách hàng yêu cầu, và lộ trình. Giá trị thực sự là khả năng truy xuất nguồn gốc — khi có ai đó hỏi "tại sao chúng ta xây dựng cái này thay vì cái kia?" bạn có thể chỉ ra các tiêu chí, điểm số, ghi chú quyết định và tín hiệu thực tế từ khách hàng. Điều đó biến cuộc thảo luận lộ trình từ chính trị nội bộ thành tư duy sản phẩm thuần túy.
Điểm cốt lõi
Một khung xác định thứ tự ưu tiên không phải là một quan tòa ma thuật — nó là một công cụ tư duy. Những gì tôi liên tục tự nhắc nhở mình:
- Hãy chọn khung ưu tiên dựa trên giai đoạn sản phẩm, chứ không phải dựa vào mức độ phổ biến của nó.
- RICE hoạt động tốt nhất khi bạn có đủ tín hiệu để chấm điểm tầm tiếp cận, tác động, độ tự tin và nỗ lực thực hiện.
- Các sản phẩm trưởng thành cần sự hiểu biết về sự hài lòng và cơ hội thực tế từ khách hàng, chứ không chỉ là việc sắp xếp danh sách backlog.
Nếu lộ trình phát triển của bạn liên tục bị đánh bại bởi những ý kiến to tiếng nhất, vấn đề không nằm ở quy mô backlog của bạn — nó nằm ở hệ thống đưa ra quyết định của bạn.
👉 Nếu bạn muốn có lộ trình, thứ tự ưu tiên, backlog, phản hồi và các vấn đề cần sửa trong một không gian duy nhất, hãy khám phá Product Package - Smart.
Muốn xem hướng dẫn quản lý sản phẩm rộng hơn trước? Hãy đọc bài viết Quản lý sản phẩm trong Notion: Từ ý tưởng đến lộ trình phát triển.
Nguồn tài liệu tham khảo:
- Atlassian — Prioritization Frameworks: https://www.atlassian.com/agile/product-management/prioritization-framework
- Productboard — Product Prioritization Frameworks: https://www.productboard.com/glossary/product-prioritization-frameworks/
- Product School — Ultimate Guide to Product Prioritization: https://productschool.com/blog/product-fundamentals/ultimate-guide-product-prioritization
