Cuối tuần lướt Threads, Py đọc được post của Boris Cherny – người tạo ra Claude Code ở Anthropic. Boris quan sát rằng hiện tại các công việc engineering, product, design, data science đang “tan vào nhau” và hình thành một kiểu vai trò mới, nhìn vào chính team Claude Code, anh thấy nổi lên 5 archetype: Prototyper (ra ý tưởng), Builder (build production), Sweeper (tối ưu), Grower (lo Product-Market Fit), Maintainer (giữ hệ thống ổn định khi scale).

Trong đó có một quan điểm Py muốn highlight lại lần nữa: các archetype này không gắn với chức danh công việc. Title trên JD và cách bạn thực sự tạo ra giá trị, giờ là hai chuyện khác nhau.

Biết để dễ làm việc, và biết để làm được việc

Trùng hợp là cuối tuần trước, trong buổi Product Management Track tại Future Ready Program 2026, Py cũng vừa nhắc đến một ý gần vậy: vị trí product vốn đã là vị trí tương đối tổng quát – nó nằm giữa, làm việc với engineering, design, data, business, leadership, user. Cái khác của thời điểm này, theo Py quan sát, không phải là PO mới bắt đầu phải “tổng quát” – mà là biên độ tổng quát đó đang giãn rộng ra, và giãn nhanh hơn trước rất nhiều.

Trước đây ranh giới mờ thường dừng ở mức: PO hiểu sơ kỹ thuật để nói chuyện được với dev, designer hiểu sơ data để đọc được dashboard. Còn giờ, cái Py thấy rõ trong vài tháng gần đây là kiêm nhiệm thật, không chỉ là “hiểu sơ” – Dev tự làm luôn QC vì AI giúp viết test case nhanh hơn chờ một QC riêng review; PO tự nhảy vào làm growth vì AI giúp đọc data, vẽ funnel, đề xuất A/B test mà không cần đợi Data Analyst phân tích số liệu. Ranh giới không mờ theo kiểu “hiểu nhau hơn” nữa – mà mờ theo kiểu một người thật sự làm được phần việc từng thuộc về vai trò khác. Nên với Py, khung 5 archetype của Boris không mô tả một xu hướng tương lai xa, mà mô tả đúng cái đang xảy ra ngay trong công việc hàng ngày của Py.

Nhưng cần nói thêm một điều trước khi đi tiếp, vì chữ “kiêm nhiệm” dễ bị hiểu lệch. Kiêm nhiệm mà Py đang nói không phải là chuyện một người gánh việc của hai vị trí vì công ty thiếu người – scope tăng nhưng thời gian, quyền hạn và đãi ngộ không tăng theo. Đó là kiêm nhiệm bị ép, và nó khác hoàn toàn. Cái Py thấy đang xảy ra là: khả năng tự đi thêm được vài bước trong chuỗi tạo ra sản phẩm mà trước đây bắt buộc phải chờ người khác xử lý – vì công cụ mới đã giúp giảm chi phí học và thực thi xuống đủ để một người không còn phải tạm dừng và chuyển giao. Trọng tâm là tăng mức độ tự chủ và giảm số lần handoff – không phải ôm thêm việc.

“Điểm thâm nhập”

Nói vậy không có nghĩa là PO nào cũng nên kiêm nhiệm giống nhau. Theo Py, hướng kiêm nhiệm hợp lý nhất là hướng đi từ thế mạnh sẵn có của mỗi người, không phải đi từ một danh sách kỹ năng “phải học” chung cho tất cả. Và nhiều quan sát trong ngành cũng đang chỉ ra điều đó: thay vì co lại thành một vài hướng cố định, vai trò PM được nhiều người trong ngành mô tả là đang phân nhánh theo rất nhiều trục khác nhau cùng lúc – có người đi sâu vào kỹ thuật và AI, có người dịch chuyển hẳn về phía growth, lifecycle, monetization¹, và còn nhiều trục khác nữa mà Py chưa kịp nhắc tới trong bài này.

Hai ví dụ dưới đây chỉ là hai trục Py thấy gần với các anh chị em đang làm product mà Py được tiếp xúc trong hành trình làm nghề.

  • PO nào vốn mạnh về business sense và UX – quen đọc hành vi người dùng, quen brainstorm câu chuyện sản phẩm – thì hướng tự nhiên là tập dần mindset xử lý các bài toán growth: đọc funnel, đặt hypothesis cho A/B test, tự diễn giải số liệu trước khi đưa cho team data review lại. Đây là mở rộng từ cái đã có sẵn (hiểu user, hiểu business), không phải học từ số 0.
  • PO nào gốc kỹ thuật hơn – ví dụ xuất phát từ ITBA – thì hướng tự nhiên hơn lại là QC automation: viết test script, tự động hoá regression test, dùng AI hỗ trợ generate test case từ acceptance criteria mình đã viết. Vẫn là mở rộng từ cái nền sẵn có (đọc được logic, hiểu hệ thống), chỉ là đi xa hơn một bước.

Nhìn tổng quan, Py nghĩ không nên “để trứng vào một rổ” – nghĩa là không nên chỉ giỏi đúng một việc và mong nó mãi đủ. Nhưng nhìn vào chi tiết, hướng kiêm nhiệm nên đi theo thế mạnh sẵn có, không phải chỉ đơn giản là chạy trend chung của thị trường.

Nghĩ sâu hơn

Phần cần được nghiền ngẫm kỹ hơn, theo Py, không phải thêm một kỹ năng trên CV hay biến “PO thành dev” hay “Dev thành product” – mà là khoảng cách giữa có ý tưởngthấy ý tưởng chạy được đang ngắn lại rất nhiều. Trước đây khoảng cách đó đi qua nhiều người, nhiều vai trò, nhiều lần chờ đợi. Giờ với một PO biết tận dụng AI đúng chỗ, khoảng cách đó có khi chỉ còn một mình Py, trong một buổi chiều.

Nhưng nói thật, Py không nghĩ câu chuyện kiêm nhiệm này nên dừng lại ở AI, ở Boris, hay ở bất kỳ archetype nào trong bài. Suy cho cùng, AI chỉ là chất xúc tác mới nhất cho một thứ vốn đã đúng từ lâu: không ai làm mãi một nghề. Nhất là trong ngành công nghệ – ngành mà tốc độ thay đổi vốn đã nhanh hơn hầu hết các ngành khác, không phải tự nhiên mà Future of Jobs Report 2025 của World Economic Forum dự báo 59 trên 100 người lao động toàn cầu sẽ cần được reskill hoặc upskill trước năm 2030². Cái khung kỹ năng mà Py giỏi nhất hôm nay, vài năm nữa nhiều khả năng sẽ không còn là cái khung quan trọng nhất.

Vậy nên với Py, kiêm nhiệm không phải là một giai đoạn ngắn để “đu trend AI” rồi xong. Nó là cách Py tập làm quen với việc liên tục học thêm một lớp kỹ năng mới, từ một nền đã có sẵn, vì đây là một trong những con đường lành mạnh để người làm nghề liên tục thấy mình hữu dụng, trong một ngành mà luật chơi cứ vài năm (hoặc tháng) lại đổi một lần.


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

² World Economic Forum, Future of Jobs Report 2025


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


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

AI (15) finance (5)