Kĩ năng "Cầm kì thi hoạ" khi vận hành team Product

Lời nói đầu: Chào mọi người, lâu quá mình mới có dịp viết lại blog, dạo này tập trung nhiều việc ở công ty quá nên chưa có thời gian viết thêm, nay mới có thời gian viết 1 bài trở lại, cũng ngẫu hứng thôi à.
Mình mới quyết định là mình sẽ có thể viết tiếng Việt nhiều hơn để phù hợp với thị hiếu của độc giả Việt Nam hơn, vì cũng là tiếng mẹ đẻ của mình nên sẽ thân thiện hơn ^^ Bên cạnh đó cũng đan xen với những bài tiếng Anh để các bài viết của mình phủ rộng hơn (Sẽ là 1 lợi thế nếu sau này mình có "lỡ" làm 1 phi vụ gì ở nước ngoài kaka 🤣. Giờ thì chắc chưa nghĩ tới.)
Nếu bạn nào có theo dõi blog của mình nhiều, thì kể từ hồi mình rời Startup đầu tiên của mình, mình có chuyển sang làm Product Manager cho 1 công ty sản phẩm tên là Holistics. Gọi là "Product Manager" thế thôi, nhưng mình thích gọi mình là "Product Operator" hơn, tức là người vận hành sản phẩm.
Lý do mình gọi là vậy vì cách mình làm product là mình sẽ xắn tay hands on khá nhiều trong những công việc hàng ngày, thay vì chỉ đơn thuần là làm việc "High level" - Những cái mà mọi người thường hình dung về 1 người Product Manager.

"Chuyển dịch"
Vì từng là engineer và tình cờ vừa chuyển dịch bất ngờ sang 1 cái title "Product Manager" như vậy nên khá là nhiều người bạn của mình, background lẫn tech và non-tech, hỏi mình là "Mày chuyển qua làm PM vậy rồi có cần biết code không?". Đây là 1 câu hỏi hay, và theo mình cũng hơi khó trả lời, vì nó tuỳ trường hợp.
Để hiểu hơn về câu hỏi này thì mình sẽ cần nhìn rộng ra 1 chút. Thì sau khi mình tìm hiểu cặn kẽ hơn về câu hỏi này, mình mới hiểu được lý do các bạn hỏi là:
- Đối với dân tech, các bạn muốn biết liệu việc biết code có trở thành 1 lợi thế cạnh tranh của mình để mình nhảy sang PM không?
- nhiều bạn mình biết cũng chán làm dev rồi, muốn làm Product cơ 🤣
- Đối với dân non-tech, các bạn muốn biết liệu không biết code có trở thành 1 trở ngại của mình khi lấn sang làm PM hay không?
- nhiều bạn non-tech cũng sụt sùi muốn lấn sân làm PM cho sản phẩm vì nghe nói bên đó lương cao
Anh Thomas, 1 người bạn của mình, cũng đã có trả lời vắn tắt câu hỏi thông qua bài viết này, các bạn có thể tham khảo thêm.
Trong bài viết này của mình sẽ tập trung khai thác kĩ cái ý đó hơn, và từ góc độ kĩ hơn của 1 người đã chinh chiến Software tương đối nhiều - từ làm Machine Learning Engineer / DevOps Engineer, Full Stack Engineer, từng làm Technical Founder của 1 cái venture-backed startup từ những ngày đầu tiên, và lần gần đây nhất là mình vừa chuyển sang làm Product Manager. Mình cũng giữ thói quen code thường xuyên để cập nhật tình hình công nghệ cũng như có thấu cảm hơn với team engineers.
Một lợi thế cạnh tranh
Thế liệu biết code có phải là 1 lợi thế cạnh tranh của 1 người vận hành team Product?
Chuyện "FOMO" giữa biz PM và Technical PM
Có 1 quan sát (và mình được nghe kể lại) mình thấy khá là buồn cười giữa 2 loại PM:
- biz PM: tức là PM nhưng từ nền tảng business
- technical PM: PM từ background coder đi lên
Thường thì 2 nhóm người này "tự tạo FOMO" cho nhau khá nhiều.
- Biz PM: "Mình không biết code là thua thằng technical PM rồi, tự ti quá!"
- Technical PM: "thằng biz PM nó biết về kinh tế nên mấy sếp lớn thích nó lắm, mình thua rồi!"
Qua câu chuyện là để thấy là, cái gap về kĩ năng giữa biz PM vs technical PM này là có tồn tại, và khá nhiều người nhìn nhận nó là 1 vấn đề lớn, từ cả loại 2 background.

