Quản lý Ngân sách và Business Case

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

Có một định kiến rất phổ biến trong giới làm sản phẩm: "Tiền bạc, ngân sách là việc của Finance, của sếp, không phải của Product Owner (PO)". Tôi từng tin như vậy trong những năm đầu sự nghiệp, cho đến khi một tính năng mà tôi tâm huyết bị "đóng băng" giữa chừng. Lý do không phải vì nó tệ, mà vì tôi không thể trả lời được câu hỏi đơn giản của ban giám đốc: "Bỏ ra 2 tỷ để làm cái này thì mấy năm thu hồi vốn?"

Đó là bài học đắt giá. Trong thực tế, một Product Owner giỏi không chỉ là người hiểu khách hàng và viết user story sắc bén, mà còn phải là người biết "nói chuyện bằng ngôn ngữ tiền bạc" với cấp lãnh đạo. Ngân sách là nguồn lực hữu hạn. Mỗi đồng bạn xin để phát triển tính năng A là một đồng không được dùng cho tính năng B hoặc cho marketing. Người ra quyết định cấp vốn (executive, ban đầu tư) luôn nhìn sản phẩm dưới góc độ: "Khoản đầu tư này sinh lời ra sao?"

Bài học này trang bị cho bạn ba năng lực cốt lõi và rất thực dụng: (1) lập kế hoạch tài chính cho sản phẩm — biết tiền đi đâu, về đâu; (2) tính toán ROI (Return on Investment) và các chỉ số đầu tư để chứng minh giá trị; và (3) xây dựng một business case thuyết phục để xin được nguồn lực và bảo vệ ưu tiên của bạn. Khi nắm vững những điều này, bạn không còn là người "đi xin tiền" mà trở thành đối tác chiến lược của lãnh đạo. Đó là ranh giới phân biệt một PO làm việc và một PO dẫn dắt.

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

Ngân sách sản phẩm gồm những gì?

Trước khi tính lời lãi, bạn phải hiểu tiền sản phẩm chảy vào đâu. Ngân sách sản phẩm thường chia làm hai nhóm lớn:

• CapEx (Capital Expenditure — chi phí đầu tư): Những khoản chi tạo ra tài sản dài hạn, ví dụ chi phí phát triển một nền tảng mới, mua bản quyền phần mềm dài hạn, xây dựng hạ tầng. Về mặt kế toán, CapEx được khấu hao dần qua nhiều năm.
• OpEx (Operational Expenditure — chi phí vận hành): Những khoản chi thường xuyên để duy trì sản phẩm sống: lương đội ngũ, chi phí cloud hằng tháng (AWS, GCP), phí license SaaS, chi phí hỗ trợ khách hàng, marketing duy trì.

Với một PO, phần lớn ngân sách bạn "động chạm" tới là chi phí phát triển (development cost). Cách ước tính phổ biến và dễ hiểu nhất là theo năng lực đội ngũ (team capacity): nếu một đội Scrum gồm 6 người với chi phí trung bình mỗi người (gồm lương, bảo hiểm, văn phòng, công cụ) là 40 triệu đồng/tháng, thì "đốt" của bạn khoảng 240 triệu/tháng. Một tính năng cần 3 sprint (khoảng 1,5 tháng) sẽ tiêu tốn xấp xỉ 360 triệu đồng. Con số này gọi là chi phí cơ hội phát triển — và nó là điểm khởi đầu của mọi business case.

ROI và các chỉ số tài chính bạn phải thuộc

ROI (Return on Investment — tỷ suất hoàn vốn) là chỉ số đơn giản nhất nhưng quyền lực nhất:

> ROI = (Lợi ích ròng − Chi phí đầu tư) / Chi phí đầu tư × 100%

Ví dụ: bạn đầu tư 500 triệu, tính năng tạo ra 800 triệu lợi ích trong năm đầu, thì ROI = (800 − 500) / 500 = 60%. Nghĩa là mỗi đồng bỏ ra sinh thêm 0,6 đồng.

Ngoài ROI, có ba chỉ số nữa mà lãnh đạo rất hay hỏi:

• Payback Period (Thời gian hoàn vốn): Bao lâu thì thu hồi đủ vốn đã bỏ ra. Nếu đầu tư 500 triệu và mỗi tháng tính năng mang về 100 triệu lợi nhuận tăng thêm, payback period là 5 tháng. Lãnh đạo thích con số này vì nó trực quan và liên quan trực tiếp tới rủi ro: hoàn vốn càng nhanh, rủi ro càng thấp.
• NPV (Net Present Value — giá trị hiện tại ròng): Khái niệm cốt lõi là "một đồng hôm nay có giá hơn một đồng năm sau" vì tiền có thể sinh lãi và vì lạm phát. NPV quy đổi tất cả dòng tiền tương lai về giá trị hôm nay theo một tỷ lệ chiết khấu (discount rate). NPV dương nghĩa là dự án đáng làm.
• Break-even point (Điểm hòa vốn): Mức doanh thu hoặc số khách hàng tối thiểu để dự án không lỗ.

