Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 11 — Apply EBM trong quyết định Backlog

PSPO II Advanced Product Ownership Bài 11/60

Mở đầu — vì sao bài này quan trọng

Đến đây, bạn đã đi qua bốn Key Value Area (KVA) của Evidence-Based Management: Current Value (CV), Unrealized Value (UV), Time to Market (T2M) và Ability to Innovate (A2I). Bạn đã biết từng nhóm metric nói lên điều gì. Nhưng có một câu hỏi mà rất nhiều Product Owner — kể cả những người đã thi đậu PSPO I — vẫn lúng túng: "Biết hết các metric đó rồi thì tôi DÙNG chúng để làm gì trong công việc hằng ngày?"

Câu trả lời ngắn gọn nhất: bạn dùng EBM để quyết định thứ tự Product Backlog. Đây chính là nơi lý thuyết về giá trị gặp gỡ hành động cụ thể. Mỗi sáng khi bạn refine backlog, mỗi lần bạn kéo một Product Backlog Item (PBI) lên trên một item khác, bạn đang ra một quyết định đầu tư. Và nếu quyết định đó không dựa trên bằng chứng về giá trị mà chỉ dựa trên "ai nói to nhất", "feature nào mới được nhắc trong cuộc họp", hay "cái nào dễ làm nhất" — thì bạn đang lãng phí năng lực đắt đỏ của cả Scrum Team.

Bài này dạy bạn một thứ rất thực dụng: một khung ra quyết định (decision framework) để chuyển trực giác mơ hồ thành lập luận có bằng chứng. Đây là kỹ năng tách biệt một Senior Product Owner khỏi một người chỉ biết "ghi chép yêu cầu". Khi bạn đứng trước executive hỏi "Tại sao chúng ta làm cái này trước cái kia?", bạn sẽ không trả lời bằng cảm tính, mà bằng một chuỗi lập luận xoay quanh CV, UV, T2M và A2I.

Khái niệm cốt lõi

Backlog ordering là một bài toán đầu tư, không phải bài toán liệt kê

Product Backlog không phải là danh sách công việc cần làm. Nó là một danh sách các giả thuyết về giá trị, được sắp xếp theo thứ tự đặt cược. Mỗi PBI ở trên cùng là một khoản đầu tư mà bạn tin sẽ mang lại lợi suất cao nhất ngay bây giờ, dựa trên những gì bạn biết được tới thời điểm này. EBM cung cấp ngôn ngữ để bạn biện minh cho thứ tự đó.

Điểm mấu chốt cần nhớ: bốn KVA không cạnh tranh nhau, chúng soi sáng cùng một quyết định từ bốn góc khác nhau. Một item có thể tệ về CV nhưng cực kỳ mạnh về A2I (ví dụ: nâng cấp hạ tầng để giảm thời gian build), và bạn vẫn nên ưu tiên nó.

Khung bốn câu hỏi cho mỗi PBI/Initiative

Với mỗi PBI hoặc initiative lớn trong backlog, hãy hỏi tuần tự bốn câu — tôi gọi đây là EBM Backlog Filter:

1. Item này có cải thiện Current Value (CV) không? — Tức là nó có làm tăng giá trị mà người dùng/khách hàng nhận được ngay tại thời điểm hiện tại không? Ví dụ: sửa một bug khiến 8% giao dịch thất bại, cải thiện tốc độ tải trang checkout, thêm tính năng mà khách hàng hiện tại đang trả tiền để chờ. CV cao = bảo vệ và gia tăng dòng giá trị đang chảy.

2. Item này có giúp nắm bắt Unrealized Value (UV) không? — Tức là nó có mở ra tiềm năng giá trị chưa được khai thác không? Đây là khoảng cách giữa giá trị hiện tại và giá trị tối đa nếu bạn đáp ứng hoàn hảo mọi nhu cầu của thị trường mục tiêu. Ví dụ: thâm nhập một phân khúc khách hàng mới, một thị trường địa lý mới, một nhu cầu chưa ai phục vụ. UV cao = cơ hội tăng trưởng lớn nhưng thường kèm rủi ro cao.

