Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà tôi luôn hỏi mỗi PM khi review PRD của họ: "Anh/chị muốn tài liệu này thành công bằng cách nào — và quan trọng hơn, anh/chị sẵn sàng KHÔNG làm gì để đạt được điều đó?". Câu hỏi thứ hai mới là câu khiến đa số PM lúng túng.
Trong các bài trước, bạn đã học cách viết phần Problem cho sắc bén. Nhưng một vấn đề được mô tả hay đến đâu cũng vô nghĩa nếu cả team không thống nhất được: chúng ta đang nhắm tới kết quả gì, và đâu là ranh giới của phiên bản này. Đó chính là vai trò của hai mục Goals và Non-goals.
Goals trả lời câu hỏi "thành công trông như thế nào". Non-goals trả lời câu hỏi "những gì chúng ta CỐ TÌNH không làm trong phạm vi này". Hầu hết PRD bị từ chối hoặc bị kéo dài vô tận không phải vì thiếu Goals — mà vì thiếu Non-goals. Khi không có Non-goals, scope của dự án sẽ phình ra như bột nở: mỗi stakeholder thêm một ý, mỗi cuộc họp đẻ thêm một feature, và rồi cái gọi là "MVP" trở thành con quái vật ngốn sáu tháng phát triển.
Bài này sẽ dạy bạn cách viết Goals theo chuẩn SMART để mỗi mục tiêu đều đo đếm được, và cách viết Non-goals đủ dứt khoát để bảo vệ team khỏi scope creep. Đây là kỹ năng tạo nên khác biệt giữa một PM "viết tài liệu" và một PM "lái được dự án".
Khái niệm cốt lõi
Goals là gì — và không phải là gì
Goals là tập hợp các kết quả (outcomes) mà tính năng này hướng tới, được diễn đạt dưới dạng đo lường được. Điểm mấu chốt mà nhiều PM nhầm: Goals không phải là danh sách việc cần làm (output), mà là kết quả mong muốn (outcome).
So sánh nhanh:
- Sai (output): "Xây dựng màn hình thanh toán mới." → Đây là việc làm, không phải mục tiêu.
- Đúng (outcome): "Tăng tỉ lệ hoàn tất thanh toán từ 62% lên 75% trong vòng 8 tuần sau khi ra mắt."
Goals chuẩn SMART
Một Goal tốt nên thỏa năm tiêu chí SMART. Tôi sẽ giải thích từng chữ kèm cách áp dụng thực tế:
- Specific (Cụ thể) — Mục tiêu phải chỉ rõ feature hoặc metric nào đang được nói tới, cho đối tượng người dùng nào. "Cải thiện trải nghiệm" là khẩu hiệu, không phải goal. "Giảm thời gian tìm kiếm sản phẩm cho người dùng mới trên app" mới là cụ thể.
- Measurable (Đo được) — Phải có con số. Nếu không gắn được một con số (tỉ lệ phần trăm, thời gian, số lượng, doanh thu), thì đó chưa phải Goal — đó là nguyện vọng. Con số này về sau chính là metric bạn sẽ theo dõi (bạn sẽ học sâu hơn về metric ở các bài về analytics và counter-metrics).
- Achievable (Khả thi) — Mục tiêu phải thực tế với nguồn lực và thời gian hiện có. Đặt mục tiêu tăng conversion từ 2% lên 20% trong một sprint là cách nhanh nhất để mất uy tín. Hãy dựa vào baseline hiện tại và mức cải thiện hợp lý.
- Relevant (Liên quan) — Mục tiêu phải kết nối với chiến lược lớn của công ty hoặc OKR của team. Một goal đẹp nhưng không phục vụ ưu tiên kinh doanh nào sẽ khó được duyệt ngân sách.
- Time-bound (Có thời hạn) — Phải có mốc thời gian để đánh giá. "Tăng retention" khác hẳn "tăng D7 retention thêm 5 điểm phần trăm trong quý 3".
Ví dụ: "Tăng tỉ lệ người dùng kích hoạt ví điện tử (activate) từ 40% lên 55% trong 6 tuần đầu sau ra mắt, áp dụng cho người dùng đăng ký mới."
Non-goals là gì — và vì sao nó quý hơn vàng
Non-goals là danh sách những thứ mà bạn chủ động quyết định không làm trong phạm vi của PRD này. Lưu ý từ "chủ động" — Non-goals không phải là những thứ bạn quên, mà là những thứ bạn đã cân nhắc và quyết định để lại.
Non-goals phục vụ ba mục đích cực kỳ thực tế:
- Chặn scope creep. Khi một stakeholder trong họp đề xuất "thêm cả tính năng chia hóa đơn nhóm vào luôn", bạn chỉ cần chỉ vào mục Non-goals: "Chia hóa đơn nhóm là non-goal của v1, đã thống nhất, sẽ cân nhắc ở v2". Tài liệu trở thành lá chắn.
- Làm rõ kỳ vọng. Engineer, designer, QA đọc Non-goals để biết họ KHÔNG cần thiết kế cho trường hợp đó, không cần test cho luồng đó. Tiết kiệm hàng chục giờ.
- Ghi lại quyết định. Sáu tháng sau khi có người hỏi "sao hồi đó không làm cái X?", Non-goals chính là biên bản giải thích lý do.
- Yếu: "Không hỗ trợ desktop."
- Mạnh: "Không hỗ trợ phiên bản desktop trong v1 — 88% người dùng mục tiêu truy cập qua mobile, desktop sẽ làm tăng gấp đôi effort testing mà phục vụ thiểu số."
Phân biệt Non-goals với các khái niệm dễ nhầm
Đây là phần nhiều PM hay sai:
- Non-goal KHÔNG phải là Out-of-scope kỹ thuật. Out-of-scope thường là chi tiết triển khai ("không refactor module thanh toán"). Non-goal nói về kết quả/giá trị mà ta cố tình không theo đuổi.
- Non-goal KHÔNG phải là "Future work". Future work là kế hoạch tương lai có chủ đích sẽ làm. Non-goal là tuyên bố "không phải bây giờ, và có thể không bao giờ". Hai cái có thể giao nhau nhưng không đồng nhất.
- Non-goal KHÔNG phải là Risk. Risk là điều xấu có thể xảy ra ngoài ý muốn; Non-goal là lựa chọn có chủ ý.
Tình huống thực tế
Ví dụ 1 — MoMo và tính năng "Túi Thần Tài" (bối cảnh giả định hợp lý)
Hình dung một team tại một ví điện tử lớn ở Việt Nam (lấy cảm hứng từ mô hình MoMo) đang xây tính năng "túi tiết kiệm tự động" — mỗi khi người dùng chi tiêu, hệ thống làm tròn lên và bỏ phần lẻ vào túi tiết kiệm.
PM ban đầu viết Goals như sau: "Ra mắt tính năng túi tiết kiệm cho người dùng." Khi tôi review, tôi gạch ngay — đây là output. Sau khi sửa, Goals trở thành:
- Tăng tỉ lệ người dùng có ít nhất một sản phẩm tiết kiệm từ 12% lên 20% trong 12 tuần.
- Đạt số dư tiết kiệm trung bình 150.000đ/người dùng kích hoạt trong 90 ngày đầu.
- "Không hỗ trợ rút tiền tức thời từ túi tiết kiệm trong v1 — cần tích hợp luồng giải ngân phức tạp, để v2."
- "Không tính lãi suất cho số dư túi — đây là tính năng thói quen, không phải sản phẩm tài chính có lãi; tránh được rủi ro pháp lý với Ngân hàng Nhà nước."
Ví dụ 2 — Tiki và tính năng đánh giá có ảnh
Một team thương mại điện tử (bối cảnh kiểu Tiki) muốn cho phép người mua đính kèm ảnh khi viết đánh giá sản phẩm, nhằm tăng độ tin cậy.
Goals được viết chuẩn SMART:
- Tăng tỉ lệ review có đính kèm ảnh từ 8% lên 25% trong 8 tuần.
- Tăng conversion của các sản phẩm có ít nhất 3 review-có-ảnh thêm 4 điểm phần trăm so với nhóm đối chứng.
- "Không hỗ trợ video trong v1 — chi phí lưu trữ và kiểm duyệt cao gấp nhiều lần ảnh."
- "Không xây hệ thống kiểm duyệt ảnh tự động bằng AI ở giai đoạn này — dùng kiểm duyệt thủ công cho 1.000 review đầu để học pattern trước."
- "Không cho phép chỉnh sửa/xóa ảnh sau khi đăng trong v1."
Bài học: Non-goal có lý do đi kèm biến mọi cuộc tranh cãi scope từ "ai to tiếng hơn" thành "ai có lập luận tốt hơn". Đó là quyền lực thầm lặng của PM.
Ví dụ 3 — Một startup giao đồ ăn đặt Goal bất khả thi
Một startup giao đồ ăn ở khu vực Đông Nam Á (bối cảnh giả định) đặt Goal cho tính năng đặt món theo nhóm: "Tăng giá trị đơn hàng trung bình (AOV) gấp đôi trong 4 tuần."
Khi tôi nhìn baseline, AOV hiện tại là 95.000đ, và mức tăng lịch sử tốt nhất của bất kỳ tính năng nào cũng chỉ 8-12%. Goal "gấp đôi trong 4 tuần" vi phạm chữ A (Achievable) và T hợp lý. Hậu quả: sau 4 tuần, AOV tăng 15% — một kết quả thực ra rất tốt — nhưng vì đặt mục tiêu phi lý, cả team bị coi là "thất bại", tinh thần đi xuống, và lãnh đạo nghi ngờ năng lực.
Chúng tôi sửa lại: "Tăng AOV của các đơn đặt theo nhóm thêm 18% so với baseline 95.000đ trong 8 tuần, đo trên nhóm người dùng tham gia tính năng."
Bài học: Một Goal phi thực tế còn nguy hiểm hơn không có Goal. Nó biến thành công thực sự thành thất bại trên giấy. Hãy luôn neo Goal vào baseline và lịch sử cải thiện của sản phẩm.
Hướng dẫn từng bước
Đây là quy trình tôi dùng để viết mục Goals & Non-goals cho mọi PRD:
Bước 1 — Liên kết ngược với Problem. Mở lại phần Problem bạn đã viết. Mỗi Goal phải là lời đáp đo lường được cho vấn đề đó. Nếu một Goal không gắn với Problem nào, hoặc bỏ nó, hoặc xem lại Problem.
Bước 2 — Viết nháp Goals dưới dạng outcome. Với mỗi Goal, hỏi "đây là việc làm hay là kết quả?". Nếu thấy động từ "xây dựng", "thiết kế", "tích hợp" — đó là output, hãy viết lại thành kết quả người dùng/kinh doanh.
Bước 3 — Gắn con số và baseline. Tra dữ liệu hiện tại. Mỗi Goal cần dạng "từ X → Y trong khoảng thời gian Z". Không có baseline thì ghi rõ "baseline đang đo, cập nhật trước launch".
Bước 4 — Kiểm tra SMART từng dòng. Đọc lại mỗi Goal qua bộ lọc 5 chữ. Đặc biệt soi chữ A: hỏi engineer và data analyst xem mục tiêu có khả thi không.
Bước 5 — Giới hạn số lượng Goals. Một PRD nên có 1-3 Goals chính. Nhiều hơn 3 nghĩa là dự án đang ôm đồm — đó là tín hiệu cần tách thành nhiều phase. Nếu buộc phải có nhiều, hãy đánh dấu Goal chính (primary) và Goal phụ (secondary).
Bước 6 — Brainstorm Non-goals. Đặt câu hỏi: "Stakeholder nào có thể đòi thêm gì? Phiên bản 'hoàn hảo' sẽ có gì mà bản này không có?". Liệt kê hết, rồi chọn ra những thứ dễ bị hiểu nhầm là 'đương nhiên phải có' để đưa vào Non-goals.
Bước 7 — Viết Non-goals kèm lý do. Mỗi Non-goal một dòng, theo mẫu "Không làm X — vì lý do Y (chi phí / rủi ro / ưu tiên / để dành cho phase sau)".
Bước 8 — Đối chiếu chéo. Đảm bảo không có Goal nào mâu thuẫn với Non-goal. Ví dụ Goal "tăng tương tác cộng đồng" mà Non-goal lại "không làm tính năng comment" thì phải xem lại logic.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết Goal là output. "Ra mắt tính năng X" không phải mục tiêu. Mẹo: luôn hỏi "rồi sao nữa? điều đó giúp người dùng/công ty đạt được gì?" cho đến khi chạm tới một con số.
Lỗi 2 — Goal không có con số. "Cải thiện hiệu suất" là khẩu hiệu. Mẹo: nếu không gắn được số ngay, ghi placeholder "[cần xác định baseline]" để buộc bản thân quay lại điền.
Lỗi 3 — Bỏ trống Non-goals. Đây là lỗi phổ biến nhất và tốn kém nhất. PRD không có Non-goals gần như chắc chắn sẽ bị scope creep. Mẹo: ép buộc bản thân viết tối thiểu 3 Non-goals cho mọi PRD.
Lỗi 4 — Non-goal không có lý do. Liệt kê suông khiến người đọc dễ chất vấn. Mẹo: mỗi Non-goal phải trả lời được câu "tại sao không?".
Lỗi 5 — Quá nhiều Goals. Năm, sáu mục tiêu ngang hàng nghĩa là không có mục tiêu nào. Mẹo: ép xuống tối đa 3, và chỉ định rõ đâu là primary.
Lỗi 6 — Goal phi thực tế. Như ví dụ startup giao đồ ăn. Mẹo: luôn neo vào baseline và lịch sử cải thiện; tham vấn data analyst trước khi chốt.
Mẹo nâng cao: Khi đàm phán scope với stakeholder, hãy dùng cặp Goals/Non-goals như một bàn cờ. Mỗi lần ai đó muốn thêm một Goal, hãy hỏi "vậy chúng ta đẩy cái gì xuống Non-goals để đổi lại?". Cách này biến cuộc họp scope thành trò chơi tổng-bằng-không có kỷ luật, thay vì cái túi không đáy.
Bài tập thực hành
Hãy chọn 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 giả định: "thêm tính năng lưu giỏ hàng cho lần sau trên một app mua sắm").
- Viết 2-3 Goals theo chuẩn SMART. Mỗi Goal phải có: động từ chỉ hướng, metric cụ thể, baseline → mục tiêu, khung thời gian, nhóm người dùng. Sau khi viết, tự chấm từng Goal qua 5 chữ SMART — đánh dấu chữ nào còn yếu.
- Phân loại lại. Đọc từng Goal và tự hỏi: "Đây là output hay outcome?". Viết lại bất kỳ Goal nào còn là output thành outcome.
- Liệt kê tối thiểu 4 Non-goals. Mỗi cái kèm một dòng lý do (chi phí / rủi ro / ưu tiên / để dành phase sau). Cố tìm ít nhất một Non-goal thuộc loại "thứ mà người ta tưởng đương nhiên phải có" — đó thường là Non-goal giá trị nhất.
- Stress-test. Tưởng tượng một stakeholder muốn nhồi thêm tính năng. Viết một câu phản biện dựa trên Non-goals của bạn. Nếu không phản biện nổi, Non-goals của bạn chưa đủ rõ — hãy bổ sung.
Tóm tắt
- Goals = outcome đo được, không phải output (việc cần làm). Mỗi Goal nên thỏa SMART: Specific, Measurable, Achievable, Relevant, Time-bound.
- Dùng công thức: động từ chỉ hướng + metric + baseline → mục tiêu + khung thời gian + nhóm người dùng. Giới hạn 1-3 Goals, chỉ rõ primary.
- Non-goals = những thứ bạn chủ động quyết định không làm, mỗi cái kèm lý do. Đây là tấm khiên chống scope creep, công cụ làm rõ kỳ vọng và là biên bản ghi lại quyết định.
- Phân biệt Non-goals với out-of-scope kỹ thuật, future work và risk — chúng không đồng nhất.
- Goal phi thực tế còn nguy hiểm hơn không có Goal: nó biến thành công thật thành thất bại trên giấy. Luôn neo vào baseline.
- Mẹo quyền lực: trong họp scope, mỗi Goal thêm vào phải đánh đổi bằng một thứ đẩy xuống Non-goals.