Cross-functional team không có decision rights chỉ là một cuộc họp đông người hơn.

Nhiều ngân hàng đã có Product Owner, squad, agile ceremony và backlog. Nhưng quyết định về pricing, policy, data, risk, architecture và vận hành vẫn nằm ở các chuỗi phê duyệt khác nhau. Đội sản phẩm chịu trách nhiệm delivery nhưng không có quyền thay đổi những yếu tố quyết định outcome.

Digital product operating model cần trả lời ba câu hỏi: ai quyết định, ai chịu trách nhiệm kết quả và bằng chứng nào được dùng để thay đổi hướng đi?

Project model và product model khác nhau ở đâu?

Project có phạm vi, ngân sách và ngày kết thúc. Product có customer, outcome, lifecycle và chi phí vận hành liên tục.

Trong project model, thành công thường là giao đúng scope. Trong product model, thành công là tạo và duy trì outcome. Scope có thể thay đổi khi bằng chứng cho thấy một giải pháp không hiệu quả.

Ngân hàng không thể bỏ hoàn toàn project governance, đặc biệt với chương trình lớn và yêu cầu kiểm soát. Nhưng cần phân biệt tài trợ cho năng lực/sản phẩm với phê duyệt một gói triển khai.

Sáu decision rights phải rõ

1. Customer và problem

Ai xác định phân khúc, nhu cầu ưu tiên và bằng chứng rằng vấn đề đáng giải quyết? Product team phải có quyền nghiên cứu và kiểm chứng, không chỉ nhận yêu cầu.

2. Outcome và metric

Ai chọn KPI, baseline và target? Nếu KPI được quyết định sau khi giải pháp đã chọn, đo lường dễ trở thành hoạt động chứng minh thành công.

3. Proposition và pricing

Ai quyết định giá trị, phí, điều kiện và trade-off? Đây là quyết định business, nhưng cần dữ liệu từ customer, finance, risk và operations.

4. Risk và control

Risk appetite thuộc thẩm quyền phù hợp; product team phải thiết kế control trong journey. Mô hình tốt phân biệt rule bắt buộc với phương án triển khai, để đội có không gian tìm cách đáp ứng tốt hơn.

5. Architecture và data

Enterprise standard bảo vệ khả năng mở rộng và an toàn. Tuy nhiên, architecture governance cần đưa ra guardrail và thời gian quyết định rõ, không biến mọi thay đổi thành exception process kéo dài.

6. Release và operation

Ai có quyền go-live, rollback và dừng? Product owner không thể chịu trách nhiệm trải nghiệm nếu không nhìn thấy incident, run cost và service performance.

Product trio là chưa đủ trong ngân hàng

Mô hình product trio gồm product, design và engineering hữu ích, nhưng banking product cần thêm risk/control và operations ngay từ đầu. Một “product core team” có thể gồm:

  • Product lead: outcome, roadmap và prioritization.
  • Business/process owner: operating model và benefit.
  • Design/research: customer evidence và service design.
  • Engineering/architecture: solution và technical health.
  • Data/analytics: instrumentation, insight và model.
  • Risk/compliance/legal: policy, challenge và control design.
  • Operations/service: run readiness, exception và recovery.

Không phải mọi người đều toàn thời gian, nhưng decision cadence và trách nhiệm phải được thiết kế.

Funding nên theo horizon

Một business case duy nhất cho ba năm dễ tạo cảm giác chắc chắn giả. Có thể chia tài trợ theo ba horizon:

Discover

Tài trợ nhỏ để kiểm chứng problem, outcome, constraint và desirability. Kết quả là bằng chứng, không phải số lượng màn hình.

Validate

Xây lát cắt end-to-end đủ để đo adoption, control và economics. Có cohort, baseline và exit criteria.

Scale

Đầu tư mở rộng capability, resilience, operating model và migration. Quyết định dựa trên bằng chứng từ validate.

Mỗi horizon có quyền dừng. Việc dừng một giả định sai là giá trị của governance, không phải thất bại của đội.

Product health cần cân bằng bốn nhóm chỉ số

  • Customer outcome: completion, time, error, satisfaction có ngữ cảnh.
  • Business outcome: revenue, cost, risk reduction, relationship depth.
  • Operational health: SLA, exception, complaint, run cost.
  • Technical health: reliability, security, debt, change failure, dependency.

Nếu chỉ đo adoption, đội có thể tăng sử dụng bằng notification và incentive nhưng làm xấu economics hoặc trust. Nếu chỉ đo revenue, đội có thể đẩy offer không phù hợp. Scorecard phải phản ánh toàn hệ thống.

Governance cadence thay cho governance event

Phê duyệt một lần ở đầu và review khi có sự cố là không đủ. Product governance có thể gồm:

  • Hàng tuần: outcome signal, experiment và operational issue.
  • Hàng tháng: product health, risk, benefit và dependency.
  • Hàng quý: chiến lược, funding, capability và quyết định scale/stop.

Mỗi cuộc họp cần decision log: quyết định gì, dựa trên bằng chứng nào, owner và ngày xem lại. Điều này giảm việc lặp lại tranh luận và giữ được trí nhớ tổ chức.

Một dấu hiệu operating model chưa thật

Product Owner được yêu cầu “chịu trách nhiệm end-to-end” nhưng không được thay đổi process, KPI, chính sách, nhân lực vận hành hoặc thứ tự dependency. Đây là accountability không đi cùng authority.

Giải pháp không phải trao toàn quyền cho một cá nhân. Giải pháp là công khai decision rights, service level của governance và cơ chế escalation.

Câu hỏi dành cho Ban điều hành

Khi một product không đạt outcome, ai có quyền thay đổi proposition, process và funding? Nếu câu trả lời cần một steering committee đặc biệt được triệu tập sau nhiều tuần, tổ chức đang vận hành project với tên gọi product.

Product operating model tốt không làm ngân hàng ít kiểm soát hơn. Nó đưa kiểm soát vào đúng nhịp quyết định, gắn quyền với trách nhiệm và biến bằng chứng thành cơ sở phân bổ vốn.

Nguồn tham khảo

Disclosure: Bài viết thể hiện quan điểm cá nhân của tác giả và không đại diện cho bất kỳ tổ chức nào mà tác giả đang hoặc sẽ làm việc.

LDT

Lê Duy Tú
Banking · Digital Product · Wealth Management