Software engineer, product manager và cái giá của chuyên môn

Cám ơn Patrick Nguyễn đã feedback và giúp mình cải thiện bản thảo của bài viết. Mọi người có thể tham khảo newsletter của Patrick ở đây nhé:

The Poly Manager

Become the life long learner of People, Product, and Systems.

The Poly ManagerPhat Nguyen

Gần đây, một bạn học viên hỏi mình:

“Nếu software engineer học thêm về product, liệu họ có thay thế được product manager không?”

Đây là câu hỏi mà dạo này mình nghe khá nhiều, có lẽ một phần vì AI đang khiến ranh giới giữa các công việc trở nên phai mờ hơn. PM có thể tự prototype; engineer có thể tự nghiên cứu thị trường; những thứ trước đây cần vài ngày ngồi mày mò thì bây giờ đôi khi chỉ vài tiếng tám với Claude.

Nếu việc xây dựng phần mềm ít tốn công hơn, engineer có thể dành thêm thời gian để hiểu người dùng, hiểu business, rồi tự quyết định luôn nên xây cái gì. Nhìn như vậy thì việc một người đảm nhiệm cả hai vai trò có vẻ khá hợp lý.

Nhưng có một giả định nằm chìm trong câu hỏi trên: để trở thành một người làm sản phẩm giỏi, engineer chỉ cần học thêm những thứ mình còn thiếu. Chuyên môn engineering đang có vẫn sẽ nằm yên ở đó, rồi chúng ta bổ sung thêm các chuyên môn business, user research, strategy vào bên cạnh. Càng học thì bộ kỹ năng càng đầy đặn, và vòng tròn chuyên môn ngày càng rộng mở.

Mình không chắc quá trình ấy diễn ra êm đẹp như vậy.

Có những kiến thức về product sẽ bổ trợ kiến thức về engineering, nhưng cũng có những thứ trong product yêu cầu engineer phải phá đi chính cách suy nghĩ đã giúp họ thành công. Liệu một người đã quen làm tốt công việc của mình có sẵn lòng chịu đựng giai đoạn mà những phản xạ quen thuộc không còn hữu dụng như trước hay không?

Mình sẽ không bảo vệ vai trò product manager hay nói rằng nó không thể bị thay thế. Ngược lại, mình tin rằng mô hình engineer kết hợp với product vượt trội hơn là non-technical product. Câu hỏi quan trọng hơn ở đây là:

“Software engineer phát triển thêm chuyên môn product có thể rất mạnh, nhưng tại sao những bạn software engineer có thể sẽ không chọn làm vậy?

Câu trả lời có thể được tìm thấy khi chúng ta nhìn vào một khái niệm trong chiến lược kinh doanh: counter-positioning.

Sơ lược về counter-positioning

Trong 7 Powers, Hamilton Helmer mô tả counter-positioning là tình huống một công ty mới áp dụng mô hình kinh doanh tốt hơn, nhưng các công ty đang dẫn đầu không muốn sao chép vì việc đó có thể làm tổn hại chính hoạt động kinh doanh hiện tại của họ.

Trên Substack của Dentmaker có một bài viết về Counter-positioning khá đầy đủ, mình sẽ chỉ trích dẫn lại phần tóm tắt thôi:

Hãy cùng tóm tắt lại những ý niệm cơ bản của counter-positioning.

1. Startup chọn business model đánh trực tiếp vào mô hình kiếm tiền chủ chốt của ông lớn.
2. Thường mô hình mới sẽ rẻ và có trải nghiệm tốt hơn hẳn cho người dùng, người dùng thích nó hơn hẳn so với mô hình cũ.
3. Ông lớn không biết cách phản ứng như thế nào và không muốn tự làm đau mình, nên thường chậm chân.
4. Ngược lại, cách để ông lớn vượt qua điều này là phải tự bắn vào chân mình, thường những công ty làm được điều này phải có tầm nhìn và ý chí lớn của CEO. Thường là founder-CEO.
5. Cách để thành công cũng là phải tạo ra một team riêng biệt với động lực là tiêu diệt chính mô hình hiện tại của công ty để tránh xung đột về lợi ích. Nếu để nguyên là team đang quản lý mô hình hiện tại thì thường tất là khó.

Counter-positioning - Dentmaker

