Ở bài Làm nhiều (1), Py có nhắc đến 5 archetype mà Boris Cherny quan sát được trong chính team Claude Code: Prototyper, Builder, Sweeper, Grower, Maintainer. Nếu phải chọn 1 trong 5 archetype phù hợp nhất với PO/BA (hoặc thậm chí PM) ở thời điểm hiện tại thì câu trả lời của Py chắc chắn là Prototyper, nhưng trong bối cảnh có công ty một tháng release đến 3 models mới, thì chắc chắn Prototyper không phải là archetype duy nhất.

Rẽ nhánh sau Prototyper

Boris định nghĩa khá rõ: Prototyper là người ra ý tưởng, còn Builder là người build production – hai việc nghe gần nhau nhưng khoảng cách thật ra không nhỏ. Không cần biết code, AI vẫn có thể giúp một PO/BA biến ý tưởng thành bản demo chạy được – đủ để test hướng đi, đủ để thuyết phục stakeholder, đủ để tự mình cảm nhận trước khi giao cho người khác làm tiếp. Đó chính xác là Prototyper. Nhưng để biến bản demo đó thành thứ chịu được tải thật, bảo mật ổn, không sập khi số người dùng tăng lên – thì cần một tầng hiểu biết kỹ thuật nhất định. Trong bài Vibe Coding (1) trước đây, Py cũng từng đề cập đến quan điểm này: vibe code phát huy rõ nhất ở khâu làm prototype, còn khi cần vận hành ổn định ở quy mô lớn thì kiến trúc ban đầu – vốn không được hoạch định cho lượng traffic đó – sẽ bắt đầu gặp vấn đề.

Nên với Py, Prototyper có thể là lựa chọn khởi điểm, không phân biệt background kỹ thuật hay không. Còn sau Prototyper, hướng đi tiếp theo, theo Py, không nhất thiết chỉ có một ngả. Cụ thể, Py nghĩ có hai hướng: một là tiến về Builder – nếu PO/BA đầu tư thêm lớp hiểu biết kỹ thuật để tự tay đưa sản phẩm từ demo lên production thật; hai là tiến về Grower – nếu PO/BA vốn mạnh về đọc hành vi người dùng và tư duy tăng trưởng, thì dùng chính khả năng Prototyper để tự đặt hypothesis, tự dựng thử nghiệm A/B, … Cả hai hướng đều xuất phát từ cùng một điểm khởi đầu – khả năng biến ý tưởng thành thứ chạy thử được nhờ AI – chỉ khác chỗ mỗi người chọn đi tiếp theo thế mạnh sẵn có của mình.

(27/07/26) Nhân tiện, Py vừa thêm ở Home một tính năng nhỏ để bạn có thể tìm thấy những quan điểm phù hợp với mình, mời bạn trải nghiệm thử nha.

Về trang chủ

Phân hoá, không phải thu hẹp
(Phần này được tổng hợp với sự hỗ trợ của AI)

Quay lại chủ đề chính của Làm nhiều: nếu Prototyper là điểm khởi đầu chung, còn Builder và Grower là hai ngả rẽ theo thế mạnh, thì câu hỏi tiếp theo là, giữa lúc AI đang gánh bớt phần thực thi, cả nghề PO nói chung đang trôi về đâu?

Theo một bài phân tích gần đây của Userpilot, tính đến tháng 5/2026, số lượng job posting cho vị trí product management vẫn tăng 14% so với cùng kỳ năm trước, nhưng các công ty vẫn nhận định đang khó tuyển, một nghịch lý cho thấy nhu cầu không giảm, chỉ là tiêu chuẩn đã đổi¹. Ngoài ra, nghiên cứu của MIT được bài này trích lại cho thấy 95% các pilot AI trong doanh nghiệp chưa tạo ra ROI đo lường được, dù 64% product team (theo Pragmatic Institute) đã tích hợp AI vào sản phẩm của mình. Nói cách khác, biết dùng AI không còn là lợi thế, biết khi nào AI thật sự cần có mặt trong sản phẩm mới là năng lực tạo nên lợi thế cạnh tranh.

Riêng cho vị trí PM/PO thì Py chưa tìm được báo cáo ở Việt Nam, nhưng nhìn rộng ra cả ngành IT thì thấy đúng nghịch lý tương tự: theo IT Labor Market Report 2025 của TopDev, khoảng 43,3% doanh nghiệp nói nhu cầu tuyển dụng IT vẫn đang tăng, nhưng 53,7% lại than khó tìm ứng viên đúng kỹ năng, và gần 6 trong 10 doanh nghiệp (59,1%) đang tìm người có kỹ năng AI hoặc Machine Learning².

Ý kiến trái chiều
(Phần này được tổng hợp với sự hỗ trợ của AI)