3. Item này có cải thiện Time to Market (T2M) không? — Nó có giúp bạn rút ngắn vòng học hỏi, giao giá trị nhanh hơn, thử nghiệm nhanh hơn không? Ví dụ: tự động hóa pipeline deploy, giảm thời gian release từ 2 tuần xuống 2 ngày, cắt bớt quy trình phê duyệt thủ công. T2M tốt = bạn học và phản hồi thị trường nhanh hơn đối thủ.

4. Item này có tăng Ability to Innovate (A2I) không? — Nó có loại bỏ những thứ cản trở khả năng tạo ra giá trị mới của team không? Ví dụ: trả nợ kỹ thuật (tech debt), gỡ bỏ tính năng chết không ai dùng nhưng vẫn tốn chi phí bảo trì, nâng cấp công cụ. A2I cao = team dành nhiều năng lực hơn cho việc tạo giá trị thay vì vật lộn với hệ thống.

Quy tắc kết hợp: không có công thức, chỉ có lập luận

Một sai lầm phổ biến là cố tạo ra một "điểm số EBM" duy nhất bằng cách cộng bốn câu trả lời lại. EBM không hoạt động như vậy. Nó không cho bạn một con số ma thuật để sắp xếp backlog tự động. Thay vào đó, nó buộc bạn phải nêu rõ bạn đang đặt cược vào KVA nào và tại sao.

Bối cảnh chiến lược (strategic context) quyết định bạn ưu tiên KVA nào:

  • Sản phẩm đang mất khách hàng vào tay đối thủ → ưu tiên T2M và CV.
  • Sản phẩm đã thống trị thị trường hiện tại nhưng tăng trưởng chững → ưu tiên UV.
  • Team liên tục giao hàng chậm, bug nhiều, ai cũng mệt mỏi → ưu tiên A2I, dù điều đó nghĩa là tạm gác feature mới.
Đây là lý do tại sao Product Goal và Product Strategy (mà bạn đã học ở các bài về strategy) phải đến trước backlog ordering. EBM Filter chỉ phát huy tác dụng khi bạn biết mình đang cố cải thiện điều gì.

Khái niệm "đặt cược nhỏ" (small bets)

EBM khuyến khích bạn không đổ hết năng lực vào một giả thuyết lớn chưa được kiểm chứng. Thay vào đó, hãy chia một initiative UV cao thành các "đặt cược nhỏ" — những lát cắt đủ nhỏ để bạn release, đo lường và học hỏi nhanh. Điều này kết nối UV (cơ hội) với T2M (tốc độ học) ngay trong cách bạn sắp xếp backlog.

Tình huống thực tế

Tình huống 1 — Ví TPBank/ví điện tử nội địa: khi CV và A2I giằng co

Hãy tưởng tượng một ví điện tử Việt Nam (gọi là MoMoNext, giả định) có 6 triệu người dùng hoạt động hằng tháng. Product Owner đứng trước một Sprint Planning với ba initiative lớn cạnh tranh nhau:

  • A — Thêm tính năng "mua trước trả sau" (BNPL): Sales và CEO rất phấn khích vì đối thủ vừa ra mắt. Đây là cơ hội UV lớn — mở phân khúc tín dụng tiêu dùng.
  • B — Sửa lỗi timeout khi liên kết thẻ ngân hàng: Hiện 11% người dùng mới bỏ cuộc ngay ở bước liên kết thẻ vì timeout. Đây thuần túy là CV.
  • C — Refactor module thanh toán đã 4 năm tuổi: Mỗi thay đổi nhỏ trong module này mất trung bình 9 ngày vì code chằng chịt. Đây là A2I.
