Tiếng Việt: Providing Product Context

Một PM ở công ty SaaS B2B mở ChatGPT, dán nguyên văn "Viết giúp tôi PRD cho tính năng export báo cáo Excel" — và nhận lại một PRD chung chung, có thể áp dụng cho bất kỳ sản phẩm nào trên đời, không có gì liên quan đến persona thật, đến metric thật, hay ràng buộc kỹ thuật thật của hệ thống công ty đó. Đây không phải lỗi của AI. Đây là lỗi context. AI không thiếu khả năng suy luận — nó thiếu thông tin nền để suy luận đúng hướng. Với một BA/PM/PO, context (bối cảnh) không phải là thứ "có thì tốt", mà là nguyên liệu đầu vào quyết định 80% chất lượng output. Bài này đi sâu vào bốn câu hỏi cốt lõi: nên đưa loại context nào cho AI, cách cấu trúc requirement/user story sao cho AI đọc hiểu tốt, cách xử lý dữ liệu customer feedback thô mà không làm mất sắc thái, và khi nào nên đưa full document thay vì bản tóm tắt.

Những Loại Context Quan Trọng Nhất: Strategy Doc, User Research, Metrics, Competitive Data, Ràng Buộc Kỹ Thuật

Khi PM nói "tôi đã cho AI context rồi", trong thực tế phần lớn chỉ dán một đoạn mô tả tính năng ngắn gọn — đây là context ở mức thấp nhất. Một product context đầy đủ cần đến từ năm nguồn khác nhau, mỗi nguồn trả lời một câu hỏi mà nếu thiếu, AI sẽ tự bịa ra câu trả lời (và thường bịa sai).

Strategy doc / vision doc trả lời câu hỏi "vì sao chúng ta làm cái này, nó phục vụ mục tiêu lớn nào". Nếu công ty bạn có OKR quý, roadmap theo North Star Metric, hay một vision doc trên Confluence/Notion, đây chính là context giúp AI không đề xuất giải pháp lệch hướng chiến lược. Ví dụ: nếu North Star Metric của công ty là "thời gian activate tài khoản mới", một feature request về "thêm dark mode" cần được AI đánh giá đúng mức độ ưu tiên thấp trong bối cảnh đó — chứ không tự nhiên coi nó quan trọng ngang với các initiative liên quan trực tiếp đến activation.

User research findings trả lời câu hỏi "người dùng thật sự gặp vấn đề gì, ở đâu, với ai". Đây gồm báo cáo usability testing, insight (thông tin chuyên sâu) rút ra từ interview, persona doc, hay journey map. Thiếu phần này, AI sẽ generate ra một user story dựa trên "user chung chung" thay vì đúng nhóm khách hàng thật của bạn — ví dụ nhầm giữa nhu cầu của SMB (doanh nghiệp nhỏ) và enterprise, hai nhóm có hành vi hoàn toàn khác nhau.

Product metrics / analytics trả lời câu hỏi "hiện tại con số đang nói gì". Số liệu từ Mixpanel, Amplitude, GA4, hay một dashboard nội bộ — funnel conversion, churn rate, retention curve, NPS (Net Promoter Score) — là bằng chứng định lượng khiến đề xuất của AI bớt mang tính "đoán mò" và neo vào thực tế vận hành sản phẩm.

Competitive data (dữ liệu cạnh tranh) trả lời câu hỏi "thị trường đang làm gì, chúng ta đứng ở đâu so với đối thủ". Một bản competitive teardown, deck phân tích đối thủ, hay đơn giản là screenshot tính năng của Notion/Slack/HubSpot cho một use case tương tự — giúp AI không đề xuất lại thứ thị trường đã làm rồi, hoặc chỉ ra khoảng trống (gap) thật sự đáng làm.

Ràng buộc kỹ thuật (technical constraints) trả lời câu hỏi "cái gì khả thi, cái gì không". Đây là phần PM hay bỏ quên nhất khi làm việc với AI — không đưa thông tin về kiến trúc hệ thống, giới hạn của third-party API đang dùng, hay technical debt hiện có, khiến AI đề xuất giải pháp "đẹp trên giấy" nhưng dev đọc vào là lắc đầu ngay vì không tương thích với hệ thống hiện tại.

Các Bước Thực Hành Cụ Thể

