Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm việc với một Product Manager (PM), hoặc chính bạn là PM, hẳn bạn hiểu nỗi ám ảnh mang tên PRD — Product Requirements Document, tài liệu mô tả yêu cầu sản phẩm. Đây là văn bản mà PM viết ra để đội ngũ engineer, designer, QA và cả sếp cùng hiểu một tính năng sẽ làm gì, cho ai, giải quyết vấn đề nào, và đo lường thành công ra sao. PRD tốt thì cả team chạy trơn tru. PRD tệ hoặc mơ hồ thì kéo theo hàng loạt cuộc họp làm rõ, sửa đi sửa lại, thậm chí ship sai thứ khách hàng cần.
Vấn đề là viết một PRD tử tế cho một feature lớn thường ngốn của PM cả tuần. Không phải vì gõ chữ chậm, mà vì PM phải tổng hợp thông tin từ hàng chục nguồn: phản hồi khách hàng, số liệu analytics, ràng buộc kỹ thuật, quy định pháp lý, ý kiến các bên liên quan. Với các sản phẩm fintech tại Việt Nam — nơi mỗi tính năng đụng đến tiền của người dùng và chịu sự giám sát của Ngân hàng Nhà nước — độ phức tạp còn nhân lên nhiều lần.
Bài này là một case study rất cụ thể: cách một Senior PM tại một startup neobank (ngân hàng số) ở TP.HCM dùng AI để rút thời gian viết PRD từ một tuần xuống còn khoảng một ngày, mà chất lượng lại tốt hơn. Điều quan trọng không phải là "AI viết hộ PRD", mà là một quy trình làm việc mới, nơi PM đóng vai đạo diễn còn AI là công cụ khuếch đại. Bạn sẽ học được cách tư duy đó và áp dụng ngay vào công việc của mình, dù bạn làm fintech hay bất kỳ ngành nào.
Khái niệm cốt lõi
PRD thực chất là gì và tại sao nó tốn thời gian
Một PRD hoàn chỉnh thường gồm các phần: bối cảnh và vấn đề (problem statement), mục tiêu và chỉ số thành công (goals & success metrics), đối tượng người dùng (user personas), các luồng nghiệp vụ (user flows), yêu cầu chức năng chi tiết (functional requirements), các trường hợp biên (edge cases), ràng buộc phi chức năng (bảo mật, hiệu năng, tuân thủ), và phần ngoài phạm vi (out of scope).
Phần lớn thời gian PM tiêu tốn không nằm ở việc gõ chữ, mà nằm ở ba việc: (1) tổng hợp thông tin rời rạc thành một câu chuyện mạch lạc, (2) suy nghĩ cho hết các edge case và tình huống mà mình dễ bỏ sót, và (3) diễn đạt sao cho engineer đọc là hiểu, không phải hỏi lại. Đây chính xác là ba chỗ mà AI mạnh.
AI không thay PM — AI khuếch đại PM
Đây là điểm mấu chốt mà nhiều người hiểu sai. AI không biết chiến lược sản phẩm của công ty bạn, không dự họp với khách hàng, không chịu trách nhiệm khi feature thất bại. Cái AI làm cực tốt là: biến một mớ ghi chú lộn xộn thành cấu trúc, gợi ý những góc nhìn bạn chưa nghĩ tới, viết bản nháp đầu tiên nhanh gấp mười lần, và đóng vai "người phản biện" để bạn tìm lỗ hổng trong lập luận.
Nói cách khác, PM vẫn là người quyết định cái gì cần làm và tại sao. AI giúp PM đi từ ý tưởng trong đầu đến tài liệu hoàn chỉnh nhanh hơn rất nhiều.
Ba trụ cột của workflow PRD với AI
Trước khi vào case study, hãy nắm ba trụ cột. Một là context tốt — bạn phải nạp cho AI đủ dữ liệu thô: transcript phỏng vấn khách hàng, số liệu, tài liệu kỹ thuật liên quan. Rác vào thì rác ra. Hai là cấu trúc — dùng một template PRD cố định để AI luôn xuất ra đúng khung công ty bạn dùng. Ba là phản biện — bắt AI đóng vai engineer, đóng vai bộ phận compliance, đóng vai khách hàng khó tính để "đục" vào bản nháp và tìm chỗ hổng.
Tình huống thực tế
Tình huống 1: Quang và tính năng "chia hoá đơn nhóm" tại startup neobank
Quang là Senior PM tại một startup neobank ở TP.HCM (ta gọi là "TienNgay Bank" cho dễ hình dung). Quý này team anh nhận nhiệm vụ ship tính năng "chia hoá đơn nhóm" (split bill) — cho phép nhóm bạn đi ăn chia tiền và đòi nợ nhau ngay trong app.
Trước khi dùng AI, quy trình của Quang cho một feature cỡ này mất trọn một tuần: hai ngày đọc lại các cuộc phỏng vấn người dùng và số liệu, hai ngày viết nháp, một ngày họp lấy ý kiến, rồi lại sửa. Sau khi chuyển sang workflow AI, đây là cách anh làm.
Ngày thứ nhất, buổi sáng. Quang đổ toàn bộ nguyên liệu thô vào một Project trong Claude: 12 đoạn transcript phỏng vấn người dùng (đã ẩn danh, không có số căn cước hay số tài khoản thật), bản export số liệu cho thấy 34% người dùng Gen Z rời app sau khi phải chuyển khoản thủ công để chia tiền, và tài liệu mô tả giới hạn kỹ thuật của core banking hiện tại. Anh yêu cầu AI: "Đọc toàn bộ tài liệu này và tổng hợp cho tôi 5 pain point lớn nhất của người dùng liên quan đến việc chia tiền, kèm trích dẫn cụ thể từ transcript." Trong vài phút, anh có được một bản tổng hợp mà bình thường phải đọc thủ công cả buổi.
Ngày thứ nhất, buổi chiều. Quang nạp template PRD chuẩn của công ty vào AI và yêu cầu viết bản nháp đầu tiên dựa trên phần tổng hợp pain point vừa rồi. Anh nhấn mạnh: "Viết phần functional requirements ở mức đủ chi tiết để engineer đọc hiểu, và liệt kê tối thiểu 8 edge case." AI trả về bản nháp trong đó có những edge case mà Quang thừa nhận bình thường anh hay quên: chuyện chia lẻ tiền không chia hết (chia 100.000đ cho 3 người thì ai chịu phần lẻ 1 đồng), chuyện một thành viên trong nhóm chưa có tài khoản ngân hàng, chuyện huỷ giao dịch giữa chừng.
Kết quả: Quang có bản nháp PRD hoàn chỉnh sau một ngày rưỡi thay vì một tuần. Anh dùng thời gian dư ra để làm đúng việc PM giỏi nên làm: ngồi với engineer lead bàn về tính khả thi, và ngồi với bộ phận compliance kiểm tra xem tính năng đòi nợ nội bộ có vướng quy định về trung gian thanh toán không.
Bài học rút ra: AI không viết chiến lược thay Quang, nhưng nó gánh hết phần việc nặng nhọc là tổng hợp và soạn nháp, giải phóng Quang để tập trung vào phần chỉ con người mới làm được — phán đoán và ra quyết định.
Tình huống 2: PM tại một sàn TMĐT và bài học "rác vào rác ra"
Một PM tên Linh làm tại một sàn thương mại điện tử ở Hà Nội thử áp dụng workflow tương tự cho tính năng "gợi ý sản phẩm cá nhân hoá". Nhưng lần đầu chị thất vọng: PRD do AI viết ra chung chung, đọc như một bài blog marketing chứ không phải tài liệu kỹ thuật.
Vấn đề nằm ở đầu vào. Linh chỉ gõ cho AI một câu prompt: "Viết PRD cho tính năng gợi ý sản phẩm cá nhân hoá cho sàn TMĐT." Không có số liệu, không có transcript, không có ràng buộc kỹ thuật. AI chỉ còn cách viết dựa trên kiến thức chung chung của nó — tức là một PRD "trung bình của internet", không dính gì đến bối cảnh cụ thể của công ty chị.
Lần thứ hai, Linh làm lại: chị nạp số liệu tỷ lệ chuyển đổi hiện tại, log hành vi click của người dùng, mô tả kiến trúc recommendation engine mà team đang có, và ba câu hỏi cụ thể mà giám đốc sản phẩm đặt ra. Lần này PRD sắc bén hẳn — có con số cụ thể, có ràng buộc thật, có cả phần thảo luận về việc cold start (người dùng mới chưa có lịch sử hành vi thì gợi ý dựa vào đâu).
Bài học rút ra: Chất lượng PRD tỷ lệ thuận với chất lượng context bạn nạp vào. AI không đọc được suy nghĩ trong đầu bạn. Nếu bạn tiếc công chuẩn bị nguyên liệu, bạn sẽ nhận về một tài liệu vô hồn. Thời gian bạn tiết kiệm được là ở khâu viết và tổng hợp, chứ không phải ở khâu thu thập dữ liệu — khâu đó vẫn là việc của PM.
Tình huống 3: Dùng AI làm "hội đồng phản biện" trước khi trình PRD
Trở lại với Quang. Trước khi đem PRD split bill ra họp với cả team, anh làm một bước mà anh gọi là "chạy hội đồng phản biện ảo". Anh yêu cầu AI lần lượt đóng ba vai:
Vai engineer khó tính: "Đọc PRD này với con mắt của một senior backend engineer. Chỉ ra 5 chỗ mơ hồ về mặt kỹ thuật mà nếu tôi bắt đầu code sẽ phải quay lại hỏi PM." AI chỉ ra ngay chuyện PRD chưa nói rõ giao dịch chia tiền là chuyển khoản thật hay chỉ là ghi nợ ảo trong hệ thống — hai hướng đó khác nhau một trời một vực về mặt triển khai.
Vai chuyên viên compliance: "Đóng vai người phụ trách tuân thủ pháp lý tại một ngân hàng số Việt Nam. Tính năng này có thể vướng quy định nào?" AI nêu ra câu hỏi liệu việc cho người dùng đòi nợ lẫn nhau qua app có bị xem là hoạt động trung gian thanh toán cần giấy phép hay không, và nhắc về nghĩa vụ định danh khách hàng (KYC/eKYC).
Vai khách hàng hoài nghi: "Bạn là một người dùng 45 tuổi, không rành công nghệ. Điều gì trong luồng này khiến bạn bối rối hoặc không tin tưởng?" AI chỉ ra rằng người lớn tuổi có thể lo lắng khi thấy tính năng tự động trừ tiền và cần một bước xác nhận rõ ràng.
Bài học rút ra: AI đóng vai phản biện cực rẻ và cực nhanh so với việc chờ đến buổi họp mới phát hiện lỗ hổng. Quang bước vào cuộc họp thật với một PRD đã được "vá" trước hàng loạt câu hỏi hiển nhiên, nên cuộc họp tập trung vào các quyết định chiến lược quan trọng thay vì mất thời gian làm rõ những chỗ đáng lẽ đã rõ.
Hướng dẫn từng bước
Đây là quy trình bạn có thể sao chép để nâng cấp cách viết PRD của mình.
Bước 1 — Thu thập và ẩn danh nguyên liệu thô. Gom hết những gì bạn có: transcript phỏng vấn, số liệu analytics, tài liệu kỹ thuật, ghi chú họp. Với dữ liệu nhạy cảm (đặc biệt trong fintech), hãy ẩn danh — bỏ tên thật, số tài khoản, số căn cước — trước khi đưa lên công cụ AI. Đây là nguyên tắc bắt buộc.
Bước 2 — Tạo một không gian làm việc có ngữ cảnh. Dùng một Project (trong Claude) hoặc một custom GPT để nạp toàn bộ nguyên liệu cộng với template PRD chuẩn của công ty. Việc này giúp AI luôn tham chiếu đúng context xuyên suốt, không phải dán lại tài liệu mỗi lần hỏi.
Bước 3 — Tổng hợp trước, viết sau. Đừng vội bảo AI viết PRD ngay. Trước tiên yêu cầu nó tổng hợp pain point, phân tích số liệu, rút ra insight — kèm trích dẫn nguồn. Bạn đọc và xác nhận phần này đúng đã, rồi mới đi tiếp.
Bước 4 — Yêu cầu bản nháp theo đúng template. Ra lệnh cho AI viết bản nháp bám sát khung PRD của bạn. Nêu rõ kỳ vọng: "functional requirements phải đủ chi tiết để engineer thực thi", "liệt kê tối thiểu 8 edge case", "có phần đo lường thành công với chỉ số cụ thể".
Bước 5 — Chạy hội đồng phản biện ảo. Bắt AI lần lượt đóng vai engineer, compliance, designer, khách hàng khó tính để soi lỗ hổng trong bản nháp. Ghi lại các câu hỏi nó nêu ra.
Bước 6 — PM chỉnh sửa và ra quyết định. Đây là phần không được giao cho AI. Bạn đọc kỹ, sửa những chỗ AI hiểu sai, bổ sung quyết định chiến lược, và chịu trách nhiệm với từng dòng. AI viết nháp, nhưng chữ ký cuối cùng là của bạn.
Bước 7 — Đem PRD đã vá đi họp thật. Vào cuộc họp với con người khi tài liệu đã sạch những câu hỏi hiển nhiên, để dành thời gian quý giá cho các quyết định thực sự cần tranh luận.
Lỗi thường gặp & mẹo
Lỗi 1 — Kỳ vọng AI biết chiến lược của công ty. AI không biết OKR quý này, không biết chính trị nội bộ, không biết sếp bạn ghét tính năng nào. Đừng bao giờ để AI quyết định cái gì đáng làm. Đó là việc của PM.
Lỗi 2 — Nạp context nghèo nàn. Như case của Linh: prompt một câu thì nhận về PRD một câu chất lượng. Đầu tư vào nguyên liệu đầu vào.
Lỗi 3 — Copy nguyên xi bản nháp AI mà không đọc lại. AI đôi khi "bịa" một cách trơn tru — nêu ra một chỉ số nghe hợp lý nhưng không có thật, hoặc mô tả một luồng nghiệp vụ không khớp với hệ thống thực. PM phải là người kiểm chứng cuối cùng. Một PRD sai được ship đi có thể khiến cả team code nhầm hàng tuần.
Lỗi 4 — Bỏ qua bảo mật dữ liệu. Trong fintech, việc đưa dữ liệu khách hàng thật lên công cụ AI công cộng có thể vi phạm nghị định về bảo vệ dữ liệu cá nhân. Luôn ẩn danh, và ưu tiên các gói AI cam kết không dùng dữ liệu của bạn để huấn luyện.
Mẹo 1 — Lưu lại prompt tốt thành thư viện. Prompt "chạy hội đồng phản biện" của Quang có thể tái sử dụng cho mọi PRD. Đừng viết lại từ đầu mỗi lần.
Mẹo 2 — Dùng AI để dịch PRD sang ngôn ngữ của từng đối tượng. Cùng một PRD, bạn có thể nhờ AI tóm tắt thành một đoạn ngắn cho sếp (tập trung vào business impact) và một checklist cho QA (tập trung vào test case). Một nguồn, nhiều phiên bản.
Mẹo 3 — Yêu cầu AI đặt câu hỏi ngược cho bạn. Trước khi viết, hãy hỏi: "Bạn cần tôi cung cấp thêm thông tin gì để viết PRD này thật tốt?" AI thường chỉ ra ngay những khoảng trống trong suy nghĩ của bạn.
Bài tập thực hành
Hãy chọn một tính năng thật mà bạn (hoặc đội của bạn) đang cần làm. Nếu bạn chưa làm PM, hãy dùng một ví dụ giả định: "thêm chức năng nhắc lịch thanh toán hoá đơn điện nước vào một app ví điện tử".
- Chuẩn bị context (30 phút). Viết ra ít nhất: một mô tả vấn đề, ba pain point của người dùng, hai ràng buộc kỹ thuật hoặc pháp lý, và một chỉ số thành công. Ẩn danh mọi dữ liệu nhạy cảm.
- Tổng hợp (15 phút). Nạp context vào AI và yêu cầu nó tổng hợp thành insight có cấu trúc. Đọc và sửa cho đúng.
- Viết nháp (20 phút). Yêu cầu AI viết bản nháp PRD theo khung: bối cảnh, mục tiêu, user flow, functional requirements, tối thiểu 6 edge case, chỉ số thành công, phần ngoài phạm vi.
- Phản biện (20 phút). Bắt AI đóng vai engineer, rồi đóng vai khách hàng khó tính, chỉ ra lỗ hổng. Ghi lại các câu hỏi.
- Tự đánh giá (15 phút). So sánh: bạn mất bao lâu để có bản nháp này so với cách làm cũ? PRD có bao nhiêu edge case mà bạn tự nghĩ sẽ không nghĩ ra? Chỗ nào AI hiểu sai và bạn phải sửa?
Tóm tắt
Case study của Quang cho thấy AI có thể rút thời gian viết PRD của một PM từ một tuần xuống còn khoảng một ngày, mà chất lượng lại cao hơn nhờ AI giúp phát hiện edge case và phản biện. Nhưng bài học lớn nhất không phải "AI viết PRD hộ bạn". Đó là một sự dịch chuyển vai trò: PM chuyển từ người thợ gõ chữ thành người đạo diễn, dành thời gian tiết kiệm được cho phần việc chỉ con người làm được — hiểu khách hàng, ra quyết định chiến lược, và chịu trách nhiệm.
Ba nguyên tắc cần nhớ: context tốt quyết định chất lượng đầu ra (rác vào rác ra); cấu trúc bằng template giúp AI xuất đúng khung công ty bạn cần; và phản biện đa vai giúp bạn vá lỗ hổng trước khi bước vào phòng họp. Với các PM fintech Việt Nam, luôn nhớ ẩn danh dữ liệu và kiểm tra tuân thủ — vì mỗi tính năng đều đụng đến tiền và niềm tin của người dùng. Hãy bắt đầu với chính tính năng bạn đang làm dở ngay tuần này, và tự đo lấy khoảng thời gian bạn tiết kiệm được.