Mẫu Tài Liệu Yêu Cầu Sản Phẩm PRD (+ Ví Dụ Thực Tế Đầy Đủ Bạn Có Thể Sao Chép)

Mẫu Tài Liệu Yêu Cầu Sản Phẩm PRD (+ Ví Dụ Thực Tế Đầy Đủ Bạn Có Thể Sao Chép)

Cập nhật lần cuối: 28/07/2026.

Hầu hết các trang mẫu tài liệu yêu cầu sản phẩm chỉ đưa cho bạn một biểu mẫu trống. Mẫu của Atlassian là bốn mục hướng dẫn bao quanh một bảng chỉ số thành công còn để trống. Mẫu của Product School có chữ "(with Example)" ngay trên tiêu đề nhưng lại không hề có ví dụ nào. Khối markdown 12 mục bên dưới chính là toàn bộ mẫu, không cần đăng ký, sao chép dán được ngay. Mục 4 sau đó điền đầy đủ cả 12 mục ấy cho một dự án thực tế hoàn chỉnh: một cổng thông tin hóa đơn cho khách hàng, đọc file PDF bằng LLM và chuyển những trường hợp còn nghi ngờ cho con người xử lý. Sao chép bản trống. Đọc bản đã điền. Rồi viết bản của riêng bạn.

Những Điểm Chính

• Một PRD trả lời câu hỏi xây cái gì và tại sao; tài liệu thiết kế kỹ thuật trả lời câu hỏi xây như thế nào.
• 12 mục này phù hợp với mọi quy mô dự án. Bản one-pager chỉ là cùng một mẫu nhưng ít dòng hơn.
• Non-goals (những thứ không làm) phải được viết ra rõ ràng. Một AI coding agent không thể tự suy luận phạm vi từ những gì bị bỏ sót.
• Acceptance criteria (tiêu chí nghiệm thu) phải kiểm tra được bằng máy: "p95 dưới 400ms", chứ không phải "nhanh".

Nên Dùng Dạng PRD Nào?

Chọn dạng PRD dựa trên ai sẽ đọc tài liệu, không phải dựa trên độ lớn cảm tính của sản phẩm. Một tính năng đơn lẻ giao cho kỹ sư nội bộ chỉ cần bản one-pager. Một dự án giao cho đội ngoài cần bản PRD 12 mục đầy đủ, vì acceptance criteria lúc này còn đóng vai trò làm cổng phê duyệt (sign-off gate). Một bản đặc tả giao cho AI coding agent cũng cần đúng 12 mục ấy nhưng cắt lát theo từng giai đoạn.

Mẫu tài liệu yêu cầu sản phẩm một trang mà mọi người vẫn hay tìm không phải là một dạng tài liệu riêng biệt. Bản one-pager nổi tiếng của Lenny Rachitsky, được đăng kèm ví dụ thực tế trong bản tin của anh ấy, thực chất chính là bộ khung ấy nhưng đã bỏ hết phần thủ tục rườm rà. One-pager không phải là một tài liệu khác. Nó vẫn là 12 mục đó, chỉ là các dòng trống đã bị xóa đi.

Các đội Agile cũng hay hỏi câu này, thường được diễn đạt theo kiểu liệu một PRD có "sống sót" khi va chạm với thực tế backlog hay không. Câu trả lời là có, dưới dạng one-pager: PRD giữ phần lý do và ranh giới, còn ticket giữ phần công việc cụ thể.

Mẫu PRD (Markdown, Sao Chép Dán Ngay)

Đây là toàn bộ mẫu dưới dạng markdown, không cần đăng ký, không đòi email. Dán nó vào Notion, Confluence, Google Docs, Linear, Word, hoặc commit lên GitHub với tên PRD.md để nó được đánh phiên bản song song với code. Người ta hỏi mẫu này ở chín định dạng khác nhau, nhưng markdown là định dạng duy nhất sống sót khi dán vào tất cả các công cụ đó, và cũng là định dạng duy nhất mà một AI coding agent đọc được sạch sẽ.