Điểm thú vị của counter-positioning nằm ở chữ không muốn. Nếu đối thủ chỉ thiếu kiến thức hay nguồn lực, họ có thể học hoặc đầu tư thêm. Nhưng khi việc bắt chước gây tổn hại cho hoạt động hiện tại, thì ngay cả một người điều hành thông minh, hiểu rõ tình hình, cũng có lý do để không làm.

Từ đây, mình muốn thử đi thêm một bước: liệu một cá nhân cũng có thể rơi vào tình thế tương tự? Một người engineer đã tích lũy nhiều năm kinh nghiệm cũng đang sở hữu những thứ có giá trị: chuyên môn, uy tín, một cách giải quyết vấn đề đáng tin cậy, và cảm giác rằng mình biết mình đang làm gì. Nếu việc chuyển sang làm product đòi hỏi họ phải xem lại những thứ ấy, thì câu chuyện có lẽ phức tạp hơn việc đăng ký học thêm khóa product như là BPM.

Đây là một mối giả thuyết mà mình muốn khai phá trong bài viết này. Counter-positioning vốn nói về cạnh tranh giữa doanh nghiệp; chúng ta cần phải lập luận để đem nó vào câu chuyện nghề nghiệp.

Trong bất kỳ loại hình lợi thế cạnh tranh nào, bao gồm counter-positioning, Hamilton nói rằng chúng ta phải phân tích lợi ích (benefit) và rào cản (barrier). Hãy bắt đầu từ lợi ích của mô hình engineer kết hợp product.

Nếu engineer làm product mạnh như vậy, tại sao nó không phải mô hình mặc định?

Khi nói về counter-positioning, trước hết chúng ta phải phân định rõ ràng giữa incumbent (mô hình đang thành công và thường phổ biến hơn) và challenger (mô hình mới, tốt hơn và đe dọa incumbent).

• Incumbent: engineer tạo ra giá trị chủ yếu bằng chuyên môn engineering sâu.
• Challenger: engineer kết hợp engineering và product để tạo ra integrated judgement.

Counter-positioning hình thành khi challenger có giá trị vượt trội hơn incumbent, nhưng incumbent lại không muốn sao chép mô hình này do một số đánh đổi.

Ở đây mình dùng incumbent và challenger để chỉ hai cách tạo ra giá trị, không nhất thiết là hai nhóm người cạnh tranh trực tiếp với nhau. Như đã nói ở đầu bài, mình sẽ không cố gắng bảo vệ vai trò product manager; đó là lý do PM còn không có mặt trong bức tranh này. Mình sẽ tập trung nhiều hơn vào việc phân tích tại sao không phải engineer nào cũng sẽ kết hợp chuyên môn product dù cho mô hình đó tốt hơn.

Nhưng mô hình đó có tốt hơn thật không? Mình nghĩ là có, và chìa khóa ở đây chính là ở integrated judgement.

Benefit: engineer làm product có thể rất mạnh

Một người hiểu cả product lẫn engineering có thể đưa ra những phán đoán tốt hơn—đây chính là benefit lớn nhất của việc engineer làm product.

Trong bài Lead Engineer as Product Owner, Marty Cagan mô tả những engineer có tiềm năng đảm nhiệm luôn trách nhiệm sản phẩm. Nếu bạn may mắn được làm với những engineer như vậy sẽ cảm thấy công việc product nhẹ đi phải được bốn năm phần.

It’s usually not very hard to spot engineers with the potential to serve this combined role.  They are very smart, very passionate and articulate about the product, and often insisting on meeting with customers personally.  They want to understand the reasons for decisions and they want to be convinced.  They get very frustrated when the work of the engineers does not result in a win for the customers.

Lead Engineer as Product Owner,

Mình nghĩ giá trị của sự kết hợp này nằm ở cách hai loại hiểu biết tác động qua lại ngay trong lúc suy nghĩ. Thí dụ, một người hiểu kỹ thuật có thể nhận ra rằng vấn đề team đang định bỏ qua thực ra có solution giải quyết khá rẻ. Hoặc họ có thể đánh giá một solution trông đơn giản trên giao diện lại kéo theo nhiều tháng thay đổi kiến trúc, và chủ động tìm cách tiếp cận khác ngay từ lúc định hình vấn đề.

