Đừng Nhớ Template: Tư Duy Cốt Lõi Khi Viết PRD Cho PM

Tư Duy Cốt Lõi: Đọc Vị Khán Giả Của PRD

Bạn không viết PRD cho bản thân. Bạn viết cho 3 nhóm đối tượng — và mỗi nhóm tìm kiếm thứ khác nhau khi mở tài liệu ra:

Software Engineers hỏi: "Logic này chạy thế nào? Khi nào thì state thay đổi? Điều gì xảy ra nếu dữ liệu bị null?" Họ ghét mô tả cảm tính ("trải nghiệm mượt mà", "giao diện thân thiện") và thích luồng dữ liệu, business rules, edge cases được viết ra rõ ràng.

QA / Testers hỏi: "Acceptance Criteria nào để tôi viết test case? Định nghĩa 'done' là gì?" Một AC kiểu "Hệ thống hoạt động bình thường" là vô dụng. Một AC kiểu "Khi user nhập sai OTP 5 lần, tài khoản bị khóa 15 phút và email thông báo được gửi đến địa chỉ đã đăng ký" mới có thể test được.

Business Stakeholders hỏi: "Tại sao chúng ta làm việc này? Nó ảnh hưởng gì đến business? Khi nào xong?" Họ không cần đọc state machine — họ cần biết khi nào feature lên production và số nào sẽ thay đổi trên dashboard.

Hiểu được ai đọc gì, bạn mới biết cần viết gì và cần bỏ gì.

4 Trụ Cột Bất Biến Của Mọi Tài Liệu Sản Phẩm

Dù công ty bạn dùng 1-Pager kiểu Intercom, PRFAQ kiểu Amazon, hay SRS truyền thống — một tài liệu yêu cầu sản phẩm chất lượng bắt buộc phải trả lời được 4 nhóm câu hỏi sau.

1. The "Why" — Bối Cảnh & Mục Tiêu

Đừng bắt Dev code một thứ mà họ không hiểu nó giải quyết vấn đề gì.

Problem Statement cần trả lời: Khách hàng đang gặp khó khăn gì? Tại sao phải giải quyết ngay bây giờ thay vì quý sau? Ví dụ yếu: "User không hài lòng với flow checkout." Ví dụ tốt: "Funnel analytics cho thấy 40% user drop-off tại bước nhập địa chỉ giao hàng — cao hơn benchmark ngành 2.5 lần. Support ticket liên quan đến checkout tăng 30% trong Q3."

Success Metrics cần cụ thể và có baseline. "Tăng Conversion Rate ở bước Checkout từ 15% lên 18% trong 60 ngày sau launch" là target có thể đo. "Cải thiện UX checkout" thì không ai biết khi nào được gọi là thành công.

Out-of-Scope là phần quan trọng nhất để chống Scope Creep — và thường xuyên bị bỏ qua nhất. Định nghĩa rõ ranh giới. Ví dụ: "Phase này KHÔNG bao gồm: lưu địa chỉ giao hàng vào profile, tích hợp với hệ thống địa chỉ của bên thứ ba, hoặc hỗ trợ địa chỉ quốc tế." Viết ra những gì không làm còn quan trọng hơn viết ra những gì sẽ làm.

2. The "What" — Giải Pháp & Trải Nghiệm

Phần này mô tả cách người dùng tương tác với sản phẩm — từ góc nhìn của họ, không phải từ góc nhìn kỹ thuật.

User Story theo format chuẩn: "Với tư cách là [persona], tôi muốn [hành động] để [mục tiêu]." Ví dụ: "Với tư cách là khách hàng mua lần đầu, tôi muốn hệ thống tự điền địa chỉ dựa trên mã bưu chính để không phải gõ tay từng trường."

Anti-pattern phổ biến cần tránh:

• Quá vague: "User có thể quản lý địa chỉ" — quản lý nghĩa là gì? Thêm? Sửa? Xóa? Đặt mặc định?
• Quá techie: "System call API để fetch address từ database" — đây là implementation detail, không phải user story.
• Thiếu persona: "User muốn thanh toán nhanh hơn" — user nào? First-time buyer hay returning customer có nhu cầu khác nhau.

User Flow nên trả lời: Event bắt đầu từ đâu? Người dùng đi qua những màn hình/trạng thái nào? Kết thúc bằng outcome gì? Happy path quan trọng, nhưng hãy mark rõ branching points — đó là nơi edge cases xuất hiện.

3. The "How" — Logic Hệ Thống & Ràng Buộc

Đây là ranh giới phân biệt giữa người viết tài liệu và người thực sự hiểu sản phẩm. Mọi template đều có thể thiếu sót phần này — nhưng đây chính là nơi bugs được sinh ra.

Business Rules là những quy tắc nghiệp vụ tường minh mà hệ thống phải enforce. Không phải UX — mà là logic. Ví dụ cho một tính năng mã giảm giá:

• User chỉ được apply 1 mã/đơn hàng. Nếu đã apply mã A và thử nhập mã B, hệ thống hỏi xác nhận thay thế.
• Mã giảm giá theo % áp dụng trước mã giảm giá cố định (nếu có cả 2 trong cùng campaign).
• Nếu đơn hàng bị hủy sau khi đã dùng mã, mã được hoàn lại vào tài khoản — trừ mã single-use.
• Mã không áp dụng cho sản phẩm đang Flash Sale.

Nếu bạn không viết những rules này ra, Dev sẽ tự quyết — và thường sẽ quyết theo cách hợp lý nhất với họ, không phải với business.

State Machine mô tả data tồn tại ở những trạng thái nào và điều kiện để chuyển giữa các trạng thái. Ví dụ cho một đơn hàng:

Mỗi mũi tên là một câu hỏi bạn cần trả lời: Ai trigger transition này? Hệ thống nào? Event gì? Nếu không có state machine, Dev thường implement happy path và bỏ sót các nhánh failure.

Data Dependencies — tính năng này cần gọi hoặc nhận data từ đâu? Mức độ chi tiết cần thiết ở giai đoạn PRD:

Câu hỏi quan trọng: Nếu dependency này unavailable, feature có bị block hoàn toàn không? Câu trả lời sẽ quyết định cách Dev thiết kế fallback.

4. The "What-If" — Rủi Ro & Edge Cases

Dev thường implement rất tốt Happy Path. Hệ thống sập là do Edge Cases — thứ không ai nghĩ đến lúc 10 giờ sáng trong phòng họp sáng sủa.

Thay vì chỉ liệt kê edge cases, hãy dùng framework PEUF để tự tìm ra chúng:

• P — Permission: Ai được làm gì? User chưa đăng nhập thì sao? User bị banned có access không? Admin có bypass được rule không?
• E — Empty/Extreme: Điều gì xảy ra khi data trống, quá lớn, hoặc sai định dạng? Giỏ hàng 0 sản phẩm? Tên người dùng 500 ký tự? Số âm trong trường số lượng?
• U — Unavailability: Service bên thứ 3 timeout thì sao? User mất mạng giữa chừng? Server restart lúc đang xử lý? (Đặc biệt quan trọng với payment và data mutation)
• F — Fraud/Abuse: User có thể lợi dụng flow này không? Spam nút submit? Race condition khi 2 người cùng đặt hàng với 1 item cuối cùng? Nhập script vào text field?

Áp dụng vào ví dụ mã giảm giá:

• Permission: Guest user có apply mã không? Nếu có, mã có được giữ khi họ đăng nhập sau đó không?
• Empty/Extreme: Mã trống, khoảng trắng thừa, mã chứa ký tự đặc biệt — reject thế nào, error message là gì?
• Unavailability: Promotion Service timeout lúc validate mã — hệ thống block checkout hay cho phép qua không giảm giá?
• Fraud/Abuse: User tạo 10 tài khoản để dùng 10 mã single-use — detection mechanism ở đâu? Có phải PM xác nhận đây là problem cần handle trong scope này không?

Không phải mọi edge case đều cần xử lý trong scope hiện tại — nhưng mọi edge case đều cần được quyết định có xử lý hay không, và ghi lại lý do.

Khung Quyết Định: Chọn Định Dạng Theo Bối Cảnh

Không có format nào đúng cho mọi tình huống. Dùng 2 trục để quyết định:

• Trục Y — Complexity & Risk: Feature đơn giản (CRUD cơ bản) vs. phức tạp (multi-system, financial transaction, real-time).
• Trục X — Team Shared Context: Team đã làm việc cùng nhau lâu, hiểu domain vs. team mới, cross-functional, outsource.

Modular PRD (High complexity + High shared context) Team senior đã làm cùng nhau nhiều quý. Không cần giải thích "tại sao" dài dòng — focus vào Tech Specs, Edge Cases, và Data Contracts. Bỏ qua phần UI fluff mà ai cũng đã biết. Ví dụ: Tính năng Real-time Inventory Sync cho team infra đã build 3 tính năng tương tự trước đó.

Comprehensive SRS (High complexity + Low shared context) Team mới, outsource, hoặc cross-functional với nhiều dependency. Cần tài liệu nặng và chặt: state machines đầy đủ, cross-system dependency map, acceptance criteria có thể audit. Đây là format tốn thời gian nhất nhưng giảm rủi ro nhất khi misalignment cost cao. Ví dụ: Module thanh toán đa cổng giao cho vendor phát triển.

1-Pager / PRFAQ (Low complexity + High shared context) Feature đơn giản, team hiểu context. Tập trung vào "Why" và Success Metrics — để engineering tự lo phần "How". Amazon PRFAQ là dạng này: viết backward từ press release, không phải forward từ spec. Ví dụ: Thêm nút "Mua lại" vào trang lịch sử đơn hàng cho team đã làm order flow này từ đầu.

Standard Feature Brief (Low complexity + Low shared context) Feature đơn giản nhưng team chưa quen nhau. Cần user stories rõ ràng, UI flows tường minh, AC đơn giản — đủ để ai cũng bắt đầu được mà không cần hỏi thêm. Ví dụ: Form cập nhật thông tin cá nhân cho team mới onboard vào dự án.

Lời Kết

Một bản PRD xuất sắc không được đo bằng số trang hay độ đẹp của template. Nó được đo bằng một câu hỏi duy nhất: Dev có thể tự tin code mà không cần hỏi lại bạn thêm một câu nào không?

Format chỉ là phương tiện. Thứ thực sự tạo ra sự khác biệt là tư duy đặt câu hỏi — biết cái gì cần làm rõ, cái gì có thể bỏ qua, và cái gì sẽ gây ra bug lúc 2 giờ sáng nếu bạn không viết ra hôm nay.

Framework PEUF và 4 trụ cột không phải là một checklist mới để điền. Chúng là lăng kính để đọc vị rủi ro của từng dự án — và quyết định đâu là nơi cần dành thêm 30 phút suy nghĩ trước khi team bắt đầu sprint.

Bài Toán "Chấm Xanh" Của Slack: Cơn Ác Mộng Kiến Trúc Thời Gian Thực

Việc hiển thị trạng thái online tưởng chừng cơ bản nhưng lại là bài toán hạ tầng khổng lồ ở quy mô lớn. Phân tích cách Slack cấu trúc lại mô hình Pub/Sub để cân bằng giữa độ chính xác realtime và chi phí máy chủ.