# PRD: [Tên sản phẩm hoặc tính năng]

## 1. Header
- Owner (product):
- Engineering lead:
- Design lead:
- Status: Draft | In review | Approved | Shipped
- Last updated:
- Change history: date / author / what changed

## 2. Problem statement
One paragraph. Who hurts, how often, what it costs today. No solution language.

## 3. Goals & success metrics
| Goal | Metric | Baseline | Target | Measured by | Date |
|---|---|---|---|---|---|

## 4. Non-goals
Stated positively: "This phase does not include X."

## 5. Users & personas
Who uses it, what they already know, which device, how often.

## 6. User stories & acceptance criteria
As a [persona], I want [action], so that [outcome].
- Given [context], when [event], then [observable result].

## 7. Functional requirements
Numbered. One requirement per line. Testable. No sentence containing "and".

## 8. Non-functional requirements
Performance / security & tenancy / data residency & retention / accessibility / availability.

## 9. Dependencies & integrations
External systems, APIs, credentials, who owns access, lead time.

## 10. Milestones & phasing
| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|

## 11. Open questions & risks
| Question or risk | Owner | Needed by | Impact if unanswered |
|---|---|---|---|

## 12. Appendix & links
Designs, research, competitor notes, prior tickets, contracts.

Mười hai mục, theo đúng thứ tự: thông tin chung (header), phát biểu vấn đề, mục tiêu và chỉ số thành công, non-goals, người dùng và persona, user stories kèm acceptance criteria, yêu cầu chức năng, yêu cầu phi chức năng, phụ thuộc và tích hợp, mốc thời gian và các giai đoạn, câu hỏi mở và rủi ro, phụ lục.

PRD Nên Bao Gồm Những Gì? 12 Mục, Và Phiên Bản "Yếu" Của Từng Mục

Một tài liệu yêu cầu sản phẩm cần có phát biểu vấn đề, mục tiêu có thể đo lường, non-goals rõ ràng, persona, user stories kèm acceptance criteria, yêu cầu chức năng và phi chức năng, các phụ thuộc, mốc thời gian, câu hỏi mở kèm người phụ trách, và lịch sử thay đổi. Mọi thứ khác thuộc về phụ lục. Bài kiểm tra cho từng dòng là tiêu chuẩn mà ISO/IEC/IEEE 29148:2018 áp dụng cho yêu cầu nói chung: kiểm chứng được, không mập mờ, chỉ mang một ý duy nhất.

Hầu hết các PRD trượt bài kiểm tra này ở đúng ba chỗ.

Có hai mục xứng đáng được đầu tư nhiều hơn mức thường thấy.

Yêu cầu phi chức năng là nơi phạm vi âm thầm phình gấp đôi. Hiệu năng, cô lập tenant, nơi lưu trữ dữ liệu, thời hạn lưu trữ, khả năng tiếp cận, độ sẵn sàng: mỗi thứ này là một quyết định kỹ thuật kèm chi phí riêng, và không cái nào xuất hiện trong user story cả. Hãy đặt dòng bảo mật ở đây thay vì nói qua loa cho xong, và viết nó theo đúng cách bạn muốn nó được kiểm tra, dùng thứ gì đó như checklist bảo mật trước khi ra mắt của chúng tôi làm danh sách nguồn. Nếu dự án có thành phần AI, các yêu cầu sẵn sàng cho production cũng nên nằm ở đây, chứ không phải để dồn vào một giai đoạn "hardening" sau này mà chẳng bao giờ được lên lịch: checklist từ PoC lên production là bản chúng tôi vẫn dùng.

