Bạn copy nguyên một PRD 35 trang, dán thêm 3 tháng dữ liệu analytics xuất từ Amplitude, kèm transcript phỏng vấn user dài 40 phút, rồi hỏi ChatGPT: "Phân tích giúp tôi nên ưu tiên fix gì trong sprint tới?". AI trả lời rất tự tin, liệt kê gọn gàng 5 gạch đầu dòng — nhưng lại bỏ sót đúng insight quan trọng nhất nằm ở giữa transcript, phần mà 3 user liên tục phàn nàn về một luồng checkout bị lỗi. Bạn không phải người đầu tiên gặp chuyện này. Đây không phải vì AI "kém thông minh" hay bạn "hỏi sai câu" — mà vì có một cơ chế kỹ thuật rất cụ thể đang chi phối cách LLM (Large Language Model) xử lý mọi thứ bạn đưa vào: tokenization (mã hoá thành token), context window (cửa sổ ngữ cảnh), và cách model phân bổ "sự chú ý" không đều trên toàn bộ văn bản.
Với một PM/BA, hiểu cơ chế này không phải kiến thức "cho vui" — nó quyết định trực tiếp việc bạn có nhận được insight đúng từ một backlog 200 item, một PRD dài, hay một bộ báo cáo nghiên cứu người dùng hay không. Bài này sẽ đi từ khái niệm token và context window, qua việc AI thực sự "thấy" gì khi bạn paste PRD/user story/báo cáo phân tích, đến lý do vì sao tài liệu dài và thiếu cấu trúc luôn cho ra kết quả tệ hơn, và cuối cùng là cách xử lý khi công việc phân tích của bạn — như review cả một backlog lớn hay tổng hợp hàng chục bản ghi phỏng vấn — vượt quá khả năng "đọc" một lần của AI.
Token, Context Window Là Gì Và Vì Sao Chúng Quyết Định Chất Lượng Prompt Của Bạn?
Token là đơn vị nhỏ nhất mà LLM dùng để "đọc" và "viết" văn bản — không phải từ, không phải ký tự, mà một đơn vị trung gian do một bộ tokenizer (bộ mã hoá) cắt ra. Với tiếng Anh, một token thường xấp xỉ 3-4 ký tự hoặc một phần của từ (ví dụ "prioritization" có thể bị cắt thành "prior", "iti", "zation"). Với tiếng Việt có dấu, tình hình phức tạp hơn: nhiều tokenizer xử lý tiếng Việt kém hiệu quả hơn tiếng Anh, một câu tiếng Việt có thể tốn nhiều token hơn hẳn câu tiếng Anh cùng nghĩa, vì dấu thanh và cấu trúc âm tiết khiến từ bị cắt vụn hơn. Đây là lý do thực tế: nếu bạn viết PRD hoàn toàn bằng tiếng Việt rồi paste vào AI, tài liệu đó "ngốn" context window nhanh hơn bạn tưởng so với cùng nội dung viết bằng tiếng Anh.
Context window là tổng số token tối đa mà model có thể "nhìn thấy" trong một lượt xử lý — bao gồm cả toàn bộ input bạn đưa vào (system prompt, tài liệu đính kèm, lịch sử hội thoại) lẫn output nó sinh ra. Các model phổ biến hiện nay có context window rất khác nhau: một số model ChatGPT phổ thông giới hạn quanh mức 32K-128K token, trong khi Claude (qua claude.ai hoặc Claude Projects) hỗ trợ tới 200K token trở lên ở một số gói. Con số cụ thể thay đổi liên tục theo từng phiên bản model, nên điều bạn cần nhớ không phải một con số cố định, mà nguyên tắc: mọi model đều có trần, và cái trần đó luôn thấp hơn bạn nghĩ khi công việc PM thực tế liên quan đến hàng chục tài liệu.
Vì Sao Điều Này Quan Trọng Với Prompt Hàng Ngày Của Bạn
Ba hệ quả trực tiếp mà PM/BA hay bỏ qua:
- Token của bạn và token của tài liệu cùng chia sẻ một "ngân sách". Nếu bạn paste một PRD dài 15.000 token, chỉ còn lại phần ngân sách còn lại cho AI suy nghĩ và trả lời — nếu ngân sách gần cạn, output sẽ bị cắt cụt hoặc hời hợt.
- Không phải mọi token đều được "chú ý" như nhau. Model có xu hướng xử lý tốt nhất phần đầu và phần cuối context, còn phần giữa dễ bị lướt qua — hiện tượng này giới nghiên cứu gọi là "lost in the middle" (mất thông tin ở giữa). Với một BA hay nhét bảng acceptance criteria dài ở giữa PRD, đây là rủi ro thật, không phải lý thuyết suông.
- Context window không miễn phí về mặt chất lượng. Nhồi càng nhiều tài liệu không liên quan vào cùng một lần hỏi, model càng dễ bị "loãng" — giống việc bạn giao cho một nhân viên mới đọc 10 tài liệu cùng lúc rồi hỏi "tóm tắt vấn đề chính", so với chỉ đưa đúng 1-2 tài liệu liên quan.
Các Bước Thực Hành
- Trước khi paste một tài liệu dài (PRD, bản backlog export, báo cáo research) vào AI, ước lượng nhanh độ dài: 1 trang A4 tiếng Việt thông thường ≈ 600-900 token. Một PRD 20 trang có thể đã chiếm 15.000-20.000 token chỉ riêng input.
- Nếu bạn dùng ChatGPT/Claude thường xuyên cho công việc PM, thử dán một đoạn mẫu vào công cụ đếm token (ví dụ OpenAI Tokenizer hoặc các tiện ích đếm token có sẵn trong nhiều app AI) để có cảm giác thực tế về tỷ lệ chữ/token của tài liệu bạn hay dùng.
- Với tài liệu quan trọng nhất trong PRD (ví dụ bảng acceptance criteria, risk, hoặc metric mục tiêu), luôn đặt nó ở đầu hoặc cuối phần bạn paste — tránh chôn nó ở giữa một khối văn bản dài.
- Khi thấy AI trả lời hời hợt hoặc bỏ sót ý dù bạn đã paste đủ thông tin, thử nghiệm bằng cách cắt bớt phần không liên quan trực tiếp đến câu hỏi, rồi hỏi lại — nếu câu trả lời tốt hơn hẳn, đó là dấu hiệu context trước đó đã quá tải.
Ví Dụ Prompt
Tôi sắp paste một PRD dài khoảng 18 trang cho tính năng "Thanh toán
one-click". Trước khi tôi paste, hãy xác nhận: bạn có thể xử lý tốt
toàn bộ tài liệu trong một lượt, hay tôi nên chia nhỏ theo từng phần
(mục tiêu, user story, acceptance criteria, rủi ro kỹ thuật) để đảm
bảo bạn không bỏ sót phần nào ở giữa tài liệu?
Nếu chia nhỏ, hãy đề xuất cách chia hợp lý nhất theo cấu trúc PRD
tiêu chuẩn, và tôi sẽ paste từng phần theo thứ tự bạn gợi ý.
Mẹo: Đặt câu hỏi quan trọng nhất — thứ bạn thực sự cần AI trả lời — ngay từ đầu prompt, trước khi paste tài liệu dài, thay vì hỏi sau cùng. Nhiều model xử lý tốt hơn khi biết trước "nhiệm vụ" là gì rồi mới đọc dữ liệu, giống việc bạn đọc đề bài trước khi đọc tài liệu tham khảo.
AI Thực Sự "Thấy" Gì Khi Bạn Paste PRD, User Story, Hay Báo Cáo Analytics?
Đây là ngộ nhận phổ biến nhất: PM thường nghĩ AI "đọc" tài liệu giống hệt cách con người đọc — thấy heading in đậm, thấy bảng được canh cột ngay ngắn, thấy biểu đồ. Thực tế, AI (khi bạn chỉ paste text) chỉ nhận một chuỗi token phẳng. Mọi định dạng trực quan — bold, indent, canh lề bảng, màu sắc highlight trong Confluence hay Notion — hoặc bị mất hoàn toàn, hoặc chỉ còn lại dưới dạng ký tự Markdown (**, -, |) nếu công cụ copy giữ được chúng.
Ba tình huống PM/BA hay gặp và hậu quả cụ thể:
- Paste PRD từ Confluence: bảng acceptance criteria có thể bị "vỡ cấu trúc" — các dòng bị dồn lại, cột bị lẫn vào nhau thành một khối text khó phân biệt trường nào ứng với giá trị nào. AI vẫn cố suy luận, nhưng dễ gán sai giá trị cho sai cột.
- Paste user story kiểu Gherkin (Given/When/Then): đây là trường hợp tốt — cấu trúc rõ ràng, từ khoá lặp lại nhất quán, giúp AI phân tách chính xác điều kiện đầu vào và kết quả mong đợi. So với một user story viết dạng văn xuôi tự do, format Gherkin gần như luôn cho kết quả phân tích chính xác hơn.
- Paste báo cáo analytics xuất từ Amplitude/Mixpanel/Google Analytics dạng PDF rồi copy text: các con số trong bảng dễ bị xáo trộn thứ tự khi copy — ví dụ tên metric và giá trị bị tách rời dòng, khiến AI đọc nhầm "tỷ lệ chuyển đổi 12%" thành gắn với sai kênh traffic. Đây là lỗi âm thầm nguy hiểm nhất vì output AI trông vẫn rất hợp lý, chỉ sai ở chỗ bạn không dễ phát hiện.
Một điểm quan trọng khác: nếu báo cáo của bạn có biểu đồ, dashboard, hoặc ảnh chụp màn hình, việc chỉ copy phần text xung quanh sẽ khiến AI hoàn toàn không "thấy" dữ liệu trong hình. Với các công cụ hỗ trợ đa phương thức (multimodal) như Claude hoặc ChatGPT có khả năng đọc ảnh, hãy đính kèm trực tiếp ảnh chụp biểu đồ thay vì mô tả lại bằng lời — độ chính xác khác biệt rất lớn.
Các Bước Thực Hành
- Trước khi paste một PRD hay báo cáo dài, kiểm tra nhanh bằng mắt: bảng có còn giữ được cấu trúc hàng/cột rõ ràng sau khi paste không? Nếu bị vỡ, chuyển bảng đó sang định dạng Markdown table thủ công trước khi gửi.
- Với user story, luôn ưu tiên viết hoặc chuyển sang định dạng có cấu trúc rõ ràng (Given/When/Then, hoặc ít nhất là "Là [role], tôi muốn [action], để [outcome]") thay vì mô tả tự do.
- Với báo cáo analytics, nếu có thể, xuất trực tiếp dữ liệu dạng bảng (CSV/Markdown) thay vì copy text từ PDF — hoặc đính kèm ảnh chụp màn hình dashboard nếu công cụ AI bạn dùng hỗ trợ đọc ảnh.
- Sau khi paste tài liệu quan trọng, luôn dùng một câu hỏi "kiểm tra hiểu" trước khi giao nhiệm vụ phân tích chính — yêu cầu AI tóm tắt lại những gì nó vừa đọc, để bạn phát hiện sớm nếu có phần bị đọc sai hoặc đọc thiếu.
Ví Dụ Prompt
Dưới đây là một bảng dữ liệu analytics tôi export từ Amplitude
(có thể bị lệch định dạng do copy từ PDF):
[PASTE DỮ LIỆU ANALYTICS]
Trước khi phân tích, hãy làm hai việc:
1. Liệt kê lại chính xác từng dòng dữ liệu bạn đọc được — tên metric,
giá trị, đơn vị, và khoảng thời gian tương ứng — để tôi xác nhận
bạn đọc đúng, không bị lệch cột do lỗi copy.
2. Nếu có dòng nào bạn không chắc chắn cách ghép giá trị với metric,
hãy nêu rõ và hỏi lại tôi thay vì tự suy đoán.
Sau khi tôi xác nhận dữ liệu đọc đúng, tôi sẽ yêu cầu bạn phân tích
xu hướng chuyển đổi (conversion) theo từng kênh.
Mẹo: Với bất kỳ tài liệu nào có bảng số liệu quan trọng cho quyết định (metric ảnh hưởng đến roadmap, risk score, ước lượng effort), luôn dành một bước "AI đọc lại cho tôi nghe" trước khi tin tưởng phân tích tiếp theo — bước này tốn 30 giây nhưng tránh được rất nhiều quyết định sai dựa trên dữ liệu bị AI đọc nhầm.
Vì Sao Tài Liệu Dài, Thiếu Cấu Trúc Luôn Cho Ra Kết Quả AI Kém?
Hiện tượng "lost in the middle" đã nhắc ở phần trên có một hệ quả cụ thể với tài liệu PM: một PRD viết dưới dạng văn xuôi liền mạch, không heading, không bullet, không bảng — dù nội dung đầy đủ — vẫn cho kết quả phân tích tệ hơn hẳn so với cùng nội dung đó được cấu trúc rõ ràng bằng heading và danh sách. Lý do không nằm ở việc AI "không đọc được" — nó vẫn đọc hết toàn bộ token — mà nằm ở việc thiếu cấu trúc khiến model khó xác định ranh giới giữa các ý, dễ trộn lẫn ngữ cảnh của đoạn này sang đoạn khác, và có xu hướng tóm tắt chung chung thay vì trích xuất chính xác.
Ba tình huống PM/BA hay tự làm khó chính mình:
- PRD viết theo kiểu "kể chuyện": mở đầu bằng bối cảnh thị trường, lồng luôn yêu cầu kỹ thuật vào giữa đoạn mô tả use case, rồi kết bằng risk — tất cả trong các đoạn văn dài không ngắt. Khi hỏi AI "liệt kê acceptance criteria", nó phải tự suy luận đâu là acceptance criteria thật sự giữa một rừng câu mô tả, dễ bỏ sót hoặc bịa thêm ý không có trong tài liệu gốc (hallucination — model "tự chế" thông tin nghe hợp lý nhưng không đúng nguồn).
- Ghi chú họp/retro dạng "brain dump": một khối ghi chú dài từ buổi sprint retro, không phân biệt ai nói gì, ý nào thuộc chủ đề nào — AI khi tóm tắt dễ gộp nhầm ý kiến của hai người khác nhau thành một, hoặc đánh mất sắc thái quan trọng (ví dụ một ý được nói với giọng phản đối mạnh bị tóm tắt thành ý kiến trung lập).
- Transcript phỏng vấn user không đánh dấu người nói: nếu bản ghi phỏng vấn 40 phút chỉ là một khối text liên tục không ghi "Interviewer:"/"User:", AI rất dễ nhầm câu hỏi của người phỏng vấn thành phát biểu của user, dẫn đến insight bị bóp méo hoàn toàn — đây là lỗi nghiêm trọng vì bạn có thể ra quyết định roadmap dựa trên "nhu cầu user" thực chất là câu hỏi dẫn dắt của chính interviewer.
Nguyên tắc chung: cấu trúc rõ ràng (heading, bullet, bảng, nhãn người nói) không chỉ giúp con người đọc nhanh hơn — nó thực sự thay đổi cách model phân bổ sự chú ý và ranh giới ngữ nghĩa, dẫn đến độ chính xác cao hơn đáng kể, đặc biệt với tài liệu dài.
Các Bước Thực Hành
- Trước khi đưa bất kỳ tài liệu dài nào vào AI để phân tích sâu, dành 5-10 phút thêm heading và bullet nếu tài liệu gốc chưa có — đây là khoản đầu tư nhỏ đổi lấy độ chính xác lớn.
- Với ghi chú họp/retro, luôn gắn nhãn người nói (tên hoặc vai trò) trước mỗi ý, kể cả khi ghi chú nhanh tay trong cuộc họp.
- Với transcript phỏng vấn, nếu công cụ ghi âm (Otter.ai, Fireflies, Zoom transcript) không tự tách người nói chính xác, dành thời gian sửa lại nhãn "Interviewer/User" cho ít nhất những đoạn chứa insight quan trọng nhất trước khi đưa vào AI phân tích.
- Nếu không có thời gian cấu trúc lại thủ công, hãy yêu cầu chính AI làm bước "cấu trúc hoá" trước, tách riêng thành một lượt hỏi độc lập, rồi mới dùng bản đã cấu trúc để phân tích sâu ở lượt sau — tránh gộp hai việc "cấu trúc lại" và "phân tích" vào cùng một prompt.
Ví Dụ Prompt
Dưới đây là ghi chú thô (chưa có cấu trúc) từ buổi sprint retro của
team tôi, không phân biệt rõ ai nói ý nào:
[PASTE GHI CHÚ THÔ]
Bước 1 — Cấu trúc hoá: hãy tổ chức lại nội dung trên thành các mục
rõ ràng: "Điều đang làm tốt", "Điều cần cải thiện", "Hành động đề
xuất", mỗi ý giữ nguyên người phát biểu nếu xác định được từ ngữ
cảnh (ví dụ nếu ghi chú có tên viết tắt). Không tự thêm ý kiến nào
không có trong ghi chú gốc.
Sau khi tôi xác nhận bản cấu trúc hoá này đúng, tôi sẽ nhờ bạn phân
tích ưu tiên hành động cho sprint tới.
Mẹo: Nếu bạn thường xuyên đưa transcript phỏng vấn hoặc ghi chú họp vào AI, xây một template chuẩn (heading cố định: Bối cảnh, Người tham gia, Insight chính, Trích dẫn nổi bật, Hành động đề xuất) và luôn chuyển ghi chú thô sang template này trước — về lâu dài việc này tiết kiệm thời gian hơn nhiều so với việc sửa lỗi phân tích sai mỗi lần.
Giới Hạn Context Window Ảnh Hưởng Thế Nào Đến Các Tác Vụ Phân Tích Phức Tạp?
Những phần trên nói về việc một tài liệu vẫn "vừa" trong context window nhưng bị đọc kém vì thiếu cấu trúc. Nhưng có một lớp vấn đề khác nghiêm trọng hơn: khi khối lượng dữ liệu PM cần phân tích vượt hẳn context window, dù đã cấu trúc tốt đến đâu. Đây là tình huống rất thực tế: review một backlog 200 item trước khi lập roadmap quý, tổng hợp 15 bản transcript phỏng vấn user cho một nghiên cứu UX, hay phân tích toàn bộ ghi chú stakeholder qua 6 tháng để chuẩn bị báo cáo cho ban lãnh đạo.
Khi bạn cố nhồi toàn bộ dữ liệu đó vào một lần hỏi, một trong hai chuyện sẽ xảy ra: tài liệu bị cắt bớt tự động (bạn mất phần cuối mà không hề biết), hoặc tài liệu vừa lọt nhưng chất lượng phân tích giảm mạnh vì hiện tượng "loãng attention" đã nói ở phần trước, nhân lên gấp nhiều lần khi khối lượng dữ liệu lớn.
Ba Kỹ Thuật Xử Lý Khi Dữ Liệu Vượt Quá Context Window
- Chunking (chia nhỏ) + tóm tắt phân cấp (map-reduce): thay vì đưa cả 15 transcript phỏng vấn vào một lần, tóm tắt riêng từng transcript trước (mỗi lần một prompt riêng, tập trung trích insight chính), sau đó đưa 15 bản tóm tắt (ngắn hơn nhiều lần bản gốc) vào một prompt tổng hợp cuối cùng để tìm pattern chung. Đây chính là kỹ thuật "map-reduce" áp dụng vào prompt: map là bước tóm tắt từng phần, reduce là bước tổng hợp.
- Dùng công cụ có context window lớn hơn và có bộ nhớ dự án: với công việc PM lặp lại nhiều lần trên cùng một bộ tài liệu (PRD, research, roadmap của một sản phẩm), các công cụ như Claude Projects hoặc custom GPT trong ChatGPT cho phép lưu trữ tài liệu nền một lần, rồi hỏi nhiều câu khác nhau mà không phải paste lại toàn bộ context mỗi lần — giảm đáng kể rủi ro vượt hoặc lãng phí context window.
- Chiến lược truy xuất (retrieval): với backlog hoặc kho tài liệu quá lớn để nạp toàn bộ (hàng trăm item, hàng chục PRD cũ), giải pháp bền vững là chỉ đưa vào AI đúng phần liên quan đến câu hỏi hiện tại — ví dụ lọc backlog theo epic hoặc theo label trước khi paste, thay vì đưa nguyên cả backlog rồi hỏi "cái nào quan trọng nhất". Ở quy mô lớn hơn, các tổ chức dùng kỹ thuật RAG (Retrieval-Augmented Generation — sinh câu trả lời có truy xuất tăng cường) để tự động tìm đúng đoạn tài liệu liên quan trước khi đưa vào model, nhưng ở cấp độ cá nhân, PM hoàn toàn có thể làm thủ công bằng cách lọc và chia nhỏ dữ liệu trước khi hỏi.
Các Bước Thực Hành
- Trước khi phân tích một backlog lớn, nhóm các item theo epic hoặc theme trước — chạy phân tích risk/ưu tiên riêng cho từng nhóm 15-20 item, thay vì đưa cả 200 item vào một prompt.
- Với nhiều bản transcript phỏng vấn, tóm tắt từng bản theo một template cố định (insight chính, trích dẫn, mức độ tin cậy) trước, sau đó gộp các bản tóm tắt lại làm input cho một prompt tổng hợp tìm pattern chung.
- Nếu bạn làm việc lặp lại nhiều lần trên cùng một bộ tài liệu sản phẩm (PRD, roadmap, research của cùng một feature/sản phẩm), cân nhắc dùng Claude Projects hoặc tính năng tương đương để lưu tài liệu nền một lần, tránh phải paste lại từ đầu mỗi phiên làm việc.
- Luôn giữ lại các bản tóm tắt trung gian (tóm tắt từng transcript, tóm tắt từng epic) như một dạng "bộ nhớ ngoài" — vừa tiết kiệm token cho các lần hỏi sau, vừa giúp bạn tự kiểm tra lại nếu nghi ngờ AI bỏ sót gì đó ở bước tổng hợp cuối.
Ví Dụ Prompt
Tôi cần tổng hợp insight từ 12 bản transcript phỏng vấn user về tính
năng "Tìm kiếm nâng cao". Vì tổng dung lượng quá lớn để paste một
lần, tôi sẽ làm theo hai bước:
Bước 1 (lặp lại cho từng transcript): Với transcript dưới đây, hãy
tóm tắt theo đúng cấu trúc:
- Insight chính (tối đa 3 gạch đầu dòng)
- Trích dẫn nổi bật nhất (nguyên văn, ghi rõ là của user hay
interviewer)
- Mức độ tin cậy của insight (Cao/Trung/Thấp) dựa trên việc user có
nói rõ ràng hay chỉ ngụ ý
[PASTE 1 TRANSCRIPT]
---
(Sau khi có đủ 12 bản tóm tắt, dùng prompt Bước 2 sau:)
Dưới đây là 12 bản tóm tắt insight từ các phỏng vấn user riêng lẻ
về tính năng "Tìm kiếm nâng cao":
[PASTE 12 BẢN TÓM TẮT]
Hãy tổng hợp:
1. Những pattern/insight xuất hiện lặp lại ở ít nhất 3 user trở lên.
2. Những insight chỉ xuất hiện ở 1 user nhưng có mức độ tin cậy Cao
và impact tiềm năng lớn (không nên bỏ qua dù ít người nhắc tới).
3. Mâu thuẫn giữa các insight (nếu có), kèm giả thuyết vì sao có
mâu thuẫn (khác nhóm user, khác use case).
4. Đề xuất 3 hướng ưu tiên cho roadmap quý tới dựa trên tổng hợp
trên.
Mẹo: Đừng đợi đến khi context window "báo lỗi" hoặc AI trả lời sai mới nhận ra dữ liệu quá lớn. Hãy tập thói quen tự hỏi trước mỗi lần phân tích lớn: "Dữ liệu này có nên chia nhỏ trước không?" — nếu khối lượng vượt quá vài trang, câu trả lời gần như luôn là có, và tóm tắt phân cấp gần như luôn cho kết quả đáng tin cậy hơn nhồi tất cả vào một lần.
Những Điểm Chính Cần Nhớ
- Token và context window là giới hạn vật lý, không phải tuỳ chọn. Mọi tài liệu bạn paste, kể cả prompt và lịch sử hội thoại, đều chia sẻ chung một ngân sách token hữu hạn — hết ngân sách, chất lượng output giảm hoặc bị cắt.
- AI không "thấy" định dạng trực quan như con người. Bảng, heading, màu sắc dễ bị vỡ cấu trúc khi copy-paste; luôn kiểm tra và chuyển sang Markdown hoặc cấu trúc rõ ràng trước khi đưa tài liệu quan trọng vào AI.
- Tài liệu dài, thiếu cấu trúc luôn cho kết quả kém hơn tài liệu ngắn, có cấu trúc — do hiện tượng "lost in the middle" và ranh giới ngữ nghĩa không rõ ràng khiến model dễ nhầm lẫn hoặc bỏ sót.
- Khi dữ liệu vượt quá context window, chunking + tóm tắt phân cấp (map-reduce) là kỹ thuật nền tảng — tóm tắt từng phần trước, tổng hợp sau, thay vì cố nhồi tất cả vào một lần.
- Luôn có bước "kiểm tra hiểu" — yêu cầu AI nhắc lại hoặc tóm tắt những gì nó vừa đọc trước khi giao nhiệm vụ phân tích sâu, đặc biệt với dữ liệu số liệu quan trọng cho quyết định roadmap hoặc ưu tiên.
Mẹo: In hoặc lưu lại 5 gạch đầu dòng trên như một checklist dán cạnh màn hình trong vài tuần đầu làm việc với AI — hầu hết lỗi phân tích tệ mà PM/BA gặp phải đều xuất phát từ việc bỏ qua một trong năm nguyên tắc cơ bản này, chứ không phải vì AI "chưa đủ giỏi".