Hiểu solution space giúp ta nhìn ra thêm khả năng trong problem space. Hiểu problem space lại giúp ta biết khả năng kỹ thuật nào đáng sử dụng. Product discovery trong thực tế thường phải di chuyển ở cả problem space sang solution space và ngược lại:

Khi bắt tay làm MVP, tụi mình nghĩ rằng mình đang “giải” vấn đề. Nhưng hoá ra, điều quý giá hơn là những gì nó giúp mình thấy được nhiều hơn: ai thực sự nhìn thấy giá trị của sản phẩm, điều kiện nào khiến họ dùng được, và khi nào cùng một giải pháp lại soi ra một vấn đề hoàn toàn khác. Những điều này không thể hiện trong phỏng vấn, cũng không nằm trong framework nào - chúng chỉ lộ ra khi giải pháp va chạm với thực tế, khi người dùng phản hồi và buộc ta phải quan sát lại chính cách mình đang nghĩ.

Từ đó, mình nhận ra rằng không phải lúc nào ta cũng có thể hiểu rõ vấn đề trước khi hành động. Đôi khi, chính việc làm mới giúp ta hiểu vấn đề sâu hơn. Giải pháp, trong trường hợp này, không còn là đích đến, mà là công cụ để học, để quan sát, để tinh chỉnh lại cách ta nhìn thế giới. ... Mình tin rằng làm sản phẩm tốt không chỉ đi theo bản đồ, họ liên tục vẽ lại nó mỗi lần chạm vào thực tế, mỗi lần thấy vấn đề rõ hơn nhờ chính những giải pháp mà họ dám thử.

"Khi MVP không chỉ để test giải pháp, mà còn để khám phá vấn đề"

Mình tạm gọi sự kết hợp này là integrated judgement. Integrated judgement là một lợi thế có thể xuất hiện khi một người xây dựng được cả chuyên môn engineering lẫn product: họ có thể nhìn problem space và solution space trong mối liên hệ với nhau.

Integrated judgement là khả năng nhận định trong việc làm sản phẩm trội hơn. Đây có lẽ cũng là lý do tại sao có một số startup đã bắt đầu tuyển vai trò product engineer thay vì engineer thuần hay product thuần. Mô hình product kết hợp engineering thật sự có giá trị. Đây là một điều kiện quan trọng trong counter-positioning, vì nó đòi hỏi mô hình mới thực sự có lợi ích (benefit)—nhưng những người đang theo mô hình cũ vẫn có lý do để không chuyển sang cái mới.

Nhưng tại sao việc sở hữu một nhóm kiến thức chuyên môn về engineering có thể làm việc xây dựng chuyên môn trong product? Để hiểu rõ hơn, chúng ta cần nhìn kỹ hơn vào thứ gọi là chuyên môn để hiểu được các rào cản (barriers).

Barrier: tự làm suy yếu chuyên môn

Bản chất của chuyên môn

Khi nhìn một engineer nhiều kinh nghiệm đọc qua một bản system design rồi chỉ ra ngay chỗ có thể gây vấn đề, ta dễ nghĩ rằng họ suy luận nhanh hơn người khác. Điều đó có thể đúng, nhưng còn một cách giải thích khác hợp lý hơn: họ nhìn thấy những thứ mà người ít kinh nghiệm chưa nhìn thấy.

Mô hình Recognition-Primed Decision của Gary Klein giải thích cách các chuyên gia nhận diện tình huống và nghĩ ra một hướng hành động khả dĩ mà không cần liệt kê, so sánh tất cả phương án một cách tỉ mỉ ở trong đầu. Kinh nghiệm giúp họ biết chi tiết nào đáng chú ý và điều gì có thể xảy ra tiếp theo. Chuyên môn khi xảy ra thì thường là tự động, thường là vô thức, và rất khó để viết thành những quy luật để người mới áp dụng được liền. Vấn đề không nằm ở việc thiếu kiến thức chuyên môn, vấn đề là người mới còn không đọc được tình huống để biết nên áp dụng kiến thức nào hay làm gì.

Chúng ta có thể hình dung chuyên môn như một tập hợp các frames: những khuôn diễn giải giúp mình đọc một tình huống và biết nên làm gì với nó. Một engineer nhìn vào một yêu cầu mới có thể lập tức thấy các dependency, những điểm dễ hỏng, hoặc một abstraction phù hợp. Một PM có kinh nghiệm có thể nghe cùng yêu cầu ấy và nhận ra sự lệch nhau giữa người đưa ra yêu cầu, người sử dụng và người chịu trách nhiệm trả tiền (rất phổ biến trong ngữ cảnh B2B).