Câu hỏi mở cần ba cột, không phải một. Câu hỏi, người phụ trách, ngày cần trả lời. Một câu hỏi không có người phụ trách là một quyết định mà chẳng ai đang thực sự đưa ra, và nó sẽ trồi lên thành một yêu cầu thay đổi vào tuần thứ sáu. Đáng nói thêm: PRD là thứ bạn viết ra sau khi đã quyết định tự xây thay vì mua sẵn. Nếu phát biểu vấn đề vẫn đọc như một danh sách mua sắm tính năng, thì quyết định mua-hay-xây thực ra chưa được đưa ra thật sự.

Ví Dụ Thực Tế: Một PRD Cổng Thông Tin Hóa Đơn, Đã Điền Đầy Đủ

Đây là một ví dụ thực tế hoàn chỉnh, cả 12 mục đã được điền. Dự án: một cổng thông tin hóa đơn cho khách hàng là một công ty logistics tầm trung. Khách hàng tải lên hóa đơn PDF, một LLM trích xuất các dòng hàng hóa, hệ thống đánh dấu những chỗ lệch so với bản ghi đơn hàng, và bất cứ điều gì hệ thống không chắc chắn sẽ được chuyển vào hàng đợi để con người xét duyệt. Stack: Next.js, Supabase/Postgres, một bước trích xuất bằng LLM. Sao chép, in ra, xuất PDF, tùy bạn cần gì.

# PRD: Client Invoice Portal, Phase 1

## 1. Header
- Owner (product): Ops director, client side
- Engineering lead: Delivery lead, Techsy
- Design lead: Product designer, Techsy
- Status: Approved for build
- Last updated: 2026-07-28
- Change history:
  - 2026-07-14 / product / first draft
  - 2026-07-21 / engineering / added confidence-threshold rule to 6.2
  - 2026-07-28 / product / moved ERP write-back to non-goals

## 2. Problem statement
Ops staff receive customer invoices as emailed PDFs and re-key them into the
order system by hand. Volume runs past 300 invoices a week, average handling
time is about 6 minutes each, and roughly 4% carry a keying error caught only
at month-end reconciliation. Every correction costs a second pass and a call.

## 3. Goals & success metrics
| Goal | Metric | Baseline | Target | Measured by | Date |
|---|---|---|---|---|---|
| Cut manual handling | Avg. handling time | 6 min | under 90 sec | Ops dashboard, weekly median | 2026-11-01 |
| Cut keying errors | Invoices corrected at reconciliation | 4% | under 1% | Finance month-end report | 2026-12-01 |
| Contain review load | Share routed to human review | n/a | under 25% | Portal queue metrics | 2026-11-01 |

## 4. Non-goals
This phase does not support multi-currency invoices, ERP write-back, customer
self-service credit notes, or a mobile app. Extraction covers PDF only.
Photographs of paper invoices and scans below 200 DPI are rejected at upload
with a message explaining why.

## 5. Users & personas
- Ops clerk (primary, 6 people): works the exception queue all day, deep
  domain knowledge, desktop only.
- Customer AP contact (external, ~140 accounts): uploads invoices, low
  tolerance for account-setup friction.
- Finance manager (secondary): pulls the month-end report, needs a per-invoice
  audit trail.

## 6. User stories & acceptance criteria
6.1 As a customer AP contact, I want to upload an invoice PDF, so that I don't
have to email it and wait.
- Given a PDF under 20 MB at 200 DPI or better, when I upload it, then the
  portal returns a reference number within 5 seconds and shows "Processing".

6.2 As an ops clerk, I want low-confidence extractions held back, so that
nothing wrong is auto-approved.
- Given a parsed invoice, when extraction confidence for any line item is
  below 0.85, then the invoice routes to the review queue and is never
  auto-approved.

6.3 As an ops clerk, I want to see the mismatch in one place, so that I can
resolve it without opening the order system.
- Given an invoice matched to an order, when any line quantity or unit price
  differs from the order record, then the portal shows both values side by
  side and flags the delta.

6.4 As a finance manager, I want to filter invoices, so that I can close the
month.
- Given the invoice list, when I filter by vendor, date range and status, then
  results return in under 400ms at p95 and the empty state offers "Clear
  filters".

