Mở đầu — vì sao bài này quan trọng
Phần lớn PM dồn 90% năng lượng vào giai đoạn trước launch: viết PRD, review spec, đẩy engineering ship đúng hạn. Đến ngày feature lên production, mọi người ăn mừng, đóng ticket, rồi lao ngay sang dự án tiếp theo. Đó chính là khoảnh khắc mà phần lớn giá trị học hỏi bị bỏ phí.
Một tính năng được ship không phải là điểm kết thúc — nó là điểm bắt đầu của một vòng dữ liệu. Bạn đã đặt cược: "Nếu chúng ta làm X, người dùng sẽ làm Y, và metric Z sẽ tăng." Post-launch review là lúc bạn quay lại đối chiếu cược đó với thực tế. Không có bước này, bạn không bao giờ biết PRD của mình dự đoán đúng hay sai, không biết giả định nào sống sót và giả định nào chết, và lần sau bạn vẫn lặp lại đúng những sai lầm cũ với một sự tự tin không có cơ sở.
Trong khóa học này, các bài trước đã dạy bạn viết Goals, đặt counter-metrics, lập rollout plan, dựng monitoring. Bài 49 là mảnh ghép khép vòng: làm sao biến một lần launch thành tài liệu học hỏi có cấu trúc, để cả team thông minh hơn sau mỗi lần ship — chứ không chỉ bận rộn hơn. Đây là kỹ năng phân biệt một PM "chạy dự án" với một PM thực sự xây dựng phán đoán sản phẩm theo thời gian.
Khái niệm cốt lõi
Post-launch review (đôi khi gọi là launch retrospective, hoặc post-mortem khi tập trung vào sự cố) là một buổi đánh giá có cấu trúc sau khi tính năng đã lên production, nhằm trả lời ba câu hỏi: Chúng ta đã đạt mục tiêu chưa? Điều gì diễn ra khác dự đoán? Chúng ta học được gì để làm tốt hơn lần sau?
Cần phân biệt rõ với hai khái niệm hay bị nhầm:
- Post-mortem theo nghĩa hẹp là buổi mổ xẻ một sự cố (incident) — site sập, bug nghiêm trọng, data loss. Nó tập trung vào timeline lỗi và phòng ngừa tái diễn.
- Post-launch review rộng hơn: kể cả khi launch trơn tru, bạn vẫn review để đánh giá tác động sản phẩm so với Goals trong PRD.
Ba mốc thời gian review
Một sai lầm phổ biến là chỉ review một lần ngay sau launch. Tín hiệu sản phẩm chín ở những thời điểm khác nhau, nên bạn cần ba mốc:
- 2 tuần sau launch — initial signal. Đây là giai đoạn đọc tín hiệu sớm: adoption ban đầu ra sao, có bug hay incident nào không, error rate có nhảy không, support ticket có tăng đột biến không. Lúc này dữ liệu còn nhiễu (novelty effect — người dùng tò mò thử rồi bỏ), nên đừng vội kết luận về thành công dài hạn. Mục tiêu chính: phát hiện cháy nhà và xác nhận instrumentation chạy đúng.
- 6 tuần sau launch — steady state. Novelty effect đã lắng, người dùng đã hình thành thói quen thật. Đây là lúc đọc retention, đọc tác động lên metric chính một cách đáng tin, và đối chiếu nghiêm túc với Goals đã đặt trong PRD. Phần lớn quyết định "tính năng này thành công hay thất bại" nên đưa ra ở mốc này, không phải mốc 2 tuần.
- Quarterly retrospective — review theo quý. Nhìn lại cả cụm tính năng đã ship trong quý, tìm pattern xuyên suốt: chúng ta hay underestimate effort ở đâu, loại giả định nào thường sai, quy trình review chỗ nào liên tục nghẽn. Đây là cấp độ học hỏi của tổ chức, không phải của một feature đơn lẻ.
Cấu trúc một post-launch review document
Một review tốt nên được viết thành tài liệu (document), không chỉ là buổi họp nói miệng rồi quên. Cấu trúc thường gồm:
- Tóm tắt launch: ship gì, cho ai, ngày nào, rollout ra sao.
- Goals vs Actuals: lấy đúng các Goals và success metrics từ PRD ban đầu, đặt cạnh con số thực tế. Đây là phần xương sống.
- What went well: điều gì hiệu quả, nên giữ và nhân rộng.
- What didn't go well: điều gì lệch dự đoán, gây đau, hoặc suýt thành sự cố.
- Root cause: với mỗi vấn đề lớn, đào tới nguyên nhân gốc (không dừng ở triệu chứng).
- Action items: việc cụ thể, có người chịu trách nhiệm và deadline. Không có phần này thì review chỉ là buổi than thở.
- Decision: quyết định tiếp theo — double down, iterate, hay kill.
Nguyên tắc blameless
Đây là điều then chốt và hay bị làm sai ở văn hóa công sở Việt Nam, nơi người ta dễ ngầm đi tìm "ai gây ra lỗi". Post-mortem phải blameless — tập trung vào hệ thống và quy trình, không vào cá nhân. Nếu một kỹ sư đẩy nhầm config gây sự cố, câu hỏi không phải "tại sao bạn cẩu thả" mà là "tại sao hệ thống cho phép một config sai lọt lên production mà không có ai chặn?". Văn hóa đổ lỗi sẽ giết chết sự trung thực; mà không trung thực thì review vô giá trị.
Tình huống thực tế
Ví dụ 1 — Ví điện tử "MoMo-style": novelty effect đánh lừa ở mốc 2 tuần
Một team product tại một ví điện tử lớn của Việt Nam ship tính năng "Lì xì online" trước Tết. PRD đặt Goal: tăng số giao dịch P2P (chuyển tiền giữa cá nhân) thêm 15% và giữ retention người dùng mới ở mức tốt.
Ở mốc review 2 tuần, mọi thứ rực rỡ: giao dịch P2P tăng 40%, vượt xa mục tiêu. Một PM thiếu kinh nghiệm sẽ tuyên bố chiến thắng ngay và chuyển sang dự án khác. Nhưng đội này kỷ luật, họ ghi nhận đây mới là initial signal và đợi mốc 6 tuần.
Đến mốc steady state, bức tranh khác hẳn: lượng giao dịch tụt về mức chỉ cao hơn baseline 8% — vì Tết đã qua và nhu cầu lì xì là thời vụ. Tệ hơn, nhóm người dùng mới được kéo vào nhờ lì xì có retention tuần 4 chỉ bằng một nửa người dùng tự nhiên: họ vào nhận tiền rồi rút ra, không hề dùng ví cho mục đích khác.
Bài học: Nếu chốt kết luận ở mốc 2 tuần, team đã ghi nhận sai một thành công ảo, và có thể đầu tư thêm vào một hướng thực ra không bền. Mốc 6 tuần cứu họ khỏi quyết định sai. Action item rút ra rất cụ thể: với feature mang tính thời vụ, success metric phải tách riêng "đỉnh mùa vụ" và "nền steady state", và phải có counter-metric về chất lượng người dùng kéo về, không chỉ đếm số lượng.
Ví dụ 2 — Sàn TMĐT Đông Nam Á: post-mortem một incident checkout
Một sàn thương mại điện tử khu vực Đông Nam Á (kiểu Shopee/Lazada) ship lại luồng checkout với một payment gateway mới. Launch lúc 10 giờ sáng. Đến 10 giờ 25, error rate ở bước thanh toán nhảy từ 0.3% lên 9%. Đội phát hiện và rollback lúc 11 giờ 10. Tổng cộng khoảng 50 phút, ước tính vài nghìn đơn hàng thất bại.
Buổi post-mortem diễn ra hai ngày sau, blameless. Timeline được dựng lại từng phút. Root cause: gateway mới có timeout mặc định 5 giây, trong khi gateway cũ là 30 giây; vào giờ cao điểm một số ngân hàng phản hồi chậm hơn 5 giây nên giao dịch bị đánh fail. Đây không phải lỗi của ai "cẩu thả" — không một spec nào đề cập tới giá trị timeout, và môi trường staging không tạo được độ trễ ngân hàng thực tế.
Điều quan trọng là cách họ phân tách action items thành ba nhóm: phòng ngừa (đưa timeout vào checklist spec cho mọi tích hợp payment), phát hiện (thêm alert tự động khi payment error rate vượt 2% trong 5 phút — trước đó alert đặt ngưỡng quá cao nên report đến chậm), và giảm thiểu (chuẩn hóa quy trình rollback một-cú-bấm để lần sau không mất 45 phút mới rollback xong).
Bài học: Một post-mortem giỏi không dừng ở "đã sửa bug". Nó tách rõ phòng ngừa, phát hiện, giảm thiểu — vì cùng một lớp lỗi sẽ còn xuất hiện dưới hình dạng khác, và bạn cần hệ thống tự bắt được nó sớm hơn lần sau.
Ví dụ 3 — Startup SaaS B2B: quarterly retrospective lộ ra pattern
Một startup SaaS B2B (khoảng 40 người) ở TP.HCM nhận thấy từng feature riêng lẻ review đều "ổn", nhưng tổng thể roadmap luôn trễ. Họ làm quarterly retrospective, gom 9 launch trong quý lại và đối chiếu estimate ban đầu với thực tế.
Pattern lộ ra rõ ràng: 7/9 dự án trễ, và điểm chung là phần "edge cases và error states" luôn bị estimate thiếu, trung bình tốn gấp đôi thời gian dự kiến. Lý do gốc: PRD của họ mô tả happy path rất kỹ nhưng edge case viết sơ sài, nên engineering liên tục phải hỏi lại giữa chừng và phát sinh việc.
Action item ở cấp tổ chức: thêm một bước review spec bắt buộc với checklist edge case trước khi estimate, và điều chỉnh hệ số đệm thời gian cho các feature nhiều trạng thái.
Bài học: Review từng feature chỉ thấy được cây; quarterly retrospective mới thấy được rừng. Những vấn đề mang tính hệ thống — quy trình, văn hóa estimate, chất lượng spec — chỉ lộ ra khi bạn nhìn nhiều launch cùng lúc.
Hướng dẫn từng bước
Bước 1 — Lên lịch ngay khi viết PRD, không phải sau khi launch. Khi viết PRD, hãy đặt sẵn ba mốc review (2 tuần, 6 tuần, quý) vào lịch và ghi rõ ai sở hữu buổi review. Nếu để sau launch mới nghĩ tới, nó sẽ không bao giờ diễn ra vì mọi người đã bận việc mới.
Bước 2 — Chuẩn bị dữ liệu trước buổi họp. PM kéo sẵn số liệu: Goals từ PRD đặt cạnh actuals, biểu đồ adoption/retention, error rate, support ticket, kết quả A/B nếu có. Đừng để buổi họp trôi vào việc "đoán" số liệu. Buổi review là để diễn giải dữ liệu, không phải đi thu thập nó.
Bước 3 — Đối chiếu Goals vs Actuals một cách thẳng thắn. Với từng success metric, ghi rõ: mục tiêu, thực tế, đạt/không đạt. Quan trọng nhất là phần "tại sao lệch" — kể cả khi đạt mục tiêu, hãy hỏi có phải nhờ lý do bạn nghĩ không, hay do may mắn hoặc yếu tố ngoài dự kiến.
Bước 4 — Chạy phần What went well / What didn't well. Mời cả engineering, design, QA, đôi khi cả support và sales. Mỗi người nêu quan sát từ góc của họ. Giữ tinh thần blameless tuyệt đối.
Bước 5 — Đào root cause cho các vấn đề lớn. Dùng kỹ thuật "5 Whys" — hỏi "tại sao" liên tiếp tới khi chạm nguyên nhân hệ thống, không dừng ở triệu chứng. "Bug lọt production" → tại sao → "không có test case" → tại sao → "edge case không có trong spec" → đó mới là gốc.
Bước 6 — Viết action items SMART, có owner và deadline. Mỗi action phải cụ thể, đo được, có một người chịu trách nhiệm và mốc hoàn thành. "Cải thiện monitoring" là vô dụng; "thêm alert payment error rate > 2%, owner: An, xong trước 15/7" mới có giá trị.
Bước 7 — Ra quyết định và truyền đạt. Chốt: double down (đầu tư thêm), iterate (cải tiến), hay kill (dừng). Viết tài liệu review, chia sẻ rộng để cả tổ chức học, và đưa action items vào backlog có theo dõi.
Bước 8 — Đóng vòng ở quarterly retrospective. Mỗi quý gom các review lại tìm pattern xuyên suốt và kiểm tra xem action items kỳ trước có thực sự được làm không. Action item không được theo dõi sẽ chết yên lặng.
Lỗi thường gặp & mẹo
Lỗi: chỉ ăn mừng, không review. Ship xong là chuyển dự án mới. Đây là lỗi phổ biến nhất và đắt nhất, vì nó vứt bỏ toàn bộ giá trị học hỏi. Mẹo: coi review là một phần bắt buộc của "definition of done", không phải việc tùy chọn.
Lỗi: chốt kết luận ở mốc 2 tuần. Như ví dụ ví điện tử, novelty effect làm số liệu sớm đẹp giả tạo. Mẹo: luôn phân biệt initial signal với steady state, và đừng ra quyết định kill/double-down quan trọng trước mốc 6 tuần.
Lỗi: review biến thành buổi đổ lỗi. Một khi có người bị chỉ mặt, mọi người sẽ phòng thủ và che giấu sự thật. Mẹo: facilitator phải nhắc nguyên tắc blameless ngay đầu buổi, và mọi câu hỏi "tại sao" hướng vào hệ thống, không vào người.
Lỗi: action items mơ hồ hoặc không ai theo dõi. Buổi họp sôi nổi rồi không ai làm gì. Mẹo: mỗi action có owner + deadline duy nhất, và mở đầu review kỳ sau bằng việc kiểm tra action items kỳ trước.
Lỗi: chỉ review khi có sự cố. Launch trơn tru cũng cần học — vì sao nó trơn tru, điều gì nên nhân rộng. Mẹo: review mọi launch đáng kể, không chỉ những lần cháy nhà.
Mẹo bổ sung: Đối chiếu thẳng với Goals và Non-goals đã viết trong PRD. Đây là lúc bạn kiểm chứng chất lượng phán đoán của chính mình — PRD dự đoán đúng hay sai, và lần sau sẽ sắc hơn ở đâu.
Bài tập thực hành
- Dựng template review. Lấy một feature gần đây bạn (hoặc công ty bạn) đã ship. Tạo một tài liệu post-launch review theo cấu trúc: Tóm tắt launch → Goals vs Actuals → What went well → What didn't → Root cause → Action items → Decision. Điền đầy đủ bằng dữ liệu thật nếu có.
- Phân biệt ba mốc. Với feature đó, viết ra: ở mốc 2 tuần bạn nên đọc những tín hiệu nào (và tín hiệu nào dễ gây hiểu lầm vì novelty effect)? Ở mốc 6 tuần bạn đọc gì khác? Quarterly retrospective sẽ tìm pattern gì?
- Tập 5 Whys. Lấy một vấn đề thật từng xảy ra (bug, trễ deadline, adoption thấp) và đào 5 lần "tại sao" tới nguyên nhân hệ thống. Sau đó viết một action item SMART tương ứng với owner và deadline giả định.
- Viết lại blameless. Lấy một câu nhận xét mang tính đổ lỗi ("X làm sập production vì cẩu thả") và viết lại thành một câu blameless tập trung vào hệ thống. So sánh hai cách diễn đạt dẫn tới hành động khác nhau ra sao.
Tóm tắt
Post-launch review là bước khép vòng học hỏi biến mỗi lần ship thành tri thức có cấu trúc, thay vì chỉ là một dòng trong changelog. Hãy nhớ ba điều cốt lõi. Một, review ở ba mốc: 2 tuần (initial signal, cẩn thận novelty effect), 6 tuần (steady state, nơi ra quyết định quan trọng), và quarterly (tìm pattern hệ thống). Hai, viết review thành tài liệu có cấu trúc với phần xương sống là Goals vs Actuals đối chiếu thẳng với PRD, và kết bằng action items SMART có owner, deadline cùng một quyết định rõ ràng. Ba, giữ tinh thần blameless tuyệt đối — đào root cause vào hệ thống, không vào cá nhân, vì chỉ có sự trung thực mới tạo ra học hỏi thật.
PM giỏi không phải người ship nhiều nhất, mà là người để mỗi lần ship khiến phán đoán của mình và của cả team sắc bén hơn. Post-launch review chính là cơ chế để điều đó xảy ra một cách có kỷ luật.