1. Tạo một thư mục "context nguồn" cố định trong Notion/Confluence cho mỗi sản phẩm/squad, gồm 5 mục: Strategy, Research, Metrics, Competitive, Technical Constraints — cập nhật định kỳ mỗi quý, không phải tạo lại từ đầu mỗi lần cần dùng AI.
2. Trước khi viết prompt cho bất kỳ tính năng nào, tự hỏi: "AI có biết feature này phục vụ OKR nào không? Có biết persona nào đang đau ở đâu không? Có biết con số hiện tại không? Có biết đối thủ đã làm gì không? Có biết ràng buộc kỹ thuật không?" — thiếu câu nào, bổ sung câu đó trước khi prompt.
3. Với các tài liệu quá dài (vision doc 20 trang, báo cáo research 15 trang), trích ra đoạn liên quan trực tiếp đến task hiện tại thay vì dán cả file — vừa tiết kiệm context window, vừa giảm nhiễu (xem thêm phần "Full Document vs. Tóm Tắt" ở dưới).
4. Lưu một "context snippet" chuẩn cho từng sản phẩm (2-3 đoạn ngắn: mục tiêu chiến lược hiện tại, top 3 pain point từ research, 2-3 con số metric quan trọng nhất) — dùng lại snippet này ở đầu mọi prompt liên quan đến sản phẩm đó, giống như một "system prompt" cá nhân của PM.

Ví Dụ Prompt

Bạn là Senior Product Manager tư vấn cho tôi về một tính năng mới.

BỐI CẢNH CHIẾN LƯỢC:
North Star Metric quý này: Time-to-first-value (thời gian từ lúc đăng ký
đến khi user tạo được báo cáo đầu tiên), hiện tại trung bình 14 phút,
mục tiêu quý là giảm xuống 5 phút.

BỐI CẢNH USER RESEARCH:
Từ 12 buổi interview với user SMB (5-20 nhân viên) tháng trước, top pain
point: (1) không hiểu cách kết nối data source, (2) bị choáng ngợp bởi
quá nhiều tùy chọn template báo cáo ngay từ màn hình đầu tiên.

BỐI CẢNH METRICS:
Funnel hiện tại: 100% đăng ký -> 62% kết nối data source -> 38% tạo
report đầu tiên. Điểm rơi lớn nhất là bước kết nối data source.

BỐI CẢNH ĐỐI THỦ:
Đối thủ X có onboarding wizard 3 bước với template mặc định theo ngành,
không cho user chọn tự do ngay từ đầu.

RÀNG BUỘC KỸ THUẬT:
Hệ thống hiện chỉ hỗ trợ kết nối qua OAuth cho 4 data source (Google
Sheets, Salesforce, HubSpot, Shopify), chưa có generic CSV upload flow
ổn định.

YÊU CẦU:
Dựa trên toàn bộ context trên, đề xuất 3 hướng cải thiện onboarding flow
để tăng % user tạo được report đầu tiên, sắp xếp theo mức độ effort
thực hiện (thấp/trung/cao) và mức độ liên quan trực tiếp đến pain point
đã tìm thấy từ research. Chỉ đề xuất giải pháp khả thi trong ràng buộc
kỹ thuật đã nêu.

Mẹo: Đừng cố đưa cả 5 loại context vào mọi prompt. Với task nhỏ (viết 1 user story đơn lẻ), 2 loại context liên quan trực tiếp là đủ; dồn cả 5 loại vào một prompt ngắn gọn thường làm loãng trọng tâm và khiến AI trả lời lan man thay vì sắc bén đúng vấn đề.

Cách Cấu Trúc Requirement Và User Story Làm Context Cho AI

Một requirement doc viết cho con người đọc (rải rác, nhiều đoạn văn dài, thông tin quan trọng chôn giữa các câu chuyện bối cảnh) khác hẳn một requirement doc được cấu trúc để AI xử lý tốt. AI đọc structured markdown (định dạng có cấu trúc rõ ràng) hiệu quả hơn nhiều so với văn xuôi tự do, vì nó có thể map (ánh xạ) chính xác field nào ứng với ý nghĩa nào, thay vì phải suy luận ngữ nghĩa từ câu văn mơ hồ.

Nguyên tắc cốt lõi: đặt tên field (trường thông tin) nhất quán, dùng đúng một tên gọi cho một khái niệm xuyên suốt toàn bộ tài liệu và xuyên suốt các tài liệu khác nhau trong cùng dự án. Nếu bạn gọi là "Acceptance Criteria" ở story này nhưng lại gọi "Definition of Done" ở story khác cho cùng một khái niệm, AI (và cả con người) dễ hiểu nhầm chúng là hai thứ khác nhau.

