Mở đầu — vì sao bài này quan trọng
Sau 55 bài học, bạn đã biết một PRD tốt cần có những gì: problem sắc bén, goals đo được, user stories rõ ràng, edge cases đầy đủ, rollout plan cẩn thận. Nhưng có một sự thật phũ phàng mà ít người nói với bạn: biết viết đúng và tránh được lỗi sai là hai kỹ năng khác nhau. Bạn có thể thuộc lòng anatomy của một PRD chuẩn, nhưng dưới áp lực deadline, dưới sức ép của sếp đang nóng lòng muốn "ship cho nhanh", bạn vẫn rơi vào đúng những cái bẫy mà ai cũng rơi.
Bài này là một bộ "danh sách kiểm tra ngược" — thay vì dạy bạn nên làm gì, nó chỉ thẳng vào những lỗi phổ biến nhất khiến một PRD bị từ chối, bị hiểu sai, hoặc tệ hơn, được phê duyệt rồi dẫn cả team xây nhầm sản phẩm. Tôi đã review hàng trăm PRD của PM ở nhiều cấp độ, từ intern đến senior, và điều đáng kinh ngạc là những lỗi nghiêm trọng nhất lại lặp đi lặp lại giống nhau đến mức có thể dự đoán được.
Lý do bạn cần học bài này: một lỗi trong code bạn có thể fix trong vài giờ. Một lỗi trong PRD — ví dụ định nghĩa sai vấn đề — có thể khiến cả team đốt 3 tháng để xây thứ không ai cần. Chi phí của một PRD sai không nằm ở chỗ viết lại tài liệu, mà ở chỗ toàn bộ engineering, design, QA đã đi theo nó. Phòng bệnh ở đây rẻ hơn chữa bệnh hàng trăm lần.
Khái niệm cốt lõi
Tôi nhóm các lỗi PRD phổ biến thành bốn nhóm theo mức độ nguy hiểm. Nhóm càng cao càng khó phát hiện và càng đắt khi sai.
Nhóm 1 — Lỗi nền tảng: viết nhầm cái cần viết
Đây là nhóm nguy hiểm nhất vì nó làm hỏng bản chất của PRD, không phải hình thức.
Lỗi solution-first (giải pháp đi trước vấn đề). Đây là lỗi số một, gặp ở 70% PRD tôi review. PRD mở đầu bằng "Chúng ta sẽ xây tính năng X" thay vì "Người dùng đang gặp vấn đề Y". Khi bạn viết solution-first, bạn đã âm thầm khóa cứng một giải pháp trước khi ai kịp hỏi "vấn đề thật sự là gì?". Hệ quả: cả team xây đúng thứ trong PRD, nhưng không giải quyết được gì cho người dùng. PRD không có Problem statement giống như một đơn thuốc không có chẩn đoán bệnh — bạn không thể biết nó có chữa đúng bệnh không.
Lỗi metric mơ hồ. "Cải thiện trải nghiệm người dùng", "tăng độ hài lòng", "làm cho sản phẩm tốt hơn" — những câu này nghe rất hay nhưng vô dụng. Vì sao? Vì không ai có thể trả lời câu hỏi "khi nào thì coi là xong?". Một metric tốt phải đo được: "Tăng tỷ lệ hoàn tất thanh toán từ 62% lên 75% trong 8 tuần". Khi metric mơ hồ, bạn không bao giờ biết tính năng thành công hay thất bại, và quan trọng hơn, bạn không có cơ sở để nói "không" với những yêu cầu thêm thắt vô tận.
Lỗi thiếu non-goals. Nếu PRD chỉ nói cái sẽ làm mà không nói cái sẽ KHÔNG làm, scope sẽ phình to không kiểm soát. Non-goals là hàng rào bảo vệ team khỏi scope creep. Thiếu nó, mỗi cuộc họp lại có người hỏi "thế cái này có làm luôn không?" và bạn không có chỗ dựa để từ chối.
Nhóm 2 — Lỗi về độ rõ ràng: viết đúng nhưng người đọc hiểu sai
Lỗi dùng từ mơ hồ định lượng. "Nhanh", "nhiều", "thường xuyên", "một số", "đa số" — engineer đọc xong không biết build cái gì. "Tải nhanh" là bao nhiêu ms? "Hỗ trợ nhiều người dùng" là bao nhiêu concurrent users? Mỗi từ mơ hồ là một quả bom hẹn giờ sẽ nổ ở giai đoạn QA hoặc tệ hơn là sau khi launch.
Lỗi giả định ngầm (implicit assumptions). PM viết "người dùng đăng nhập rồi mới thấy giỏ hàng" mà không nói rõ điều gì xảy ra với người chưa đăng nhập. Những giả định trong đầu PM không tự động chui vào đầu engineer. Mọi giả định phải được viết ra.
Lỗi quá tải chi tiết kỹ thuật. Ngược lại với mơ hồ, một số PRD sa đà vào mô tả database schema, API endpoint, cấu trúc class — những thứ thuộc về Solution/architecture mà bài 18 đã dạy là phải để sau user-facing behavior. PRD bị nhồi nhét kỹ thuật khiến stakeholder không kỹ thuật (sales, marketing, legal) không đọc nổi.
Nhóm 3 — Lỗi về tính đầy đủ: bỏ quên những phần quan trọng
Lỗi bỏ qua edge cases và error states. PRD chỉ mô tả "happy path" — luồng lý tưởng khi mọi thứ suôn sẻ. Không có gì về lỗi mạng, lỗi server, dữ liệu rỗng, người dùng nhấn nút hai lần. Engineer sẽ tự bịa ra cách xử lý, và mỗi người bịa một kiểu.
Lỗi thiếu phần Open Questions. PRD nào cũng có những điều chưa chắc chắn. PM giấu chúng đi vì sợ trông thiếu chuyên nghiệp. Nhưng giấu câu hỏi mở không làm nó biến mất — nó chỉ nổ ra giữa lúc sprint đang chạy.
Nhóm 4 — Lỗi về quy trình và con người
Lỗi viết PRD một mình rồi mới đưa cho team. PRD là công cụ đồng thuận, không phải bài tập về nhà. Nếu engineer và designer chỉ thấy PRD lần đầu trong buổi review, bạn sẽ nhận về một trận mưa câu hỏi và sự kháng cự.
Lỗi PRD "đông cứng". PM viết xong, ship đi, rồi không bao giờ cập nhật lại dù thực tế đã thay đổi. PRD trở thành tài liệu chết, không ai tin tưởng.
Tình huống thực tế
Ví dụ 1 — Solution-first khiến một startup fintech Việt đốt 2 tháng
Một startup ví điện tử ở TP.HCM (gọi là VíNhanh cho dễ) có CEO đọc được tin đối thủ ra mắt tính năng "chia hóa đơn nhóm" (split bill). Ông yêu cầu PM viết PRD ngay với tiêu đề: "Xây tính năng Split Bill cho phép chia hóa đơn tối đa 20 người".
PM, vì áp lực, viết PRD đúng như chỉ đạo: mô tả UI chia tiền, công thức làm tròn số lẻ, màn hình mời bạn bè. Không có một dòng Problem statement nào. Team build trong 2 tháng. Khi launch, tính năng có tỷ lệ sử dụng 0,8% — gần như không ai dùng.
Lúc đó họ mới làm điều lẽ ra phải làm từ đầu: phỏng vấn người dùng. Hóa ra vấn đề thật của người dùng Việt không phải "chia tiền khó" — họ đã quen chuyển khoản tay đôi qua Momo/chuyển khoản ngân hàng rồi. Vấn đề thật là "tôi ngại nhắc bạn trả tiền" — một vấn đề tâm lý xã hội, không phải vấn đề tính toán. Giải pháp đúng lẽ ra là tính năng "nhắc nợ khéo" tự động gửi lời nhắc dễ thương, chứ không phải máy tính chia tiền.
Bài học: Nếu PRD bắt đầu bằng "xây tính năng X", hãy dừng lại và hỏi "vấn đề Y là gì?". Một Problem statement bị bỏ qua đã khiến team xây đúng thứ vô dụng. Solution-first không sai vì giải pháp dở — nó sai vì không ai kiểm chứng giải pháp có khớp vấn đề không.
Ví dụ 2 — Metric mơ hồ khiến đội Grab-style không thể đóng dự án
Một công ty gọi xe khu vực Đông Nam Á có PM viết PRD cho việc làm lại màn hình đặt xe với mục tiêu: "Cải thiện trải nghiệm đặt xe, làm cho luồng đặt mượt mà hơn". Team thiết kế lại, ship phiên bản mới.
Vấn đề bắt đầu khi đến lúc đánh giá. Design team nói "đẹp hơn rồi, thành công". Engineering nói "code sạch hơn, thành công". Nhưng business team nhìn vào số liệu thì tỷ lệ chuyển đổi đặt xe không đổi, thậm chí giảm nhẹ 1,2% ở nhóm người dùng lớn tuổi vì layout mới khó dùng hơn với họ. Không ai có thể tuyên bố dự án thành công hay thất bại, vì "mượt mà hơn" không phải con số đo được. Cuộc tranh cãi kéo dài 3 tuần, dự án không thể đóng sổ.
Nếu PRD ban đầu viết metric rõ: "Tăng tỷ lệ hoàn tất đặt xe từ 84% lên 88%, không làm giảm conversion ở bất kỳ nhóm tuổi nào (counter-metric)", thì ngay từ đầu họ đã thiết kế có chủ đích để bảo vệ nhóm người dùng lớn tuổi, và sau khi launch sẽ có câu trả lời dứt khoát.
Bài học: Metric mơ hồ không chỉ khiến bạn không biết thành công hay không — nó còn xóa bỏ khả năng học hỏi. Mỗi tính năng ship đi mà không có metric đo được là một cơ hội học hỏi bị vứt vào sọt rác.
Ví dụ 3 — Thiếu non-goals khiến một dự án e-commerce phình to gấp ba
Một sàn thương mại điện tử ở Hà Nội triển khai tính năng "đánh giá sản phẩm bằng video". PRD ban đầu gọn gàng: cho phép người mua quay video ngắn đánh giá sản phẩm. Nhưng PRD không có mục Non-goals.
Trong buổi review đầu tiên, marketing hỏi "có làm luôn tính năng KOL/influencer dùng video này để kiếm hoa hồng không?". Sales hỏi "có cho người bán phản hồi lại video không?". CTO hỏi "có làm luôn AI tự kiểm duyệt nội dung nhạy cảm không?". Vì PRD không có hàng rào Non-goals, PM không có cơ sở để từ chối, và tất cả những thứ này bị gom vào scope. Dự án từ 3 tuần ước tính phình thành 9 tuần, và cuối cùng bị hủy giữa chừng vì quá phức tạp, không kịp mùa sale.
Một dòng Non-goals đơn giản như "v1 KHÔNG bao gồm: hệ thống hoa hồng cho KOL, phản hồi hai chiều, kiểm duyệt AI tự động — những phần này để v2 sau khi xác nhận người dùng có quay video không" đã đủ để cứu cả dự án.
Bài học: Non-goals không phải là dấu hiệu của sự thiếu tham vọng. Nó là công cụ quyền lực nhất của PM để bảo vệ scope. Viết ra cái bạn KHÔNG làm cũng quan trọng như viết cái bạn làm.
Hướng dẫn từng bước
Đây là quy trình tự kiểm tra (self-audit) bạn nên chạy qua trước khi gửi bất kỳ PRD nào cho team. Mất khoảng 15 phút và cứu được hàng tuần.
Bước 1 — Đọc lại dòng đầu tiên. Câu mở đầu PRD nói về vấn đề hay về giải pháp? Nếu nó bắt đầu bằng "Xây...", "Thêm tính năng...", "Tích hợp..." — bạn đang solution-first. Viết lại để bắt đầu bằng vấn đề của người dùng.
Bước 2 — Highlight mọi tính từ và trạng từ mơ hồ. Quét cả tài liệu, tô vàng mọi từ như: nhanh, chậm, nhiều, ít, tốt hơn, mượt, thường xuyên, đa số, một số. Với mỗi từ, hỏi "con số cụ thể là bao nhiêu?". Nếu không trả lời được, đó là một lỗ hổng.
Bước 3 — Kiểm tra metric có thể vẽ thành biểu đồ không. Đặt câu hỏi: "Nếu tôi mở dashboard sau 4 tuần, tôi nhìn vào đường nào để biết thành công?". Nếu không chỉ ra được một con số cụ thể với mốc hiện tại và mốc mục tiêu, metric của bạn chưa đạt.
Bước 4 — Tìm mục Non-goals. Nếu chưa có, viết ngay ít nhất 3 dòng "Phiên bản này KHÔNG bao gồm...". Nghĩ về những thứ stakeholder có thể đề xuất thêm và chủ động loại trừ chúng.
Bước 5 — Truy lùng happy path. Đọc phần Solution và hỏi với mỗi bước: "Nếu bước này thất bại thì sao? Mạng lỗi? Dữ liệu rỗng? Người dùng làm sai?". Nếu PRD không trả lời, bổ sung error states.
Bước 6 — Săn giả định ngầm. Đọc và tự hỏi "tôi đang ngầm cho rằng điều gì là đúng?". Ví dụ: giả định người dùng đã đăng nhập, giả định có kết nối mạng, giả định dữ liệu luôn hợp lệ. Viết mọi giả định ra giấy.
Bước 7 — Kiểm tra phần Open Questions. Một PRD trung thực luôn có câu hỏi mở. Nếu mục này trống, có thể bạn đang giấu sự không chắc chắn. Liệt kê 2-3 điều bạn chưa chắc và ai sẽ trả lời.
Bước 8 — Hỏi "ai chưa được đọc cái này?". Trước buổi review chính thức, gửi bản nháp cho ít nhất một engineer và một designer để lấy phản hồi sớm. Đừng để buổi review là lần đầu họ nhìn thấy PRD.
Lỗi thường gặp & mẹo
Lỗi: nghĩ rằng PRD dài là PRD tốt. Nhiều PM mới tin rằng càng nhiều chữ càng chuyên nghiệp. Sai. Một PRD 2 trang rõ ràng tốt hơn 15 trang lan man. Engineer không có thời gian đọc tiểu thuyết. Mẹo: sau khi viết xong, cắt 30% và xem nó có mất thông tin quan trọng nào không — thường là không.
Lỗi: copy-paste PRD cũ mà không xóa phần thừa. Dùng lại template là tốt (bài 60 sẽ nói kỹ), nhưng copy nguyên PRD cũ rồi sửa qua loa thường để sót những câu không liên quan, khiến người đọc rối. Mẹo: khi tái sử dụng, đọc lại từng dòng và hỏi "câu này còn đúng với dự án mới không?".
Lỗi: dùng từ viết tắt/jargon nội bộ mà không giải thích. PRD thường có nhiều người ngoài team đọc. Viết "tích hợp với CDP qua webhook" mà không giải thích CDP là gì khiến nửa số người đọc bỏ cuộc. Mẹo: lần đầu dùng thuật ngữ, giải thích trong ngoặc.
Lỗi: gộp Problem và Solution làm một. PM viết "Vấn đề là người dùng không tìm thấy nút thanh toán nên ta cần làm nút to hơn màu đỏ". Đây không phải Problem statement — đây là giải pháp ngụy trang. Mẹo: Problem phải mô tả được kể cả khi bạn chưa biết giải pháp.
Lỗi: bỏ qua counter-metric. Chỉ đặt metric tăng trưởng mà quên metric bảo vệ. Tăng tỷ lệ click nhưng làm tăng tỷ lệ gỡ app thì là thất bại. Mẹo: với mỗi metric chính, hỏi "tối ưu nó quá đà có thể làm hỏng cái gì?" và đặt counter-metric tương ứng.
Mẹo vàng — quy tắc "người lạ đọc trong 30 giây": Đưa PRD cho một người hoàn toàn không biết dự án. Nếu sau 30 giây đọc phần đầu, họ không nói được "à, vấn đề là X, mục tiêu là Y" thì PRD của bạn đã hỏng ngay từ gốc.
Bài tập thực hành
Bài tập 1 — Phẫu thuật một PRD bệnh. Lấy đoạn PRD sau và viết lại cho đúng:
> "Chúng ta sẽ xây tính năng thông báo đẩy để cải thiện sự gắn kết của người dùng. Tính năng này sẽ gửi nhiều thông báo hữu ích và làm cho app tốt hơn."
Hãy chỉ ra ít nhất 3 lỗi (gợi ý: solution-first, metric mơ hồ, từ định lượng mơ hồ) và viết lại thành một đoạn mở đầu có Problem statement rõ, metric đo được, và ít nhất một non-goal.
Bài tập 2 — Audit PRD của chính bạn. Lấy một PRD bạn từng viết (hoặc một template trong khóa học). Chạy qua đủ 8 bước trong phần "Hướng dẫn từng bước". Đếm xem bạn tìm ra bao nhiêu lỗi. Ghi lại lỗi nào bạn hay mắc nhất — đó là điểm yếu cá nhân cần để ý.
Bài tập 3 — Viết Non-goals cho một tình huống. Cho tình huống: bạn được giao viết PRD cho tính năng "tìm kiếm bằng giọng nói" trên app mua sắm. Hãy viết ít nhất 5 dòng Non-goals — những thứ bạn cố tình KHÔNG làm ở v1. Suy nghĩ về cái stakeholder sẽ muốn nhồi thêm và chủ động loại trừ.
Bài tập 4 — Săn từ mơ hồ. Viết một đoạn mô tả tính năng dài khoảng 150 chữ, cố tình nhét vào càng nhiều từ mơ hồ càng tốt. Sau đó đổi bài với một bạn học (hoặc tự để qua một ngày) và thay mọi từ mơ hồ bằng con số/định nghĩa cụ thể. Bài tập này rèn phản xạ phát hiện sự mơ hồ.
Tóm tắt
Một PRD thất bại hiếm khi vì PM thiếu kiến thức — mà vì PM rơi vào những cái bẫy quen thuộc dưới áp lực. Bốn nhóm lỗi nguy hiểm nhất là: (1) lỗi nền tảng — solution-first, metric mơ hồ, thiếu non-goals; (2) lỗi độ rõ ràng — từ định lượng mơ hồ, giả định ngầm, quá tải kỹ thuật; (3) lỗi tính đầy đủ — bỏ quên edge cases và open questions; (4) lỗi quy trình — viết một mình và để PRD đông cứng.
Ba bài học từ thực tế: VíNhanh đốt 2 tháng vì solution-first; đội gọi xe không thể đóng dự án vì metric mơ hồ; sàn e-commerce Hà Nội mất cả dự án vì thiếu non-goals. Điểm chung là cái giá của lỗi PRD luôn lớn hơn nhiều lần công sức bỏ ra để tránh nó.
Hãy biến quy trình tự kiểm tra 8 bước thành thói quen trước khi gửi bất kỳ PRD nào. Và nhớ quy tắc vàng: nếu một người lạ không thể nói "vấn đề là X, mục tiêu là Y" sau 30 giây đọc, thì PRD của bạn cần viết lại từ gốc. Tránh lỗi không phải là cầu toàn — đó là tôn trọng thời gian của cả team đang tin tưởng đi theo tài liệu của bạn.