Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi một Product Manager (PM) rằng phần việc nào ngốn nhiều thời gian nhất nhưng lại ít người yêu thích nhất, câu trả lời gần như luôn là: viết tài liệu. PRD (Product Requirements Document — tài liệu yêu cầu sản phẩm), spec kỹ thuật, user story, release note... Đây là những thứ gắn kết cả đội ngũ lại với nhau, nhưng cũng là những thứ khiến bạn ngồi nhìn màn hình trắng vào 9 giờ tối, không biết bắt đầu từ đâu.
Có một khảo sát nội bộ tại nhiều công ty công nghệ cho thấy PM dành tới 30–40% thời gian làm việc cho documentation. Với một PM ở Việt Nam quản lý cùng lúc 2–3 sản phẩm — điều rất phổ biến ở các startup như Tiki, Sapo hay các fintech vừa và nhỏ — con số này còn cao hơn. Tài liệu viết vội thì thiếu chặt chẽ, gây hiểu lầm; tài liệu viết kỹ thì tốn thời gian, làm chậm cả nhịp độ phát triển.
Đây chính là chỗ AI tỏa sáng. Không phải để thay bạn quyết định sản phẩm nên làm gì — đó vẫn là việc của bạn. Mà để xóa bỏ "nỗi sợ trang giấy trắng", dựng khung sườn nhanh, đặt câu hỏi mà bạn quên mất, và chuyển ý tưởng lộn xộn trong đầu thành văn bản có cấu trúc trong vài phút. Bài học này tập trung riêng vào việc dùng AI để sản xuất ba loại tài liệu cốt lõi của PM: PRD, technical spec, và user story. Chúng ta sẽ không bàn về research hay phân tích dữ liệu (đã có bài riêng), mà đi thẳng vào nghệ thuật biến AI thành "trợ lý viết tài liệu" đáng tin cậy của bạn.
Khái niệm cốt lõi
AI là người soạn thảo, bạn là người biên tập
Hiểu lầm lớn nhất là nghĩ AI sẽ "viết hộ" toàn bộ PRD chuẩn chỉnh để bạn copy-paste. Không. AI mạnh ở việc tạo bản nháp đầu tiên (first draft) với cấu trúc đầy đủ, nhưng nó không biết bối cảnh nội bộ công ty bạn, không biết quyết định chiến lược của ban lãnh đạo, không biết "nợ kỹ thuật" mà team đang gánh. Vai trò của bạn chuyển từ người viết sang người biên tập và bổ sung ngữ cảnh. Đây là sự dịch chuyển quan trọng nhất cần nắm: bạn tiết kiệm 70% thời gian gõ phím, nhưng 30% còn lại — phần phán đoán — vẫn là của bạn và quý hơn bao giờ hết.
Ba loại tài liệu, ba kiểu prompt khác nhau
Mỗi loại tài liệu cần một cách "ra lệnh" khác nhau cho AI:
PRD trả lời câu hỏi Tại sao và Cái gì: vấn đề người dùng là gì, tại sao đáng giải quyết, thành công đo bằng gì, phạm vi đến đâu. Khi prompt cho PRD, bạn phải cung cấp bối cảnh kinh doanh và đối tượng người dùng.
Technical spec trả lời câu hỏi Như thế nào: luồng dữ liệu, các trường hợp biên (edge case), trạng thái lỗi, yêu cầu phi chức năng (hiệu năng, bảo mật). Khi prompt cho spec, bạn cần mô tả ràng buộc kỹ thuật và hành vi mong muốn ở mức chi tiết hơn.
User story trả lời câu hỏi Ai cần gì và để làm gì, theo định dạng "Là một [vai trò], tôi muốn [hành động], để [lợi ích]", kèm theo tiêu chí chấp nhận (acceptance criteria). AI đặc biệt giỏi việc bẻ một tính năng lớn thành nhiều story nhỏ và viết acceptance criteria theo dạng Given-When-Then.
Context là vua
Chất lượng đầu ra của AI tỉ lệ thuận với chất lượng bối cảnh bạn đưa vào. Một prompt "viết PRD cho tính năng thanh toán" sẽ cho ra văn bản chung chung, vô dụng. Nhưng "viết PRD cho tính năng thanh toán trả góp qua thẻ tín dụng, dành cho sàn thương mại điện tử ở Việt Nam, đối tượng khách hàng 25–40 tuổi mua sản phẩm 3–15 triệu đồng, mục tiêu tăng tỷ lệ chuyển đổi giỏ hàng giá trị cao thêm 15%" sẽ cho ra thứ gần với tài liệu thật. Hãy nhớ công thức: Vai trò + Nhiệm vụ + Bối cảnh + Ràng buộc + Định dạng đầu ra.
Tình huống thực tế
Tình huống 1: PM tại một fintech ví điện tử dựng PRD trong 30 phút
Linh là PM tại một công ty ví điện tử ở TP.HCM (giả định, lấy cảm hứng từ MoMo/ZaloPay). Sếp giao việc lúc 4 giờ chiều: ngày mai họp roadmap, cần một PRD nháp cho tính năng "Hũ tiết kiệm tự động" — tự động trích một khoản nhỏ mỗi khi người dùng chi tiêu, bỏ vào hũ tiết kiệm sinh lời.
Thay vì ngồi viết từ đầu, Linh mở Claude và gõ một prompt có đầy đủ bối cảnh: vai trò (PM fintech), mô tả tính năng, đối tượng (người dùng 22–35 tuổi, thu nhập 8–20 triệu/tháng, khó tiết kiệm), mục tiêu kinh doanh (tăng số dư bình quân trong ví, tăng retention), và yêu cầu định dạng PRD chuẩn gồm: Problem statement, Goals & non-goals, User personas, Functional requirements, Success metrics, Risks.
Trong 90 giây, AI trả về một PRD nháp dài 2 trang với cấu trúc hoàn chỉnh. Linh dành 25 phút còn lại để biên tập: cô xóa phần "tích hợp blockchain" mà AI tự thêm vào (không phù hợp), bổ sung ràng buộc pháp lý về việc trích tiền tự động (AI không biết quy định của Ngân hàng Nhà nước), và sửa lại metric thành công cho khớp với OKR quý của team.
Bài học rút ra: AI rút ngắn việc từ 3 tiếng xuống 30 phút, nhưng phần giá trị nhất — kiểm tra tính tuân thủ pháp lý và gắn với OKR — vẫn do con người làm. Linh không "lười đi" mà "tập trung đúng chỗ".
Tình huống 2: Bẻ một epic thành user story tại một startup SaaS
Tuấn là PM ở một startup SaaS quản lý nhà hàng (giả định kiểu iPOS/KiotViet). Team chuẩn bị làm tính năng lớn "Đặt bàn online", và Tuấn cần chuyển nó thành các user story để đưa vào sprint planning. Việc này thường mất cả buổi sáng.
Tuấn đưa cho AI mô tả tính năng và yêu cầu: "Bẻ tính năng đặt bàn online thành các user story theo định dạng 'Là một... tôi muốn... để...', nhóm theo ba vai trò: khách hàng, nhân viên nhà hàng, và quản lý. Với mỗi story, viết acceptance criteria theo dạng Given-When-Then."
AI trả về 14 story, bao gồm cả những story mà Tuấn đã quên: "Là một khách hàng, tôi muốn nhận thông báo khi bàn được xác nhận, để tôi yên tâm đến đúng giờ" và quan trọng hơn là các edge case như "khi nhà hàng hết bàn trống vào khung giờ đã chọn". Tuấn nhận ra mình suýt bỏ sót luồng hủy đặt bàn và hoàn cọc.
Bài học rút ra: Sức mạnh thật sự của AI ở đây không phải tốc độ, mà là tính bao quát. Nó đóng vai một đồng nghiệp tỉ mỉ, nhắc bạn những trường hợp biên mà bộ não đang vội của bạn dễ bỏ qua. Tuấn vẫn loại bỏ 3 story ngoài phạm vi và gộp 2 story trùng lặp — nhưng anh bắt đầu từ một danh sách phong phú thay vì trang giấy trắng.
Tình huống 3: Viết technical spec để nói chung ngôn ngữ với engineer
Hà là PM mới chuyển từ mảng business sang, chưa vững về kỹ thuật, tại một công ty logistics ở Hà Nội. Cô cần viết spec cho API thông báo trạng thái đơn hàng, nhưng sợ team engineer chê "spec thiếu chiều sâu kỹ thuật".
Hà dùng AI như một "người dịch": cô mô tả bằng ngôn ngữ nghiệp vụ ("khi đơn hàng chuyển trạng thái, hệ thống cần báo cho khách qua app và SMS"), rồi yêu cầu AI dựng spec gồm: các trạng thái đơn hàng và điều kiện chuyển trạng thái, định dạng payload, xử lý lỗi khi gửi thất bại, và yêu cầu phi chức năng như độ trễ tối đa. Sau đó cô hỏi thêm AI: "Engineer có thể chất vấn những điểm nào trong spec này?" — và AI liệt kê ra các câu hỏi về retry logic, idempotency, rate limiting.
Nhờ vậy, khi vào buổi review spec, Hà tự tin trả lời được phần lớn câu hỏi kỹ thuật.
Bài học rút ra: AI giúp PM không chuyên kỹ thuật "nâng trần năng lực", nói chuyện ngang hàng hơn với engineer. Nhưng Hà luôn ghi chú rõ những phần cô chưa chắc chắn để hỏi lại team — không giả vờ hiểu, vì spec sai có thể khiến cả sprint đi chệch hướng.
Hướng dẫn từng bước
Đây là quy trình bốn bước để sản xuất một PRD chất lượng với AI. Bạn có thể áp dụng tương tự cho spec và user story.
Bước 1 — Bản nháp đầu tiên (khoảng 5 phút). Mở Claude hoặc ChatGPT, dùng một prompt giàu bối cảnh. Mẫu:
Bạn là PM giàu kinh nghiệm trong lĩnh vực [lĩnh vực].
Hãy viết một PRD nháp cho tính năng [tên tính năng].
Bối cảnh:
- Sản phẩm: [mô tả 1-2 câu]
- Người dùng mục tiêu: [đối tượng, độ tuổi, hành vi]
- Vấn đề cần giải quyết: [mô tả]
- Mục tiêu kinh doanh: [metric mong muốn]
- Ràng buộc: [pháp lý, kỹ thuật, thời gian]
Cấu trúc PRD gồm: Problem statement, Goals & Non-goals,
User personas, Functional requirements, Success metrics,
Open questions, Risks.
Bước 2 — Thẩm vấn và làm giàu (5–10 phút). Đừng nhận bản nháp đầu rồi dừng lại. Hãy hỏi tiếp AI: "Phần nào trong PRD này còn mơ hồ?", "Có edge case nào tôi bỏ sót?", "Liệt kê 5 câu hỏi mà stakeholder sẽ chất vấn." Mỗi câu hỏi giúp PRD chặt chẽ hơn một bậc.
Bước 3 — Biên tập với phán đoán con người (15–20 phút). Đây là phần không thể giao phó. Đọc kỹ, xóa những gì AI bịa ra hoặc ngoài phạm vi, bổ sung ngữ cảnh nội bộ (quyết định của lãnh đạo, ràng buộc team, ưu tiên thật), và chỉnh metric cho khớp OKR. Hãy đặc biệt cảnh giác với những con số hoặc tuyên bố mà AI tự đưa ra — kiểm chứng lại tất cả.
Bước 4 — Tinh chỉnh giọng văn và định dạng (5 phút). Yêu cầu AI viết lại phần tóm tắt cho ngắn gọn, hoặc chuyển bảng yêu cầu sang định dạng phù hợp với công cụ của bạn (Notion, Confluence, Jira). Bạn cũng có thể yêu cầu một phiên bản "TL;DR" để gửi cho lãnh đạo bận rộn.
Một mẹo quan trọng: hãy lưu lại các prompt mẫu tốt thành thư viện riêng. Lần sau bạn chỉ cần điền vào chỗ trống thay vì nghĩ lại từ đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Prompt quá mỏng, kỳ vọng quá nhiều. PM gõ "viết PRD cho tính năng chat" rồi thất vọng vì kết quả chung chung. Nhớ rằng: prompt nghèo bối cảnh thì đầu ra nghèo giá trị. Dành thêm 2 phút mô tả bối cảnh sẽ tiết kiệm 30 phút sửa chữa.
Lỗi 2 — Tin tưởng mù quáng vào con số AI đưa ra. AI có thể "tự tin" viết "tính năng này sẽ tăng retention 20%" — một con số nó hoàn toàn bịa ra. Đừng bao giờ để những con số chưa kiểm chứng lọt vào tài liệu chính thức. Hãy đánh dấu mọi giả định cần xác minh.
Lỗi 3 — Để AI quyết định phạm vi. AI có xu hướng "vẽ" thêm tính năng cho hoành tráng. PRD của bạn cần một mục Non-goals rõ ràng để chống lại hiện tượng phình phạm vi (scope creep). Hãy chủ động yêu cầu AI liệt kê những gì không làm.
Lỗi 4 — Quên rằng tài liệu là để giao tiếp, không phải để khoe. Đôi khi AI viết quá dài dòng, hoa mỹ. Tài liệu PM tốt là tài liệu engineer và designer đọc xong hiểu ngay phải làm gì. Hãy yêu cầu AI "viết ngắn gọn, ưu tiên sự rõ ràng hơn văn vẻ".
Mẹo hữu ích:
- Dùng kỹ thuật "few-shot": dán một PRD cũ chất lượng tốt của công ty bạn làm mẫu, rồi bảo AI viết theo đúng phong cách và cấu trúc đó. Kết quả sẽ khớp với chuẩn nội bộ ngay lập tức.
- Với tài liệu nhạy cảm, hãy ẩn danh dữ liệu (đổi tên công ty, làm mờ số liệu thật) trước khi đưa vào AI — chủ đề bảo mật dữ liệu sẽ được bàn kỹ ở bài khác, nhưng nguyên tắc thận trọng nên áp dụng ngay từ bây giờ.
- Tạo một prompt "checklist": sau khi viết xong, bảo AI rà soát tài liệu theo danh sách tiêu chí chất lượng (đầy đủ metric? có non-goals? có edge case? có open questions?).
Bài tập thực hành
- Dựng PRD nháp: Chọn một tính năng thật mà bạn (hoặc một sản phẩm bạn dùng hằng ngày như Grab, Shopee) có thể cải thiện. Viết một prompt giàu bối cảnh theo mẫu ở Bước 1 và tạo PRD nháp. Sau đó tự biên tập: gạch bỏ ít nhất 2 điểm AI viết sai/thừa và bổ sung ít nhất 3 ngữ cảnh mà chỉ con người mới biết.
- Bẻ epic thành story: Lấy một tính năng lớn và yêu cầu AI bẻ thành user story theo định dạng "Là một... tôi muốn... để...", kèm acceptance criteria dạng Given-When-Then. Đếm xem có bao nhiêu edge case mà bạn đã bỏ sót.
- So sánh prompt nghèo và prompt giàu: Viết cùng một yêu cầu PRD theo hai cách — một prompt một dòng và một prompt đầy đủ bối cảnh. Đặt hai kết quả cạnh nhau và ghi lại sự khác biệt. Đây là bài tập giúp bạn "thấm" tầm quan trọng của context.
- Xây thư viện prompt cá nhân: Lưu lại 3 prompt mẫu (PRD, spec, user story) mà bạn thấy hiệu quả nhất vào một file Notion riêng để tái sử dụng.
Tóm tắt
AI không thay thế khả năng phán đoán sản phẩm của bạn, nhưng nó xóa bỏ rào cản lớn nhất của documentation: nỗi sợ trang giấy trắng và thời gian gõ phím lặp đi lặp lại. Hãy nhớ ba điều cốt lõi: (1) AI là người soạn thảo, bạn là người biên tập — giá trị của bạn nằm ở 30% phán đoán cuối cùng; (2) chất lượng bối cảnh trong prompt quyết định chất lượng đầu ra, hãy luôn cung cấp Vai trò + Nhiệm vụ + Bối cảnh + Ràng buộc + Định dạng; (3) mỗi loại tài liệu — PRD, spec, user story — cần một kiểu prompt riêng, và bạn phải luôn thẩm vấn, kiểm chứng, cắt gọt thay vì tin tưởng mù quáng.
Khi đã thành thạo, bạn sẽ thấy việc tạo một PRD chỉn chu không còn là gánh nặng cuối ngày, mà chỉ là 30 phút tập trung — phần lớn dành cho thứ thực sự quan trọng: tư duy về sản phẩm.