Mở đầu — vì sao bài này quan trọng
Có một khoảnh khắc kinh điển trong vòng đời mọi feature: ba ngày trước ngày ship, một kỹ sư backend nhắn vào nhóm chat: "Khoan đã, vậy nếu user chưa verify email thì có cho đặt hàng không?" Im lặng. Rồi PM trả lời: "Ờ... cái này mình chưa nghĩ tới." Thế là cả team chậm một tuần.
Câu hỏi đó không phải tự nhiên sinh ra vào phút chót. Nó đã tồn tại ngay từ ngày PM viết PRD — chỉ là nó bị giấu kín dưới dạng một giả định ngầm mà không ai dám nói ra. Bài học hôm nay nói về một mục tưởng nhỏ nhưng cực kỳ quyền lực trong PRD: Open Questions (Những câu hỏi còn để mở).
Open Questions là nơi PM công khai thừa nhận: "Đây là những điều tôi CHƯA biết, CHƯA quyết, hoặc đang chờ người khác trả lời." Nghe có vẻ ngược đời — chẳng phải PM nên là người có câu trả lời sao? Nhưng một PM giỏi không phải người giả vờ biết hết. PM giỏi là người biết chính xác mình KHÔNG biết gì, và quản lý sự không chắc chắn đó một cách có kỷ luật để nó không nổ tung vào phút 89.
Trong bài này, chúng ta sẽ tập trung riêng vào cách quản lý mục Open Questions: vì sao phải viết nó ra một cách tường minh, format chuẩn để theo dõi, và đặc biệt là cách "đóng" từng câu hỏi để chúng không trở thành nợ kỹ thuật âm thầm. Đây không phải bài về cách viết Risk Register (sổ rủi ro — Bài 54), cũng không phải về Open Questions kiểu chiến lược trong Vision Doc. Đây là kỹ năng vận hành: biến một danh sách câu hỏi lộn xộn thành một công cụ điều phối quyết định.
Khái niệm cốt lõi
Open Questions là gì và không là gì
Open Question là một quyết định chưa được chốt mà việc chốt nó sẽ ảnh hưởng đến cách team xây dựng sản phẩm. Phân biệt rõ:
- Open Question không phải là rủi ro (risk). Rủi ro là "điều xấu có thể xảy ra" (ví dụ: "API của đối tác có thể downtime"). Open Question là "điều ta cần ai đó quyết" (ví dụ: "Khi đối tác downtime, ta hiển thị lỗi hay cache giá cũ?").
- Open Question không phải là task. Task là việc cần làm và đã rõ phải làm gì. Open Question là chỗ chưa rõ phải làm gì.
- Open Question không phải là FAQ. FAQ giải thích những điều đã quyết cho người đọc. Open Question là những điều CHƯA quyết.
Vì sao phải viết tường minh (explicit)
Đây là phần cốt lõi nhất. Có ba lý do khiến việc viết Open Questions ra giấy trắng mực đen quan trọng hơn nhiều so với việc giữ chúng trong đầu.
Thứ nhất: ép PM thừa nhận sự không chắc chắn. Bộ não con người rất giỏi tự lừa dối. Khi viết PRD, ta có xu hướng lướt qua những chỗ mơ hồ với câu thần chú "tí nữa tính sau". Nhưng "tí nữa" thường biến mất. Khi buộc bản thân gõ ra dòng chữ "Câu hỏi: User chưa verify email có được đặt hàng không?", ta không thể trốn nó nữa. Việc viết ra là hành động thừa nhận có chủ đích — nó chuyển một nỗi lo mơ hồ thành một mục công việc cụ thể.
Thứ hai: crowdsource câu trả lời từ reviewer. Một PRD tốt được nhiều người đọc: kỹ sư, designer, legal, data, CS. Mỗi người nhìn từ một góc khác nhau. Khi bạn viết "Open Question: GrabFood có cho phép tip tài xế bằng số âm để hoàn tiền không?", có thể một bạn kỹ sư đã từng làm hệ thống thanh toán sẽ trả lời ngay: "Không, vì cổng VNPay không hỗ trợ giao dịch âm, phải tách thành refund riêng." Bạn vừa tiết kiệm hai ngày nghiên cứu chỉ bằng cách hỏi đúng chỗ. Open Questions biến PRD từ một văn bản một chiều thành một cuộc đối thoại.
Thứ ba: tránh bất ngờ vào cuối chu kỳ. Đây là giá trị lớn nhất. Mọi câu hỏi không được trả lời sớm sẽ quay lại đòi nợ — và càng muộn càng đắt. Một câu hỏi được trả lời ở giai đoạn viết PRD tốn 5 phút. Cũng câu hỏi đó nếu lòi ra khi code đã viết xong có thể tốn cả sprint để làm lại. Open Questions là một cơ chế "đẩy chi phí về phía trước" (front-loading): trả giá rẻ bây giờ để khỏi trả giá đắt sau.
Cấu trúc của một Open Question tốt
Một câu hỏi để mở chỉ có giá trị khi nó đủ thông tin để ai đó trả lời và đóng lại. Một bảng Open Questions chuẩn nên có các cột sau:
| # | Câu hỏi | Owner (người chịu trách nhiệm chốt) | Hạn cần trả lời | Trạng thái | Quyết định cuối / Ghi chú |
|---|
- Owner: không phải "ai biết câu trả lời" mà là "ai chịu trách nhiệm đảm bảo câu hỏi này được chốt". Một câu hỏi không có owner là một câu hỏi sẽ không bao giờ được trả lời.
- Hạn (deadline): mỗi câu hỏi phải có thời điểm cần chốt, thường gắn với một mốc (trước khi eng bắt đầu code phần X, trước design review...). Câu hỏi không deadline sẽ trôi.
- Trạng thái: Open / Đang thảo luận / Đã chốt / Hoãn (defer sang phiên bản sau). Trạng thái cho phép quét nhanh xem còn bao nhiêu nợ chưa trả.
- Quyết định cuối: khi đóng câu hỏi, ghi rõ quyết định và lý do ngay tại đó. Đây là vàng cho người đọc PRD ba tháng sau hỏi "vì sao hồi đó mình chọn thế này".
Tình huống thực tế
Ví dụ 1 — Tiki và câu hỏi về "giỏ hàng của khách vãng lai"
Một PM tại một sàn thương mại điện tử lớn ở Việt Nam (gọi là sàn X cho gần với bối cảnh Tiki/Shopee) viết PRD cho tính năng "Mua nhanh không cần đăng nhập". Trong lúc viết, cô liệt kê 6 Open Questions, trong đó có một câu tưởng vô hại: "Giỏ hàng của khách vãng lai (guest) lưu được bao lâu? Khi guest đăng nhập, có merge giỏ hàng cũ không?"
Cô gán owner là chính mình, deadline trước khi eng bắt đầu. Khi gửi PRD cho review, bạn lead backend trả lời ngay dưới câu hỏi: "Nếu merge giỏ hàng, ta phải xử lý conflict khi cùng SKU — guest đã có 2 sản phẩm, tài khoản cũ đã có 3. Cộng dồn hay ghi đè? Cái này ảnh hưởng schema, cần chốt trước." Một bạn data thì thêm: "Cẩn thận, nếu lưu giỏ guest 30 ngày bằng cookie, ta đụng quy định lưu trữ dữ liệu cá nhân theo Nghị định 13."
Diễn giải: Một câu hỏi đơn giản đã kéo theo hai hệ quả lớn — một về kỹ thuật (conflict resolution) và một về pháp lý (Nghị định 13 về bảo vệ dữ liệu cá nhân). Nhờ viết ra sớm, cả hai được giải quyết trên giấy trong hai ngày. PM chốt: merge bằng cách cộng dồn, cap giỏ guest ở 7 ngày để giảm rủi ro pháp lý, và ghi rõ quyết định ngay trong bảng.
Bài học: Open Questions giỏi nhất ở chỗ một câu hỏi thường mở khóa những câu hỏi ẩn khác. Nếu cô giữ câu hỏi này trong đầu, nhiều khả năng nó lòi ra khi eng đã code xong phần guest checkout và phải đập đi làm lại schema.
Ví dụ 2 — Startup fintech và câu hỏi không có owner
Một startup ví điện tử ở Đông Nam Á (tương tự MoMo/ZaloPay quy mô nhỏ) làm tính năng "Chia hóa đơn nhóm". PM viết PRD khá tốt, có hẳn mục Open Questions với 8 câu hỏi. Nhưng có một vấn đề: cả 8 câu đều để trống cột Owner, và không câu nào có deadline.
Kết quả: PRD được "approve", team bắt đầu code. Đến tuần thứ ba, câu hỏi số 5 — "Nếu một thành viên trong nhóm chưa có ví, họ nhận yêu cầu chia tiền qua đâu? SMS hay link?" — bất ngờ trở thành điểm nghẽn. Không ai từng nhận trách nhiệm trả lời nó. Khi truy lại, mỗi người tưởng người khác lo. PM tưởng growth lo phần invite, growth tưởng PM đã chốt. Tính năng trễ 10 ngày và phải thêm cả một luồng SMS OTP không nằm trong kế hoạch ban đầu.
Diễn giải: Đây là lỗi kinh điển — viết Open Questions ra nhưng không quản lý chúng. Một danh sách câu hỏi không có owner và deadline chỉ là một danh sách ước nguyện, không phải công cụ vận hành. Sự tồn tại của mục Open Questions tạo cảm giác an toàn giả: "mình đã liệt kê rồi mà", trong khi thực chất chẳng câu nào được giao cho ai.
Bài học: Mỗi Open Question phải có một cái tên người cụ thể bên cạnh và một mốc thời gian. Quy tắc vàng: một câu hỏi không có owner thì không tồn tại. Trong review meeting, việc đầu tiên PM nên làm với mục này là đi từng dòng và gán owner trực tiếp, có mặt người đó trong phòng để họ gật đầu.
Ví dụ 3 — Grab và nghệ thuật "đóng" câu hỏi bằng cách hoãn
PM tại một công ty gọi xe/giao đồ ăn (bối cảnh Grab) làm tính năng đặt món cho nhóm văn phòng. Cô có 12 Open Questions. Nhưng cô làm một điều thông minh: cô phân loại chúng thành ba nhóm.
- Nhóm A (5 câu): bắt buộc chốt trước v1 — ví dụ "ai là người thanh toán cuối cùng?".
- Nhóm B (4 câu): có thể chốt trong lúc build — ví dụ "màu của nút xác nhận".
- Nhóm C (3 câu): cố ý hoãn sang v2 — ví dụ "có cho phép chia bill theo % không?".
Diễn giải: "Đóng" một Open Question không có nghĩa là phải trả lời nó. Đóng có thể là: trả lời, hoặc quyết định CÓ CHỦ ĐÍCH không trả lời bây giờ. Sự khác biệt giữa "quên trả lời" và "cố ý hoãn" là một dòng ghi chú. Nhờ phân nhóm, cả team biết chính xác cái gì chặn ship và cái gì không, tránh tranh luận màu nút trong khi câu hỏi thanh toán còn treo.
Bài học: Quản lý Open Questions không phải đua xem trả lời được bao nhiêu câu, mà là phân loại đúng mức độ chặn (blocking) của từng câu, và mỗi câu phải kết thúc ở một trong ba trạng thái rõ ràng: Đã chốt, Defer, hoặc Đang xử lý có owner+deadline.
Hướng dẫn từng bước
Bước 1 — Thu thập câu hỏi liên tục trong lúc viết PRD. Đừng để dành đến cuối. Mỗi khi viết một câu mà bụng thấy gợn "ờ cái này chưa chắc", lập tức nhảy xuống mục Open Questions và gõ nó ra. Coi đó như một nơi "đổ rác" tạm — viết thô trước, gọt sau.
Bước 2 — Lọc và phân loại. Sau khi viết xong bản nháp PRD, rà lại danh sách. Loại bỏ những câu thực ra đã có câu trả lời (chuyển chúng vào phần nội dung chính). Gộp câu trùng. Với mỗi câu còn lại, gán mức độ blocking: chặn-v1, có-thể-chốt-sau, hay defer.
Bước 3 — Gán Owner và Deadline cho từng câu. Đây là bước không được bỏ qua. Owner là người sẽ đảm bảo câu hỏi được chốt, không nhất thiết là người biết câu trả lời. Deadline nên neo vào mốc cụ thể của dự án ("trước eng kickoff", "trước design review") thay vì một ngày trừu tượng.
Bước 4 — Phát tán để crowdsource. Khi gửi PRD review, hãy chủ động tag đúng người vào đúng câu hỏi. Đừng chỉ gửi cả PRD rồi hy vọng có người đọc tới mục Open Questions. Viết thẳng: "@An, câu số 3 về cổng thanh toán cần ý kiến của bạn trước thứ Sáu."
Bước 5 — Chạy qua Open Questions trong review meeting. Dành riêng vài phút trong buổi review để đi từng dòng. Mục tiêu của buổi họp không phải trả lời hết, mà là: gán owner còn thiếu, chốt những câu dễ ngay tại chỗ, và thống nhất deadline cho phần còn lại.
Bước 6 — Đóng từng câu và ghi quyết định. Khi một câu được chốt, đổi trạng thái thành "Đã chốt", ghi quyết định cuối cùng kèm lý do ngắn vào cột ghi chú, rồi (nếu cần) chuyển nội dung quyết định đó vào phần chính của PRD. Đừng xóa câu hỏi — lịch sử quyết định là tài sản quý.
Bước 7 — Theo dõi đến khi sạch. Trước khi vào cột mốc ship, mục Open Questions phải không còn câu nào ở trạng thái "Open" hay "Đang thảo luận" mà thuộc nhóm chặn-v1. Coi đây như một mục bắt buộc trong checklist trước khi build và trước khi ship.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết câu hỏi mơ hồ không trả lời được. "Cần làm rõ phần thanh toán" không phải câu hỏi, đó là một lời than. Câu hỏi tốt phải đóng được bằng một quyết định: "Khi thanh toán thất bại lần 3, ta giữ hay hủy đơn?". Mẹo: nếu câu trả lời không thể là một lựa chọn cụ thể, hãy viết lại cho sắc hơn.
Lỗi 2 — Để Open Questions thành nghĩa địa. Danh sách phình to mà không câu nào được đóng. Mẹo: đặt quy tắc "mỗi câu sống tối đa một tuần ở trạng thái Open" — quá hạn thì phải escalate hoặc defer có chủ đích.
Lỗi 3 — Nhầm Open Question với Risk. Nếu một dòng mô tả "điều xấu có thể xảy ra" thay vì "quyết định cần chốt", nó thuộc Risk Register chứ không phải đây. Giữ hai mục tách biệt để mỗi mục làm tốt việc của nó.
Lỗi 4 — Giấu câu hỏi khó vì sợ trông thiếu chuyên nghiệp. Nhiều PM trẻ ngại viết ra điều mình chưa biết vì sợ sếp đánh giá. Thực tế ngược lại: lãnh đạo giỏi đánh giá cao PM biết chính xác mình chưa rõ gì. Một PRD không có Open Question nào thường không phải PRD hoàn hảo — mà là PRD chưa suy nghĩ đủ sâu.
Lỗi 5 — Đóng câu hỏi mà không ghi lý do. Ba tháng sau không ai nhớ vì sao chọn phương án đó, và cuộc tranh luận cũ tái diễn. Mẹo: mỗi quyết định đóng phải kèm một câu "vì sao", dù ngắn.
Mẹo bổ sung: Đánh số câu hỏi (Q1, Q2...) để dễ tham chiếu trong chat và họp. Khi một câu được chốt và chuyển vào phần chính của PRD, để lại con trỏ "đã chuyển vào mục Solution" thay vì xóa, để giữ mạch theo dõi.
Bài tập thực hành
- Tự kiểm PRD cũ. Lấy một PRD bạn từng viết (hoặc một PRD mẫu). Đọc lại và tìm ít nhất 4 chỗ chứa giả định ngầm mà lẽ ra phải là Open Question. Viết lại chúng thành câu hỏi sắc bén, đóng được bằng một quyết định.
- Dựng bảng đầy đủ. Với 4 câu hỏi vừa tìm, lập một bảng Open Questions hoàn chỉnh gồm các cột: #, Câu hỏi, Owner, Deadline, Trạng thái, Quyết định. Gán owner và deadline giả định hợp lý cho từng câu.
- Phân loại blocking. Đánh dấu mỗi câu thuộc nhóm nào: chặn-v1, chốt-trong-lúc-build, hay defer-v2. Với câu defer, viết một dòng ghi chú lý do hoãn đủ thuyết phục để người đọc đồng ý.
- Mô phỏng crowdsource. Tưởng tượng bạn gửi bảng này cho 3 reviewer: một kỹ sư, một bạn legal, một bạn CS. Viết ra với mỗi câu hỏi, bạn sẽ tag ai và vì sao họ là người phù hợp để trả lời.
Tóm tắt
Open Questions là mục PRD nơi PM công khai thừa nhận những gì mình chưa quyết — và chính sự tường minh đó tạo ra ba giá trị: ép PM đối diện sự không chắc chắn, huy động câu trả lời từ reviewer, và chặn những bất ngờ đắt đỏ vào cuối chu kỳ. Nhưng viết ra mới chỉ là một nửa; nửa còn lại là quản lý: mỗi câu hỏi phải có owner cụ thể, một deadline neo vào mốc dự án, một trạng thái rõ ràng, và khi đóng phải ghi lại quyết định kèm lý do.
Phân biệt Open Question với Risk và Task. Phân loại theo mức độ chặn. Chấp nhận rằng "đóng" một câu hỏi có thể là cố ý hoãn nó sang v2 — miễn là có chủ đích và được ghi chú. Một danh sách câu hỏi không owner, không deadline chỉ là ảo giác an toàn. Nhưng một bảng Open Questions được quản lý tử tế là một trong những công cụ điều phối quyết định mạnh nhất mà một PM có trong tay — nó biến sự không chắc chắn từ kẻ thù ẩn nấp thành một danh sách việc cần làm có thể chinh phục từng dòng một.