Beyond Job Titles
Khi AI làm mờ ranh giới giữa PM, Engineer, Designer và Data Scientist, điều quan trọng không còn là chức danh của chúng ta, mà là cách mỗi người tạo ra giá trị trong từng giai đoạn sản phẩm
Nay mình có đọc một bài viết của Boris Cherny khá thú vị, Boris nói về việc các vai trò quen thuộc trong product team như engineering, product, design, data science… đang dần melt vào một dạng vai trò mới.
Thay vì nhìn một team theo những chức danh truyền thống như Product Manager, Engineer, Designer, Data Scientist, him thử nhìn team qua 5 kiểu đóng góp khác nhau:
Prototyper: người nghĩ ra ý tưởng mới, thử nhanh, tạo nhiều prototype, phần lớn có thể không bao giờ được ship.
Builder: người biến prototype hoặc idea thành sản phẩm thật, đủ tốt để chạy production.
Sweeper: người dọn dẹp UI, đơn giản hóa code và system, bỏ bớt những thứ không cần, tối ưu performance.
Grower: người lấy một sản phẩm đã được build rồi tiếp tục iterate để cải thiện Product-Market Fit.
Maintainer: người giữ một hệ thống mature được secure, reliable, fast và efficient khi scale.
Đọc qua thì có vẻ đây chỉ là một cách phân loại mới. Nhưng càng nghĩ, mình càng thấy nó phản ánh khá đúng những gì đang xảy ra trong các product team hiện đại, đặc biệt là trong bối cảnh AI và coding agent đang làm mờ ranh giới giữa các function.
Điều thú vị không nằm ở việc chúng ta có thêm 5 cái tên mới. mà điều đáng suy nghĩ hơn là: có lẽ job title đang ngày càng không còn đủ để mô tả giá trị thật mà một người tạo ra trong team.
1. Từ chức danh sang kiểu tạo giá trị
Trước đây, mình cũng thường nhìn team theo cấu trúc khá quen thuộc: PM lo requirement và roadmap, BA làm rõ nghiệp vụ, Designer làm UI/UX, FE/BE lo implementation, QC test, DevOps deploy và vận hành.
Cách chia này không sai, thậm chí trong nhiều team, nó vẫn rất cần thiết để phân định ownership, quy trình và trách nhiệm.
Rồi đến lúc mình làm đủ lâu với những sản phẩm đã thật sự đi vào production, nơi mọi quyết định đều tác động đến client, user và business, mình bắt đầu nhận ra: chức danh chưa bao giờ là thứ mô tả đầy đủ giá trị mà một người mang lại cho team.
Developer, QC hay Designer đều có thể tạo ra giá trị vượt ra ngoài phần mô tả công việc của mình.
Mình từng làm việc với những developer mà điều họ quan tâm không chỉ là hoàn thành ticket. Họ nhìn ra flow nào đang trở nên rối rắm, logic nào đang sinh ra quá nhiều edge case, hay quyết định nào hôm nay có thể trở thành technical debt của vài tháng sau. Họ không chỉ xây thêm sản phẩm, mà còn chủ động làm cho sản phẩm trở nên đơn giản và bền vững hơn. Theo cách Boris mô tả, đó vừa là một Builder, vừa mang tư duy của một Sweeper.
Điều tương tự cũng xảy ra với QC. Những người giỏi không chỉ tìm bug để đánh dấu pass hay fail. Họ hiểu business, hình dung được cách người dùng sẽ sử dụng sản phẩm và nhận ra những rủi ro mà PM hoặc developer đôi khi chưa kịp nghĩ tới. Mỗi bug họ phát hiện không chỉ là một lỗi được sửa, mà có thể là một sự cố được ngăn chặn trước khi ảnh hưởng đến khách hàng hay doanh thu.
Với designer cũng vậy. Giá trị lớn nhất của họ không nằm ở việc tạo ra những màn hình đẹp, mà ở việc liên tục đặt câu hỏi: tại sao người dùng phải thực hiện bước này, liệu có thể bỏ bớt một thao tác hay giảm cognitive load ở đâu không. Khi bắt đầu chất vấn chính flow của sản phẩm thay vì chỉ chăm chút giao diện, designer lúc đó đã bước sang vai trò của một người làm product thinking.
Và với PM, mình cũng thấy điều tương tự. PM không chỉ viết requirement hay quản lý Jira. Ở nhiều thời điểm, PM phải prototype flow, clarify scope, translate business expectation thành product decision, gom feedback từ client, cắt bớt những thứ chưa cần làm, và đôi khi phải đứng giữa áp lực business với thực tế engineering.
Nói cách khác, câu hỏi quan trọng không còn chỉ là:
“Bạn là PM, Engineer hay Designer?”
Mà là:
“Ở giai đoạn này của sản phẩm, bạn đang tạo ra loại giá trị gì?”
2. Khi làm product, mình bắt đầu thấy rõ 5 vai trò này
Mình thấy rõ điều này nhất khi làm với các sản phẩm đã đi vào production.
Ở giai đoạn đầu, một sản phẩm thường cần rất nhiều năng lượng của Prototyper và Builder. Team cần thử nhanh, dựng nhanh, biến một idea còn mơ hồ thành thứ có thể demo, có thể test, có thể đặt trước mặt client hoặc user để lấy feedback.
Ví dụ khi xây một CRM/trading platform, giai đoạn đầu team phải dựng rất nhiều foundation: authentication, trading flow, KYC, referral, multi-account, CRM structure, roles & permission, settings foundation. Lúc này, điều quan trọng nhất là sản phẩm phải có hình hài đủ rõ để mọi người cùng nhìn thấy nó đang trở thành cái gì.
Nhưng khi sản phẩm bắt đầu có client thật, user thật và feedback thật, nhu cầu của team cũng thay đổi.
Câu hỏi không còn chỉ là “làm sao build được tính năng này?”, mà dần chuyển thành “làm sao để sản phẩm này tiếp tục phát triển mà không trở nên quá nặng?”.
Ở giai đoạn này, Grower bắt đầu quan trọng hơn. Vì sản phẩm không chỉ cần được build, mà cần được học từ feedback thật. Có những flow tưởng hợp lý trên Figma nhưng khi đưa vào sử dụng lại tạo ra friction. Có những requirement ban đầu nghe rất cần thiết nhưng sau vài vòng feedback mới thấy không thật sự phục vụ MVP. Có những tính năng đã ship rồi nhưng vẫn cần iterate liên tục để đến gần hơn với nhu cầu thật của user và business.
Rồi khi sản phẩm lớn hơn, complexity bắt đầu xuất hiện. Scope thay đổi sau mỗi sprint. Deadline bị rút ngắn. Team mở rộng với những thành viên mới cần onboarding. Những quyết định nhỏ ở giai đoạn đầu bắt đầu tạo ra hiệu ứng dây chuyền lên toàn bộ hệ thống.
Đây là lúc team cần nhiều hơn tư duy của Sweeper: người biết nhìn lại những gì đã build, nhận ra phần nào đang trở nên rối, phần nào có thể đơn giản hóa, phần nào nên cắt bớt để sản phẩm tiếp tục di chuyển nhẹ hơn.
Và khi sản phẩm thật sự đi vào production, có merchant, user, dữ liệu và business thật, Maintainer trở nên cực kỳ quan trọng. Lúc này, sản phẩm không thể chỉ sống bằng roadmap feature. Nó còn phải sống bằng reliability, security, performance, khả năng xử lý incident, khả năng tương thích với thay đổi từ platform bên ngoài, và khả năng giữ được niềm tin của client qua từng lần vận hành.
Điều mình rút ra là: không có archetype nào luôn quan trọng hơn archetype nào.
Một sản phẩm ở giai đoạn rất sớm có thể cần nhiều Prototyper hơn Maintainer. Một sản phẩm đang scale có thể cần Sweeper hơn Builder. Một sản phẩm đã có user thật có thể cần Grower nhiều hơn người nghĩ thêm idea mới. Và một sản phẩm mature có thể cần Maintainer hơn bất kỳ vai trò nào khác.
Vấn đề không phải là team có đủ mọi chức danh hay chưa.
Vấn đề là: ở giai đoạn hiện tại, sản phẩm đang cần kiểu đóng góp nào nhất, và team có nhận ra điều đó đủ sớm hay không?
3. Sweeper là vai trò bị đánh giá thấp nhất
Trong 5 archetype mà Boris đưa ra, mình bị ấn tượng nhất với Sweeper.
Có lẽ vì đây là kiểu đóng góp rất dễ bị bỏ quên.
Trong hầu hết các buổi planning hay review, chúng ta thường hào hứng nói về ý tưởng mới, feature mới, roadmap mới, hoặc những thứ sắp được release. Đó là những thành quả dễ nhìn thấy. Chúng tạo cảm giác sản phẩm đang tiến lên, team đang ship nhanh hơn, và mọi thứ đang có chuyển động.
Nhưng product không chỉ tiến lên bằng cách build thêm.
Có những thời điểm, điều quan trọng hơn lại là quay lại nhìn những gì mình đã xây và tự hỏi: phần nào đang bắt đầu trở nên quá nặng?
Một đoạn code từng hợp lý ở giai đoạn đầu có thể trở nên rườm rà sau nhiều lần thay đổi.
Một flow ban đầu chỉ có vài bước có thể dần phình ra thành một trải nghiệm khó hiểu.
Một feature từng được build để giải quyết một nhu cầu rất cụ thể trong quá khứ có thể không còn phù hợp với sản phẩm hiện tại.
Một requirement mơ hồ nếu không được làm rõ từ đầu có thể tạo ra rất nhiều logic chồng chéo về sau.
Và một lớp complexity nhỏ, nếu cứ được giữ lại qua nhiều sprint, cuối cùng sẽ trở thành thứ kéo cả sản phẩm chậm xuống.
Những công việc như vậy hiếm khi xuất hiện trong release note. Không ai chụp ảnh màn hình một đoạn code được refactor, một flow được rút từ bảy bước xuống còn ba bước, hay một feature được quietly unship để khoe rằng team vừa tạo ra giá trị.
Nhưng càng làm những sản phẩm lớn và sống đủ lâu trên production, mình càng thấy chính những việc ẩn phía sâu ấy lại là thứ quyết định sản phẩm có thể tiếp tục phát triển hay không.
Vì nếu không có Sweeper, sản phẩm sẽ ngày càng nặng.
Mình từng thấy nhiều tình huống mà vấn đề lớn nhất của sản phẩm không phải là thiếu feature. Ngược lại, sản phẩm có quá nhiều feature, quá nhiều case, quá nhiều logic chồng chéo, và quá nhiều thứ từng đúng ở một thời điểm nào đó nhưng không còn đúng ở hiện tại.
Khi sản phẩm còn nhỏ, mỗi shortcut có vẻ không đáng kể.
Nhưng khi sản phẩm lớn hơn, mỗi logic cũ, mỗi quyết định tạm thời, mỗi phần debt chưa được xử lý đều trở thành một khoản lãi kép âm.
Nó làm team chậm hơn.
Làm onboarding người mới khó hơn.
Làm QC khó test hơn.
Làm PM khó explain hơn.
Làm client khó hiểu hơn.
Và cuối cùng, làm user phải gánh một phần phức tạp mà lẽ ra team nên xử lý ở phía sau.
Vì vậy, mình nghĩ Sweeper không phải là vai phụ trong product team hiện đại.
Sweeper là người giúp sản phẩm giữ được sự nhẹ nhàng cần thiết để tiếp tục di chuyển. Họ không chỉ “dọn dẹp” những gì đã cũ. Họ bảo vệ khả năng phát triển tiếp theo của sản phẩm, bằng cách liên tục giảm bớt những lớp complexity không còn tạo ra giá trị.
4. Maintainer không chỉ là người bảo trì hệ thống
Một vai trò khác mình thấy rất rõ khi làm các sản phẩm production là Maintainer.
Với những sản phẩm đã có merchant, user, dữ liệu thật và business thật, công việc quan trọng không chỉ là build thêm feature. Sản phẩm cần được vận hành ổn định.
Có những lúc thứ quan trọng nhất không phải là thêm một màn hình mới, mà là xử lý webhook, kiểm tra rate limit, upgrade API, tối ưu database, kiểm tra billing, xử lý incident, hoặc đảm bảo một thay đổi từ platform bên ngoài không làm ảnh hưởng đến merchant.
Những việc này thường không tạo ra cảm giác “product innovation”. Nhưng chúng bảo vệ business.
Một app Shopify mình quản lý đang chạy production không thể chỉ sống bằng roadmap feature. Nó còn phải sống bằng reliability, security, performance, compatibility với thay đổi từ Shopify, và khả năng phản ứng nhanh khi có issue.
Đây là chỗ mình thấy Maintainer thường bị hiểu sai.
Maintainer không phải là người chỉ làm việc nhàm chán sau khi sản phẩm đã xong. Maintainer là người giữ cho sản phẩm tiếp tục đáng tin cậy khi nó đã có người dùng thật.
Ở giai đoạn mature, một lỗi nhỏ có thể không còn nhỏ nữa. Nó có thể ảnh hưởng đến merchant, đến revenue, đến niềm tin của client, đến uy tín của team.
Vì vậy, nếu Prototyper giúp sản phẩm có cơ hội được sinh ra, Builder giúp sản phẩm thành hình, Grower giúp sản phẩm lớn lên, thì Maintainer giúp sản phẩm phát triển bền vững.
5. AI không làm các vai trò này biến mất, nhưng nâng chuẩn của chúng lên
Một phản biện khá thú vị dưới bài của Boris là: nếu coding agent ngày càng mạnh, Builder và Sweeper có còn cần thiết không? Nếu Claude Code đã có thể build, refactor, cleanup, viết test, vậy con người còn đóng vai trò gì?
Mình nghĩ AI thật sự đang làm cho Builder và Sweeper mạnh hơn rất nhiều.
Một PM bây giờ có thể dùng AI để prototype flow, viết draft requirement, tạo user story hoặc nhanh chóng kiểm tra một vài hướng giải pháp trước khi đưa vào discussion với team.
Một designer có thể dùng AI để biến một ý tưởng UI còn rất thô thành wireframe, mockup hoặc demo đủ rõ để team cùng phản biện.
Một engineer có thể dùng AI để generate code, refactor, viết test, review logic hoặc thử nhiều hướng implementation nhanh hơn trước.
Một BA cũng có thể dùng AI để phân tích requirement, tìm edge case, viết acceptance criteria và làm rõ những điểm mơ hồ trong nghiệp vụ.
Nhưng điểm quan trọng là: AI có thể giúp chúng ta làm nhanh hơn, chứ không tự quyết định được điều gì thật sự đáng làm.
AI không tự hiểu trade-off business trong một context cụ thể.
AI không biết client đang thật sự kỳ vọng điều gì nếu con người không đưa vào đúng bối cảnh.
AI không biết requirement nào chỉ là mong muốn nhất thời, requirement nào thật sự quan trọng với MVP.
AI cũng không tự phân biệt được debt nào có thể chấp nhận để ship nhanh, và debt nào sẽ khiến sản phẩm rất khó scale về sau.
Nói cách khác, AI có thể tăng tốc execution, nhưng judgment vẫn là phần việc của con người.
Và chính vì AI làm execution nhanh hơn, vai trò của judgment lại càng trở nên quan trọng hơn. Khi việc build trở nên dễ hơn, câu hỏi khó nhất không còn là “có build được không?”, mà là “có nên build không?”.
Builder trong tương lai có lẽ không chỉ là người code tốt mà Builder là người biết dùng AI để biến idea thành production-grade product nhanh hơn, nhưng vẫn hiểu architecture, security, scalability và business context.
Sweeper trong tương lai cũng không chỉ là người refactor code. Sweeper là người có taste và judgment để biết cái gì đang làm sản phẩm phức tạp hơn mức cần thiết.
Có thể AI giúp chúng ta làm nhanh hơn rất nhiều. Nhưng chính vì nhanh hơn, team càng cần người biết dừng lại và hỏi:
Cái này có thật sự nên build không?
Nếu build, có nên build theo cách này không?
Nếu không build, có cách nào đơn giản hơn không?
Nếu phải ship nhanh, debt nào chấp nhận được và debt nào không?
Đó là phần mà mình nghĩ AI sẽ không thay thế dễ dàng: product judgment.
6. Role nên là mode, không phải identity
Một ý mình nghĩ không nên định nghĩa archetype quá cứng, vì con người dễ nhìn vào đó rồi nghĩ đó chính là họ.
Nếu một người nói “tôi là Prototyper” rồi từ chối maintain, đó là vấn đề.
Nếu một người nói “tôi là Builder” rồi không quan tâm user feedback, đó cũng là vấn đề.
Nếu một PM nói “tôi chỉ làm strategy” và không chịu đi vào delivery detail khi sản phẩm cần, đó cũng là vấn đề.
Trong thực tế, role nên là một mode đóng góp theo context, không phải identity cố định.
Có lúc một người cần là Prototyper.
Có lúc cần là Builder.
Có lúc cần là Sweeper.
Có lúc cần là Grower.
Có lúc cần là Maintainer.
Điều này đặc biệt đúng với PM. Vì PM thường là người phải thay đổi mode rất nhiều tùy theo giai đoạn sản phẩm.
Khi sản phẩm còn mơ hồ, PM phải giúp prototype problem và solution.
Khi sản phẩm bước vào build, PM phải giúp team rõ scope, rõ priority, rõ acceptance criteria.
Khi sản phẩm bắt đầu rối, PM phải sweep requirement, simplify roadmap, cắt bớt những thứ chưa cần.
Khi sản phẩm có user, PM phải grow bằng cách hiểu feedback, dữ liệu, behavior và PMF.
Khi sản phẩm lên production, PM phải maintain expectation, maintain trust, maintain operating rhythm giữa client và team.
Đó là lý do mình nghĩ PM không nên chỉ được hiểu là “người quản lý backlog”. PM trong một product team tốt phải biết chuyển mode theo nhu cầu thật của sản phẩm.
7. Một team khỏe không phải là team toàn người ship nhanh
Có một hiểu lầm phổ biến trong product development: team mạnh là team ship thật nhanh.
Mình nghĩ điều này chỉ đúng một phần.
Ship nhanh rất quan trọng, nhất là ở giai đoạn đầu. Nhưng nếu team chỉ biết ship nhanh mà không biết dọn, không biết học từ feedback, không biết maintain hệ thống, thì tốc độ ban đầu có thể trở thành món nợ về sau.
Một team toàn Prototyper sẽ có rất nhiều ý tưởng nhưng thiếu sản phẩm thật.
Một team toàn Builder sẽ ship nhiều nhưng có thể build cả những thứ không nên build.
Một team thiếu Sweeper sẽ tạo ra complexity ngày càng lớn.
Một team thiếu Grower sẽ có sản phẩm nhưng không biết cải thiện PMF.
Một team thiếu Maintainer sẽ có hệ thống chạy được hôm nay nhưng không chắc chạy tốt khi scale.
Vì vậy, team khỏe không phải là team có nhiều người giỏi giống nhau.
Team khỏe là team biết sản phẩm đang ở phase nào, đang thiếu kiểu đóng góp nào, và có đủ người sẵn sàng chuyển mode khi context thay đổi.
Ở góc nhìn PM, đây là một câu hỏi rất đáng đặt ra khi nhìn lại team:
Hiện tại sản phẩm của mình đang cần nhiều Prototyper hơn hay Builder hơn?
Có phải team đang build quá nhiều nhưng thiếu Sweeper?
Có phải sản phẩm đã có user nhưng chưa có Grower đúng nghĩa?
Có phải hệ thống đã mature nhưng Maintainer lại chưa được xem trọng?
Những câu hỏi này đôi khi quan trọng hơn việc chỉ hỏi: sprint này còn bao nhiêu ticket?
8. Điều mình rút ra
Mình không nghĩ bài của Boris đang nói rằng PM, Engineer, Designer hay Data Scientist sẽ biến mất.
Các function truyền thống vẫn quan trọng. Domain expertise vẫn rất quan trọng.
Mỗi function vẫn cần giữ phần chuyên môn lõi của mình. Engineer vẫn cần hiểu system design, architecture, security và performance. Designer vẫn cần hiểu interaction, visual hierarchy và cách người dùng cảm nhận sản phẩm. Data Scientist vẫn cần hiểu data quality, measurement, experiment và causal reasoning. PM vẫn cần hiểu strategy, prioritization, stakeholder management và khả năng đưa sản phẩm đi đến kết quả cuối cùng.
Nhưng có lẽ cách chúng ta nhìn giá trị của một người trong team sẽ cần thay đổi.
Thay vì chỉ nhìn vào title của một người, có lẽ chúng ta nên nhìn sâu hơn vào kiểu giá trị mà họ đang tạo ra trong context hiện tại.
Có người giúp team mở ra một hướng đi mới khi mọi thứ còn mơ hồ.
Có người biến một idea còn rất thô thành sản phẩm thật, đủ rõ để test, để demo, để đưa vào production.
Có người giúp sản phẩm trở nên đơn giản hơn, nhẹ hơn, bớt phức tạp hơn sau nhiều vòng thay đổi.
Có người liên tục học từ feedback thật để giúp sản phẩm tiến gần hơn với user và business.
Và cũng có người âm thầm giữ cho hệ thống ổn định, đáng tin cậy, an toàn và bền vững khi sản phẩm bắt đầu scale.
Với mình, đây mới là phần đáng suy nghĩ nhất. Giá trị của một người trong product team hiện đại không chỉ nằm ở việc họ đang giữ chức danh gì, mà nằm ở việc họ đang giúp sản phẩm tiến lên theo cách nào.
Trong tương lai, người giỏi có thể không phải là người chỉ master một chức danh cố định. Người giỏi là người hiểu sản phẩm đang ở giai đoạn nào, nhận ra team đang cần kiểu đóng góp gì, và đủ linh hoạt để chuyển mode khi context thay đổi.
Vì sau cùng, product team không tồn tại để bảo vệ job title.
Product team tồn tại để tạo ra giá trị cho user, cho business, và cho chính hệ thống mà mình đang xây dựng.
Nếu một title, một quy trình, hay một cách chia function không còn giúp team tạo ra giá trị tốt hơn, thì có lẽ đã đến lúc chúng ta nên nhìn nó theo một cách khác.
Không phải để xóa bỏ vai trò cũ.
Mà để hiểu rõ hơn: trong một product team hiện đại, giá trị thật không nằm ở việc chúng ta được gọi là gì, mà nằm ở việc chúng ta giúp sản phẩm tiến lên theo cách nào.