Khi người làm Product mắt kẹt trong “execution”.

Trong quá trình phỏng vấn đầu vào tại UXCamp, chúng tôi gặp đi gặp lại một trạng thái ở rất nhiều vai trò khác nhau: PM, UX/UI Designer, BA, Researcher, Leader / Manager.

Những lời này đến từ trạng thái bị kẹt trong một cách làm việc khiến năng lực không có cơ hội lớn lên.

Một trường hợp PM khum happy vì suốt ngày đi optimize.

Biểu hiện của trạng thái đó nek:

• Bị thụ động mỗi khi việc tới, ít được trao quyền hay chủ động trong công việc.
• Không bảo vệ được chuyên môn của mình.
• Lãnh đạo là người nắm domain knowledge, thường xuyên cầm tay chỉ việc.
• Công việc không được tạo tác động đến tầng vận hành, hệ thống.
• Nhàm chán với công việc lặp đi lặp lại.
• Lơ tơ mơ khi làm việc thiếu tài liệu, không research, không UT, không đo lường hiệu quả.
• Có những môi trường đưa ra các yêu cầu quá chi tiết, khiến nhân sự không còn không gian phát triển và sáng tạo.

Khác môi trường, nhưng cảm giác giống nhau: “Mình đang làm rất nhiều, nhưng không thấy mình lớn lên.”

Không chỉ nhân sự nghĩ vậy. Quản lý cũng thấy vấn đề này.

Khi trao đổi với anh Thế Anh (Design Lead tại MSB), anh chỉ ra 3 nguyên nhân chính dẫn đến trạng thái trên:

1. Nhân sự chưa được trang bị đủ năng lực cho giai đoạn họ đang ở
2. Môi trường không tạo điều kiện để năng lực đó được sử dụng
3. Nhu cầu cá nhân: có người thoải mái với việc nhận task, không có nhu cầu mở rộng vai trò

Bài này không bàn sâu về nhóm số 3.
UXCamp tập trung vào nhóm số 1 và 2: những người muốn làm tốt hơn, nhưng đang mắc kẹt.

I. Nhận diện trạng thái mắc kẹt

1. Khi năng lực không kịp lớn cùng vai trò

Rất nhiều PM chia sẻ rằng họ làm quá nhiều việc triển khai (execution): chạy ticket, theo deadline, đẩy task giữa các team. Lâu dần, tư duy sản phẩm bị bào mòn.

Không phải vì họ không thông minh. Mà vì không còn không gian để tư duy, phân tích, phản biện.

Một ví dụ khác:
Một PM từng làm ở công ty lớn, khi chuyển sang công ty nhỏ thì gặp vấn đề ngược lại. Do thiếu kinh nghiệm “chạy sản phẩm end-to-end”, bạn yêu cầu timeline dài và nguồn lực lớn. Sản phẩm không đạt KPI. Kết quả: bạn được rút về làm execution, roadmap và planning do sếp trực tiếp đảm nhận.

Hay một trường hợp khác:
Có PM trung bình 6-18 tháng lại đổi công ty một lần. 4 năm kinh nghiệm, đi qua nhiều môi trường, nhưng không có sản phẩm nào làm đủ sâu. Cuối cùng, công việc chính chỉ còn là kết nối API với đối tác.

Nhiều Designer, BA đến với UXCamp với mong muốn chuyển sang trail Product Management với kỳ vọng có nhiều không gian để "lớn lên".
Điều này hoàn toàn khả thi, nhưng thực tế cho thấy khoảng cách là rất lớn. Nhìn chung là cần cả thiên thời, địa lợi, nhân hòa.

Ví dụ một trường hợp UI UX Designer muốn chuyển sang làm PO

Điểm chung của các trường hợp này không phải là yếu, mà là: "trải nghiệm chưa được chuyển hóa thành năng lực."

2. Khi môi trường thu hẹp dần quyền tự quyết

Bài thánh ca buồn các con vợ hay hát:

• Request đến từ team kinh doanh, mà request là “thánh chỉ”.
• Tài liệu giao cho designer đã kèm sẵn solution, luồng, thậm chí wireframe.
• Một số công ty ưu tiên tính đồng nhất hệ thống đến mức mọi màn hình chỉ còn là kéo thả component.
• UX không được tham gia vào các quyết định quan trọng

