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.

Khi bạn gia nhập vào 1 công ty với vai trò là vị trí PM, bạn phải hiểu được điều này. Vì hoàn toàn, (ở 1 số công ty), team dev vẫn chạy bình dù không có PM, đôi khi team marketing là người giao task cho dev làm, vậy vai trò của bạn là gì?

• Như vậy, team sẽ đặt kì vọng gì ở một người PM?
• Liệu biết code đã đủ chưa?
• Người CEO tuyển bạn vào có cần bạn là 1 .. engineer nữa không?
• Có lẽ là team chạy được bình thường, nhưng chưa tạo được nhiều thành quả. Thế bạn vào rồi có tăng thêm gì không?

Đây là những câu hỏi bạn phải trả lời được trong quá trình cân nhắc chuyển sang PM. Vậy làm sao bạn chứng minh bạn sẽ "có ích" với team đây?

Làm "Dâu trăm họ" phải "cầm kì thi hoạ"?

PM cần nhiều thứ hơn là biết code. Dùng từ "Dâu trăm họ" nghe hơi buồn cười, nhưng đây là cụm từ mà các bạn làm Product hay dùng để nói với nhau về "số phận" của mình 🤣

Đúng là như thế thật, vì PM đứng ở giữa là cầu nối xuyên suốt giữa nhiều stakeholders từ các phòng ban khác nhau, và phải làm hài lòng (hoặc là ít nhất là không làm phật ý ai) trong quá trình này.

Vậy ròi để làm PM thì bạn biết điều gì?

Kẻ thù của PM là việc "không quản lí được product".

...Ủa nói gì nghe hiển nhiên dữ ta? Nghe hơi lùng bùng lỗ tai.

​Tuy nhiên, khi bạn nhìn vào lăng kính này, thì việc "không biết technical" chỉ là 1 vấn đề nhỏ dẫn đến việc "không quản lí được Product". Nhiều người nghĩ rằng nếu không biết technical, bạn không thể xây dựng lòng tin với team engineer, nên dẫn đến việc vận hành team Product không được trơn tru. Tuy nhiên, để tạo được lòng tin với team thì có nhiều cách, không nhất thiết phải biết code.

• Nhiều non-technical người chọn cách 1-on-1 thường xuyên sát sao với engineers, hoặc kết thân với 1 người cầu nối để hiểu technical hơn. Từ đó có thể khắc phục điểm mình yếu là technical.
• Mặt khác cũng có nhiều technical PM dù biết code cũng khó có sức ảnh hưởng với team engineer, vì thiếu nhiều kĩ năng mềm.

Ngoài ra, việc "không quản lí được product" còn đến từ nhiều khía cạnh:

• Không deliver được đúng deadline. Bạn không push được team hoàn thành đúng deadline, project đã trễ 2 tháng. Doanh thu của công ty đang đi xuống, và đang phụ thuộc vào feature mà bạn hứa là bạn sẽ deliver 2 tháng trước đó.
• Không nhìn ra được cơ hội. Đã 2 tháng nhưng team vẫn chưa "sản xuất" ý tưởng nào mới, và lương của dev thì vẫn đang nằm trong chi phí lớn của công ty, giờ team dev chỉ làm những task nho nhỏ, fix bugs.
• Không có niềm tin của team. Khi không có niềm tin, quyết định của bạn khó được thông qua hơn. Mỗi quyết định đều rất khó khăn và dài dằng dặc, mọi người sẽ ngờ vực, và vô tình tạo ra những friction làm quá trình làm Product không được diễn ra thuận lợi.
• Vô vàn, mình có thể kể tới sáng mai..

Vậy nguyên nhân đến từ đâu?

Gót chân asin của người PM đến từ việc "thiếu tầm nhìn".

Nhìn chung, để "làm dâu trăm họ" hiệu quả, bạn cần biết có có 1 bộ kĩ năng khá rộng, tạm gọi là phải kĩ năng "cầm kì thi hoạ", để mà có tầm nhìn.

Tầm nhìn ở đây ý mình không phải là 1 tầm nhìn về tương lai, ý mình là phải có tầm nhìn vào hiện tại.

• Nếu bạn không biết technical, có thể nói là bạn đã thiếu tầm nhìn vào tiềm lực công nghệ của công ty. Khi đứng trước một vấn đề về mặt vận hành, bạn không nhìn ra được tiềm năng công nghệ trong đó. Bạn cũng không biết cách nói chuyện với engineer thế nào, hoặc đề xuất thường ra giải pháp trên trời, bạn đã bị mất niềm tin. Bây giờ bạn chỉ là cục router giữa nhiều người.
• Nếu bạn không biết business, có thể nói là bạn thiếu tầm nhìn vào mô hình kinh doanh và vận hành của công ty. Khi launch một feature mới, bạn không thể gắn được lợi ích của việc bạn làm với giá trị của doanh nghiệp, và doanh thu công ty đang đi xuống. Một ngày đẹp trời bạn nhận được thư cảm ơn từ ban giám đốc.
• Nếu bạn không biết về product design, bạn không thể chung tay thiết kế với designer của mình để ra 1 sản phẩm có độ hoàn chỉnh cao, và giao diện dễ dùng. Bạn khó có thể truyền tải và truyền cảm hứng cho designer, ngoài thúc việc thật nhanh. Tiêu. Quan hệ của bạn với designer bây giờ đã trở thành mối quan hệ điển hình giữa client và freelance designer.
• Nếu bạn không nói chuyện nhiều vời người dùng thường xuyên, có thể nói là bạn đã thiếu tầm nhìn vào "Nhu cầu thực tế của người dùng". Khi đứng trước một quyết định phải chọn giữa rất nhiều ý tưởng để làm, bạn không biết phải chọn cái nào, vì bạn có hiểu gì về người dùng đâu.
• ...

