Mở đầu — vì sao bài này quan trọng
Có một nghịch lý kinh điển mà gần như ai chuyển nghề sang Product Manager (PM) cũng vấp phải: nhà tuyển dụng muốn bạn có kinh nghiệm PM, nhưng không ai cho bạn kinh nghiệm PM nếu bạn chưa từng làm PM. Vòng luẩn quẩn "không có việc vì thiếu kinh nghiệm, thiếu kinh nghiệm vì không có việc" này khiến rất nhiều người tài năng bỏ cuộc giữa chừng.
Side project chính là chiếc chìa khóa để phá vỡ vòng luẩn quẩn đó. Bạn không cần ai cho phép mới được làm PM. Bạn có thể tự tạo ra một sản phẩm, tự đặt mình vào vai trò người dẫn dắt, và tự tích lũy đúng những trải nghiệm mà nhà tuyển dụng tìm kiếm: phát hiện vấn đề người dùng, ra quyết định ưu tiên, làm việc với người khác, đo lường kết quả.
Quan trọng hơn, side project tạo ra bằng chứng (proof) thay vì lời khẳng định (claim). Trong CV, ai cũng viết "tư duy sản phẩm tốt", "định hướng người dùng". Nhưng khi bạn nói "tôi đã xây một ứng dụng giúp 200 sinh viên đặt lịch học nhóm, và đây là cách tôi quyết định tính năng nào làm trước", người phỏng vấn buộc phải tin bạn — vì bạn có dữ liệu, có câu chuyện, có sản phẩm thật để chỉ vào.
Bài học này tập trung riêng vào side project như một công cụ xây dựng kinh nghiệm PM. Chúng ta sẽ không bàn về cách viết case study hay portfolio (đó là bài riêng), mà tập trung vào: tại sao side project hiệu quả, chọn project nào, và làm thế nào để biến nó thành kinh nghiệm PM thật chứ không chỉ là một dự án "vọc cho vui".
Khái niệm cốt lõi
Side project là gì trong bối cảnh PM?
Side project, hiểu đơn giản, là một dự án sản phẩm bạn tự khởi xướng và dẫn dắt bên ngoài công việc chính. Với người chuyển sang PM, side project không nhất thiết phải là một startup hoành tráng hay một app có hàng nghìn người dùng. Nó có thể nhỏ gọn, nhưng phải đủ "đầy đủ vòng đời" để bạn thực hành những kỹ năng cốt lõi của PM.
Điều khác biệt giữa một side project "kiểu PM" và một project "kiểu kỹ thuật" hay "kiểu vui" nằm ở chỗ: PM không quan tâm chủ yếu đến việc bạn code đẹp hay thiết kế lung linh, mà quan tâm đến bạn ra quyết định như thế nào. Một PM thật sự sẽ hỏi: Vấn đề người dùng là gì? Tại sao đáng giải quyết? Làm trước cái gì, bỏ qua cái gì? Đo lường thành công bằng chỉ số nào?
Tại sao học bằng cách làm (learning by doing) lại vượt trội?
Đọc sách về product management cho bạn từ vựng. Nhưng chỉ khi bạn thật sự phải quyết định "có nên thêm tính năng đăng nhập bằng Google không khi mà tôi chỉ có 3 tuần", bạn mới hiểu thế nào là đánh đổi (trade-off). Khi bạn phỏng vấn 5 người dùng và phát hiện giả định ban đầu của mình sai bét, bạn mới thấm thía vì sao PM phải khiêm tốn trước dữ liệu.
Side project ép bạn trải qua đầy đủ chu trình: phát hiện vấn đề → định nghĩa giải pháp → ưu tiên → làm việc với người khác (designer, dev, hoặc chính bạn kiêm nhiệm) → ra mắt → đo lường → học và lặp lại. Đây chính xác là vòng lặp mà một PM sống cùng mỗi ngày.
Bốn loại "nguyên liệu" PM mà side project tạo ra
Một side project tốt sẽ cung cấp cho bạn bốn thứ để mang vào phỏng vấn và CV:
- Câu chuyện ra quyết định — bạn đã ưu tiên thế nào, đánh đổi ra sao.
- Bằng chứng tiếp xúc người dùng — bạn đã nói chuyện với người dùng thật, rút ra insight thật.
- Con số — dù nhỏ: 150 lượt đăng ký, tỉ lệ giữ chân 30%, giảm 2 bước trong luồng thanh toán.
- Tư duy phản tỉnh — bạn rút ra bài học gì, lần sau làm khác đi thế nào.
Side project không bắt buộc phải tự code
Đây là hiểu lầm phổ biến nhất ở người Việt chuyển nghề. Nhiều người nghĩ "tôi không biết lập trình thì làm sao có side project". Sai. PM không phải là người viết code — PM là người định nghĩa cái gì đáng được xây và tại sao.
Bạn có thể làm side project bằng no-code (như Glide, Bubble, Softr), bằng cách hợp tác với một bạn dev, bằng cách tự thiết kế prototype trên Figma rồi đem đi test với người dùng, hoặc thậm chí vận hành một dịch vụ thủ công hoàn toàn (kiểu "concierge MVP" — bạn làm tay mọi thứ phía sau, người dùng tưởng có hệ thống). Cái nhà tuyển dụng cần thấy là tư duy sản phẩm, không phải dòng code.
Tình huống thực tế
Ví dụ 1: Minh — kế toán chuyển sang PM nhờ một bot Telegram quản lý chi tiêu
Minh, 28 tuổi, làm kế toán tại một công ty sản xuất ở Bình Dương, muốn chuyển sang PM nhưng CV trống trơn phần kinh nghiệm sản phẩm. Thay vì học thêm khóa học rồi rải CV, Minh quyết định làm một side project nhỏ trong 6 tuần.
Anh nhận thấy bạn bè quanh mình (dân văn phòng trẻ) luôn than phiền không kiểm soát được chi tiêu, nhưng lại lười mở app ngân hàng. Minh đặt giả thuyết: "Nếu việc ghi chi tiêu dễ như nhắn tin, người ta sẽ làm." Anh không biết code, nên dùng một nền tảng bot không cần lập trình sâu, dựng một bot Telegram cho phép gõ "trà sữa 35k" là tự động ghi nhận.
Điểm PM của câu chuyện không nằm ở cái bot. Nó nằm ở chỗ Minh phỏng vấn 8 người dùng đầu tiên, phát hiện ra rằng họ không cần biểu đồ phân tích phức tạp (giả định ban đầu của anh), mà chỉ cần một con số duy nhất: "tháng này tôi đã tiêu bao nhiêu". Anh cắt bỏ toàn bộ tính năng báo cáo cầu kỳ, tập trung vào trải nghiệm ghi nhanh. Sau 6 tuần, bot có 120 người dùng, trong đó 40% vẫn dùng sau 3 tuần.
Bài học rút ra: Khi phỏng vấn PM, Minh không kể "tôi làm một con bot". Anh kể "tôi có một giả định sai, dữ liệu người dùng chứng minh tôi sai, và tôi đã cắt scope để tập trung vào giá trị cốt lõi". Đó chính xác là tư duy ưu tiên (prioritization) và định hướng người dùng (user-centricity) mà nhà tuyển dụng PM khao khát. Minh được nhận vào vị trí Associate PM tại một startup fintech ở TP.HCM.
Ví dụ 2: Lan — nhóm phối hợp làm một công cụ nhỏ cho cộng đồng
Lan làm marketing, không biết kỹ thuật. Cô không tự làm một mình mà rủ một bạn dev và một bạn designer cùng làm một side project cuối tuần: một website giúp các quán cà phê nhỏ ở Đà Nẵng đăng menu và nhận đặt bàn qua link, thay vì phụ thuộc hoàn toàn vào các nền tảng giao đồ ăn ăn hoa hồng cao.
Vai trò của Lan là PM thực thụ: cô đi gặp 6 chủ quán, tổng hợp nỗi đau (hoa hồng 25-30% của app giao đồ ăn), viết ra một danh sách tính năng, rồi cùng nhóm quyết định chỉ làm 3 tính năng cho bản đầu tiên. Cô vẽ luồng người dùng đơn giản, viết "user story", và làm cầu nối giữa bạn dev và bạn designer khi hai người bất đồng về cách hiển thị menu.
Sản phẩm cuối cùng chỉ có 4 quán dùng thật. Con số rất khiêm tốn. Nhưng trải nghiệm của Lan thì cực kỳ giàu: cô đã trải qua xung đột nhóm, đã phải nói "không" với tính năng mà bạn dev rất muốn làm vì nó không giải quyết nỗi đau chính, đã học cách viết tài liệu để người khác hiểu.
Bài học rút ra: PM là nghề làm việc xuyên chức năng (cross-functional). Side project theo nhóm cho Lan đúng trải nghiệm đó — điều mà một project solo không bao giờ tạo ra được. Khi phỏng vấn câu behavioral "kể về lúc bạn xử lý bất đồng trong nhóm", Lan có câu chuyện thật, sống động, để kể.
Ví dụ 3: Cường — cải tiến một sản phẩm có sẵn thay vì làm từ đầu
Không phải ai cũng cần xây sản phẩm mới. Cường, một nhân viên chăm sóc khách hàng tại một sàn thương mại điện tử, làm một dạng side project rất thông minh: anh chọn một ứng dụng đang tồn tại (một app đặt lịch khám bệnh ở Việt Nam) và làm một bản product teardown — phân tích ngược sản phẩm.
Cường tự đăng ký, đi qua toàn bộ luồng đặt lịch, ghi lại mọi điểm khó chịu, phỏng vấn 5 người từng dùng app đó, rồi viết một đề xuất cải tiến: chỉ ra 3 vấn đề lớn nhất trong luồng đặt lịch, đề xuất giải pháp, ước lượng tác động, và sắp xếp ưu tiên theo khung impact/effort. Anh thậm chí vẽ lại vài màn hình trên Figma để minh họa.
Đây không phải side project "xây thật", nhưng nó chứng minh tư duy PM cực kỳ rõ. Khi nộp đơn vào một công ty trong lĩnh vực y tế số, Cường gửi kèm bản teardown này. Người phỏng vấn nói thẳng: "Bản phân tích của bạn cho thấy bạn suy nghĩ như một PM rồi, chỉ là chưa có chức danh."
Bài học rút ra: Nếu bạn không có thời gian, kỹ năng kỹ thuật, hay đồng đội để xây sản phẩm, một bản teardown nghiêm túc cũng là một side project hợp lệ. Nó rẻ về công sức nhưng giàu về tín hiệu tư duy.
Hướng dẫn từng bước
Dưới đây là quy trình để biến một ý tưởng thành một side project "kiểu PM" thực thụ trong khoảng 4–8 tuần.
Bước 1 — Chọn một vấn đề bạn thật sự hiểu. Đừng chọn vấn đề "to và sang" mà bạn không sống cùng. Hãy chọn nỗi đau bạn hoặc người quanh bạn gặp hằng ngày: sinh viên khó tìm bạn học nhóm, dân văn phòng quên uống nước, người mới đi làm khó theo dõi chi tiêu. Lợi thế của việc hiểu vấn đề là bạn phỏng vấn người dùng dễ hơn và đặt giả định sắc hơn.
Bước 2 — Viết một giả thuyết rõ ràng. Một câu duy nhất theo mẫu: "Tôi tin rằng [nhóm người dùng] gặp [vấn đề], và nếu tôi cung cấp [giải pháp], họ sẽ [hành vi mong đợi]." Viết ra để sau này bạn kiểm chứng được mình đúng hay sai.
Bước 3 — Phỏng vấn 5–8 người dùng tiềm năng TRƯỚC khi xây. Đây là bước người mới hay bỏ qua và là bước PM coi trọng nhất. Hỏi về vấn đề, đừng hỏi "bạn có thích ý tưởng của tôi không" (ai cũng lịch sự gật đầu). Hỏi: "Lần gần nhất bạn gặp việc này là khi nào? Bạn đã xử lý ra sao? Phiền phức nhất ở đâu?"
Bước 4 — Xác định phạm vi tối thiểu (MVP). Liệt kê mọi tính năng nghĩ ra, rồi tàn nhẫn cắt xuống còn 1–3 tính năng giải quyết đúng nỗi đau cốt lõi. Ghi lại lý do bạn cắt — chính cái lý do này là "vàng" khi phỏng vấn.
Bước 5 — Chọn cách hiện thực phù hợp năng lực. Tự code nếu biết; dùng no-code (Glide, Bubble, Softr) nếu không; làm prototype Figma rồi test; hoặc vận hành thủ công kiểu concierge. Đừng để rào cản kỹ thuật chặn bạn lại.
Bước 6 — Ra mắt nhỏ và đo lường. Đưa cho 10–50 người dùng thật. Chọn trước 1–2 chỉ số quan trọng: số người kích hoạt, tỉ lệ quay lại sau 1 tuần, số lần dùng/người. Con số nhỏ không sao, miễn là có con số thật.
Bước 7 — Phản tỉnh và ghi chép. Sau mỗi tuần, viết ngắn: tôi đã quyết định gì, dựa trên cái gì, kết quả ra sao, lần sau làm khác thế nào. Tập "nhật ký quyết định" này về sau biến thẳng thành nội dung phỏng vấn và case study.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến side project thành dự án kỹ thuật. Nhiều người dành 90% thời gian để code cho đẹp, học framework mới, tối ưu hiệu năng — và quên mất rằng nhà tuyển dụng PM không quan tâm điều đó. Mẹo: nếu bạn dành nhiều thời gian cho code hơn cho việc nói chuyện với người dùng và ra quyết định, bạn đang lệch hướng.
Lỗi 2 — Không bao giờ ra mắt vì cầu toàn. "Để xong nốt tính năng này đã rồi mới cho người dùng." Tính năng thì vô tận, còn động lực thì hữu hạn. Mẹo: đặt deadline ra mắt cứng ngay từ đầu, dù sản phẩm còn xấu. Ra mắt sớm để có dữ liệu thật còn quý hơn một sản phẩm hoàn hảo trong ngăn kéo.
Lỗi 3 — Chọn dự án quá to. "Tôi sẽ làm một Grab cho ngành giặt là." Quá lớn, không bao giờ hoàn thành, và bỏ dở giữa chừng còn tệ hơn không bắt đầu. Mẹo: chọn phạm vi nhỏ đến mức bạn chắc chắn ra mắt được trong 6 tuần.
Lỗi 4 — Không ghi lại quá trình ra quyết định. Sáu tháng sau, khi đi phỏng vấn, bạn chỉ nhớ "tôi từng làm cái gì đó". Mẹo: viết nhật ký quyết định ngắn mỗi tuần. Đây là khác biệt giữa "có làm side project" và "kể được câu chuyện PM thuyết phục".
Lỗi 5 — Bỏ qua hoàn toàn việc tiếp xúc người dùng. Xây dựa trên giả định trong đầu rồi tự huyễn hoặc. Mẹo: bắt buộc bản thân nói chuyện với ít nhất 5 người dùng trước khi viết dòng mã đầu tiên. Đây là kỹ năng PM số một mà phỏng vấn nào cũng kiểm tra.
Mẹo cộng thêm: Hãy chọn dự án bạn có chút đam mê thật, vì side project sống nhờ động lực nội tại — bạn làm nó sau giờ làm, cuối tuần, lúc mệt. Nếu bạn không quan tâm đến vấn đề, bạn sẽ bỏ cuộc ở tuần thứ ba.
Bài tập thực hành
- Săn vấn đề (30 phút). Viết ra 5 nỗi đau bạn hoặc người quanh bạn gặp hằng tuần. Với mỗi nỗi đau, ghi: ai gặp, gặp bao lâu một lần, hiện họ xử lý thế nào. Khoanh tròn cái mà bạn vừa hiểu rõ vừa có chút hứng thú.
- Viết giả thuyết (15 phút). Lấy vấn đề đã khoanh, viết một câu giả thuyết theo mẫu: "Tôi tin rằng [ai] gặp [vấn đề], và nếu tôi làm [giải pháp], họ sẽ [hành vi]."
- Lên lịch 5 cuộc phỏng vấn (tuần này). Nhắn 5 người trong nhóm người dùng tiềm năng, xin 15 phút mỗi người. Chuẩn bị 4 câu hỏi tập trung vào vấn đề (không hỏi về ý tưởng của bạn). Sau khi xong, viết 3 insight bất ngờ nhất.
- Cắt scope (20 phút). Liệt kê mọi tính năng bạn tưởng tượng, rồi cắt xuống còn tối đa 3, và viết một dòng giải thích vì sao mỗi tính năng bị cắt được cắt.
- (Thay thế nếu không có thời gian xây) Chọn một app Việt Nam bạn hay dùng, làm một bản teardown: đi qua một luồng chính, ghi 3 điểm khó chịu, đề xuất cải tiến và sắp xếp ưu tiên theo impact/effort. Đây là một side project hợp lệ ở quy mô nhỏ.
Tóm tắt
Side project là cách mạnh nhất để người chuyển nghề phá vỡ vòng luẩn quẩn "không có kinh nghiệm vì không được tuyển, không được tuyển vì không có kinh nghiệm". Nó biến lời khẳng định trong CV thành bằng chứng thật mà nhà tuyển dụng buộc phải tin.
Điều cốt lõi: side project "kiểu PM" không đo bằng độ đẹp của code hay quy mô người dùng, mà bằng chất lượng tư duy ra quyết định — bạn phát hiện vấn đề thế nào, phỏng vấn người dùng ra sao, ưu tiên và đánh đổi thế nào, đo lường bằng chỉ số gì, và rút ra bài học gì. Bạn không cần biết code: no-code, hợp tác nhóm, prototype Figma, hay teardown đều là những con đường hợp lệ.
Hãy chọn một vấn đề nhỏ bạn thật sự hiểu, viết giả thuyết, phỏng vấn người dùng trước khi xây, cắt scope tàn nhẫn, ra mắt sớm, đo lường, và ghi lại nhật ký quyết định. Sáu đến tám tuần sau, bạn sẽ không còn là "người muốn làm PM" — bạn sẽ là người có một câu chuyện sản phẩm thật để kể.