Một user story chuẩn để làm AI context nên có cấu trúc:

## User Story: [Tên ngắn gọn]

**As a** [persona cụ thể, không viết "user" chung chung]
**I want to** [hành động cụ thể]
**So that** [giá trị/kết quả mong muốn]

### Context bổ sung
- Persona: [link tới persona doc nếu có]
- Liên quan OKR: [tên OKR/metric]
- Độ ưu tiên: [P0/P1/P2 + lý do ngắn]

### Acceptance Criteria
- [ ] AC1: Given [điều kiện], when [hành động], then [kết quả]
- [ ] AC2: Given [điều kiện], when [hành động], then [kết quả]
- [ ] AC3 (edge case): Given [điều kiện biên], when [hành động], then [kết quả]

### Ràng buộc kỹ thuật đã biết
- [Liệt kê giới hạn API, hệ thống, performance nếu có]

### Ngoài phạm vi (Out of scope)
- [Liệt kê rõ những gì KHÔNG làm trong story này]

Định dạng Given/When/Then (Gherkin-style) cho acceptance criteria đặc biệt hiệu quả khi làm context cho AI, vì nó buộc bạn — và AI khi generate thêm case — phải nghĩ theo cấu trúc điều kiện/hành động/kết quả rõ ràng, thay vì liệt kê mô tả mơ hồ kiểu "hệ thống phải hoạt động đúng".

Mục "Ngoài phạm vi" thường bị bỏ qua nhưng lại cực kỳ quan trọng khi làm context cho AI — nếu không nói rõ AI sẽ tự suy luận phạm vi dựa trên độ rộng của câu chuyện, dễ generate ra test case, task breakdown, hay thiết kế UI cho những phần bạn chưa muốn làm ở giai đoạn này.

Các Bước Thực Hành Cụ Thể

1. Chuẩn hóa một template Markdown cho user story (như mẫu trên) và lưu làm snippet trong Jira/Confluence, dùng lại cho mọi story thay vì viết tự do mỗi lần.
2. Rà lại tên field trong toàn bộ backlog hiện có — tìm và thống nhất các cách gọi khác nhau cho cùng một khái niệm (Acceptance Criteria/Definition of Done, User/Actor/Persona) trước khi đưa hàng loạt story cũ vào AI để xử lý.
3. Khi viết acceptance criteria, luôn thêm ít nhất một dòng edge case (điều kiện biên) tường minh — dữ liệu rỗng, quyền hạn không đủ, timeout, mạng chập chờn — vì AI generate test case hay task breakdown tốt hơn hẳn khi acceptance criteria đã có sẵn tư duy edge case, thay vì phải tự đoán.
4. Với epic lớn gồm nhiều story con, luôn đính kèm một đoạn "Epic Context" ngắn ở đầu mỗi story con (2-3 câu tóm tắt epic đó phục vụ mục tiêu gì), để khi AI xử lý story riêng lẻ vẫn không mất bối cảnh tổng thể.

Ví Dụ Prompt

Dưới đây là một user story được viết theo cấu trúc chuẩn của team.

## User Story: Xuất báo cáo giao dịch định kỳ

**As a** Kế toán trưởng tại doanh nghiệp SMB (dùng gói Business)
**I want to** thiết lập lịch tự động xuất báo cáo giao dịch hàng tuần
qua email
**So that** không phải vào hệ thống export thủ công mỗi thứ Hai

### Context bổ sung
- Liên quan OKR: Tăng retention của gói Business quý này (hiện churn
  rate gói Business là 8%/tháng, cao hơn gói Free 3%/tháng)
- Độ ưu tiên: P1

### Acceptance Criteria
- [ ] AC1: Given user ở gói Business, when họ vào Settings > Reports,
  then thấy tùy chọn "Lịch xuất báo cáo tự động"
- [ ] AC2: Given user đã thiết lập lịch, when đến đúng giờ đã chọn,
  then hệ thống gửi email kèm file PDF trong vòng 5 phút
- [ ] AC3 (edge case): Given user không có giao dịch nào trong tuần,
  when đến lịch xuất báo cáo, then hệ thống gửi email thông báo "không
  có giao dịch" thay vì gửi file rỗng