Bạn không cần là chuyên gia tài chính. Nhưng khi đứng trước hội đồng đầu tư, bạn phải nói được: "ROI dự kiến năm đầu là 60%, hoàn vốn trong 8 tháng, NPV dương." Câu nói đó có sức nặng gấp mười lần "tính năng này khách hàng rất thích".

Business Case — bộ hồ sơ thuyết phục

Business case là tài liệu trả lời câu hỏi: "Tại sao tổ chức nên đầu tư vào việc này thay vì việc khác?" Một business case tốt không phải là bản kế hoạch kỹ thuật, mà là một lập luận đầu tư. Cấu trúc chuẩn gồm:

• Vấn đề / Cơ hội: Đang đau ở đâu, hoặc cơ hội thị trường nào đang mở ra.
• Giải pháp đề xuất: Bạn định làm gì (ở mức khái quát, không sa đà kỹ thuật).
• Chi phí: Cần bao nhiêu tiền, nhân lực, thời gian.
• Lợi ích: Định lượng được (tăng doanh thu, giảm chi phí, giảm churn) và không định lượng được (thương hiệu, trải nghiệm).
• Phân tích tài chính: ROI, payback, NPV.
• Rủi ro và phương án thay thế: Bao gồm cả phương án "không làm gì" (do nothing) để so sánh.

Mẹo của tôi: phần lợi ích phải gắn với một giả định (assumption) rõ ràng. Đừng viết "tăng doanh thu 30%". Hãy viết "nếu tỷ lệ chuyển đổi tăng từ 2% lên 2,6%, với lưu lượng hiện tại 100.000 lượt/tháng và giá trị đơn trung bình 500 nghìn, doanh thu tăng thêm khoảng 300 triệu/tháng". Lãnh đạo có thể không đồng ý với con số, nhưng họ sẽ tranh luận về giả định — và đó chính là cuộc trò chuyện bạn muốn có.

Tình huống thực tế

Tình huống 1: Sàn TMĐT đầu tư tính năng "mua trước trả sau"

Một sàn thương mại điện tử tại Việt Nam (tạm gọi ShopViet) cân nhắc tích hợp tính năng BNPL (Buy Now Pay Later — mua trước trả sau). PO của đội thanh toán xây dựng business case như sau:

• Chi phí: Đội 7 người làm trong 4 tháng, chi phí phát triển khoảng 1,1 tỷ đồng. Phí tích hợp đối tác tài chính và vận hành năm đầu khoảng 400 triệu. Tổng đầu tư năm đầu: 1,5 tỷ.
• Lợi ích (giả định): Dữ liệu cho thấy giỏ hàng bị bỏ rơi nhiều ở nhóm đơn giá trị cao. Giả định BNPL nâng tỷ lệ chuyển đổi nhóm này thêm 1,5%, cộng với việc khách dùng BNPL có giá trị đơn trung bình cao hơn 35%. Ước tính doanh thu tăng thêm 200 triệu/tháng, biên lợi nhuận gộp 25% → lợi nhuận tăng thêm 50 triệu/tháng, tức 600 triệu/năm.

PO trình bày thẳng thắn: ROI năm đầu = (600 − 1.500)/1.500 = −60%, tức lỗ trong năm đầu. Nhưng payback period rơi vào khoảng tháng thứ 30, và từ năm thứ hai trở đi chi phí phát triển không còn, lợi ích tích lũy khiến NPV ba năm dương.

Bài học: Một business case trung thực dám trình ra cả con số xấu. Chính sự minh bạch về payback period dài đã giúp ban lãnh đạo ra quyết định đúng: phê duyệt nhưng kèm điều kiện đánh giá lại sau 6 tháng. PO không bán giấc mơ, PO bán một khoản đầu tư có rủi ro được lượng hóa.

Tình huống 2: SaaS B2B chọn giữa hai tính năng tranh nhau ngân sách

Một startup SaaS quản lý nhân sự ở Đông Nam Á (tạm gọi HRNow) chỉ có ngân sách cho một dự án lớn trong quý. Hai lựa chọn:

