Mở đầu — vì sao bài này quan trọng
Có một sự thật khó chịu mà mọi PM đều phải đối mặt sớm hay muộn: không ai đọc PRD của bạn kỹ như bạn nghĩ. Một kỹ sư mở document của bạn lúc 10 giờ sáng, lướt qua trong 90 giây giữa hai cuộc họp, rồi quyết định xem họ có hiểu được feature hay không. Trong 90 giây đó, một sơ đồ rõ ràng đáng giá hơn ba đoạn văn mô tả logic. Não người xử lý hình ảnh nhanh hơn văn bản tới hàng chục lần — đó không phải khẩu hiệu truyền cảm hứng, đó là lý do vật lý vì sao một flow diagram tốt có thể cứu cả buổi review.
Nhưng đây mới là chỗ nhiều PM hiểu sai. Họ nghĩ "diagram = PRD chuyên nghiệp", rồi nhồi nhét sơ đồ vào mọi chỗ: vẽ flow cho một feature chỉ có hai bước, dán một architecture diagram khổng lồ mà chính họ cũng không hiểu, hoặc copy một wireframe đã lỗi thời ba phiên bản. Kết quả ngược lại: document trông rối rắm, người đọc mất niềm tin, và mỗi diagram trở thành một món nợ phải bảo trì.
Bài này không nói về việc vẽ đẹp. Nó nói về quyết định: khi nào một đoạn văn là đủ, khi nào bạn bắt buộc phải vẽ, và khi đã vẽ thì làm sao để hình ảnh đó giảm công sức đọc thay vì tăng nó. Đây là kỹ năng phân biệt giữa một PM viết PRD "có hình cho đẹp" và một PM dùng hình ảnh như một công cụ tư duy. Lưu ý: bài này tập trung vào nguyên tắc quyết định when & how cho diagram nói chung. Các loại diagram cụ thể như flow diagram conventions hay wireframe vs hi-fi mock đã có bài riêng — ở đây chúng ta học cách lùi lại một bước và chọn đúng.
Khái niệm cốt lõi
Nguyên tắc nền: diagram là để giảm tải nhận thức, không phải để trang trí
Mỗi yếu tố bạn đưa vào PRD đều có "chi phí". Một đoạn văn tốn thời gian đọc. Một diagram tốn thời gian giải mã — người đọc phải hiểu ký hiệu, hướng mũi tên, ý nghĩa màu sắc. Diagram chỉ xứng đáng tồn tại khi chi phí giải mã nó nhỏ hơn chi phí đọc đoạn văn tương đương. Đây là phép thử số một: nếu bạn có thể nói điều gì đó rõ ràng trong một câu, đừng vẽ. Diagram dành cho những thứ mà ngôn ngữ tuần tự (đọc từ trái sang phải, trên xuống dưới) làm tệ — đó là những mối quan hệ đa chiều, song song, hoặc rẽ nhánh.
Bốn trường hợp bắt buộc nên có diagram
Qua nhiều năm review PRD, bạn sẽ thấy đa số nhu cầu vẽ rơi vào bốn nhóm rõ rệt:
1. Multi-step flow — luồng nhiều bước (thường trên 3 màn hình). Khi người dùng đi qua một chuỗi màn hình, mô tả bằng chữ "sau đó họ nhấn tiếp, rồi đến màn hình xác nhận, nếu lỗi thì quay lại..." nhanh chóng trở thành mê cung. Một flow diagram cho phép người đọc thấy toàn cảnh hành trình trong một cái nhìn. Quy tắc ngón tay cái: dưới 3 màn hình thì viết chữ, từ 3 màn hình trở lên thì vẽ.
2. Decision tree — cây quyết định (logic if/else phức tạp). Khi feature có nhiều nhánh điều kiện — "nếu user đã verify VÀ có số dư VÀ chưa quá hạn mức thì A, ngược lại nếu... thì B" — văn bản sẽ buộc người đọc phải tự giữ trạng thái trong đầu. Cây quyết định biến logic ẩn thành hình ảnh tường minh, và quan trọng hơn, nó lộ ra những nhánh bạn quên xử lý.
3. System architecture — kiến trúc hệ thống (khi feature đi qua nhiều service). Khi một tính năng chạm vào nhiều thành phần — app gọi API, API gọi service thanh toán, service đó gọi đối tác bên thứ ba — một sequence diagram hoặc architecture diagram cho thấy ai gọi ai, theo thứ tự nào. Đây là loại diagram mà bạn nên làm cùng engineer, không phải vẽ một mình.
4. Comparison — so sánh (giữa các phương án, trạng thái before/after, hoặc các option). Khi bạn cần đặt nhiều thứ cạnh nhau để người đọc thấy khác biệt — phương án A vs B vs C, hoặc UI hiện tại vs UI đề xuất — một bảng so sánh hoặc cặp hình before/after truyền tải nhanh hơn nhiều so với mô tả tuần tự từng cái.
Ba phương án onboarding tài xế: thủ công, tự động, hybrid:
flowchart LR
subgraph Phương án A
A1[Xác minh thủ công]
end
subgraph Phương án B
B1[OCR tự động]
end
subgraph Phương án C
C1[OCR trước] --> C2[Người duyệt trường hợp không chắc]
endKhi nào KHÔNG nên vẽ
Đối trọng cũng quan trọng không kém. Đừng vẽ khi: (a) logic đủ đơn giản để gói trong một câu; (b) bạn chưa chắc về thiết kế — một diagram chi tiết tạo cảm giác "đã chốt" trong khi thực ra còn đang khám phá, dễ khóa cứng tư duy quá sớm; (c) diagram sẽ thay đổi liên tục — bạn sẽ tốn công cập nhật và nó sẽ lỗi thời nhanh; (d) bạn vẽ chỉ vì "PRD chuyên nghiệp phải có hình". Một PRD 1.000 chữ không có diagram nào nhưng rõ ràng còn tốt hơn một PRD đầy sơ đồ rối.
Ba tầng "độ phân giải" của visual
Không phải mọi visual đều phải hoàn hảo. Hãy nghĩ theo ba tầng, chọn tầng thấp nhất đủ truyền đạt ý:
- Tầng phác (sketch): vẽ tay, chụp ảnh, hoặc box-and-arrow thô. Dùng khi ý tưởng còn sớm, mục đích là khơi gợi thảo luận. Càng thô càng tốt — nó báo hiệu "chưa chốt, mời góp ý".
- Tầng sơ đồ chuẩn (diagram): flowchart, sequence diagram, ERD vẽ bằng công cụ. Dùng cho PRD chính thức cần review. Gọn gàng, có chú thích, nhưng không cần đẹp như sản phẩm.
- Tầng tinh (polished): mock hi-fi, infographic. Hiếm khi cần trong PRD — dành cho buổi present với leadership hoặc tài liệu đối ngoại.
Tình huống thực tế
Ví dụ 1 — MoMo và luồng hoàn tiền 7 bước
Một PM tại một ví điện tử lớn ở Việt Nam (gọi là "MoMo" cho dễ hình dung) viết PRD cho tính năng hoàn tiền (refund) khi giao dịch lỗi. Bản đầu, cô mô tả bằng chữ: người dùng mở giao dịch, nhấn "Báo lỗi", hệ thống kiểm tra trạng thái, nếu giao dịch đã settle thì tạo refund request, nếu chưa settle thì hủy trực tiếp, sau đó gửi cho đối tác ngân hàng, chờ phản hồi, cập nhật trạng thái, thông báo cho user.
Đoạn văn này dài 4 câu nhưng trong buổi review, ba engineer hỏi ba câu khác nhau về cùng một nhánh: "Nếu đối tác ngân hàng timeout thì sao?", "Settle là tính theo lúc nào?", "User thấy gì trong lúc chờ?". Họ không hỏi vì PM viết sai — họ hỏi vì văn bản tuần tự che mất các nhánh song song.
PM về vẽ lại bằng một flow diagram có 7 node và 3 nhánh điều kiện. Trong buổi review tiếp theo, đúng một câu hỏi được đặt ra — và đó là câu hỏi về một nhánh mà chính diagram để trống: trường hợp đối tác timeout. Chính việc vẽ ra đã phơi bày lỗ hổng. Bài học: với luồng trên 3 màn hình và có rẽ nhánh, diagram không chỉ giúp người đọc hiểu nhanh hơn — nó còn buộc chính bạn phải xử lý đủ mọi nhánh, vì một mũi tên cụt là bằng chứng nhãn tiền của một edge case bị bỏ quên.
Ví dụ 2 — Tiki và cái architecture diagram không ai cần
Một PM tại một sàn thương mại điện tử (gọi là "Tiki") viết PRD cho tính năng thêm nút "Lưu sản phẩm vào danh sách yêu thích". Đây là một feature đơn giản: nhấn nút, gọi API, lưu vào database, đổi trạng thái icon. Nhưng vì muốn PRD trông "đủ tầm", PM dán vào một architecture diagram đầy đủ: client, API gateway, microservice, message queue, cache layer, database replica — 11 box và 14 mũi tên.
Kết quả là buổi review bị lạc hướng. Một senior engineer dành 10 phút tranh luận về việc có thực sự cần message queue cho một thao tác đơn giản thế này không — một cuộc tranh luận về implementation mà lẽ ra thuộc về engineer, không phải PRD. Feature đáng lẽ được duyệt trong 5 phút thì kéo dài 25 phút, và phần thực sự quan trọng (hành vi với danh sách yêu thích khi sản phẩm hết hàng) thì không ai bàn tới.
Bài học: architecture diagram chỉ nên xuất hiện khi feature thực sự đi qua nhiều service theo cách không hiển nhiên, và nên do PM làm cùng engineer. Với một CRUD đơn giản, một câu "nhấn nút → gọi API lưu → đổi trạng thái icon" là đủ. Diagram sai chỗ không chỉ vô dụng — nó chủ động làm hại bằng cách kéo sự chú ý vào nơi không cần.
Ví dụ 3 — Grab và bảng so sánh ba phương án onboarding
Đội product tại một super-app (gọi là "Grab") cần quyết định cách onboard tài xế mới: (A) xác minh giấy tờ thủ công bởi nhân viên, (B) xác minh tự động bằng OCR, (C) hybrid — OCR trước, người duyệt các trường hợp OCR không chắc. PM ban đầu viết ba đoạn văn cho ba phương án, mỗi đoạn nói về tốc độ, chi phí, độ chính xác, rủi ro.
Vấn đề: để so sánh "độ chính xác của A với C", người đọc phải nhảy giữa đoạn 1 và đoạn 3, tự ghép thông tin. Trong buổi quyết định, mọi người cứ lật qua lật lại, mỗi người nhớ một con số khác nhau.
PM thay ba đoạn văn bằng một bảng: hàng là tiêu chí (thời gian onboard trung bình, chi phí mỗi hồ sơ, tỉ lệ sai, effort kỹ thuật), cột là ba phương án, mỗi ô một con số hoặc một mức cao/trung/thấp. Quyết định được chốt trong 8 phút: phương án C, vì bảng cho thấy nó đạt 90% tốc độ của B với độ chính xác gần bằng A, chỉ tốn thêm một phần nhỏ effort. Bài học: khi nội dung cốt lõi là so sánh nhiều chiều giữa nhiều lựa chọn, bảng (một dạng visual) thắng tuyệt đối văn xuôi. Văn xuôi tuyến tính ép người đọc tự dựng bảng trong đầu — hãy dựng sẵn cho họ.
Hướng dẫn từng bước
Đây là quy trình thực dụng để quyết định và tạo diagram cho mỗi phần của PRD:
Bước 1 — Viết bằng chữ trước. Luôn diễn đạt ý bằng văn bản trước. Nếu một câu là đủ rõ, dừng lại — bạn không cần diagram. Việc viết chữ trước cũng giúp bạn kiểm tra liệu mình có thực sự hiểu logic hay không. Người không diễn đạt được bằng chữ thường cũng vẽ ra diagram lộn xộn.
Bước 2 — Áp dụng bốn câu hỏi sàng lọc. Hỏi: (1) Đây có phải luồng trên 3 màn hình không? (2) Có logic rẽ nhánh phức tạp không? (3) Có đi qua nhiều service theo cách không hiển nhiên không? (4) Mình có đang so sánh nhiều phương án/trạng thái không? Nếu không câu nào "có", đừng vẽ. Nếu "có", chuyển sang bước 3.
Bước 3 — Chọn đúng loại visual cho nhu cầu. Luồng nhiều bước → flowchart. Logic if/else → decision tree. Tương tác giữa các service theo thời gian → sequence diagram. So sánh phương án → bảng. Quan hệ dữ liệu → ERD. Đừng dùng một loại cho mọi việc; chọn loại mà bộ não người đọc giải mã nhanh nhất cho nội dung đó.
Bước 4 — Chọn độ phân giải thấp nhất đủ dùng. Ý còn sớm và cần thảo luận? Vẽ phác, thậm chí chụp ảnh bảng trắng. PRD chính thức cần review? Vẽ bằng công cụ, gọn gàng, có chú thích. Đừng polish quá mức cho thứ chưa chốt.
Bước 5 — Đặt diagram cạnh văn bản giải thích, không thay thế. Mỗi diagram cần một câu dẫn ở trên ("Sơ đồ dưới mô tả luồng hoàn tiền; chú ý nhánh khi đối tác timeout") và, nếu cần, vài dòng diễn giải các điểm tinh tế bên dưới. Diagram trần trụi không lời dẫn buộc người đọc tự đoán ý đồ.
Bước 6 — Ghi nguồn và ngày. Thêm dòng nhỏ: "Vẽ bằng [công cụ], cập nhật [ngày], link gốc: [...]". Điều này cho người đọc biết diagram còn mới hay đã cũ, và biết tìm bản gốc để sửa.
Bước 7 — Tự kiểm: có mũi tên cụt nào không? Trước khi nộp, rà mọi node: mỗi nhánh điều kiện đã có đủ lối ra chưa? Mọi luồng có điểm kết thúc rõ ràng chưa? Mũi tên cụt = edge case bị bỏ quên.
Lỗi thường gặp & mẹo
Lỗi: vẽ vì nghĩ "PRD phải có hình". Diagram không phải huy hiệu chứng minh sự chuyên nghiệp. Một câu rõ ràng đánh bại một sơ đồ thừa. Mẹo: với mỗi diagram, tự hỏi "nếu xóa nó đi, người đọc có mất gì không?". Nếu không, xóa.
Lỗi: diagram lỗi thời. Diagram trong PRD rất hay bị bỏ quên khi feature thay đổi, dẫn đến tài liệu nói một đằng, sản phẩm một nẻo — nguy hiểm hơn cả không có diagram. Mẹo: với phần còn đang biến động, dùng sketch thô thay vì hi-fi (sketch tự báo hiệu "tạm thời"), và ghi rõ ngày cập nhật.
Lỗi: nhồi quá nhiều vào một diagram. Một flowchart 40 node không ai đọc nổi. Mẹo: nếu một diagram có trên 10-12 phần tử, hãy tách thành nhiều diagram theo tầng — một sơ đồ tổng quan và vài sơ đồ chi tiết cho từng nhánh.
Lỗi: ký hiệu tự chế không chú thích. Bạn dùng hình thoi cho điều kiện, màu đỏ cho lỗi, nét đứt cho "tương lai" — nhưng không ai biết. Mẹo: thêm một legend (chú giải) nhỏ nếu dùng bất kỳ quy ước màu/hình nào ngoài chuẩn.
Lỗi: polish quá sớm cho thứ chưa chốt. Một mock đẹp lung linh khiến người ta ngại góp ý và khiến chính bạn ngại sửa. Mẹo: độ "thô" của visual nên tỉ lệ thuận với độ chắc chắn của quyết định. Còn bàn cãi thì vẽ xấu một cách có chủ đích.
Mẹo công cụ: ưu tiên công cụ tạo diagram dạng text (như Mermaid) cho flow và sequence — vì chúng sống ngay trong document, dễ sửa, dễ version-control, không bị lỗi thời kiểu ảnh tĩnh. Dành công cụ kéo-thả (Figma, Excalidraw, Whimsical) cho khi cần bố cục linh hoạt hoặc trình bày trực quan hơn.
Bài tập thực hành
Lấy một PRD bạn đã viết gần đây (hoặc một tính năng quen thuộc của một app bạn dùng hàng ngày — ví dụ luồng đặt món trên ShopeeFood).
- Sàng lọc: Đọc lại từng phần, đánh dấu mỗi chỗ áp dụng bốn câu hỏi sàng lọc cho "có". Liệt kê những chỗ đáng có diagram nhưng đang viết bằng chữ, và những chỗ đang có diagram nhưng thực ra một câu là đủ.
- Vẽ một flow: Chọn một luồng trên 3 màn hình trong feature đó, vẽ flowchart bằng Mermaid hoặc bút giấy. Buộc bản thân đánh dấu mọi nhánh điều kiện. Đếm xem có bao nhiêu mũi tên cụt — mỗi cái là một edge case bạn vừa phát hiện.
- Dựng một bảng so sánh: Nghĩ ra hai phương án giải quyết cho một vấn đề trong feature đó. Dựng bảng so sánh theo ít nhất 4 tiêu chí. Quan sát xem bảng có giúp bạn thấy phương án thắng rõ hơn so với khi nghĩ trong đầu không.
- Tự phê bình: Với mỗi visual bạn vừa tạo, áp dụng phép thử "xóa đi có mất gì không?". Giữ lại những cái vượt qua, bỏ phần còn lại.
Tóm tắt
Diagram trong PRD là công cụ giảm tải nhận thức, không phải đồ trang trí. Hãy luôn viết bằng chữ trước; chỉ vẽ khi rơi vào một trong bốn trường hợp: luồng nhiều bước (trên 3 màn hình), logic rẽ nhánh phức tạp, feature đi qua nhiều service, hoặc so sánh nhiều phương án. Chọn đúng loại visual cho nội dung — flowchart cho luồng, decision tree cho logic, sequence diagram cho tương tác giữa các service, bảng cho so sánh. Dùng độ phân giải thấp nhất đủ dùng: vẽ thô cho thứ chưa chốt, gọn gàng cho PRD review, và hiếm khi cần hi-fi. Luôn đặt diagram cạnh văn bản giải thích, ghi nguồn và ngày, và rà soát mũi tên cụt như những edge case bị bỏ quên. Phép thử cuối cùng cho mọi visual: "nếu xóa nó, người đọc có mất gì không?" — nếu không, hãy xóa. Một PM giỏi không phải người vẽ nhiều nhất, mà là người biết khi nào một câu là đủ và khi nào một hình ảnh đáng giá hơn cả nghìn chữ.