Mở đầu — vì sao bài này quan trọng
Nếu bạn chỉ có thời gian viết tốt hai phần trong toàn bộ PRD, hãy chọn Problem và Goals. Đây là hai phần định đoạt số phận của tài liệu. Một problem statement mơ hồ sẽ kéo theo cả đội kỹ thuật và thiết kế đi sai hướng trong nhiều tuần; một mục goals không đo được sẽ khiến bạn không bao giờ biết tính năng của mình thành công hay thất bại.
Trong thực tế làm việc, tôi thấy đây cũng là nơi PM mắc lỗi nhiều nhất. Lý do rất con người: chúng ta thường đã có sẵn một giải pháp trong đầu trước khi thực sự hiểu vấn đề. Thế là phần "Problem" bị viết ngược — nó mô tả việc thiếu giải pháp thay vì mô tả nỗi đau của người dùng. Khi đó, cả đội mất đi cơ hội suy nghĩ ra phương án tốt hơn cái bạn đã tưởng tượng.
Bài này tập trung vào đúng một kỹ năng: viết phần Problem và Goals thật sắc bén. Bạn sẽ học cách tách bạch problem khỏi solution, cách đặt mục tiêu theo nguyên tắc SMART, và cách dùng counter-metrics để mục tiêu không bị "lách". Các phần khác của PRD như Context, Non-goals, hay Guardrails sẽ được đào sâu ở những bài riêng — ở đây ta chỉ chạm tới chúng vừa đủ để Problem và Goals đứng vững.
Khái niệm cốt lõi
Problem statement: mô tả nỗi đau, không mô tả giải pháp
Một problem statement tốt trả lời ba câu hỏi: Ai đang gặp khó khăn, khó khăn gì, và vì sao điều đó quan trọng (cho người dùng và cho doanh nghiệp). Nó tuyệt đối không chứa từ ngữ mô tả cách giải quyết.
Hãy nhìn sự khác biệt:
- ❌ "Chúng ta cần thêm nút lọc theo giá trên trang danh sách sản phẩm."
- ✅ "Người mua trên app đang phải cuộn qua trung bình 40 sản phẩm để tìm món trong tầm giá của họ. 28% phiên tìm kiếm kết thúc mà không xem chi tiết sản phẩm nào, cao hơn nhiều so với mức 12% của các phiên có dùng bộ lọc hiện có."
Mẹo kiểm tra nhanh: đọc problem statement của bạn và hỏi "Đây có phải là một sự thật về người dùng, hay là một ý tưởng của tôi?". Nếu trong câu có động từ chỉ hành động xây dựng ("thêm", "làm", "tích hợp", "xây"), gần như chắc chắn bạn đang viết solution.
Tách "triệu chứng" khỏi "nguyên nhân"
Nhiều problem statement dừng lại ở triệu chứng bề mặt: "tỷ lệ chuyển đổi giảm". Đó là một con số, chưa phải vấn đề. Hãy đào sâu thêm một, hai lớp bằng kỹ thuật hỏi "tại sao". Tỷ lệ chuyển đổi giảm — tại sao? Vì người dùng bỏ giỏ hàng ở bước thanh toán — tại sao? Vì họ phải nhập lại địa chỉ và phương thức thanh toán mỗi lần. Đến đây bạn đã có một vấn đề đủ cụ thể để hành động.
Đừng đào quá sâu đến mức triết lý ("vì con người vốn lười"), cũng đừng dừng quá nông. Mức "đủ" là khi vấn đề đã cụ thể tới mức nhiều giải pháp khả thi xuất hiện trong đầu bạn.
Goals: kết quả mong muốn, viết theo SMART
Goals là phần trả lời: "Nếu chúng ta giải quyết vấn đề này thành công thì điều gì sẽ thay đổi, và đo bằng cách nào?". Goals không phải danh sách việc cần làm (đó là scope), cũng không phải mô tả tính năng. Goals là kết quả đo lường được.
Nguyên tắc SMART giúp mục tiêu sắc bén:
- S – Specific (cụ thể): chỉ rõ chỉ số nào thay đổi, cho nhóm người dùng nào.
- M – Measurable (đo được): có con số, có cách thu thập dữ liệu.
- A – Achievable (khả thi): dựa trên baseline thực tế, không phải mơ ước.
- R – Relevant (liên quan): mục tiêu phải nối thẳng với problem statement.
- T – Time-bound (có mốc thời gian): đo trong bao lâu sau khi ra mắt.
- ❌ "Cải thiện trải nghiệm thanh toán."
- ✅ "Giảm tỷ lệ bỏ giỏ ở bước thanh toán từ 34% xuống dưới 25% cho người dùng đã đăng nhập, đo trong 4 tuần đầu sau khi ra mắt."
Counter-metrics: tấm khiên chống "thắng giả"
Đây là phần phân biệt PM giỏi với PM mới. Mỗi mục tiêu, khi bị tối ưu hết mức, đều có thể gây hại ở chỗ khác. Counter-metric (chỉ số đối trọng) là chỉ số bạn cam kết không làm xấu đi khi đuổi theo goal chính.
Ví dụ: goal của bạn là tăng tỷ lệ nhấp vào thông báo đẩy. Cách "thắng" rẻ tiền nhất là gửi thật nhiều thông báo và giật tít. Chỉ số nhấp sẽ tăng — nhưng người dùng tắt thông báo hàng loạt và gỡ app. Counter-metric ở đây có thể là: "tỷ lệ tắt nhận thông báo không tăng quá 2%" và "tỷ lệ gỡ app trong 7 ngày giữ nguyên". Counter-metric biến một mục tiêu một chiều thành một mục tiêu lành mạnh.
Lưu ý phạm vi: bài này chỉ giới thiệu counter-metric vừa đủ để gắn vào Goals. Cách thiết kế guardrail chi tiết và ngưỡng cảnh báo là chủ đề của một bài riêng sau này.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT giả định "ChợViệt": problem bị viết ngược
Một PM ở sàn thương mại điện tử giả định ChợViệt nhận yêu cầu từ sếp: "Đối thủ có tính năng live-stream bán hàng rồi, mình phải làm gấp." PM viết PRD với problem statement: "ChợViệt chưa có tính năng livestream, gây bất lợi cạnh tranh."
Diễn giải: Đây là problem viết ngược điển hình — nó mô tả việc thiếu một giải pháp, không phải nỗi đau người dùng. Khi mang lên review, một thành viên engineering hỏi đúng một câu: "Người mua của mình thực sự đang gặp khó khăn gì mà livestream giải quyết được?". Cả phòng im lặng. Sau khi đào dữ liệu, đội phát hiện vấn đề thật khác hẳn: 61% người mua nhắn tin hỏi shop "sản phẩm thật trông thế nào" trước khi đặt, và thời gian chờ shop trả lời trung bình là 3,5 giờ — nhiều người bỏ đi giữa chừng. Vấn đề thật là thiếu lòng tin vào hình ảnh sản phẩm và phản hồi quá chậm.
Bài học: Khi vấn đề được viết lại đúng, không gian giải pháp mở rộng. Livestream chỉ là một cách; video review ngắn của người mua trước, hay tính năng chat phản hồi nhanh, có thể rẻ hơn và hiệu quả hơn. Vấn đề đúng đáng giá hơn câu trả lời nhanh.
Ví dụ 2 — Ví điện tử "MoMo-style": goal SMART cứu một dự án
Một đội làm ví điện tử (lấy cảm hứng từ bối cảnh các ví Việt Nam) muốn tăng số người dùng liên kết tài khoản ngân hàng. PRD ban đầu đặt goal: "Khuyến khích nhiều người dùng liên kết ngân hàng hơn." Sau hai tháng, không ai trong đội đồng ý được với nhau là dự án thành công hay không, vì mỗi người nhìn một con số khác nhau.
Diễn giải: Họ viết lại goal theo SMART: "Tăng tỷ lệ người dùng mới hoàn tất liên kết ngân hàng trong 7 ngày đầu từ 22% lên 35%, đo trên nhóm đăng ký mới, trong 6 tuần sau ra mắt." Kèm theo là counter-metric quan trọng: "Tỷ lệ khiếu nại liên quan đến liên kết sai tài khoản không tăng" và "Tỷ lệ rớt ở bước xác thực OTP không xấu đi". Counter-metric thứ hai hóa ra cực kỳ giá trị: trong quá trình tối ưu, một phiên bản rút ngắn luồng đã đẩy tỷ lệ liên kết lên 38% nhưng làm tỷ lệ xác thực OTP thất bại tăng vọt vì bỏ qua một bước hướng dẫn. Nhờ counter-metric, đội phát hiện sớm và không "ăn mừng nhầm".
Bài học: SMART biến một mong muốn mơ hồ thành thước đo chung. Counter-metric đảm bảo thắng lợi là thật, không phải ảo giác do dịch chuyển vấn đề sang chỗ khác.
Ví dụ 3 — App giao đồ ăn khu vực Đông Nam Á: triệu chứng vs nguyên nhân
Một app giao đồ ăn (bối cảnh giả định kiểu Grab/ShopeeFood) thấy chỉ số "tỷ lệ đặt lại đơn trong 30 ngày" giảm. PM đầu tiên định nghĩa problem là: "Tỷ lệ giữ chân người dùng giảm." Đó là triệu chứng.
Diễn giải: Đào sâu bằng "tại sao", đội phát hiện phần lớn người rời đi là những người từng gặp đơn giao trễ hơn 45 phút trong lần đặt gần nhất. Vấn đề thật cụ thể hơn nhiều: trải nghiệm giao trễ ở lần đầu phá vỡ niềm tin và khiến người dùng không quay lại. Goal được viết: "Giảm tỷ lệ rời bỏ trong 30 ngày của nhóm gặp giao trễ ở đơn đầu tiên, từ 47% xuống 38%, đo trong quý tới." Vì problem đã chỉ rõ nhóm và nguyên nhân, goal trở nên sắc và khả thi thay vì chung chung.
Bài học: Đừng đặt goal trên triệu chứng. Đào xuống nguyên nhân trước, rồi goal gần như tự viết ra.
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:
- Viết một câu mô tả nỗi đau, không nhắc giải pháp. Cấu trúc gợi ý: "[Nhóm người dùng] đang [gặp khó khăn cụ thể] khi [bối cảnh], dẫn đến [hậu quả đo được]."
- Đào "tại sao" hai lần. Hỏi tại sao vấn đề tồn tại cho đến khi bạn chạm tới nguyên nhân có thể tác động được, chứ không phải triệu chứng bề mặt.
- Gắn dữ liệu vào. Tìm baseline: con số hiện tại đang là bao nhiêu? Nếu chưa có, đánh dấu là "cần đo" và đi tìm trước khi chốt goal.
- Kiểm tra "ngược": đọc lại problem và tự hỏi — nó có vô tình ép một giải pháp duy nhất không? Nếu có, viết lại trừu tượng hơn một bậc.
- Viết goal theo công thức "từ X đến Y, cho Z, trong T". Mỗi PRD nên có 1–3 goal chính, không nên nhiều hơn. Quá nhiều goal nghĩa là chưa rõ ưu tiên.
- Soi từng goal qua bộ lọc SMART. Thiếu chữ nào, bổ sung chữ đó.
- Thêm counter-metric cho mỗi goal chính. Hỏi: "Nếu ai đó tối ưu mù quáng goal này, họ sẽ phá hỏng điều gì?". Câu trả lời chính là counter-metric.
- Đọc to cả phần Problem và Goals cho một người không trong dự án. Nếu họ hiểu vấn đề và biết khi nào thì thành công, bạn đã viết tốt.
Lỗi thường gặp & mẹo
Lỗi 1 — Solution núp trong problem. Dấu hiệu: problem chứa tên tính năng hoặc động từ "thêm/làm/xây". Mẹo: gạch bỏ mọi danh từ chỉ giải pháp và viết lại bằng ngôn ngữ của người dùng.
Lỗi 2 — Goal không có con số. "Cải thiện", "tối ưu", "nâng cao" mà không kèm số là goal vô dụng. Mẹo: nếu chưa có baseline, ít nhất hãy ghi rõ chỉ số nào sẽ được đo và hứa bổ sung con số trước khi khởi công.
Lỗi 3 — Quá nhiều goal. Năm, sáu goal ngang hàng nghĩa là không có goal nào thật sự quan trọng. Mẹo: ép mình chọn một "north-star" duy nhất, các goal còn lại là phụ.
Lỗi 4 — Quên counter-metric. Hậu quả là tối ưu một chiều gây hại chỗ khác. Mẹo: với mỗi goal, viết kèm một câu "miễn là không làm xấu...".
Lỗi 5 — Goal thực ra là một feature trá hình. "Ra mắt màn hình onboarding mới" không phải goal, đó là việc cần làm. Mẹo: hỏi "ra mắt nó để đạt được kết quả gì?" — câu trả lời mới là goal.
Mẹo vàng: Problem và Goals phải khớp nhau như khóa với chìa. Đọc problem xong, người ta phải đoán được goal sẽ đo gì. Nếu goal đo một thứ chẳng liên quan tới problem, một trong hai phần đang sai.
Bài tập thực hành
Hãy lấy một tính năng bạn đang hoặc sắp làm (nếu chưa có, dùng tình huống: "app đọc sách điện tử muốn người dùng đọc nhiều hơn").
- Viết problem statement sai trước — cố tình nhét giải pháp vào. Sau đó viết lại thành phiên bản đúng, mô tả nỗi đau người dùng kèm ít nhất một con số (có thể giả định hợp lý).
- Đào "tại sao" hai lần cho vấn đề đó và ghi lại nguyên nhân gốc bạn tìm được.
- Viết một goal chính theo công thức "từ X đến Y, cho Z, trong T", và tự chấm điểm nó qua từng chữ trong SMART.
- Thêm một counter-metric cho goal đó, kèm câu giải thích: "Nếu ai đó tối ưu mù quáng goal này, họ sẽ phá hỏng ______."
- Đưa cả hai đoạn cho một người ngoài dự án đọc trong 60 giây và hỏi họ hai câu: "Vấn đề là gì?" và "Khi nào thì coi là thành công?". Nếu họ trả lời đúng, bạn đã đạt.
Tóm tắt
Problem và Goals là xương sống của mọi PRD. Problem phải mô tả nỗi đau của người dùng — ai, đau gì, vì sao quan trọng — và tuyệt đối không chứa giải pháp; hãy đào từ triệu chứng xuống nguyên nhân trước khi viết. Goals phải là kết quả đo được theo SMART, viết theo công thức "từ X đến Y, cho Z, trong T", và mỗi goal đi kèm một counter-metric để đảm bảo thắng lợi là thật chứ không phải ảo giác do đẩy vấn đề sang chỗ khác. Khi Problem và Goals khớp nhau như khóa với chìa, cả đội của bạn sẽ biết chính xác mình đang giải quyết điều gì và làm sao biết mình đã thành công.