Áp EBM Filter: Initiative A có UV cực cao nhưng — và đây là điểm quan trọng — nó cũng đụng vào chính module thanh toán cũ kỹ ở Initiative C. Nghĩa là nếu làm A trước C, mỗi lần chỉnh sửa sẽ chậm và rủi ro. Initiative B có CV rõ ràng, đo được: cứu 11% người dùng mới, ước tính khoảng 30.000 người/tháng.

Diễn giải: PO quyết định thứ tự B → C → A. B được làm trước vì nó "chảy máu giá trị" ngay lập tức, ROI rõ ràng và rẻ. C được đẩy lên trước A — dù C không trực tiếp tạo giá trị cho khách hàng — vì A2I thấp đang biến mọi đặt cược UV thành đắt đỏ và rủi ro. Sau khi C xong, Initiative A (BNPL) được triển khai theo kiểu "đặt cược nhỏ": ra mắt cho 5% người dùng để đo tỷ lệ chấp nhận trước khi mở rộng.

Bài học rút ra: A2I không tạo giá trị trực tiếp, nhưng bỏ qua nó sẽ khiến mọi cơ hội UV trong tương lai đắt hơn. EBM giúp PO biện minh được với CEO tại sao một việc "không thấy được" (refactor) lại đứng trước một feature hào nhoáng.

Tình huống 2 — Tiki và bài toán Time to Market

Một sàn thương mại điện tử (lấy cảm hứng từ Tiki) nhận thấy đối thủ tung khuyến mãi flash sale phản ứng theo thời gian thực, còn họ mất tới 5 ngày để cấu hình và chạy một chương trình tương tự — vì quy trình cần 3 phòng ban phê duyệt thủ công.

Product Owner có một backlog đầy feature merchant yêu cầu (đều là CV/UV nhỏ lẻ). Nhưng khi áp EBM Filter, câu hỏi T2M nổi bật: mọi cơ hội giá trị của chúng ta đang bị bóp nghẹt vì tốc độ phản ứng quá chậm. Dù mỗi feature merchant đều "có giá trị", chúng không quan trọng bằng việc gỡ nút thắt T2M.

PO sắp xếp lại backlog, đưa initiative "Self-service flash sale config" lên đầu — một công cụ cho phép đội vận hành tự cấu hình khuyến mãi mà không cần phê duyệt chéo. Kết quả sau hai Sprint: thời gian từ ý tưởng đến chạy chương trình giảm từ 5 ngày xuống 6 giờ.

Bài học rút ra: T2M không phải metric "kỹ thuật" của riêng đội dev. Nó là đòn bẩy chiến lược. Khi tốc độ học hỏi/phản ứng là điểm yếu cạnh tranh, một item cải thiện T2M có thể đáng giá hơn cả chục feature CV cộng lại. EBM cho PO ngôn ngữ để thấy điều này thay vì bị cuốn vào danh sách yêu cầu rời rạc.

Tình huống 3 — SaaS B2B và cái bẫy "khách hàng to nhất nói to nhất"

Một startup SaaS quản lý kho ở Đông Nam Á (giả định KhoSmart) có một khách hàng lớn chiếm 22% doanh thu liên tục đòi một tính năng báo cáo tùy chỉnh rất phức tạp. CEO muốn làm ngay để giữ chân họ.

PO áp EBM Filter một cách lạnh lùng:

  • CV: Tính năng này chỉ phục vụ 1 khách hàng. Giá trị hiện tại cho phần còn lại của tập khách hàng gần như bằng 0.
  • UV: Liệu nó có mở thị trường mới? Khảo sát cho thấy chỉ 3% khách hàng tiềm năng quan tâm. UV thấp.
  • T2M / A2I: Nó đòi hỏi một engine báo cáo riêng, làm phình code base, giảm A2I trong tương lai.
