Mở đầu — vì sao bài này quan trọng
Nếu bạn đang là Designer và muốn bước sang vai trò BA, thì hai tài liệu bạn buộc phải làm chủ chính là PRD (Product Requirements Document — tài liệu yêu cầu sản phẩm) và Business Case (luận chứng kinh doanh). Đây là hai "ngôn ngữ viết" mà một BA dùng để thuyết phục và điều phối cả một dự án.
Vì sao lại quan trọng đến vậy? Bởi vì trong thế giới Design, bạn thuyết phục bằng hình ảnh: một mockup đẹp, một prototype mượt mà, một flow rõ ràng. Nhưng khi bước sang bàn của những người ra quyết định — Product Owner, CTO, Giám đốc kinh doanh — họ không mua "cái đẹp". Họ mua giá trị: dự án này giải quyết vấn đề gì, tốn bao nhiêu, mang lại bao nhiêu, rủi ro ra sao, và tại sao phải làm bây giờ. PRD và Business Case chính là nơi bạn dịch trực giác thiết kế của mình thành lập luận mà lãnh đạo có thể "ký duyệt ngân sách".
Tin vui là: nền Design cho bạn một lợi thế khổng lồ mà nhiều BA "gốc kỹ thuật" không có. Bạn đã quen tư duy từ góc nhìn người dùng, quen đặt câu hỏi "vấn đề thật sự là gì", quen kể chuyện bằng cấu trúc. Ba thứ đó chính là bộ khung của một PRD tốt và một Business Case thuyết phục. Bài này sẽ giúp bạn chuyển hóa các kỹ năng sẵn có đó thành hai tài liệu chuẩn nghề BA.
Khái niệm cốt lõi
PRD là gì và nó khác gì với brief thiết kế
PRD là tài liệu mô tả sản phẩm/tính năng cần xây dựng làm được gì, cho ai, và theo tiêu chuẩn nào. Nó là cây cầu nối giữa "chúng ta muốn giải quyết vấn đề gì" (chiến lược) và "dev sẽ code cái gì" (kỹ thuật).
Một PRD tốt thường gồm các phần:
- Bối cảnh & vấn đề (Problem statement): Vì sao chúng ta làm cái này? Ai đang khổ vì điều gì?
- Mục tiêu & metrics thành công: Làm xong thì đo bằng chỉ số nào để biết là thành công?
- Đối tượng người dùng & use case: Ai dùng, trong tình huống nào.
- Phạm vi (Scope) và không thuộc phạm vi (Out of scope): Ranh giới rõ ràng để tránh "phình" dự án.
- Yêu cầu chức năng (Functional requirements): Hệ thống phải làm được những gì, thường mô tả theo hành vi.
- Yêu cầu phi chức năng (Non-functional): Tốc độ, bảo mật, khả năng chịu tải…
- Giả định & phụ thuộc (Assumptions & dependencies).
- Câu hỏi mở (Open questions).
Business Case là gì
Business Case trả lời một câu hỏi duy nhất mà lãnh đạo luôn hỏi: "Tại sao tôi nên đầu tư tiền và người vào việc này thay vì việc khác?"
Cấu trúc kinh điển của một Business Case:
- Vấn đề/cơ hội: Điều gì đang xảy ra khiến ta phải hành động.
- Các phương án (Options): Thường có ít nhất 3 — bao gồm cả phương án "không làm gì" (do nothing) để làm mốc so sánh.
- Chi phí (Cost): Tiền, người, thời gian.
- Lợi ích (Benefit): Định lượng được (tăng doanh thu, giảm chi phí) và định tính (thương hiệu, trải nghiệm).
- ROI / Payback period: Bao lâu thì hoàn vốn.
- Rủi ro & giả định.
- Khuyến nghị (Recommendation).
Sợi chỉ đỏ: từ "design rationale" sang "business rationale"
Là Designer, bạn đã quen bảo vệ quyết định của mình bằng design rationale — "tôi để nút CTA ở đây vì mắt người dùng quét theo hình chữ F". Kỹ năng lập luận đó chính là hạt giống của Business Case. Việc bạn cần học thêm chỉ là đổi đơn vị đo: từ "trải nghiệm tốt hơn" sang "giảm X% tỷ lệ rời bỏ, tương đương Y triệu đồng doanh thu/tháng".
Tình huống thực tế
Ví dụ 1 — Tiki: từ "giỏ hàng xấu" sang một PRD có sức thuyết phục
Giả định bạn là Designer tại một sàn thương mại điện tử kiểu Tiki, vừa chuyển sang BA. Team phát hiện tỷ lệ bỏ giỏ hàng ở bước thanh toán là 68%. Với tư duy Designer cũ, bạn sẽ viết: "Trang checkout rối, cần thiết kế lại cho gọn."
Với tư duy BA, bạn viết PRD:
- Problem statement: 68% người dùng thêm hàng vào giỏ nhưng không hoàn tất thanh toán; khảo sát cho thấy 3 nguyên nhân chính — phải tạo tài khoản mới (41%), phí ship hiện quá muộn (33%), quá nhiều bước (26%).
- Mục tiêu: Giảm tỷ lệ bỏ giỏ từ 68% xuống 55% trong 2 quý.
- Scope: Thêm guest checkout, hiển thị phí ship ngay ở trang giỏ, gộp 4 bước thành 2.
- Out of scope: Tích hợp ví điện tử mới (để phase sau).
- Functional requirements: "Khi người dùng chưa đăng nhập nhấn Thanh toán, hệ thống cho phép nhập email và tiếp tục mà không bắt tạo mật khẩu."
Ví dụ 2 — Một fintech VN: Business Case cho tính năng đăng nhập sinh trắc học
Giả định tại một ví điện tử kiểu MoMo, bạn muốn đề xuất thêm đăng nhập bằng vân tay/khuôn mặt. Nếu chỉ nói "sẽ tiện hơn cho người dùng", sếp sẽ gật gù rồi… để đó. Bạn làm Business Case:
- Vấn đề: 12% ticket chăm sóc khách hàng mỗi tháng liên quan đến quên mật khẩu; mỗi ticket tốn trung bình 15.000đ chi phí xử lý. Với ~50.000 ticket/tháng loại này, tổng chi phí ~750 triệu/tháng.
- Option A (do nothing): Giữ nguyên, chi phí tiếp tục leo thang.
- Option B: Đăng nhập sinh trắc học. Chi phí phát triển ~600 triệu (một lần), dự kiến giảm 60% ticket quên mật khẩu → tiết kiệm ~450 triệu/tháng.
- Option C: Chỉ thêm khôi phục mật khẩu qua OTP nhanh hơn. Rẻ hơn (~150 triệu) nhưng chỉ giảm ~20% ticket.
- ROI: Với Option B, payback period ~1,3 tháng; sau đó là lợi ích ròng.
Ví dụ 3 — Agency VN: PRD sai vì thiếu "Out of scope"
Một Designer chuyển BA tại agency ở TP.HCM viết PRD cho app đặt lịch spa. Anh mô tả rất kỹ giao diện đẹp nhưng quên phần Out of scope. Kết quả: client liên tục đòi thêm "tích hợp Zalo", "thêm loyalty point", "thêm chat" — và vì PRD không vẽ ranh giới, đội dev bị đội chi phí 40%, deadline trễ 6 tuần.
Bài học: Với Designer, việc "vẽ khung" là bản năng (bạn luôn có canvas với kích thước cố định). Hãy mang chính bản năng đó vào PRD: một tài liệu tốt định nghĩa rõ cái gì KHÔNG làm cũng quan trọng như cái gì làm.
Hướng dẫn từng bước
Bước 1 — Bắt đầu từ vấn đề, không phải giải pháp. Viết một Problem statement dài đúng 2–3 câu, có số liệu. Nếu bạn không có số, hãy đi tìm: khảo sát, analytics, phỏng vấn. Đây là kỹ năng user research bạn đã có, chỉ đổi mục tiêu đầu ra.
Bước 2 — Định nghĩa metrics thành công trước khi viết requirement. Hỏi: "Làm xong, tôi nhìn vào con số nào để biết là thắng?" Ví dụ: tỷ lệ chuyển đổi, thời gian hoàn thành tác vụ, số ticket giảm.
Bước 3 — Vẽ ranh giới Scope / Out of scope. Liệt kê rõ những gì thuộc và không thuộc phiên bản này. Đây là "phanh" chống phình dự án.
Bước 4 — Viết functional requirements theo hành vi. Dùng mẫu "Khi [tình huống], hệ thống [làm gì], để [mục đích]." Tránh mô tả màu sắc, font — đó là việc của design spec, không phải PRD.
Bước 5 — Ghi lại giả định, phụ thuộc và câu hỏi mở. Thành thật với những gì bạn chưa biết. BA giỏi là người quản lý sự không chắc chắn, không phải giả vờ biết hết.
Bước 6 — Dựng Business Case song song. Với mỗi đề xuất lớn, lập bảng: Option / Cost / Benefit / Risk. Luôn có "do nothing" làm mốc. Quy đổi lợi ích ra tiền hoặc thời gian bất cứ khi nào có thể.
Bước 7 — Tính ROI đơn giản. Công thức tối thiểu: ROI = (Lợi ích – Chi phí) / Chi phí. Và Payback = Chi phí một lần / Lợi ích ròng mỗi tháng. Không cần mô hình tài chính phức tạp — một phép chia rõ ràng đã đủ thuyết phục.
Bước 8 — Kết bằng một khuyến nghị dứt khoát. Đừng để lãnh đạo tự chọn. Nói rõ: "Tôi khuyến nghị Option B vì hoàn vốn trong 1,3 tháng và rủi ro thấp nhất."
Lỗi thường gặp & mẹo
- Lỗi: PRD biến thành bản mô tả UI. Designer hay sa đà tả giao diện. Mẹo: mỗi câu trong phần requirement, tự hỏi "câu này nói cái gì hệ thống làm hay nó trông thế nào?" Nếu là cái sau, chuyển sang tài liệu design spec riêng.
- Lỗi: Business Case không có phương án "do nothing". Không có mốc so sánh thì mọi con số đều vô nghĩa. Luôn thêm nó.
- Lỗi: Lợi ích chỉ định tính. "Trải nghiệm tốt hơn" không duyệt được ngân sách. Mẹo: ép mình quy đổi ít nhất một lợi ích ra tiền hoặc thời gian tiết kiệm.
- Lỗi: Requirement mơ hồ, không kiểm chứng được. "Hệ thống phải nhanh" — nhanh là bao nhiêu? Viết "tải trang <2 giây với 95% request".
- Mẹo tận dụng nền Design: Dùng kỹ năng visual của bạn để làm Business Case dễ đọc — một biểu đồ cột so sánh chi phí/lợi ích 3 phương án thuyết phục hơn 3 đoạn văn. Đây là lợi thế cạnh tranh của bạn so với BA gốc kỹ thuật.
- Mẹo con số: Khi chưa có dữ liệu chính xác, dùng ước lượng có giả định ghi rõ ("giả sử 50.000 ticket/tháng"). Ước lượng minh bạch tốt hơn im lặng.
Bài tập thực hành
- Viết mini-PRD (1 trang) cho một tính năng bạn từng thiết kế. Bắt buộc có đủ: Problem statement (có số), Mục tiêu đo được, Scope, Out of scope, và 3 functional requirements viết theo mẫu "Khi… hệ thống… để…".
- Dựng Business Case cho chính tính năng đó. Lập bảng 3 phương án (bao gồm "do nothing"), điền Cost – Benefit – Risk, và tính ROI cùng payback period. Quy đổi ít nhất một lợi ích ra tiền.
- Tự phản biện: Đưa PRD cho một người bạn không làm trong ngành đọc. Nếu họ không hiểu "vì sao đáng làm" chỉ sau phần Problem statement, hãy viết lại. Business Case tốt phải thuyết phục được cả người ngoài.
Tóm tắt
PRD và Business Case là hai công cụ viết biến bạn từ người "làm ra cái đẹp" thành người "chứng minh được giá trị". PRD trả lời sản phẩm phải làm gì, cho ai, đo bằng gì; Business Case trả lời tại sao đáng đầu tư, so với các phương án nào, hoàn vốn ra sao.
Nền Design cho bạn ba lợi thế: tư duy từ người dùng (viết Problem statement sắc bén), thói quen lập luận (biến design rationale thành business rationale), và khả năng trực quan hóa (làm Business Case dễ đọc). Thứ bạn cần bổ sung là kỷ luật con số: mọi lợi ích nên quy đổi ra tiền hoặc thời gian, mọi đề xuất nên có phương án "do nothing" để so sánh, mọi requirement nên kiểm chứng được.
Hãy nhớ nguyên tắc vàng: bắt đầu từ vấn đề, kết bằng khuyến nghị dứt khoát, và luôn vẽ ranh giới rõ ràng. Làm chủ hai tài liệu này, bạn đã nắm trong tay phần lớn công việc viết lách cốt lõi của một BA.