Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa nhận một dự án mới. Bạn mở laptop, tạo một file Google Docs trống, và bắt đầu gõ. Nhưng gõ cái gì? Một PRD dài 15 trang? Một one-pager để sếp duyệt ngân sách? Một RFC để cả team tranh luận kiến trúc? Rất nhiều Product Manager (PM) mới — và cả những người đã làm vài năm — lúng túng ngay ở bước này. Họ viết một "tài liệu hổ lốn": vừa muốn thuyết phục stakeholder, vừa muốn chỉ dẫn engineer, vừa muốn ghi lại tầm nhìn dài hạn. Kết quả là một tài liệu không phục vụ tốt cho ai cả — stakeholder thấy quá chi tiết và bỏ qua, engineer thấy quá mơ hồ và phải hỏi lại, còn bạn thì mất hai ngày viết một thứ không ai đọc hết.
Sự thật là: mỗi loại tài liệu PM tồn tại để giải quyết một bài toán giao tiếp khác nhau, cho một nhóm độc giả khác nhau, ở một thời điểm khác nhau trong vòng đời sản phẩm. Hiểu rõ "khi nào dùng cái nào" không phải là chuyện học thuộc định nghĩa cho vui. Nó quyết định bạn có lãng phí thời gian của chính mình và của 20 con người trong phòng họp hay không. Đây là kỹ năng nền tảng — trước khi học cách viết một PRD đẹp (các bài sau sẽ dạy kỹ), bạn cần biết khi nào thì PRD thậm chí là công cụ đúng.
Bài này sẽ giúp bạn phân biệt rõ bốn loại tài liệu phổ biến nhất trong công việc của PM: PRD, Spec, One-pager, và RFC. Sau bài này, mỗi khi mở file trống, bạn sẽ biết chính xác mình đang viết gì và cho ai.
Khái niệm cốt lõi
Cách dễ nhất để phân biệt bốn loại tài liệu này là đặt ba câu hỏi cho mỗi loại: Viết cho ai? Trả lời câu hỏi gì? Ở giai đoạn nào? Khi bạn nắm được ba trục này, mọi thứ trở nên rõ ràng.
One-pager — "Có nên làm việc này không?"
One-pager là tài liệu ngắn gọn (đúng nghĩa đen: thường gói trong một trang, tối đa khoảng 400–600 từ), viết cho người ra quyết định: sếp, leadership, hội đồng duyệt ngân sách, đôi khi là khách hàng lớn. Mục đích duy nhất của nó là giúp người đọc trả lời: "Việc này có đáng đầu tư không?"
Một one-pager tốt trả lời nhanh: vấn đề là gì, tại sao quan trọng bây giờ, ta định làm gì ở mức rất cao, ước lượng tác động (impact) và chi phí (effort), và đề xuất gì. Nó không đi vào chi tiết kỹ thuật, không có acceptance criteria, không có sơ đồ luồng. Nó là công cụ để xin "đồng ý đi tiếp" chứ không phải để hướng dẫn xây dựng.
Người đọc one-pager thường rất bận. Họ dành 3–5 phút cho tài liệu của bạn. Nếu bạn bắt họ đọc 12 trang để hiểu một ý, bạn đã thua.
PRD (Product Requirements Document) — "Ta sẽ xây cái gì?"
PRD là trái tim của công việc PM. Nó viết cho đội ngũ thực thi: engineer, designer, QA, đôi khi là data analyst và đội marketing. PRD trả lời câu hỏi: "Chúng ta sẽ xây dựng cái gì, và làm sao biết khi nào nó xong?"
PRD đi sâu hơn one-pager rất nhiều. Nó mô tả vấn đề (problem), mục tiêu (goals) và những thứ không làm (non-goals), các user story, hành vi mong đợi của hệ thống, edge cases, success metrics. Nhưng — và đây là điểm nhiều người nhầm — PRD tập trung vào cái gì (what) và tại sao (why), chứ không phải làm thế nào (how) ở tầng kỹ thuật chi tiết. PRD nói "khi người dùng nhấn nút Thanh toán mà thẻ bị từ chối, hệ thống phải hiển thị thông báo lỗi và giữ nguyên giỏ hàng". Nó không nói "dùng Redis để cache trạng thái giỏ hàng" — đó là việc của engineer.
PRD xuất hiện ở giai đoạn sau khi ý tưởng đã được duyệt (thường là sau khi one-pager được thông qua), khi bạn bắt đầu nghiêm túc bước vào pha thiết kế và xây dựng.
Spec (Technical/Functional Spec) — "Chính xác nó hoạt động ra sao?"
Trong nhiều công ty, ranh giới giữa PRD và Spec khá mờ, thậm chí gộp làm một. Nhưng về bản chất, Spec (specification) là tài liệu đặc tả chi tiết hành vi cụ thể — thường chi tiết đến mức một engineer có thể đọc và biết phải code chính xác cái gì, một QA có thể đọc và viết test case từng dòng.
Cách phân biệt hữu ích: nếu PRD là "chúng ta cần một tính năng đăng nhập bằng số điện thoại vì người dùng Việt Nam quen dùng SĐT hơn email", thì Spec là "OTP gồm 6 chữ số, hết hạn sau 60 giây, cho phép gửi lại tối đa 3 lần trong 15 phút, sau đó khóa 30 phút; nếu nhập sai 5 lần thì...". Spec sống ở tầng hành vi chính xác và các trường hợp biên. Có functional spec (mô tả hành vi nhìn từ người dùng) và technical spec (mô tả giải pháp kỹ thuật — thường do engineer/tech lead viết, không phải PM).
Trong thực tế ở các startup nhỏ và vừa tại Việt Nam, PM thường viết một tài liệu duy nhất bao trùm cả phần PRD lẫn functional spec. Điều đó hoàn toàn ổn — miễn là bạn ý thức được mình đang phục vụ cả "what/why" lẫn "hành vi chính xác" trong cùng một file.
RFC (Request for Comments) — "Đây là đề xuất của tôi, mọi người thấy sao?"
RFC mang một tinh thần rất khác. Nó không phải để ra lệnh "hãy xây cái này", mà để mở ra một cuộc thảo luận. Người viết đưa ra một đề xuất (thường là một quyết định lớn, có nhiều phương án, hoặc gây tranh cãi), trình bày các lựa chọn, ưu nhược điểm, và mời mọi người phản biện trước khi chốt.
RFC phổ biến trong văn hóa kỹ thuật (nguồn gốc từ giới làm internet và các công ty như Google, Stripe), nhưng PM cũng dùng khi đối mặt với quyết định có tính chiến lược hoặc liên quan nhiều team: "Chúng ta nên tự xây hệ thống thanh toán hay tích hợp bên thứ ba?", "Có nên đổi mô hình định giá không?". RFC trả lời câu hỏi: "Trong các hướng đi này, ta chọn hướng nào — và tại sao?"
Điểm khác biệt cốt lõi: PRD/Spec giả định quyết định "làm" đã được đưa ra và tập trung vào "làm sao cho đúng". RFC tồn tại để đi đến quyết định, thường có phần Open Questions sống động và nhiều bình luận trao đổi.
Tóm gọn bằng một bảng tư duy
- One-pager: cho leadership · trả lời "có nên làm không" · giai đoạn ý tưởng/xin duyệt · 1 trang.
- PRD: cho team thực thi · trả lời "xây cái gì, why" · giai đoạn thiết kế/xây dựng · vài trang.
- Spec: cho engineer/QA · trả lời "hành vi chính xác ra sao" · giai đoạn xây dựng · chi tiết, đầy đủ edge case.
- RFC: cho những người cùng quyết định · trả lời "chọn hướng nào, why" · giai đoạn trước quyết định · thiên về tranh luận.
Tình huống thực tế
Ví dụ 1: Startup giao đồ ăn — sai lầm "một tài liệu cho tất cả"
Linh là PM tại một startup giao đồ ăn ở TP.HCM, quy mô khoảng 40 người. Cô được giao ý tưởng "thêm tính năng đặt món theo nhóm" (group order) để nhóm bạn/đồng nghiệp cùng đặt chung một đơn. Linh hào hứng, ngồi viết một tài liệu Google Docs dài 18 trang: vừa phân tích thị trường, vừa mô tả từng màn hình, vừa liệt kê 40 acceptance criteria, vừa đề xuất ngân sách marketing.
Cô gửi cho CEO để xin duyệt. Hai tuần trôi qua, CEO không phản hồi. Khi Linh hỏi, CEO thú thật: "Anh mở ra thấy dài quá, định để cuối tuần đọc kỹ, rồi quên mất."
Bài học: Linh đã trộn lẫn mục đích. CEO ở thời điểm đó chỉ cần một one-pager để trả lời "có đáng đầu tư 6 tuần engineer cho group order không?". Sau khi Linh viết lại thành một trang — nêu rõ vấn đề (35% đơn hàng văn phòng là nhiều người ăn nhưng phải đặt riêng lẻ, gây phiền), ước lượng tác động (tăng giá trị đơn trung bình ~25%), effort thô (6 tuần) — CEO duyệt ngay trong buổi chiều. Phần PRD 18 trang kia chỉ nên ra đời sau khi có cái gật đầu này. Dùng đúng tài liệu cho đúng thời điểm tiết kiệm cho Linh cả hai tuần chờ đợi.
Ví dụ 2: Đội fintech — khi nào RFC cứu cả team
Tại một công ty fintech ở Singapore phục vụ thị trường Đông Nam Á, đội của Minh đứng trước một quyết định lớn: xây tính năng "trả góp" (buy-now-pay-later). Có hai hướng — tự xây toàn bộ hệ thống chấm điểm tín dụng và thu hồi nợ, hoặc tích hợp với một đối tác BNPL có sẵn.
Nếu Minh nhảy thẳng vào viết PRD cho một trong hai hướng, anh đã ngầm "chốt" quyết định mà chưa hề có sự đồng thuận. Engineering có thể phản đối vì rủi ro vận hành; bộ phận pháp lý lo về giấy phép cho vay; tài chính lo về dòng tiền. Thay vào đó, Minh viết một RFC: nêu bối cảnh, trình bày cả hai phương án với bảng so sánh ưu/nhược (chi phí, thời gian ra mắt, rủi ro pháp lý, biên lợi nhuận), và một phần Open Questions.
RFC được chia sẻ cho engineering, legal, finance và đề nghị bình luận trong 5 ngày. Sau 30+ comment, team nhận ra hướng "tự xây" sẽ vướng giấy phép tín dụng mà công ty chưa có, đẩy thời gian ra mắt thêm 9 tháng. Quyết định cuối: tích hợp đối tác trước, tự xây sau. Chỉ khi đó Minh mới viết PRD cho phương án tích hợp.
Bài học: Khi quyết định còn mở và liên quan nhiều bên, RFC là công cụ đúng. Viết PRD quá sớm cho một quyết định chưa chốt là cách nhanh nhất để phải vứt đi cả tài liệu — và làm mất lòng những team cảm thấy bị "qua mặt".
Ví dụ 3: Tính năng nhỏ — khi PRD và Spec hòa làm một
Trang là PM ở một công ty SaaS Việt Nam làm phần mềm quản lý bán hàng. Tính năng cần làm: cho phép xuất báo cáo doanh thu ra file Excel. Đây là một tính năng rõ ràng, không gây tranh cãi, không cần xin ngân sách lớn.
Trang không viết one-pager (không cần thuyết phục ai), không viết RFC (không có lựa chọn lớn cần tranh luận). Cô viết một tài liệu gọn gàng vừa đóng vai PRD vừa đóng vai functional spec: vấn đề (kế toán đang phải copy thủ công, mất 2 giờ/tuần), mục tiêu, và phần đặc tả hành vi rất chi tiết — nút "Xuất Excel" nằm ở đâu, các cột trong file, định dạng ngày tháng (DD/MM/YYYY theo chuẩn Việt Nam), xử lý khi không có dữ liệu, giới hạn tối đa 50.000 dòng, hành vi khi vượt giới hạn.
Bài học: Đừng giáo điều. Không phải dự án nào cũng cần đủ bốn loại tài liệu. Với tính năng nhỏ, rõ ràng, một tài liệu PRD-kèm-Spec là đủ và hiệu quả. Sự thành thạo nằm ở chỗ biết bỏ bớt đúng lúc, không phải ở chỗ luôn viết đủ bộ.
Hướng dẫn từng bước
Khi đứng trước một nhiệm vụ mới và phân vân nên viết gì, hãy đi qua quy trình sau:
- Xác định bạn đang ở giai đoạn nào. Ý tưởng còn mơ hồ, chưa được duyệt? → One-pager. Quyết định lớn chưa chốt, nhiều phương án? → RFC. Đã quyết làm, cần hướng dẫn xây dựng? → PRD/Spec.
- Xác định độc giả chính. Hỏi: "Ai là người bắt buộc phải đọc và hành động dựa trên tài liệu này?" Nếu là leadership ra quyết định đầu tư → one-pager. Nếu là engineer/designer/QA thực thi → PRD/Spec. Nếu là nhiều bên cần đồng thuận → RFC.
- Xác định câu hỏi cốt lõi tài liệu phải trả lời. Viết câu hỏi đó ra một dòng. "Có nên làm không?" khác hẳn "Xây cái gì?" khác hẳn "Chọn hướng nào?". Câu hỏi này định hình toàn bộ cấu trúc.
- Chọn độ chi tiết tương xứng. One-pager: chỉ phần ngọn. PRD: what/why đầy đủ. Spec: chi tiết đến từng edge case. Đừng đổ chi tiết Spec vào one-pager, và đừng để PRD mơ hồ như one-pager.
- Cân nhắc gộp khi hợp lý. Tính năng nhỏ → gộp PRD và Spec. Đừng tạo thủ tục giấy tờ thừa.
- Đặt tên file rõ ràng theo loại. "One-pager: Group Order", "PRD: Phone Login", "RFC: Build vs Buy — BNPL". Người đọc biết ngay kỳ vọng nên đặt vào đâu trước khi mở.
Lỗi thường gặp & mẹo
Lỗi 1 — "Tài liệu Frankenstein". Nhồi tất cả vào một file: pitch cho sếp, chi tiết cho engineer, tầm nhìn 3 năm. Kết quả không phục vụ tốt cho ai. Mẹo: mỗi tài liệu một mục đích, một độc giả chính.
Lỗi 2 — Viết PRD khi thật ra cần RFC. Bạn ngầm chốt một quyết định lớn mà chưa ai đồng thuận, rồi ngạc nhiên khi engineering phản đối ở phút chót. Mẹo: nếu bạn thấy mình đang phải "biện hộ" cho một lựa chọn giữa nhiều phương án, đó là tín hiệu cần RFC, không phải PRD.
Lỗi 3 — One-pager dài 5 trang. Cái tên đã nói lên tất cả. Nếu không gói được trong một trang, bạn chưa đủ rõ ràng về điều cốt lõi. Mẹo: viết phần đề xuất trước, rồi cắt mọi thứ không phục vụ quyết định "đi tiếp hay không".
Lỗi 4 — Nhầm "what" với "how". PRD lao vào quyết định kỹ thuật (chọn database, kiến trúc), lấn sân engineer và làm cứng nhắc giải pháp quá sớm. Mẹo: khi viết PRD, tự hỏi "đây là yêu cầu hay là một cách triển khai?". Nếu là cách triển khai, để lại cho engineer.
Lỗi 5 — Giáo điều với quy trình. Viết đủ bốn loại tài liệu cho một tính năng sửa lỗi nhỏ. Mẹo: tài liệu là phương tiện, không phải mục đích. Viết ít nhất có thể mà vẫn đủ để mọi người làm đúng việc.
Mẹo nâng cao: Ở đầu mỗi tài liệu, ghi một dòng "Tài liệu này dành cho ai và để quyết định/làm gì". Một câu duy nhất này giúp người đọc tự hiệu chỉnh kỳ vọng và giảm hẳn những hiểu lầm về mức độ chi tiết.
Bài tập thực hành
- Phân loại nhanh. Với mỗi tình huống sau, hãy quyết định nên viết loại tài liệu nào và viết một câu giải thích lý do:
- Viết lại. Lấy một tài liệu cũ bạn từng viết (hoặc tưởng tượng một cái). Xác định nó thật sự nên là loại nào, rồi viết lại 3 dòng đầu nêu rõ: độc giả, câu hỏi cốt lõi, độ chi tiết phù hợp.
- One-pager 250 từ. Chọn một ý tưởng tính năng bất kỳ bạn quan tâm. Viết một one-pager đúng nghĩa, tối đa 250 từ, gồm: vấn đề, tại sao bây giờ, đề xuất ở mức cao, ước lượng tác động và effort, và yêu cầu cụ thể (xin gì từ người đọc). Tự chấm: người bận rộn đọc trong 3 phút có ra được quyết định không?
Tóm tắt
Bốn loại tài liệu PM không cạnh tranh nhau — chúng phục vụ những thời điểm và độc giả khác nhau trong vòng đời sản phẩm. One-pager giúp leadership quyết định có nên làm không. PRD chỉ cho team thực thi biết xây cái gì và tại sao. Spec đặc tả hành vi chính xác ra sao để engineer và QA làm việc không cần đoán. RFC mở cuộc thảo luận để cùng chọn hướng đi khi quyết định còn ngỏ.
Bí quyết không phải là học thuộc định nghĩa, mà là phản xạ đặt ba câu hỏi mỗi khi mở file trống: Viết cho ai? Trả lời câu hỏi gì? Đang ở giai đoạn nào? Trả lời được ba câu này, bạn sẽ luôn chọn đúng công cụ — và tiết kiệm cho mình lẫn cả team vô số giờ lãng phí. Và đừng quên: dùng đúng tài liệu, đúng lúc, đôi khi nghĩa là không viết một tài liệu nào cả. Ở các bài tiếp theo, ta sẽ mổ xẻ sâu cách viết một PRD thật tốt — nhưng giờ thì bạn đã biết khi nào PRD mới là lựa chọn đúng.