Không phải chỉ học kỹ năng mới là có thêm frames. Chúng được hình thành qua nhiều lần bắt gặp những tình huống cụ thể, hành động, nhận phản hồi, rồi điều chỉnh hiểu biết nội tại của mình (đóng được vòng tròn). Một software engineer vừa mới tốt nghiệp và bắt đầu đi làm sẽ không có nhiều frames, vì họ chưa từng phải áp dụng các kiến thức kỹ thuật đã học trong trường vào trong thực tế và hứng chịu hậu quả từ những quyết định của mình. Ví dụ cá nhân là mình mãi đến năm thứ tư làm software engineer mới nghiệm ra một chút về chuyện design patterns thực chất để làm gì và apply ra sao.

Qua nhiều năm, các frame ấy còn trở nên quen thuộc và tự động đến mức chúng ta ít khi ý thức rằng mình đang sử dụng chúng. Đây là một phần giá trị của chuyên môn: ta không cần bắt đầu lại từ đầu mỗi ngày. Nhưng sự quen thuộc và tự động trong chuyên môn này cũng có mặt trái.

Chuyên môn trong một lĩnh vực khiến xây dựng chuyên môn khác trở nên khó hơn

Khi một cách suy nghĩ đã quá vững chắc, chúng ta có thể tiếp tục dùng nó ngay cả khi tình huống cần được nhìn theo cách khác. Erik Dane bàn về vấn đề này qua khái niệm cognitive entrenchment: tính ổn định của các frames có thể hạn chế khả năng thay đổi cách tiếp cận.

Không có nghĩa là chuyên gia nào cũng sẽ trở nên cứng nhắc, nhưng nó chỉ ra một rủi ro của chuyên môn sâu: thứ giúp chúng ta nhìn thấy vấn đề nhanh hơn (frames) cũng có thể khiến ta ngừng tìm kiếm một cách nhìn khác quá sớm.

Thử tưởng tượng người dùng nói với team: “Mỗi tuần mình phải mất nửa ngày để xuất dữ liệu rồi làm báo cáo cho sếp.”

• Phản ứng chuyên môn của engineer. Trong một team nơi engineer chủ yếu được PM giao những bài toán đã xác định rõ ràng, phản xạ quen thuộc có thể là nghĩ đến việc tự động hóa: dữ liệu nằm ở đâu, cần nối những hệ thống nào, có thể lên lịch gửi báo cáo hay không. Chỉ một lúc sau, hình dạng của giải pháp đã xuất hiện khá rõ.
• Phản ứng chuyên môn của product. Một người đang làm discovery có thể muốn ở lại với câu chuyện ấy thêm chút nữa. Người sếp dùng báo cáo để ra quyết định gì? Phần nào trong nửa ngày ấy thực sự tốn công? Nếu báo cáo được gửi nhanh hơn thì điều gì thay đổi? Có thể sau khi tìm hiểu, ta nhận ra phần tốn thời gian nhất là giải thích những con số không khớp giữa hai phòng ban. Tự động hóa việc xuất dữ liệu vẫn làm được, nhưng nó chỉ xử lý một phần nhỏ của chuyện đang khiến người dùng mệt mỏi.

Trong tình huống này, khả năng nhanh chóng hình dung một giải pháp kỹ thuật có thể kéo sự chú ý của ta về phía triển khai trước khi hiểu đủ vấn đề. Khi giải pháp càng gọn đẹp và khả thi, việc tiếp tục chất vấn nó càng trở nên khó chịu. Ta đã nhìn thấy một thứ có thể xây, và rất muốn bắt tay vào xây nó.

Hiển nhiên, nhiều engineer giỏi sẽ đặt những câu hỏi về vấn đề người dùng ngay từ đầu, cũng như nhiều PM dễ nhảy vào việc vẽ ra giải pháp rất nhanh. Mình chỉ đang nói về những phản xạ được môi trường rèn luyện và reward, còn chức danh không tự động quyết định cách một người suy nghĩ.

