Mở đầu — vì sao bài này quan trọng
Trong các vòng Product Sense tại Big Tech, dạng câu hỏi "Improve X" (Hãy cải thiện một sản phẩm đang tồn tại) xuất hiện với tần suất ngang ngửa, thậm chí nhiều hơn dạng "Design X". Lý do rất thực tế: trong công việc PM hằng ngày, bạn hiếm khi xây sản phẩm từ con số không. Phần lớn thời gian bạn ngồi trên một sản phẩm đã có hàng triệu người dùng, có dữ liệu, có nợ kỹ thuật, có những trade-off đã được chốt từ trước — và nhiệm vụ của bạn là làm nó tốt hơn mà không phá vỡ những gì đang chạy. Vì thế, khi phỏng vấn viên hỏi "Improve X", họ đang mô phỏng đúng công việc thật của bạn.
Điều khiến nhiều ứng viên Việt Nam mất điểm ở dạng câu này không phải vì thiếu ý tưởng. Ngược lại, họ có quá nhiều ý tưởng và lao ngay vào "tôi sẽ thêm tính năng A, B, C". Đó chính là cái bẫy. "Improve X" không phải bài kiểm tra khả năng nghĩ ra tính năng — nó là bài kiểm tra khả năng quan sát (observation), khả năng chẩn đoán (diagnosis) và khả năng ưu tiên vấn đề trước khi đụng tới giải pháp. Một bác sĩ giỏi không kê thuốc ngay khi bệnh nhân vừa bước vào phòng; họ hỏi triệu chứng, khám, rồi mới chẩn đoán. Bài này dạy bạn tư duy như bác sĩ đó.
Khái niệm cốt lõi
"Improve X" khác "Design X" ở chỗ nào
Ở Bài 15 bạn đã học dạng "Design X for Y" — nơi bạn được tự do định nghĩa người dùng, vẽ ra hành trình lý tưởng và sáng tạo gần như từ trang giấy trắng. "Improve X" thì ngược lại: sản phẩm đã tồn tại. Điều này tạo ra ba khác biệt nền tảng.
Thứ nhất, có một trạng thái hiện tại mà bạn buộc phải hiểu trước khi đụng tay. Nếu bạn được hỏi "Cải thiện tính năng Reels của Instagram", bạn không thể giả vờ Reels chưa từng có. Bạn phải thể hiện rằng bạn đã dùng nó, biết nó hoạt động ra sao, ai đang dùng, và chỗ nào đang gãy.
Thứ hai, đã tồn tại nghĩa là có dữ liệu và ràng buộc. Sản phẩm thật có metric, có nhóm người dùng đang phụ thuộc vào hành vi hiện tại. Mọi thay đổi đều có rủi ro làm hỏng trải nghiệm của ai đó. Phỏng vấn viên muốn thấy bạn ý thức được điều này.
Thứ ba, và quan trọng nhất: phỏng vấn viên muốn thấy observation skill — kỹ năng quan sát. Trước khi bạn được phép đề xuất giải pháp, bạn phải chứng minh rằng bạn nhìn ra vấn đề thật. Một ứng viên nói "Tôi sẽ thêm nút chia sẻ" thì tầm thường. Một ứng viên nói "Tôi để ý rằng ở bước thanh toán, người dùng phải nhập lại địa chỉ dù đã lưu hồ sơ — đây là điểm rơi (drop-off) lớn" thì cho thấy họ thật sự nhìn sản phẩm bằng con mắt PM.
Ba câu hỏi mà phỏng vấn viên đang thầm chấm điểm
Khi bạn trả lời "Improve X", người ngồi đối diện đang ngầm đánh giá ba thứ:
- Bạn có thật sự hiểu sản phẩm và người dùng không? Hay bạn chỉ nói chung chung về một sản phẩm bạn chưa từng dùng nghiêm túc?
- Bạn có chọn đúng vấn đề để giải không? Trong vô số thứ có thể cải thiện, bạn có biết đâu là chỗ đáng làm nhất theo mục tiêu kinh doanh?
- Giải pháp của bạn có gắn với vấn đề đã chẩn đoán không? Hay bạn nhảy cóc tới một tính năng hào nhoáng không liên quan?
Khung "mục tiêu trước, vấn đề sau, giải pháp cuối"
Cốt lõi của dạng này là tuân thủ một thứ tự không được đảo: Goal → User → Problem → Solution → Prioritize → Metric. Khác biệt lớn nhất so với "Design X" là bạn dành nhiều thời gian hơn cho phần quan sát và chẩn đoán (User + Problem), và bạn luôn neo mọi đề xuất vào một mục tiêu cải thiện cụ thể mà bạn tự chọn — ví dụ "tăng retention", "tăng độ phủ ở thị trường nông thôn", hay "giảm chi phí hỗ trợ". Không có mục tiêu, "cải thiện" trở thành một bãi ý tưởng rời rạc.
Tình huống thực tế
Ví dụ 1 — Cải thiện Grab Food cho người dùng tỉnh lẻ Việt Nam
Giả sử phỏng vấn viên hỏi: "Hãy cải thiện GrabFood." Một ứng viên yếu sẽ nói ngay: "Tôi thêm tính năng đặt nhóm, thêm ví thưởng, thêm livestream món ăn." Ứng viên giỏi làm khác.
Đầu tiên họ chọn mục tiêu: "Tôi giả định GrabFood đã bão hòa ở TP.HCM và Hà Nội, nên mục tiêu cải thiện của tôi là tăng tỷ lệ đặt đơn lặp lại ở các thành phố cấp 2 như Cần Thơ, Đà Nẵng, Vinh." Rồi họ quan sát: "Khi tôi dùng GrabFood ở tỉnh, tôi thấy ba vấn đề. Một, danh sách quán mỏng nên người dùng mở app rồi đóng vì không có món muốn ăn. Hai, phí giao hàng so với giá món ở tỉnh chiếm tỷ trọng cao hơn ở thành phố lớn, gây cảm giác đắt. Ba, thời gian giao lâu vì ít tài xế." Đây là phần observation — họ mô tả triệu chứng cụ thể, không nói chung chung.
Tiếp theo họ chẩn đoán và ưu tiên: "Trong ba vấn đề, tôi cho rằng 'danh sách quán mỏng' là gốc rễ, vì nó tạo vòng xoáy: ít quán → ít đơn → tài xế không mặn mà → giao lâu → người dùng bỏ. Tôi sẽ tập trung vào nguồn cung quán." Giải pháp của họ — chương trình onboard quán địa phương với phí hoa hồng 0% trong 2 tháng đầu, kèm gói chụp ảnh món miễn phí — gắn chặt với vấn đề đã chẩn đoán.
Bài học: Sức mạnh không nằm ở giải pháp mà ở chuỗi quan sát → chẩn đoán nguyên nhân gốc → ưu tiên. Giải pháp chỉ là hệ quả tự nhiên.
Ví dụ 2 — Cải thiện tính năng Stories của Instagram
Phỏng vấn viên hỏi: "Cải thiện Instagram Stories." Ứng viên bắt đầu bằng việc làm rõ phạm vi: "Anh muốn em cải thiện cho người sáng tạo nội dung (creator) hay người xem (viewer)? Em sẽ chọn người xem, vì nhóm này đông hơn và quyết định tổng thời gian sử dụng." Đây là một bước nhỏ nhưng cho thấy bạn không tham lam ôm cả thế giới.
Sau đó họ quan sát hành vi xem Stories: "Tôi nhận thấy khi xem chuỗi Stories, người dùng thường tap liên tục để bỏ qua những story nhàm chán của tài khoản họ không thật sự quan tâm. Hành vi 'tap để skip' liên tục cho thấy nội dung hiển thị chưa khớp với mức độ quan tâm." Vấn đề được chẩn đoán: thứ tự hiển thị Stories chưa được cá nhân hóa đủ tốt theo mức độ thân thiết.
Giải pháp gắn với chẩn đoán: ưu tiên Stories của những tài khoản người dùng tương tác nhiều nhất lên đầu, và gom nhóm những tài khoản ít tương tác vào một cụm "xem nhanh". Họ cũng nói rõ trade-off: làm vậy có thể giảm lượt xem của creator nhỏ, nên cần theo dõi metric phân phối tương tác giữa các creator, tránh làm tổn thương hệ sinh thái.
Bài học: Quan sát một hành vi cụ thể (tap để skip) mạnh hơn nhiều so với phát biểu trừu tượng ("Stories nên hấp dẫn hơn"). Và việc tự nêu trade-off cho thấy độ chín của tư duy PM.
Ví dụ 3 — Cải thiện ứng dụng ngân hàng số tại Việt Nam (bối cảnh thật)
Một ứng viên phỏng vấn cho vị trí PM tại một ngân hàng số như TPBank hoặc Techcombank được hỏi: "Cải thiện app ngân hàng của chúng tôi." Họ chọn mục tiêu giảm tỷ lệ gọi tổng đài vì đây là chi phí lớn và phản ánh trải nghiệm gãy. Họ quan sát: "Người dùng lớn tuổi thường gọi tổng đài để hỏi 'tiền của tôi đã chuyển chưa', vì sau khi bấm chuyển khoản, màn hình xác nhận trông giống màn hình đang xử lý, gây hoang mang." Vấn đề được chẩn đoán: phản hồi trạng thái sau giao dịch không đủ rõ ràng và trấn an.
Giải pháp: thiết kế lại màn hình xác nhận với dấu tích lớn màu xanh, dòng chữ "Đã chuyển thành công" cỡ to, và nút "Xem biên lai". Họ ưu tiên việc này trên cả việc thêm tính năng đầu tư mới, vì nó tác động trực tiếp tới chi phí vận hành và lòng tin.
Bài học: Trong môi trường Việt Nam, quan sát đúng nhóm người dùng đặc thù (người lớn tuổi, người ít rành công nghệ) là một lợi thế cực lớn — và nó thể hiện observation skill mà phỏng vấn viên nước ngoài rất ấn tượng.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho bất kỳ câu "Improve X" nào trong 25–30 phút phỏng vấn.
Bước 1 — Làm rõ và chọn mục tiêu (2–3 phút). Hỏi lại: cải thiện theo hướng nào? Tăng trưởng người dùng, retention, doanh thu, hay trải nghiệm? Nếu phỏng vấn viên để bạn tự quyết, hãy tuyên bố rõ: "Em chọn mục tiêu tăng retention 30 ngày, vì đây là chỉ số sống còn của sản phẩm này." Mục tiêu này sẽ là kim chỉ nam để ưu tiên về sau.
Bước 2 — Quan sát sản phẩm hiện tại (4–5 phút). Đây là phần làm bạn khác biệt. Mô tả sản phẩm hiện tại đang vận hành thế nào, ai đang dùng, và quan trọng nhất: bạn đã quan sát thấy những điểm gãy cụ thể nào. Hãy nói như người thật sự đã dùng sản phẩm. Dùng câu mở đầu kiểu "Khi tôi dùng X, tôi để ý rằng…".
Bước 3 — Liệt kê và phân nhóm vấn đề (3–4 phút). Gom các điểm gãy thành 3–4 vấn đề rõ ràng. Tránh trộn lẫn triệu chứng với nguyên nhân. Cố gắng tìm nguyên nhân gốc — chỗ mà nếu giải được sẽ kéo theo nhiều thứ khác.
Bước 4 — Ưu tiên một vấn đề để giải (2 phút). Chọn một vấn đề duy nhất, biện minh tại sao nó đáng làm nhất theo mục tiêu ở Bước 1 (tác động lớn, khả thi, gắn với mục tiêu). Việc chọn một vấn đề thay vì giải tất cả là dấu hiệu của một PM có kỷ luật.
Bước 5 — Đề xuất 2–3 giải pháp cho vấn đề đó (4–5 phút). Đưa nhiều phương án, từ giải pháp nhanh-gọn tới giải pháp tham vọng, rồi chọn một và giải thích lý do. Mỗi giải pháp phải truy ngược được về vấn đề đã chẩn đoán.
Bước 6 — Nêu trade-off và cách đo lường (3 phút). Mọi thay đổi đều có cái giá. Ai có thể bị ảnh hưởng tiêu cực? Và bạn sẽ đo thành công bằng metric nào? Phần metric chi tiết bạn sẽ học sâu ở Bài 22, nhưng ở đây chỉ cần nêu một metric chính khớp với mục tiêu.
Bước 7 — Tóm tắt (1 phút). Gói lại: mục tiêu, vấn đề đã chọn, giải pháp, và metric. Một bản tóm tắt gọn cho thấy bạn kiểm soát được mạch trình bày.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào giải pháp. Đây là lỗi phổ biến nhất. Bạn nghe "improve" và bộ não bật ngay sang "thêm tính năng". Hãy ép mình dừng lại và quan sát trước. Mẹo: luôn nói thành tiếng "Trước khi đề xuất giải pháp, em muốn quan sát sản phẩm hiện tại đã" — câu này vừa câu giờ suy nghĩ, vừa ghi điểm về quy trình.
Lỗi 2 — Cải thiện một sản phẩm mình chưa từng dùng. Nếu được hỏi về một sản phẩm xa lạ, đừng giả vờ. Hãy hỏi phỏng vấn viên vài câu về cách nó hoạt động, hoặc nói rõ giả định của bạn. Sự trung thực cộng khả năng đặt câu hỏi tốt vẫn hơn việc bịa ra trải nghiệm.
Lỗi 3 — Liệt kê 10 ý tưởng mà không ưu tiên. Số lượng ý tưởng không phải điểm cộng. Một PM giỏi được nhận ra qua việc nói "không" với 9 ý để dồn lực vào 1. Hãy luôn chọn và biện minh.
Lỗi 4 — Bỏ qua trade-off. Nói "giải pháp của tôi hoàn hảo" là tín hiệu thiếu chín chắn. Mọi thay đổi trên sản phẩm thật đều làm phật lòng một nhóm nào đó. Chủ động nêu ra ai bị ảnh hưởng cho thấy bạn nghĩ như người vận hành sản phẩm thật.
Mẹo vàng — Dùng dữ liệu giả định một cách thông minh. Bạn không có số liệu thật, nhưng bạn có thể nói "Giả sử retention 30 ngày hiện tại là 40%, và tôi tin điểm rơi lớn nhất nằm ở tuần đầu tiên." Việc dám đặt con số giả định cho thấy bạn tư duy định lượng, miễn là bạn nói rõ đó là giả định.
Mẹo — Phân biệt rõ "cải thiện trải nghiệm" và "cải thiện chỉ số kinh doanh". Đôi khi hai thứ này xung đột. Một PM trưởng thành biết gọi tên sự căng thẳng đó thay vì giả vờ mọi thứ đều thắng-thắng.
Bài tập thực hành
- Khởi động quan sát. Chọn một app bạn dùng hằng ngày (Zalo, Shopee, Spotify). Trong 10 phút, ghi ra 5 điểm gãy cụ thể bạn quan sát được khi dùng — bắt đầu mỗi câu bằng "Khi tôi dùng…". Đừng đề xuất giải pháp, chỉ quan sát.
- Chẩn đoán nguyên nhân gốc. Lấy 5 điểm gãy ở trên, nhóm chúng lại và tìm xem có vấn đề gốc nào gây ra nhiều điểm gãy cùng lúc không. Viết một câu mô tả nguyên nhân gốc đó.
- Mô phỏng đầy đủ. Tự đặt giờ 25 phút và trả lời miệng câu "Cải thiện Shopee cho người bán nhỏ lẻ". Đi đủ 7 bước trong phần Hướng dẫn. Ghi âm lại và nghe xem bạn có vô tình nhảy thẳng vào giải pháp không.
- Luyện trade-off. Với giải pháp bạn vừa đề xuất ở bài 3, viết ra ít nhất hai nhóm người dùng có thể bị ảnh hưởng tiêu cực và cách bạn sẽ theo dõi tác hại đó.
Tóm tắt
Dạng câu "Improve X" không kiểm tra xem bạn nghĩ ra được bao nhiêu tính năng — nó kiểm tra xem bạn có quan sát được sản phẩm thật, chẩn đoán đúng vấn đề, và ưu tiên đúng chỗ hay không. Khác với "Design X" vốn cho bạn trang giấy trắng, "Improve X" đặt bạn lên một sản phẩm đang chạy với người dùng thật, dữ liệu thật và ràng buộc thật — đúng như công việc PM hằng ngày. Hãy ghi nhớ thứ tự bất di bất dịch: chọn mục tiêu trước, quan sát và chẩn đoán vấn đề, ưu tiên một vấn đề, rồi mới đề xuất giải pháp gắn chặt với chẩn đoán đó, kèm trade-off và metric. Sai lầm chết người nhất là nhảy thẳng vào "tôi sẽ thêm tính năng". Hãy tư duy như một bác sĩ giỏi: khám trước, kê thuốc sau. Khi bạn thể hiện được kỹ năng quan sát sắc bén — đặc biệt với những nhóm người dùng đặc thù của thị trường Việt Nam — bạn sẽ nổi bật ngay trong mắt phỏng vấn viên Big Tech.