Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa có một ý tưởng sản phẩm mà bạn tin là sẽ thay đổi cục diện. Bạn muốn xin ngân sách, xin headcount, hoặc đơn giản là xin một cái "gật đầu" từ CEO để bắt đầu. Bạn viết một PRD dài 12 trang, đính kèm vào email, rồi chờ. Một tuần sau, CEO trả lời: "Anh chưa đọc, để cuối tuần xem nhé." Và cái "cuối tuần" đó không bao giờ đến.
Vấn đề không nằm ở ý tưởng của bạn. Vấn đề nằm ở chỗ bạn đưa nhầm tài liệu cho nhầm người. Lãnh đạo cấp cao — CEO, VP, founder, hội đồng đầu tư — không có thời gian đọc 12 trang. Họ ra hàng chục quyết định mỗi ngày, mỗi quyết định họ dành cho bạn có khi chỉ 3–5 phút. Nếu bạn không thuyết phục được họ trong khoảng thời gian ngắn ngủi đó, ý tưởng của bạn sẽ chết — không phải vì nó dở, mà vì nó chưa bao giờ được hiểu.
One-pager (tài liệu một trang) chính là vũ khí cho khoảnh khắc này. Đây là tài liệu được thiết kế để align (đồng thuận) stakeholder cấp cao về một initiative (sáng kiến) trong dưới 5 phút đọc. Nó không thay thế PRD — như chúng ta đã phân biệt ở Bài 1 (PRD vs Spec vs One-pager vs RFC) — mà đứng ở một vị trí hoàn toàn riêng trong vòng đời sản phẩm: nó đến trước PRD, dùng để xin quyết định "có làm hay không", trước khi bạn bỏ công sức viết spec chi tiết. Bài học này sẽ dạy bạn cấu trúc chuẩn của một one-pager, cho bạn template để dùng ngay, và phân tích những ví dụ thực tế để bạn thấy nó hoạt động ra sao trong môi trường công ty Việt Nam và Đông Nam Á.
Khái niệm cốt lõi
One-pager là gì và không là gì
One-pager là một tài liệu thuyết phục gói gọn trong một trang giấy (khoảng 400–700 từ), trả lời đúng một câu hỏi của người đọc: "Tại sao tôi nên đầu tư nguồn lực vào việc này, và đầu tư bao nhiêu?" Nó là công cụ để xin quyết định, không phải để hướng dẫn thực thi.
Hãy phân biệt rõ:
- PRD trả lời câu hỏi "Đội ngũ sẽ xây cái gì và như thế nào?" — dành cho engineer, designer, người trực tiếp làm.
- One-pager trả lời câu hỏi "Chúng ta có nên làm việc này không?" — dành cho người ký duyệt, người cấp ngân sách.
Cấu trúc chuẩn của một one-pager
Một one-pager hiệu quả thường có 6–8 mục, mỗi mục chỉ vài dòng. Đây là khung sườn tôi khuyên dùng:
- Title + Author + Date. Tiêu đề phải nói được kết quả mong muốn, không phải tên tính năng. "Tăng tỷ lệ thanh toán thành công lên 90%" tốt hơn "Tích hợp cổng thanh toán mới". Kèm tên người chịu trách nhiệm (DRI — Directly Responsible Individual) và ngày, để người đọc biết tài liệu còn mới hay đã cũ.
- TL;DR (Tóm tắt 2–3 câu). Đây là phần quan trọng nhất. Giả định người đọc chỉ đọc duy nhất phần này rồi quyết định. Nó phải nêu: vấn đề, đề xuất, và "ask" (điều bạn cần) — tất cả trong 2–3 câu.
- Problem / Context (Vấn đề & bối cảnh). Tại sao việc này quan trọng ngay bây giờ? Có số liệu chứng minh không? Bài này không đi sâu cách viết Problem Statement — đó là chủ đề riêng của Bài 13 — nhưng ở one-pager, bạn cần nêu vấn đề kèm con số tác động.
- Proposal (Đề xuất). Bạn định làm gì, ở mức một câu hoặc một đoạn ngắn. Tập trung vào kết quả và hướng tiếp cận, không vào chi tiết implementation.
- Why now / Opportunity size (Cơ hội & tính cấp thiết). Quy mô tác động kỳ vọng: doanh thu, số người dùng, chi phí tiết kiệm. Đây là phần làm lãnh đạo "động lòng".
- Cost / Effort (Chi phí & nguồn lực). Cần bao nhiêu người, bao lâu, tốn gì. Lãnh đạo luôn cân nhắc đánh đổi (trade-off).
- Risks / Open questions (Rủi ro & câu hỏi mở). Trung thực nêu điều bạn chưa chắc. Người đọc tinh tế sẽ tin bạn hơn khi bạn thừa nhận rủi ro.
- The Ask (Điều bạn cần). Kết bằng một câu hỏi cụ thể: "Tôi xin duyệt 2 engineer trong 6 tuần để chạy thử nghiệm" — chứ không phải một lời kết mơ hồ.
Nguyên tắc "đảo ngược kim tự tháp"
Báo chí có một nguyên tắc gọi là inverted pyramid (kim tự tháp ngược): thông tin quan trọng nhất đặt lên đầu, chi tiết hỗ trợ xuống dưới. One-pager hoạt động y hệt. Người đọc có thể dừng ở bất kỳ dòng nào và vẫn nắm được điều cốt yếu. TL;DR ở đầu, chi tiết bổ trợ ở sau. Đừng bao giờ giấu kết luận xuống cuối trang như viết tiểu thuyết trinh thám.
Tình huống thực tế
Ví dụ 1: One-pager xin ngân sách tại một ví điện tử ở Việt Nam
Một công ty ví điện tử (gọi tên là PayViet) phát hiện 18% giao dịch nạp tiền qua thẻ ngân hàng nội địa bị thất bại do lỗi timeout ở cổng thanh toán cũ. Một Product Manager tên Linh muốn xin duyệt tích hợp cổng thanh toán mới. Cô không gửi PRD. Cô gửi một one-pager:
- Title: "Giảm tỷ lệ nạp tiền thất bại từ 18% xuống dưới 5%."
- TL;DR: "18% giao dịch nạp tiền đang thất bại, tương đương 2,4 tỷ đồng GMV bốc hơi mỗi tháng và hàng nghìn user bỏ app. Tôi đề xuất tích hợp cổng thanh toán Napas thế hệ mới. Cần 3 engineer trong 8 tuần."
- Problem: kèm biểu đồ tỷ lệ thất bại theo tháng và một trích dẫn từ ticket support thật.
- Opportunity: nếu giảm về 5%, ước tính cứu lại ~1,7 tỷ GMV/tháng.
- Cost: 3 engineer, 8 tuần, phí tích hợp khoảng 200 triệu.
- The Ask: "Xin duyệt nguồn lực để khởi động trong sprint tới."
Ví dụ 2: One-pager bị từ chối — và lý do tại sao
Tại một startup logistics ở TP.HCM, một PM tên Quân muốn xây tính năng chat trong app cho tài xế. Anh viết một one-pager nhưng mắc lỗi: nửa trang đầu mô tả kiến trúc WebSocket, hàng đợi tin nhắn, mã hóa đầu cuối. Phần "tại sao" chỉ vỏn vẹn một dòng: "Tài xế cần liên lạc tốt hơn."
VP Sản phẩm đọc xong hỏi đúng một câu: "Hiện tài xế đang liên lạc bằng cách nào, và việc đó tệ đến đâu?" Quân không có số liệu. One-pager bị gác lại.
Bài học: Quân đã viết một bản tóm tắt giải pháp, không phải một one-pager. Anh đầu tư từ ngữ vào "làm thế nào" trong khi lãnh đạo chỉ cần biết "tại sao" và "đáng giá bao nhiêu". Một one-pager mà người đọc không thấy được nỗi đau và quy mô của vấn đề thì dù giải pháp có hay đến đâu cũng vô nghĩa với người ký duyệt.
Ví dụ 3: One-pager định hướng chiến lược tại một super-app Đông Nam Á
Một super-app vùng Đông Nam Á (kiểu Grab/Gojek) đang cân nhắc mở rộng sang mảng "đi chợ hộ". Giám đốc mảng mới viết một one-pager gửi cho ban điều hành. Khác với hai ví dụ trên, đây không phải xin duyệt một tính năng nhỏ mà xin "ánh sáng xanh" cho một hướng đi.
One-pager này dành nhiều dòng cho phần Why now: thị trường grocery online tăng trưởng 40%/năm hậu đại dịch, hai đối thủ vừa rút khỏi mảng này tạo khoảng trống, và tập user hiện có 12 triệu người mỗi tháng là kênh phân phối sẵn sàng. Phần Ask rất rõ: "Xin phê duyệt một pilot tại Jakarta trong 90 ngày với ngân sách 500 nghìn USD để xác nhận unit economics, trước khi cam kết đầu tư lớn."
Bài học: One-pager chiến lược không xin cam kết toàn bộ — nó xin một bước nhỏ có kiểm soát để giảm rủi ro. Cách đóng khung "xin pilot 90 ngày để học" dễ được duyệt hơn nhiều so với "xin đầu tư 10 triệu USD vào mảng mới". Lãnh đạo thích những quyết định có thể đảo ngược (reversible) và có cột mốc kiểm chứng rõ ràng.
Hướng dẫn từng bước
Đây là quy trình tôi dùng để viết một one-pager từ con số không:
Bước 1 — Xác định người đọc và quyết định họ cần ra. Trước khi gõ chữ nào, viết ra: ai sẽ đọc cái này, và bạn muốn họ làm gì sau khi đọc? Duyệt ngân sách? Cấp người? Đồng ý hướng đi? Toàn bộ tài liệu phải phục vụ đúng quyết định đó.
Bước 2 — Viết phần "The Ask" trước tiên. Nghe ngược đời, nhưng hãy bắt đầu từ cuối. Khi bạn biết chính xác mình cần gì, mọi phần khác sẽ tự định hướng để dẫn tới điều đó.
Bước 3 — Viết TL;DR thành 3 câu. Câu 1: vấn đề kèm số. Câu 2: đề xuất. Câu 3: điều bạn cần. Nếu bạn không gói được trong 3 câu, nghĩa là bạn chưa hiểu đủ rõ vấn đề.
Bước 4 — Tìm con số tác động. Mọi one-pager mạnh đều có ít nhất một con số khiến người đọc giật mình: doanh thu mất đi, số user rời bỏ, chi phí lãng phí. Nếu chưa có số, hãy đi tìm — dù chỉ là ước lượng có cơ sở.
Bước 5 — Viết phần thân, mỗi mục 2–4 dòng. Problem, Proposal, Opportunity, Cost, Risks. Kỷ luật về độ dài. Nếu một mục dài quá, có thể nó thuộc về PRD chứ không phải one-pager.
Bước 6 — Cắt gọt xuống còn một trang. Đọc lại và xóa mọi câu không phục vụ quyết định. Một one-pager dài 1,5 trang đã thất bại về mặt định nghĩa. Quy tắc: nếu xóa một câu mà quyết định không thay đổi, hãy xóa nó.
Bước 7 — Kiểm tra bằng "phép thử 30 giây". Đưa cho một đồng nghiệp đọc đúng 30 giây rồi hỏi: "Tôi đang xin gì, và tại sao?" Nếu họ trả lời được, one-pager của bạn đạt.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết one-pager thành tóm tắt PRD. Đây là lỗi phổ biến nhất. Bạn dồn chi tiết kỹ thuật vào trong khi lãnh đạo chỉ cần biết "đáng làm không". Mẹo: nếu một câu trả lời cho câu hỏi "làm thế nào", hãy cân nhắc xóa nó khỏi one-pager.
Lỗi 2 — Giấu phần "Ask" hoặc viết nó mơ hồ. Kết bằng "mong nhận được góp ý của mọi người" là một cái kết chết. Người đọc không biết phải làm gì. Mẹo: luôn kết bằng một yêu cầu cụ thể, đo đếm được: bao nhiêu người, bao lâu, bao nhiêu tiền.
Lỗi 3 — Không có con số. "Tài xế cần liên lạc tốt hơn" là một cảm giác, không phải một lý lẽ. Mẹo: với mỗi tuyên bố về vấn đề, ép mình thêm một con số phía sau, dù là ước lượng.
Lỗi 4 — Tô hồng, giấu rủi ro. Một one-pager hoàn hảo không có rủi ro nào thì đáng ngờ. Lãnh đạo giàu kinh nghiệm sẽ tự đặt câu hỏi, và nếu bạn không nêu trước, bạn trông như chưa nghĩ kỹ. Mẹo: chủ động nêu 2–3 rủi ro lớn nhất kèm cách bạn sẽ giảm thiểu.
Lỗi 5 — Tiêu đề mô tả tính năng thay vì kết quả. "Tích hợp Napas" không nói lên giá trị. "Giảm nạp tiền thất bại còn 5%" thì có. Mẹo: tiêu đề nên đọc như một mục tiêu, không như một dòng trong backlog.
Mẹo tổng quát: Đặt phần đắt giá nhất — con số tác động — vào câu đầu tiên của TL;DR. Nếu người đọc chỉ liếc đúng một dòng, đó phải là dòng làm họ muốn đọc tiếp.
Bài tập thực hành
Bài tập 1 — Viết TL;DR ba câu. Chọn một tính năng hoặc sáng kiến bạn đang ấp ủ (ở công ty hiện tại hoặc một ý tưởng giả định). Viết phần TL;DR đúng 3 câu theo công thức: vấn đề + số / đề xuất / điều bạn cần. Đọc lại và tự hỏi: nếu người đọc dừng ở đây, họ có đủ thông tin để quyết định không?
Bài tập 2 — Hoàn thiện one-pager đầy đủ. Mở rộng TL;DR ở Bài tập 1 thành một one-pager hoàn chỉnh theo cấu trúc 8 mục đã học. Giới hạn nghiêm ngặt: tối đa một trang A4, khoảng 500–650 từ. Bắt buộc có ít nhất một con số tác động và một phần "Ask" cụ thể.
Bài tập 3 — Chữa lỗi. Đọc lại ví dụ của Quân (one-pager chat cho tài xế bị từ chối). Viết lại one-pager đó sao cho được duyệt: thêm con số ước lượng về thời gian tài xế mất do liên lạc kém, đóng khung lại tiêu đề theo hướng kết quả, và viết một phần "Ask" rõ ràng. So sánh bản của bạn với bản gốc để thấy sự khác biệt.
Bài tập 4 — Phép thử 30 giây. Đưa one-pager ở Bài tập 2 cho một người không liên quan đến dự án, cho họ đọc đúng 30 giây, rồi hỏi: "Tôi đang xin gì và tại sao?" Ghi lại câu trả lời. Nếu họ trả lời sai hoặc ấp úng, hãy chỉnh sửa cho đến khi đạt.
Tóm tắt
One-pager là tài liệu thuyết phục một trang, được thiết kế để giúp lãnh đạo cấp cao ra quyết định "có làm hay không" trong dưới 5 phút. Nó khác hoàn toàn với PRD: PRD hướng dẫn đội ngũ xây gì, còn one-pager bán cho người ký duyệt một quyết định. Cấu trúc chuẩn gồm tiêu đề hướng-kết-quả, TL;DR ba câu, vấn đề kèm số, đề xuất, cơ hội, chi phí, rủi ro, và một "Ask" cụ thể — sắp xếp theo nguyên tắc kim tự tháp ngược, đặt thông tin quan trọng nhất lên đầu.
Ba bài học cốt lõi từ các ví dụ thực tế: (1) con số tác động đặt ngay TL;DR là thứ thuyết phục lãnh đạo, không phải chi tiết kỹ thuật; (2) one-pager mô tả giải pháp mà thiếu nỗi đau và quy mô vấn đề sẽ bị từ chối; (3) với sáng kiến lớn, hãy xin một bước nhỏ có kiểm soát (pilot) thay vì cam kết toàn bộ. Quy trình viết bắt đầu từ "The Ask" và kết thúc bằng phép thử 30 giây. Khi bạn nắm vững one-pager, bạn sẽ thấy nhiều ý tưởng tốt của mình được duyệt nhanh hơn — không phải vì chúng hay hơn, mà vì cuối cùng chúng đã được hiểu.