## 7. Functional requirements
1. Upload accepts PDF only, 20 MB maximum, one file per submission.
2. Extraction returns vendor, invoice number, date, currency, and line items
   with quantity, unit price and total.
3. Each line item carries a confidence score between 0 and 1.
4. Matching compares the extracted invoice to the open order by PO number.
5. Exceptions enter a queue ordered oldest first, assignable to one clerk.
6. Every state change writes an audit entry with actor, timestamp, prior value.
7. Approved invoices export as a CSV batch for the finance system.

## 8. Non-functional requirements
- Performance: invoice list p95 under 400ms. Extraction completes within 90
  seconds of upload at p95.
- Security & tenancy: per-tenant isolation enforced at the database row level.
  A customer can never read another customer's invoice. Verified by an
  automated test on every release.
- Data residency & retention: documents stored in the EU. Originals retained 7
  years, extraction payloads 90 days.
- Accessibility: queue fully keyboard-operable, WCAG 2.2 AA contrast.
- Availability: 99.5% monthly, support during business hours.

## 9. Dependencies & integrations
- Order records: read-only Postgres replica. Access owned by client IT,
  credentials needed by 2026-08-15.
- LLM extraction provider: contract and data-processing agreement signed
  before build starts.
- Email notifications: existing transactional provider, sender domain verified
  by the client.

## 10. Milestones & phasing
| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|
| P1 | Upload, extraction, confidence routing | 50 real invoices end to end, under 25% queued | 2026-09-19 |
| P2 | Order matching and mismatch view | Mismatch flagged correctly on 20 seeded cases | 2026-10-10 |
| P3 | Audit trail, CSV export, reporting | Finance closes one month in the portal | 2026-11-01 |

## 11. Open questions & risks
| Question or risk | Owner | Needed by | Impact if unanswered |
|---|---|---|---|
| Which PO number is authoritative when an invoice shows two? | Client ops director | 2026-08-08 | Matching logic blocked |
| Do the 12 largest customers send scanned or native PDFs? | Delivery lead | 2026-08-08 | Confidence threshold may be wrong |
| Is 7-year retention confirmed with client counsel? | Client finance manager | 2026-08-22 | Storage design and cost change |
| Extraction cost per invoice at 300/week | Delivery lead | 2026-09-05 | Unit economics unknown |

## 12. Appendix & links
Anonymized sample invoice set (40 files), order-table schema, current
handling-time study, Figma flows for upload and queue, signed statement of work.

Có bốn lựa chọn trong bản trên đáng được nói riêng, vì phiên bản làm cẩu thả của mỗi cái đều tốn tiền thật.

Mục 3, đường mốc gốc (baseline). "6 phút" không phải là chi tiết trang trí. Không có mốc gốc, bạn không thể biết được liệu mọi thứ có hiệu quả hay không, và sáu tháng sau ai đó sẽ tranh cãi về điều này trong một cuộc họp mà chẳng có dữ liệu nào cả. Phiên bản cẩu thả, "cải thiện hiệu suất", khiến dự án không thể kiểm chứng đúng-sai.

Mục 4, non-goal. Việc ghi ngược dữ liệu vào ERP được chuyển sang non-goals vào ngày 2026-07-28, sau khi nó bị mặc nhiên coi là đã có trong một cuộc họp review. Viết nó ra thành non-goal chỉ tốn một dòng nhưng đã tránh được một cuộc tranh cãi về phạm vi.

Mục 6.2, ngưỡng độ tin cậy. Đây là quy tắc mà chính các bản nháp đầu tiên của chúng tôi thường bỏ sót nhất. Bỏ nó đi thì hệ thống sẽ tự động duyệt những hóa đơn lẽ ra phải để con người xem qua, đúng là loại lỗi xóa sạch phần thời gian tiết kiệm được mà bạn đã hứa ở mục 3.

