PRD (Product Requirement Document - tài liệu yêu cầu sản phẩm) là loại tài liệu mà gần như PM nào cũng phải viết, nhưng rất ít người thấy tự tin về nó. Vấn đề không nằm ở việc thiếu ý tưởng, mà nằm ở việc PRD phải phục vụ cùng lúc nhiều đối tượng khác nhau — sếp cần executive summary ngắn gọn để duyệt ngân sách, dev cần chi tiết kỹ thuật đủ để estimate, designer cần hiểu rõ user flow, còn stakeholder kinh doanh thì chỉ quan tâm success metrics (chỉ số thành công) có đạt được không. Viết một tài liệu thỏa mãn tất cả các nhóm này cùng lúc, trong khi vẫn giữ được tính súc tích, là kỹ năng cần nhiều năm rèn luyện. AI thay đổi cuộc chơi này không phải bằng cách viết PRD thay bạn, mà bằng cách giúp bạn chuẩn hóa cấu trúc, tăng tốc độ soạn thảo bản nháp đầu tiên, và đảm bảo không bỏ sót phần nào — miễn là bạn biết cách đưa đúng input và review đúng chỗ.
Bài học này sẽ đi từ cách cấu trúc một prompt PRD chuẩn với đầy đủ goals, context, constraints và success metrics, đến kỹ thuật biến ghi chú thô và bản ghi trao đổi stakeholder thành PRD hoàn chỉnh, cách sinh phần technical context làm cầu nối giữa product và engineering, và cuối cùng là quy trình review để PRD thực sự dùng được cho cả hai phía business và kỹ thuật.
Cách Cấu Trúc Một Prompt PRD — Goals, Context, Constraints Và Success Metrics
Một prompt PRD hời hợt sẽ cho ra một PRD hời hợt — đây là quy luật bất biến khi làm việc với AI. Trước khi nghĩ đến việc AI viết gì, bạn cần hiểu bốn thành phần bắt buộc phải có trong bất kỳ prompt PRD nghiêm túc nào.
Bốn Trụ Cột Của Một Prompt PRD Chất Lượng
- Goals (mục tiêu): PRD này giải quyết vấn đề gì, cho ai, và tại sao ngay bây giờ? Nếu goal mơ hồ, AI sẽ viết một PRD nghe hay nhưng không neo vào giá trị kinh doanh thật.
- Context (bối cảnh): sản phẩm hiện tại đang ở đâu, đã có tính năng gì liên quan, đối thủ cạnh tranh đang làm gì, dữ liệu người dùng nào đã có sẵn (từ analytics, khảo sát, phỏng vấn).
- Constraints (ràng buộc): giới hạn kỹ thuật (stack công nghệ hiện tại), giới hạn thời gian (deadline cứng nếu có), giới hạn ngân sách hoặc nhân sự, các ràng buộc pháp lý/compliance nếu có (GDPR, PCI-DSS).
- Success Metrics (chỉ số thành công): làm sao biết tính năng này thành công? Cần con số cụ thể (ví dụ tăng conversion rate 5%, giảm thời gian xử lý ticket 20%), không phải mục tiêu định tính chung chung như "cải thiện trải nghiệm".
Vì Sao Thứ Tự Của 4 Thành Phần Này Quan Trọng
Nhiều PM khi prompt AI viết PRD chỉ đưa vào goal và yêu cầu "viết PRD đầy đủ", để AI tự bịa ra context, constraints, và success metrics. Kết quả là một PRD nghe rất chuyên nghiệp nhưng hoàn toàn không dựa trên thực tế sản phẩm của bạn — một dạng hallucination nghiệp vụ nguy hiểm vì nó "nghe có vẻ đúng". Luôn cung cấp cả 4 trụ cột này một cách tường minh, kể cả khi một số phần còn chưa chắc chắn (trong trường hợp đó, ghi rõ "chưa xác định" thay vì để trống, để AI không tự bịa).
Các Bước Thực Hành
- Soạn một "PRD brief" ngắn 1 trang trước khi prompt AI — chỉ cần gạch đầu dòng cho 4 trụ cột, không cần văn phong hoàn chỉnh.
- Đưa brief này vào AI kèm yêu cầu cấu trúc PRD chuẩn của team bạn (nếu công ty có template PRD riêng, luôn đính kèm template đó để AI theo đúng format, không tự sáng tạo cấu trúc mới).
- Yêu cầu AI liệt kê phần nào trong 4 trụ cột còn thiếu thông tin trước khi viết nội dung đầy đủ — đây là bước kiểm tra chất lượng input trước khi tốn công viết ra một bản PRD không dùng được.
Ví Dụ Prompt
Bạn là một Senior Product Manager chuyên viết PRD cho các sản phẩm SaaS
B2B.
Đây là PRD brief của tôi:
- Goal: Cho phép admin doanh nghiệp tự cấu hình workflow phê duyệt chi
tiêu (approval workflow) nhiều cấp, thay vì chỉ có 1 cấp duyệt cố định
như hiện tại.
- Context: Hiện có 40% khách hàng enterprise yêu cầu tính năng này qua
support ticket trong 3 tháng qua. Đối thủ X đã có tính năng tương tự.
- Constraints: Phải tương thích ngược với workflow 1 cấp hiện tại
(không được breaking change), release trong quý này, team chỉ có 2
backend + 1 frontend.
- Success Metrics: Giảm 30% ticket liên quan đến "không cấu hình được
quy trình duyệt chi", tăng NPS nhóm khách hàng enterprise thêm 10
điểm trong 2 quý.
Trước khi viết PRD đầy đủ, hãy:
1. Liệt kê những thông tin còn thiếu hoặc mơ hồ trong 4 trụ cột trên mà
bạn cần tôi làm rõ thêm.
2. Đề xuất cấu trúc mục lục PRD phù hợp với brief này (không cần viết
nội dung, chỉ liệt kê heading).
Trả lời bằng tiếng Việt.
Mẹo: Luôn yêu cầu AI liệt kê phần thiếu thông tin TRƯỚC khi viết nội dung đầy đủ. Việc này giúp bạn phát hiện lỗ hổng trong tư duy của chính mình trước khi lỗ hổng đó biến thành một đoạn văn PRD "nghe rất thuyết phục nhưng sai".
Dùng AI Tạo PRD Toàn Diện Từ Ghi Chú Thô Và Trao Đổi Với Stakeholder
Trong thực tế, hiếm khi bạn có sẵn một PRD brief gọn gàng như ví dụ trên. Thông thường, bạn có một mớ ghi chú họp, email trao đổi qua lại với stakeholder, vài slide Google Slides cũ, và một Slack thread dài về ý tưởng. AI có thể tổng hợp tất cả nguồn này thành một PRD có cấu trúc, nhưng cần kỹ thuật đúng để tránh mất thông tin quan trọng.
Xử Lý Input Đa Nguồn Và Mâu Thuẫn Giữa Các Stakeholder
Vấn đề thường gặp nhất khi tổng hợp từ nhiều nguồn: các stakeholder khác nhau có thể có quan điểm mâu thuẫn nhau về cùng một tính năng (ví dụ Sales muốn ship nhanh với scope nhỏ, Customer Success muốn scope đầy đủ để giảm ticket). AI có thể giúp bạn nhìn ra những mâu thuẫn này một cách tường minh, thay vì bạn tự đọc và có thể vô tình chọn phe mà không nhận ra.
Các Bước Thực Hành
- Gom toàn bộ raw input vào một tài liệu duy nhất, giữ nguyên attribution (ghi rõ ai nói gì) — đừng tóm tắt trước, để AI tự phân tích trên dữ liệu gốc.
- Yêu cầu AI trích xuất các chủ đề chính và chỉ ra rõ chỗ nào các stakeholder không đồng thuận.
- Xác nhận lại với stakeholder những điểm mâu thuẫn trước khi AI viết PRD đầy đủ — đừng để AI tự chọn phương án nào "hợp lý hơn", vì đó là quyết định kinh doanh, không phải quyết định ngôn ngữ.
- Yêu cầu AI viết PRD đầy đủ dựa trên input đã được làm rõ mâu thuẫn.
Ví Dụ Prompt
Dưới đây là ghi chú thô từ 3 nguồn: (1) transcript họp với Sales,
(2) email trao đổi với Customer Success, (3) Slack thread nội bộ
team Product.
[PASTE TỪNG NGUỒN, GHI RÕ NGUỒN NÀO LÀ NGUỒN NÀO]
Hãy:
1. Trích xuất các yêu cầu/mong muốn chính từ mỗi nguồn.
2. Chỉ ra rõ những điểm các nguồn KHÔNG đồng thuận với nhau (ví dụ về
scope, timeline, hoặc mức độ ưu tiên).
3. KHÔNG tự quyết định phương án nào đúng — chỉ liệt kê rõ ràng để tôi
quyết định.
4. Đề xuất 3 câu hỏi cụ thể tôi nên hỏi lại các bên liên quan để giải
quyết mâu thuẫn trước khi viết PRD chính thức.
Sau khi mâu thuẫn được giải quyết, dùng prompt tiếp theo để sinh PRD đầy đủ:
Dựa trên input đã thống nhất dưới đây, hãy viết PRD đầy đủ theo cấu
trúc: Tổng quan, Vấn đề & Bối cảnh, Mục tiêu & Success Metrics, User
Personas, User Flows chính, Yêu cầu chức năng, Yêu cầu phi chức năng,
Ràng buộc & Rủi ro, Timeline đề xuất, Câu hỏi mở còn tồn đọng.
[PASTE INPUT ĐÃ THỐNG NHẤT]
Với mỗi yêu cầu chức năng, đánh số thứ tự để dễ tham chiếu (FR-1, FR-2,
...) và ghi rõ mức ưu tiên (Must have / Should have / Could have theo
mô hình MoSCoW).
Mẹo: Không bao giờ để AI tự "hòa giải" mâu thuẫn giữa các stakeholder bằng cách chọn một phương án trung dung. Vai trò của PM chính là ra quyết định đó — AI chỉ nên làm nhiệm vụ hiển thị mâu thuẫn rõ ràng để bạn quyết định nhanh hơn, không phải quyết định thay bạn.
Sinh Phần Technical Context Kết Nối Product Và Engineering
Phần khó viết nhất của một PRD, với hầu hết PM không có background kỹ thuật sâu, là technical context — phần giải thích PRD này tương tác thế nào với hệ thống hiện tại, ảnh hưởng đến kiến trúc ra sao, và có rủi ro kỹ thuật gì cần lưu ý sớm. AI có thể giúp bạn viết phần này ở mức đủ để dev đọc hiểu, dù bạn không phải kỹ sư.
Technical Context Nên Bao Gồm Những Gì
- Hệ thống/module bị ảnh hưởng: liệt kê các phần hệ thống hiện tại mà tính năng mới sẽ chạm vào (dựa trên hiểu biết sản phẩm của bạn, không cần chi tiết code).
- Giả định về tích hợp: tính năng có cần tích hợp với hệ thống bên thứ ba không (payment gateway, SSO, CRM)?
- Yêu cầu phi chức năng sơ bộ: hiệu năng (bao nhiêu request/giây), bảo mật (dữ liệu nhạy cảm có liên quan không), khả năng mở rộng (scale cho bao nhiêu user).
- Câu hỏi mở cho engineering: những điểm bạn biết mình chưa đủ kiến thức kỹ thuật để trả lời, cần dev xác nhận.
Các Bước Thực Hành
- Liệt kê các module sản phẩm hiện tại có thể liên quan ở mức hiểu biết của PM (không cần chính xác tuyệt đối).
- Dùng AI để mở rộng thành checklist câu hỏi kỹ thuật cần hỏi engineering lead trước buổi technical review.
- Đưa checklist này vào buổi review kỹ thuật đầu tiên với tech lead, ghi lại câu trả lời.
- Yêu cầu AI viết lại phần technical context dựa trên câu trả lời thực tế từ engineering.
Ví Dụ Prompt
Đây là mô tả tính năng ở mức business:
[PASTE MÔ TẢ TÍNH NĂNG]
Hệ thống hiện tại của chúng tôi là một SaaS B2B, kiến trúc microservice,
có các module chính: Auth, Billing, Workflow Engine, Notification.
Với vai trò một Solutions Architect, hãy:
1. Liệt kê các module trong hệ thống hiện tại có khả năng bị ảnh hưởng
bởi tính năng này, giải thích ngắn gọn tại sao.
2. Đề xuất danh sách 8-10 câu hỏi kỹ thuật tôi (Product Manager không
có nền tảng kỹ thuật sâu) nên hỏi engineering lead trước buổi
technical review, bao phủ: hiệu năng, bảo mật, khả năng tương thích
ngược, độ phức tạp tích hợp.
3. Gợi ý các yêu cầu phi chức năng sơ bộ (performance, security,
scalability) cần đưa vào PRD ở mức "giả định ban đầu, cần
engineering xác nhận".
Trả lời bằng tiếng Việt, giữ thuật ngữ kỹ thuật bằng tiếng Anh.
Mẹo: Luôn đánh dấu rõ trong PRD phần nào là "giả định của Product, cần Engineering xác nhận" và phần nào là "đã được Engineering xác nhận". Việc trộn lẫn hai loại thông tin này là nguyên nhân phổ biến khiến dev mất niềm tin vào PRD do PM viết, vì họ phát hiện ra giả định sai được trình bày như sự thật đã kiểm chứng.
Cách Review Và Tinh Chỉnh PRD Do AI Tạo Để Phù Hợp Với Stakeholder Và Engineering
PRD do AI viết ra ở bản nháp đầu tiên luôn cần một vòng review nghiêm túc trước khi gửi cho các bên liên quan. Vấn đề không phải AI viết sai ngữ pháp, mà là nó có thể viết những câu nghe rất "chắc chắn" về những điều thực ra chưa được xác nhận.
Ba Câu Hỏi Review Bắt Buộc
- Có câu nào trong PRD nghe như sự thật nhưng thực ra là giả định chưa kiểm chứng không? Đây là lỗi nguy hiểm nhất — AI có xu hướng viết mọi thứ với giọng văn tự tin như nhau, dù thông tin gốc là chắc chắn hay chỉ là suy đoán.
- Success metrics có đo được thật không, hay chỉ là con số nghe hợp lý? Nếu bạn không có cách thực sự đo "tăng NPS 10 điểm", con số đó vô nghĩa dù nghe rất chuyên nghiệp.
- PRD có phù hợp với TỪNG đối tượng đọc không? Executive summary có đủ ngắn cho sếp không cần đọc hết? Phần yêu cầu chức năng có đủ chi tiết cho dev estimate không?
Các Bước Thực Hành
- Yêu cầu AI tự đánh dấu (highlight) những câu là giả định chưa được xác nhận trong chính bản PRD nó vừa viết — đây là kỹ thuật self-critique hiệu quả.
- Gửi PRD cho 1 stakeholder kinh doanh và 1 tech lead review song song, thu thập feedback riêng biệt.
- Dùng AI tổng hợp feedback từ cả hai phía thành danh sách chỉnh sửa cụ thể, phân loại theo mức độ ưu tiên.
- Chốt phiên bản final và version nó rõ ràng (PRD v1.0, v1.1...) để tránh nhầm lẫn bản nào là bản mới nhất.
Ví Dụ Prompt
Đây là bản PRD nháp tôi vừa viết (với sự hỗ trợ của AI):
[PASTE PRD ĐẦY ĐỦ]
Hãy tự rà soát lại và:
1. Đánh dấu rõ (bằng cách liệt kê riêng) những câu/đoạn nào trong PRD
là GIẢ ĐỊNH chưa được xác nhận bởi dữ liệu hoặc stakeholder thực tế,
phân biệt với những câu là SỰ THẬT đã được xác nhận.
2. Kiểm tra phần Success Metrics: mỗi metric có nêu rõ cách đo, nguồn
dữ liệu, và baseline hiện tại không? Nếu thiếu, chỉ rõ.
3. Đánh giá xem Executive Summary (nếu có) có thể đọc hiểu trong dưới
2 phút không, có đủ ngắn gọn cho người bận rộn không.
4. Đánh giá xem phần Yêu cầu chức năng có đủ chi tiết để một dev
backend estimate story point mà không cần hỏi lại nhiều lần không.
Trả lời bằng tiếng Việt, dùng bảng nếu phù hợp.
Mẹo: Đừng review PRD một mình. Luôn có ít nhất một cặp mắt kỹ thuật và một cặp mắt kinh doanh đọc qua trước khi PRD được coi là "final" — AI có thể giúp bạn tự phát hiện lỗ hổng, nhưng nó không thay thế được việc con người thật xác nhận thông tin thật.
Những Điểm Chính Cần Nhớ
- Một prompt PRD chất lượng luôn cần đủ 4 trụ cột: Goals, Context, Constraints, Success Metrics — thiếu một trong bốn sẽ khiến AI tự bịa phần còn lại.
- Khi tổng hợp từ nhiều nguồn stakeholder, để AI hiển thị mâu thuẫn rõ ràng thay vì tự "hòa giải" — quyết định kinh doanh luôn thuộc về con người.
- Technical context là cầu nối giữa product và engineering; luôn phân biệt rõ giả định của PM và thông tin đã được engineering xác nhận.
- Success metrics phải đo được thật, có baseline và nguồn dữ liệu rõ ràng, không chỉ là con số nghe hợp lý.
- Luôn review PRD do AI viết qua ít nhất hai góc nhìn: một người kinh doanh, một người kỹ thuật, trước khi coi là bản final.
Mẹo: Xây một template PRD chuẩn cho team và luôn đính kèm template đó khi prompt AI, thay vì để AI tự chọn cấu trúc mỗi lần — sự nhất quán về cấu trúc PRD qua các dự án giúp cả team (kể cả người mới) đọc và review nhanh hơn nhiều.