Nhiều designer làm outsource tự gọi mình là “thợ vẽ” - để mô tả cảm giác không được chạm vào bài toán nghiệp vụ của khách hàng.

Bản thân tôi trong năm 2025 làm 3 dự án outsource, hiểu vấn đề lun.

Con vợ này làm Fsoft cười hí hí vì có kèo design inhouse được can thiệp nghiệp vụ và động vào số má =))

UX designer khi BA làm solution rất chi tiết.

Một BA làm giải pháp cho các Bộ, Ban, Ngành chia sẻ:
Mỗi khi có request mới, bạn chỉ tiếp nhận và triển khai, không có cơ hội khai thác sâu nhu cầu hay painpoint thực sự của người dùng cuối.

Hay một designer làm Product Design trong edTech:
CEO xuất thân từ giảng dạy IELTS, rất hiểu domain. Mọi quyết định sản phẩm do CEO đưa ra. Designer làm theo. Hệ thống gần như không có data usage. Làm xong tính năng cũng không biết người dùng có dùng hay không.

Rất rõ ràng: nhiều môi trường không giúp nhân sự lớn lên về tư duy sản phẩm.

II. Mong muốn

UXCamp thu hút được những người có mong muốn rất giống nhau:

• Được hiểu rõ vì sao sản phẩm được phát triển theo hướng đó
• Được quyền quyết định trong phạm vi chuyên môn
• Cảm nhận được giá trị mình tạo ra cho tổ chức
• Thích build sản phẩm từ đầu hoặc giai đoạn growth hơn là chỉ maintain

Mong muốn không mới. Khó khăn thì rất rõ. Vấn đề còn lại là:

Làm cách nào để vượt qua được giai đoạn này?

III. Cách người giỏi thoát khỏi “execution-only”

Chia sẻ từ anh Thế Anh (Design Lead tại MSB) xoay quanh 3 từ khóa: trực tiếp, chủ động, kiên trì

a. Học để làm được, không phải để biết

Trước khi muốn được giao những việc “ở tầm cao hơn”, anh tập trung đảm bảo rằng mình làm được đã.

• Học nghiệp vụ ngân hàng
• Học logic hệ thống từ BA
• Học cách một sản phẩm tài chính được hình thành từ team kinh doanh
• Đọc kỹ Thông tư, Quyết định, Chỉ thị của Ngân hàng Nhà nước

Việc này giúp anh có đủ nền tảng để tự tin lên tiếng khi cơ hội xuất hiện.

b. Làm không chính thức trước khi được giao chính thức

Có một chi tiết rất hay anh chia sẻ:

Trước đây, BA chịu trách nhiệm vẽ luồng. Trong quá trình họp, anh nhận ra nhiều điểm trải nghiệm chưa tốt.
Anh không “innovate” BA ngay trong phòng họp.

Thay vào đó:

• Ngồi riêng với BA
• Đề xuất luồng mới
• Align trước khi vào họp chính thức

Khi vào họp, mọi thứ đã được chuẩn bị. Đề xuất của anh dễ được chấp nhận hơn.

Anh làm những việc chưa được giao, đủ nhiều, đủ lâu.
Đến lúc sếp thấy rõ, công việc đó trở thành nhiệm vụ chính thức.

Từ UI/UX Designer, anh đảm nhận toàn bộ hành trình nghiên cứu, thiết kế, tài liệu bàn giao cho 8 sản phẩm tại VPBank, trước khi chuyển sang MSB.

c. Tự tạo cơ hội cho chính mình

Anh không chờ “được chọn”.
Anh chủ động đề xuất:

“Em muốn làm cái này.”

Và câu nói rất thật:

“Năng lực có rồi mà môi trường không tạo điều kiện thì nhảy việc.”

Lời kết

Trạng thái “chỉ làm execution” không phải là thất bại cá nhân. mà là một giai đoạn rất phổ biến trong sự nghiệp product.

Khác biệt giữa người mắc kẹt lâu và người đi tiếp được không nằm ở may mắn, mà nằm ở việc:

• Có nhận ra mình đang bị kẹt không
• Có chủ động chuẩn bị để thoát ra không