Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa đẩy một bản PRD dài 8 trang vào kênh Slack của đội ngũ. Engineer mở ra, lướt qua phần "Solution", nhíu mày rồi gõ một câu hỏi mà bạn sợ nhất: "Sao mình lại làm cái này nhỉ? Có gấp không?". Câu hỏi đó không phải vì engineer lười đọc, mà vì PRD của bạn nhảy thẳng vào "làm cái gì" trước khi trả lời "vì sao bây giờ". Đó chính là dấu hiệu kinh điển của một Context section yếu — hoặc tệ hơn, không tồn tại.
Context (bối cảnh) là phần mở đầu của PRD, nơi bạn dựng sân khấu trước khi diễn viên bước ra. Nó là cây cầu nối giữa thực tế kinh doanh hỗn độn ngoài kia và đề xuất giải pháp gọn gàng bạn sắp trình bày. Trong cả khóa học này, mỗi bài chỉ tập trung một mảnh: Bài 13 sẽ dạy bạn viết một Problem Statement sắc như dao, Bài 14 phân định Goals và Non-goals, Bài 16 đào sâu Personas. Còn Bài 12 hôm nay đứng ở vị trí đặc biệt: nó dạy bạn viết phần đặt nền móng — phần khiến người đọc gật gù "ừ, mình hiểu rồi, làm cái này lúc này là hợp lý" trước khi bạn nói một chữ nào về tính năng.
Một PM giỏi viết Context không phải để "cho đủ mục". Họ viết Context để mua được sự đồng thuận từ exec, để engineer hiểu được mức độ ưu tiên, và để chính bản thân kiểm tra xem ý tưởng này có thật sự đáng làm hay không. Nếu bạn không viết nổi một đoạn Context thuyết phục, rất có thể tính năng đó chưa đủ chín để làm.
Khái niệm cốt lõi
Context là gì và không phải là gì
Context section trả lời đúng một câu hỏi trọng tâm: "Vì sao chúng ta cần giải quyết chuyện này, và vì sao là NGAY BÂY GIỜ?"
Lưu ý hai vế. Vế đầu — "vì sao cần giải quyết" — là phần problem. Vế sau — "vì sao bây giờ" — chính là linh hồn của Context, thứ phân biệt nó với Problem Statement thuần túy. Một vấn đề có thể tồn tại nhiều năm, nhưng tại sao đội ngũ phải bỏ công sức vào nó trong quý này thay vì quý sau? Đó là câu hỏi mà exec luôn cân não, và Context phải trả lời thay họ.
Context không phải là:
- Một bản tóm tắt giải pháp (đó là phần Solution).
- Một danh sách tính năng (đó là phần Requirements).
- Một bài tự sự dài dòng về lịch sử sản phẩm từ thuở khai thiên lập địa.
Bốn thành tố của một Context mạnh
Tôi thường dạy học viên ghi nhớ một khung gồm bốn lớp, đi từ rộng đến hẹp:
1. Tình hình hiện tại (Current state). Mô tả thực trạng một cách trung thực, có số liệu. Không phải "người dùng không hài lòng" mà là "tỷ lệ rời bỏ ở bước thanh toán là 38%, cao gấp đôi mức trung bình ngành 18%".
2. Áp lực / sự thay đổi (The shift). Điều gì vừa thay đổi khiến vấn đề này trở nên cấp bách? Có thể là đối thủ vừa ra mắt tính năng, quy định pháp lý mới, hành vi người dùng đổi, hoặc một mục tiêu OKR của công ty. Đây chính là "vì sao bây giờ".
3. Cơ hội / rủi ro (Stakes). Nếu làm, công ty được gì? Nếu không làm, mất gì? Lượng hóa nếu có thể: doanh thu, thị phần, chi phí, mức độ hài lòng.
4. Vì sao là chúng ta (Why us / why this team). Vì sao đội ngũ này, ở thời điểm này, có lợi thế hoặc trách nhiệm giải quyết nó.
Không phải PRD nào cũng cần đủ bốn lớp với độ dài bằng nhau. Một tính năng nhỏ có thể gói gọn trong hai đoạn. Nhưng một sáng kiến chiến lược lớn cần cả bốn lớp được dệt vào nhau mạch lạc.
Context khác với các phần lân cận thế nào
Để bạn không lấn sân các bài khác, hãy phân định rạch ròi:
- Context trả lời "vì sao bây giờ" — đặt nền móng kinh doanh.
- Problem Statement (Bài 13) trả lời "vấn đề chính xác là gì" — đóng đinh nỗi đau cụ thể.
- Goals (Bài 14) trả lời "thành công trông như thế nào" — định nghĩa kết quả mong muốn.
Viết Context cho ba kiểu người đọc
Một PRD thường có ba nhóm độc giả với mối quan tâm khác nhau, và Context tốt phải chạm được cả ba:
- Engineer cần hiểu độ ưu tiên và ràng buộc kỹ thuật ẩn sau (vì sao gấp, có phụ thuộc gì).
- Designer cần hiểu người dùng đang khổ ở đâu để đồng cảm khi thiết kế.
- Exec / leadership cần thấy con số kinh doanh và sự liên kết với chiến lược công ty để duyệt nguồn lực.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán giao hàng nhanh (bối cảnh giả định hợp lý)
Giả sử bạn là PM tại một sàn thương mại điện tử lớn như Tiki, phụ trách tính năng giao hàng. Bạn muốn đề xuất xây dựng dịch vụ "giao trong 2 giờ" cho khu vực nội thành TP.HCM.
Một Context yếu sẽ viết: "Khách hàng muốn nhận hàng nhanh hơn. Chúng ta nên làm giao hàng 2 giờ." Đọc xong, exec không thấy lý do gì để duyệt ngân sách vận hành khổng lồ.
Một Context mạnh sẽ là: "Khảo sát Q1/2026 cho thấy 41% khách hủy giỏ hàng vì thời gian giao trung bình 1,8 ngày. Trong khi đó, đối thủ vừa tung gói giao 2 giờ ở 5 quận trung tâm và đã giành 12% thị phần nhóm khách hàng giá trị cao trong 3 tháng. Mỗi tháng trì hoãn, chúng ta ước tính mất 4,5 tỷ đồng GMV (tổng giá trị hàng hóa giao dịch) ở phân khúc này. Hạ tầng kho TikiNOW hiện đã phủ 80% nội thành — đây là cửa sổ hiếm để triển khai với chi phí biên thấp trước khi đối thủ mở rộng."
Bài học rút ra: Context mạnh không chỉ nói vấn đề, nó nối vấn đề với động thái đối thủ (the shift), lượng hóa thiệt hại (stakes), và chỉ ra lợi thế sẵn có (why us). Sau đoạn này, exec không hỏi "vì sao làm" nữa, mà hỏi "khi nào xong".
Ví dụ 2 — Startup fintech và áp lực pháp lý (bối cảnh Đông Nam Á)
Một startup ví điện tử ở Việt Nam — tạm gọi là PayViet — nhận được dự thảo quy định mới của Ngân hàng Nhà nước yêu cầu xác thực sinh trắc học (eKYC) cho mọi giao dịch trên 10 triệu đồng, có hiệu lực sau 6 tháng. PM phụ trách onboarding cần viết PRD cho tính năng eKYC.
Context của PM viết như sau: "Thông tư 17/2026 yêu cầu xác thực sinh trắc học bắt buộc cho giao dịch trên 10 triệu đồng từ ngày 01/01/2027. Hiện 23% giao dịch của PayViet (tương đương 180 tỷ đồng/tháng) thuộc nhóm này và chưa có cơ chế xác thực phù hợp. Nếu không tuân thủ đúng hạn, chúng ta đối mặt rủi ro bị đình chỉ giấy phép trung gian thanh toán — rủi ro sống còn. Đây không phải lựa chọn về tính năng, mà là điều kiện để tiếp tục vận hành. Cửa sổ 6 tháng đòi hỏi chốt phạm vi ngay trong sprint này."
Bài học rút ra: Khi động lực là tuân thủ pháp lý, "vì sao bây giờ" trở nên tuyệt đối và không thể thương lượng. Context ở đây có nhiệm vụ chuyển một yêu cầu pháp lý khô khan thành mệnh lệnh ưu tiên rõ ràng, kèm con số rủi ro để cả đội hiểu vì sao tính năng này được cắt ngang lộ trình. Lưu ý cách PM gắn deadline pháp lý vào hành động cụ thể ("chốt phạm vi ngay trong sprint này").
Ví dụ 3 — Grab và tính năng nhỏ dễ bị xem nhẹ
Không phải Context nào cũng phải hoành tráng. Giả sử bạn là PM tại Grab, đề xuất một thay đổi nhỏ: thêm nút "Đặt lại chuyến vừa rồi" trên màn hình chính.
Context ngắn gọn: "Dữ liệu hành vi cho thấy 34% chuyến xe là lặp lại lộ trình quen thuộc (nhà - công ty, công ty - nhà). Hiện người dùng phải gõ lại địa chỉ mỗi lần, trung bình 4 thao tác và 22 giây. Trong nhóm tài xế và người dùng cao tần, thời gian này là điểm ma sát lớn nhất theo phản hồi NPS quý trước. Đây là cải tiến chi phí thấp nhưng chạm trực tiếp nhóm người dùng đóng góp 60% doanh thu — phù hợp với OKR 'giảm ma sát đặt xe' của quý này."
Bài học rút ra: Ngay cả tính năng nhỏ cũng cần Context để giành quyền ưu tiên trong backlog đông đúc. Bí quyết là liên kết tính năng nhỏ với mục tiêu lớn (OKR của quý) và chỉ ra tỷ lệ "công ít - lợi nhiều". Context ở đây ngắn nhưng vẫn đủ bốn lớp: hiện trạng (34% chuyến lặp lại), ma sát (22 giây), stakes (nhóm 60% doanh thu), và liên kết chiến lược (OKR).
Hướng dẫn từng bước
Đây là quy trình tôi dùng để viết một Context section từ con số không:
Bước 1 — Thu thập "đạn" trước khi viết. Đừng viết Context bằng cảm tính. Đi gom số liệu: tỷ lệ chuyển đổi, số phàn nàn của support, dữ liệu phân tích, động thái đối thủ, OKR công ty. Mở một tài liệu nháp và dán hết vào. Context mạnh được xây từ bằng chứng, không phải tính từ.
Bước 2 — Viết câu mở đầu "vì sao bây giờ" trong một dòng. Trước khi viết cả đoạn, ép mình rút gọn lý do cấp bách thành đúng một câu. Ví dụ: "Đối thủ vừa chiếm 12% thị phần nhóm khách cao cấp trong 3 tháng." Nếu không viết nổi câu này, bạn chưa đủ rõ vì sao nên làm.
Bước 3 — Dệt bốn lớp theo thứ tự rộng-đến-hẹp. Bắt đầu bằng hiện trạng, rồi sự thay đổi/áp lực, rồi cơ hội/rủi ro, kết bằng vì sao là đội ngũ này. Mỗi lớp một đến hai câu, có số liệu.
Bước 4 — Cắt mọi câu không phục vụ "vì sao". Đọc lại từng câu và tự hỏi: "Câu này có giúp người đọc hiểu vì sao nên làm ngay không?" Nếu nó đang mô tả giải pháp, chuyển xuống phần Solution. Nếu nó là lịch sử không liên quan, xóa.
Bước 5 — Kiểm tra với "bài test exec 30 giây". Đưa Context cho một đồng nghiệp không thuộc đội, cho họ đọc 30 giây rồi hỏi: "Vì sao chúng ta nên làm cái này lúc này?" Nếu họ trả lời đúng và mạch lạc, Context của bạn đạt. Nếu họ ngập ngừng, viết lại.
Bước 6 — Gắn liên kết chiến lược. Câu cuối cùng nên nối tính năng với một OKR, chiến lược, hoặc cam kết cấp công ty. Đây là chiếc móc giúp exec dễ duyệt.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào giải pháp. Đây là lỗi phổ biến nhất. PM hào hứng với ý tưởng nên viết ngay "chúng ta sẽ xây dựng X". Hậu quả: người đọc không có nền tảng để đánh giá X có đáng làm không. Mẹo: bắt mình viết hết Context rồi mới cho phép gõ chữ "giải pháp" đầu tiên.
Lỗi 2 — Bỏ quên "vì sao bây giờ". Context chỉ nói vấn đề mà không nói tính cấp bách. Vấn đề thì lúc nào cũng có, nhưng nếu không có yếu tố thời điểm, tính năng của bạn sẽ mãi nằm dưới đáy backlog. Mẹo: luôn có ít nhất một câu bắt đầu bằng "Gần đây..." hoặc "Vừa qua..." để chỉ ra sự thay đổi.
Lỗi 3 — Định tính thay vì định lượng. "Nhiều người dùng phàn nàn" yếu hơn nhiều so với "287 ticket support trong tháng 5, tăng 40% so với tháng 4". Mẹo: với mỗi tính từ cảm tính (nhiều, lớn, nghiêm trọng), hãy tìm một con số thay thế.
Lỗi 4 — Viết quá dài thành tiểu thuyết. Context không phải nơi kể toàn bộ lịch sử sản phẩm. Một Context tốt cho tính năng vừa thường chỉ 3-5 đoạn. Mẹo: nếu vượt quá nửa trang, có lẽ bạn đang lẫn nội dung của phần khác vào.
Lỗi 5 — Số liệu không nguồn gốc. Đưa ra con số ấn tượng nhưng không ai biết lấy từ đâu sẽ làm giảm uy tín cả PRD. Mẹo: gắn nguồn ngắn gọn ngay sau số liệu — "(theo Mixpanel, Q1/2026)" — để người đọc tin tưởng.
Mẹo nâng cao — Viết Context cuối cùng, kiểm tra đầu tiên. Nhiều PM kỳ cựu viết phần Context sau khi đã làm rõ giải pháp trong đầu, vì lúc đó họ mới biết chính xác cần đặt nền móng cho điều gì. Nhưng khi trình bày, Context luôn đứng đầu. Hãy tách bạch thứ tự viết và thứ tự đọc.
Bài tập thực hành
Bài 1 — Chẩn đoán. Lấy một PRD cũ của bạn (hoặc một bản mẫu trên mạng) và đọc phần mở đầu. Đánh dấu xem nó có đủ bốn lớp không: hiện trạng, sự thay đổi, cơ hội/rủi ro, vì sao là chúng ta. Lớp nào thiếu? Lớp nào chỉ là tính từ mà thiếu số liệu?
Bài 2 — Một dòng "vì sao bây giờ". Chọn một tính năng bạn đang muốn đề xuất ở công ty. Viết đúng MỘT câu trả lời cho "vì sao phải làm cái này NGAY BÂY GIỜ". Nếu mất hơn 15 phút mà không viết nổi, đó là tín hiệu tính năng chưa đủ cấp bách — hãy ghi nhận điều đó.
Bài 3 — Viết hoàn chỉnh. Dùng khung bốn lớp, viết một Context section dài 3-4 đoạn cho tính năng ở Bài 2. Bắt buộc có ít nhất ba con số có nguồn, và câu cuối phải liên kết với một OKR hoặc chiến lược của công ty bạn.
Bài 4 — Bài test 30 giây. Gửi Context vừa viết cho một đồng nghiệp, cho họ đọc 30 giây rồi hỏi "vì sao nên làm cái này lúc này". Ghi lại câu trả lời của họ. Nếu lệch với ý bạn muốn truyền tải, viết lại đoạn mở đầu cho đến khi họ "bắt" đúng thông điệp.
Tóm tắt
Context section là phần đặt nền móng kinh doanh của PRD, trả lời câu hỏi cốt lõi: "Vì sao cần giải quyết, và vì sao là NGAY BÂY GIỜ?". Nó khác với Problem Statement (vấn đề chính xác là gì) và Goals (thành công trông ra sao) — Context đứng trước, rộng nhất, và mang nhiệm vụ mua được sự đồng thuận từ engineer, designer và exec.
Một Context mạnh được dệt từ bốn lớp: hiện trạng có số liệu, sự thay đổi tạo tính cấp bách, cơ hội/rủi ro được lượng hóa, và lý do vì sao đội ngũ này nên làm. Qua ba ví dụ — từ giao hàng nhanh, tuân thủ pháp lý fintech, đến một nút bấm nhỏ của Grab — ta thấy nguyên tắc chung: gắn vấn đề với con số, nối với động thái thị trường, và liên kết với chiến lược công ty.
Hãy nhớ năm chữ vàng: bằng chứng, không tính từ; cấp bách, không chung chung. Và mỗi khi viết xong, dùng "bài test exec 30 giây" để kiểm chứng. Nếu người đọc trả lời được "vì sao bây giờ" chỉ sau nửa phút, bạn đã viết một Context xứng đáng dẫn dắt cả PRD.