Mục 11, người phụ trách. Mỗi câu hỏi mở đều có tên người và ngày hạn. Cột đó chính là ranh giới giữa một tài liệu thật sự và một danh sách việc cần làm mà chẳng ai nhận trách nhiệm.

PRD cho bạn biết cái gì. Nó không cho bạn biết mất bao lâu hay tốn bao nhiêu, đó là một việc tách riêng: xem định phạm vi cho dự án để biết nửa còn lại. Và một non-goal mà bạn không viết ra chính là một tính năng ai đó sẽ đi xây.

Làm Sao Viết PRD Để Một AI Coding Agent Thực Sự Dựa Vào Đó Mà Xây Được?

Một PRD viết cho AI coding agent phải đánh đổi sự ngắn gọn lấy sự tường minh. Agent không có ngữ cảnh "nghe lỏm hành lang", không có lịch sử chung, và không có bản năng để hiểu rõ điều bạn hiển nhiên không có ý đó. Bốn quy tắc bao quát phần lớn sự khác biệt, và chúng đến từ việc quan sát các bản đặc tả thành công và thất bại qua chính các dự án dùng agent của chúng tôi.

1. Phát biểu non-goals theo hướng khẳng định. Con người tự suy luận phạm vi từ những gì bị bỏ sót. Agent thì không. "Không thêm xác thực đăng nhập trong giai đoạn này" phải là một câu viết hẳn ra trong tài liệu, nếu không thì chức năng xác thực sẽ bị xây, được test, và giao ngược lại cho bạn.

2. Chia công việc theo từng giai đoạn vừa sức. Một tài liệu độc khối 40 trang sẽ tạo ra một pull request tự tin, lan man và chỉ đúng một nửa. Hãy cắt PRD thành các đợt mà agent hoàn thành trọn vẹn trong một lượt chạy, mỗi đợt có tiêu chí kết thúc riêng.

3. Biến acceptance criteria thành thứ kiểm tra được bằng máy. "Nhanh" không phải là một yêu cầu, đó chỉ là một cảm giác. "p95 dưới 400ms trên endpoint danh sách hóa đơn" mới là một bài test mà agent có thể viết trước cả khi nó viết tính năng.

4. Đặt đường dẫn file và ràng buộc stack ngay trong tài liệu, không phải trong chat. Ngữ cảnh chat sẽ bốc hơi giữa các phiên làm việc. Bản đặc tả thì không. Đây cũng là lý do vì sao plan mode của Claude Code quan trọng: nó đọc file của bạn và đề xuất một kế hoạch mà không chỉnh sửa gì cho đến khi bạn phê duyệt, và bước phê duyệt đó hữu ích hơn hẳn khi kế hoạch được đối chiếu với một bản đặc tả viết sẵn thay vì trí nhớ của bạn về những gì bạn đã yêu cầu.

Đây là cổng thông tin hóa đơn, được cắt thành một giai đoạn mà agent có thể thực hiện trọn vẹn trong một lượt chạy.

# Build task: Invoice upload and extraction (Phase 1 of 3)

## Stack constraints (do not substitute)
Next.js 15 App Router, TypeScript, Supabase Postgres with row-level security,
Vercel deploy. No new dependencies without asking first.

