#52 - "Product Manager cần phải technical đến mức nào?"
Bốn cấp độ của "technical" khi làm quản lý sản phẩm
Giới thiệu
"Product Manager cần phải technical đến mức nào?"
Mình thề là không đếm được số lần nhận được câu hỏi này trong đời 🤣. Thú thật rằng, trước kia mình không có câu trả lời nào hay hơn là "cần đủ technical để hiểu và làm việc được với engineers".
Tuy nhiên, sau sáu tháng làm ở công ty ở vai trò quản lý sản phẩm cho developer experience của công ty - một vị trí khá thách thức về mặt "technical" nhưng vẫn đậm màu làm sản phẩm, thì mình dần có một vài quan điểm thú vị hơn về chủ đề này, nên hôm nay lại ngoi lên để chia sẻ góc nhìn. Hy vọng đây sẽ là mồi lửa để châm ngòi cho mọi người suy nghĩ nhiều hơn!
Background "technical" của mình
Trước khi vào nội dung chính, thì sơ lược một xíu về background của mình để mọi người hình dung rõ ràng hơn bối cảnh mà ở trong đó mình nhìn nhận quản lý sản phẩm.
Kinh nghiệm của mình chủ yếu là quản lý sản phẩm ở những công ty B2B SaaS. Cụ thể hơn thì đối tượng người dùng của mình trước giờ đa số là dân kỹ thuật. Ở Katalon mình làm sản phẩm cho Software Tester, ở Holistics mình làm sản phẩm cho Analytics Engineer/Data Analyst, còn hiện tại mình đang làm sản phẩm nội bộ cho Software Engineers trong công ty.
Trước khi làm Product Manager thì mình cũng đi làm dev tầm 3 năm - chủ yếu là phát triển desktop application (Eclipse OSGI) và sau đó thiết kế Plugin API cho Katalon Platform. Sau khi làm PM, mình có cơ hội làm các sản phẩm dưới dạng web extension, cloud infrastructure, programming language (AMQL) và developer platform. Tóm lại, các sản phẩm mình làm đó giờ đều có thể được đánh giá là "technical".
Hai cách nhìn về khái niệm "technical"
Trước khi đi sâu hơn, mình muốn làm rõ góc nhìn của mình về khái niệm "technical". Chuyện là mình có gửi bản thảo của bài này cho một người bạn trong ngành product xem, và bạn ấy nêu lên một quan điểm mình thấy khá hay, nên mình xin phép đưa vào bài viết này luôn.
Mình tạm phân định ra hai góc nhìn về "technical": góc nhìn theo chiều dọc (vertical) sẽ tập trung vào độ chi tiết hay cụ thể, và góc nhìn mở rộng (expansive) sẽ tập trung vào phạm vi ảnh hưởng. Trong bài viết này, mình đang dùng góc nhìn thứ hai nhiều hơn. Góc nhìn đầu tiên không có gì sai cả, chỉ là nó chưa làm rõ được những khía cạnh mình muốn nhắc đến ở đây mà thôi.
Góc nhìn theo chiều dọc (Vertical View) hiểu "technical" theo mức độ chi tiết từ trừu tượng đến cụ thể. Bạn bắt đầu từ strategy, customer problems, business value ở tầng trên, rồi đi xuống use cases, capabilities, features, và cuối cùng là code, infrastructure, CI/CD pipeline ở tầng dưới. Càng đi sâu xuống dưới thì càng "technical".
Góc nhìn mở rộng (Expansive View) hiểu "technical" theo phạm vi ảnh hưởng từ cá nhân đến hệ sinh thái. Bạn bắt đầu từ việc nắm rõ nội tại sản phẩm của bạn, rồi mở rộng ra cách nó tương tác với các hệ thống và sản phẩm khác, sau đó đến kiến trúc/hạ tầng/công cụ, và cuối cùng là khả năng công nghệ của tổ chức. Càng hiểu được phạm vi ảnh hưởng rộng thì càng "technical".
Lý do vì mình tiếp cận khái niệm "technical" trong ngữ cảnh quản lý sản phẩm, chứ không phải kỹ thuật phát triển phần mềm.
Quản lý sản phẩm là về việc tạo ra giá trị cho người dùng và doanh nghiệp. Xuất phát từ tọa độ đó, "technical" mình đang nói đến ở đây sẽ thiên về việc làm sao để vận dụng công nghệ để tạo ra giá trị cho sản phẩm được rộng hơn. Càng "technical" thì PM chúng ta càng có khả năng tạo được giá trị ở nhiều tầng ngữ cảnh khác nhau, từ đơn lẻ đến bao quát cả tổ chức.
Do đa số PMs không trực tiếp code ra phần mềm (ít nhất là chưa phải bây giờ), nên mình thấy việc tập trung khái niệm "technical" vào mật độ chi tiết chưa đủ hữu ích trong ngữ cảnh làm sản phẩm cho lắm.
Bốn cấp độ technical trong việc quản lý sản phẩm
Từ góc nhìn trên, mình thấy có bốn cấp độ technical đối với một người quản lý sản phẩm, theo thứ tự như sau:
- Hiểu biết cơ bản về hệ thống: hiểu được kiến trúc sơ bộ và các cấu thành của một sản phẩm phần mềm.
- Thành thạo việc tích hợp: hiểu được việc thiết kế API ảnh hưởng đến việc tích hợp giữa các sản phẩm trong hệ sinh thái như thế nào. Có được góc nhìn sâu và rộng về mối quan hệ giữa sản phẩm của bạn và các sản phẩm khác trong nền tảng hay hệ sinh thái.
- Hiểu biết về tác động công nghệ lên đội ngũ phát triển: hiểu được các quyết định về công nghệ sẽ ảnh hưởng đến cách mà đội ngũ phát triển sản phẩm (và trong hệ sinh thái hay nền tảng) của bạn sử dụng công nghệ để tạo ra giá trị như thế nào.
- Hiểu biết về tác động công nghệ lên tổ chức: hiểu được các quyết định về mặt công nghệ sẽ ảnh hưởng đến cách tổ chức của bạn có thể tạo ra giá trị dài hạn như thế nào.
Cấp độ 1: Hiểu biết cơ bản về hệ thống
Đây là cấp độ mà tất cả PM đều cần có, bất kể bạn làm sản phẩm tiêu dùng hay B2B, sản phẩm kỹ thuật hay không kỹ thuật. Ở cấp độ này bạn hiểu được cách dữ liệu chạy trong hệ thống: từ giao diện người dùng → logic nghiệp vụ → cơ sở dữ liệu, và ngược lại. Bạn hiểu được tại sao một số tính năng tưởng đơn giản nhưng lại phức tạp, và tại sao một số thay đổi "nhỏ" lại cần nhiều thời gian.
Lấy ví dụ như tính năng lưu địa chỉ. Ở trên giao diện thì chỉ đơn giản là hiển thị một text input cho ngươi dùng lưu thôi, thế nhưng ở mặt nghiệp vụ có nhiều biến số. Chúng ta cần đánh giá địa chỉ này có tồn tại thật hay không, và nếu có tồn tại thì có ràng buộc gì về vị trí địa lý hay không (một số sản phẩm không khả dụng ở một số nước). Sau đó chúng ta cần xem thông tin về việc tồn tại hay không lấy ở đâu - hệ thống bên ngoài hay cơ sở dữ liệu nội bộ, và nếu hệ thống bên ngoài thì chi phí cho một lần gọi API là bao nhiêu.
Điều quan trọng nhất ở cấp độ này là bạn không còn nói những câu như "cái này đơn giản mà, chỉ cần thêm một button thôi" hay "tính năng này giống như Google Docs, làm sao khó được". Những câu này là cách nhanh nhất để mất uy tín với nhóm kỹ thuật. Trong khóa học Breaking into PM của tụi mình, cung cấp kiến thức nền tảng để các bạn đạt được cấp độ này chính là một mục tiêu quan trong của chương trình.
Bạn đang muốn chuẩn bị kiến thức nền tảng về quản lý sản phẩm? Hãy đăng ký tham gia khóa học Breaking into Product Management của chúng mình nhé. Khóa tháng 10 còn một vài slots cuối cùng đang còn mở đấy!
Ngoài ra, mình cũng có một bài viết liên quan về chủ đề này ở đây:
Minh Thanh To
Khi bạn hiểu được độ phức tạp của hệ thống, bạn sẽ tự nhiên bắt đầu ưu tiên các tính năng dựa trên công sức kỹ thuật so với tác động kinh doanh thay vì chỉ nhìn vào các yêu cầu của người dùng ở bề mặt. Bạn cũng sẽ giao tiếp với các bên liên quan một cách thực tế hơn về thời gian và sự đánh đổi. Nếu bạn có tiếp xúc với engineers thì chắc hẳn sẽ nghe nhiều câu chuyện về anh Product chị Manager đi chốt timeline không khả thi với sếp, và ép team phải deliver. Họ có thể OT để hoàn thành công việc cho bạn, nhưng họ không cần phải hỗ trợ hoặc thích bạn. Về lâu dài, hành vi đó sẽ để lại những vết nứt lớn giữa bạn và team engineering. Khi sự hỗ trợ của họ trở nên cần thiết trong công việc của bạn, thì bạn chắc chắn sẽ không nhận được điều đó.
Nếu bạn master được level này, nhóm kỹ thuật sẽ tin tưởng phán đoán của bạn hơn, dẫn đến hợp tác tốt hơn và deliver được hơn. Bạn sẽ được mời vào những cuộc thảo luận về kiến trúc kỹ thuật sớm hơn, giúp bạn định hình hướng đi của sản phẩm từ đầu thay vì phản ứng sau khi các quyết định kỹ thuật đã được đưa ra.
Do bản thân xuất phát từ developer nên mình không có quá nhiều khó khăn ở cấp độ này, nhưng mình đã mắt thấy tai nghe nhiều câu chuyện về các đồng môn PM không biết nhiều về kỹ thuật nhưng lại rất pushy trong việc hứa hẹn, và kết quả thường là không tốt cho đội ngũ phát triển sản phẩm.
Cấp độ 2: Thành thạo việc tích hợp
Cấp độ này chỉ cần thiết nếu bạn đang xây dựng sản phẩm kết nối với các hệ thống khác - thương mại điện tử, fintech, developer toolings, hay bất kỳ sản phẩm nào có tích hợp bên thứ ba.
Ở cấp độ này bạn hiểu được các nguyên tắc thiết kế API, luồng xác thực, thách thức đồng bộ dữ liệu, và tại sao việc tích hợp "đơn giản" lại thường không đơn giản chút nào. Anh Thiện - một người bạn và cũng ở trong cộng đồng BPM của tụi mình, có một bài viết khá hay về chủ đề này (btw anh Thiện đang open to work, mọi người ai có cơ hội có thể liên hệ giới thiệu anh qua LinkedIn nhé!)
Substack
Đây cũng là cấp độ cần thiết nếu bạn đang xây dựng tính năng nền tảng - những thứ mà các developer khác (nội bộ hay bên ngoài) sẽ xây dựng dựa trên đó. Bạn hiểu được trải nghiệm developer từ góc độ của người thực sự sử dụng API của bạn.
API hoạch định những thứ hệ thống của bạn có thể tương tác được với hệ thống khác, vì nó giống như một bản hợp đồng để xác định những điều khoản hai bên phải thực thi để làm tròn nghĩa vụ. Nếu không quan tâm đến khía cạnh này thì trải nghiệm người dùng sẽ bị đứt gãy hoặc thậm chí không hoàn thành được khi có nhiều hệ thống đan xen. Thậm chí, API của bạn có thể được sử dụng bởi các developers để xây dựng sản phẩm của họ, và trải nghiệm sử dụng API không tốt sẽ làm cho họ rời bỏ nền tàng của bạn (trừ khi bạn có lợi thế cạnh tranh khác).
Bạn sẽ thiết kế tính năng với tư duy hệ sinh thái hơn là tư duy cô lập. Thay vì chỉ tập trung vào chức năng cốt lõi, bạn sẽ cân nhắc cách sản phẩm của bạn khuếch đại giá trị thông qua hiệu ứng mạng lưới và đối tác. Bạn cũng sẽ dự đoán các trường hợp ngoại lệ và chế độ lỗi trong hệ thống kết nối, dẫn đến thiết kế sản phẩm bền vững hơn. Bạn có thể nhận diện cơ hội để biến sản phẩm của mình thành nền tảng (platform), tạo ra rào cản cạnh tranh thông qua hiệu ứng hệ sinh thái. Bạn cũng sẽ xây dựng mối quan hệ tốt hơn với đối tác và developer bên thứ ba, có thể mở ra các kênh phân phối và dòng doanh thu mới được tốt hơn.
Lúc còn làm ở Katalon, mình có cơ hội thiết kế một phần của platform architecture để developers có thể mở rộng nền tảng để xây dựng plugin và kiếm tiền từ đó. Dù dự án đó không thành công về mặt doanh thu, nó đã cho mình một trải nghiệm đáng nhớ về việc thiết kế sản phẩm cho developers sử dụng. Vấn đề không chỉ là họ làm được gì với platform, mà còn phải làm sao để mình có thể thêm các tính năng thông qua API phiên bản mới mà không ảnh hưởng đến những thứ họ đã phát triển sử dụng API phiên bản cũ, hoặc nếu có thì làm thế nào để họ migrate một cách an toàn. Khi có nhiều plugins muốn tương tác sử dụng cùng một tài nguyên hữu hạn trong platform (như bất động sản trên màn hình), thì chúng ta cần phải xử lý như thế nào để không ảnh hưởng trải nghiệm của người dùng cuối. Đó chỉ là một trong nhiều các câu hỏi chúng ta phải trả lời khi quản lý sản phẩm là platform API.
Cấp độ 3: Hiểu biết về tác động công nghệ lên đội ngũ phát triển
Cấp độ này phù hợp cho PM chịu trách nhiệm về nhiều nhóm sản phẩm trong platform. Bạn hiểu được cách các quyết định về công nghệ sẽ ảnh hưởng đến cách mà đội ngũ phát triển sản phẩm của bạn (và trong hệ sinh thái hay nền tảng) sử dụng công nghệ để tạo ra giá trị.
Ở cấp độ này, bạn không chỉ suy nghĩ về sản phẩm riêng lẻ mà bắt đầu nhìn thấy được mối liên hệ giữa kiến trúc, cơ sở hạ tầng, và công cụ phát triển với khả năng deliver của các nhóm khác nhau. Bạn hiểu được khi nào technical debt trở thành nút thắt cho nhiều nhóm, và khi nào đầu tư vào hạ tầng chung hay công cụ developer sẽ nhân lên năng suất của toàn bộ hệ thống.
Điều quan trọng là bạn có thể đánh giá sự đánh đổi giữa tốc độ của từng nhóm riêng lẻ và hiệu quả của toàn hệ sinh thái. Ví dụ, việc áp dụng các tiêu chuẩn API thống nhất có thể làm chậm một nhóm nhưng lại tạo điều kiện tích hợp tốt hơn cho toàn bộ hệ sinh thái, hoặc đầu tư thiết lập contracts cho các services sẽ giúp cho bạn xác định được dependencies giữa chúng, và giúp kích hoạt kiểm thử tự động phù hợp nhằm mục đích giảm thời gian chờ đợi để validate service deployment.
Khi bạn thành thạo cấp độ này, bạn có thể tham gia vào các quyết định về hạ tầng chung, quy trình phát triển, và tiêu chuẩn kỹ thuật ở cấp độ công ty. Bạn có thể ảnh hưởng đến lựa chọn công nghệ không chỉ cho nhóm mình mà cho nhiều nhóm, và hiểu được cách những lựa chọn đó ảnh hưởng đến khả năng sản phẩm lâu dài. Về lâu dài, bạn có thể thiết kế trải nghiệm developer trong và ngoài công ty, cũng như nâng cấp công cụ nội bộ để nhân lên hiệu quả nhóm. Bạn có thể nhận diện cơ hội để xây dựng nền tảng nội bộ, và đưa ra quyết định sáng suốt về việc tự xây dựng so với mua sắm cho các thành phần hạ tầng.
Ở Holistics, khi mình làm một bộ ngôn ngữ lập trình cho dân Data sử dụng, vấn đề mình gặp phải là khó để biết được tất cả những use cases họ có, vì dân kỹ thuật họ rất ưa chuộng việc kết hợp và tái sử dụng những mẫu logic hiện có để thực hiện tác vụ mới, nên chúng mình đã phải vận dụng cả domain knowledge cũng như technical knowledge để thiết kế ra các hàm (functions) trong bộ ngôn ngữ đủ phục vụ nhiều use cases phức tạp không đoán trước được, nhưng đồng thời cũng đủ cover những use case rất phổ biến (design for emergence). Việc này cần thiết để Data Analysts hay Analytics Engineers có thể sử dụng sản phẩm của mình để phục vụ nhiều nhu cầu trong tổ chức của họ hơn.
Tuy nhiên, mình đang ở giai đoạn chập chứng bước vào vào cấp độ này mà thôi. Rất may mắn rằng ở công ty hiện tại, mình thấy được cách các quyết định về CI/CD pipeline, container orchestration, monitoring services ảnh hưởng trực tiếp đến khả năng phát triển, vận hành và hỗ trợ của các team như thế nào. Nhưng việc hiểu đủ sâu để đưa ra recommendations cụ thể cho các quyết định công nghệ ở tầng tổ chức thì mình vẫn cần học hỏi thêm rất nhiều.
Cấp độ 4: Hiểu biết về tác động công nghệ lên khả năng tạo giá trị của tổ chức
Thú thật, cấp độ này gần như không còn là lãnh thổ "Product Manager" nữa. Đây là lĩnh vực của VP Product, CTO, hay các Engineering Director. Bạn hiểu được cách các lựa chọn công nghệ định hình văn hóa tổ chức, cách mà các phương pháp tổ chức phát triển sản phẩm khác nhau ảnh hưởng đến hợp tác nhóm, và cách cơ sở hạ tầng kỹ thuật cho phép hay hạn chế đổi mới mô hình kinh doanh.
Ở cấp độ này bạn suy nghĩ về Định luật Conway - cách cấu trúc nhóm ảnh hưởng đến kiến trúc phần mềm, và ngược lại. Bạn thiết kế không chỉ sản phẩm mà cả cấu trúc tổ chức để tối ưu hóa cho kết quả bạn muốn đạt được. Những người ở cấp độ này ảnh hưởng đến các quyết định toàn công ty về tech stack, phương pháp phát triển, và tổ chức nhóm. Những quyết định này ảnh hưởng không chỉ đến việc xây dựng sản phẩm gì, mà còn tốc độ xây dựng và khả năng bảo trì lâu dài. Họ có thể kiến tạo lợi thế cạnh tranh thông qua văn hóa kỹ thuật và năng suất developer vượt trội. Các công ty có hệ thống nội bộ tốt hơn thường deliver nhanh hơn và sản phẩm chất lượng cao hơn, dẫn đến lợi thế kinh doanh bền vững.
Cũng thành thật luôn mình đang hoàn toàn không ở level này. Đây chỉ là cố gắng nhìn lên trên để quan sát xem những người ở tầng này họ đang làm gì thôi, nên mình không quá tự tin nhận định của mình ở khu vức này là đúng. Bản thân mình cũng không chắc mình có muốn cố gắng leo lên đây không. Việc viết ra tính chất thì dễ, vì chỉ cần thời gian quan sát và nghiền ngẫm, nhưng thật sự làm được những chuyện đó đòi hỏi không chỉ kinh nghiệm mà còn là convictions về việc con đường nào sẽ tạo ra lợi thế cạnh tranh về mặt công nghệ cho tổ chức nữa.
Khi nào thì cần nâng cấp kỹ năng technical?
Theo ý kiến cá nhân của mình, phần lớn PM sản phẩm tiêu dùng chỉ cần cấp độ 1 là đủ xài rồi, Nếu bạn là Technical PM hoặc làm các sản phẩm tích hợp nhiều, thì cần thành thạo cấp độ 2. Nếu các bạn phải chịu trách nhiệm internal platform PM như mình phải cố gắng mon men lên được cấp độ 3. Có lẽ chỉ các vai trò lãnh đạo kỹ thuật cấp cao mới thực sự cần cấp độ 4.
Mình muốn nhấn mạnh: chỉ vì bạn ở Cấp độ 1 không có nghĩa là bạn phải "leo rank", mà tùy vào ngữ cảnh mà bạn có thể có những vấn đề khác cần tập trung giải quyết hơn. Đối mặt với việc biết thêm "technical" trong một công ty cần nhiều hơn efforts Go-to-market, hãy tập trung vào cái sau thay vì cái đầu.
Các dấu hiệu bạn có thể cần nâng cấp kỹ năng "technical" của mình:
- Bạn thường xuyên ngạc nhiên trước độ phức tạp kỹ thuật của các tính năng. Khả năng đánh giá độ phức tạp kỹ thuật có thể được tinh chỉnh (dù không hoàn hảo) để nhận định của bạn gần hơn với thực tế. Thường các bạn freshers/juniors mình thấy khá cần rèn luyện khả năng này để có thể thấu cảm và làm việc với developers tốt hơn.
- Technical debt thường xuyên cản trở lộ trình sản phẩm của bạn. Developers thường bảo bạn "cái này không làm được đâu, vì hệ thống hiện tại không được thiết kế để hỗ trợ use case đó từ đầu" (còn mà nếu họ bảo khó quá vì họ không thích bạn thì đó lại là một câu chuyện hoàn toàn khác 😢). Đây là dấu hiệu bạn nên bắt đầu đào sâu hơn nữa về cách kiến trúc hiện tại vận hành và đâu là rào cản. Biết đâu bạn có thể giúp team allocate một số efforts để trả được technical debt, tái kiến trục và mở rộng giá trị mà hệ thống có thể mang lại.
- Bạn đang xây dựng API hay sản phẩm hướng đến developer. Nếu phải làm nền tảng tích hợp cho các bên thứ ba mở rộng để phục vụ nhiều mục đích hơn, bạn cần hiểu được cách các quyết định thiết kế sẽ lan tỏa ra khắp hệ sinh thái. API không được thiết kế có chủ đích sẽ tạo ra trải nghiệm tích hợp tệ, cản trở developers và buộc họ chọn nền tảng khác (đây cũng là lý do developers yêu thích Stripe - API của họ được thiết kế cực kỳ tốt)
- Bạn chịu trách nhiệm cho nhiều nhóm kỹ thuật và cần hiểu được cách technical decisions của một team ảnh hưởng đến các team khác. Hiện tại mình đang ở trong giai đoạn này, khi mà sản phẩm của mình cần được đưa vào ngữ cảnh sử dụng của nhiều đội ngũ khác nhau với các cách thức phát triển khác nhau. Không chỉ là dựa vào cách họ đang làm hiện tại, mà còn phải học hỏi thêm về best practices và convictions của những người staff engineers trong công ty để định hướng được đúng đắn.
Nhưng cũng cần nhớ: nếu nhóm của bạn giao sản phẩm một cách suôn sẻ, người dùng hài lòng, và bạn có mối quan hệ làm việc tốt với các kỹ sư, thì có thể cấp độ kỹ thuật hiện tại của bạn đã đủ rồi. Thời gian và năng lượng của bạn có thể được đầu tư tốt hơn vào nghiên cứu người dùng, phân tích thị trường, hay chiến lược kinh doanh. Đừng học technical để chứng minh bạn "đủ xứng đáng" làm PM. Học để giải quyết được những vấn đề thực tế mà bạn đang gặp phải trong công việc, đó là cách để bạn phát triển trong con đường sự nghiệp PM của mình. Nếu không có vấn đề gì cần giải quyết, thì tập trung vào những thứ khác có nhiều impact hơn.
Kết luận
Việc là một PM technical không phải về việc chứng minh bạn có thể lập trình hay có thể vibe-code được interactive prototype hay tự build tự sản phẩm của mình. Những việc đó đều có lợi ích, nhưng về bản chất chúng nên giúp chúng ta có nhiều chiều sâu để đưa ra quyết định sản phẩm và làm việc hiệu quả hơn với đội ngũ phát triển sản phẩm tốt hơn mà thôi. Hy vọng bài viết này giúp cho bạn thêm một góc nhìn hữu ích!
Bạn đang muốn chuẩn bị kiến thức nền tảng về quản lý sản phẩm? Hãy đăng ký tham gia khóa học Breaking into Product Management của chúng mình nhé. Khóa tháng 10 còn một vài slots cuối cùng đang còn mở đấy!
Product Manager Technical Levels Quiz
Test your understanding of the four technical levels framework
