Mở đầu — vì sao bài này quan trọng
Suốt 49 bài trước, chúng ta đã mổ xẻ từng bộ phận của một PRD: cách viết Problem sắc bén, cách dựng Goals và Non-goals, cách viết acceptance criteria, cách spec cho mobile, AI, permission, analytics, rollout... Mỗi bài là một mảnh ghép. Nhưng có một câu hỏi mà học viên luôn hỏi tôi sau khi học xong từng mảnh: "Vậy ráp tất cả lại thì một PRD hoàn chỉnh trông như thế nào? Thứ tự các mục ra sao? Cái gì đặt trước, cái gì đặt sau?"
Bài này chính là câu trả lời. Đây là bài "tổng lắp ráp" — nơi tôi đưa cho bạn một template PRD đầy đủ, từ dòng tiêu đề đầu tiên đến phần phụ lục cuối cùng, để bạn copy về và dùng ngay trong công việc. Hãy nghĩ về nó như một tờ giấy nến: bạn đặt lên trên bất kỳ tính năng nào và tô theo, thay vì mỗi lần lại ngồi nhìn trang giấy trắng tự hỏi "bắt đầu từ đâu".
Tại sao cần một template chuẩn thay vì mỗi người viết một kiểu? Vì PRD không phải tài liệu cá nhân — nó là tài liệu chung mà engineer, designer, QA, data, legal, support đều phải đọc. Khi cả công ty dùng chung một khung, người đọc biết chính xác chỗ nào tìm thông tin gì: muốn biết phạm vi thì nhảy xuống mục Scope, muốn biết đo lường thì tìm mục Success Metrics. Sự nhất quán này tiết kiệm hàng trăm giờ làm việc mỗi quý. Một template tốt còn là một checklist trá hình: nếu một mục trống, bạn lập tức biết mình đang bỏ sót suy nghĩ ở đâu.
Lưu ý quan trọng: bài này dạy bạn bộ khung và thứ tự, không lặp lại cách viết chi tiết từng mục — vì mỗi mục đã có bài riêng. Khi cần đào sâu một phần, tôi sẽ chỉ bạn về đúng bài tương ứng.
Khái niệm cốt lõi
Một PRD đầy đủ gồm hai phần lớn: Header và Body
Mọi PRD chuyên nghiệp đều tách rõ hai khối: Header (siêu dữ liệu — metadata về chính tài liệu) và Body (nội dung — suy nghĩ về sản phẩm). Header trả lời "tài liệu này là gì, của ai, đang ở trạng thái nào". Body trả lời "chúng ta xây gì và tại sao". Nhầm lẫn hai khối này là lỗi của người mới: họ nhét tên tác giả vào giữa phần giải pháp, hoặc quên ghi trạng thái khiến cả team không biết PRD đã chốt hay chưa.
Header — phần ít chữ nhưng quyết định độ tin cậy
Header chỉ chiếm vài dòng nhưng là thứ người đọc liếc đầu tiên. Một header chuẩn gồm:
- Title (Tiêu đề). Nên nói lên kết quả, không chỉ tên tính năng. "Cho phép thanh toán bằng QR VietQR tại bước checkout" tốt hơn "Tính năng QR".
- Author / DRI. Người chịu trách nhiệm chính (Directly Responsible Individual). Một PRD chỉ nên có một DRI để khỏi rơi vào cảnh "ai cũng phụ trách nghĩa là chẳng ai phụ trách".
- Status. Trạng thái vòng đời: Draft → Review → Approved → Shipped (đôi khi thêm Deprecated). Đây là dòng cứu mạng cả team — nó cho biết có nên tin nội dung bên dưới hay không.
- Date / Version. Ngày cập nhật gần nhất và số phiên bản. PRD là tài liệu sống; thiếu ngày, người đọc không biết nó còn đúng hay đã lỗi thời.
- Stakeholders (RACI). Danh sách các bên liên quan kèm vai trò theo mô hình RACI: Responsible (người làm), Accountable (người chịu trách nhiệm cuối, thường là DRI), Consulted (người được hỏi ý kiến), Informed (người được thông báo). RACI ngăn chặn cảnh "tới lúc ship mới phát hiện chưa hỏi ý Legal".
Body — dòng chảy logic từ "tại sao" đến "làm sao đo"
Body không phải một đống mục rời rạc; nó là một câu chuyện có thứ tự. Thứ tự chuẩn mà tôi khuyên dùng:
- TL;DR (Tóm tắt). 2–4 câu để người bận rộn đọc xong là nắm được toàn cảnh: vấn đề gì, giải pháp gì, cần gì.
- Context / Background (Bối cảnh). Vì sao việc này nổi lên bây giờ. (Chi tiết ở Bài 12.)
- Problem Statement (Phát biểu vấn đề). Vấn đề cốt lõi, sắc và có số liệu. (Bài 3, Bài 13.)
- Goals & Non-goals (Mục tiêu & ngoài phạm vi). Cái gì làm, cái gì cố ý không làm. (Bài 14.)
- Success Metrics & Guardrails (Chỉ số thành công & rào chắn). Đo bằng gì, counter-metric nào để tránh "thắng chỗ này thua chỗ kia". (Bài 15.)
- Personas / JTBD (Chân dung người dùng). Làm cho ai, họ đang cố hoàn thành "việc" gì. (Bài 16, 17.)
- Solution — User-facing behavior (Giải pháp — hành vi người dùng thấy trước). Mô tả trải nghiệm trước khi nói kiến trúc. (Bài 18.)
- User Stories & Acceptance Criteria. (Bài 4, 21.)
- Edge cases & các trạng thái (empty/loading/error/success, offline, race, permission). (Bài 5, 22, 23.)
- Cross-cutting specs. Tùy tính năng: a11y, i18n, deeplink, push, analytics, permission, data schema, AI contract... (Các bài 24–37.)
- Rollout & Launch. Feature flag, experiment, rollout strategy, monitoring, support readiness. (Bài 38–44.)
- Open Questions, Risks, Versioning, Timeline. (Bài 52, 53, 54.)
- Appendix. Link tới mock, RFC, research, dữ liệu.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT "ChợViệt" và sức mạnh của dòng Status
ChợViệt là một sàn thương mại điện tử giả định ở TP.HCM, đội product 8 người. Trước đây mỗi PM viết PRD trong Google Docs theo cách riêng. Hậu quả: một engineer tên Tú đã code suốt 3 ngày dựa trên một PRD mà... PM đã bỏ giữa chừng và chuyển hướng — nhưng tài liệu không hề ghi trạng thái, nên Tú tưởng nó còn hiệu lực. Ba ngày công lập trình đổ sông đổ biển.
Sau sự cố, ChợViệt áp dụng template chuẩn với Header bắt buộc: dòng Status và Date đặt ngay dưới tiêu đề, in đậm. Quy ước nội bộ: engineer không được bắt đầu code khi Status chưa là "Approved". Họ còn thêm một dòng nhỏ: "Last updated: 2026-06-20 — nếu hôm nay cách ngày này hơn 30 ngày, hãy hỏi DRI trước khi tin." Sáu tháng sau, số vụ "code nhầm phiên bản" về 0.
Bài học: Header không phải thủ tục hành chính. Một dòng Status rõ ràng tiết kiệm nhiều ngày công hơn cả chục trang nội dung hay. Template tốt buộc thông tin sống còn này phải xuất hiện.
Ví dụ 2 — Ví điện tử "MoMo-style" và RACI cứu một pha suýt vi phạm
Một fintech ví điện tử (lấy cảm hứng từ MoMo) lên kế hoạch tính năng "Lì xì online" cho dịp Tết. PM viết PRD đầy đủ phần Solution, metrics, edge case — nhưng trong mục Stakeholders (RACI), ô "Consulted" để trống vì bạn ấy nghĩ đây chỉ là tính năng UI.
May mắn, template của công ty có một dòng gợi ý cứng dưới bảng RACI: "Mọi tính năng liên quan chuyển tiền bắt buộc liệt kê Legal và Compliance ở cột Consulted." Dòng nhắc đó khiến PM khựng lại, mời team Compliance vào review. Compliance lập tức chỉ ra: chuyển tiền kèm lời chúc có thể bị xem là một dạng giao dịch cần tuân thủ quy định phòng chống rửa tiền (AML), cần thêm giới hạn 500.000đ/lần và lưu vết người gửi/nhận. Phát hiện ở giai đoạn PRD, fix tốn vài câu chữ. Nếu phát hiện sau khi ship trong mùa Tết cao điểm, đó sẽ là một cơn ác mộng pháp lý.
Bài học: Mục RACI trong Header không chỉ liệt kê tên — nó là cơ chế ép bạn nghĩ về ai cần được hỏi. Một template tốt nhúng sẵn các "luật cứng" theo loại tính năng để người viết không bỏ sót bên liên quan quan trọng.
Ví dụ 3 — Startup logistics và cái bẫy "PRD nào cũng phải đủ 13 mục"
Một startup giao hàng ở Hà Nội, sau khi học được tầm quan trọng của template, đã rơi vào thái cực ngược: bắt mọi PRD, kể cả sửa một dòng chữ trên nút bấm, phải điền đủ 13 mục. Kết quả là PM mất 2 giờ viết PRD cho một thay đổi mất 10 phút code. Tệ hơn, các mục bị điền cho có — "Analytics: N/A", "i18n: N/A", "Rollout: N/A" — khiến PRD trông dài mà rỗng, và engineer bắt đầu lướt qua không đọc vì 80% là rác.
Họ sửa bằng cách chia template thành ba "size": PRD-S (bugfix/thay đổi nhỏ: 4 mục), PRD-M (tính năng vừa: 8 mục), PRD-L (tính năng lớn/đa nền tảng: đủ khung). DRI tự chọn size lúc mở tài liệu. Tỷ lệ engineer đọc kỹ PRD tăng rõ rệt vì độ dài tài liệu khớp với độ phức tạp thật.
Bài học: Template là người hầu, không phải ông chủ. Một template đầy đủ phải đi kèm hướng dẫn khi nào lược bớt. Nhồi nhét mọi mục vào mọi tài liệu giết chết chính giá trị của template.
Hướng dẫn từng bước
Đây là quy trình dùng template để viết một PRD từ con số 0:
- Copy bộ khung, điền Header trước. Tiêu đề (nói kết quả), DRI, Status = Draft, ngày hôm nay, version 0.1. Dựng bảng RACI ngay cả khi còn trống — chỗ trống sẽ tự nhắc bạn còn thiếu ai.
- Viết TL;DR cuối cùng nhưng đặt đầu tiên. Nghịch lý: TL;DR đặt trên đầu Body nhưng nên viết sau khi xong cả tài liệu, vì lúc đó bạn mới chắt được tinh túy. Khi đang nháp, để placeholder "[TL;DR — viết sau]".
- Đi theo dòng chảy "tại sao → cho ai → làm gì → đo sao". Lấp Context → Problem → Goals/Non-goals → Metrics → Personas → Solution → Stories/AC. Đừng nhảy thẳng vào Solution; nếu phần Problem yếu, mọi thứ bên dưới sẽ lung lay.
- Chọn size và cắt mục thừa. Tính năng của bạn có chạm mobile không? AI không? Chuyển tiền không? Đa ngôn ngữ không? Với mỗi "không", xóa mục tương ứng hoặc ghi "N/A — không áp dụng vì...". Đừng để mục rỗng đánh lừa người đọc.
- Rà cross-cutting theo checklist. Lướt qua nhóm a11y, i18n, analytics, permission, data schema, rollout, monitoring, support. Đây là chỗ người mới hay quên. Template tốt liệt kê sẵn để bạn chỉ việc đánh dấu "có cần / không cần".
- Đẩy phần chưa chắc xuống Open Questions, đừng giả vờ đã biết. Một PRD trung thực mạnh hơn một PRD giả vờ hoàn hảo.
- Đổi Status sang Review, mời đúng người trong RACI. Khi đã sẵn sàng, đổi Draft → Review, gửi cho cột Responsible và Consulted. Sau khi chốt, đổi sang Approved kèm ngày — đây là tín hiệu xanh cho engineer bắt đầu.
- Sau khi ship, cập nhật Status = Shipped và link post-launch review. PRD không chết khi ship; nó thành tài liệu lịch sử để team sau tra cứu. (Hậu kiểm ở Bài 49.)
Lỗi thường gặp & mẹo
Lỗi 1 — Thiếu Status và Date. Đây là lỗi phổ biến nhất và nguy hiểm nhất. Không có hai dòng này, không ai biết PRD còn hiệu lực hay đã bị bỏ. Mẹo: đặt Status + Date ngay dưới tiêu đề, in đậm, là dòng đầu tiên người đọc thấy.
Lỗi 2 — Đặt Solution lên trước Problem. PM háo hức nhảy vào mô tả giao diện, đẩy lý do xuống cuối hoặc bỏ luôn. Người duyệt không hiểu vì sao phải làm. Mẹo: ép bản thân viết xong Problem và Goals trước khi gõ một chữ về giải pháp.
Lỗi 3 — RACI để trang trí. Liệt kê tên cho có nhưng không thực sự mời họ review. Mẹo: quy ước nội bộ — Status chỉ được lên "Approved" khi toàn bộ cột Accountable và Consulted đã thực sự bấm duyệt.
Lỗi 4 — Template phình to thành quái vật. Bắt mọi PRD đủ mọi mục, khiến tài liệu dài mà rỗng. Mẹo: dùng cơ chế size S/M/L; thà một PRD 4 mục đầy đủ ý còn hơn 13 mục nửa vời.
Lỗi 5 — Không nhúng "luật cứng" theo loại tính năng. Mẹo: trong template, thêm các dòng nhắc tự động: "Nếu chạm thanh toán → bắt buộc Legal ở Consulted"; "Nếu thu thập dữ liệu cá nhân → bắt buộc mục Privacy". Những lời nhắc nhúng sẵn cứu bạn khỏi điểm mù.
Mẹo vàng: Lưu template trong một file mẫu (Notion template, Google Docs template, hoặc repo nội bộ) để cả team "New from template" chỉ một cú nhấp. Khi template là mặc định, sự nhất quán xảy ra tự nhiên mà không cần ép buộc.
Bài tập thực hành
- Dựng template của riêng bạn. Mở một tài liệu trắng, tạo Header (Title, DRI, Status, Date/Version, bảng RACI 4 cột) và Body với 13 tiêu đề mục theo thứ tự ở trên. Lưu lại làm file mẫu — đây sẽ là công cụ bạn dùng suốt sự nghiệp.
- Áp template vào một tính năng thật. Chọn một tính năng nhỏ bạn đang/từng làm (ví dụ: "thêm đăng nhập bằng số điện thoại"). Điền đầy đủ Header và TL;DR, Problem, Goals/Non-goals, Solution, Acceptance Criteria. Với các mục không liên quan, ghi "N/A — vì..." thay vì xóa. Quan sát: có mục nào để trống khiến bạn nhận ra mình chưa nghĩ tới?
- Thiết kế ba size. Định nghĩa rõ PRD-S, PRD-M, PRD-L cho team của bạn: mỗi size gồm những mục nào, dùng cho loại thay đổi nào. Viết một dòng tiêu chí quyết định size.
- Thêm 3 "luật cứng". Nghĩ về sản phẩm của bạn và viết 3 dòng nhắc nhúng sẵn vào template (ví dụ: "Nếu tính năng gửi push → bắt buộc mục Push Spec"; "Nếu chạm dữ liệu thanh toán → bắt buộc Compliance review"). Đây chính là cách bạn biến template thành một tấm lưới an toàn.
Tóm tắt
Một PRD đầy đủ gồm hai khối: Header (Title, DRI, Status, Date/Version, RACI) cho biết tài liệu là gì và đáng tin đến đâu, và Body kể câu chuyện theo dòng chảy logic: TL;DR → Context → Problem → Goals/Non-goals → Metrics → Personas → Solution → Stories/AC → Edge cases → Cross-cutting specs → Rollout → Open Questions/Risks → Appendix. Dòng Status và Date tuy ngắn nhưng cứu nhiều ngày công; bảng RACI ép bạn nghĩ về ai cần được hỏi trước khi quá muộn.
Quan trọng nhất: template là thực đơn, không phải mệnh lệnh. Hãy chọn đúng size cho độ phức tạp, cắt mục thừa nhưng ghi rõ "N/A — vì sao", và nhúng sẵn các "luật cứng" để khỏi rơi vào điểm mù. Một template chuẩn biến trang giấy trắng đáng sợ thành một danh sách bạn chỉ việc tô theo — và biến PRD từ tài liệu cá nhân thành ngôn ngữ chung của cả tổ chức. Ở các bài tiếp theo, chúng ta sẽ đi sâu hơn vào các tài liệu chuyên biệt (B2B, versioning, risk register) cũng như cách viết để PRD của bạn được duyệt.