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 PM cũng vấp phải: nhà tuyển dụng muốn bạn có "kinh nghiệm làm sản phẩm", nhưng không ai cho bạn cơ hội làm PM cho đến khi bạn đã có kinh nghiệm. Vòng lặp này khiến rất nhiều người mắc kẹt — đặc biệt là dân chuyển ngành từ marketing, business analyst, kế toán, kỹ sư hay vận hành. Bạn nộp đơn, bị loại ở vòng hồ sơ, rồi tự hỏi: "Làm sao có kinh nghiệm khi không ai thuê mình?"
Side project chính là chiếc đòn bẩy phá vỡ vòng lặp đó. Đây không phải là "việc làm thêm cho vui", mà là cách bạn tự tạo ra bằng chứng rằng mình có thể tư duy và hành xử như một PM — trước khi có ai trả lương cho bạn để làm điều đó.
Cụ thể, một side project tốt mang lại ba thứ mà CV chay không bao giờ có được:
- Demo product sense và năng lực execution: Bạn không nói suông "tôi có tư duy sản phẩm", bạn chỉ vào một thứ thật và nói "tôi đã tìm ra vấn đề này, phỏng vấn 12 người dùng, ưu tiên tính năng, và đây là kết quả".
- Chất liệu kể chuyện trong phỏng vấn: 80% câu hỏi behavioral và case study đều có thể trả lời bằng chính trải nghiệm làm side project của bạn. Bạn có câu chuyện thật để kể, không phải bịa.
- Nguyên liệu xây portfolio: Case study đầu tiên của bạn (thứ bạn học cách viết ở Bài 21) thường đến trực tiếp từ side project.
Khái niệm cốt lõi
Side project của PM khác gì side project của lập trình viên?
Đây là hiểu lầm tai hại nhất. Nhiều người chuyển nghề nghĩ rằng side project của PM nghĩa là phải tự code ra một app. Sai. Nếu bạn build một app nhưng không thể hiện được tư duy sản phẩm phía sau nó, bạn chỉ đang chứng minh mình biết code — và đó không phải việc của PM.
Một side project của PM phải thể hiện được quy trình tư duy sản phẩm, bao gồm: phát hiện vấn đề (problem discovery), nghiên cứu người dùng, định nghĩa giải pháp, ưu tiên (prioritization), và đo lường kết quả. Bản thân sản phẩm cuối có thể chỉ là một landing page, một bản Figma, một bot Telegram đơn giản, hay thậm chí một bản phân tích sâu về một app đang tồn tại. Cái nhà tuyển dụng đọc được là cách bạn suy nghĩ, không phải dòng code.
Bốn dạng side project phù hợp cho PM aspirant
- Build một sản phẩm nhỏ thật: Một MVP đơn giản giải quyết vấn đề có thật. Không cần biết code nhờ no-code tools (Glide, Bubble, Softr, Google Forms + Sheets). Mạnh nhất về mặt "execution" nhưng tốn công nhất.
- Teardown / phân tích sản phẩm: Bạn chọn một app (ví dụ MoMo, Shopee, Grab) và viết phân tích sâu: vấn đề người dùng, đánh giá UX, đề xuất cải tiến có lập luận. Rẻ về công sức, nhanh có kết quả, hợp với người mới.
- Cải tiến cho sản phẩm đang dùng: Bạn lấy một sản phẩm thật, xác định một điểm yếu, rồi thiết kế đề xuất tính năng đầy đủ (PRD, wireframe, success metrics) như thể bạn là PM của nó.
- Tham gia cộng đồng / hackathon với vai trò PM: Đóng vai PM trong một nhóm hackathon, một dự án nguồn mở, hoặc một product challenge.
Khung 5 tiêu chí để chọn project (SCOPE)
Tôi gợi ý bạn lọc ý tưởng qua khung SCOPE:
- S — Small enough (đủ nhỏ): Hoàn thành được trong 4–8 tuần với vài giờ mỗi tuần. Project lớn quá sẽ chết yểu.
- C — Care (bạn thật sự quan tâm): Bạn phải sống được với nó vài tuần liền vào buổi tối sau giờ làm. Không có động lực nội tại, bạn sẽ bỏ.
- O — Observable users (có người dùng quan sát được): Phải có người thật để phỏng vấn và quan sát, dù chỉ 5–10 người. Project không có người dùng = không có insight = không kể được chuyện.
- P — Provable outcome (kết quả chứng minh được): Phải có thứ gì đó đo được ở cuối — dù là 30 lượt đăng ký, 12 cuộc phỏng vấn, hay một bản PRD hoàn chỉnh.
- E — Explainable in 3 minutes (kể được trong 3 phút): Nếu bạn không tóm tắt được project trong 3 phút cho người phỏng vấn, nó quá phức tạp.
Tình huống thực tế
Tình huống 1: Linh — từ kế toán sang PM, chọn teardown thay vì build
Linh, 28 tuổi, làm kế toán 5 năm tại một công ty sản xuất ở Bình Dương, muốn chuyển sang PM. Cô không biết code và chỉ có khoảng 5 giờ rảnh mỗi tuần. Ban đầu Linh định học Bubble để tự build một app quản lý chi tiêu — nhưng sau 3 tuần loay hoay, cô mới hoàn thành được màn hình đăng nhập và gần như bỏ cuộc.
Cô đổi hướng. Thay vì build, Linh chọn dạng teardown: phân tích app quản lý tài chính cá nhân Money Lover (một sản phẩm Việt khá nổi tiếng). Tận dụng nền kế toán, cô làm điều người khác không làm được — phỏng vấn 9 người dùng thật (đồng nghiệp, bạn bè) về cách họ ghi chép chi tiêu, phát hiện ra rằng phần lớn bỏ app sau 2 tuần vì việc nhập tay quá cực. Cô viết một bản phân tích 6 trang: chỉ rõ điểm rơi (drop-off) ở khâu nhập liệu thủ công, đề xuất tính năng quét hóa đơn tự động, kèm wireframe vẽ bằng Figma và một bảng ưu tiên RICE.
Kết quả: bản teardown này trở thành case study chính trong portfolio của Linh. Trong phỏng vấn tại một startup fintech, cô dành trọn 15 phút kể về nó và được nhận vào vị trí Associate PM.
Bài học: Không biết code không phải rào cản. Teardown tận dụng đúng lợi thế domain (ở đây là tài chính) thường mạnh hơn một app tự build dở dang. Quan trọng là chiều sâu tư duy, không phải sản phẩm hào nhoáng.
Tình huống 2: Nhóm "ChợGần" — khi project bị scope quá lớn
Một nhóm 3 người (một dev, một designer, một marketer muốn làm PM tên Tuấn) quyết định build "ChợGần" — một super-app kết nối tiểu thương chợ truyền thống với người mua quanh khu phố, có cả đặt hàng, thanh toán, giao hàng, đánh giá. Nghe rất tham vọng.
Sau 3 tháng, họ chỉ ship được một bản đăng ký tiểu thương sơ sài, không có người dùng thật, và nhóm tan rã vì kiệt sức. Tuấn không có gì để kể trong phỏng vấn ngoài câu "bọn em định làm super-app nhưng không xong".
Giả sử Tuấn đóng vai PM tốt từ đầu, anh đã phải cắt scope tàn nhẫn: chỉ làm một việc — giúp người mua xem hôm nay sạp rau nào ở chợ Bà Chiểu còn hàng gì, qua một group Zalo + Google Form. Không app, không thanh toán. Chỉ cần 20 người dùng thử trong 2 tuần là đã có insight và con số để kể.
Bài học: Lỗi chết người nhất của PM mới là không biết cắt scope. Một super-app chết yểu kể câu chuyện tệ hơn nhiều so với một tính năng tí hon nhưng chạy thật, có người dùng thật, có số liệu thật. Nhà tuyển dụng đánh giá cao khả năng "ship small và học nhanh" hơn là tham vọng viển vông.
Tình huống 3: Minh — biến nỗi đau cá nhân thành project có người dùng
Minh là kỹ sư backend muốn chuyển sang PM. Anh bực bội với việc các nhóm chạy bộ trong công ty toàn dùng Excel để theo dõi quãng đường thi đua. Đó là một nỗi đau anh đang sống cùng — đúng tiêu chí "Care" và "Observable users".
Minh không build app phức tạp. Anh dùng Google Sheets + một Google Form + một con bot Telegram đơn giản (anh biết code nên tận dụng, nhưng giữ phạm vi cực nhỏ). Trong 5 tuần, 34 đồng nghiệp dùng công cụ của anh. Quan trọng hơn cả con số: Minh ghi lại nhật ký quyết định — vì sao anh không làm bảng xếp hạng cá nhân (sợ tạo áp lực tiêu cực, một insight đến từ 2 cuộc phỏng vấn người dùng), vì sao anh ưu tiên thông báo nhóm trước.
Khi phỏng vấn, Minh không khoe code. Anh kể về cái quyết định không làm tính năng — và đó chính xác là tư duy PM mà nhà tuyển dụng tìm kiếm.
Bài học: Project mạnh nhất thường xuất phát từ nỗi đau bạn đang sống cùng, vì bạn có sẵn động lực, người dùng và insight. Và với PM, quyết định không làm gì thường ấn tượng hơn danh sách tính năng đã làm.
Hướng dẫn từng bước
Bước 1 — Săn ý tưởng từ nỗi đau thật (tuần 0). Liệt kê 5–7 vấn đề bạn hoặc người quanh bạn gặp hàng tuần. Ưu tiên những vấn đề thuộc domain bạn có lợi thế từ ngành nguồn. Đừng nghĩ giải pháp vội — chỉ liệt kê vấn đề.
Bước 2 — Lọc qua khung SCOPE. Chấm điểm mỗi ý tưởng theo 5 tiêu chí Small / Care / Observable / Provable / Explainable. Chọn ý tưởng điểm cao nhất. Nếu phân vân giữa hai, chọn cái nhỏ hơn.
Bước 3 — Viết "1-pager" định nghĩa project. Một trang duy nhất gồm: vấn đề, đối tượng người dùng, giả thuyết, phạm vi (đặc biệt là những gì KHÔNG làm), và 1–2 chỉ số thành công. Đây là bài tập tư duy PM quan trọng nhất.
Bước 4 — Nói chuyện với 5–8 người dùng trước khi làm bất cứ gì. Đừng build hay vẽ gì cả. Phỏng vấn để xác nhận vấn đề có thật. (Kỹ thuật phỏng vấn người dùng bạn đã học ở Bài 20.) Rất có thể bạn sẽ đổi hướng sau bước này — đó là dấu hiệu tốt.
Bước 5 — Dựng phiên bản nhỏ nhất có thể. Dùng no-code (Glide, Softr, Google Forms), hoặc thậm chí làm "thủ công" (bạn tự xử lý đơn hàng bằng tay sau hậu trường). Mục tiêu là học, không phải hoàn hảo.
Bước 6 — Đưa cho người thật dùng và đo. Dù chỉ 10–20 người. Ghi lại số liệu: bao nhiêu đăng ký, bao nhiêu quay lại, rơi ở đâu.
Bước 7 — Ghi nhật ký quyết định xuyên suốt. Đây là khác biệt giữa người làm PM và người làm cho có. Mỗi khi bạn quyết định làm/không làm gì, viết một dòng: quyết định gì, vì sao, dựa trên dữ liệu nào. Nhật ký này là vàng cho phỏng vấn sau này.
Bước 8 — Đóng gói lại. Khi đạt mốc kết quả (hoặc hết 8 tuần), dừng lại và tổng hợp. Việc chuyển nhật ký này thành case study hoàn chỉnh là nội dung của Bài 21.
Lỗi thường gặp & mẹo
Lỗi 1 — Tưởng phải biết code. Như đã nói, no-code và teardown hoàn toàn đủ. PM được đánh giá ở tư duy, không ở kỹ năng kỹ thuật xây dựng.
Lỗi 2 — Scope quá lớn. Đây là lỗi số một (xem tình huống ChợGần). Quy tắc vàng: nếu không xong trong 8 tuần với vài giờ/tuần, project quá lớn. Cắt đến khi nó nhỏ một cách "đáng xấu hổ".
Lỗi 3 — Bỏ qua người dùng. Project không có người dùng thật chỉ là bài tập tưởng tượng. Không có người dùng = không có insight = không có gì để kể khác biệt với hàng trăm ứng viên khác.
Lỗi 4 — Chạy theo sự hoàn hảo. Bạn không cần app đẹp lung linh. Một sản phẩm xấu nhưng có 20 người dùng thật giá trị hơn một bản Figma lộng lẫy không ai chạm vào.
Lỗi 5 — Không ghi lại quá trình tư duy. Nhiều người làm xong project nhưng khi phỏng vấn chỉ nói được "em làm cái app này". Hãy ghi nhật ký quyết định ngay từ đầu — bạn sẽ quên rất nhanh.
Lỗi 6 — Chọn domain xa lạ. Đừng làm project về ngành y nếu bạn chưa từng đụng tới y tế. Chọn domain bạn có lợi thế tiếp cận người dùng và hiểu vấn đề.
Mẹo:
- Đặt deadline cứng (ví dụ 6 tuần) và công bố với một người bạn để tạo trách nhiệm.
- Dùng "Wizard of Oz" — giả lập tính năng phức tạp bằng cách tự làm thủ công sau hậu trường, để học nhanh mà không cần xây dựng.
- Ưu tiên chiều sâu một việc hơn chiều rộng nhiều việc. Một tính năng làm tới nơi tới chốn hơn năm tính năng nửa vời.
Bài tập thực hành
- Săn vấn đề (30 phút): Viết ra 7 vấn đề bạn hoặc người quanh bạn gặp hàng tuần, ưu tiên những vấn đề thuộc domain bạn có lợi thế từ ngành cũ.
- Chấm điểm SCOPE (20 phút): Lập bảng, chấm mỗi ý tưởng theo 5 tiêu chí Small / Care / Observable / Provable / Explainable trên thang 1–5. Chọn ý tưởng điểm cao nhất.
- Viết 1-pager (45 phút): Cho ý tưởng đã chọn, viết một trang gồm: vấn đề, người dùng mục tiêu, giả thuyết, 3 thứ bạn cố tình KHÔNG làm, và 1 chỉ số thành công cụ thể có con số.
- Lên lịch 5 cuộc phỏng vấn (tuần này): Liệt kê tên 5 người thật bạn sẽ phỏng vấn về vấn đề trên, và thời điểm cụ thể trong 7 ngày tới.
- Tự kiểm scope: Tự hỏi "tôi có hoàn thành được trong 8 tuần không?". Nếu lưỡng lự, cắt scope đi một nửa rồi viết lại 1-pager.
Tóm tắt
- Side project là cách bạn tự tạo bằng chứng về tư duy và năng lực PM khi chưa ai cho bạn chức danh PM, phá vỡ vòng lặp "không kinh nghiệm thì không được thuê".
- Side project của PM thể hiện quy trình tư duy sản phẩm (phát hiện vấn đề, nghiên cứu người dùng, ưu tiên, đo lường), không phải kỹ năng code. Teardown và no-code là lựa chọn hoàn toàn hợp lệ.
- Chọn project qua khung SCOPE: đủ nhỏ, bạn thật sự quan tâm, có người dùng quan sát được, có kết quả chứng minh được, kể được trong 3 phút.
- Ưu tiên domain bạn có lợi thế từ ngành nguồn, và những nỗi đau bạn đang sống cùng — vì sẵn động lực, người dùng và insight.
- Lỗi chết người nhất là scope quá lớn và bỏ qua người dùng thật. Một tính năng tí hon chạy thật với 20 người dùng đánh bại một super-app chết yểu.
- Ghi nhật ký quyết định xuyên suốt — đặc biệt những quyết định không làm gì — vì đó là chất liệu mạnh nhất cho portfolio (Bài 21) và phỏng vấn sau này.