### Ràng buộc kỹ thuật đã biết
- Hệ thống email hiện dùng SendGrid, giới hạn 100 email/phút cho tier
  hiện tại
- Job scheduler dùng cron nội bộ, độ trễ tối đa cho phép là 10 phút

Dựa trên story này, hãy:
1. Viết ra 8-10 test case chi tiết bao phủ cả AC đã nêu và các edge
   case chưa được liệt kê (ví dụ: user đổi timezone, user hạ gói xuống
   Free giữa chừng khi đã thiết lập lịch).
2. Chỉ ra nếu có AC nào mâu thuẫn với ràng buộc kỹ thuật đã nêu (ví dụ
   về giới hạn gửi email).

Mẹo: Mỗi khi tạo story mới, tự hỏi "nếu tôi đưa đúng đoạn Markdown này cho một AI chưa từng biết gì về sản phẩm của tôi, nó có đủ thông tin để không hỏi lại câu nào cơ bản không?" — nếu câu trả lời là không, bổ sung ngay phần còn thiếu trước khi đưa vào backlog.

Cách Đưa Customer Feedback, Interview Transcript, Và Survey Data Vào AI Hiệu Quả

Customer feedback thô — email complaint, review trên App Store, transcript phỏng vấn dài 40 phút, kết quả khảo sát NPS với hàng trăm câu trả lời mở — là loại context giàu insight nhất nhưng cũng dễ bị AI xử lý sai nhất nếu đưa vào không đúng cách. Vấn đề cốt lõi: dữ liệu này thường rất dài, rất lộn xộn, và chứa nhiều sắc thái (nuance) tinh tế mà nếu tóm tắt vội sẽ mất mát thông tin quan trọng.

Vấn đề với việc dán transcript thô, không xử lý: một buổi interview 40 phút transcript ra có thể dài 6.000-8.000 từ. Nếu bạn dán nguyên cả file vào AI và hỏi "insight là gì", AI có xu hướng tóm tắt chung chung, dễ bỏ sót câu nói quan trọng nằm giữa cuộc trò chuyện (đặc biệt nếu nó bị chìm giữa những đoạn small talk hay câu hỏi lặp lại của interviewer). Đây là hiện tượng "lost in the middle" (thất lạc thông tin ở giữa) khá phổ biến với các mô hình ngôn ngữ khi context quá dài.

Kỹ thuật tagging theo theme trước khi đưa vào AI: thay vì đưa cả transcript thô, hãy đọc lướt một lần và gắn nhãn (tag) theo theme cho từng đoạn quan trọng — ví dụ [PAIN POINT], [FEATURE REQUEST], [WORKAROUND HIỆN TẠI], [CẢM XÚC MẠNH]. Việc này vừa giúp bạn (con người) không bỏ sót ý quan trọng khi đọc, vừa giúp AI xử lý có định hướng rõ ràng hơn thay vì phải tự suy luận đâu là ý chính giữa hàng nghìn từ.

Anonymize (ẩn danh hóa) trước khi đưa vào AI công cộng: nếu bạn dùng bản ChatGPT/Claude phiên bản không có cam kết bảo mật enterprise, luôn thay tên khách hàng thật, tên công ty, email, số điện thoại bằng placeholder (ví dụ "Khách hàng A", "Công ty X") trước khi dán vào AI — đây không chỉ là best practice bảo mật mà ở nhiều công ty là yêu cầu tuân thủ (compliance) bắt buộc, đặc biệt với dữ liệu thuộc phạm vi GDPR hoặc hợp đồng bảo mật với khách hàng enterprise.

Chunking (chia nhỏ) transcript dài: với transcript trên 3.000-4.000 từ, chia theo cấu trúc câu hỏi của buổi interview (mỗi chunk ứng với 1 câu hỏi lớn + câu trả lời liên quan) thay vì chia cơ học theo số từ. Phân tích từng chunk riêng để lấy insight, sau đó dùng một prompt tổng hợp để gộp các insight từ nhiều chunk lại — cách này giữ được độ chi tiết tốt hơn nhiều so với nhồi cả transcript vào một lần.

