Mở đầu — vì sao bài này quan trọng
Nếu vòng product sense và behavioral kiểm tra cách bạn suy nghĩ trực tiếp trước mặt phỏng vấn viên, thì take-home product exercise kiểm tra một thứ khác: cách bạn làm việc khi không ai nhìn. Đây là bài tập về nhà — công ty giao cho bạn một đề bài mở, cho bạn từ 3 đến 7 ngày để nộp một tài liệu strategy hoặc spec dài 3-5 trang, đôi khi kèm một buổi present 30 phút sau đó.
Vì sao càng ngày càng nhiều công ty Big Tech và scale-up tại Việt Nam, Singapore dùng format này? Lý do đơn giản: nó mô phỏng gần nhất công việc thật của một PM. Một PM thật không bao giờ giải case trong 20 phút trên whiteboard. PM thật ngồi viết PRD (Product Requirements Document), viết strategy memo, viết doc thuyết phục stakeholder — có thời gian để nghiên cứu, có thời gian để chỉnh sửa, và phải tự quyết định scope. Take-home đo đúng năng lực đó.
Nhưng đây cũng là vòng bị candidate Việt Nam đánh giá thấp nhiều nhất. Nhiều người nghĩ "có cả tuần rồi, viết gì chẳng được", rồi nộp một doc 8 trang lan man không có quan điểm, hoặc một doc 2 trang hời hợt thiếu chiều sâu. Cả hai đều trượt. Bài này sẽ chỉ cho bạn cách đọc đúng đề, cấu trúc đúng tài liệu, quản lý thời gian, và tránh những cái bẫy ẩn mà nhà tuyển dụng cố tình gài.
Khái niệm cốt lõi
Take-home thực chất đang đo cái gì
Đừng nhầm: phỏng vấn viên không chấm bạn dựa trên "câu trả lời đúng". Họ không có đáp án mẫu. Họ chấm bạn dựa trên bốn trục:
- Structured thinking (tư duy có cấu trúc): Bạn có đi từ vấn đề → mục tiêu → giải pháp → đo lường một cách logic không, hay nhảy thẳng vào tính năng?
- Product judgment (phán đoán sản phẩm): Bạn có dám đưa ra một quan điểm rõ ràng — chọn cái này, bỏ cái kia — và bảo vệ nó bằng lý lẽ không?
- Communication (truyền đạt): Một người bận rộn đọc doc của bạn trong 5 phút có nắm được luận điểm chính không? Có heading, có TL;DR, có hình minh hoạ không?
- Prioritization & scoping (xác định phạm vi): Bạn có biết tự cắt scope cho vừa, hay ôm đồm mọi thứ?
Các format phổ biến
Take-home thường rơi vào một trong các dạng sau:
- "Pick a feature for our product. Write a spec/PRD for it." — Bạn tự chọn một tính năng, viết tài liệu yêu cầu sản phẩm. Đây là dạng phổ biến nhất.
- "Write a 1-year strategy for product X." — Thiên về tư duy chiến lược, ít chi tiết tính năng hơn.
- "Improve metric Y by Z%." — Cho một mục tiêu số, bạn đề xuất các sáng kiến và lý giải tác động.
- "Critique our product and propose a roadmap." — Đánh giá sản phẩm hiện tại, đề xuất lộ trình.
- "Go-to-market plan for launching X." — Thiên về ra mắt và phân phối.
Cấu trúc một tài liệu thắng cuộc
Một strategy doc / PRD tốt cho take-home thường gồm các phần này, theo đúng thứ tự:
- TL;DR / Executive Summary (3-5 dòng): Tóm tắt vấn đề, đề xuất, và kết quả kỳ vọng. Đây là phần quan trọng nhất — nhiều reviewer chỉ đọc phần này kỹ.
- Assumptions (Giả định): Liệt kê rõ những gì bạn giả định vì đề bài không nói. Điều này thể hiện sự trưởng thành.
- Problem & Context (Vấn đề và bối cảnh): Ai là user? Pain point là gì? Vì sao đáng giải quyết bây giờ?
- Goals & Success Metrics (Mục tiêu và chỉ số thành công): Bạn muốn đạt gì, đo bằng metric nào.
- Solution / Proposal (Giải pháp): Đề xuất cụ thể, kèm các phương án thay thế đã cân nhắc và lý do loại bỏ.
- Prioritization (Ưu tiên): Nếu nhiều ý tưởng, dùng một framework để chọn (sẽ học sâu ở bài RICE/ICE).
- Risks & Open Questions (Rủi ro và câu hỏi mở): Điều gì có thể sai, bạn cần thêm dữ liệu gì.
- Rollout / Next steps (Triển khai): MVP ra sao, đo thế nào, mở rộng thế nào.
Tình huống thực tế
Ví dụ 1: Take-home của một fintech tại TP.HCM (đề "Pick a feature")
Minh, một PM có 3 năm kinh nghiệm, ứng tuyển vị trí Senior PM tại một ví điện tử lớn ở Việt Nam (gọi là VPay). Đề bài: "Chọn một tính năng mới cho VPay nhằm tăng tỷ lệ giữ chân người dùng (retention). Viết một PRD 4 trang. Bạn có 5 ngày."
Sai lầm đầu tiên Minh suýt mắc: anh định viết về "thêm chatbot AI" vì nghe thời thượng. Nhưng anh dừng lại và tự hỏi: retention của ví điện tử rớt ở đâu? Anh giả định (và ghi rõ trong phần Assumptions) rằng nhóm user rời bỏ nhiều nhất là người dùng mới sau tháng đầu, vì họ chỉ nạp tiền một lần rồi quên. Từ đó anh chọn tính năng "Gói tiết kiệm tự động chia nhỏ" — mỗi lần user thanh toán, hệ thống làm tròn lên và bỏ phần lẻ vào một hũ tiết kiệm sinh lời nhẹ.
Anh viết PRD gọn: TL;DR nói rõ "tăng D30 retention thêm 6-8 điểm phần trăm bằng cách tạo lý do quay lại hằng ngày". Phần metric: North Star là số user có ít nhất một giao dịch tiết kiệm trong 7 ngày. Anh nêu hai phương án thay thế (điểm thưởng, cashback) và giải thích vì sao tiết kiệm tạo "hook" bền hơn cashback đốt tiền.
Bài học: Minh thắng vòng này không phải vì ý tưởng độc đáo, mà vì anh kết nối tính năng với một insight về user và một metric đo được, và dám nói rõ giả định. Reviewer ghi chú: "Có quan điểm, biết tự thu hẹp phạm vi."
Ví dụ 2: Đề strategy của một công ty SaaS Singapore (làm quá tay)
Lan ứng tuyển PM tại một startup B2B SaaS ở Singapore. Đề: "Viết chiến lược 12 tháng giúp chúng tôi mở rộng từ SME sang khách hàng enterprise." Lan rất giỏi và rất chăm — chị nộp một tài liệu 14 trang, có cả phân tích đối thủ chi tiết, 3 personas đầy đủ, sơ đồ kiến trúc kỹ thuật.
Kết quả: chị bị loại. Feedback của hiring manager: "Doc quá dài, tôi không tìm thấy luận điểm chính trong 5 phút. Cảm giác như bạn không biết cái gì quan trọng nhất."
Vấn đề không phải Lan thiếu năng lực — mà là chị thiếu prioritization và communication. Một chiến lược 12 tháng cần một luận điểm sắc: ví dụ "Chúng ta nên đánh vào phân khúc mid-market trước, không nhảy thẳng lên enterprise, vì sales cycle ngắn hơn và sản phẩm hiện tại đã gần đủ." Thay vào đó chị dàn trải đều mọi thứ, không có thứ tự ưu tiên.
Bài học: Độ dài không phải thước đo chất lượng. Reviewer là người bận. Một doc 4 trang sắc bén luôn thắng một doc 14 trang đều đều. Nếu bắt buộc phải đưa nhiều chi tiết, hãy đẩy chúng xuống Appendix và giữ phần chính ngắn gọn.
Ví dụ 3: Đề "improve metric" cho một sàn TMĐT Đông Nam Á
Đức nhận take-home từ một sàn thương mại điện tử khu vực (kiểu Shopee/Lazada). Đề: "Đề xuất các sáng kiến tăng tỷ lệ chuyển đổi từ xem sản phẩm sang đặt hàng (view-to-order) lên 15%. Bạn có 3 ngày."
Đức làm một việc thông minh: thay vì liệt kê 10 ý tưởng ngang hàng, anh chia phễu (funnel) trước. Anh giả định phễu gồm: xem sản phẩm → thêm vào giỏ → bắt đầu thanh toán → hoàn tất. Anh ước lượng (ghi rõ là ước lượng) tỷ lệ rớt ở từng bước, và chỉ ra bước "bắt đầu thanh toán → hoàn tất" rớt nặng nhất, có thể do phí ship hiện quá muộn và phương thức thanh toán hạn chế.
Từ đó anh đề xuất 3 sáng kiến tập trung đúng bước nghẽn: hiện phí ship sớm trên trang sản phẩm, thêm trả góp 0%, và one-tap reorder. Mỗi sáng kiến anh gắn một ước lượng tác động thô và mức độ công sức.
Bài học: Khi đề cho một metric mục tiêu, đừng bắn ý tưởng tự do. Hãy phân rã metric thành phễu hoặc thành các thành phần trước, tìm điểm nghẽn lớn nhất, rồi mới đề xuất. Cách này cho thấy bạn tư duy bằng dữ liệu chứ không bằng cảm hứng.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng cho mọi take-home, giả sử bạn có 5 ngày:
Bước 0 — Đọc đề ba lần và làm rõ (30 phút, ngày 1). Gạch chân động từ và đối tượng: họ muốn "spec", "strategy", hay "critique"? Họ muốn dài bao nhiêu? Có deadline present không? Nếu đề thực sự mơ hồ ở điểm quan trọng, gửi email hỏi recruiter một, hai câu — điều này không bị trừ điểm, ngược lại thể hiện bạn biết hỏi đúng chỗ. Nhưng đừng hỏi những thứ bạn nên tự giả định.
Bước 1 — Nghiên cứu và đặt giả định (nửa ngày, ngày 1-2). Dùng thử sản phẩm của công ty nếu có thể. Đọc về thị trường, đối thủ. Viết ra danh sách giả định bạn sẽ dùng. Đây là lúc bạn quyết định scope — chọn MỘT vấn đề cụ thể thay vì cả vũ trụ.
Bước 2 — Vẽ khung doc trước khi viết chữ (1-2 giờ, ngày 2). Liệt kê các heading theo cấu trúc ở trên. Điền một câu cho mỗi phần. Lúc này bạn đã thấy được mạch logic và phát hiện lỗ hổng sớm, trước khi tốn công viết.
Bước 3 — Viết bản nháp đầy đủ (1 ngày, ngày 3). Viết nhanh, đừng cầu toàn câu chữ. Mục tiêu là có đủ nội dung. Ở phần giải pháp, luôn nêu ít nhất một phương án thay thế và lý do loại bỏ — đây là dấu hiệu của product judgment.
Bước 4 — Để nguội rồi cắt gọt (nửa ngày, ngày 4). Đọc lại với con mắt của reviewer bận rộn. Phần nào không phục vụ luận điểm chính thì cắt hoặc đẩy xuống Appendix. Viết lại TL;DR cho thật sắc. Thêm một bảng hoặc sơ đồ nếu nó giúp truyền đạt nhanh hơn.
Bước 5 — Soát chính tả, định dạng, nộp sớm (ngày 5). Đảm bảo heading nhất quán, không lỗi chính tả, file đúng định dạng họ yêu cầu (thường là PDF hoặc Google Doc link). Nộp trước deadline nửa ngày — đừng nộp phút chót, vừa rủi ro kỹ thuật vừa mất điểm chuyên nghiệp.
Bước 6 — Chuẩn bị cho buổi present (nếu có). Nhiều take-home có vòng present 30 phút. Hãy chuẩn bị nói được luận điểm trong 3 phút, và lường trước các câu hỏi "vì sao không làm X?". Reviewer thường thử thách quyết định của bạn để xem bạn bảo vệ hay sụp đổ.
Lỗi thường gặp & mẹo
Lỗi 1 — Không có quan điểm. Doc liệt kê đủ thứ nhưng không nói "tôi chọn cái này vì...". PM được trả lương để quyết định. Hãy luôn có một câu khẳng định rõ ràng và bảo vệ nó.
Lỗi 2 — Nhảy thẳng vào giải pháp. Bắt đầu bằng "tôi sẽ làm tính năng X" mà chưa nói user là ai, pain gì. Luôn đi từ problem trước.
Lỗi 3 — Viết quá dài. Như ví dụ của Lan. Nhắm 3-5 trang phần chính. Mọi thứ thừa đẩy xuống Appendix.
Lỗi 4 — Quên metric. Đề xuất tính năng nhưng không nói đo thành công thế nào. Luôn gắn mỗi đề xuất với chỉ số đo được.
Lỗi 5 — Không ghi giả định. Vì đề mơ hồ, bạn bắt buộc phải giả định. Việc ghi rõ giả định không phải điểm yếu — nó cho thấy bạn ý thức được những gì mình chưa biết.
Lỗi 6 — Đầu tư công sức sai chỗ. Vẽ mockup pixel-perfect trong khi luận điểm chiến lược còn lủng củng. Reviewer chấm tư duy, không chấm tài năng Figma.
Mẹo: Thêm một phần ngắn "What I'd do with more time / data" — nêu những gì bạn sẽ làm tiếp nếu có thêm thời gian và dữ liệu. Điều này biến giới hạn thời gian thành điểm cộng, cho thấy bạn biết doc này chỉ là bước đầu của một quá trình lớn hơn.
Mẹo về AI: Bạn có thể dùng AI để soát chính tả hay brainstorm, nhưng đừng để doc nghe như máy viết — chung chung, không có insight riêng về sản phẩm cụ thể của họ. Reviewer nhận ra ngay. Giá trị của bạn nằm ở phán đoán, không phải số chữ.
Bài tập thực hành
Hãy tự ra cho mình một take-home và làm trọn vẹn trong 3 ngày:
- Chọn đề: "Chọn một tính năng mới cho một ứng dụng bạn dùng hằng ngày tại Việt Nam (ví dụ Grab, MoMo, ZaloPay, Tiki) nhằm cải thiện một metric cụ thể bạn tự chọn. Viết PRD 4 trang."
- Ngày 1: Viết phần Assumptions và Problem & Context. Xác định rõ một user segment và một pain point. Chọn metric mục tiêu.
- Ngày 2: Viết phần Solution với ít nhất hai phương án thay thế và lý do chọn/loại. Viết phần Success Metrics và Risks.
- Ngày 3: Viết TL;DR sắc bén (tối đa 5 dòng), cắt gọt toàn bộ doc xuống đúng 4 trang, thêm một bảng hoặc sơ đồ phễu.
- Tự chấm: Đưa doc cho một người không biết gì về dự án, cho họ 5 phút đọc, rồi hỏi: "Luận điểm chính của tôi là gì? Tôi đề xuất gì và đo bằng cách nào?" Nếu họ trả lời trôi chảy, bạn đã đạt. Nếu họ ấp úng, doc của bạn chưa đủ rõ.
Tóm tắt
Take-home product exercise là vòng mô phỏng gần nhất công việc thật của một PM: cho bạn 3-7 ngày để viết một tài liệu strategy hoặc spec 3-5 trang từ một đề bài cố tình mơ hồ. Nó đo bốn thứ — tư duy có cấu trúc, phán đoán sản phẩm, khả năng truyền đạt, và năng lực xác định phạm vi.
Công thức thắng: đọc kỹ đề và làm rõ động từ chính, ghi rõ giả định, đi từ problem trước rồi mới đến solution, luôn có một quan điểm dám bảo vệ, gắn mỗi đề xuất với metric đo được, và giữ doc ngắn-sắc-có-TL;DR thay vì dài-dàn-trải. Như Minh đã thắng nhờ kết nối tính năng với insight và metric, như Lan đã trượt vì 14 trang không luận điểm, và như Đức đã nổi bật nhờ phân rã metric thành phễu trước khi đề xuất — sự khác biệt không nằm ở độ độc đáo của ý tưởng, mà ở độ rõ ràng của tư duy. Quản lý thời gian theo từng ngày, để doc nguội rồi cắt gọt, và nộp sớm. Đó là cách bạn biến một bài tập về nhà thành lời mời vòng tiếp theo.