Problem Brief

Problem Brief dùng để làm gì?

Problem Brief là tài liệu một đến hai trang viết trước khi có giải pháp. Nó trả lời: vấn đề gì, của ai, to cỡ nào, ta biết gì và chưa biết gì, giải được thì nhìn thấy gì thay đổi. Nó cố ý không có phần thiết kế tính năng.

Lý do nó tồn tại: phần lớn đội nhận việc dưới dạng giải pháp — "làm nút X", "thêm bộ lọc Y". Khi giải pháp đến trước, đội tranh luận về cái nút, và không ai kiểm xem vấn đề có thật và có đáng giải không. Problem Brief kéo cuộc trò chuyện lùi lại một bước, đúng chỗ rẻ nhất để đổi ý.

Nó cũng là đầu vào cho MVP. Khi vấn đề, người gặp và chỉ số thành công đã rõ, phạm vi nhỏ nhất đủ để kiểm gần như tự lộ ra. Một brief tốt thường khiến đội bỏ đi một nửa số tính năng định làm — và đó là dấu hiệu nó đang làm đúng việc.

Dành cho: Product Manager · Business Analyst · Product Owner · Head of Product khi duyệt đầu vào cho đội

Dùng khi: Khi một yêu cầu, ý tưởng hoặc khiếu nại sắp biến thành việc của đội; trước khi viết PRD; trước buổi brainstorm giải pháp; khi hai bên đang cãi về giải pháp mà chưa thống nhất vấn đề.

Problem Brief, One-pager và PRD khác nhau ở đâu?

Thứ tự tự nhiên là brief, rồi one-pager hoặc thí nghiệm, rồi PRD. Bỏ qua brief không làm đội nhanh hơn; nó chỉ dời cuộc cãi về vấn đề sang lúc code đã viết xong.

Bản trắng — copy và dán vào tài liệu của bạn

Tối đa hai trang. Nếu phần 3 (bằng chứng) trống, brief chưa sẵn sàng để gửi đi — nó là một giả thuyết, và nên chuyển thành kế hoạch nghiên cứu.

PROBLEM BRIEF — [tên ngắn của vấn đề]
Người viết: ________  Ngày: ________  Trạng thái: nháp / đang rà / đã duyệt
Người cần đọc và góp ý: ________________________

1. VẤN ĐỀ TRONG MỘT CÂU
   [Ai] đang gặp [chuyện gì] khi [làm gì], dẫn tới [hậu quả đo được].

2. AI GẶP VẤN ĐỀ
   Nhóm người dùng: ________________  Quy mô: ______ người / ____ %
   Không phải ai: ________________

3. BẰNG CHỨNG
   Số liệu: ______________________________
   Lời người dùng (trích nguyên văn): "______________________________"
   Nguồn và ngày: ______________________________

4. TÁC ĐỘNG NẾU KHÔNG GIẢI
   Với người dùng: ______________________________
   Với doanh nghiệp (con số): ______________________________

5. VÌ SAO LÀ BÂY GIỜ
   ______________________________

6. NGƯỜI DÙNG ĐANG XOAY XỞ THẾ NÀO
   ______________________________

7. GIẢ ĐỊNH CHƯA KIỂM
   - Giả định: ______________  | Cách kiểm: ______________
   - Giả định: ______________  | Cách kiểm: ______________

8. GIẢI ĐƯỢC THÌ THẤY GÌ
   Chỉ số chính: ________ từ ____ xuống/lên ____ trong ____
   Chỉ số giữ an toàn (không được xấu đi): ________________

9. NGOÀI PHẠM VI
   - ______________________________

10. CÂU HỎI MỞ VÀ BƯỚC TIẾP THEO
   - ______________________ (ai trả lời, hạn)

Từng ô điền gì, và vì sao ô đó tồn tại

Cách viết và dùng Problem Brief

• Viết câu số 1 trước, rồi đưa ba người đọc. Nếu ba người hiểu ba kiểu, chưa viết tiếp. Mọi phần sau đều dựa vào câu này.
• Đi tìm bằng chứng trước khi viết tiếp. Mở dữ liệu, đọc 20 phiếu hỗ trợ gần nhất, gọi năm người dùng. Hai ngày tìm bằng chứng rẻ hơn rất nhiều so với hai tuần xây sai.
• Ước lượng tác động bằng phép nhân đơn giản — số người gặp × tần suất × cái giá mỗi lần. Ghi rõ đây là ước lượng và các số lấy từ đâu.
• Liệt kê giả định bằng câu "Chúng ta đang tin rằng..." và đánh dấu giả định nào nếu sai thì cả vấn đề sụp. Đó là thứ cần kiểm đầu tiên.
• Gửi cho kỹ thuật, thiết kế và một người phía kinh doanh trước khi họp. Yêu cầu họ góp ý bằng bình luận trên tài liệu; buổi họp chỉ để giải quyết chỗ bất đồng.
• Chốt bằng một trong ba quyết định: đi tiếp sang tìm giải pháp, cần thêm bằng chứng (ghi rõ thiếu gì), hoặc không giải lần này (ghi lý do). Cả ba đều là kết quả tốt.
• Giữ brief làm điểm neo. Khi viết PRD hoặc thiết kế MVP, mỗi phần phải chỉ ngược được về một dòng trong brief. Phần nào không chỉ được là phạm vi đang phình.

Ví dụ đã điền đầy đủ

Xe Gần (công ty giả định) — app đặt xe tải nhỏ chở hàng nội thành TP.HCM, khoảng 3.500 tài xế hoạt động. Đội vận hành đề xuất "thêm phí phạt tài xế huỷ chuyến"; PM viết brief trước khi ai bắt tay vào làm.

