Mở đầu — vì sao bài này quan trọng
Bạn có thể có ý tưởng sản phẩm xuất sắc, hiểu vấn đề của người dùng sâu sắc hơn bất kỳ ai trong công ty. Nhưng nếu PRD của bạn dài dòng, mơ hồ, lan man, thì engineer đọc lướt qua, designer hiểu sai một nửa, và sếp thì gật gù phê duyệt mà không thực sự nắm được bạn định làm gì. Tài liệu là giao diện duy nhất giữa cái đầu của bạn và phần còn lại của tổ chức. Văn phong tệ giống như một API trả về dữ liệu lộn xộn: ai gọi vào cũng phải đoán.
Đây là điều ít người nói thẳng với PM mới: chất lượng tư duy của bạn được đánh giá qua chất lượng câu chữ của bạn. Một câu văn vòng vo thường không phải lỗi viết, mà là dấu hiệu bạn chưa nghĩ thông. Khi bạn buộc mình viết ngắn, rõ, cụ thể, bạn cũng buộc mình phải nghĩ rõ. Vì vậy, học viết tốt không chỉ giúp người khác đọc dễ hơn — nó còn làm chính bạn trở thành một PM sắc bén hơn.
Trong các bài trước, bạn đã học viết cái gì vào từng phần của PRD: problem, goals, user stories, edge cases. Bài này tập trung vào viết như thế nào — ở cấp độ câu và từ. Đây là lớp kỹ năng nền, áp dụng cho mọi loại tài liệu bạn từng viết và sẽ viết. Một PRD đúng cấu trúc nhưng viết tệ vẫn là một PRD tệ.
Khái niệm cốt lõi
Có bốn nguyên tắc nền tảng. Hãy nhớ chúng như bốn cái cần gạt bạn luôn kéo về một phía mỗi khi viết.
1. Active voice > passive voice (chủ động hơn bị động)
Câu chủ động nói rõ ai làm gì. Câu bị động giấu chủ thể đi, khiến trách nhiệm và hành động trở nên mơ hồ.
- Bị động: "Thông báo sẽ được gửi tới người dùng." → Ai gửi? Hệ thống? Service nào? Khi nào?
- Chủ động: "Notification Service gửi push tới người dùng trong vòng 5 giây sau khi đơn hàng được xác nhận."
2. Concrete > abstract (cụ thể hơn trừu tượng)
Từ trừu tượng nghe sang nhưng rỗng. "Cải thiện trải nghiệm", "tối ưu hiệu suất", "nâng cao engagement" — những cụm này không gắn vào hành động hay con số nào cả, nên ai đọc cũng tự vẽ ra một bức tranh khác nhau.
- Trừu tượng: "Chúng ta cần cải thiện trải nghiệm thanh toán."
- Cụ thể: "Giảm số bước thanh toán từ 5 màn hình xuống 2, và bỏ yêu cầu nhập lại địa chỉ với khách hàng cũ."
3. Short > long (ngắn hơn dài)
Mỗi từ thừa làm loãng tín hiệu. Người đọc tài liệu kỹ thuật không đọc để thưởng thức — họ đọc để lấy thông tin và quay lại làm việc. Câu càng dài, xác suất họ lạc ý càng cao.
Quy tắc thực dụng: một câu nên chứa một ý. Nếu câu của bạn có hai chữ "và" hoặc một dấu phẩy nối ba mệnh đề, hãy tách ra. Đoạn văn nên dưới 4 câu. Mục nào liệt kê được thì dùng bullet thay vì viết thành đoạn.
- Dài: "Trong trường hợp người dùng thực hiện thao tác đăng nhập mà hệ thống phát hiện ra rằng thông tin xác thực được cung cấp là không chính xác thì khi đó một thông báo lỗi sẽ được hiển thị."
- Ngắn: "Nếu sai mật khẩu, hiển thị lỗi: 'Email hoặc mật khẩu không đúng.'"
4. Specific > generic (chi tiết hơn chung chung)
Khác với "cụ thể" ở chỗ specific nhấn mạnh chi tiết phân biệt. Generic là viết kiểu ai cũng viết được, không gắn với sản phẩm của bạn. Specific là khi câu chữ chỉ đúng cho đúng tính năng này.
- Generic: "Người dùng có thể tìm kiếm sản phẩm."
- Specific: "Người dùng gõ từ khóa, thấy gợi ý autocomplete sau 200ms, và có thể lọc theo giá / thương hiệu / đánh giá ngay trên trang kết quả."
Một nguyên tắc bao trùm: viết cho người đọc, không phải cho bản thân
PM hay viết để chứng tỏ mình đã suy nghĩ kỹ — nhồi nhét mọi thứ mình biết vào tài liệu. Nhưng người đọc cần quyết định và hành động, không cần xem bạn đã làm việc vất vả thế nào. Trước mỗi đoạn, hãy hỏi: "Người đọc cần biết điều này để làm gì?" Nếu không trả lời được, cắt.
Tình huống thực tế
Ví dụ 1 — Tiki: một câu PRD khiến hai team hiểu khác nhau
Một PM tại một sàn thương mại điện tử lớn ở Việt Nam (tạm gọi mô hình giống Tiki) viết trong PRD tính năng flash sale: "Hệ thống cần đảm bảo việc hiển thị sản phẩm được tối ưu để mang lại trải nghiệm tốt nhất cho người dùng trong khung giờ cao điểm."
Khi triển khai, team backend hiểu "tối ưu" là cache aggressive để chịu tải. Team frontend hiểu là thêm animation đếm ngược cho hấp dẫn. Đến sprint review mới lộ ra hai bên làm hai hướng. Mất gần một tuần để đồng bộ lại.
Vấn đề nằm ở văn phong: câu đó vừa trừu tượng ("tối ưu", "trải nghiệm tốt nhất"), vừa bị động ("được tối ưu"), vừa không chi tiết. PM viết lại sau buổi retro: "Trong khung 12h–13h, trang flash sale phải load dưới 1.5 giây với 50.000 người truy cập đồng thời. Mỗi sản phẩm hiển thị: ảnh, giá gốc gạch ngang, giá sale, thanh tiến độ 'đã bán X%', và bộ đếm ngược tới khi hết giờ.'"
Bản mới dài hơn một chút về số từ nhưng đóng kín mọi khoảng trống. Backend biết chính xác chỉ tiêu hiệu năng. Frontend biết chính xác phải render gì. Bài học: một câu trừu tượng tiết kiệm chữ nhưng tốn cả tuần công sức; một câu cụ thể tốn vài chữ nhưng tiết kiệm cả tuần.
Ví dụ 2 — Một startup fintech: cắt PRD từ 8 trang xuống 3 trang
Một startup ví điện tử ở TP.HCM có PM viết PRD trung bình 8 trang. Engineer phàn nàn không ai đọc hết, thường chỉ lướt qua phần user stories rồi bỏ qua context. Trưởng nhóm yêu cầu thử nghiệm: mọi PRD phải dưới 4 trang.
PM ban đầu phản đối, sợ cắt mất thông tin quan trọng. Nhưng khi buộc phải cắt, họ phát hiện ra 60% nội dung là "văn lấp đầy" — những đoạn mở bài kiểu "Như chúng ta đều biết, trong bối cảnh thị trường fintech ngày càng cạnh tranh...", những câu lặp lại ý đã nói, những giải thích quá dài cho điều hiển nhiên. Sau khi cắt:
- Phần mở đầu 3 đoạn → 2 câu.
- "Background and context" 1.5 trang → một bảng 5 dòng.
- Mỗi user story bỏ phần "lý do tại sao tính năng này quan trọng" (đã nói ở goals rồi).
Ví dụ 3 — Grab: passive voice che giấu một quyết định chưa ai đưa ra
Trong một spec về xử lý hoàn tiền (refund) cho một ứng dụng gọi xe khu vực Đông Nam Á (mô hình giống Grab), có câu: "Khi đơn bị hủy, tiền sẽ được hoàn lại cho khách hàng."
Câu này nghe trọn vẹn nên không ai chất vấn. Đến khi build, engineer hỏi dồn: hoàn về đâu — ví trong app hay thẻ ngân hàng gốc? Hoàn ngay hay sau khi tài xế xác nhận? Hoàn toàn bộ hay trừ phí hủy? Hóa ra không ai từng quyết định những điều này — câu bị động "sẽ được hoàn lại" đã khéo léo giấu đi sự thiếu vắng chủ thể và chi tiết.
PM viết lại theo lối chủ động, buộc phải điền chủ thể vào: "Payment Service hoàn tiền về ví GrabPay trong vòng 2 phút sau khi hệ thống xác nhận hủy. Nếu khách thanh toán bằng thẻ, Payment Service hoàn về thẻ gốc trong 3–5 ngày làm việc. Phí hủy (nếu áp dụng) được trừ trước khi hoàn." Quá trình viết lại lộ ra ba quyết định còn bỏ ngỏ. Bài học: active voice không chỉ là phong cách — nó là công cụ phát hiện lỗ hổng. Khi bạn không điền được chủ thể vào câu, đó là một quyết định chưa được đưa ra.
Hướng dẫn từng bước
Đây là quy trình áp dụng được ngay cho mỗi tài liệu bạn viết:
Bước 1 — Viết bản nháp nhanh, đừng tự kiểm duyệt. Cứ tuôn ý ra trước. Đừng cố viết hay ngay từ đầu — bạn sẽ bị kẹt. Mục tiêu của bản nháp là có đủ ý, không phải viết đẹp.
Bước 2 — Đọc lại và săn passive voice. Quét từng câu, tìm các cụm "được + động từ" ("được gửi", "được xử lý", "được hiển thị"). Với mỗi câu, hỏi "Ai làm?" và viết lại với chủ thể rõ ràng. Nếu không biết chủ thể, đánh dấu lại — đó là một câu hỏi mở cần giải quyết.
Bước 3 — Săn từ trừu tượng. Khoanh các từ như "tối ưu", "cải thiện", "nâng cao", "trải nghiệm tốt", "hiệu quả", "linh hoạt". Với mỗi từ, thay bằng con số, hành động hoặc tiêu chí đo được. Không thay được nghĩa là bạn chưa nghĩ đủ sâu.
Bước 4 — Cắt không thương tiếc. Đọc lại từng câu và hỏi: "Bỏ câu này đi, người đọc có mất thông tin để hành động không?" Nếu không, xóa. Đặc biệt nhắm vào: câu mở bài sáo rỗng, ý lặp lại, lời giải thích cho điều hiển nhiên, và các cụm đệm ("về cơ bản", "nói chung là", "trong trường hợp mà", "việc thực hiện").
Bước 5 — Tách câu dài, dùng bullet. Câu nào có hai mệnh đề trở lên thì tách. Danh sách nào liệt kê được thì chuyển thành bullet. Bảng nào so sánh được thì chuyển thành bảng.
Bước 6 — Đọc to lên. Đây là mẹo đơn giản mà hiệu nghiệm nhất. Nếu bạn hụt hơi giữa câu, câu đó quá dài. Nếu bạn vấp ở chỗ nào, người đọc cũng vấp ở đó. Tai bắt lỗi mà mắt bỏ sót.
Bước 7 — Đưa cho một người không trong dự án đọc 30 giây. Hỏi họ "Tài liệu này yêu cầu làm gì?" Nếu họ trả lời sai hoặc ngập ngừng, vấn đề là ở câu chữ của bạn, không phải ở họ.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm dài với kỹ lưỡng. Nhiều PM viết dài vì sợ bị chê hời hợt. Thực tế ngược lại: người đọc giỏi đánh giá cao tài liệu ngắn gọn vì nó tôn trọng thời gian của họ. Mẹo: đặt giới hạn trang cứng cho mỗi loại tài liệu (one-pager 1 trang, PRD 3–4 trang) và coi đó là ràng buộc thiết kế, không phải gợi ý.
Lỗi 2 — Dùng từ to để nghe sang. "Leverage", "synergy", "tận dụng tối đa nguồn lực", "đột phá toàn diện". Buzzword làm câu nghe oách nhưng rỗng nghĩa. Mẹo: với mỗi từ kêu, thử thay bằng từ đời thường nhất. "Leverage AI" → "dùng AI". Nếu nghĩa không đổi, từ to chỉ là trang trí.
Lỗi 3 — Hedging quá đà. "Có thể chúng ta nên cân nhắc việc có lẽ thử nghiệm..." Khi viết spec, hedging quá nhiều khiến không ai biết bạn quyết hay chưa. Mẹo: phân biệt rõ điều đã quyết (viết khẳng định: "Chúng ta làm X") và điều còn mở (đưa vào mục Open Questions, đừng rải hedging khắp văn bản).
Lỗi 4 — Đại từ mơ hồ. "Nó", "cái này", "điều đó" khi không rõ chỉ về cái gì. "Khi user nhấn nút và hệ thống tải dữ liệu, nó sẽ hiển thị..." — nó là cái nút hay hệ thống hay dữ liệu? Mẹo: thay đại từ bằng danh từ cụ thể, kể cả khi nghe hơi lặp. Rõ ràng quan trọng hơn duyên dáng.
Lỗi 5 — Bắt đầu mọi đoạn bằng văn dẫn nhập. "Trước khi đi vào chi tiết, cần lưu ý rằng...", "Như đã đề cập ở trên...". Mẹo: vào thẳng ý chính ở câu đầu mỗi đoạn (nguyên tắc BLUF — Bottom Line Up Front: kết luận lên trước).
Mẹo vàng: giữ một "danh sách từ cấm" của riêng bạn — những từ trừu tượng bạn hay lạm dụng (tối ưu, cải thiện, mạnh mẽ, linh hoạt...). Mỗi lần định viết một từ trong danh sách, dừng lại và viết cụ thể hơn.
Bài tập thực hành
Bài 1 — Viết lại 5 câu. Lấy 5 câu dưới đây, viết lại theo cả bốn nguyên tắc (chủ động, cụ thể, ngắn, chi tiết):
- "Trải nghiệm onboarding cần được cải thiện để nâng cao tỷ lệ giữ chân."
- "Trong trường hợp có lỗi xảy ra thì người dùng sẽ được thông báo."
- "Hệ thống cần phải xử lý tốt các tình huống tải cao."
- "Việc tìm kiếm sẽ được tối ưu hóa để mang lại kết quả phù hợp."
- "Chúng ta nên cân nhắc việc có thể bổ sung thêm một số tính năng liên quan đến chia sẻ."
Bài 3 — Test đọc to. Lấy một đoạn bất kỳ bạn viết, đọc to. Đánh dấu mọi chỗ bạn hụt hơi hoặc vấp. Viết lại những câu đó.
Bài 4 — Lập danh sách từ cấm. Đọc lại 3 tài liệu cũ của bạn, liệt kê 10 từ trừu tượng bạn lặp lại nhiều nhất. Dán danh sách này cạnh màn hình khi viết tài liệu tiếp theo.
Tóm tắt
Văn phong không phải lớp trang trí phủ lên tài liệu — nó là giao diện truyền tải tư duy của bạn ra cả tổ chức. Bốn cần gạt luôn kéo về một phía: chủ động hơn bị động, cụ thể hơn trừu tượng, ngắn hơn dài, chi tiết hơn chung chung.
Ba bài học cốt lõi từ thực tế: một câu trừu tượng tiết kiệm chữ nhưng tốn cả tuần đồng bộ (Tiki); tài liệu ngắn thể hiện tư duy đã được nén, không phải tư duy hời hợt (fintech cắt 8 trang còn 3); và passive voice thường che giấu một quyết định chưa ai đưa ra (Grab refund). Khi bạn không điền được chủ thể vào câu, hay không thay được từ trừu tượng bằng con số, đó là tín hiệu tư duy còn lỗ hổng — viết tốt buộc bạn nghĩ tốt.
Hãy biến quy trình bảy bước thành thói quen: nháp nhanh, săn passive, săn trừu tượng, cắt không thương tiếc, tách câu, đọc to, kiểm tra với người ngoài. Mỗi tài liệu rõ và ngắn bạn viết ra đều âm thầm xây dựng uy tín của bạn như một PM biết suy nghĩ rành mạch.