Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng đội của bạn vừa kết thúc một tuần discovery sprint cường độ cao: phỏng vấn mười hai khách hàng, dựng hai bản prototype, chạy một landing page test, ngồi cãi nhau ba buổi về insight. Tất cả đều mệt nhưng hứng khởi. Rồi thứ Sáu trôi qua, mọi người về cuối tuần, và đến thứ Hai tuần sau… không ai nhớ chính xác đã quyết định gì. Sếp hỏi "tuần rồi học được gì?", mỗi người trả lời một kiểu. Ba tháng sau, một thành viên mới vào hỏi "tại sao mình bỏ ý tưởng X?", và cả đội ngẩn ra vì không ai nhớ lý do.
Đây là vấn đề kinh điển của discovery: insight bay hơi rất nhanh. Bộ não con người tự bịa lại lịch sử — chúng ta nhớ kết luận nhưng quên bằng chứng, nhớ cảm xúc nhưng quên dữ liệu. Một discovery sprint tốn 5–10 ngày công của cả đội, đốt tiền lương và cơ hội, nhưng nếu không có bản recap đúng cách thì 80% giá trị học được sẽ tan biến trong vòng hai tuần.
Discovery Sprint Recap chính là cơ chế chống lại sự bay hơi đó. Nó là một tài liệu một trang (one-pager) chốt lại bốn câu hỏi sống còn: Chúng ta đã test giả thuyết gì? Học được gì? Quyết định gì? Và làm gì tiếp theo? Bài này dạy bạn cách viết bản recap đó — không phải kiểu báo cáo dài dòng cho có, mà một artifact gọn, sắc, có thể đọc trong 90 giây và làm cơ sở ra quyết định.
Lưu ý phân biệt: bài này tập trung vào format và kỹ thuật viết bản recap cuối sprint — không phải cách thiết kế sprint (đó là một chủ đề riêng), không phải cách tổng hợp research thô (synthesizing), cũng không phải cách lưu trữ toàn bộ kho tài liệu discovery dài hạn. Recap là cái chốt cuối, là điểm kết tinh của một chu kỳ discovery thành một trang ai cũng đọc được.
Khái niệm cốt lõi
Recap là một quyết định, không phải một bản tường thuật
Sai lầm lớn nhất là coi recap như nhật ký: "Thứ Hai làm gì, thứ Ba làm gì, thứ Tư phỏng vấn ai…". Đó là log, không phải recap. Một bản recap đúng nghĩa được tổ chức quanh một quyết định trung tâm: dựa trên những gì học được tuần này, đội sẽ go / pivot / kill / dig deeper (tiến tới, xoay trục, dừng, hay đào sâu thêm).
Mọi thứ khác trong tài liệu chỉ tồn tại để biện minh cho quyết định đó. Nếu một thông tin không ảnh hưởng đến quyết định, nó không thuộc về bản recap — hãy để nó trong tài liệu research chi tiết.
Bốn khối nội dung bắt buộc
Một bản recap chuẩn gồm bốn khối, đúng theo ý định gốc của bài:
1. What we tested (Đã test gì) — Nêu rõ giả thuyết đã đưa vào kiểm chứng, viết theo cấu trúc giả thuyết: "Chúng tôi tin rằng [nhóm khách hàng] gặp [vấn đề] và sẽ [hành vi mong đợi]." Kèm phương pháp (phỏng vấn, smoke test, concierge…) và cỡ mẫu. Phần này trả lời "chúng ta đã đặt cược vào điều gì?".
2. What we learned (Đã học gì) — Insight cốt lõi, ưu tiên bằng chứng định lượng và trích dẫn nguyên văn (verbatim) của user. Phân biệt rõ bằng chứng ủng hộ và bằng chứng phản bác giả thuyết. Đây là phần dễ bị bóp méo nhất — người ta hay chỉ ghi cái củng cố niềm tin sẵn có (confirmation bias).
3. What we decided (Đã quyết gì) — Quyết định rõ ràng, dứt khoát: Go / Pivot / Kill / Continue. Kèm lý do và mức độ tự tin (confidence: cao/trung bình/thấp). Quyết định mà không kèm lý do thì sáu tháng sau vô dụng.
4. What's next (Tiếp theo gì) — Hành động cụ thể, có người chịu trách nhiệm (owner) và mốc thời gian. Nếu quyết định là "dig deeper" thì giả thuyết tiếp theo cần test là gì?
Nguyên tắc một trang
Tại sao bắt buộc một trang? Vì ràng buộc về độ dài ép bạn phải suy nghĩ, phải chọn lọc. Một báo cáo mười trang là nơi insight đi trốn — không ai đọc, và sự thiếu rõ ràng được ngụy trang bằng độ dài. Một trang buộc bạn phải biết đâu là điều quan trọng nhất. Marty Cagan và nhiều product leader gọi đây là "forcing function": ràng buộc tạo ra chất lượng tư duy.
Recap phải "scannable" trong 90 giây
Đối tượng đọc recap thường là người bận: founder, head of product, stakeholder không tham gia sprint. Họ cần nắm được kết luận trong chưa đầy hai phút. Vì vậy recap nên có cấu trúc thị giác rõ: tiêu đề khối in đậm, một câu kết luận lớn (TL;DR) ở đầu, bullet ngắn, số liệu nổi bật. Tránh đoạn văn dài đặc.
Tình huống thực tế
Ví dụ 1 — Tiki và cú recap cứu một tuần lãng phí (bối cảnh giả định hợp lý)
Giả sử đội growth của một sàn thương mại điện tử lớn tại Việt Nam — gọi là sàn "T" — chạy một discovery sprint một tuần để kiểm chứng giả thuyết: "Khách mua mỹ phẩm trên sàn ngại đặt vì sợ hàng giả, và một tính năng 'xác thực chính hãng bằng QR' sẽ tăng tỷ lệ chuyển đổi." Đội phỏng vấn 15 khách, chạy một fake-door test cho nút "Kiểm tra chính hãng".
Cuối sprint, PM viết một bản recap đúng chuẩn:
- Tested: Giả thuyết nỗi sợ hàng giả là rào cản mua hàng số 1; smoke test nút QR với 4.200 lượt hiển thị.
- Learned: Chỉ 1,8% người click nút "Kiểm tra chính hãng" (thấp hơn nhiều ngưỡng kỳ vọng 8%). Trong phỏng vấn, 11/15 người nói rào cản thực sự là phí ship và thời gian giao, không phải hàng giả. Verbatim đắt giá: "Em biết shop này uy tín rồi, em chỉ ngại ship 4 ngày mới tới."
- Decided: KILL tính năng QR chính hãng. Confidence: cao. Lý do: cả định lượng (click rate thấp) và định tính (user tự nói rào cản khác) đều phủ định giả thuyết.
- Next: Mở sprint mới test giả thuyết về tốc độ giao hàng. Owner: chị Lan. Bắt đầu thứ Hai tuần sau.
Ví dụ 2 — Startup SaaS B2B và recap "mơ hồ" gây hại
Một startup phần mềm quản lý nhà hàng tại TP.HCM (gọi là "Bếp Số") chạy sprint phỏng vấn 8 chủ quán ăn về tính năng quản lý tồn kho. Bản recap đầu tiên của họ viết kiểu:
> "Tuần này phỏng vấn nhiều chủ quán. Nhìn chung họ thấy tính năng tồn kho hữu ích và quan tâm. Đội thấy đây là hướng tiềm năng, sẽ tiếp tục phát triển."
Nghe có vẻ tích cực. Nhưng bản recap này vô giá trị vì ba lý do: không có giả thuyết rõ, không có bằng chứng định lượng, và "quan tâm" là một tín hiệu rác. Người ta luôn nói "hữu ích" để lịch sự.
Mentor của họ yêu cầu viết lại theo format bốn khối. Khi làm vậy, đội phát hiện ra sự thật phũ: trong 8 người, chỉ 2 người thực sự đang dùng một công cụ tồn kho nào đó (kể cả Excel) và sẵn sàng trả tiền. 6 người còn lại "quan tâm" nhưng quản lý tồn kho bằng… trí nhớ và không thấy đó là vấn đề đủ đau. Verbatim phơi bày: "Thấy hay đó nhưng quán em nhỏ, em nhớ hết, chắc chưa cần."
Khi viết lại:
- Learned: Chỉ 2/8 có dấu hiệu sẵn sàng trả tiền; 6/8 không coi đây là pain đủ lớn.
- Decided: PIVOT — thu hẹp đối tượng sang chuỗi quán từ 3 chi nhánh trở lên (nơi tồn kho thực sự đau). Confidence: trung bình.
Ví dụ 3 — Grab và recap "dig deeper" (bối cảnh Đông Nam Á, giả định)
Một đội tại một super-app khu vực Đông Nam Á chạy sprint test giả thuyết về một dịch vụ giao thuốc theo toa. Sau một tuần, dữ liệu trộn lẫn: nhu cầu rõ ràng có thật (cầu cao ở nhóm người chăm sóc cha mẹ già), nhưng vướng pháp lý đơn thuốc và bài toán vận hành dược sĩ xác nhận toa.
Đội đứng trước cám dỗ ra quyết định vội — hoặc go (vì thấy nhu cầu) hoặc kill (vì thấy khó). Bản recap tốt của họ chọn lựa chọn thứ ba:
- Decided: DIG DEEPER — chưa đủ cơ sở go hay kill. Confidence vào "có nhu cầu": cao. Confidence vào "vận hành khả thi": thấp.
- Next: Sprint tiếp theo tập trung duy nhất vào assumption rủi ro nhất: liệu có quy trình xác nhận đơn thuốc vừa hợp pháp vừa dưới 5 phút? Owner: đội Legal + Ops. Test bằng một concierge nhỏ với 20 đơn thật.
Hướng dẫn từng bước
Bước 1 — Đặt lịch recap ngay trong kế hoạch sprint. Block 60–90 phút vào cuối sprint, cả đội core có mặt. Đừng để recap thành việc "PM về nhà tự viết". Recap là hoạt động tập thể để đồng thuận về diễn giải dữ liệu.
Bước 2 — Viết câu TL;DR trước tiên. Trước khi điền bốn khối, hãy ép cả đội thống nhất một câu tóm tắt: ví dụ "Đã kill ý tưởng X vì user không coi đó là pain đủ lớn; chuyển sang test Y." Nếu không viết được một câu, nghĩa là đội chưa thực sự thống nhất — đó là tín hiệu cần thảo luận thêm.
Bước 3 — Điền khối "Tested". Ghi lại nguyên văn giả thuyết đã đặt ra từ đầu sprint (lấy từ tài liệu kế hoạch, đừng viết lại theo trí nhớ sau khi đã biết kết quả — đó là hindsight bias). Kèm phương pháp và cỡ mẫu.
Bước 4 — Điền khối "Learned" với kỷ luật bằng chứng. Mỗi insight phải kèm bằng chứng: con số hoặc verbatim. Tách riêng "bằng chứng ủng hộ giả thuyết" và "bằng chứng phản bác". Bắt buộc tìm ít nhất một bằng chứng phản bác — nếu không tìm được, có thể bạn đang chỉ nghe điều mình muốn nghe.
Bước 5 — Chốt khối "Decided". Buộc đội chọn một từ: Go / Pivot / Kill / Dig deeper. Kèm lý do (một câu) và confidence level. Ghi rõ ai là người ra quyết định cuối (decision owner) nếu đội không đồng thuận hoàn toàn.
Bước 6 — Điền khối "Next" với owner và deadline. Mỗi hành động phải có một cái tên người và một mốc thời gian. Action không có owner là action sẽ không xảy ra.
Bước 7 — Ép vào một trang và phát hành. Cắt bỏ những gì không phục vụ quyết định. Đăng vào kênh chung (Slack/Notion/Confluence) trong vòng 24 giờ — để nguội là hỏng. Link tới tài liệu research chi tiết cho ai muốn đào sâu, nhưng recap tự nó đứng vững một trang.
Lỗi thường gặp & mẹo
Lỗi 1 — Recap thành bản tường thuật theo ngày. "Thứ Hai làm A, thứ Ba làm B…" Không ai quan tâm timeline. Mẹo: tổ chức quanh quyết định, không quanh thời gian.
Lỗi 2 — Chỉ ghi bằng chứng ủng hộ. Confirmation bias là kẻ thù số một. Mẹo: thêm một dòng bắt buộc "Bằng chứng phản bác giả thuyết" — nếu để trống, đội phải giải thích vì sao.
Lỗi 3 — Dùng tín hiệu rác làm bằng chứng. "User thấy hữu ích", "user quan tâm", "phản hồi tích cực" — đều là tín hiệu yếu. Mẹo: thay bằng hành vi (họ đã click? đã trả tiền? đã giới thiệu?) và verbatim cụ thể.
Lỗi 4 — Không có quyết định. Recap kết thúc bằng "đội sẽ tiếp tục theo dõi" là recap thất bại. Mẹo: nếu thật sự chưa quyết được, hãy ghi rõ "DIG DEEPER" kèm assumption cần test — đó vẫn là một quyết định.
Lỗi 5 — Viết quá dài. Mười trang nghĩa là không ai đọc. Mẹo: đặt giới hạn cứng một trang, hoặc một màn hình. Phần thừa đẩy sang phụ lục.
Lỗi 6 — Recap không kèm confidence level. Một quyết định "go" với confidence thấp rất khác "go" với confidence cao — nó báo hiệu cần nhiều validation hơn. Mẹo: luôn ghi mức tự tin để người đọc biết tin tới đâu.
Lỗi 7 — Viết xong rồi cất tủ. Recap chỉ có giá trị nếu được tra cứu. Mẹo: lưu tập trung, đặt tên có hệ thống (Sprint-YYYYMMDD-tên giả thuyết), để bộ nhớ tổ chức tích lũy theo thời gian.
Mẹo nâng cao — Template hóa. Tạo một template cố định để mỗi sprint chỉ việc điền vào. Sự nhất quán về format giúp đọc nhanh và so sánh giữa các sprint dễ dàng.
Bài tập thực hành
Bài tập 1 — Dựng template của riêng bạn. Tạo một template recap một trang gồm: ô TL;DR (1 câu), bốn khối (Tested / Learned / Learned-phản bác / Decided / Next), và một dòng confidence level. Lưu lại để dùng cho mọi sprint sau này.
Bài tập 2 — Viết lại một recap rác. Lấy đoạn sau và viết lại theo format bốn khối: > "Tuần rồi đội phỏng vấn vài người dùng app gọi xe về tính năng đặt xe ghép (carpool). Mọi người nói ý tưởng hay, tiết kiệm tiền. Đội thấy có tiềm năng nên sẽ phát triển thêm." Hãy chỉ ra: giả thuyết thực sự là gì, "ý tưởng hay" là tín hiệu rác cần thay bằng gì, và một quyết định rõ ràng kèm confidence.
Bài tập 3 — Áp dụng vào dự án thật. Nếu bạn đang làm một dự án, hãy viết một bản recap một trang cho lần discovery gần nhất — kể cả khi nó đã xong từ lâu. Quan sát: bạn còn nhớ chính xác giả thuyết ban đầu và bằng chứng không? Nếu khó nhớ, đó chính là lý do bạn cần recap.
Bài tập 4 — Test "90 giây". Đưa bản recap của bạn cho một người không tham gia sprint, bấm giờ 90 giây, rồi hỏi họ: "Đội đã quyết gì và vì sao?" Nếu họ trả lời đúng, recap của bạn đạt chuẩn scannable. Nếu không, hãy cắt gọn và làm nổi bật phần quyết định.
Tóm tắt
Discovery Sprint Recap là cơ chế chống lại sự bay hơi của insight — biến công sức một tuần discovery thành một artifact một trang có thể đọc trong 90 giây và làm cơ sở ra quyết định. Cốt lõi nằm ở bốn khối: đã test giả thuyết gì, học được gì (kèm cả bằng chứng phản bác), quyết định gì (Go/Pivot/Kill/Dig deeper kèm confidence), và làm gì tiếp theo (kèm owner và deadline).
Recap không phải bản tường thuật theo ngày, mà được tổ chức quanh một quyết định trung tâm. Ràng buộc một trang là một forcing function ép bạn suy nghĩ và chọn lọc. Format không phải thủ tục hành chính — như ví dụ sàn "T", "Bếp Số" và super-app khu vực cho thấy, một format có kỷ luật phơi bày sự thật phũ phàng sớm, khi sửa còn rẻ, và xây nên bộ nhớ tổ chức để không ai phải test lại cùng một ý tưởng đã bị giết.
Hãy nhớ ba điều: viết quanh quyết định, luôn kèm bằng chứng (đặc biệt là bằng chứng phản bác), và phát hành trong 24 giờ trước khi insight nguội. Một bản recap tốt là món quà bạn tặng cho chính đội mình ba tháng sau.