Diễn giải: Đây là một item có vẻ ưu tiên cao vì áp lực chính trị, nhưng bằng chứng EBM cho thấy nó là khoản đầu tư kém. PO không từ chối thẳng thừng mà đề xuất một "đặt cược nhỏ": một bản báo cáo cấu hình bằng filter có sẵn, đủ đáp ứng 80% nhu cầu khách hàng đó trong 1 Sprint, thay vì engine tùy chỉnh mất 6 Sprint. Khách hàng được giữ chân, A2I được bảo vệ.

Bài học rút ra: EBM là lá chắn giúp PO push back hợp lý trước áp lực. Khi bạn có thể nói "đây là dữ liệu CV, đây là dữ liệu UV", cuộc tranh luận chuyển từ cảm xúc sang bằng chứng — và đó là sân nhà của một Senior Product Owner.

Hướng dẫn từng bước

Đây là quy trình áp dụng EBM vào backlog ordering mà bạn có thể dùng ngay trong buổi refinement tiếp theo:

  • Xác định lại bối cảnh chiến lược. Trước khi đụng vào backlog, viết ra một câu: "KVA quan trọng nhất với sản phẩm chúng ta lúc này là ___, vì ___." Đây là kim chỉ nam cho mọi quyết định bên dưới.
  • Liệt kê các initiative/PBI lớn đang cạnh tranh. Đừng filter từng story nhỏ — hãy làm ở cấp initiative hoặc epic, nơi quyết định đầu tư thực sự diễn ra.
  • Chạy EBM Filter bốn câu cho từng item. Với mỗi item, ghi rõ tác động lên CV, UV, T2M, A2I. Dùng từ định tính (cao/trung bình/thấp/âm) kèm bằng chứng — số liệu, kết quả khảo sát, thời gian đo được. Tránh đoán mò.
  • Gắn item vào KVA chiến lược. Item nào tác động mạnh nhất lên KVA bạn xác định ở bước 1 sẽ được ưu tiên. Đây là nơi lập luận, không phải nơi cộng điểm.
  • Kiểm tra phụ thuộc và đòn bẩy. Hỏi: "Có item A2I/T2M nào đang làm các item khác đắt hơn không?" Nếu có, cân nhắc đưa nó lên trước (như Initiative C ở tình huống 1).
  • Chẻ nhỏ các đặt cược UV cao. Với item cơ hội lớn nhưng chưa chắc chắn, định nghĩa lát cắt nhỏ nhất để release và đo. Đặt lát cắt đó vào backlog, không phải toàn bộ initiative.
  • Định nghĩa metric sẽ đo sau khi giao. Mỗi item ở top backlog nên đi kèm câu hỏi "Sau khi làm xong, chúng ta kỳ vọng KVA nào thay đổi, đo bằng gì?" Đây là vòng lặp bằng chứng — EBM yêu cầu bạn kiểm chứng giả thuyết, không chỉ đặt cược rồi quên.
  • Sắp xếp lại và truyền đạt lập luận. Khi reorder backlog, chuẩn bị sẵn một câu giải thích dựa trên EBM cho mỗi vị trí top. Đây là thứ bạn mang ra Sprint Review và các cuộc họp stakeholder.

Lỗi thường gặp & mẹo

Lỗi 1 — Biến EBM thành công thức tính điểm. Nhiều người tạo bảng cho điểm 1–5 cho từng KVA rồi cộng lại sắp xếp. Điều này tạo cảm giác khách quan giả tạo và che giấu lập luận chiến lược. Mẹo: dùng EBM để cấu trúc cuộc tranh luận, không để thay thế nó.

Lỗi 2 — Bỏ quên A2I và T2M vì chúng "vô hình". CV và UV dễ thấy nên dễ được ưu tiên, còn refactor hay cải thiện pipeline luôn bị đẩy xuống. Hệ quả: sau một năm, team chậm như rùa. Mẹo: đặt một "ngân sách năng lực" cố định cho A2I/T2M mỗi quý (ví dụ 15–20% capacity), bảo vệ nó như bảo vệ một feature.

