Thật là một câu đùa cũ rích rằng product manager là vai trò khó giải thích nhất cho bố mẹ. “Vậy con không code? Không design? Không bán hàng? Vậy con… làm gì?” Và câu trả lời thường kiểu như: “Con đảm bảo rằng chúng ta đang xây đúng thứ và mọi người đều aligned.” Điều đó đúng, nhưng… khó hiểu. “Con không quản lý con người à?” “À, có đôi khi nhưng không hẳn. Chủ yếu là quy trình…” Rất khó để giải thích.
Trớ trêu thay, trong thời đại “AI-pocalypse”, tôi cho rằng chính sự mơ hồ, khó định nghĩa của vai trò PM lại là điều khiến nó trở thành một trong những vị trí có lợi thế nhất để tận dụng AI.
Không phải engineer (dù họ chiếm hết spotlight AI). Không phải designer. Mà là product manager*. Cùng đi vào chi tiết.
Lợi thế chuyển đổi chế độ tư duy
Hầu hết các vai trò cho phép bạn ổn định trong một kiểu tư duy. Engineer nghĩ theo hệ thống và ràng buộc. Designer nghĩ theo trải nghiệm và affordance. Sales nghĩ theo objection và value proposition. Đây là những mode sâu, chuyên biệt và thực sự khó để phát triển. Nhưng chúng lại dễ bị tái tạo hơn chúng ta tưởng.
Product manager thì không bao giờ được “ổn định”. Trong vòng một giờ, bạn có thể chuyển từ tư duy ràng buộc (scope một spec kỹ thuật với các trade-off cứng), sang tư duy kể chuyện (pitch roadmap quý cho lãnh đạo), sang chế độ đồng cảm (tổng hợp điều khách hàng thực sự muốn nói), rồi sang phân tích cạnh tranh (đánh giá feature mới của đối thủ có thay đổi ưu tiên không). Mỗi cái không chỉ là khác audience, mà là một cách lý luận khác nhau về cùng một vấn đề.
Khả năng chịu đựng và thích nghi với việc chuyển context nhanh như vậy chính là kỹ năng cốt lõi phân biệt những người khai thác được giá trị thực từ AI với những người nói rằng họ “không làm nó làm theo ý mình được”.
Lấy output tốt từ model không phải là viết prompt thật chính xác về mặt kỹ thuật. Mà là hiểu mode nào phù hợp với tình huống. Khi tôi dùng Claude để hỗ trợ thiết kế kỹ thuật, tôi nghĩ theo constraint: “Đây là boundary hệ thống, đây là thứ không thể thay đổi, đây là mục tiêu tối ưu.” Khi cần positioning, tôi chuyển sang narrative: “Đây là thị trường cạnh tranh, đây là điểm khác biệt, đây là hook cảm xúc.” Khi dùng cho research synthesis, tôi ở mode nhận diện pattern: “Đây là 15 transcript, tìm các pain point lặp lại mà tôi chưa thấy.” Cùng một tool, nhưng hoàn toàn khác cách tiếp cận nhận thức mỗi lần.
Những người chỉ dùng một mode, prompt AI theo một cách duy nhất cho mọi thứ, sẽ nhận kết quả tầm thường rồi đổ lỗi cho model. Những người điều chỉnh framing theo outcome mong muốn sẽ nhận được nhiều hơn rất nhiều. Đây là lý do founder có mức hài lòng với AI cao nhất: 49% tiết kiệm hơn 6 giờ mỗi tuần, và use case lớn nhất của họ không phải viết tài liệu mà là “productivity và decision support” (32.9%). Founder là những người chuyển mode giỏi nhất. Họ dùng AI như một đối tác tư duy, không phải công cụ sản xuất.
Khảo sát năng suất AI của Lenny Rachitsky (n=1.750) cho thấy PM thấy AI hữu ích nhất trong việc viết PRD (21.5%), tạo prototype (19.8%) và cải thiện giao tiếp (18.5%). Điểm chung? Tất cả đều là task dịch nghĩa: biến hiểu biết mơ hồ thành cấu trúc phù hợp với context cụ thể. PM đã luyện cơ này cả sự nghiệp. AI chỉ là một “bề mặt” mới để áp dụng.
Thoải mái với sự bất định
Có một điều người ngoài PM không nhận ra: sự bất định và những vấn đề phát sinh không phải bug. Nó là feature. PM luôn phải dựa vào các team khác và quy trình độc lập để vận hành. Chúng ta viết spec để engineer hiểu, designer review, QA kiểm thử. Chúng ta đặt hướng đi với hiểu biết rằng output sẽ không bao giờ giống hệt tưởng tượng ban đầu, và cả một discipline được xây dựng quanh việc khiến điều đó trở nên chấp nhận được.
Sự thoải mái với output không xác định này, theo tôi, là kỹ năng quan trọng nhất khi làm việc với AI. Và ironically, nhiều engineer lại gặp khó khăn ở điểm này.
Văn hóa engineering đề cao độ chính xác. Function đúng hoặc sai. Test pass hoặc fail. Khi bắt đầu dùng AI, họ thường frustrate với tính không xác định: “Cùng prompt nhưng ra kết quả khác.” “Nó hallucinate function không tồn tại.” “Hoạt động phần lớn nhưng không phải lúc nào cũng đúng.” Những phàn nàn này hợp lý, nhưng đó chính là bản chất của hệ thống có độ chính xác cao nhưng không phải precision tuyệt đối.
PM giỏi phải ship product dù timeline trễ, requirement thay đổi, dependency fail. Hai kỹ năng PM vốn quen thuộc chuyển trực tiếp sang AI:
-
Viết instruction rõ ràng với kỳ vọng output không xác định: mỗi PRD, user story, design brief đều là bài tập viết rõ ràng trong khi chấp nhận phải iterate. Đây chính là prompting. PM đã “prompt engineering” từ trước khi thuật ngữ này tồn tại.
-
Xây hệ thống resilient với failure bên ngoài: PM giỏi không chỉ viết spec rồi cầu may. Họ thiết kế checkpoint, review cycle, fallback plan. Đây chính là cách vận hành agentic AI workflow: evaluate output, xử lý edge case, biết khi nào can thiệp.
Dữ liệu từ khảo sát Lenny củng cố điều này. 21% engineer nói AI làm giảm chất lượng công việc — mức bất mãn cao nhất. So với PM và founder, nơi hơn 70% thấy chất lượng tăng. Code có tiêu chuẩn đúng/sai rõ ràng. Công việc PM được đánh giá khác: chiến lược có thuyết phục không? spec có rõ không? roadmap có hợp lý không? Vai trò quen với ambiguity xem AI là tăng chất lượng. Vai trò cần precision xem nó là rủi ro.
Hướng tới mục tiêu, không phải sự chính xác tuyệt đối
Đây là điểm quan trọng nhất, và thường bị bỏ qua.
Product management luôn là một hoạt động rộng, định hướng mục tiêu. Không giống engineering hay design, nơi có tiêu chuẩn đúng/sai rõ ràng (code compile hay không, layout đúng grid hay không), PM sống trong thế giới của “đủ tốt cho hiện tại” và “ship rồi học tiếp”. PM giỏi xây sản phẩm như chuỗi iteration. Chúng ta chưa bao giờ tìm kiếm sự hoàn hảo ngay từ đầu. Chúng ta tìm một đối tác nhanh và lặp lại tốt.
AI chính là đối tác đó.
Lenny Rachitsky, người vận hành một trong những newsletter ảnh hưởng nhất về product management, nói rằng vai trò PM sẽ chuyển sang “trở nên rất giỏi trong việc biết nên cung cấp dữ liệu gì cho AI và đặt câu hỏi đúng.” Đây không phải kỹ năng mới với PM. Đó chính là kỹ năng cốt lõi: framing vấn đề, định nghĩa yêu cầu, refine liên tục, đánh giá output đã “đủ tốt” hay chưa.
Jensen Huang, CEO của Nvidia, nói: “Nhiệm vụ của chúng ta là tạo ra công nghệ tính toán để không ai cần lập trình nữa. Ngôn ngữ lập trình là ngôn ngữ con người.” Nếu ngôn ngữ lập trình là ngôn ngữ con người, thì “lập trình viên” giỏi nhất là người truyền đạt requirement, context và intent rõ ràng nhất. Một lần nữa, đó chính là PM.
Từ Product Manager sang Product Engineer
Nếu PM có bộ kỹ năng phù hợp với AI, vậy nó dẫn tới đâu? Tôi không nghĩ câu trả lời là “PM viết PRD nhanh hơn”. Tôi nghĩ vai trò PM sẽ tiến hóa thành một thứ hoàn toàn khác.
Trong nhiều năm, PM hoạt động thông qua delegation. Bạn có giả thuyết về user need nhưng không tự build prototype. Bạn có intuition về data nhưng cần analyst query. Bạn muốn test positioning nhưng cần copywriter viết nội dung. PM là vai trò tạo outcome thông qua người khác, dẫn đến tiêu tốn năng lượng vào alignment, transfer context và review cycle. Bạn là đạo diễn nhưng không chạm vào camera. Giờ thì bạn có thể.
Kỹ năng PM dùng để brief engineer (tư duy constraint, acceptance criteria rõ ràng, review lặp) cũng áp dụng khi “engineer” là Claude. Kỹ năng dùng để hướng designer (đồng cảm, framing vấn đề, “cho tôi 3 option để phản hồi”) cũng áp dụng khi “designer” là tool như Lovable hay v0. 63% người không phải developer đang “vibe coding” để tự build sản phẩm. Prototyping đã là use case AI #2 của PM (19.8%), với nhu cầu tương lai tăng +24.6 điểm %. PM không chỉ nghĩ cái gì cần build nữa — họ đang trực tiếp build.
Hãy nhìn sự trỗi dậy của product engineer. Lượng tìm kiếm cho “product engineer” tăng 89% từ 2021. Các công ty như Linear và PostHog đã vận hành theo mô hình này từ lâu, xây sản phẩm với product engineer và không cần PM truyền thống. Những công ty khác như Vercel và Stripe cũng theo hướng ownership cao, nơi một người sở hữu cả “what” và “how”. Lee Robinson, VP Product tại Vercel, nói: “Trong kỷ nguyên AI-first, product engineering quan trọng hơn bao giờ hết. Thậm chí, gần như đó là thứ duy nhất còn lại.”
AI cho phép PM áp dụng workflow “chỉ đạo + lặp” vào layer thực thi mà trước đây họ bị khóa ngoài. Tất nhiên, mức độ leverage còn phụ thuộc vào độ kỹ thuật, gu thẩm mỹ và hiểu biết domain của PM. Nhưng những kỹ năng cốt lõi — chuyển mode, chấp nhận bất định, iteration theo mục tiêu — vẫn là như cũ, chỉ là áp dụng trên phạm vi lớn hơn.
Như Software Letters nói, khi AI giảm chi phí implementation, thứ trở nên khan hiếm là “taste, judgment và context.” PM nào tận dụng được điều này, dùng AI để thu hẹp khoảng cách giữa “quyết định build gì” và “thực sự build nó”, không phải đang bảo vệ vai trò của mình — họ đang tiến hóa nó.
Nhưng có một vấn đề
Cần công bằng: luận điểm này không hoàn toàn màu hồng. Nghiên cứu Harvard/BCG cho thấy người dùng AI cải thiện 31% ở nhóm hiệu suất thấp, nhưng cũng có mặt trái: khi task vượt ngoài khả năng AI, người dùng AI có xác suất đúng thấp hơn 19 điểm % so với người không dùng (84.5% vs ~65%). Các nhà nghiên cứu gọi đây là “ngủ quên trên tay lái”.
Nghiên cứu của Anthropic cũng cho thấy developer dùng AI chỉ để generate code có điểm comprehension thấp hơn 17%. Nhưng nếu dùng AI để giải thích thay vì chỉ tạo output, họ vẫn giữ được hiểu biết cao.
Bài học? Kỹ năng PM trong việc đánh giá và chất vấn output là cực kỳ quan trọng. PM coi AI như hộp đen sẽ thất bại. PM coi AI như một cộng tác viên nhanh, không mệt mỏi, nhưng cần direction và review, sẽ thành công.
Tương lai sẽ đi về đâu
Tôi không nghĩ vai trò PM biến mất. Tôi nghĩ nó đang tiến hóa, và đích đến là product engineer.
PM truyền thống — viết spec, điều phối team, không chạm vào code — sẽ bị ép. Không phải trực tiếp bởi AI, mà bởi những người dùng AI để xóa khoảng cách giữa quyết định và thực thi. Khảo sát McKinsey Global AI cho thấy 88% tổ chức đã dùng AI thường xuyên, nhưng gần 2/3 chưa scale vượt qua giai đoạn thử nghiệm. Khoảng cách giữa “dùng AI” và “tạo giá trị thật” thực chất là bài toán product: ưu tiên, hiểu user, triển khai lặp, biết khi nào output đủ tốt. PM nào giải được bài toán này và tự ship solution sẽ cực kỳ giá trị.
Tin tốt là những kỹ năng PM đã xây dựng — chuyển mode, chấp nhận bất định, theo đuổi mục tiêu qua iteration — chính là nền tảng cho sự tiến hóa này. PM đã dành nhiều năm để học cách tạo outcome thông qua engineer, designer và analyst — thực chất là đang luyện tập cho một thế giới nơi AI cho phép họ tự làm điều đó.
Vai trò không còn như cũ. Nhưng những người có khả năng thực hiện bước nhảy này? Họ đã luyện tập suốt cả sự nghiệp. Họ chỉ gọi nó là “product management.”