Mở đầu — vì sao bài này quan trọng
Nếu bạn từng viết một PRD và thấy phần "Problem Statement" của mình dài lê thê nhưng đọc xong vẫn không ai hiểu rốt cuộc vấn đề là gì — thì bài này dành cho bạn. Problem Statement (tuyên bố vấn đề) là trái tim của mọi tài liệu sản phẩm. Nó là câu trả lời cho câu hỏi đắt giá nhất: "Tại sao chúng ta phải làm cái này?"
Trong các bài trước, bạn đã học cách phân biệt PRD với Spec, học giải phẫu (anatomy) của một PRD tốt, và học viết phần "Problem" và "Goals" sắc bén ở mức tổng quan. Bài 13 này đi sâu vào một kỹ năng rất cụ thể nhưng cực kỳ quan trọng: chọn đúng độ dài cho Problem Statement — 1 câu hay 1 đoạn văn?
Đây không phải chuyện làm dáng văn chương. Một PM giỏi biết rằng độ dài của Problem Statement quyết định ba thứ: (1) tốc độ người đọc nắm được vấn đề, (2) khả năng tài liệu được phê duyệt nhanh, và (3) sự đồng thuận của team về phạm vi. Viết quá ngắn, bạn bỏ sót bối cảnh khiến engineer làm sai. Viết quá dài, bạn chôn vùi vấn đề chính dưới một đống chi tiết và không ai nhớ nổi bạn đang giải quyết điều gì.
Bài học hôm nay sẽ cho bạn hai công thức cụ thể — định dạng 1 câu và định dạng 1 đoạn — kèm tiêu chí rõ ràng để biết khi nào dùng cái nào, và cách viết từng loại sao cho sắc.
Khái niệm cốt lõi
Problem Statement là gì và không phải là gì
Problem Statement là một tuyên bố ngắn gọn, có cấu trúc, mô tả vấn đề người dùng đang gặp (chứ không phải giải pháp bạn muốn xây). Đây là điểm nhiều PM mới sai nhất: họ viết "Chúng ta cần xây nút thanh toán nhanh" — đó là giải pháp, không phải vấn đề. Vấn đề thực sự là "Người dùng bỏ giỏ hàng vì quy trình checkout quá nhiều bước."
Một Problem Statement tốt luôn trung lập về giải pháp (solution-agnostic). Nó mở ra không gian để team brainstorm nhiều cách giải, thay vì khóa cứng vào một hướng ngay từ đầu.
Định dạng 1 câu (one-sentence)
Định dạng này nén toàn bộ vấn đề vào một câu duy nhất theo công thức:
> "[Đối tượng người dùng] muốn [kết quả mong muốn — outcome] nhưng gặp [trở ngại — obstacle] dẫn đến [hệ quả — consequence]."
Bốn thành phần này không phải ngẫu nhiên:
- Người dùng: cụ thể hóa ai đang khổ. "Gen Z buyers" sắc hơn "người dùng".
- Outcome: điều họ thực sự muốn đạt được (job-to-be-done), không phải tính năng.
- Obstacle: cái gì đang chặn họ. Đây là chỗ chứa "nỗi đau".
- Consequence: tại sao việc này quan trọng — thường gắn với business impact hoặc cảm xúc tiêu cực.
> "Gen Z buyers muốn chốt đơn ngay trong buổi livestream nhưng phải rời app để sang trang checkout riêng, dẫn đến 40% bỏ giỏ và mất doanh thu impulse-buy."
Một câu, nhưng có đủ ai, muốn gì, vướng gì, mất gì. Đó là sức mạnh của định dạng 1 câu.
Định dạng 1 đoạn (one-paragraph)
Khi vấn đề phức tạp hơn — nhiều nhóm người dùng, có dữ liệu định lượng cần trình bày, hoặc bối cảnh thị trường phải giải thích — bạn cần một đoạn văn 3–6 câu. Cấu trúc gợi ý:
- Câu chủ đề: nêu vấn đề cốt lõi (gần giống định dạng 1 câu).
- Câu bằng chứng: số liệu, dữ liệu hành vi, hoặc trích dẫn người dùng chứng minh vấn đề có thật và đủ lớn.
- Câu bối cảnh: tại sao vấn đề tồn tại, hoặc tại sao bây giờ mới giải (why now).
- Câu hệ quả/stakes: nếu không giải thì sao; cơ hội bị bỏ lỡ là gì.
Khi nào dùng 1 câu, khi nào dùng 1 đoạn?
Đây là phần quan trọng nhất của bài. Quy tắc thực dụng:
Dùng 1 câu khi:
- Bạn viết One-pager hoặc tài liệu cần được lãnh đạo lướt nhanh.
- Vấn đề đã rõ ràng, được team đồng thuận từ trước.
- Bạn đặt nó làm câu mở đầu (TL;DR) cho một đoạn dài hơn bên dưới.
- Đối tượng người dùng và nỗi đau đơn giản, một chiều.
- Vấn đề cần thuyết phục stakeholder hoài nghi — bạn cần dữ liệu.
- Có nhiều nhóm người dùng hoặc nhiều khía cạnh của nỗi đau.
- Yếu tố "why now" quan trọng (thị trường thay đổi, đối thủ mới, quy định mới).
- Đây là PRD đầy đủ cho một initiative lớn cần đầu tư nhiều quý.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán giao hàng siêu tốc
Bối cảnh: Đội PM của một sàn thương mại điện tử Việt Nam (gọi là TikiNow để minh họa) muốn đề xuất tính năng "đặt lại đơn cũ trong 2 chạm". Bạn PM mới viết Problem Statement đầu tiên như sau:
> "Chúng tôi muốn xây tính năng reorder để khách mua lại nhanh hơn vì hiện tại họ phải tìm lại sản phẩm rất mất công và điều này không tốt cho trải nghiệm."
Vấn đề: đây là giải pháp ("xây tính năng reorder"), người dùng mơ hồ ("khách"), không có số liệu, và "không tốt cho trải nghiệm" thì chung chung vô nghĩa.
Sau khi áp dụng định dạng 1 câu, bản viết lại:
> "Khách hàng mua hàng tiêu dùng định kỳ (sữa, tã, đồ vệ sinh) muốn đặt lại đúng đơn hàng cũ trong vài giây, nhưng hiện phải tìm kiếm và thêm lại từng món thủ công, dẫn đến trung bình 7 thao tác mỗi lần và 28% khách bỏ giữa chừng theo dữ liệu funnel quý 1."
Diễn giải: Câu này đã cụ thể nhóm người dùng (mua hàng định kỳ), nêu outcome (đặt lại đơn cũ trong vài giây), obstacle (tìm và thêm thủ công), và consequence có số (7 thao tác, 28% rớt).
Bài học rút ra: Khi nâng cấp từ giải pháp sang vấn đề, và thêm con số cụ thể, Problem Statement lập tức có sức nặng để phê duyệt. Lãnh đạo không cần đọc thêm gì cũng hiểu vì sao đáng làm.
Ví dụ 2 — Một fintech Đông Nam Á và phần "why now"
Bối cảnh: Một ví điện tử ở Đông Nam Á (giả định tên MoMoPay) muốn ra mắt tính năng "trả góp khi mua" (BNPL — Buy Now Pay Later). PM cần thuyết phục ban lãnh đạo đầu tư lớn, đối mặt với rủi ro tín dụng và pháp lý. Ở đây dùng định dạng 1 đoạn là bắt buộc, vì cần dữ liệu và "why now":
> "Người dùng trẻ 22–30 tuổi của chúng ta muốn mua các món giá trị 2–10 triệu đồng (điện thoại, đồ gia dụng) nhưng không đủ tiền mặt một lần và ngại mở thẻ tín dụng vì thủ tục ngân hàng phức tạp. Khảo sát 1.200 người dùng cho thấy 61% đã hoãn ít nhất một giao dịch lớn trong 3 tháng qua vì lý do dòng tiền, và 44% nói sẽ chi nhiều hơn nếu được trả góp ngay trong app. Thị trường BNPL khu vực đang tăng trưởng 35%/năm và hai đối thủ trực tiếp vừa ra mắt tính năng tương tự trong quý vừa rồi. Nếu không hành động trong 6 tháng tới, chúng ta có nguy cơ mất nhóm khách hàng có giá trị vòng đời cao nhất vào tay đối thủ."
Diễn giải: Đoạn này có đủ bốn lớp — câu chủ đề (muốn mua trả góp, ngại thẻ tín dụng), câu bằng chứng (61%, 44%), câu bối cảnh/why now (thị trường tăng 35%, đối thủ vừa ra mắt), và câu stakes (mất khách giá trị cao).
Bài học rút ra: Khi vấn đề gắn với đầu tư lớn, rủi ro, và yếu tố thời điểm, một câu là không đủ. Đoạn văn cho bạn không gian chứng minh "vấn đề có thật, đủ lớn, và bây giờ là lúc". Nhưng để ý: dù dài, đoạn vẫn không nhắc đến giải pháp cụ thể — không nói "xây màn hình BNPL với 3 kỳ hạn". Đó là việc của phần Solution sau này.
Ví dụ 3 — Khi viết quá dài giết chết tài liệu
Bối cảnh: Một startup SaaS B2B Việt Nam làm phần mềm quản lý kho. PM viết Problem Statement dài tới 4 đoạn, mỗi đoạn 8–10 câu, kể lể lịch sử ngành logistics, trích dẫn 5 báo cáo McKinsey, và mô tả chi tiết 6 persona khác nhau. Khi đưa vào cuộc họp review, giám đốc sản phẩm đọc nửa trang thì dừng lại hỏi: "Vậy rốt cuộc vấn đề số một chúng ta giải là gì?" — và không ai trong phòng trả lời thống nhất được.
PM về viết lại, nén thành một dòng TL;DR in đậm cộng một đoạn:
> Quản lý kho ở doanh nghiệp vừa (50–200 nhân sự) mất trung bình 4 giờ mỗi ngày đối soát tồn kho thủ công qua Excel, dẫn đến sai số tồn kho 12% và thất thoát doanh thu do hết hàng đột ngột. > > Trong 18 cuộc phỏng vấn với thủ kho và quản lý vận hành, 15 người mô tả việc đối soát cuối ngày là "ác mộng" và cho biết họ không tin con số trên Excel. Các giải pháp ERP hiện có quá đắt và phức tạp cho quy mô của họ, nên họ chấp nhận sống chung với sai số. Đây là nhóm chưa được phục vụ đúng (underserved) và đang tăng nhanh khi làn sóng số hóa SME lan rộng sau 2023.
Diễn giải: Cùng một lượng nghiên cứu, nhưng giờ được nén lại. Dòng TL;DR trả lời ngay câu hỏi "vấn đề số một là gì". Đoạn dưới cung cấp bằng chứng và bối cảnh. Bốn đoạn lịch sử ngành kia? Chuyển xuống phần Context/Background (sẽ học ở Bài 12) hoặc phụ lục.
Bài học rút ra: Dài không có nghĩa là sâu. Một Problem Statement bị phình to thường che giấu việc PM chưa thực sự xác định được vấn đề cốt lõi. Nếu bạn không nén được vào một dòng, có thể bạn chưa hiểu vấn đề đủ rõ.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay cho PRD tiếp theo:
Bước 1 — Viết phiên bản 1 câu trước, luôn luôn. Dù cuối cùng bạn dùng đoạn văn, hãy bắt đầu bằng việc ép mình nén vào công thức "[Người dùng] muốn [outcome] nhưng gặp [obstacle] dẫn đến [consequence]." Nếu không viết nổi câu này, bạn chưa sẵn sàng viết PRD.
Bước 2 — Kiểm tra tính trung lập với giải pháp. Đọc lại câu vừa viết. Nó có chứa tên tính năng, công nghệ, hay màn hình cụ thể không? Nếu có, gỡ ra. Problem Statement chỉ nói về nỗi đau, không nói cách chữa.
Bước 3 — Gắn ít nhất một con số. "Nhiều người bỏ giỏ hàng" yếu hơn "40% bỏ giỏ". Nếu chưa có số, ghi rõ giả định cần kiểm chứng — điều đó trung thực hơn là phóng đại.
Bước 4 — Quyết định độ dài bằng đối tượng đọc. Hỏi: ai đọc tài liệu này và họ cần gì để gật đầu? Lãnh đạo lướt nhanh → ưu tiên 1 câu. Stakeholder hoài nghi cần thuyết phục → 1 đoạn có dữ liệu. Initiative lớn nhiều quý → đoạn có "why now".
Bước 5 — Nếu chọn đoạn, dùng cấu trúc 4 lớp. Câu chủ đề → bằng chứng → bối cảnh/why now → stakes. Mỗi câu một nhiệm vụ. Đừng để hai câu nói cùng một ý.
Bước 6 — Áp dụng "cả hai" khi nghi ngờ. Đặt câu 1-dòng in đậm làm TL;DR, rồi đoạn văn bên dưới. Bạn không cần chọn — bạn phục vụ cả người đọc vội lẫn người đọc kỹ.
Bước 7 — Test với người ngoài. Đưa Problem Statement cho một đồng nghiệp không trong dự án đọc trong 30 giây, rồi hỏi: "Vấn đề là gì và ai đang gặp?" Nếu họ trả lời đúng, bạn thành công. Nếu họ ngập ngừng, viết lại.
Lỗi thường gặp & mẹo
Lỗi 1: Nhồi giải pháp vào Problem Statement. "Người dùng cần một chatbot AI để..." — sai. Chatbot là giải pháp. Hãy hỏi: nếu bỏ tên giải pháp đi, nỗi đau còn lại là gì?
Lỗi 2: Người dùng quá mơ hồ. "Người dùng", "khách hàng", "mọi người" — đều yếu. Càng cụ thể nhóm người càng tốt: "thủ kho ở doanh nghiệp 50–200 nhân sự", "người bán livestream trên TikTok Shop".
Lỗi 3: Thiếu hệ quả (consequence). Nếu chỉ có "người dùng muốn X nhưng vướng Y" mà không nói "dẫn đến Z", người đọc không thấy được mức độ quan trọng. Z là chỗ chứa business impact.
Lỗi 4: Viết dài vì sợ thiếu, không vì cần đủ. Mỗi câu thêm vào phải trả lời được câu hỏi "câu này giúp người đọc hiểu vấn đề rõ hơn hay chỉ thêm chữ?". Nếu là vế sau, cắt.
Lỗi 5: Số liệu không nguồn. "70% người dùng gặp vấn đề này" mà không nói lấy từ đâu sẽ bị nghi ngờ. Ghi rõ: "theo dữ liệu funnel quý 1" hoặc "qua 18 cuộc phỏng vấn".
Mẹo 1 — Phép thử "so what": Sau mỗi câu, tự hỏi "so what — rồi sao?". Nếu không trả lời được, câu đó thừa.
Mẹo 2 — Đọc to lên. Problem Statement 1 câu nên đọc trôi trong một hơi thở. Nếu bạn hụt hơi, câu quá dài và cần tách hoặc nén.
Mẹo 3 — Bắt đầu bằng động từ "muốn". Công thức "[ai] muốn [gì]" buộc bạn đứng ở góc nhìn người dùng, tránh sa vào góc nhìn nội bộ công ty.
Bài tập thực hành
Bài 1 — Nén thành 1 câu. Lấy một tính năng bạn đang làm (hoặc một app bạn dùng hằng ngày) và viết Problem Statement theo đúng công thức: "[Người dùng cụ thể] muốn [outcome] nhưng gặp [obstacle] dẫn đến [consequence có số]." Yêu cầu: không được nhắc tên giải pháp, phải có ít nhất một con số (giả định cũng được).
Bài 2 — Mở rộng thành 1 đoạn. Lấy câu ở Bài 1, mở rộng thành đoạn 4 câu theo cấu trúc: câu chủ đề → câu bằng chứng → câu why now → câu stakes. Sau đó tự hỏi: đoạn này có thực sự cần thiết hơn câu đơn không, hay bạn đang viết dài cho có?
Bài 3 — Cắt gọt. Tìm một Problem Statement dài (trong PRD cũ của bạn, hoặc tự viết một đoạn 8 câu lan man). Cắt nó xuống còn 1 dòng TL;DR in đậm + 1 đoạn 4 câu. Ghi lại bạn đã bỏ những gì và tại sao chúng không thuộc về Problem Statement.
Bài 4 — Phép thử người ngoài. Đưa cả hai phiên bản (1 câu và 1 đoạn) cho một người bạn không làm sản phẩm. Hỏi họ vấn đề là gì sau 30 giây đọc. Ghi lại phiên bản nào giúp họ hiểu nhanh hơn — và rút ra kết luận cho riêng bạn về việc khi nào nên dùng định dạng nào.
Tóm tắt
Problem Statement là phần đắt giá nhất của mọi tài liệu sản phẩm vì nó trả lời câu hỏi "tại sao". Bạn có hai định dạng chính:
- 1 câu theo công thức "[Người dùng] muốn [outcome] nhưng gặp [obstacle] dẫn đến [consequence]" — dùng cho one-pager, TL;DR, vấn đề đã rõ, người đọc lướt nhanh.
- 1 đoạn với cấu trúc 4 lớp (chủ đề → bằng chứng → bối cảnh/why now → stakes) — dùng khi cần thuyết phục bằng dữ liệu, có nhiều nhóm người dùng, hoặc đầu tư lớn cần "why now".
Và mẹo vàng: khi phân vân, hãy viết cả hai — câu 1-dòng in đậm làm TL;DR, đoạn văn bên dưới để giải thích. Bạn phục vụ được cả người đọc vội lẫn người đọc kỹ, và đó là dấu hiệu của một PM viết tài liệu chuyên nghiệp.