Vai trò quản lý sản phẩm là một sai lầm
(sollecitom.github.io)- Khi một công ty sản phẩm phần mềm hiểu sai product-led là “cấu trúc trong đó PM đưa ra mọi quyết định”, họ sẽ áp dụng một mô hình vốn chỉ phù hợp với kiểu lãnh đạo sáng lập ngoại lệ cho những PM nghề nghiệp bình thường
- Với cách trao quyền kiểm soát sản phẩm cho một lãnh đạo duy nhất, điều cốt lõi không nằm ở bản thân mô hình mà là trao cho ai; nó giả định phải có một nhân vật hiếm hoi có tầm nhìn, sức hút, năng lực kỹ thuật và niềm tin mạnh mẽ
- Khi một PM bình thường được trao quá nhiều quyền, dữ liệu, framework, quy trình phê duyệt, cuộc họp và hệ thống vai trò không còn là công cụ phán đoán mà trở thành lá chắn cho né tránh trách nhiệm và chính trị nội bộ
- Dòng chảy này khiến người giỏi rời đi, còn công ty thì mắc kẹt trong các nhiệm vụ ít rủi ro và quy trình nội bộ, dần đánh mất tầm nhìn và tài năng
- Phương án thay thế không phải là cấu trúc xoay quanh chức danh PM, mà là gom những người ám ảnh với kỹ thuật và chất lượng ở từng lĩnh vực vào một đội, để cùng xử lý product discovery, observability, engineering, design, business và kiến thức domain
Vấn đề hiểu sai product-led thành cấu trúc PM độc quyền
- Nhiều công ty sản phẩm phần mềm được sáng lập bởi những người giỏi gọi vốn và hiểu ngành mục tiêu hơn là những người có kinh nghiệm mạnh trong việc tạo ra sản phẩm phần mềm
- Những nhà sáng lập này khởi nghiệp dựa trên kinh nghiệm và quan hệ trong ngành, nhưng nếu họ trực tiếp dẫn dắt mọi quyết định, sự tự tin của chuyên gia domain có thể gây hại cho công ty
- Một số nhà sáng lập thừa nhận rằng bản thân có thể là rủi ro và tuyển người để giao quyền ra quyết định
- Lúc này nảy sinh hiểu lầm kiểu “chúng ta không nên là một tổ chức dịch vụ mà phải là công ty sản phẩm, công ty sản phẩm thì product-led, nên PM phải chịu trách nhiệm”
- Ở đây, product-led không có nghĩa là PM đưa ra mọi quyết định
- Khi có ý kiến phản đối, phản biện thường gặp là những công ty xuất sắc như Amazon, Apple, Tesla cũng giao quyền kiểm soát cho một người
- Nhiều công ty xuất sắc giao quyền kiểm soát cho một cá nhân duy nhất, nhưng không phải mọi công ty xuất sắc đều dùng cùng một mô hình
Tiền đề của mô hình người ra quyết định duy nhất
- Mô hình trao quyền kiểm soát công ty cho một người không hẳn là sai; thành bại phụ thuộc vào trao cho ai
- Những nhân vật như Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo được công chúng ngưỡng mộ nhờ tầm nhìn, sức hút, sự tự tin, khả năng phục hồi và sự xuất chúng
- Họ là kiểu người tưởng tượng ra một thực tại thay thế, hoàn toàn đắm chìm vào công việc của mình và tạo ra thay đổi lớn bằng ý chí
- Nếu thực sự có một người như vậy, mô hình kiểm soát duy nhất có thể vận hành rất mạnh mẽ
Nhân vật ngoại lệ không phải là PM thông thường
- Những con người vĩ đại nói trên không phải là quản lý sản phẩm
- Họ là nghệ sĩ, nhà toán học, nhà phát minh, nhà khoa học, CEO, và có trường hợp đồng thời đảm nhiệm nhiều vai trò
- Họ ám ảnh với tầm nhìn và kỹ thuật của mình hơn là OKR, KPI, dữ liệu hay ý kiến của người khác
- Nhân vật ngoại lệ có thể có quan điểm mạnh, cái tôi lớn, cách làm riêng, những mặt gai góc và sự khinh thường với tầm thường
- Vì những đặc điểm này, họ khó được tuyển dụng trong các công ty thông thường, và bản thân họ nhiều khả năng cũng không muốn làm việc ở đa số công ty
- Nếu có thể tìm được người vĩ đại, không cản trở họ và chịu được cường độ của họ, bạn có thể giao quyền kiểm soát sản phẩm và công ty cho họ
- Thực tế là rất khó tìm được người như vậy, họ có thể không muốn làm việc cùng bạn, hoặc công ty có thể không chịu nổi cái tôi và cường độ của họ
Khi áp dụng cấu trúc dành cho nhân vật vĩ đại cho PM bình thường
- Sai lầm lớn nhất là đưa vào một mô hình vận hành cần nhân vật ngoại lệ mà lại không có nhân vật ngoại lệ
- Bài viết phê phán rằng các PM nghề nghiệp mà công ty có thể tuyển dụng một cách thoải mái thường không phải là người ở tầm đó
- Họ được mô tả như tay sai kinh doanh, tín đồ cuồng framework, chuyên gia chủ đề, cựu maker đã leo lên nấc thang doanh nghiệp, người nghiện chỉ số, người xuất thân MBA, v.v.
- Nếu hiểu “product-led” là PM đưa ra mọi quyết định rồi tuyển PM nghề nghiệp, điều đó có thể gây chết người
- Những PM này thiếu tầm nhìn, sức hút, chuyên môn, niềm tin mạnh mẽ và năng lực kỹ thuật, nên họ hành động an toàn và mang tính chính trị
- Vì biết sự thiếu hụt của mình, họ lặp đi lặp lại hành vi nhận lấy thành quả và né tránh trách nhiệm
Quá trình dữ liệu và quy trình trở thành công cụ phòng thủ
- Bước đầu tiên là vũ khí hóa ra quyết định dựa trên dữ liệu
- Họ không thừa nhận rằng có thể tìm dữ liệu hỗ trợ cho bất kỳ lập luận nào, mà tô vẽ rằng chỉ quyết định của mình mới hợp lý theo dữ liệu
- Khi mọi việc sai, họ đổ lỗi cho thị trường, chất lượng dữ liệu hoặc vận rủi của công ty, và khẳng định đó không phải trách nhiệm của mình
- Bước tiếp theo là đưa framework và vai trò vào mọi thứ
- Xuất hiện framework nghề nghiệp 18 bước, đánh giá hiệu suất hằng quý, PI planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe, v.v.
- Không tuân thủ quy trình, không dựa trên dữ liệu, thiếu tài liệu, tài liệu không cập nhật trở thành lý do để chỉ trích
- Trong tổ chức xuất hiện các vai trò như Director of KPIs, Deputy Director of Product Operations, Global Head of Digital Whiteboard Solutions
- Mọi thứ đều cần phê duyệt, và không quy trình hay lĩnh vực nào được một người kiểm soát hoàn toàn
- Trong các ủy ban lớn, ai cũng có thể nói “no”, nhưng không ai có thể nói “yes” một cách trọn vẹn
- Các cuộc họp cũng bùng nổ
- Báo cáo trạng thái, họp alignment, 1:1, họp nhân sự, thảo luận chiến lược, thiết lập ngữ cảnh, release go/no-go, báo cáo dự án, v.v. đều tăng lên
- Bước cuối cùng là tuyển thật nhiều người tệ
- Họ tuyển dựa trên tiêu chí người đó có phải là mối đe dọa hay không, còn dấu hiệu của sự xuất sắc lại trở thành lý do từ chối
- Ứng viên lý tưởng trở thành kiểu người đa năng làm tạm ổn việc được giao mà không có ý kiến phản biện hay sự quan tâm đến chất lượng
- Số lượng PM tăng vọt, mỗi đội và mỗi lĩnh vực đều có tầng lớp PM, lặp lại cùng một hành vi
Những gì tổ chức đánh mất
- Khi dòng chảy trong đó người bình thường nắm quyền bắt đầu, người xuất sắc cuối cùng sẽ rời đi
- Hoặc họ bị một nhà độc tài tầm thường đẩy ra, hoặc tự rời đi vì khó chịu nổi môi trường
- Tốc độ công việc dừng lại, và việc thực thi điều gì đó trở thành một việc đau đớn, một cam kết lớn và một thử nghiệm rủi ro
- Tầm nhìn lớn bị coi là phi thực tế và nhanh chóng bị loại bỏ
- Những việc công ty làm bị giới hạn trong các “quả thấp dễ hái” và lựa chọn an toàn
- Ngay cả những người không quá đam mê kỹ năng của mình cũng cảm thấy đau đớn và rời đi; những người đủ chai lì để ở lại lại làm vấn đề tệ hơn
- Công ty đánh mất nhân tài tốt nhất, quên đi tầm nhìn, trở nên hướng nội và vô nghĩa
- Trường hợp tốt nhất là nó chết ở một thời điểm nào đó; tệ nhất là nó sống sót nửa vời, biến những người đầy nhiệt huyết thành zombie ghét công việc của mình
Phương án thay thế là đội gồm những người xuất sắc trong đời thường
- Có thể xây dựng một công ty sản phẩm thành công mà không cần tìm và tuyển nhân vật ngoại lệ, giao quyền kiểm soát cho họ rồi chịu đựng cường độ của họ
- Phương án thay thế là tuyển những người xuất sắc trong đời thường
- Mỗi người phải xuất sắc ở một lĩnh vực nào đó
- Họ phải ám ảnh với kỹ năng của mình và được thúc đẩy bởi chất lượng
- Hãy xây dựng đội sao cho các vùng xuất sắc của họ chồng lấn ít nhất có thể
- Thay vì chia nhỏ trách nhiệm theo từng cá nhân, hãy để họ vui vẻ làm việc họ thích và dùng thời gian, kỹ năng của mình cho công ty
- Những người này cũng có thể thách thức, bướng bỉnh, cái tôi mạnh, kỳ lạ và thất thường
- Nếu giao cho họ vấn đề tốt và cho phép họ làm công việc tuyệt vời, họ sẽ hoàn toàn tận tâm với thành công của công ty
Vị trí nên có của lãnh đạo và PM
- Không nhất thiết phải từ bỏ hoàn toàn lãnh đạo; cũng có thể bỏ team lead và đặt area lead làm người điều phối giữa bên ngoài và bên trong
- Nếu đặt một lãnh đạo chịu trách nhiệm cho từng lĩnh vực, vai trò đó nên được trao cho người gần với nhân vật vĩ đại
- Đó là người gần với Jobs, Musk, Bezos về tầm nhìn, sức hút, cường độ, đam mê và hành vi cực đoan
- Nếu đưa một người thoải mái trong ngắn hạn, nghe lời tốt và đòi hỏi ít sự chú ý hơn lên làm người chịu trách nhiệm, bạn có nguy cơ rơi vào tình huống đã nói ở trên
- Bài viết cho rằng vai trò PM theo nghĩa truyền thống không có chỗ trong một công ty vận hành tốt
- Tuy nhiên, vẫn cần những người ám ảnh với các lĩnh vực vốn thường được giao cho PM, như product discovery và product observability
- Những người này có thể từng có chức danh PM, và bản thân điều đó không phải vấn đề
- Lý do tuyển họ không phải là chức danh, mà là sự ám ảnh và thế mạnh
- Thay vì đặt họ vào một vai trò PM riêng, hãy xếp họ vào cùng đội với những người ám ảnh về engineering, design, performance, business và kiến thức domain
Không chỉ là vấn đề của PM
- Khi người không có tầm nhìn, sức hút, đam mê, năng lực kỹ thuật và ý chí trở thành người chịu trách nhiệm, vấn đề tương tự sẽ xảy ra
- Lý do tập trung vào PM là vì trong phát triển sản phẩm phần mềm có xu hướng đặt người mang chức danh product manager vào vị trí chịu trách nhiệm
- Một số PM thực sự ngoại lệ và có thể làm rất tốt trong cả hai mô hình
- Tuy nhiên, những PM như vậy không nhất thiết làm tốt hơn những người xuất sắc có nền tảng khác
- Những PM như vậy chỉ là một thiểu số rất nhỏ, và tác giả cho rằng phần lớn PM nghề nghiệp còn lâu mới có năng lực lãnh đạo bằng sự xuất sắc
1 bình luận
Ý kiến trên Hacker News
Công ty hiện tại có nhiều người thông minh nhưng vì nhiều lý do lại không có quản lý sản phẩm, và kết quả là những việc lẽ ra quản lý sản phẩm phải làm thì đơn giản là không được làm
Hầu như không có kỹ sư nào muốn làm những việc như duy trì quan hệ khách hàng, phỏng vấn người dùng, phát hiện các tính năng tiềm năng, thuyết phục ban lãnh đạo, hay làm chính trị để phân bổ nguồn lực
Ở công ty trước, 2 trong 3 quản lý sản phẩm bất tài nên bị sa thải, nhưng 1 người thì thật sự xuất sắc, và chỉ với một phần thời gian của người đó, trong vòng 1 năm công ty đã làm được nhiều hơn công ty hiện tại đã làm trong hơn 2 năm
Tôi đồng ý rằng không có đủ quản lý sản phẩm giỏi. Số người có thể trở thành quản lý sản phẩm giỏi tăng tuyến tính theo dân số, nhưng ngành phần mềm đã bùng nổ theo cấp số nhân, nên tôi nghĩ nhu cầu về vai trò PM đã nhiều hơn số PM thật sự xuất sắc tới 100 lần
Họ cũng không có tính kỹ thuật nên không quản lý các ticket Jira, còn việc quản lý lãnh đạo thì phần lớn do các manager đảm nhiệm
Tôi nghĩ các quản lý sản phẩm đó chủ yếu họp hành, nói chuyện với lãnh đạo, nói chuyện với kỹ sư, viết tài liệu, và chủ trì các buổi lập kế hoạch sprint bị kéo dài
Nếu là quản lý sản phẩm xử lý các vấn đề về khách hàng, người dùng và nguồn lực thì tôi nghĩ có thể có giá trị hơn nhiều
Tôi cứ nghe câu “chúng ta là công ty ưu tiên engineering”, nhưng thực tế điều đó chỉ có nghĩa là các nhóm engineering tự ý chạy theo công nghệ mới nhất
Có 3,5 sản phẩm chính, thực tế là 4,5 sản phẩm, mỗi cái được xây bằng một tech stack khác nhau, và còn khoảng 8 sản phẩm nữa phải hỗ trợ vì các yêu cầu legacy. Không có chuẩn hóa hay khả năng tương tác giữa các sản phẩm, cũng không có chuyển giao tri thức, nên chi phí phát triển tăng vọt
Riêng năm nay đã hai lần tôi phải giải thích cho các kỹ sư có 20 năm thâm niên vì sao việc một API chỉ dùng TLS 1.3, cái khác dùng 1.x, còn cái khác nữa thậm chí không yêu cầu TLS là điều tệ hại
Khách hàng ghét chúng tôi. Sản phẩm của tôi thì được viết tài liệu marketing trước rồi để kỹ sư tự xoay xở xây. Một bước chuyển dữ liệu Oracle sang parquet được làm bằng ba ngôn ngữ và hai DB trung gian (MySQL và PG), và tôi phải rất vất vả mới ngăn họ đưa thêm cả Redis vào
May là 2 năm trước một quỹ private equity đã mua lại công ty và giờ chúng tôi nhận tối hậu thư rằng nếu không kiếm được tiền thì coi như xong. Công ty 20 năm tuổi này là một cost center chưa từng kiếm ra tiền, và ngay cả khi chúng tôi không đạt mục tiêu, tôi nghĩ vũ trụ sẽ tốt đẹp hơn nếu thảm họa thiết kế phần mềm mà chúng tôi tạo ra biến mất
Quản lý sản phẩm ngốc nghếch sẽ trở thành một kiểu quản lý dự án trá hình chuyên theo dõi thêm một sổ công việc nữa; người thông minh thì hiểu sâu về business rồi được thăng chức hoặc rời đi
Vai trò này cũng khó quản trị. Đôi khi họ nhận được công lao lớn từ việc của người khác, đôi khi lại không được ghi nhận chút công nào và sự nghiệp bị chững lại
Nếu đẩy vai trò này sang engineering, quản lý engineering hoặc quản lý chung, năng lực engineering sẽ yếu đi. Nếu cần tuyển kỹ sư thì nên chọn theo năng lực đó và bảo vệ họ khỏi những người bên ngoài, nhưng nếu đội còn phải xử lý cả tương tác, bạn sẽ tuyển những người có năng lực pha trộn và cuối cùng mặt engineering sẽ bị pha loãng
Nếu cố ý giữ sức chứa của quản lý sản phẩm ở mức eo hẹp, đó có thể trở thành một cơ chế ép buộc khiến họ tập trung vào tầm nhìn và những việc cấp cao, đồng thời tránh việc sa đà quá sâu để tạo ra các quy trình vô dụng hoặc định nghĩa tính năng quá mức
Trong ngành công nghệ đã phình to nhờ hơn 10 năm tăng trưởng nhờ lãi suất thấp, có lẽ rất nhiều người chỉ cần đi làm là đã có thể thành công
Bài viết khá rối. Vừa nói “nên loại bỏ vai trò PM”, nhưng lại nói “vẫn cần người chuyên trách những việc PM từng làm, chỉ là đừng gọi là PM mà hãy gọi bình thường là người xuất sắc”
Có vẻ tác giả đã có trải nghiệm tệ với PM, và qua đoạn nói về MBA thì thấy dấu vết đó; vì vậy có vẻ họ đang muốn vứt cả đứa bé cùng với nước tắm
Khi quy mô kinh doanh lớn lên, sự chuyên môn hóa vai trò sẽ xuất hiện và trở nên cần thiết. Có những PM tệ và đây là công việc khó, nhưng nếu đội của chúng tôi mất PM, tôi sẽ thật sự thất vọng
Có thể tôi chỉ toàn có trải nghiệm tốt với PM, nhưng các PM ở công ty tôi tìm hiểu khách hàng muốn gì và sản phẩm cần cung cấp gì, rồi cùng engineering manager cân bằng giữa tính khả thi về kỹ thuật và năng lực triển khai
Nếu engineering manager nói “với lịch này thì tuyệt đối không được”, PM sẽ tìm ra phương án thay thế cho sản phẩm
Bài này trông như bỏ qua bước giữa và chỉ muốn đổi tên mà chẳng có lý do gì
Chính xác thì ai được cho là sẽ quyết định đội nên ưu tiên vấn đề nào? Đó chính là trách nhiệm cốt lõi của vai trò PM
Rốt cuộc có vẻ tác giả đã có trải nghiệm tệ với một PM không làm được việc quyết định ưu tiên đó
Tuy vậy, vì người đó mà tôi phải tham dự cuộc họp khó xử nhất trong đời: suốt một tiếng từ đầu đến cuối, họ phơi bày trước mặt quản lý cấp cao rằng mình hoàn toàn không hiểu sản phẩm, trong khi vị quản lý cấp cao đó thì hiểu sản phẩm
Những PM giỏi giúp rất nhiều vì họ hiểu khách hàng muốn gì, chúng tôi có thể cung cấp gì, lịch trình thực tế ra sao, cũng như cách làm việc với pháp lý và các bên liên quan phía kinh doanh. Tôi hỗ trợ họ khi họ cần kiểm tra khía cạnh kỹ thuật
Hiếm khi một đội thiếu ý tưởng để xây dựng hoặc cách cải thiện trải nghiệm sản phẩm/vận hành. Product manager là người cố gắng bảo đảm đội xây dựng đúng thứ
Tôi là PM với 20 năm kinh nghiệm IT, và đang cân nhắc học MBA để có thêm kiến thức, hiểu biết kinh doanh chính quy và hỗ trợ cho sự phát triển về sau
Những PM giống tôi không vừa lấy MBA xong là bắt đầu, mượn cách nói quân đội, chơi trò làm chuyện vô ích
Vấn đề là những người đi thẳng từ trung học, đại học, MBA rồi vào vị trí quản lý. Ngoài vài kỳ thực tập ngắn giữa bậc đại học, nhiều người trong số họ không có lấy một ngày kinh nghiệm thực địa
Bài viết kỳ lạ. Dùng rất nhiều lời lẽ, nhưng cuối cùng chẳng phải chỉ là “nếu tuyển người hiệu suất thấp thì sẽ có hại cho công ty” sao
Phương án thay thế cũng kiểu “hãy tuyển người giỏi, nhưng đừng tuyển vào vai trò PM”
Đọc giống bài của một người đã có trải nghiệm tệ với một PM tự nghĩ mình là Steve Jobs. PM cũng chỉ là người bình thường thôi, tôi không hiểu vì sao lại giả định rằng tất cả những người mang chức danh đó đều là kiểu người có cảm giác đặc quyền
Một tổ chức có thể có hàng nghìn PM và mỗi người đều có sếp riêng. Đúng là bài viết kỳ lạ
Kiểu như “đừng tuyển product manager, vì họ sẽ không phải người tuyệt vời đâu. Thay vào đó hãy tuyển người tuyệt vời, không chỉ một người mà là cả đội!”
Ngày nào cũng tuyển người hiệu suất thấp mà tôi không hiểu vì sao. Một con tinh tinh chưa được huấn luyện cầm chồng CV có khi còn đoán trúng tốt hơn
PM đáp ứng một nhu cầu rất cụ thể. Nhu cầu đó khó định lượng, nhưng có thể nói rằng nếu không có PM giỏi thì mọi thứ sẽ sụp đổ
Thông thường họ thu thập thông tin từ người dùng về điều gì hiệu quả và điều gì không, nghe từ ban điều hành về những việc cần làm để vận hành công ty, tìm hiểu từ các lãnh đạo ngành xem ngành đang đi về đâu, làm việc với thiết kế, rồi chắt lọc tất cả thành các tính năng thật sự cần xây dựng
Họ cũng làm việc với engineering để đánh giá điều gì thực tế, mất khoảng bao lâu, loại bỏ những tính năng tốn nhiều thời gian nhưng giá trị thấp, đồng thời giúp các ước lượng và tốc độ của đội trở nên phần nào dự đoán được
Như vậy là đã mô tả khối lượng công việc của 1,5 người rồi. Nếu loại bỏ tổ chức sản phẩm, tất cả những việc này sẽ bị phân tán sang đội engineering, nhưng không phải mọi thành viên trong đội đều làm tốt những việc đó
Ngay cả khi cân bằng được, nếu một người rời đi, sẽ xuất hiện một khoảng trống vô hình mà lúc tuyển dụng bạn thậm chí không tìm kiếm
Có vẻ nhiều đội đã bị tổ chức sản phẩm rối loạn chức năng làm cho ám ảnh. Những tổ chức như vậy tách rời hoặc có vẻ chẳng quan tâm đến khách hàng, ngành và khía cạnh tổ chức; thay vào đó đốt cực nhiều thời gian vào các cuộc họp lặp đi lặp lại mockup, micromanage designer khiến người giỏi bỏ đi, và trói engineering vào những cuộc họp sản phẩm không cần thiết
PM làm việc sát với đội để định nghĩa roadmap và ưu tiên những việc sẽ tạo tác động lớn nhất cho khách hàng và doanh nghiệp
Nếu PM làm tốt, các kỹ sư sẽ hiểu rất rõ tiếp theo cần giải quyết vấn đề nào và vì sao cần giải quyết nó
Thứ hai, việc họ có vị thế trong tổ chức để trao đổi với lãnh đạo cấp cao về dự án hay không cũng quan trọng. Nếu có cả hai thuộc tính này thì đang ở trạng thái tốt
Điều tôi học được sau hơn 12 năm làm việc trong ngành công nghệ là vai trò chỉ là cách tổ chức thể hiện mong muốn của mình mà thôi
Nếu muốn ai đó suy nghĩ theo hướng sản phẩm, họ mở vị trí PM; nếu muốn có người dẫn dắt đội nhóm, họ tạo vị trí engineering manager
Chức danh là một yếu tố hư cấu cho phép chúng ta chơi trò RPG mang tên công việc từ nhiều góc độ khác nhau. Rốt cuộc, thứ mỗi người mang đến nơi làm việc là tổ hợp độc đáo giữa tài năng và kinh nghiệm của riêng mình
Một số người đôi khi vượt qua ranh giới của các vai trò này, và điều đó cũng ổn. Họ có ý tưởng và thậm chí có thể tự tạo ra chức danh riêng cho mình
Tổ chức cần đủ thông minh để để những người như vậy trưởng thành và phát triển. Điều đó không có nghĩa là họ không thể thành công hoặc làm việc xuất sắc với tư cách PM, mà là vì tổ chức thường không đầu tư đủ thời gian để tìm hiểu sâu người mà họ tuyển vào, nên họ đưa ra một vai trò được nấu sẵn
Kỹ sư cũng có thể làm vai trò PM, nhưng họ không suy nghĩ mọi thứ từ góc nhìn PM. Vì bản sắc chính của họ không phải là PM mà là kỹ sư
Một điều nữa tôi nhận ra trong bối cảnh vượt qua ranh giới vai trò là phần có giá trị nhất trong vai trò của một người thường là những trách nhiệm không được định nghĩa rõ ràng
Khó giải thích, nhưng con người thường tạo ra giá trị theo những cách khó mô tả hoặc định lượng
Nhìn chung đây là một quan điểm khá harsh, nhưng rõ ràng cũng có phần đúng. Khi trong công ty xuất hiện tổ chức sản phẩm, nó có xu hướng trôi sang các ủy ban, OKR, chu kỳ review, kế hoạch và rất nhiều quan liêu, đúng như tác giả mô tả
Trước đây, trong vai trò sales engineering tiếp xúc trực tiếp với khách hàng, tôi đã dẫn dắt sản phẩm rất thành công bằng ảnh hưởng của mình, và ngây thơ nhận việc product manager vì nghĩ rằng mình sẽ có quyền kiểm soát chính thức
Nhưng khi ngồi vào vị trí đó, hóa ra đó là một công việc văn phòng bị ràng buộc cực kỳ nhiều và hoàn toàn không hợp với tôi. Phần lớn là quản lý ticket và backlog, điều phối thay vì ra quyết định, viết vô tận các báo cáo PowerPoint; việc sáng tạo nhất là tạo ra quy trình để công ty chính thức hóa product roadmap. Tôi bỏ chạy sau 6 tháng
Chức năng này khá hữu ích trong việc tạo khả năng nhìn thấy cái gì đang được xây dựng và quản lý các ưu tiên xung đột của một sản phẩm đang phát triển. Nhưng nó không phải là việc định hình hay kiểm soát hướng tiến hóa của sản phẩm
Đó là chức năng căn chỉnh, lọc, và nếu may mắn thì thu thập dữ liệu; nó tạo ra dấu vết ra quyết định có thể kiểm toán và cảm giác về sự trưởng thành trong ra quyết định để các MBA cấp trên ngủ ngon hơn một chút
Thông thường mỗi tháng tôi tạo 4–12 đề xuất tính năng mới (PRD), con số thay đổi tùy quy mô công ty và lượng quy trình cần thiết
Hình thức luôn là “người dùng hiện có vấn đề X, và để giải quyết nó ta cần xây Y. Y sẽ trông như thế này…”
Dĩ nhiên có những khó khăn về điều phối và giao tiếp, nhưng tất cả luôn nhằm tìm ra tiếp theo nên xây gì
Tôi hiểu không phải mọi vai trò PM đều như vậy, nhưng tôi không đồng ý với việc nói rằng PM không thể tốt hơn mức “căn chỉnh/lọc/diễn kịch về sự trưởng thành trong ra quyết định”
Nếu vai trò đó chỉ là sắp xếp thứ tự backlog hiện có, tôi tò mò không biết ai là người định nghĩa các mục mới để đưa vào backlog
Tôi đồng ý rằng tổ chức sản phẩm có thể trở thành một thực thể chính trị/quan liêu thay vì bên hỗ trợ
Cá nhân tôi cho rằng vai trò sản phẩm nên được nhúng trong đội ngũ engineering và báo cáo cho cùng một lãnh đạo. Cấp bậc có thể tranh luận, nhưng như vậy mới có thể xử lý PM tệ như xử lý kỹ sư tệ
Dĩ nhiên nếu công ty cũng không thể cho kỹ sư tệ ra đi thì đó là một vấn đề khác
Tác giả không đưa ra nhiều framework cho việc này
Giải pháp của bài viết có mùi thuyết vĩ nhân
Đoạn cuối nói rằng “những con người phi thường tưởng tượng ra các thực tại thay thế, tận hiến hoàn toàn cho công việc, và dùng ý chí để dời núi” là quá giản lược
Thứ dời núi không phải là ý chí, mà là những người bên dưới thực sự triển khai tầm nhìn. Cùng lắm thì “vĩ nhân” đó chỉ căn chỉnh incentive để khiến những người thực thi và chuyên gia thực sự hành động
Tôi đang làm ở một công ty công nghệ lớn gần như không có vai trò PM, nên có thể nói cảm nhận trực tiếp
Cho đến nay thì khá pha trộn. Tôi từng làm ở các tổ chức có nhiều PM và đồng ý rằng những tổ chức đó không tốt lắm. Nhưng rốt cuộc những việc PM làm vẫn cần có người làm
Trong tổ chức của chúng tôi, trách nhiệm đó chính thức rơi vào software manager và developer từ cấp senior trở lên
Ví dụ, nếu là senior engineer và dẫn dắt một initiative của đội, bạn phải chịu trách nhiệm cho mọi hoạt động mà PM từng làm. Các hoạt động khác do manager hoặc senior manager đảm nhận
Từ góc nhìn developer thì khá vất vả. Với tư cách individual contributor, bạn vẫn phải hoàn thành việc của mình, đồng thời phải điều phối người khác và bảo đảm công việc được hoàn tất
Không chỉ là khối lượng việc bổ sung, mà thành thật mà nói nhiều developer không có kỹ năng để trở thành PM hiệu quả. Việc hợp tác giữa các đội cũng trở nên khó hơn vì phải điều phối những người thuộc tuyến báo cáo khác
Cách này thường dẫn đến thiếu quyền sở hữu, thiếu trách nhiệm giải trình, nỗ lực trùng lặp, việc bị rơi qua kẽ hở, và sự lộn xộn nói chung
Tuy vậy, nó hoạt động tốt với các initiative nhỏ trong nội bộ một đội có vài người tham gia. Vì nó loại bỏ overhead của PM và trao quyền kiểm soát cho những người trực tiếp xây dựng. Nhưng tôi không chắc nó có phù hợp với các initiative lớn hơn hay không
Nói rằng nhiều developer không có kỹ năng PM hiệu quả là đúng, nhưng công bằng mà nói thì nhiều PM cũng không có kỹ năng PM hiệu quả
Khó khăn khi phải điều phối với những người thuộc tuyến báo cáo khác cũng giống hệt với PM
Khác biệt cốt lõi có vẻ nằm ở phán đoán “việc này có đáng tách thành một vai trò chuyên trách hay không”. Tôi có xu hướng cho rằng với kỹ sư thì gần như luôn không đáng
Chỉ nhìn tiêu đề là tôi đã chuẩn bị tinh thần để ghét bài này. Tôi tưởng đây sẽ là kiểu bài điển hình rằng “PM ngu ngốc, công ty chỉ cần những kỹ sư thông minh có thể thống trị thế giới”
Nhưng hóa ra không phải vậy, và tôi nghĩ bài viết gần như chỉ ra vấn đề một cách hoàn hảo
Tuy nhiên, phần giải pháp thì biến mất như thể chỉ vẫy tay cho qua. Kiểu như “hãy tuyển những người bình thường nhưng xuất sắc, mỗi người giỏi một thứ gì đó, ám ảnh với kỹ năng của mình, được thúc đẩy bởi chất lượng, rồi gom họ thành một đội và để họ làm việc mà không có trách nhiệm cá nhân”
Nghe thì hay, nhưng ai có thể đưa ra ví dụ cách này thành công trong thực tế ở một công ty hơn 100 người? Tôi không rõ nó có thể vận hành ra sao ngoài đời
Valve dường như đang, hoặc ít nhất từng, làm theo cách rất giống vậy. Sổ tay nhân viên[0] của họ từng là nội dung quen thuộc trên HN, nhưng dạo này không thấy nhiều nữa. Tôi tò mò không biết cách đó có đang hiệu quả với họ không
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
Có vẻ tác giả đã thực sự làm việc với những product manager rất tầm thường. Tôi là PM có nền tảng kỹ thuật tự học, và đã thấy rất nhiều người tầm thường ở nhiều lĩnh vực
Tôi xem công việc của mình chủ yếu là quản lý rủi ro. Ngay cả một đội gồm các kỹ sư và designer giỏi cũng sẽ đối mặt với nhiều rủi ro trong quá trình ra mắt một sản phẩm tốt
Họ có thể không có kỹ năng giải thích tầm nhìn để thuyết phục người khác, hoặc bộ phận pháp lý có thể đặt ra yêu cầu hay hạn chế về những gì được và không được làm
Công việc của tôi là quản lý những điều đó để phát huy điểm mạnh của đội, và giúp đội tập trung vào việc thực sự quan trọng: xây dựng và ra mắt một sản phẩm tốt
Tôi đánh giá thành công bằng mức độ tôi trở nên không còn cần thiết. Mục tiêu là làm cho tôi không còn cần thiết, để đội có đủ bối cảnh, sự tự tin và hỗ trợ để đưa ra quyết định tốt mà không cần tôi
Tôi thích làm việc cùng các kỹ sư để họ phát triển những năng lực đó, và cùng các engineering manager hiểu điểm mạnh, điểm yếu, mục tiêu của từng kỹ sư để tìm cách giúp họ trưởng thành
Tôi hiểu lập luận rằng trong một utopia lý tưởng, có thể sẽ không cần đến tôi. Nhưng trong hầu hết trường hợp, để làm được việc thực sự xuất sắc thì sẽ phải đối mặt với thách thức và rủi ro, và một PM giỏi là người tạo thêm giá trị ròng bằng cách hợp tác với đội để giúp họ vượt qua những điều đó
Tức là đảm bảo đội có bối cảnh, yêu cầu, insight, chỉ số, mục tiêu, v.v. cần thiết để làm việc tốt nhất, và hiểu cần giải quyết vấn đề gì, cho ai và vì sao
Một PM giỏi tạo ra môi trường tốt đến mức kỹ sư nghĩ rằng “PM chẳng làm gì cả nên không cần thiết”. Nhận định như vậy là thiển cận và, nói thật, khá xúc phạm