Bởi vì đứng giữa nhiều phòng ban khác nhau, việc nắm được tầm nhìn ở tất cả mọi nơi, hay... "cầm kì thi hoạ" là một điều khó tránh khỏi.

Cầm kì thi hoạ trong thực tế

Product Manager là 1 nhánh công việc tương đối gần với chủ doanh nghiệp / hoặc CEO, mình tạm gọi là khá là "ăn trơ prờ nua".

Tuy không có quá nhiều quyền lực như CEO (như quyền sinh sát, tuyển người, etc.) nhưng mình có thể tạm gọi là PM phải đưa ra khá nhiều quyết định tự chủ và phải có tính chủ động cao, tương tự như 1 chủ doanh nghiệp - bị nerfed 1 chút.

Vì vậy, khi làm PM, ban đang vận hành team gần như tương tự như 1 người chủ doanh nghiệp. Hoàn toàn quyết định của bạn của thể bị overwrite bởi CEO, và bạn cũng không phải chịu áp lực tài chính gì cho công ty, nhưng để làm tốt, bạn phải đóng được vai "CEO", và làm PM như thể đây là công ty của mình.

Bạn phải nắm được mọi ngóc ngách, và phải biết điều mình cần biết. Còn nếu chỉ dừng nghĩ ở cương vị là 1 người "làm công ăn lương", "làm tròn trách nhiệm", sáng đi chiều về, rất khó để trở thành PM giỏi.

Muốn chủ động thì mình phải có tầm nhìn:

• Công việc chính của Elon Musk là CEO. Nhưng ông đủ có tầm nhìn ở mọi điểm trong vận hành doanh nghiệp để có thể giúp điều hành công ty và nhiều khi hands on khi cần.
• Nhờ hiểu biết về Design (đặc biệt là về phông chữ) mà Steve Jobs đã sản xuất chiếc máy tính đầu tiên có design và phông chữ đẹp nhất thế giới, tên là Mac.
• Shark Hưng không còn là kĩ sư, nhưng có thể thấy shark Hưng am hiểu khá nhiều về công nghệ mới, điều này mới giúp shark đầu tư khôn ngoan được. Hiểu thì mới đầu tư.

Đừng bao giờ cho phép mình "thiếu tầm nhìn". Đã làm thì phải hiểu, chưa hiểu thì phải tìm cách.

• Hồi mình còn làm AI Engineer, mình rất muốn đưa con AI mình lên ứng dụng cho nhiều người sử dụng, thế là mình học làm web.
• Sau khi đã có kĩ năng làm web, mình lại muốn xoay sở không biết cách nào để "xây dựng 1 ứng dụng mà người ta muốn trả tiền?". Thế là phải học thêm kĩ năng về Product.
• Trong quá trình làm Product hay startup đầu tiên, có nhiều cái mình không biết, ví dụ như cách doanh nghiệp vận hành hoặc đóng thuế như thế nào, gọi vốn ra sao. Cũng phải tìm hiểu.
• Nếu mới vào công ty không biết sản phẩm là gì, hay đang gặp vấn đề gì, thì phải chịu khó ngồi nói chuyện với khách hàng, giúp họ setup từng phần nhỏ nhất. Hoặc là phải chịu khó đi nói chuyện với từng người trong team để có được tầm nhìn đó.

Thiếu tầm nhìn là 1 lý do sẽ dẫn đến việc sản phẩm đầu ra bị thiếu "trải nghiệm chặng cuối" (last mile experience) hay "trải nghiệm hoàn chỉnh", có lẽ mình sẽ chia sẻ thêm ở blog khác.

Cầm kì thi hoạ 1 cách thông minh.

Có những cái bạn làm được, nhưng chưa chắc là bạn giỏi, hay có "khẩu vị tốt" về cái đó (tiếng anh gọi là có "appetite"). Bạn có thể biết về design, nhưng chưa chắc bạn có khẩu vị design tốt.

Tuy nhiên:

• bạn cần biết những thứ cơ bản về design để có thể làm việc việc với designer
• bạn cần biết những thứ cơ bản về business để có thể làm việc với CEO
• bạn cần biết những thứ cơ bản về marketing để có thể làm việc với team tiếp thị

Nếu bạn biết mấy thứ 1 cách nâng cao thì đây là 1 lợi thế lớn, chúc mừng bạn 😄

Nhìn chung, việc có tầm nhìn vào giúp việc vận hành team product trôi trảy hơn (rất nhiều), nhưng không làm bạn "thay thế" được team dev hay product design, và cũng đừng nên cố gắng thay thế. Chỉ cần làm trôi chảy hơn, thì điều đó cũng đủ để bạn toả sáng rồi.

Chỉ là: đừng để mình bị thiếu tầm nhìn. Vậy nha. 👋