Mở đầu — vì sao bài này quan trọng
Ở bài trước, bạn đã phân biệt được PRD với Spec, One-pager và RFC — biết khi nào dùng loại tài liệu nào. Nhưng biết "khi nào dùng PRD" mới chỉ là một nửa câu chuyện. Nửa còn lại, cũng là nửa khiến nhiều PM mắc kẹt, là: một PRD tốt thực sự gồm những phần gì, và mỗi phần làm nhiệm vụ gì?
Tôi đã đọc hàng trăm PRD trong sự nghiệp, từ tài liệu của các bạn PM mới ra trường ở startup Việt cho tới spec của những team sản phẩm hàng chục triệu người dùng. Và tôi nhận ra một quy luật: PRD dở thường không dở vì viết kém, mà vì thiếu cấu trúc. Người viết nhảy thẳng vào giải pháp mà quên kể bối cảnh. Họ mô tả tính năng nhưng không ai biết tính năng đó giải quyết vấn đề gì. Họ liệt kê một đống thứ "cần làm" nhưng không định nghĩa rõ "không làm gì". Kết quả: engineer hiểu một kiểu, designer hiểu một kiểu, sếp hiểu kiểu thứ ba — và ba tuần sau khi build xong, không ai hài lòng.
Một PRD tốt giống như một bộ khung xương. Khi bạn có khung xương chuẩn, bạn biết chính xác chỗ nào cần đắp thịt, chỗ nào còn thiếu. Bài này dạy bạn 8 phần cốt lõi tạo nên bộ khung đó. Hãy coi đây là bản đồ tổng thể — những bài sau (Problem, Goals, User stories, Edge cases...) sẽ đào sâu từng phần. Còn hôm nay, bạn cần nhìn thấy toàn cảnh: tám mảnh ghép và cách chúng khớp với nhau thành một câu chuyện thuyết phục.
Khái niệm cốt lõi
Một PRD chuẩn gồm 8 phần, sắp xếp theo một logic kể chuyện rất tự nhiên: bối cảnh → vấn đề → mục tiêu → ranh giới → ai liên quan → họ cần gì → ta làm gì → đo lường ra sao. Đừng học thuộc lòng — hãy hiểu vì sao thứ tự này hợp lý.
1. Context (Bối cảnh)
Context trả lời câu hỏi: "Tại sao chúng ta nói về chuyện này, lúc này?" Đây là phần đặt người đọc vào đúng thời điểm và hoàn cảnh. Có một thay đổi gì trên thị trường? Một dữ liệu mới? Một quyết định chiến lược của công ty? Một feedback dồn dập từ khách hàng?
Context không phải là vấn đề — nó là cái nền để vấn đề trở nên có nghĩa. Ví dụ: "Quý trước, tỷ lệ người dùng mới hoàn tất onboarding giảm từ 62% xuống 48% sau khi chúng ta thêm bước xác minh số điện thoại." Câu đó cho người đọc biết bối cảnh, để khi bạn nêu vấn đề ở phần sau, họ đã sẵn sàng đồng cảm.
2. Problem (Vấn đề)
Problem là trái tim của PRD. Nó nêu rõ điều gì đang trục trặc, ai chịu thiệt, và thiệt hại lớn cỡ nào. Một problem tốt phải cụ thể, có thể quan sát được, và lý tưởng là kèm con số.
Tránh nêu vấn đề kiểu "người dùng muốn tính năng X". Đó không phải vấn đề — đó là giải pháp trá hình. Vấn đề thật là cái đau phía sau: "Người dùng phải mở 3 app khác nhau để đối chiếu lịch giao hàng, mất trung bình 7 phút mỗi đơn." (Bài 3 và Bài 13 sẽ dạy bạn viết phần này thật sắc.)
3. Goals (Mục tiêu)
Goals trả lời: "Nếu giải quyết được vấn đề, thế giới sẽ trông như thế nào?" Mục tiêu nên gắn với kết quả (outcome), không phải hoạt động (output). "Giảm thời gian đối chiếu lịch giao hàng từ 7 phút xuống dưới 1 phút" là goal tốt. "Xây màn hình dashboard mới" không phải goal — đó là việc cần làm.
4. Non-goals (Không thuộc phạm vi)
Đây là phần bị bỏ quên nhiều nhất, và cũng là phần tạo khác biệt lớn nhất giữa PRD nghiệp dư và chuyên nghiệp. Non-goals nói rõ những gì bạn cố tình không làm trong lần này. Nó chặn đứng "scope creep" — hiện tượng phạm vi cứ phình ra mãi. Khi bạn viết "Phiên bản này không hỗ trợ đa ngôn ngữ, không hỗ trợ thanh toán quốc tế", bạn đang bảo vệ team khỏi việc bị kéo đi mọi hướng. (Bài 14 sẽ đào sâu.)
5. Users (Người dùng)
Phần này định nghĩa ai sẽ dùng tính năng. Không phải "tất cả mọi người" — mà là phân khúc cụ thể với đặc điểm, hành vi, hoàn cảnh riêng. Một feature cho chủ shop online bán hàng livestream sẽ rất khác feature cho kế toán doanh nghiệp. Mô tả users càng rõ, các quyết định thiết kế phía sau càng có cơ sở. (Bài 16 và Bài 17 đào sâu personas và JTBD.)
6. User stories (Câu chuyện người dùng)
User stories chuyển từ "ai" sang "họ muốn làm gì và để được gì". Công thức kinh điển: "Là [vai trò], tôi muốn [hành động] để [đạt được kết quả]." Đây là cầu nối giữa nhu cầu trừu tượng và chức năng cụ thể. Mỗi story sau này sẽ kèm acceptance criteria — điều kiện để coi là "làm xong". (Bài 4 và Bài 21 chuyên sâu phần này.)
7. Solution (Giải pháp)
Đây mới là phần mô tả bạn định làm gì. Lưu ý quan trọng: solution trong PRD nên mô tả hành vi người dùng nhìn thấy trước, kiến trúc kỹ thuật sau (Bài 18 nhấn mạnh điều này). PRD không phải nơi vẽ sơ đồ database. PRD mô tả: người dùng bấm nút này thì thấy gì, hệ thống phản hồi ra sao, luồng đi như thế nào. Phần solution thường kèm flow, wireframe, và mô tả các trạng thái.
8. Metrics (Chỉ số đo lường)
Phần cuối trả lời: "Làm sao biết ta thành công?" Metrics gồm chỉ số chính (cái bạn muốn cải thiện) và lý tưởng là cả counter-metrics (cái bạn không muốn làm tệ đi — Bài 15). Không có metrics, PRD chỉ là một lời hứa không thể kiểm chứng. Có metrics, bạn biến nó thành một cam kết đo được.
Vì sao thứ tự này quan trọng
Tám phần này không phải danh sách rời rạc — chúng là một mạch logic dẫn dắt. Context dựng sân khấu. Problem nêu xung đột. Goals vẽ đích đến. Non-goals vạch lằn ranh. Users + User stories cho biết ta phục vụ ai và họ cần gì. Solution là câu trả lời. Metrics là lời cam kết. Nếu bạn nhảy thẳng từ Context sang Solution mà bỏ qua Problem và Goals, người đọc sẽ luôn hỏi "ủa nhưng để làm gì?". Cấu trúc giữ cho câu chuyện không bị hụt hơi.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán "giỏ hàng bị quên"
Giả sử một PM tại Tiki nhận thấy một con số đáng lo: 38% người dùng thêm sản phẩm vào giỏ nhưng không bao giờ quay lại thanh toán trong vòng 48 giờ. Bạn ấy viết PRD đầu tiên chỉ gồm: "Đề xuất: gửi email nhắc giỏ hàng bị bỏ quên." — và nhảy thẳng vào mô tả email.
Engineering lead đọc xong hỏi ba câu khiến PRD sụp đổ: "Vấn đề thật là gì — người ta quên, hay người ta chê giá? Mục tiêu là tăng doanh thu hay tăng tỷ lệ quay lại? Đo bằng gì?" PM không trả lời được.
Bạn ấy viết lại theo 8 phần. Context: mùa sale 9/9 sắp tới, lưu lượng tăng gấp 3. Problem: 38% giỏ bị bỏ quên, tương đương ~12 tỷ đồng GMV tiềm năng mỗi tháng bị bỏ lỡ; phỏng vấn cho thấy 60% người quên vì bị phân tâm chứ không phải chê giá. Goals: phục hồi 15% số giỏ bỏ quên trong 60 ngày. Non-goals: chưa làm push notification, chưa cá nhân hóa giá. Users: người mua đã đăng nhập, có app. Solution: email + in-app reminder sau 4 giờ và 24 giờ. Metrics: tỷ lệ phục hồi giỏ là chỉ số chính; counter-metric là tỷ lệ unsubscribe email không vượt 2%.
Bài học: chính các phần Problem, Goals, Metrics — chứ không phải mô tả email — mới là thứ giúp PRD được duyệt. Cấu trúc buộc bạn trả lời những câu hỏi khó trước khi engineer hỏi.
Ví dụ 2 — Startup fintech và sức mạnh của Non-goals
Một startup ví điện tử ở TP.HCM (gọi là MoMoPay-clone, 200 nghìn người dùng) muốn ra tính năng "chia tiền nhóm" — bạn bè đi ăn xong chia hóa đơn qua app. PM viết PRD khá đầy đủ về Context, Problem, Solution. Nhưng PRD không có phần Non-goals.
Hậu quả: trong buổi review, mỗi người thêm một ý. Sales muốn hỗ trợ chia tiền với người chưa cài app. Marketing muốn thêm tính năng "nhắc nợ tự động qua SMS". CEO muốn tích hợp luôn với nhóm Zalo. Phạm vi từ một tính năng 3 tuần phình thành dự án 4 tháng. Cuối cùng lùi lịch hai lần và ship một bản nửa vời.
Khi làm lại tính năng "quỹ nhóm" sáu tháng sau, PM rút kinh nghiệm, viết Non-goals ngay từ đầu: "V1 KHÔNG hỗ trợ: người chưa có tài khoản, nhắc nợ qua SMS, tích hợp Zalo/Telegram, chia theo tỷ lệ phần trăm tùy chỉnh." Buổi review lần này, khi ai đó đề xuất thêm tính năng, PM chỉ vào dòng Non-goals: "Cái này nằm trong V2, đã ghi nhận." Dự án ship đúng hạn 3 tuần.
Bài học: Non-goals không phải là dấu hiệu bạn thiếu tham vọng — nó là công cụ quyền lực nhất để giữ dự án không chệch hướng. Một dòng Non-goals rõ ràng tiết kiệm hàng chục giờ tranh luận.
Ví dụ 3 — Grab và phần Users bị mơ hồ
Một team tại một công ty gọi xe (bối cảnh giả định kiểu Grab) làm tính năng "đặt xe đi sân bay đặt trước 24h". PRD viết phần Users là: "Tất cả người dùng đi sân bay."
Vấn đề lộ ra khi build: tài xế phàn nàn khách đặt trước rồi hủy phút chót. Hóa ra "tất cả người dùng đi sân bay" gộp chung hai nhóm hoàn toàn khác nhau: dân công tác (đặt chắc chắn, cần hóa đơn VAT, sẵn sàng trả giá cao) và khách du lịch tự phát (hay đổi ý, nhạy giá). Một tính năng không thể phục vụ tốt cả hai mà không có lựa chọn.
Team viết lại phần Users, tách rõ persona chính là "khách công tác đặt xe có kế hoạch" và đưa "khách du lịch tự phát" vào Non-goals của V1. Lập tức các quyết định trở nên rõ ràng: yêu cầu đặt cọc nhỏ để giảm hủy, thêm trường xuất hóa đơn, hiển thị giá cố định trước. Tỷ lệ hủy giảm từ 22% xuống 9%.
Bài học: phần Users mơ hồ làm hỏng mọi quyết định phía sau. "Tất cả mọi người" thực ra là "không ai cụ thể cả". Định nghĩa người dùng càng sắc, giải pháp càng đúng đích.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn làm khi bắt đầu một PRD mới với khung 8 phần:
- Tải template và điền 8 tiêu đề trống trước. Trước khi viết một chữ nội dung nào, hãy tạo 8 heading: Context, Problem, Goals, Non-goals, Users, User stories, Solution, Metrics. Nhìn thấy chỗ trống sẽ nhắc bạn không bỏ sót.
- Bắt đầu từ Problem, không phải Solution. Đây là điều phản trực giác nhất. Hầu hết chúng ta hào hứng với giải pháp. Hãy ép mình viết Problem trước. Nếu bạn không nêu được vấn đề rõ trong 2–3 câu, có lẽ bạn chưa hiểu nó đủ sâu để xây giải pháp.
- Viết Goals và Metrics cùng lúc. Mỗi goal nên có một metric tương ứng. Nếu một goal không đo được, hoặc nó chưa đủ cụ thể, hoặc nó không thực sự là goal.
- Viết Non-goals ngay sau Goals, khi đầu óc còn tỉnh táo. Lúc này bạn đang nghĩ về phạm vi. Hãy liệt kê thẳng những thứ "ai cũng sẽ muốn thêm nhưng V1 không làm".
- Định nghĩa Users trước khi viết User stories. Stories phải xuất phát từ một người dùng cụ thể. Nếu chưa biết phục vụ ai, đừng viết story.
- Solution viết sau cùng, mô tả hành vi trước kiến trúc. Lúc này bạn đã có đủ Problem, Goals, Users — solution sẽ tự nhiên bám đúng nhu cầu thay vì là giải pháp bạn yêu thích.
- Đọc lại theo mạch kể chuyện. Đọc PRD từ trên xuống như đọc truyện. Có chỗ nào người đọc sẽ hỏi "tại sao?" mà không tìm thấy câu trả lời ở phần trước không? Nếu có, mạch logic đang đứt.
Lỗi thường gặp & mẹo
Lỗi 1: Nhảy thẳng vào Solution. Triệu chứng: PRD bắt đầu bằng "Chúng ta sẽ xây màn hình...". Mẹo: che phần Solution lại, đọc các phần trên. Nếu chúng đủ thuyết phục để bất kỳ ai cũng tự nghĩ ra hướng giải pháp tương tự, bạn đã viết đúng.
Lỗi 2: Problem thực ra là Solution trá hình. "Vấn đề: người dùng cần nút chia sẻ." Không — đó là giải pháp. Vấn đề là "người dùng không có cách lan tỏa nội dung họ thích cho bạn bè". Mẹo: hỏi "tại sao?" ba lần liên tiếp cho mỗi câu Problem.
Lỗi 3: Bỏ trống Non-goals. Đây là lỗi tốn kém nhất. Mẹo: luôn viết ít nhất 3 dòng Non-goals. Nếu thật sự không nghĩ ra, đó là dấu hiệu phạm vi của bạn chưa được kiểm soát.
Lỗi 4: Metrics chung chung. "Cải thiện trải nghiệm người dùng" không đo được. Mẹo: mỗi metric phải có con số mục tiêu và mốc thời gian — "tăng X từ A lên B trong N ngày".
Lỗi 5: Users là 'tất cả mọi người'. Như ví dụ Grab phía trên. Mẹo: nếu phần Users dài hơn một dòng và không có một persona chính rõ ràng, hãy thu hẹp lại.
Mẹo tổng quát: Không phải PRD nào cũng cần cả 8 phần dài như nhau. Tính năng nhỏ có thể gói Context và Problem vào vài câu. Nhưng đừng bao giờ xóa hẳn một heading — hãy để nó đó và ghi "Không áp dụng" nếu cần. Sự hiện diện của heading là một checklist nhắc bạn đã cân nhắc đủ.
Bài tập thực hành
Chọn một tính năng bạn từng dùng và thấy khó chịu — ví dụ luồng đặt vé xe khách online, hoặc tính năng tích điểm của một app cà phê quen thuộc. Sau đó:
- Mở template 8 phần (tải ở cuối bài) và điền cả 8 heading.
- Viết Problem trong tối đa 3 câu, kèm ít nhất một con số (có thể là số ước lượng hợp lý).
- Viết 2 Goals, mỗi goal kèm 1 Metric tương ứng có con số và mốc thời gian.
- Viết ít nhất 3 dòng Non-goals — những thứ bạn cố tình không làm ở V1.
- Định nghĩa một persona chính trong phần Users (không quá 2 dòng).
- Viết 2 User stories theo công thức "Là... tôi muốn... để...".
- Cuối cùng, đọc to toàn bộ từ trên xuống. Tự hỏi: có chỗ nào người đọc sẽ hỏi "tại sao?" mà không tìm được câu trả lời ở phần trước không?
Tóm tắt
Một PRD tốt được dựng trên 8 phần cốt lõi, theo đúng mạch kể chuyện: Context (vì sao lúc này) → Problem (cái đau là gì, lớn cỡ nào) → Goals (đích đến, gắn outcome) → Non-goals (lằn ranh phạm vi) → Users (phục vụ ai cụ thể) → User stories (họ cần làm gì để được gì) → Solution (hành vi trước kiến trúc) → Metrics (làm sao biết thành công).
Ba bài học lớn nhất: (1) luôn bắt đầu từ Problem, đừng nhảy vào Solution; (2) Non-goals là công cụ quyền lực nhất để giữ dự án không chệch hướng; (3) Users càng cụ thể, mọi quyết định phía sau càng đúng đích. Đừng học thuộc — hãy hiểu rằng cấu trúc này tồn tại để buộc bạn trả lời những câu hỏi khó trước khi người khác hỏi. Hãy tải template 8 phần kèm bài học, dùng nó cho dự án tiếp theo, và để các bài sau dạy bạn cách đào sâu từng mảnh ghép.