## Files you may create or edit
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Do not touch
- lib/auth/*  (auth ships in Phase 2; do not add sign-in flows now)
- Anything under app/(marketing)/
- The existing orders schema. Read it. Never migrate it.

## Acceptance criteria (write these as tests first)
1. POST /api/invoices rejects non-PDF with 415 and files over 20 MB with 413.
2. A line item with confidence < 0.85 sets invoice.status = 'review',
   never 'approved'.
3. Every insert writes an audit row with actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= returns under 400ms on a
   10,000-row seed.

## Out of scope for this pass
Order matching, mismatch UI, CSV export, email notifications.

Có ba thứ thay đổi so với bản dành cho con người: đường dẫn file xuất hiện, danh sách không được đụng vào xuất hiện, và acceptance criteria trở thành các khẳng định kiểm tra được thay vì những câu văn mô tả. Agent nào bạn giao việc thì cũng không quan trọng bằng người ta vẫn tưởng, dù bảng so sánh các coding agent vẫn đáng đọc trước khi bạn quyết định. Hãy giữ yêu cầu và quy tắc dự án ở hai file riêng biệt: Cursor rules và CLAUDE.md chứa các quy ước và công cụ, PRD chứa cái cần xây. Nếu bạn muốn AI hỗ trợ ngay từ khâu tạo ra phạm vi thay vì chỉ tiếp nhận nó, đó là một quy trình khác. Còn với bước trích xuất, lựa chọn model và vòng lặp đánh giá là một mảng công việc tích hợp AI riêng.

Điều Gì Thay Đổi Khi PRD Được Giao Cho Đội Ngoài

Khi PRD được giao cho agency hoặc nhà thầu ngoài, nó không còn là tài liệu để căn chỉnh nội bộ nữa mà trở thành ngôn ngữ hợp đồng. Sự mập mờ mà một đội nội bộ có thể giải quyết bằng hai phút trò chuyện giờ đây trở thành một yêu cầu thay đổi kèm mức giá. Báo cáo Pulse of the Profession của PMI cho thấy 47% dự án thất bại vì quản lý yêu cầu không chính xác. Đó chính là toàn bộ lý do tài liệu này tồn tại.

Có ba mục mang trọng lượng lớn hơn hẳn trong bối cảnh đó. Acceptance criteria trở thành cổng phê duyệt, nên chúng cần quan sát được bởi một người không phải kỹ sư. Câu hỏi mở cần một người phụ trách được nêu tên ở phía khách hàng, vì nhà cung cấp không thể tự trả lời và sẽ xây dựng vòng quanh khoảng trống đó. Và lịch sử thay đổi không còn là chuyện hành chính nữa: đó là bản ghi ai đã đồng ý gì vào lúc nào, thứ đầu tiên mà bất kỳ ai cũng lôi ra khi có tranh chấp.

Câu mà chúng tôi từng chứng kiến đi sai đường không chỉ một lần là một biến thể nào đó của "người dùng có thể xuất dữ liệu của họ". Không ai viết rõ định dạng nào. Phiên bản tốn kém của điều đó, với chúng tôi, là khi bản xuất ra thành file CSV trong khi khách hàng thực ra muốn một tập hóa đơn PDF được định dạng sẵn có logo thương hiệu của họ, và làm lại việc đó ngốn khoảng một tuần công sức kỹ thuật mà chẳng ai lên kế hoạch trước. Đọc lại một cách trung thực thì lỗi nằm ở tài liệu, không phải ở khâu triển khai. Một acceptance criterion đã có thể phát hiện ra điều đó trong năm phút: given một yêu cầu xuất dữ liệu, when file được tạo ra, then nó phải là PDF khớp với bố cục đã cung cấp. Một dòng non-goals cũng có thể bắt được điều đó, từ hướng ngược lại. Vậy nên giờ đây đó là một quy tắc trong quá trình khám phá yêu cầu của chúng tôi: bất kỳ yêu cầu nào treo lơ lửng vào một danh từ như "xuất", "báo cáo" hay "thông báo" đều phải gắn kèm định dạng, điều kiện kích hoạt và một ví dụ thực tế trước khi statement of work được ký.

Đó cũng chính là phần lớn những gì cách chúng tôi triển khai các dự án ứng dụng web thực sự là: biến nửa mơ hồ trong bản đặc tả của khách hàng thành những dòng kiểm tra được trước khi ai đó bắt tay viết code.

r/ProductManagement Thực Sự Nói Gì Về Các Mẫu PRD

Tìm product requirements document template reddit và bạn sẽ thấy cùng một lời phàn nàn lặp đi lặp lại trên r/ProductManagement: mẫu bị phình to vô ích. PRD chẳng ai đọc. Các mục được điền chỉ vì mẫu có sẵn tiêu đề, không phải vì ai đó thực sự cần nội dung ấy. Những tài liệu lỗi thời ngay ngày sau khi khởi động và âm thầm bị thay thế bằng một luồng tin nhắn trên Slack. Đó là một lời phê bình công bằng dành cho hầu hết các mẫu, kể cả một số mẫu nằm trong top mười kết quả cho truy vấn này.

Câu trả lời của chúng tôi: xóa mục đi thay vì điền nó cho có. Persona đi trước khi người dùng đã quá rõ ràng. Phụ lục đi sau. Mốc thời gian có thể sống trong công cụ theo dõi thay vì trong tài liệu. Mục duy nhất chúng tôi không bao giờ xóa là non-goals, vì đó là mục duy nhất ngắn lại khi bạn làm việc nhiều hơn, và là mục duy nhất luôn ngăn được cuộc tranh cãi mà nếu không có nó bạn chắc chắn sẽ gặp vào tuần thứ sáu.

Về Tác Giả

Mert Batur Gurbuz, Đồng sáng lập, Techsy.io. Chứng chỉ: Đồng sáng lập Techsy.io, Đại học Birmingham. LinkedIn

Mert Batur Gurbuz là Đồng sáng lập của Techsy.io, nơi đội ngũ xây dựng AI agent, hệ thống tự động hóa và các pipeline voice/SDR cho khách hàng B2B. Anh theo học tại Đại học Birmingham và viết về hệ sinh thái công cụ LLM mà đội ngũ Techsy thực sự dùng trong production.

Câu Hỏi Thường Gặp

Tài liệu yêu cầu sản phẩm (PRD) là gì?

Một tài liệu yêu cầu sản phẩm (PRD) nêu rõ đội ngũ đang xây dựng cái gì và tại sao: vấn đề, mục tiêu cùng chỉ số của chúng, những gì không làm (non-goals), đối tượng phục vụ, và các yêu cầu định nghĩa thế nào là hoàn thành. PRD cố tình không đi vào chi tiết triển khai kỹ thuật, phần đó thuộc về tài liệu thiết kế kỹ thuật do đội kỹ thuật viết sau đó.

Làm sao để viết một tài liệu yêu cầu sản phẩm?

Bắt đầu từ phát biểu vấn đề và tuyệt đối không dùng ngôn ngữ giải pháp trong đó. Thêm các mục tiêu đo lường được kèm mốc gốc và ngày đích, rồi viết non-goals. Điền persona, user stories kèm acceptance criteria dạng Given/When/Then, yêu cầu chức năng và phi chức năng, các phụ thuộc, mốc thời gian, và câu hỏi mở kèm người phụ trách.

PRD nên bao gồm những gì?

Mười hai mục: header kèm lịch sử thay đổi, phát biểu vấn đề, mục tiêu và chỉ số thành công, non-goals, người dùng và persona, user stories kèm acceptance criteria, yêu cầu chức năng, yêu cầu phi chức năng, phụ thuộc và tích hợp, mốc thời gian và các giai đoạn, câu hỏi mở và rủi ro, và một phụ lục. Bất cứ thứ gì không khớp với một trong các mục đó thì có lẽ không phải là một yêu cầu thật sự.

PRD nên dài bao nhiêu?

Một đến hai trang cho một tính năng đơn lẻ, ba đến năm trang cho một giai đoạn sản phẩm, năm đến tám trang khi giao cho đội ngoài xây và acceptance criteria đóng vai trò cổng phê duyệt. Độ dài phụ thuộc vào số lượng quyết định được ghi lại, không phải quy mô sản phẩm. Các mục trống nên bị xóa, không nên bị nhồi cho đầy.

PRD có giống BRD không?

Không. Một tài liệu yêu cầu kinh doanh (BRD) nêu kết quả thương mại mà tổ chức mong muốn cùng các ràng buộc xung quanh nó, thường là trước khi giải pháp được chọn. Một PRD mô tả sản phẩm mang lại kết quả đó: người dùng, hành vi, acceptance criteria, non-goals. Ở các công ty nhỏ hơn, BRD thường chỉ là phần phát biểu vấn đề mà thôi.

Các đội Agile có còn viết PRD không?

Có, thường là dưới dạng one-pager. Backlog giữ phần công việc, nhưng ticket lại rất kém trong việc giữ lại lý do, non-goals, và chỉ số thành công. Những đội bỏ hẳn PRD thường cuối cùng lại phải phát minh lại nó dưới dạng một trang Confluence tên là "context" sau ba sprint kể từ khi dự án bắt đầu.

Có thể viết PRD bằng markdown không?

Markdown là định dạng tốt nhất cho việc này. Nó dán sạch vào Notion, Confluence, Google Docs và Linear, được đánh phiên bản trong Git song song với code dưới tên PRD.md, hiện diff đúng trong một pull request, và là định dạng duy nhất một AI coding agent đọc được mà không mất cấu trúc. Mẫu bên trên là markdown chính vì những lý do đó.

Làm sao để viết PRD cho một AI coding agent?

Hãy tường minh ở những chỗ mà bình thường bạn sẽ viết ngắn gọn. Phát biểu non-goals theo hướng khẳng định, vì agent không thể tự suy luận phạm vi từ những gì bị bỏ sót. Cắt tài liệu thành các giai đoạn hoàn thành được trong một lượt chạy. Viết acceptance criteria dưới dạng các khẳng định kèm con số cụ thể. Nêu tên các file agent được phép sửa và những file không được đụng vào.

Khác biệt giữa PRD và tài liệu thiết kế kỹ thuật là gì?

PRD trả lời câu hỏi cái gì và tại sao: vấn đề, người dùng, hành vi, acceptance criteria, non-goals. Tài liệu thiết kế kỹ thuật trả lời câu hỏi như thế nào: kiến trúc, mô hình dữ liệu, hợp đồng API, các đánh đổi đã cân nhắc. Bộ phận sản phẩm thường sở hữu tài liệu đầu, kỹ thuật sở hữu tài liệu sau, và tài liệu thiết kế nên đọc được như một câu trả lời cho PRD.

Ai sở hữu PRD, sản phẩm, kỹ thuật, hay khách hàng?

Bộ phận sản phẩm sở hữu tài liệu và các quyết định trong đó. Kỹ thuật sở hữu phản hồi về tính khả thi và các yêu cầu phi chức năng. Trong các dự án agency, khách hàng sở hữu phát biểu vấn đề, mục tiêu, và mọi câu hỏi mở liên quan đến chính công việc kinh doanh của họ. Việc chia sẻ quyền sở hữu cho toàn bộ tài liệu thường có nghĩa là chẳng ai thực sự duy trì nó.

Tổng Kết

Có ba điều đáng nhớ. Mẫu chỉ hữu ích khi nó được điền đầy đủ, vậy nên hãy sao chép hình dạng của ví dụ thực tế thay vì bản trống. Non-goals là mục có giá trị cao nhất tính theo từng từ trong tài liệu, và cũng là mục đầu tiên bị người ta bỏ qua. Và acceptance criteria được viết dưới dạng các khẳng định kiểm tra được phục vụ tốt cho cả hai người đọc: một kỹ sư đang ký duyệt bàn giao, và một agent đang viết bài test.

Nếu bạn đang viết một PRD để giao cho đội ngoài và muốn có thêm một cặp mắt nhìn qua trước khi nó trở thành hợp đồng, chúng tôi sẵn lòng đọc và đánh dấu những dòng còn mập mờ. Đó cũng chính là bước rà soát chúng tôi áp dụng cho chính các dự án ứng dụng web của mình.