Với survey data (dữ liệu khảo sát) dạng câu trả lời mở số lượng lớn: đừng đưa từng câu trả lời riêng lẻ, cũng đừng chỉ đưa con số tổng hợp (ví dụ "NPS = 42") mà bỏ mất câu trả lời định tính. Cách hiệu quả: export toàn bộ câu trả lời mở ra một bảng (kèm điểm NPS đi cùng mỗi câu, ví dụ Promoter/Passive/Detractor), rồi để AI nhóm theo theme và đếm tần suất — vừa giữ được ngữ cảnh gốc (bạn có thể trace lại câu trả lời nào tạo ra theme nào), vừa có số liệu định lượng đi kèm.

Các Bước Thực Hành Cụ Thể

1. Sau mỗi buổi interview, dành 10-15 phút đọc lại transcript và gắn tag theo theme ngay (dùng comment trong Google Docs hoặc highlight màu) — đừng để dồn 10 buổi interview rồi mới xử lý cùng lúc, vì lúc đó khối lượng dữ liệu sẽ quá lớn để AI xử lý có chất lượng tốt.
2. Xây một bảng tổng hợp "Theme x Interview" (dòng là theme, cột là từng buổi interview, ô đánh dấu có/không xuất hiện) trước khi hỏi AI phân tích — bảng này tự nó thường đã cho bạn thấy pattern rõ ràng trước cả khi cần AI.
3. Với survey NPS/CSAT, luôn xuất riêng nhóm Detractor (điểm thấp) ra một context riêng để phân tích sâu — nhóm này thường chứa insight về pain point giá trị nhất, dễ bị pha loãng nếu trộn chung với câu trả lời của Promoter khi phân tích.
4. Thiết lập một checklist ẩn danh hóa bắt buộc (tên, email, công ty, số hợp đồng) áp dụng cho mọi dữ liệu feedback trước khi đưa vào công cụ AI không thuộc phạm vi bảo mật doanh nghiệp đã ký hợp đồng.

Ví Dụ Prompt

Dưới đây là transcript một buổi interview với khách hàng đã được tôi
gắn tag theo theme (đã ẩn danh hóa tên khách hàng thành "Khách hàng A").

[PASTE TRANSCRIPT ĐÃ TAG, ví dụ:
Interviewer: Anh thường gặp khó khăn gì khi tạo báo cáo tháng?
Khách hàng A: [PAIN POINT] Tôi mất khoảng 2 tiếng mỗi tháng để copy dữ
liệu từ 3 nguồn khác nhau vào Excel, rất dễ sai sót.
[WORKAROUND HIỆN TẠI] Hiện tại tôi phải nhờ đội kế toán double-check
lại số liệu trước khi gửi cho sếp.
[CẢM XÚC MẠNH] Nói thật là tháng nào tôi cũng thấy stress vì việc này,
nó chiếm hết một ngày làm việc của tôi.]

Hãy phân tích:
1. Liệt kê tất cả pain point cụ thể được đề cập, trích dẫn nguyên văn
   câu nói làm bằng chứng cho mỗi pain point (không diễn giải lại,
   trích dẫn chính xác).
2. Với mỗi pain point, đánh giá mức độ cảm xúc (từ ngữ thể hiện mức độ
   bức xúc/hài lòng) dựa trên cách khách hàng diễn đạt, không chỉ dựa
   trên nội dung.
3. Chỉ ra các workaround khách hàng đang tự làm — đây là tín hiệu quan
   trọng cho thấy nhu cầu thật, vì họ đã bỏ effort ra tự giải quyết.
4. Không tự suy diễn thêm pain point nào KHÔNG có trong transcript.

Trả lời bằng tiếng Việt, giữ nguyên các trích dẫn tiếng Việt gốc.

Dưới đây là 80 câu trả lời mở từ khảo sát NPS quý này, mỗi câu kèm
điểm NPS (0-10) khách hàng đã cho:

[PASTE BẢNG: Câu trả lời | Điểm NPS]

Hãy:
1. Nhóm các câu trả lời của nhóm Detractor (điểm 0-6) theo theme, đếm
   số lượng câu trả lời cho mỗi theme.
2. Làm tương tự cho nhóm Promoter (điểm 9-10) — họ đánh giá cao điều gì
   nhất.
3. Với mỗi theme, trích 2-3 câu trả lời tiêu biểu làm ví dụ minh họa.
4. Chỉ ra nếu có theme nào xuất hiện ở CẢ hai nhóm Detractor và Promoter
   (ví dụ cùng nói về tốc độ tải trang nhưng một bên khen một bên chê)
   — đây là tín hiệu đáng chú ý về sự không nhất quán trải nghiệm.