Biết code là 1 lợi thế trong công ty công nghệ
Việc có cần biết code hay không phụ thuộc khá nhiều vào bản chất sản phẩm mà công ty bạn đang theo đuổi. Mình sẽ tạm chia nhị phân thành 2 loại chính là (1) Công ty truyền thống và (2) Công ty công nghệ. Tuy nhiên, thực tế mà nói, thường các công ty sẽ đan xen khá nhiều giữa 2 loại này, không phải công ty nào cũng rơi vào 1 đầu trong 2 thái cực.
- Đối với 1 số loại hình sản phẩm truyền thống, ví dụ như thịt, cá, trứng, sữa chẳng hạn, việc biết code không phải giúp bạn có quá nhiều lợi thế trong việc apply ở các công ty, hoặc tự làm startup cho riêng mình.
- Ở trong các công ty này, đôi khi công nghệ chỉ là 1 chất xúc tác ("enabler") để bổ trợ cho việc vận hành nội bộ của doanh nghiệp. Ví dụ, đôi khi những công ty này chỉ cần là 1 cái website đẹp và 1 cái trang quản lí khách hàng (CRM) là ok. Team marketing happy, khách hàng nhìn vào thấy đẹp, reach được nhiều người, team sales quản lý được đơn nàng, thế là có thể tập trung bán được hàng. Cả nhà đều vui.
- Mặt khác, mình có cũng thấy có 1 số công ty truyền thống hiện tại cũng đã nhanh chóng chuyển mình khá nhanh để tiếp cận thêm những công nghệ cao, dưới sự áp lực của thị trường và các cái trend công nghệ mới nổi (ví dụ: AI, Blockchain,.. đồ)
- Đối với Công ty Công nghệ thế hệ mới (tạm gọi là vậy), hoặc cụ thể ở đây mình ví dụ là các công ty phần mềm, tạm định nghĩa là có "nhiều điểm chạm" với khách hàng ở thông qua các sản phẩm công nghệ, hoặc là trên không gian mạng.
- Ví dụ: những sản phẩm công nghệ vận tải như Grab, ShopeeFood, hoặc các sản phẩm productivity Canva, Figma đều là những công ty công nghệ thế hệ mới.
- Ở các công ty này, công nghệ đôi khi nằm trong "điểm chạm chính" trong trải nghiệm khách hàng, thay vì con người là điểm chạm như các công ty truyền thống. Đôi khi, những kiến thức technical là 1 lợi thế để các technical PM biết khi nào nên dùng công nghệ gì, và nó có khả thi không?
- Ví dụ để triển khai 1 sản phẩm có AI trong đó, người PM đầu tiên phải là người đầu tiên nhìn nhận đây là vấn đề có thể giải quyết được bằng AI, và khả thi về mặt chi phí, vận hành, cũng như tạo được giá trị cạnh tranh cho doanh nghiệp. Những non-technical PM sẽ không nhìn ra được khía cạnh này
- Vì không hiểu về công nghệ, nên non-technical PM sẽ gặp các khó khăn gì trao đổi với team dev, không lấy được lòng tin của team, và tạo ra những friction mà khiến team đi chậm hơn.
- Mặt khác, những non-technical thường sẽ kiếm được lợi thế cạnh tranh của mình ở background của họ,
- ví dụ người học background business sẽ nhìn ra được tiềm năng kinh doanh của 1 loại hình dịch vụ nào đó
- hoặc người có background finance sẽ có lợi thế về khi làm việc các sản phẩm tài chính chẳng hạn. Kiến thức về tài chính của họ trở thành việc cốt lõi trong việc định hịnh sản phẩm tài chính đó.
- nếu 1 người chỉ có technical skills thì việc nhìn ra các cái cơ hội này cũng ít hơn, at least là khi chưa có quá nhiều kinh nghiệm hoặc quan sát đủ nhiều.
Lợi thế, nhưng không phải tất cả
Việc có nền tảng technical là 1 lợi thế, vì nó giúp PM nắm rõ không gian giải pháp tốt hơn và có thể vận hành một team sản phẩm công nghệ một cách trơn tru hơn. Tuy nhiên, theo mình, đây là 1 lợi thế nhỏ, ngắn hạn, và tương đối dễ bị thay thế (và yes, sẽ rất phù thuộc vào loại hình công ty mà bạn đang theo đuổi, như mình có chia sẻ ở trên).
Điều này cũng đúng với lợi thế business của dân non-technical, biết business là 1 lợi thế, nhưng sẽ không giúp bạn trụ được lâu nếu không có kĩ năng khác.
"Team dev hoàn toàn có thể vận hành nếu không có PM, còn PM thì không thể tự chạy mà không có dev", câu này mình nghe được ở 1 buổi sharing ở Product Tank VN đợt trước mình có tham gia, chia sẻ của anh cựu PM ở Google. Mình thấy nó đúng.