Vấn đề của bạn
Viết PRD (Product Requirements Document) tốn thời gian nhất ở khâu khởi động trang trắng và đảm bảo đủ mục: bối cảnh, vấn đề, mục tiêu, user story, acceptance criteria, edge case, metric. PM giỏi thường không thiếu ý — họ thiếu thời gian để cấu trúc và diễn đạt cho rõ. AI xử lý đúng khâu này: biến ý rời rạc của bạn thành bản nháp có cấu trúc, để bạn tập trung vào phần khó là đánh giá và bổ sung tư duy sản phẩm.
Nguyên tắc vàng
AI viết bản nháp, bạn viết quyết định. Đừng để AI tự "sáng tác" vấn đề khách hàng — bạn cung cấp bối cảnh, AI cấu trúc nó.
Ví dụ cụ thể
Bạn cần PRD cho tính năng "Nhắc thanh toán trước hạn 3 ngày". Bạn có vài dòng ghi chú từ buổi họp. Thay vì ngồi 2 tiếng, bạn đưa ghi chú vào prompt dưới và có bản nháp 8 mục trong 5 phút, rồi dành 45 phút để tinh chỉnh phần thực sự cần não người.
Prompt mẫu
Bạn là PM senior. Viết PRD cho tính năng dưới đây theo cấu trúc:
1) Bối cảnh & vấn đề 2) Mục tiêu & non-goals 3) Đối tượng người dùng
4) User stories (dạng: Là <ai>, tôi muốn <gì>, để <lợi ích>)
5) Yêu cầu chức năng 6) Acceptance criteria (dạng Given/When/Then)
7) Edge cases & lỗi 8) Metric đo thành công (kèm baseline nếu có)
Quy tắc:
- CHỈ dùng thông tin tôi cung cấp; chỗ nào thiếu, ghi [CẦN LÀM RÕ: ...]
thay vì tự bịa.
- Acceptance criteria phải test được, tránh từ mơ hồ ("nhanh", "dễ dùng").
- Ngôn ngữ tiếng Việt, súc tích.
GHI CHÚ CỦA TÔI:
- Người dùng hay quên hạn thanh toán, tỉ lệ trễ ~18%.
- Muốn nhắc qua email + push, trước 3 ngày.
- Chưa rõ: có cho tắt nhắc không? nhắc mấy lần?
Các bước triển khai
- Thu thập nguyên liệu thô: ghi chú họp, feedback, số liệu hiện trạng. Dán nguyên trạng, không cần gọt.
- Chạy prompt PRD ở trên. Chú ý các dấu
[CẦN LÀM RÕ]— đó là danh sách việc bạn phải quyết định. - Đánh giá phần tư duy sản phẩm: đọc mục Mục tiêu và Metric — AI hay đề xuất metric chung chung, bạn phải thay bằng metric thật của team.
- Nhờ AI "phản biện": dán lại PRD và hỏi "Là một dev/QA khó tính, hãy chỉ 5 chỗ mơ hồ hoặc thiếu edge case."
- Hoàn thiện acceptance criteria — đây là phần dev đọc nhiều nhất, phải chuẩn Given/When/Then.
- Lưu prompt vào Prompt Library kèm ghi chú "phiên bản nào cho ra kết quả tốt".
Prompt phản biện (rất giá trị)
Đọc PRD dưới đây với vai QA và Tech Lead. Liệt kê:
- 5 acceptance criteria còn mơ hồ, viết lại cho test được.
- 3 edge case bị bỏ sót (trường hợp lỗi, đồng thời, dữ liệu rỗng).
- 2 giả định ẩn có thể sai.
[DÁN PRD]
Checklist "PRD sẵn sàng review"
[ ] Vấn đề nêu rõ + có số liệu chứng minh (không phải cảm tính)
[ ] Mục tiêu đo được + có non-goals
[ ] Mọi acceptance criteria đều test được (Given/When/Then)
[ ] Đã liệt kê edge case: lỗi mạng, dữ liệu rỗng, quyền hạn
[ ] Metric thành công + baseline hiện tại
[ ] Đã xóa/quyết mọi dấu [CẦN LÀM RÕ]
[ ] Đã đọc lại toàn bộ bằng mắt người (không publish thẳng từ AI)
Sai lầm thường gặp
- Publish thẳng bản AI cho dev. AI hay viết acceptance criteria nghe hay nhưng không test được, hoặc bịa metric ("tăng 20% retention") mà không có cơ sở — ảo giác dạng nguy hiểm nhất vì trông rất thuyết phục. Luôn thay số bịa bằng số thật.
- Để AI tự định nghĩa vấn đề khách hàng. Nếu bạn không cung cấp insight, AI sẽ viết vấn đề chung chung, dẫn team đi sai. Vấn đề là phần của bạn.
- Dán spec chứa dữ liệu mật lên AI công cộng. Kiến trúc hệ thống, khóa API, dữ liệu khách hàng — ẩn danh trước khi dán.
- Phụ thuộc: mất kỹ năng viết. Nếu bạn không bao giờ tự viết, khi AI hỏng bạn sẽ tê liệt. Định kỳ tự viết một PRD không AI để giữ nghề.
Chốt bài
AI giúp bạn từ "trang trắng" đến "bản nháp có cấu trúc" trong vài phút, và đóng vai QA phản biện miễn phí. Nhưng tư duy vấn đề và metric thật vẫn là của bạn. Bài sau: biến feedback lộn xộn thành insight.