PROBLEM BRIEF — Tài xế huỷ chuyến sau khi đã nhận
Người viết: Phương (PM, mảng Đặt chuyến)   Ngày: 18/11/2026
Trạng thái: đang rà
Người cần đọc: anh Khoa (Vận hành), Bình (Tech lead), Thu (Design), chị Mai (Kinh doanh SME)

1. VẤN ĐỀ TRONG MỘT CÂU
   Khách đặt chuyến có bốc vác hoặc giao lên tầng bị tài xế huỷ sau khi
   đã nhận, phải đặt lại và chờ thêm trung bình 34 phút; 1/4 trong số đó
   bỏ đặt hẳn.

2. AI GẶP VẤN ĐỀ
   Nhóm: khách đặt chuyến có ghi chú "bốc vác", "lên tầng", "hàng cồng
   kềnh". Quy mô: khoảng 9.800 chuyến/tháng, 17% tổng số chuyến.
   Không phải ai: chuyến giao hàng thương mại điện tử theo tuyến cố định
   (tỷ lệ huỷ ở nhóm này chỉ 3%, đã ổn).

3. BẰNG CHỨNG
   Số liệu: tỷ lệ tài xế huỷ sau khi nhận là 21% ở nhóm này, so với 6%
   ở các chuyến khác (dữ liệu 01/08 - 31/10/2026).
   Lời tài xế: "Nhận rồi mới thấy ghi chú lên tầng 5 không thang máy,
   giá vậy em chịu không nổi." (tài xế quận 7, phỏng vấn 12/11)
   Lời khách: "Lần thứ hai bị huỷ là em gọi xe ngoài luôn." (khách SME
   bán nội thất, phiếu hỗ trợ 05/11)

4. TÁC ĐỘNG NẾU KHÔNG GIẢI
   Với khách: chờ thêm 34 phút; 26% bỏ đặt sau lần huỷ thứ nhất.
   Với doanh nghiệp: khoảng 2.060 chuyến huỷ/tháng × 26% bỏ đặt ×
   phí trung bình 285.000đ, khoảng 150 triệu đồng doanh thu/tháng, chưa
   tính khách SME rời đi hẳn.

5. VÌ SAO LÀ BÂY GIỜ
   Khối kinh doanh đang ký 40 khách SME nội thất và vật liệu cho Q1/2027,
   đúng nhóm có nhiều chuyến bốc vác nhất.

6. NGƯỜI DÙNG ĐANG XOAY XỞ THẾ NÀO
   Khách: gọi tổng đài nhờ tìm tài xế quen, hoặc thoả thuận thêm tiền
   mặt qua điện thoại. Tài xế: gọi khách hỏi trước rồi mới quyết định
   có đi hay huỷ.

7. GIẢ ĐỊNH CHƯA KIỂM
   - Tài xế huỷ chủ yếu vì giá không bù được công bốc vác, không phải vì
     quãng đường | Cách kiểm: đọc lý do huỷ của 300 chuyến gần nhất
   - Ghi chú của khách đủ rõ để định giá trước | Cách kiểm: đọc 100 ghi
     chú, đếm số ghi chú có tầng, thang máy, khối lượng
   - Phạt tài xế sẽ giảm huỷ mà không làm tài xế tránh nhận nhóm chuyến
     này | Cách kiểm: hỏi 15 tài xế; xem dữ liệu đợt phạt thử năm 2025

8. GIẢI ĐƯỢC THÌ THẤY GÌ
   Chỉ số chính: tỷ lệ tài xế huỷ sau khi nhận ở nhóm này từ 21% xuống
   10% trong 8 tuần sau khi ra mắt.
   Chỉ số an toàn: thời gian tìm được tài xế cho nhóm này không vượt
   quá 6 phút (hiện tại 4 phút 20 giây).

9. NGOÀI PHẠM VI
   - Huỷ do khách (một vấn đề khác, sẽ có brief riêng)
   - Chuyến liên tỉnh

10. CÂU HỎI MỞ VÀ BƯỚC TIẾP THEO
   - Đợt phạt thử 2025 cho kết quả gì? (anh Khoa, 22/11)
   - Có bao nhiêu % tài xế có người phụ bốc vác đi cùng? (Phương, 25/11)
   - Quyết định cần có: đi tiếp sang tìm giải pháp, hay cần thêm dữ liệu

Để ý chuyện gì xảy ra với đề xuất ban đầu "phạt tài xế huỷ chuyến". Nó không bị bác bỏ — nó trở thành một giả định ở phần 7, kèm cách kiểm và một chỉ số an toàn ở phần 8. Nếu tài xế huỷ vì giá không bù công bốc vác, phạt sẽ chỉ khiến họ né nhóm chuyến này, và thời gian tìm tài xế sẽ vọt lên. Brief giúp đội thấy điều đó trước khi code dòng đầu tiên.

Hiccups thường gặp và cách xử lý

Vì sao vai trò của bạn cần cái này

Definition of done

• Câu vấn đề không chứa tên tính năng hay thành phần giao diện.
• Có ít nhất một con số và một lời trích nguyên văn, kèm nguồn và ngày.
• Tác động được ước lượng bằng con số, có cách tính.
• Giả định được liệt kê kèm cách kiểm.
• Có chỉ số thành công và chỉ số giữ an toàn.
• Brief kết thúc bằng một quyết định rõ: đi tiếp, cần thêm bằng chứng, hoặc không giải lần này.