Nhưng dừng ở Prototyper cũng có rủi ro riêng của nó. Marty Cagan, qua loạt bài A Vision For Product Teams, cho rằng vai trò Product Owner như đang tồn tại hiện tại sẽ dần bị AI và chính đội ngũ engineering “hấp thụ”, khi kỹ sư tự làm luôn phần discovery³. Andrew Ng thì tóm gọn theo cách khác: “Product management is becoming the new bottleneck” — quản lý sản phẩm đang trở thành nút thắt cổ chai mới, vì tốc độ ra quyết định của PM chưa theo kịp tốc độ code của AI.

Nhưng bức tranh không chỉ một chiều. Ngay trong bài Userpilot mà Py trích ở phần trên, chính tác giả cũng phản biện lại: nghề product năm 2026 chưa hề biến mất, chỉ là PM nào chuyển được từ việc tự tay vận hành (operating) một hệ thống AI sang việc điều phối cả hệ thống đó (governing) mới thật sự tạo ra lợi thế khó sao chép¹. Product Management Society cũng đưa ra góc nhìn tương tự: “AI isn’t replacing PMs. It’s sorting them by the kind of judgment they own” – AI không thay thế PM, nó đang phân loại PM theo loại phán đoán mà từng người nắm giữ. Cùng nguồn này ghi nhận số job posting yêu cầu “AI fluency” cho vị trí product đã tăng khoảng 7 lần từ 2024 đến 2026⁴ – không hẳn là dấu hiệu một nghề đang chết, mà là một nghề đang đổi hẳn tiêu chuẩn tuyển.

Rộng hơn, “trở thành nút thắt cổ chai mới” vốn không phải chuyện riêng của BA/PO/PM. Một nghiên cứu của Carnegie Mellon và Stanford, theo dõi 802 developer và hơn 196.000 pull request tại một công ty đang chạy chỉ tiêu tăng gấp đôi năng suất, cho thấy sản lượng code trên đầu người tăng 2,09 lần, nhưng khối lượng việc của mỗi reviewer cũng tăng gần gấp đôi theo⁵ – nút thắt không biến mất, chỉ dịch chuyển từ bàn phím sang khâu review. Nói cách khác, hễ AI làm nhanh hơn ở khâu tạo ra, thì khâu con người phải phán đoán và kiểm tra sẽ tự động trở thành nút thắt kế tiếp, bất kể đó là BA/PO/PM, kỹ sư senior review code, hay bất kỳ vai trò nào cần đưa ra quyết định tùy theo bối cảnh.

Với Py, những quan sát này, cả hai chiều, là lời nhắc rằng nếu PO/BA chỉ dùng AI để ra demo rồi vẫn giao hết phần “làm thật” cho người khác như trước giờ, dù là build hay growth, thì phần việc còn lại của mình sẽ ngày càng mỏng đi. Prototyper là điểm khởi đầu tốt, nhưng không phải điểm dừng an toàn.

Học, học nữa, học mãi

Nếu phải rút một điều từ tất cả những gì Py vừa kể, từ việc nghĩ lại Prototyper rồi mới tới Builder hay Grower, đến những con số về sự phân hoá của nghề này, thì đó không hẳn là bài học riêng của ngành product. Ngành nào cũng vậy: học không phải một giai đoạn để “xong” rồi mới đi làm, mà là một hành trình không có điểm dừng.

Chỉ là, với ngành product, nhất là trong giai đoạn công nghệ thay đổi nhanh hơn bất kỳ lúc nào Py từng chứng kiến, cái giá của việc ngừng học có vẻ đắt hơn hẳn. Archetype Py tự nhận hôm nay (Prototyper, còn rẽ về Builder hay Grower thì Py vẫn chưa chắc) vài năm nữa có khi lại không còn đúng, hoặc không còn đủ. Tool Py vừa quen tay tháng trước, tháng sau đã có bản thay thế nhanh và gọn hơn. Nên với Py, nguyên tắc đơn giản Py đang cố giữ cho mình là: đừng đợi đến khi cần mới học, cứ tự tay làm thử một thứ nho nhỏ, đều đặn, kể cả khi chưa ai yêu cầu. Vì suy cho cùng, thứ giữ Py “còn dùng được” trong nghề, có lẽ không phải một archetype cụ thể nào, mà là việc chưa từng ngừng học.

¹ Userpilot, 6 Product Management Trends in 2026: The PM Role Is Splitting

² TopDev, IT Labor Market Report 2025, dẫn lại qua 5 xu hướng mới nhất trong thị trường tuyển dụng IT 2026

³ Userpilot, Product Management in 2026: Is AI Product Management a Lie?

⁴ Product Management Society, Future of Product Management Beyond 2026

⁵ Generative Labs, AI Code Review Is the New Bottleneck, and the New Control Point

Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.

Chúc bạn nhiều may mắn và bình an.

Anpy