Bạn sẽ học gì
Bạn sẽ học PRD là gì và cấu trúc cơ bản của nó. Đây là tài liệu quan trọng nhất của Product Manager, giúp bạn truyền đạt ý tưởng sản phẩm một cách rõ ràng, ngay cả khi bạn không có nền tảng kỹ thuật.
Khái niệm
PRD (Product Requirements Document) là tài liệu mô tả chi tiết một sản phẩm hoặc tính năng mới: nó giải quyết vấn đề gì, cho ai, và cần hoạt động như thế nào. Giống như bản thiết kế cho một ngôi nhà, PRD giúp cả đội (kỹ sư, thiết kế, kinh doanh) hiểu cùng một hướng đi.
Liên hệ dễ hiểu
Hãy tưởng tượng bạn muốn mở một quán cà phê. Bạn sẽ viết một bản kế hoạch nhỏ: quán phục vụ ai, thực đơn gồm những gì, không gian ra sao. PRD cũng vậy, nó là kế hoạch cho sản phẩm của bạn.
Ví dụ thực tế
Bạn là PM tại một ứng dụng giao đồ ăn. Bạn muốn thêm tính năng 'Đặt lịch trước' (cho phép người dùng đặt món vào giờ cụ thể trong tương lai). PRD sẽ ghi rõ: tính năng này giúp người dùng đặt trước bữa trưa cho ngày mai; yêu cầu người dùng chọn giờ giao; hệ thống phải gửi thông báo nhắc nhở; v.v.
Sơ đồ
graph TD
A[Tại sao cần tính năng?] --> B[Đối tượng người dùng]
B --> C[Yêu cầu chức năng]
C --> D[Yêu cầu phi chức năng]
D --> E[Mô tả chi tiết]
E --> F[Tiêu chí thành công]Thực hành ngay
Mở một file văn bản mới, viết 3-5 dòng về một ý tưởng sản phẩm nhỏ (ví dụ: tính năng 'Nhắc uống nước' trong app sức khỏe). Gồm: (1) vấn đề cần giải quyết, (2) ai sẽ dùng, (3) cách hoạt động cơ bản. Đừng lo lắng về độ hoàn hảo.
Tóm tắt
- PRD là tài liệu mô tả chi tiết sản phẩm.
- Cấu trúc cơ bản: vấn đề, đối tượng, yêu cầu, mô tả, tiêu chí thành công.
- Giúp cả đội hiểu cùng một hướng.
- Thuật ngữ mới: PRD (Product Requirements Document - Tài liệu yêu cầu sản phẩm).
Cấu trúc một PRD — từng phần và vì sao nó tồn tại
Đây là bộ khung dùng được ngay. Không phải mọi PRD đều cần đủ tám phần, nhưng phần 1, 2, 5 và 7 thì gần như luôn cần.
| # | Phần | Trả lời câu | Bỏ qua thì |
|---|---|---|---|
| 1 | Vấn đề | Ai đang gặp khó khăn gì? | Đội xây giải pháp cho một vấn đề không ai có |
| 2 | Mục tiêu và cách đo | Thành công trông như thế nào? | Không ai biết khi nào thì xong, và có đáng làm không |
| 3 | Người dùng | Ai sẽ dùng, trong tình huống nào? | Thiết kế cho một người dùng tưởng tượng |
| 4 | Bối cảnh hiện tại | Hôm nay họ xử lý ra sao? | Bỏ sót các ca ngoại lệ thật |
| 5 | Phạm vi | Làm gì, và KHÔNG làm gì? | Phạm vi phình ra, tranh cãi lúc nghiệm thu |
| 6 | Luồng và màn hình | Người dùng đi qua những bước nào? | Thiếu trạng thái rỗng, đang tải, lỗi |
| 7 | Điều kiện xác nhận | Làm sao biết là đã đúng? | Cãi nhau về nghĩa của "xong" |
| 8 | Câu hỏi chưa có đáp án | Còn gì chưa biết? | Giả định được coi là sự thật |
Phần quan trọng nhất và hay bị bỏ nhất
Mục "KHÔNG làm" (phần 5). Một dòng như "Lần này chưa xử lý đơn hàng quốc tế" tiết kiệm nhiều tranh luận hơn bất kỳ dòng nào khác trong tài liệu. Nó cũng là cách bạn bảo vệ đội khỏi việc phạm vi phình ra trong lúc làm.
Mục "câu hỏi chưa có đáp án" (phần 8). Người mới thường tránh mục này vì sợ trông như chưa chuẩn bị kỹ. Thực tế ngược lại: tài liệu không có mục này đọc như thể mọi thứ đã rõ, nên không ai dám nêu nghi ngờ — và những nghi ngờ đó sẽ xuất hiện muộn hơn, đắt hơn.
Thứ tự viết khác thứ tự đọc
Người đọc đọc từ phần 1. Nhưng người viết nên viết theo thứ tự khác:
- Viết phần 4 (bối cảnh hiện tại) trước. Nó buộc bạn đi tìm hiểu thay vì ngồi suy luận.
- Rồi phần 1 (vấn đề). Sau khi hiểu hiện trạng, vấn đề thường khác với điều bạn nghĩ lúc đầu.
- Rồi phần 2 (mục tiêu) và phần 5 (phạm vi).
- Phần 6, 7 cuối cùng, vì chúng là hệ quả của những phần trên.
Độ dài
Với một tính năng thông thường: một tới ba trang. Dài hơn thì hãy hỏi phần nào có thể cắt.
Một PRD 15 trang gần như chắc chắn không được đọc hết, nghĩa là những phần quan trọng trong đó cũng không được đọc. Chi tiết kỹ thuật sâu thuộc về tài liệu riêng, không thuộc PRD.
Làm ngay
Lấy một tính năng nhỏ đội bạn sắp làm. Viết PRD chỉ với bốn phần bắt buộc: vấn đề, mục tiêu và cách đo, phạm vi (gồm cả phần không làm), điều kiện xác nhận. Một trang là đủ. Rồi gửi cho một lập trình viên và hỏi họ còn thiếu gì. <!--/les-append-->