Đây là chỗ negative transfer có thể xuất hiện: một phản xạ có ích trong bối cảnh quen thuộc lại gây cản trở khi được mang sang bối cảnh đòi hỏi cách phản ứng khác. Negative transfer là một phần lý do mình nghĩ cấu trúc giống counter-positioning có thể xuất hiện: để xây dựng chuyên môn product, một engineer phải học cách không để những phản xạ engineering vốn rất hữu ích chi phối mọi tình huống. Điều này không nhất thiết khiến họ trở thành engineer kém hơn, nhưng nó đòi hỏi họ xây dựng một tập hợp frames khác, đôi khi cạnh tranh với cách phản ứng đã được củng cố suốt nhiều năm.

Không chỉ là negative transfer, mà software engineer phải trả chi phí cơ hội (opportunity cost) phát triển chuyên môn product.

Chi phí cơ hội phải trả để engineer thay thế product

Đến đây, chúng ta mới giải thích được vì sao việc chuyển vai trò có thể khó, bởi vì phản xạ của engineer và của product trên cùng một vấn đề có thể rất khác nhau. Nhưng học nghề nào mà chẳng khó? Nếu chỉ dừng ở đó thì chưa cần đến counter-positioning.

Để product trở thành một chuyên môn thực sự chứ không chỉ là một nhóm kỹ năng phụ trợ, engineer phải dành cho nó chính thứ tài nguyên đã giúp họ xây dựng lợi thế engineering: thời gian, sự chú ý và số lần va chạm với thực tế. Ở mức nào đó, hai quá trình xây dựng chuyên môn cạnh tranh với nhau.

Mắt xích nằm ở cái giá mà người học phải trả cho chính vị thế hiện tại của mình. Sau đây là một số lý do mà vị thế của engineer có thể bị suy yếu nếu muốn phát triển thêm chuyên môn product.

• Status. Một engineer có nhiều kinh nghiệm đang được tin tưởng vì họ có thể tháo gỡ những bài toán kỹ thuật khó. Khi có sự cố, mọi người tìm đến họ. Khi có một hướng kiến trúc cần cân nhắc, ý kiến của họ có trọng lượng. Chuyên môn ấy vừa tạo ra giá trị cho tổ chức, vừa mang lại cho họ sự công nhận và cảm giác thành thạo.
• Habits. Bước sâu sang product có thể đòi hỏi họ dành ít thời gian hơn cho những việc ấy. Họ phải tham gia những cuộc trò chuyện mà mình chưa biết cách đọc tình huống, đưa ra những quyết định có phản hồi chậm và khó diễn giải hơn, rồi chịu trách nhiệm cho kết quả không thể xác nhận chỉ bằng việc hệ thống đã chạy đúng.
• Self-assessment. Cách đánh giá một ngày làm việc tốt cũng có thể thay đổi. Có hôm, kết quả hữu ích nhất của discovery là nhận ra thứ team định xây không đáng để tiếp tục. Để thấy đó là tiến bộ, một người đã quen tìm niềm vui trong việc xây dựng cần điều chỉnh cả cách mình cảm nhận về công việc. Trải nghiệm làm product của mình là những chuỗi ngày dài cố gắng điều hướng mà không thấy đường ra, để rồi đến một lúc nhìn thấy được tia sáng cuối đường hầm. Trước đó khi làm engineer, dường như mình luôn cảm giác có thành tựu mỗi tuần khi mà phát triển hay release được tính năng gì đó.
• Organizational incentives. Việc chuyển đổi vì vậy có thể tác động đến thời gian, mức độ thành thạo, uy tín và bản dạng nghề nghiệp. Trong một tổ chức vẫn chủ yếu tưởng thưởng người engineer cho đóng góp kỹ thuật, khoản đầu tư vào product còn có thể không được ghi nhận tương xứng. Ngay cả hơn 5-6 năm trước lúc mình chuyển từ engineer sang product, mình biết rằng đã có người nghĩ mình dev lỏm hoặc không tập trung chuyên môn mà bày đặt này kia. Điều đó không vui tí nào.

Đây là phần có cấu trúc tương đồng với counter-positioning: để theo đuổi một cách tạo ra giá trị mới, ta có thể phải làm suy yếu vị thế mà mình đang được hưởng từ cách tạo ra giá trị cũ.