Mẹo: Đừng bao giờ để AI tóm tắt feedback rồi xóa bản gốc — luôn giữ transcript/raw data gốc kèm theo bất kỳ bản insight nào AI tạo ra, và luôn có thể trace ngược từ insight về câu nói gốc. Insight không có nguồn trích dẫn cụ thể rất dễ bị nghi ngờ khi trình bày trước stakeholder, và bản thân bạn cũng khó kiểm chứng lại AI có suy diễn quá đà hay không.

Khi Nào Nên Dùng Full Document, Khi Nào Nên Dùng Bản Tóm Tắt

Đây là câu hỏi PM nào cũng gặp nhưng ít ai có nguyên tắc rõ ràng để quyết định: dán cả một PRD 15 trang, hay chỉ tóm tắt 3 đoạn? Câu trả lời phụ thuộc vào việc đánh đổi giữa ba yếu tố — độ trung thực (fidelity), ngân sách context window, và độ nhiễu (noise).

Fidelity (độ trung thực) là lý do để dùng full document. Khi task đòi hỏi AI phải bắt được chi tiết cụ thể, câu chữ chính xác, hay các ràng buộc nhỏ nằm rải rác trong tài liệu (ví dụ: một PRD có 20 acceptance criteria với nhiều điều kiện biên phức tạp, một hợp đồng SLA với khách hàng enterprise có điều khoản cụ thể), tóm tắt sẽ luôn làm mất một phần thông tin — và bạn không biết trước phần nào bị mất cho đến khi phát hiện ra AI bỏ sót nó ở output cuối cùng. Với các tài liệu mang tính pháp lý, compliance, hay acceptance criteria chi tiết, ưu tiên full document gần như luôn là lựa chọn an toàn hơn.

Ngân sách context window (context window budget) là lý do để dùng bản tóm tắt. Mọi mô hình AI đều có giới hạn về lượng văn bản xử lý tốt trong một lần — và quan trọng hơn, ngay cả khi kỹ thuật cho phép nhồi rất nhiều văn bản, chất lượng chú ý (attention) của mô hình vẫn giảm khi văn bản quá dài, đặc biệt với thông tin nằm ở giữa tài liệu. Nếu bạn cần AI xử lý nhanh nhiều tài liệu cùng lúc (ví dụ tổng hợp 10 buổi interview để tìm theme chung), dùng bản tóm tắt của từng buổi thay vì 10 transcript đầy đủ sẽ hiệu quả hơn nhiều và ít có nguy cơ AI bỏ sót thông tin ở giữa.

Noise (nhiễu) là lý do để luôn tóm tắt trước khi đưa các phần không liên quan. Một vision doc 20 trang có thể chỉ có 2 đoạn liên quan trực tiếp đến task hiện tại — 18 trang còn lại là nhiễu, khiến AI dễ bị phân tán, đôi khi còn "nhặt" nhầm thông tin không liên quan để đưa vào câu trả lời chỉ vì nó nằm trong context, dù không ai yêu cầu.

Nguyên tắc thực dụng để quyết định nhanh:

Kỹ thuật hai tầng (two-tier context): với các task quan trọng, một cách làm an toàn là đưa bản tóm tắt trước để AI nắm bối cảnh tổng thể, sau đó đưa full document của riêng phần cần độ chính xác cao (ví dụ: tóm tắt toàn bộ PRD 15 trang trong 5 câu, nhưng dán nguyên văn phần "Acceptance Criteria" và "Ràng buộc kỹ thuật"). Cách này cân bằng được cả ba yếu tố: AI vẫn có bối cảnh rộng, nhưng phần cần độ chính xác tuyệt đối không bị tóm tắt làm mất chi tiết.

Các Bước Thực Hành Cụ Thể

