Mở đầu — vì sao bài này quan trọng
Trong các bài trước, bạn đã học cách viết BRD, FRD và SRS — những tài liệu đầy đủ, chi tiết, thường gắn với mô hình phát triển truyền thống (waterfall). Nhưng nếu bạn đang làm việc trong một đội Agile — sprint hai tuần, backlog liên tục thay đổi, sản phẩm tiến hóa từng phiên bản — thì những tài liệu dày 40 trang ấy nhanh chóng trở nên lỗi thời ngay khi bạn vừa viết xong. Đó là lúc PRD (Product Requirements Document) bước vào.
PRD không phải là "BRD phiên bản ngắn". Nó là một loại tài liệu có triết lý hoàn toàn khác: thay vì cố gắng đặc tả từng dòng hành vi của hệ thống, PRD tập trung trả lời hai câu hỏi cốt lõi — chúng ta đang xây cái gì (what) và tại sao lại xây cái đó (why). Phần "làm thế nào" (how) được để dành cho đội phát triển và đội thiết kế, những người gần với giải pháp kỹ thuật nhất.
Với một BA làm việc trong môi trường product (sản phẩm), PRD thường là tài liệu trung tâm mà cả product manager, designer và developer cùng tham chiếu hằng ngày. Viết PRD tốt nghĩa là cả đội cùng hiểu một hướng, giảm họp hành vô nghĩa, giảm rework. Viết PRD tệ nghĩa là dev hỏi đi hỏi lại "cái này để làm gì?", designer vẽ sai luồng, và sprint review trở thành buổi tranh cãi. Bài này sẽ giúp bạn viết một PRD vừa đủ chặt để định hướng, vừa đủ mềm để tiến hóa cùng sản phẩm Agile.
Khái niệm cốt lõi
PRD là gì và khác gì với BRD/SRS
PRD là tài liệu mô tả sản phẩm hoặc tính năng cần xây dựng dưới góc nhìn người dùng và mục tiêu kinh doanh. Nó tập trung vào giá trị (value), vấn đề cần giải quyết (problem), và kết quả mong đợi (outcome) — chứ không phải vào đặc tả kỹ thuật chi tiết.
Hãy phân biệt nhanh để khỏi nhầm với các bài trước:
- BRD trả lời "doanh nghiệp cần gì và vì sao" ở tầng chiến lược, thường do bên kinh doanh sở hữu.
- FRD/SRS trả lời "hệ thống phải làm chính xác những gì" ở tầng kỹ thuật, rất chi tiết, ổn định, ít thay đổi.
- PRD đứng ở giữa và nghiêng về sản phẩm: "người dùng có vấn đề gì, ta sẽ giải quyết ra sao ở mức sản phẩm, thành công đo bằng gì". PRD sống động, được cập nhật liên tục theo từng iteration.
Đặc trưng "Agile-friendly" của PRD
PRD trong môi trường Agile có vài đặc điểm khiến nó khác hẳn tài liệu truyền thống:
1. Tiến hóa (evolving), không đóng băng. PRD không phải ký một lần rồi khóa lại. Nó là tài liệu sống, được điều chỉnh khi đội học được điều mới từ người dùng, từ data, từ kết quả của các sprint trước. Nhiều đội đặt PRD trên Confluence hoặc Notion thay vì file Word đính kèm email, chính vì cần sửa liên tục.
2. Mỏng nhưng đủ (lean but sufficient). Triết lý là "vừa đủ tài liệu để cả đội cùng hiểu, không hơn". Một PRD Agile tốt thường chỉ 3–8 trang, tập trung vào vấn đề và mục tiêu, để lại không gian cho đội tự quyết định chi tiết triển khai.
3. Gắn với metric đo lường. PRD Agile luôn đi kèm tiêu chí thành công (success metrics): tỉ lệ chuyển đổi, thời gian hoàn thành tác vụ, số lượng người dùng quay lại... Không có metric thì không biết khi nào tính năng được coi là "thành công".
4. Phân rã được thành backlog. Một PRD tốt phải dễ dàng bẻ thành các epic, sau đó thành user story và đưa vào sprint backlog. Nếu PRD viết xong mà product owner không biết cách tạo story từ nó, PRD đó chưa đạt.
Các thành phần chuẩn của một PRD Agile
Không có một template duy nhất đúng tuyệt đối, nhưng một PRD Agile chỉn chu thường gồm các phần sau:
- Tổng quan & Bối cảnh (Overview & Context): Một đoạn ngắn nói rõ tính năng/sản phẩm này là gì, đặt trong bối cảnh nào.
- Vấn đề & Cơ hội (Problem & Opportunity): Người dùng hoặc doanh nghiệp đang gặp khó khăn gì? Vì sao đáng giải quyết bây giờ?
- Mục tiêu & Phi mục tiêu (Goals & Non-goals): Phần "non-goals" cực kỳ quan trọng — nói rõ những gì ta cố tình không làm trong phạm vi này, để tránh scope creep (phình phạm vi).
- Đối tượng người dùng & Persona: Ai sẽ dùng? Liên hệ với customer journey và persona đã học ở các bài trước.
- Yêu cầu / User stories cấp cao (High-level requirements): Mô tả ở mức "what", thường dạng story hoặc bullet, kèm mức ưu tiên (P0/P1/P2 hoặc MoSCoW).
- Success metrics: Cách đo thành công, có con số mục tiêu cụ thể.
- Phạm vi & Phát hành (Scope & Release): Cái gì vào MVP, cái gì để phase sau.
- Open questions & Dependencies: Câu hỏi còn để mở và các phụ thuộc (đội khác, hệ thống khác, đối tác thứ ba).
Tình huống thực tế
Ví dụ 1 — Tính năng "Mua trước trả sau" của một sàn TMĐT Việt Nam
Giả sử bạn là BA tại một sàn thương mại điện tử tầm trung ở TP.HCM, đang muốn ra mắt tính năng "Mua trước trả sau" (Buy Now Pay Later) hợp tác với một công ty fintech.
PRD bạn viết mở đầu bằng phần Problem: "Khảo sát 1.200 người dùng cho thấy 38% từng bỏ giỏ hàng có giá trị trên 2 triệu đồng vì không đủ tiền mặt tại thời điểm mua. Tỉ lệ chuyển đổi ở nhóm giỏ hàng giá trị cao chỉ 11%, thấp hơn nhiều mức 24% của giỏ hàng dưới 500 nghìn."
Phần Goals: tăng tỉ lệ chuyển đổi của nhóm giỏ hàng trên 2 triệu lên 18% trong quý đầu. Phần Non-goals: "Phiên bản này KHÔNG xử lý tranh chấp hoàn tiền tự động, KHÔNG hỗ trợ trả góp cho đơn hàng quốc tế." Chính dòng non-goals này về sau cứu cả đội: khi một stakeholder đề nghị thêm hoàn tiền tự động giữa sprint, product owner chỉ cần trỏ vào PRD và nói "đó là non-goal phase này".
Phần Success metrics: tỉ lệ chuyển đổi nhóm mục tiêu, tỉ lệ duyệt hồ sơ BNPL thành công, tỉ lệ nợ xấu dưới 3%. Phần High-level requirements liệt kê 5 story cấp cao, gắn nhãn P0 cho "người dùng chọn BNPL ở bước thanh toán" và P2 cho "xem lịch sử các kỳ trả".
Bài học: một PRB mạnh nhờ phần Problem có số liệu thật và phần Non-goals rõ ràng. Chính hai phần này, chứ không phải đặc tả kỹ thuật, là thứ giữ cho cả đội đi đúng hướng qua nhiều sprint.
Ví dụ 2 — Grab và bài toán PRD cho nhiều thị trường
Hãy hình dung một PRD kiểu Grab cho tính năng "đặt xe theo lịch hẹn" (scheduled rides). Grab hoạt động ở nhiều nước Đông Nam Á, nên PRD của họ buộc phải xử lý một thực tế: cùng một tính năng nhưng hành vi người dùng ở Việt Nam, Indonesia và Singapore rất khác nhau.
Trong PRD, phần Personas mô tả ba nhóm: dân văn phòng Singapore đặt xe đi sân bay từ tối hôm trước, người dùng Jakarta đặt trước để né kẹt xe giờ cao điểm, và người dùng TP.HCM thường đặt sát giờ hơn. Phần Requirements vì thế tách rõ phần lõi (đặt lịch, nhắc nhở, gán tài xế trước giờ chạy) khỏi phần tùy biến theo thị trường (khung giờ cho phép, phụ phí).
Quan trọng nhất là phần Open questions & Dependencies: PRD ghi rõ "phụ thuộc vào đội Pricing để xác định phụ phí đặt trước theo từng nước" và "câu hỏi mở: gán tài xế trước bao lâu là tối ưu — cần A/B test". PRD không cố trả lời tất cả; nó thành thật đánh dấu những gì chưa biết để đội cùng giải quyết qua các iteration.
Bài học: trong sản phẩm đa thị trường, PRD tốt biết tách phần lõi không đổi khỏi phần biến thiên theo bối cảnh, và dùng mục Open questions như một hàng đợi việc cần làm rõ — đúng tinh thần Agile "tiến hóa dần".
Ví dụ 3 — PRD một trang cho startup giai đoạn đầu
Một startup edtech ở Hà Nội với đội 6 người muốn thêm tính năng "học nhóm livestream". BA của họ không viết PRD 8 trang — họ dùng mẫu one-page PRD: một trang Notion chia bốn ô — Vấn đề, Mục tiêu & Metric, Phạm vi MVP, Câu hỏi mở.
Phần Metric ghi đúng một con số: "ít nhất 200 buổi học nhóm được tạo trong 30 ngày đầu". Phần Phạm vi MVP cố tình cắt gọn: chỉ cho tối đa 4 người/nhóm, chưa có ghi hình lại, chưa có chia sẻ màn hình. Cả đội đọc hết PRD trong 5 phút và bắt tay vào sprint ngay chiều hôm đó.
Bài học: độ dài PRD phải tỉ lệ với độ phức tạp và rủi ro, không phải với tham vọng. Với startup chạy nhanh, một trang giấy rõ ràng còn giá trị hơn một tài liệu hoành tráng mà không ai đọc.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để viết một PRD Agile từ con số không:
Bước 1 — Làm rõ vấn đề trước khi nghĩ giải pháp. Bắt đầu bằng câu hỏi "người dùng hoặc doanh nghiệp đang đau ở đâu?". Thu thập bằng chứng: số liệu từ analytics, phản hồi khách hàng, kết quả phỏng vấn. Viết phần Problem dựa trên dữ liệu, không dựa trên cảm tính. Nếu bạn không nêu được con số nào, hãy quay lại bước elicitation.
Bước 2 — Viết Goals và Non-goals. Đặt 1–3 mục tiêu chính, mỗi mục tiêu nên đo được. Sau đó liệt kê Non-goals — đây là bước hay bị bỏ qua nhưng quyết định chất lượng PRD. Hỏi "stakeholder dễ hiểu nhầm rằng ta sẽ làm gì mà thực ra ta không làm?" và viết chúng ra.
Bước 3 — Mô tả người dùng và bối cảnh. Liên kết với persona và customer journey. Nêu rõ ai dùng, dùng trong hoàn cảnh nào, trên thiết bị gì. Bối cảnh càng cụ thể, đội thiết kế càng ít đoán mò.
Bước 4 — Liệt kê yêu cầu cấp cao kèm ưu tiên. Viết ở mức "what", dạng user story hoặc bullet. Gắn mức ưu tiên (P0/P1/P2 hoặc Must/Should/Could). Đừng sa vào chi tiết kỹ thuật — nếu bạn thấy mình đang viết tên cột database, bạn đã đi quá xa khỏi PRD.
Bước 5 — Xác định success metrics. Mỗi mục tiêu cần ít nhất một metric với con số mục tiêu và mốc thời gian. Phân biệt metric dẫn dắt (leading, ví dụ số người bấm thử) và metric kết quả (lagging, ví dụ doanh thu tăng).
Bước 6 — Khoanh vùng phạm vi MVP và release plan. Quyết định cái gì vào bản phát hành đầu, cái gì để phase sau. Đây là nơi PRD gặp Agile: bạn chia thành các lát cắt giá trị (vertical slices) có thể ship độc lập.
Bước 7 — Ghi Open questions & Dependencies. Thành thật liệt kê những gì chưa biết và phụ thuộc vào ai. Đừng giả vờ đã có mọi câu trả lời.
Bước 8 — Review với đội rồi phân rã thành backlog. Đưa PRD cho product owner, dev lead, designer đọc và phản biện. Sau khi thống nhất, chuyển PRD thành epic và user story trên công cụ quản lý (Jira/Confluence). PRD vẫn nằm đó như tài liệu tham chiếu, được cập nhật khi học được điều mới.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết PRD như một bản SRS thu nhỏ. Nhiều BA mới quen tài liệu chi tiết nên sa đà mô tả từng validation, từng error message trong PRD. Hậu quả: PRD dài, cứng, và lỗi thời ngay khi giải pháp thay đổi. Mẹo: mỗi khi bạn định viết một chi tiết "how", hãy tự hỏi "điều này có thay đổi cách đội hiểu what/why không?" Nếu không, để dành nó cho story hoặc thiết kế.
Lỗi 2 — Bỏ qua Non-goals. Không nêu phi mục tiêu là nguyên nhân số một của scope creep. Mẹo: luôn dành một mục riêng cho Non-goals, và cập nhật nó mỗi khi có ai đó đề nghị thêm thứ nằm ngoài phạm vi.
Lỗi 3 — Mục tiêu không đo được. "Cải thiện trải nghiệm người dùng" không phải mục tiêu — nó không đo được. Mẹo: mỗi goal phải đi kèm một metric và con số. Nếu không nghĩ ra cách đo, có thể mục tiêu đó chưa đủ rõ.
Lỗi 4 — Coi PRD là tài liệu ký một lần. Trong Agile, PRD phải tiến hóa. Mẹo: đặt PRD trên nền tảng sửa được (Confluence/Notion), ghi changelog ở cuối, và review lại sau mỗi vài sprint.
Lỗi 5 — PRD không ai đọc. Tài liệu hoàn hảo mà cả đội bỏ qua thì vô giá trị. Mẹo: viết ngắn, đặt phần Problem và Goals lên đầu, dùng bảng và bullet thay vì đoạn văn dài. Đo độ thành công của PRD bằng việc dev có ngừng hỏi "cái này để làm gì?" hay không.
Mẹo nâng cao: dùng cấu trúc "Problem → Goal → Metric → Solution sketch" cho từng yêu cầu lớn. Khi mỗi khối yêu cầu đều truy được ngược về một vấn đề và một metric, PRD của bạn tự nhiên có tính traceability — thứ bạn sẽ học sâu hơn ở bài về traceability matrix.
Bài tập thực hành
Bài tập 1 — Viết PRD một trang. Chọn một tính năng quen thuộc của một ứng dụng Việt Nam bạn hay dùng (ví dụ: tính năng "chia hóa đơn" của một ví điện tử). Viết một PRD một trang gồm bốn phần: Problem (kèm ít nhất một số liệu giả định hợp lý), Goals & Non-goals, High-level requirements (3–5 story có ưu tiên), và Success metrics (ít nhất một con số mục tiêu).
Bài tập 2 — Phân biệt what và how. Lấy 10 câu trong một tài liệu yêu cầu bất kỳ (hoặc tự viết 10 câu), phân loại từng câu là "what/why" (thuộc về PRD) hay "how" (thuộc về thiết kế/story). Giải thích vì sao. Mục tiêu là rèn phản xạ nhận ra khi nào mình đang viết quá chi tiết.
Bài tập 3 — Phân rã PRD thành backlog. Lấy PRD ở Bài tập 1, chuyển nó thành 1–2 epic và 4–6 user story sẵn sàng đưa vào sprint. Với mỗi story, viết một dòng acceptance criteria ở mức cao. Quan sát xem PRD của bạn có "phân rã được" dễ dàng không — nếu thấy chật vật, hãy quay lại làm rõ PRD.
Tóm tắt
PRD là tài liệu định nghĩa what + why của một sản phẩm hay tính năng, được viết theo tinh thần Agile: mỏng nhưng đủ, tiến hóa liên tục, gắn chặt với metric đo lường, và dễ phân rã thành backlog. Nó khác BRD ở chỗ nghiêng về sản phẩm và người dùng, khác SRS ở chỗ không sa vào đặc tả kỹ thuật chi tiết.
Một PRD tốt luôn bắt đầu từ vấn đề có bằng chứng, đặt mục tiêu đo được, nêu rõ phi mục tiêu để chống scope creep, và thành thật đánh dấu những câu hỏi còn mở. Ba ví dụ — tính năng BNPL của sàn TMĐT, PRD đa thị trường kiểu Grab, và one-page PRD của startup — cho thấy độ dài và độ chi tiết của PRD phải tỉ lệ với độ phức tạp, chứ không phải với tham vọng.
Khi viết PRD, hãy luôn giữ kỷ luật: mô tả "cái gì" và "vì sao", để "làm thế nào" cho đội thiết kế và phát triển. Đó chính là điều khiến PRD trở thành tài liệu trung tâm hiệu quả của một đội product Agile, thay vì một tập giấy không ai đọc.