Với một số người, cái giá của việc tự làm suy yếu chuyên môn ấy là đáng trả. Với những người khác, tiếp tục đi sâu vào engineering là lựa chọn phù hợp hơn. Họ vẫn có thể hiểu business, quan tâm đến người dùng và phối hợp rất tốt với PM mà không muốn nhận toàn bộ trách nhiệm của vai trò này.

Mình đoán rằng có nhiều software engineer sẽ không chọn phát triển chuyên môn product. Chữ sẽ không mình muốn nói đến nằm ở đây. Có khả năng làm một công việc và có lý do để lựa chọn công việc ấy là hai chuyện khác nhau.

AI giảm chi phí làm việc, không xoá bỏ chi phí xây dựng chuyên môn

Giờ quay lại AI, thứ đã khiến câu hỏi ban đầu xuất hiện thường xuyên hơn.

AI có thể hỗ trợ viết code, tổng hợp tài liệu, tạo prototype, chuẩn bị câu hỏi phỏng vấn hay phác thảo một bản spec. Khi những hoạt động này ít tốn công hơn, việc thử sức với phần việc của một vai trò khác cũng trở nên dễ tiếp cận hơn. Nhưng như mình nói ở trên, expert frames được hình thành không phải do làm nhiêui2 đầu việc, mà l được cô đọng thông qua việc đóng nhiều vòng lặp từ thực tế đến quyết định đến kết quả (closing the loop).

AI chắc chắn có thể giúp quá trình xây dựng chuyên môn diễn ra nhanh hơn. Nhưng nếu frames được hình thành bằng việc liên tục đi từ thực tế, đến phán đoán, đến hành động, rồi quan sát kết quả để điều chỉnh lại cách nhìn, thì việc AI giúp ta thực hiện một hành động nhanh hơn mới chỉ rút ngắn một phần của vòng lặp ấy. Nó không tự động đóng vòng lặp thay cho chúng ta. Ngoài ra, theo quan sát của mình, thì nếu bạn không có thói quen đóng vòng tròn trước khi có AI, bạn cũng sẽ không làm vậy sau khi có AI. Tóm lại, AI không trực tiếp giúp xây dựng chuyên môn.

Sau đây là một sơ đồ mà mình dùng AI gen từ bài blog này, để giúp cho các bạn đọc giả theo dõi được luồng lập luận từ đầu đến giờ.

Kết luận: sẽ không, chứ không phải không thể

Vậy nếu trả lời lại bạn học viên, mình sẽ nói rằng engineer hoàn toàn có thể trở thành một người làm sản phẩm rất giỏi. Nền tảng kỹ thuật còn có thể giúp họ nhìn ra những khả năng mà người khác bỏ lỡ.

Tuy nhiên, mình không nghĩ chuyện AI làm cho một số đầu việc dễ hơn sẽ tự động khiến engineer thay thế PM trên diện rộng. Để đảm nhiệm tốt cả hai, một người cần nhiều hơn việc bổ sung kiến thức business vào chuyên môn sẵn có.

Việc software engineer có thể đảm nhiệm product không có nghĩa họ sẽ chọn làm vậy. AI làm việc vượt qua ranh giới nghề nghiệp dễ hơn, nhưng không xóa cái giá của việc xây dựng một loại chuyên môn khác.

Counter-positioning giúp chúng ta chú ý đến một yếu tố quan trọng: có những người không bước sang một vai trò khác vì họ có những lý do hợp lý để giữ lại công việc và vị thế hiện tại. Counter-positioning là một góc nhìn để hiểu tại sao nhiều người lại chọn như vậy, chứ không phải một định luật đảm bảo vai trò PM sẽ luôn tồn tại.

Những software engineers chọn bước sang product, và học được cách phối hợp cả hai loại phán đoán để có integrated judgement, có thể trở nên rất mạnh. Họ vừa nhìn thấy những gì công nghệ cho phép, vừa có khả năng chất vấn xem điều gì đáng được xây dựng. Để đi đến đó, có lẽ phần khó nhất không nằm ở việc thừa nhận rằng mình còn thiếu kiến thức. Phần khó hơn là nhận ra một phản xạ chuyên môn đã giúp mình làm tốt công việc suốt nhiều năm, rồi chấp nhận rằng mình cần học cách phản ứng khác đi để có được judgement toàn vẹn hơn.