1. Trước khi dán bất kỳ tài liệu dài nào, tự hỏi: "Task này có cần AI bắt đúng từng câu chữ cụ thể không, hay chỉ cần hiểu ý chính?" — câu trả lời quyết định ngay full document hay tóm tắt.
2. Với tài liệu dài trên 5-6 trang, luôn thử kỹ thuật hai tầng: tóm tắt tổng thể + full document cho đúng phần liên quan trực tiếp, thay vì chọn cực đoan một trong hai.
3. Khi tổng hợp nhiều nguồn (nhiều buổi interview, nhiều PRD cũ), tạo bản tóm tắt chuẩn hóa cho mỗi nguồn trước (ví dụ 5 dòng: mục tiêu, đối tượng, top pain point, quyết định chính, ngày thực hiện) rồi mới đưa các bản tóm tắt này vào cùng một prompt tổng hợp.
4. Luôn giữ lại full document gốc kèm link trong prompt hoặc trong tài liệu context, để khi AI đưa ra kết luận nghi vấn, bạn (hoặc đồng nghiệp review lại) có thể quay về nguồn gốc kiểm chứng ngay, không phải đi tìm lại từ đầu.

Ví Dụ Prompt

Tôi cần bạn phân tích một PRD dài. Để tiết kiệm context và tránh nhiễu,
tôi sẽ cung cấp theo 2 tầng:

TẦNG 1 - TÓM TẮT TỔNG THỂ (bối cảnh, không cần trích dẫn chính xác):
Đây là PRD cho tính năng "Đa tiền tệ" (Multi-currency) cho phép doanh
nghiệp xuất hóa đơn bằng nhiều loại tiền tệ khác nhau. Mục tiêu: mở
rộng thị trường sang khách hàng có giao dịch quốc tế, hiện chiếm 15%
tổng khách hàng nhưng có ARPU (doanh thu trung bình/khách hàng) cao
gấp 2.3 lần khách hàng nội địa.

TẦNG 2 - FULL TEXT phần Acceptance Criteria (cần chính xác tuyệt đối):
[PASTE NGUYÊN VĂN TOÀN BỘ ACCEPTANCE CRITERIA, không tóm tắt]

Dựa trên cả hai tầng context trên, hãy viết breakdown task kỹ thuật chi
tiết cho đội dev, đảm bảo bám sát chính xác từng acceptance criteria đã
nêu ở Tầng 2, không bỏ sót điều kiện nào, đồng thời giải thích ngắn gọn
lý do ưu tiên (dựa trên bối cảnh kinh doanh ở Tầng 1) nếu cần sắp xếp
thứ tự triển khai các task.

Mẹo: Khi phân vân không biết chọn full document hay tóm tắt, hãy nghiêng về full document cho lần phân tích đầu tiên của một tài liệu mới — bạn có thể quan sát AI xử lý toàn bộ nó thế nào, từ đó biết chính xác phần nào an toàn để tóm tắt ở các lần dùng sau, thay vì đoán mò ngay từ đầu và có nguy cơ bỏ sót thông tin quan trọng mà chính bạn cũng chưa biết là nó tồn tại.

Những Điểm Chính Cần Nhớ

• Product context đầy đủ đến từ năm nguồn: strategy/vision doc, user research, product metrics, competitive data, và ràng buộc kỹ thuật — thiếu nguồn nào, AI sẽ tự bịa ra giả định thay cho nguồn đó, thường dẫn đến output lệch hướng.
• Cấu trúc requirement và user story theo Markdown nhất quán (tên field cố định, Given/When/Then cho acceptance criteria, mục "Ngoài phạm vi" rõ ràng) giúp AI đọc hiểu chính xác hơn hẳn so với văn xuôi tự do.
• Customer feedback thô cần được tag theo theme, ẩn danh hóa, và chunking hợp lý trước khi đưa vào AI — dán nguyên transcript dài không qua xử lý dễ khiến AI bỏ sót insight quan trọng nằm ở giữa.
• Chọn giữa full document và bản tóm tắt dựa trên đánh đổi giữa fidelity, ngân sách context window, và noise; kỹ thuật hai tầng (tóm tắt tổng thể + full text phần quan trọng) thường là lựa chọn cân bằng nhất cho các tài liệu dài.
• Luôn giữ lại nguồn gốc (raw data, full document) song song với bất kỳ bản tóm tắt hay insight nào AI tạo ra — khả năng trace ngược về nguồn là yếu tố quyết định độ tin cậy khi trình bày trước stakeholder.

Mẹo: Trước khi paste bất kỳ tài liệu nào cho AI trong tuần này, chạy nhanh qua 5 gạch đầu dòng trên như một checklist 30 giây — nếu thiếu nguồn context nào hoặc chưa xác định full document vs. tóm tắt, bổ sung ngay trước khi bấm gửi, thay vì phát hiện ra sau khi đã nhận một output lệch hướng.