• Tính năng A — Chấm công nhận diện khuôn mặt: Chi phí 600 triệu. Khảo sát cho thấy 12 khách hàng doanh nghiệp đang chờ tính năng này, mỗi khách trả thêm 5 triệu/tháng nếu có → 60 triệu/tháng, tức 720 triệu/năm. ROI năm đầu = 20%.
• Tính năng B — Tích hợp tính lương tự động: Chi phí 800 triệu. Giúp giảm churn: hiện mỗi tháng mất 3 khách (giá trị mỗi khách 8 triệu/tháng). Giả định tính năng này giảm một nửa số churn → giữ lại 1,5 khách/tháng × 8 triệu × 12 = 144 triệu/năm giá trị giữ chân, cộng thêm khả năng upsell.

Nhìn ROI thuần, tính năng A thắng. Nhưng PO của HRNow lập luận sâu hơn: doanh thu giữ chân (retention) ổn định và lặp lại hằng tháng, trong khi 12 khách hàng chờ tính năng A có thể chỉ là lời hứa miệng. PO áp dụng phân tích kịch bản (scenario): nếu chỉ 50% khách hứa thực sự trả tiền, ROI của A tụt xuống dưới 0.

Bài học: ROI cao nhất chưa chắc là lựa chọn đúng. Chất lượng của lợi ích (lặp lại hay một lần, chắc chắn hay phỏng đoán) quan trọng không kém độ lớn. PO giỏi phải đặt các con số trong bối cảnh rủi ro, không chỉ so sánh con số trần trụi.

Tình huống 3: Ngân hàng số kiểm soát chi phí cloud phình to

Một ngân hàng số (tạm gọi NeoBank) phát hiện chi phí cloud OpEx tăng từ 300 triệu lên 520 triệu/tháng chỉ trong một năm, ăn mòn lợi nhuận. PO phụ trách nền tảng được giao xây business case cho một dự án tối ưu hạ tầng.

• Chi phí: Đội 4 người làm 2 tháng tối ưu, khoảng 320 triệu.
• Lợi ích: Giảm 30% chi phí cloud → tiết kiệm khoảng 156 triệu/tháng.
• Payback: Chỉ ~2 tháng. ROI năm đầu lên tới hơn 480%.

Bài học: Không phải business case nào cũng nói về tính năng mới. Lợi ích "giảm chi phí" (cost saving) thường có ROI rực rỡ và payback cực ngắn vì nó tác động trực tiếp tới dòng tiền, ít phụ thuộc giả định thị trường. Một PO trưởng thành biết rằng đôi khi khoản đầu tư sinh lời nhất lại nằm ở việc dọn dẹp bên trong, chứ không phải xây thêm cái mới.

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

Đây là quy trình tôi dùng mỗi khi cần xây dựng một business case cho tính năng hoặc sáng kiến sản phẩm:

• Bước 1 — Làm rõ vấn đề và mục tiêu kinh doanh. Viết một câu duy nhất: "Chúng ta đang giải quyết vấn đề gì, và nó liên quan tới mục tiêu kinh doanh nào (doanh thu, chi phí, giữ chân, mở rộng thị phần)?" Nếu không gắn được vào mục tiêu kinh doanh, hãy dừng lại.

• Bước 2 — Ước tính chi phí. Tính chi phí phát triển theo team capacity (số người × chi phí/người × thời gian), cộng chi phí vận hành dự kiến (cloud, license, hỗ trợ). Đừng quên chi phí ẩn: đào tạo, marketing ra mắt, bảo trì.

• Bước 3 — Định lượng lợi ích theo giả định minh bạch. Mỗi con số lợi ích phải có công thức và giả định đứng sau. Ghi rõ "giả định" để người đọc có thể chất vấn.

• Bước 4 — Tính các chỉ số tài chính. Tối thiểu: ROI và payback period. Với dự án lớn hoặc dài hạn, thêm NPV. Trình bày theo nhiều kịch bản: lạc quan, cơ sở (base case), thận trọng.

• Bước 5 — Phân tích rủi ro và phương án thay thế. Luôn đưa phương án "không làm gì" làm mốc so sánh. Liệt kê 2–3 rủi ro lớn nhất và cách giảm thiểu.

• Bước 6 — Đề xuất quyết định rõ ràng. Kết thúc bằng một khuyến nghị dứt khoát: "Đề xuất phê duyệt với ngân sách X, đánh giá lại sau Y tháng." Đừng để lãnh đạo phải tự suy diễn bạn muốn gì.