Lỗi 3 — Đo output thay vì outcome. Đừng để metric trở thành "số story hoàn thành" hay "số feature ship". EBM quan tâm đến giá trị nhận được, không phải khối lượng sản xuất ra. (Chủ đề outcome vs output sẽ được đào sâu ở bài riêng — ở đây chỉ cần nhớ nguyên tắc.)

Lỗi 4 — Áp filter mà không có dữ liệu thật. Nếu bạn trả lời bốn câu hỏi hoàn toàn bằng cảm tính, bạn chỉ đang trang trí trực giác bằng từ ngữ EBM. Mẹo: nếu không có bằng chứng cho một câu hỏi, hãy ghi nhận đó là khoảng trống và cân nhắc thêm một đặt cược nhỏ để thu thập bằng chứng (ví dụ một A/B test, một khảo sát).

Lỗi 5 — Quên đóng vòng lặp. PO sắp xếp backlog theo EBM nhưng không bao giờ quay lại đo xem giả thuyết đúng hay sai. Mẹo: mỗi Sprint Review, đối chiếu KVA kỳ vọng với KVA thực tế. Đây là phần "Evidence-Based" thực sự của EBM.

Bài tập thực hành

Bài tập 1 — Chạy EBM Filter trên backlog thật của bạn. Lấy 5 initiative/epic đang cạnh tranh ở đầu backlog hiện tại. Lập một bảng đơn giản với 4 cột (CV, UV, T2M, A2I). Với mỗi item, điền tác động (cao/trung bình/thấp/âm) kèm một mẩu bằng chứng cụ thể. Sau đó viết một câu lập luận cho thứ tự cuối cùng.

Bài tập 2 — Tìm item vô hình bị bỏ quên. Rà soát backlog và tìm ít nhất một item A2I hoặc T2M đang nằm tận đáy. Viết một đoạn 4–5 câu biện minh tại sao nó nên được nâng lên, dùng ngôn ngữ EBM, như thể bạn đang thuyết phục CEO.

Bài tập 3 — Tình huống push back. Tưởng tượng khách hàng lớn nhất của bạn đòi một feature chỉ phục vụ riêng họ. Hãy soạn một phản hồi dài 1 đoạn, dùng CV/UV/A2I để (a) thừa nhận mối quan tâm của họ, và (b) đề xuất một "đặt cược nhỏ" thay thế. Mục tiêu: từ chối khoản đầu tư kém mà vẫn giữ quan hệ.

Bài tập 4 — Đóng vòng lặp. Chọn một item bạn đã giao trong 2 Sprint gần nhất. Bạn đã kỳ vọng KVA nào thay đổi? Bạn có đo nó không? Nếu chưa, định nghĩa metric bạn lẽ ra nên đo và cách lấy nó.

Tóm tắt

Backlog ordering là nơi EBM ngừng là lý thuyết và trở thành công cụ ra quyết định hằng ngày của Product Owner. Với mỗi initiative, hãy chạy EBM Filter bốn câu: nó có cải thiện Current Value, nắm bắt Unrealized Value, rút ngắn Time to Market, hay tăng Ability to Innovate không? Quan trọng nhất: EBM không cho bạn một công thức điểm số — nó buộc bạn nêu rõ mình đang đặt cược vào KVA nào và dựa trên bằng chứng gì, trong khuôn khổ chiến lược sản phẩm.

Ba bài học cốt lõi từ các tình huống: (1) đừng bỏ quên A2I và T2M chỉ vì chúng vô hình — chúng quyết định chi phí của mọi cơ hội tương lai; (2) khi tốc độ học hỏi là điểm yếu cạnh tranh, một item T2M có thể đáng giá hơn cả chục feature; (3) EBM là lá chắn giúp bạn push back hợp lý trước áp lực chính trị, chuyển tranh luận từ cảm xúc sang bằng chứng. Và cuối cùng, đừng quên đóng vòng lặp: sắp xếp backlog theo giả thuyết về giá trị chỉ có ý nghĩa khi bạn quay lại đo và học từ kết quả thực tế.