Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười Product Manager về tài liệu nào khiến họ "đau đầu" nhất, có lẽ tám người sẽ trả lời: PRD. Không phải vì PRD khó viết về mặt câu chữ, mà vì nó là nơi mọi sự mơ hồ trong đầu bạn bị phơi bày ra giấy. Khi bạn còn nói chuyện miệng, bạn có thể "lươn lẹo" qua những chỗ chưa nghĩ kỹ. Nhưng khi phải viết một PRD, bạn buộc phải trả lời: Vấn đề chính xác là gì? Thành công trông như thế nào? Cái gì nằm ngoài phạm vi? Đây chính là lúc một PM giỏi tách biệt khỏi một PM làng nhàng.
PRD — Product Requirements Document, hay tài liệu yêu cầu sản phẩm — là bản hợp đồng tinh thần giữa bạn và đội ngũ kỹ sư, thiết kế, kinh doanh. Nó không chỉ mô tả "xây cái gì", mà quan trọng hơn, nó giải thích "vì sao đáng để xây" và "làm sao biết ta đã thắng". Trong thực tế tại các công ty công nghệ Việt Nam như MoMo, Tiki hay VNG, một PRD tốt có thể tiết kiệm hàng tuần làm lại (rework), trong khi một PRD tệ khiến cả team lao vào code rồi nhận ra mình giải sai bài toán sau ba tháng.
Bài học này sẽ giúp bạn nắm vững cấu trúc một PRD hiện đại — gọn gàng, tập trung vào vấn đề thay vì đặc tả dày cộp kiểu cũ — và biết cách viết sao cho người đọc tin tưởng và hành động được. Lưu ý: bài này tập trung riêng vào tài liệu PRD và cách cấu trúc nó. Các chủ đề liên quan như framework ưu tiên (RICE, Kano) hay roadmapping sẽ được đề cập sâu ở các bài riêng.
Khái niệm cốt lõi
PRD hiện đại khác PRD truyền thống thế nào
PRD kiểu cũ (đặc biệt thời waterfall) thường là tài liệu hàng chục trang, liệt kê từng đặc tả kỹ thuật, từng nút bấm, từng trường dữ liệu. Vấn đề là: thị trường thay đổi nhanh hơn tốc độ bạn viết xong tài liệu đó. PRD hiện đại — theo tinh thần mà Marty Cagan, Lenny Rachitsky hay các đội product tại Spotify, Stripe cổ vũ — mỏng hơn, sống động hơn, và đặt câu hỏi "tại sao" lên trước câu hỏi "cái gì".
Nguyên tắc vàng: PRD mô tả vấn đề và kết quả mong muốn, không mô tả giải pháp chi tiết. Giải pháp chi tiết thuộc về thiết kế và kỹ thuật — đó là chuyên môn của họ, hãy để họ tỏa sáng. Vai trò của bạn là định khung bài toán thật sắc bén để team không lạc hướng.
Cấu trúc một PRD chuẩn
Một PRD hiện đại thường gồm các phần sau. Bạn không cần cứng nhắc theo thứ tự, nhưng đừng bỏ phần nào:
1. Problem statement (Tuyên bố vấn đề) — Đây là trái tim của PRD. Viết một đoạn ngắn gọn nêu rõ vấn đề của người dùng hoặc của doanh nghiệp, kèm bằng chứng (evidence). Bằng chứng có thể là dữ liệu định lượng (ví dụ "35% người dùng bỏ giỏ hàng ở bước nhập địa chỉ"), trích dẫn phỏng vấn người dùng, hoặc ticket support lặp đi lặp lại. Không có bằng chứng, problem statement chỉ là ý kiến cá nhân.
2. Goal & Non-goal (Mục tiêu & Ngoài phạm vi) — Goal nêu rõ thành công trông như thế nào, kèm success metric (chỉ số đo lường thành công) cụ thể. Ví dụ: "Giảm tỷ lệ bỏ giỏ hàng ở bước thanh toán từ 35% xuống dưới 25% trong vòng 8 tuần." Non-goal cũng quan trọng không kém — nó nói rõ những gì bạn cố tình không làm lần này. Non-goal bảo vệ team khỏi scope creep (phình phạm vi). Ví dụ: "Lần này không tối ưu luồng đăng ký tài khoản mới."
3. Context & Background (Bối cảnh) — Vì sao là bây giờ? Có thay đổi gì về thị trường, đối thủ, hay chiến lược công ty khiến vấn đề này trở nên cấp thiết? Phần này giúp người đọc hiểu "tại sao ưu tiên việc này lúc này".
4. User & Use cases (Người dùng & Tình huống sử dụng) — Ai là người chịu ảnh hưởng? Mô tả họ qua một vài kịch bản cụ thể, lý tưởng là dạng câu chuyện ngắn hoặc user story: "Là một người bán hàng nhỏ lẻ, tôi muốn… để tôi có thể…".
5. Requirements (Yêu cầu) — Liệt kê những gì giải pháp phải đáp ứng, thường chia theo mức độ: must-have, should-have, nice-to-have. Mô tả ở mức kết quả mong muốn chứ không phải chỉ định kỹ thuật. Ví dụ tốt: "Người dùng phải hoàn tất thanh toán mà không rời khỏi trang". Ví dụ tồi: "Đặt nút màu xanh #00B14F ở góc dưới phải".
6. Success metrics (Chỉ số thành công) — Định nghĩa rõ chỉ số chính (primary metric), chỉ số phụ (secondary), và guardrail metrics — những chỉ số không được phép xấu đi (ví dụ: tăng chuyển đổi nhưng tỷ lệ hoàn tiền không được tăng).
7. Open questions & Risks (Câu hỏi mở & Rủi ro) — Một PRD trung thực luôn thừa nhận những gì chưa chắc chắn. Ghi rõ giả định (assumption) cần kiểm chứng và rủi ro tiềm ẩn.
8. Appendix (Phụ lục) — Link tới wireframe, kết quả nghiên cứu, phân tích dữ liệu, để người đọc đào sâu khi cần mà phần thân vẫn gọn.
PRD là tài liệu sống
Đừng nghĩ PRD viết một lần rồi đóng băng. Nó là tài liệu sống (living document): khi team học được điều mới trong quá trình build, bạn cập nhật. Phần "Changelog" ở đầu hoặc cuối PRD ghi lại ai sửa gì, khi nào — giúp mọi người đồng bộ và không tranh cãi về "bản nào mới nhất".
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT giả định "ChợViệt" và bài học về Problem statement
ChợViệt là một sàn thương mại điện tử giả định tại TP.HCM. Một PM mới tên Linh được giao "cải thiện tính năng tìm kiếm". Bản PRD đầu tiên của Linh mở đầu bằng: "Chúng ta cần làm cho tìm kiếm tốt hơn vì người dùng phàn nàn." Sếp của Linh trả lại ngay với một câu hỏi: "Bằng chứng đâu? Tốt hơn nghĩa là gì?"
Linh quay lại đào dữ liệu và phát hiện: 42% lượt tìm kiếm bằng tiếng Việt có dấu trả về 0 kết quả vì hệ thống không xử lý được dấu. Cô viết lại problem statement: "42% truy vấn tìm kiếm trả về 0 kết quả do hệ thống không chuẩn hóa dấu tiếng Việt; nhóm này có tỷ lệ rời bỏ phiên cao gấp 3 lần. Mỗi tháng ước tính mất 1,2 tỷ đồng GMV." Goal: "Giảm tỷ lệ tìm kiếm 0-kết-quả từ 42% xuống dưới 10% trong 6 tuần." Non-goal: "Chưa làm gợi ý sản phẩm (recommendation) lần này."
Bài học: Problem statement không có dữ liệu chỉ là cảm tính. Khi Linh gắn vấn đề với con số doanh thu, cả ban lãnh đạo lập tức ưu tiên dự án. Bản PRD thứ hai được duyệt trong một cuộc họp 20 phút, trong khi bản đầu tiên đã bị bỏ xó.
Ví dụ 2 — Startup fintech và sức mạnh của Non-goal
Một startup fintech giả định tên "VíNhanh" muốn xây tính năng chuyển tiền giữa bạn bè. PM viết PRD và liệt kê hàng loạt thứ: chuyển tiền, chia hóa đơn, nhắc nợ, lịch sử giao dịch, sticker chúc mừng, tích điểm thưởng. Đội kỹ sư ước lượng phải mất 4 tháng.
Trong buổi review, một engineer senior hỏi: "Vấn đề cốt lõi ta đang giải là gì?" Câu trả lời: người dùng thấy phiền khi phải nhập số tài khoản dài dòng để chuyển tiền cho bạn. Vậy là PM cắt mạnh phần Non-goal: "Lần này KHÔNG làm chia hóa đơn, nhắc nợ, sticker, tích điểm. Chỉ làm: chuyển tiền qua số điện thoại danh bạ." Phạm vi co lại còn 5 tuần.
Kết quả: bản MVP ra mắt sớm, đạt 60.000 lượt chuyển trong tháng đầu, và dữ liệu thực tế cho thấy tính năng "chia hóa đơn" mà họ định làm thật ra ít người cần — thứ người dùng muốn tiếp theo là "chuyển tiền theo nhóm". Nếu không có phần Non-goal kỷ luật, họ đã lãng phí hai tháng xây thứ sai.
Bài học: Non-goal không phải dấu hiệu của sự lười biếng — nó là biểu hiện của tư duy chiến lược. Một PM giỏi nói "không" với 9 ý tưởng để dồn lực cho 1 ý tưởng đúng.
Ví dụ 3 — Grab và Success metric kèm guardrail
Tại một đội product làm về tài xế (giả định dựa trên bối cảnh Grab khu vực Đông Nam Á), team muốn ra mắt tính năng "gợi ý điểm đón đông khách" để tài xế kiếm được nhiều cuốc hơn. PRD đặt success metric: "Tăng số cuốc trung bình mỗi tài xế/giờ thêm 8%."
Nhưng một PM kỳ cựu thêm vào phần guardrail metric: "Thời gian chờ của khách không được tăng quá 5%, và mức độ hài lòng của tài xế (driver NPS) không được giảm." Quả nhiên, trong giai đoạn thử nghiệm A/B, số cuốc tăng đúng như kỳ vọng nhưng thời gian chờ của khách tăng vọt 12% vì tài xế dồn về vài điểm nóng, bỏ trống các khu vực khác. Nhờ có guardrail, team phát hiện sớm và điều chỉnh thuật toán trước khi rollout toàn bộ.
Bài học: Một success metric đơn lẻ rất dễ bị "đánh lừa". Luôn đi kèm guardrail metrics để đảm bảo bạn không tối ưu một chỉ số bằng cách phá hỏng chỉ số khác.
Hướng dẫn từng bước
Đây là quy trình thực tế để viết một PRD từ con số 0:
Bước 1 — Đào vấn đề trước khi đụng tới giải pháp. Dành thời gian thu thập bằng chứng: dữ liệu analytics, ticket support, phỏng vấn người dùng. Viết problem statement và đọc to lên — nếu nghe vẫn mơ hồ, bạn chưa hiểu vấn đề đủ sâu.
Bước 2 — Xác định Goal và Success metric. Trả lời: "Sau khi xong việc này, con số nào thay đổi và thay đổi bao nhiêu?" Đặt mục tiêu cụ thể, có thời hạn. Tránh mục tiêu kiểu "cải thiện trải nghiệm" — không đo được thì không quản được.
Bước 3 — Viết Non-goal ngay lập tức. Đừng để đến cuối. Khi vừa xác định goal, hãy lập tức ghi ra những gì không làm. Đây là tấm khiên chống scope creep.
Bước 4 — Mô tả người dùng và use case. Dùng user story hoặc kịch bản cụ thể. Hình dung một người dùng thật và kể câu chuyện của họ.
Bước 5 — Liệt kê Requirements theo mức kết quả. Phân loại must/should/nice-to-have. Mô tả "cần đạt được gì" chứ không phải "làm thế nào". Để khoảng trống cho thiết kế và kỹ thuật sáng tạo.
Bước 6 — Ghi Open questions và Risks. Trung thực về những gì chưa chắc chắn. Mỗi assumption nên có kế hoạch kiểm chứng.
Bước 7 — Review chéo (cross-functional review). Gửi PRD cho engineer lead, designer, data, và stakeholder kinh doanh trước khi chốt. Mục tiêu của review không phải để được khen, mà để bị "đập" — càng nhiều câu hỏi khó càng tốt.
Bước 8 — Cập nhật liên tục. Khi build, sẽ có điều bất ngờ. Ghi changelog và cập nhật PRD. Một PRD lỗi thời còn nguy hiểm hơn không có PRD.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết giải pháp thay vì vấn đề. Nhiều PM nhảy thẳng vào "ta sẽ làm nút này, màn hình kia". Hậu quả: bóp nghẹt sáng tạo của team và dễ giải sai bài toán. Mẹo: Mỗi khi viết một requirement, tự hỏi "đây là kết quả mong muốn hay là cách thực hiện?". Nếu là cách thực hiện, lùi lại một bậc.
Lỗi 2 — Problem statement không có bằng chứng. "Người dùng muốn cái này" — bạn lấy đâu ra? Mẹo: Quy tắc cá nhân: không câu nào trong problem statement được tồn tại nếu không có dữ liệu, trích dẫn, hoặc quan sát thực tế chống lưng.
Lỗi 3 — Bỏ qua Non-goal. PRD không có Non-goal gần như chắc chắn sẽ phình to. Mẹo: Bắt buộc mỗi PRD có ít nhất ba Non-goal.
Lỗi 4 — Success metric mơ hồ hoặc đơn lẻ. "Tăng engagement" là vô nghĩa. Engagement đo bằng gì? Mẹo: Mỗi metric phải có công thức tính rõ ràng và luôn kèm guardrail.
Lỗi 5 — PRD dài lê thê không ai đọc. Tài liệu 30 trang sẽ bị lướt qua. Mẹo: Giữ phần thân ngắn (lý tưởng 1–3 trang), đẩy chi tiết vào Appendix. Nếu engineer phải đọc quá 10 phút mới hiểu bạn muốn gì, PRD đã thất bại.
Lỗi 6 — Viết PRD một mình trong góc. PRD viết kín cửa rồi "ném qua tường" cho engineer là công thức gây mâu thuẫn. Mẹo: Lôi kéo engineer và designer tham gia từ giai đoạn đào vấn đề, không phải khi đã chốt.
Mẹo vàng: Trước khi gửi PRD đi, hãy đưa cho một đồng nghiệp không liên quan đọc trong 5 phút rồi hỏi: "Theo bạn, ta đang giải vấn đề gì và làm sao biết ta thành công?" Nếu họ trả lời đúng, PRD của bạn rõ ràng. Nếu không, hãy viết lại.
Bài tập thực hành
Bài tập 1 — Viết Problem statement có bằng chứng. Chọn một sản phẩm bạn đang dùng (ví dụ một app giao đồ ăn) và một vấn đề bạn từng gặp. Viết một đoạn problem statement 3–4 câu, bắt buộc có ít nhất một con số hoặc một quan sát cụ thể làm bằng chứng (bạn có thể tự ước lượng hợp lý). Đọc to lên và kiểm tra xem nó còn mơ hồ chỗ nào.
Bài tập 2 — Luyện cơ Non-goal. Lấy chính vấn đề ở Bài tập 1, liệt kê 5 ý tưởng tính năng có thể làm. Sau đó chọn DUY NHẤT một ý tưởng làm Goal, và viết 4 ý còn lại thành Non-goal. Tự hỏi: vì sao mình dám cắt 4 ý kia lần này?
Bài tập 3 — Thiết kế Success metric + Guardrail. Với ý tưởng bạn chọn ở Bài tập 2, định nghĩa một primary metric (kèm con số mục tiêu và thời hạn) và ít nhất một guardrail metric. Giải thích: nếu chỉ tối ưu primary metric mà bỏ guardrail, điều tồi tệ gì có thể xảy ra?
Bài tập 4 — Viết PRD hoàn chỉnh một trang. Gộp ba bài tập trên lại thành một PRD một trang theo cấu trúc đã học: Problem → Goal & Non-goal → User & Use case → Requirements → Success metrics → Open questions. Đưa cho một người bạn đọc trong 5 phút và nhờ họ kể lại bạn đang giải vấn đề gì.
Tóm tắt
PRD không phải bài tập viết lách hành chính — nó là công cụ tư duy buộc bạn làm rõ vấn đề trước khi đốt tiền và thời gian của cả team. Một PRD hiện đại tốt mỏng mà sắc: nó mở đầu bằng một problem statement có bằng chứng, định nghĩa rõ goal kèm success metric và non-goal để chống phình phạm vi, mô tả requirements ở mức kết quả mong muốn thay vì chỉ định kỹ thuật, và luôn đi kèm guardrail metrics để bạn không tối ưu mù quáng.
Ba điều cần khắc cốt: (1) Luôn viết vấn đề trước giải pháp; (2) Non-goal cũng quan trọng như Goal; (3) PRD là tài liệu sống, cập nhật liên tục và viết cùng team, không phải ném qua tường. Khi bạn thành thạo việc này, bạn sẽ thấy số lần làm lại giảm hẳn, các cuộc họp ngắn lại, và niềm tin của team dành cho bạn tăng lên — bởi vì một PRD rõ ràng chính là chữ ký của một PM biết mình đang làm gì.