• Bước 7 — Theo dõi sau phê duyệt. Business case không chết sau khi được duyệt. Đặt các mốc kiểm tra: lợi ích thực tế có khớp giả định không? Đây là cách bạn xây uy tín cho những lần xin ngân sách sau.

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

Lỗi 1 — Thổi phồng lợi ích, giấu nhẹ chi phí. Đây là cái bẫy tự sát. Khi lợi ích thực tế không đạt, uy tín của bạn sụp đổ và lần sau không ai tin business case của bạn nữa. Mẹo: luôn trình bày base case (kịch bản cơ sở) thận trọng, để dành kịch bản lạc quan như phần thưởng.

Lỗi 2 — Quên chi phí vận hành dài hạn. Nhiều PO chỉ tính chi phí phát triển một lần mà quên rằng tính năng cần được nuôi sống: cloud, hỗ trợ, bảo trì kỹ thuật (technical debt). Một tính năng "rẻ để xây" có thể "đắt để nuôi".

Lỗi 3 — Bỏ qua chi phí cơ hội. Đầu tư vào A đồng nghĩa từ chối B. Business case mạnh luôn so sánh tương quan, không chỉ đứng một mình.

Lỗi 4 — Dùng quá nhiều thuật ngữ tài chính phức tạp. Nếu lãnh đạo không hiểu NPV, đừng ép họ. Hãy quy về ngôn ngữ trực quan: "bỏ ra 1,5 tỷ, sau 8 tháng bắt đầu có lãi."

Mẹo vàng: Hãy biến mỗi user story lớn thành một mini business case một dòng. Ví dụ: "Tính năng X tốn ~3 sprint (~360 triệu), kỳ vọng giảm churn 0,5%/tháng (~giữ lại 40 triệu/tháng)." Thói quen này khiến cả đội tư duy theo giá trị, không chỉ theo tính năng.

Mẹo thứ hai: Hợp tác sớm với bộ phận Finance. Họ có sẵn discount rate, chuẩn khấu hao và mẫu báo cáo của công ty. Một PO biết "mượn" chuyên môn tài chính sẽ ra business case nhanh và đáng tin hơn nhiều.

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

Bài tập 1 — Tính ROI và payback. Đội của bạn muốn xây tính năng đề xuất sản phẩm cá nhân hóa. Chi phí phát triển: đội 5 người, chi phí 35 triệu/người/tháng, làm trong 3 tháng. Chi phí vận hành năm đầu: 150 triệu. Lợi ích kỳ vọng: tăng doanh thu thêm 120 triệu/tháng với biên lợi nhuận gộp 30%. Hãy tính: tổng đầu tư năm đầu, lợi nhuận tăng thêm/năm, ROI năm đầu và payback period (theo tháng).

Bài tập 2 — Viết mini business case. Chọn một sản phẩm bạn đang dùng hằng ngày. Đề xuất một tính năng mới và viết business case ngắn (1 trang) theo đủ 6 phần: vấn đề, giải pháp, chi phí, lợi ích (kèm giả định), phân tích tài chính, rủi ro. Bắt buộc có một phương án "không làm gì".

Bài tập 3 — Phân tích kịch bản. Lấy Tình huống 2 (HRNow). Giả định chỉ 50%, rồi 70%, rồi 100% khách hàng hứa thực sự trả tiền cho tính năng A. Tính lại ROI ở mỗi kịch bản và viết một khuyến nghị: nên chọn A hay B, vì sao?

Tóm tắt

Quản lý ngân sách và business case là kỹ năng biến một Product Owner từ "người thực thi tính năng" thành "đối tác đầu tư của lãnh đạo". Bạn cần hiểu tiền sản phẩm chảy đi đâu (CapEx, OpEx, chi phí phát triển theo team capacity), thành thạo các chỉ số đầu tư cốt lõi (ROI, payback period, NPV, break-even), và biết dệt chúng thành một business case minh bạch — luôn gắn lợi ích với giả định rõ ràng và luôn so sánh với phương án "không làm gì".

Ba tình huống thực tế cho thấy: một business case trung thực dám trình ra cả con số xấu (ShopViet), ROI cao nhất chưa chắc là lựa chọn đúng khi chất lượng lợi ích khác nhau (HRNow), và đôi khi khoản đầu tư sinh lời nhất là tối ưu chi phí nội bộ chứ không phải xây cái mới (NeoBank). Hãy bắt đầu ngay từ hôm nay: biến mỗi tính năng lớn thành một mini business case một dòng. Khi bạn nói được bằng ngôn ngữ tiền bạc, cánh cửa ngân sách — và cả sự tín nhiệm của lãnh đạo — sẽ mở ra với bạn.