When AI can't replace product owner in million dollar project (yet)
222 ngày làm product owner cho dự án triệu đô trong một big corp tại New Zealand và suy ngẫm làm thế nào để không bị AI thay thế
In anniversary of my one year writing on Substack.
For those who are concerns about how to survive in this AI-era, myself including.
And for those who come after, as an retrospective read.
In hindsight, this writing might seem silly few more years down the line as technological landscape changes, we’ll see.
Bài viết nhiều quan điểm cá nhân từ trải nghiệm riêng từ một người background business làm product owner một product ERP tại công ty FMCG nọ.
Mục lục
My story - Starting from zero
Will I be replace by AI?
Surviving the AI replacement trend
Reach for the stars, Coromandel, 2025
My story - Starting from zero
Hồi còn đi học đại học, mình hay mơ mộng về một ngày được tự tay build product - một thứ gì đó để lại dấu ấn của riêng mình. Ý tưởng về việc có một legacy để lại khiến mình thấy rất hứng thú.
Tiếng Anh có câu: “Be careful what you wish for”. Vào một ngày đẹp trời 4 năm sau, ở một đất nước xa lạ, mình được trao cơ hội để làm điều đó.
Cầu được ước nấy, 2 tháng sau khi mình join công ty, sếp quay ra nói với mình: “Bây giờ em lead dự án này và dự kiến deliver trong năm tới nhé”. Đây chỉ là 1 trong top 14 dự án transformation lớn nhất trước giờ của công ty thôi mà, no pressure!
Một chút background, trước khi mình join công ty, dự án đã được start từ đầu năm. Tiền thân của nó là 1 project liên quan tới Finance (FP&A) - một platform modelling chuyên dùng phân tích, giờ được customize thêm module cho mục đích quản lý cho các hoạt động của Sales & promotion planning. Khi mình onboard, product vừa chuyển từ closed development sang phiên bản đầu tiên (MVP) để đưa tới tay đội Sale sử dụng.
Tưởng như mọi thứ gần đã gần hoàn thiện, chỉ cần cải tiến thêm một vài tính năng trước khi go live, thì thực tế phủ gáo nước lạnh vào đầu. Tính tới hiện tại thì project đã hơn 1 năm trong development hell: một vài thứ phải đập đi làm lại, tốn vài trăm nghìn $ tiền budget và phải xin thêm. Nói vui giống con người có combo nhiệt tình + thiếu hiểu biết = phá hoại, thì trong product development có combo kì vọng cao + quá nhiều stakeholder = cam chịu (cam kết chịu không nổi). Khi ai cũng muốn tool mới giải quyết được vấn đề của mình, thì giống như có cái búa nhìn đâu cũng thấy đinh, và hệ quả là chiếc backlog (to-do) dài như chiếc sớ mãi không hết.
Cú sốc “văn hóa” từ vị trí mới đối với mình cũng không nhẹ nhàng lắm - một người mới join công ty vài tháng, còn chưa hiểu hết về “route-to-market” ở thị trường, chiếc pricing structure 3 tầng độc lạ, cộng thêm một hệ thống legacy SAP xài hơn chục năm với vài chục module “độ” thêm. Nói là đi xây tool mới thì cũng chỉ mới đúng một phần, phần nhiều thực ra là đi làm change management: chuẩn hóa process, onboard người dùng và quan trọng nhất… đi fix bug, dù vô tình hay cố ý, dù cho là hệ quả tích tụ của nhiều năm trước đó. Không cần biết đúng sai, ai đề xuất thay đổi là người đấy chịu trách nhiệm.
Và đối với một người background non-tech như mình, hấp thụ mấy kiến thức này giống như đang dùng “abc” chuyển qua dùng chữ tượng hình vậy. Từ những thứ đơn giản nhất như vận hành một project kiểu Scrum, role trong team ai làm gì, hay cách viết “story” trên Jira… đều là những kĩ năng mình phải fast-track sau 2 ngày đi Agile bootcamp nếu muốn thật sự fill-in role của một Product Owner. Nhưng đó chưa phải thử thách lớn nhất.
“Biết địch biết ta”, muốn thay thế một cái gì thì trước hết phải hiểu bản chất của cái đang bị thay thế. Mà tất nhiên là không dễ gì để thẩm thấu hết một thứ đã được xây trước đó cả chục năm, với rất nhiều thứ thay đổi nhỏ tí ti tưởng không quan trọng mà lại quan trọng không tưởng. Trong 3 tháng đầu, quyển note A4 của mình dần dày đặc các thuật ngữ cả về chuyên môn Sale lẫn technical lẫn internal process của công ty. Mình phải học từ những điều đơn giản nhất như là cách tạo một order trên hệ thống, cách xuất hóa đơn, cho đến soi từng khác biệt tới 0.01$ trong hệ thống.
Dự án tới giờ đã đi vào phase cuối để chính thức go live. Đến lúc này, hơn cả cảm giác phấn khích, mình chỉ muốn thở phào nhẹ nhõm.
Lúc đấy tự dưng trong đầu tự dưng xuất hiện một suy nghĩ, “làm xong rồi thì có con AI nào sẽ thay thế mình luôn không?”
Will I be replace by AI?
Để quote một câu mà mình học được ở bên này, và từ đó đã trở thành cửa miệng, “Yes and no….”.
Có những cái AI hoàn toàn làm được, và làm tốt hơn mình nhiều, nhưng đó lại không phải là cái cốt lõi của công việc mình làm.
Bởi vì thay vì trả lời có hoặc không, hữu ích hơn là khi nhìn nó trên một dải (spectrum) những gì có thể AI hóa (AI-able). Để bóc tách một công việc có thể bị AI thay thế hay không, trực quan nhất là dựa trên framework kiến thức và kĩ năng cần thiết cho vị trí đó, và mức độ AI-able tới đâu.
Những thứ AI có thể thay thế (vùng xanh) và chưa thể thay thế (vùng xám)
Kiến thức thì có thể chỉa ra làm 2 loại: Functional Domain Knowledge (các kiến thức chuyên ngành, dạng như làm Finance thì phải biết mặt mũi 1 cái P&L nhìn nó ra làm sao, các yếu tố nào tác động vào các financial line items…) và Internal Knowledge (hệ thống/process nào đang được sử đụng để tracking promotion, các anh em Sale đang chơi “game” trên đó như thế nào…).
Tương tự với nhóm kĩ năng thì nhìn 1 cách high-level nhất là skillset liên quan tới Technical và People. Cái này nhiều sách vở cũng viết rồi, điều mình muốn nói tới là không phải phạm trù nào thì AI cũng có sức công phá như nhau. Phần ở giữa màu xanh có thể AI hóa được nằm ở nhóm kiến thức cơ bản đã được chuẩn hóa / có documentations đàng hoàng trong nội bộ (hàng hiếm hay không phụ thuộc vào công ty bạn process chuẩn chỉ tới đâu).
Khi quick-check với GPT, nó có thể chỉ step-by-step để phân tích 1 bảng data extract doanh số bán hàng tháng này như thế nào, highlight các trend/outlier cần đào sâu. Và mình thì hay xài Bing Work để search mấy tài liệu sharepoint nội bộ trong vòng 1 nốt nhạc. Giờ con Co-Pilot có thể connect thẳng với source đó luôn - tất cả documents, S&OP process… nhờ AI tóm tắt trong vài bullet-point, thứ mà xưa tốn cả tuần công lực đi mò mẫm.
AI sẽ xử lí khá tốt đối với các nhóm kĩ năng phụ thuộc nhiều vào khả năng tổng hợp và chắt lọc thông tin (“synthesizing”, “brainstorming”, “copywriting”…), cũng như các kĩ năng cứng liên quan tới software và technical đã được phổ cập rộng rãi (một lần nữa nhấn mạnh vào yếu tố “well-documented”). Một ví dụ là mình đã nhờ GPT paraphrase lại một chiếc email từ thế đang combat với một stakeholder khó tính thành professional feedbacks. Absolute technologia!
Giống như một nghiên cứu của HBS đã chỉ ra, có những cái AI thay thế được rất tốt, nhưng có nhiều phần vẫn còn “meh”, dù độ phức tạp của các task đó có thể gần ngang nhau.
Our results demonstrate that AI capabilities cover an expanding, but uneven, set of knowledge work we call a "jagged technological frontier.” Within this growing frontier, AI can complement or even displace human work; outside of the frontier, AI output is inaccurate, less useful, and degrades human performance.
Nói lí thuyết thì khô khan vậy, thực tế thì AI đang chiếm ghế của mình như thế nào?
Yes, and…
Lowkey would save alot of time answering to email - Reddit
Nếu chỉ tính đến những công việc day-to-day của một product owner, AI có thể thay thế đến 80% những gì mình đang làm.
Những ai đã / đang làm product owner sẽ hiểu câu chuyện đau đớn về ngồi update backlog mỗi khi bắt đầu, trong, và sau một kì product sprint. Mỗi một sprint như vậy sẽ gồm tầm chục “story”, bao gồm các tính năng hoặc các to-do, và thường kéo dài từ 2-3 tuần.
Xưa mình vốn dốt văn, ai dè lớn lại phải ngồi viết “story” cho user. Về khoản này thì Co-Pilot là người bạn chí cốt của mình, bởi vì dù không được sponsor bởi Fristi, trí tưởng tượng của GPT bay xa tới độ viết description như thể được user nhập . Nhiều lúc lười, mình tranh thủ nhờ GPT viết luôn cho cả các yêu cầu về sản phẩm (acceptance criteria) và tầm 5-10’ tinh chỉnh paraphase chút chút là bạn có thể hoàn thiện từ hai đến ba “story” với vài bullet-points đủ các ý chính.
Để so sánh thì trước khi dùng GPT, mình mất từ 15-20’ để hoàn thiện một story - và rõ ràng tiếng Anh thì chắc chắn không hay bằng…, nên gần như AI là không thể thiếu trong mỗi lần backlog refinement.
Buổi sáng đẹp trời là ngày không nhận được hơn 30+ email noti từ Jira tag tên bạn
Một khoản nữa AI có thể hoàn thành nhanh và khá tốt là khi phải vẽ mockup cho một process nào đó trên hệ thống. Các tool như eraser.io có thể vẽ nhanh trong 1 nốt nhạc (dù hơi tiếc là chưa export được ra PPT). Và mình đã từng nghe giang hồ đồn thổi, AI giờ hiện đại tới độ có thể vẽ luôn design UI/UX, làm wireframe (+ code), xịn thật!
Nếu vậy anh em ngày cũng chỉ cần làm 3-4h thôi còn đâu để AI tự chạy là ngon lành. Nói đến đây thì chắc bạn hình dung chỉ thiếu điều nhờ con chatbot trả lời email tự động (mà giờ Outlook có sẵn), thì lúc đấy công việc mỗi ngày chỉ cần dự 15’ standup, mỗi tháng xuất hiện 1-2 lần vào sprint planning, sprint review. Ngày làm 4h, cuối tháng vẫn nhận lương ngon lành.
Nhưng đời làm gì có bữa trưa nào miễn phí, người ta cũng không trả mình mấy ngàn $ chỉ để ngồi rung đùi và dùng Co-Pilot cả ngày.
Nếu giờ cho AI làm hết việc của mình, tầm sau khoảng 1 tuần thì mọi thứ sẽ bung bét. Tại sao ư?
Chào mừng tới với corporate world, người theo hương hoa mây mù giăng lối.
What the AI can’t replace (yet)
Cuộc đời đi làm corporate nếu chỉ đi xử lí những vấn đề về chuyên môn thì mọi thứ đã đơn giản hơn 9-10 phần. 20% công việc tốn tới 90% thời gian đi xử lí nằm ở những yếu tố bất định (ambiguous), mà nó lại không nằm chỉ trong chuyên môn.
Trong số những thứ có thể tăng độ khó lên nhiều lần cho 1 product owner, ba challenges lớn nhất, theo mình, mà bất kì ai làm trong 1 big corp nào đều sẽ gặp phải: tình hình business thay đổi, câu chuyện về accountability và stakeholder expectations.
Axis of evils (corporate-version)
The ever-changing business context
Một thứ sai lầm khi mình mới bắt đầu làm role này là coi rằng mọi thứ sẽ không thay đổi. Đáng tiếc là, thế giới không đứng yên một chỗ, chỉ vì bạn coi rằng như vậy.
Câu chuyện focus của công ty sẽ rất khác nhau tùy thời điểm - và kéo theo đó là sự thay đổi budget, scope, resources.
Một ngày có thể mọi thứ đang tốt đẹp và ontrack, chiếc backlog đã vạch sẵn với từng đó feature aligned kể từ lần sprint planning cách đó một tuần. Ngày kế tiếp, business có yêu cầu urgent để review toàn bộ P&L từng khách hàng kênh truyền thống, thứ vốn được plan để làm cách đó 3 tuần, bỗng trở thành ưu tiên hàng đầu. Không phải là một feature dễ implement, có thể tốn vài tuần để developer triển khai.
Dĩ nhiên là khi dành thời gian và nguồn lực làm thứ đó, thì sẽ phải làm giảm ưu tiên của một “story” khác. Cái khó không phải là làm plan ở trong 1 sprint, cái khó là làm sao để make call bạn cần ưu tiên cái gì trước sau, và nhất là mục tiêu ban đầu thay đổi. Điều này cũng đúng khi scope bị co hẹp lại, budget không còn đủ, và bắt buộc phải bỏ đi một vài tính năng nằm trong pipeline.
Nếu đem điều ấy hỏi AI thì nó sẽ cho bạn một câu trả lời chung chung kiểu ba phải, cái nào cũng quan trọng, hoặc cho bạn 1 cái framework nhưng kết luận tựu lại là business phải tự đi mà đánh giá. Càng ép thì nó sẽ càng có xu hướng thuận theo ý ban đầu bạn đã input cho nó. Bản thân OpenAI cũng đã phải thừa nhận và xóa bớt thiên kiến này khỏi GPT-4o trong một update gần đây.
Is ChatGPT only a yes man? - Reddit
Khổ là điều này xảy ra gần như thường xuyên trong suốt quá trình phát triển. Chưa kể tới việc càng develop tool hoàn thiện, người ta mới nghĩ ra nhiều thứ mong muốn hơn (mình sẽ đề cập nhiều hơn ở ý 3). Để đưa ra quyết định, và thuyết phục tất cả mọi người thuận theo ý đó, không phải là một công việc dễ dàng mà ngồi gõ prompt là có thể trả lời được.
Một cái khó thứ 2, AI không toàn năng để hiểu mọi ngóc ngách business như bạn nghĩ đâu. Ít nhất là trong công ty mình đang làm, luôn tồn tại 1 khoảng gap giữa những gì process đáng lẽ phải là và thực tế đang xảy ra như thế nào.
Một ví dụ đơn giản như việc quản lí một khoản trade promo của khách hàng luôn được ghi nhận cục tiền fixed cost, nhưng thực tế là variable - bởi vì nguyên lí của nó được gắn với từng chương trình promo. Chỉ là vì nó luôn giữ mức như vậy, nên bằng một cách nào đó được assume là nó sẽ không đổi, và những người được handover lại cũng nghiễm nhiên coi đó là thật.
Hay nghiêm trọng hơn, có những khoản markup của khách hàng cho cửa hàng được gộp vào modelling gross profit của công ty, trong khi đó không phải là giá mà công ty bán ra. Lí do, trước đây Key Account quản lí sử dụng một template modelling của khách hàng khác anh từng quản lí để áp luôn cho khách hàng này, và pricing model của hai nhóm là hoàn toàn khác nhau. Hệ quả là profit ghi nhận trong file modelling sẽ bị thổi phồng so với thực tế. Rồi kết quả của modelling đó lại được sử dụng để đưa ra các quyết định về giá khuyến mại, khiến cái sai càng thêm sai.
Đây là hệ quả của việc khi công ty không có 1 standard system, và mỗi người có 1 chiếc excel spreadsheet chạy vài trăm dòng, nhưng như một chiếc “black box” không ai hiểu rõ, do người build nó đã rời công ty từ cách đây mấy năm. Kể cả bạn có “feed” cho AI nhưng thông tin này, thực tế sẽ chỉ làm nó rối hơn.
Nhiều lúc nghĩ nếu giờ mình nghỉ khỏi công ty, chắc cũng phải kha khá lâu sau người thay thế mình mới thẩm thấu được hết những thứ tiểu tiết phức tạp ấy. Vì trong các noise gây nhiễu, kĩ năng quan trọng là phải biết chắt lọc ra được thông tin đúng, mà cái này thì cần lấm tay bùn mới biết được.
Còn với AI thì đơn giản: “garbage in - garbage out”. Đầu vào sai bét thì đầu ra cũng rứa.
Và khi biết được thông tin đúng thì vẫn chưa phải là cái kết của câu chuyện. Để tạo thay đổi, bạn có sẵn sàng đứng ra chịu trách nhiệm cho quyết định đó hay không?
Taking Accountability
Chú Ben trước khi ra đi đã nói với Peter Parker rằng: “With great power come great responsibility”. Rõ ràng là khi mọi thứ tốt đẹp thì sẽ chẳng ai đoái hoài tới những chuyện đang xảy ra, miễn là mọi thứ vẫn hoạt động trơn tru. Nhưng project bắt đầu không như mong muốn, thì người ta sẽ gõ đầu thằng lead đầu tiên.
Spider-man (2002)
Một trong những thử thách lớn ở dự án này mình làm đó là đi khớp số với các reports khác trong nội bộ công ty. Chuyện đi audit sổ sách phải đi tới từng dòng details mệt mỏi là một phần, nhưng phần mệt hơn là phải làm điều đó dưới pressure phải deliver con số đúng - một con số thần kì mà bản thân trong business không ai biết rõ, kể cả finance.
Lí do: các hệ thống tracking trước đây đều sử dụng một (vài) các assumption để allocate lại các khoản chi phí, hoặc doanh thu, đơn giản vì nguồn data trước đó hoặc chưa có, hoặc bị phân mảnh. Thứ duy nhất có thể convince đâu là số đúng? Dựa vào logic, toán, và rất nhiều round giải thích, dùng tới cả ý kiến chuyên gia (SMEs) để thuyết phục người dùng.
Và tất nhiên là sẽ phải có người đứng ra chịu trách nhiệm cho tất cả những việc đó.
Một phép thử cơ bản là: có nên tin vào đứa đang đề xuất hay không.
Nếu đặt bản thân vào vị trí một Sale Director, trước khi đưa quyết định có khả năng tiêu tốn của business vài trăm nghìn $$$, bạn có đủ tự tin rằng AI sẽ không nói láo?
Và lúc mọi thứ sai (có thể vì nhiều lí do), có quay lại bắt AI chịu trách nghiệm được không?
Mình nghĩ là không.
Có thể ở một vài công ty khác có sự buy-in vào AI lớn hơn thì đây sẽ không phải vấn đề, nhưng công ty mình thì không. Và có một vài lí do khác mà mọi người tin mình nhiều hơn một con bot.
Bề nổi, mình có track-record deliver từ trước đó rồi, nên sếp tin mình hơn.
Bề chìm ít đẹp đẽ hơn, nguyên một tuần mình thức tới đêm đi validate từng con số, chase finance từng công thức tính toán đang được sử dụng đến cả các assumptions, catchup với từng Key Account Manager để hiểu bản chất của khoản cost được ghi nhận từ phía khách hàng là gì. Sau quá trình như vậy thì đến giờ mình tự tin nếu có ai challenge gì về cái P&L đó, mình có thể giải thích được bản chất nó là gì, và tại sao công thức tính toán nó lại như vậy.
Trong dự án, head of commercial business control đã từng email lại mình và nói rằng: “Anh tự tin số report trên TPM là số gần sát thật nhất trong tất cả các báo cáo hiện có. Có thể là chúng ta đang từ chối nhìn vào thực tế là nó phải thấp như vậy.”
Lúc ấy, mình biết mình đã làm đúng công việc của mình.
Stakeholder Expectations
Không ai là làm việc một mình, cho dù bạn có giỏi tới đâu, nên trong lúc làm dự án chắc chắn là sẽ có những sự va chạm.
Va chạm số 1 là về những kì vọng khác nhau về dự án.
Nhẹ thì: “Tại sao ý kiến này của chị được đề xuất nhưng không được ưu tiên?”
Nặng đô hơn thì: “Anh từng có kinh nghiệm về cái này rồi, tool nó làm abc mà đáng lẽ ra nó phải làm được xyz cơ”
Mệt hơn nữa là khi các request đến từ stakeholder ở tít trên cao, một dạng “offer you can’t refuse”, nhưng mình vẫn phải tìm cách từ chối anyway. Vì cái gì cũng cần có điểm dừng, nếu không thì cái danh sách backlog sẽ không bao giờ thấy kết thúc.
Một thứ mà AI không có được, đó là real human relationship, vì đến cuối ngày business vẫn là giữa người với người. Mình may mắn có một người sếp đủ tin tưởng, và nếu mình approach chị với đầy đủ lí lẽ và rationale, chị sẽ giúp mình push back lại những yêu cầu phi lí từ cấp trên.
Từ hồi làm role này, mình cũng học được cách lắng nghe nhiều hơn. Bởi vì khi lắng nghe, mình có thể hỏi những câu hỏi giúp user tự đánh giá được thứ họ thực sự cần là gì. Nhiều khi người ta nói vấn đề là vậy, mà thực sự là không phải vậy.
Đã có lúc team suýt dành vài sprint để phát triển một tính năng full year planning. Nhưng sau khi clarify thì Key Account team mới bày tỏ rằng không cần chức năng đó. Họ chỉ cần các enhancement để có thể làm bottom-up planning một cách dễ dàng hơn.
Và có một thời gian dài ban đầu, SMEs tư vấn cho project là Key Account Manager, trong khi người thực sự dùng tool lại là Key Acc. Executive - người làm data entry day-to-day. Sau vài buổi ngồi nán lại trễ office cùng họ, mình mới được nghe kể khổ, về những limitations của tools mà trước đây chưa từng được nghe. Đó mới là những key insights về operation thật sự cần giải quyết thì mới tới được mass adoption.
Nói giống như gửi tiền vào ngân hàng, phải có thời gian và sự đầu tư thì mới có thể rút “credit” này ra xài được.
Va chạm số 2 là quản lí những cảm xúc của con người.
Đến một dạo, ai có vấn đề gì về sản phẩm là sẽ tự động tới tai mình.
Vì mang tiếng là công ty lớn, nhưng trong team thì product owner được ưu ái kiêm luôn role QC/tester/customer support nội bộ, do không làm thì cũng chẳng còn ai khác làm.
Để empathy với các user thì đúng là công đoạn develop product cũng phát sinh kha khá bug. Chắc đếm số bug ticket từ đầu project nhận được tới giờ, ít nhiều chắc cũng phải hơn 100+. Hầu hết số đó đã được close, nhưng lúc nào cũng sẽ có xuất hiện, vì mỗi tính năng mới được phát triển là một cục bug tiềm tàng - do không test kĩ module, do test kĩ module này nhưng lại không tính đến module nọ bị ảnh hưởng….
Và bên cạnh đó, có nhiều complaint chỉ vì họ đã từng có những thứ mà họ từng làm được trên Excel hay những hệ thống khác, vốn là nice-to-have ở khía cạnh sản phẩm nhưng là must-have trong mắt họ.
Chúng sẽ luôn bị đem lên như vật tế thần (scapegoat) trong mỗi cuộc họp khi product có gì đó không như ý user muốn. Và đó là cái khó, vì không phải feedback nào cũng valid. Đôi khi chỉ là họ xả, just because they had a bad day. Mà những cái này thì đòi hỏi EQ để có thể tách bạch được.
Sau gần 1 năm, product này thì nó cũng giống như đứa con tinh thần của mình vậy. Bị người ta chê chửi nó thiếu này thiếu kia hoài thì cũng buồn chứ.
Nhưng một lần nữa, đứng ở phương diện khách quan, đội cái nón product owner, mình cần phải chấp nhận rằng thực tế đang ở đâu - và say “no” với những gì không phải là ưu tiên. Lúc này thì việc có relationship tốt sẽ giúp một lần nữa, dù không phải lúc nào cũng work. Các vấn đề tưởng như rất nghiêm trọng đều có thể giải quyết bằng một buổi quick catchup 1-1 trước các meeting lớn để lắng nghe concern từ phía họ. Keyword: “được lắng nghe”.
Bởi vì những vấn đề khó nhất luôn là vấn đề về con người. “Business problems are always people problem.”
Back to the true meaning of “Problem Solving”
Đọc tới được đây, chắc hẳn bạn là một người nghiêm túc tìm hiểu về chủ đề này.
Và mình tin rằng bạn là một trong số ít những người nhận ra lợi thế độc nhất của chính bản thân mà AI không có được.
Mình tin con người có khả năng “problem solving” tốt hơn AI.
Hiểu cơ bản, đây là kĩ năng giải quyết vấn đề - cái này AI làm được một phần.
Hiểu rộng ra, đây là khả năng để biến từ một ý tưởng, một cái plan, một project từ trên giấy thành hiện thực. Cái này mình nghĩ AI sẽ struggle khá nhiều.
Khi đặt tất cả các yếu tố kể trên trong một trang giấy, những thứ tưởng có thể dễ dàng AI hóa giờ đây đã không còn như vậy nữa.
The lines between what’s AI-able get murkier as we giving more ambiguity
Ngẫm lại, có rất nhiều bài học từ khi mình onboard role này. Những thứ phải đánh đổi, những chiếc drama nội bộ, đến từ câu chuyện navigating corporate cho project có thể đi tiếp, đều là những bài học về making tough decisions, và managing tough stakeholders. Tất cả đều là hành trình trải qua những unknown unknowns, và một môi trường mờ ảo những ambiguity.
Con đường để xây dựng một thứ mới không dễ, và càng khó hơn khi phải thay đổi cách làm việc của một tổ chức đã hằn sâu những process, system đã được sử dụng qua hàng chục năm. Khi tồn tại nhóm người ngại thay đổi, khả năng leadership lúc này là giúp mở rộng tầm nhìn của họ về một mục tiêu chung. Như Yuval Noah Harrari từng viết trong “Homo Sapiens”, loài người là loài động vật độc nhất có thể kể những câu chuyện, và hợp nhất lại từ niềm tin chung vào một sứ mệnh nào đó.
Đây là yếu tố khác biệt tách biệt chúng ta khỏi AI, khả năng sở hữu “tầm nhìn” để có thể đoàn kết tất cả mọi người vì một lợi ích lớn hơn tất cả.
Một lợi thế cạnh tranh độc nhất (point-of-difference) mà ta phải nắm thật chắc để tồn tại qua làn sóng AI này.
In the end, we will prevail.
On top of the Pinnacles summit, 2025
Surviving the AI replacement trend
Một inspiration khá lớn cho mình viết bài này chính là nghiên cứu của Havard (HBS) về câu chuyện khả năng của AI và thay thế các kĩ năng vốn được coi là high-skilled của con người (trong bài dùng management consulting làm đối tượng nghiên cứu).
Quay trở về căn bản, nếu hình dung khả năng của AI giống một cái tiền tuyến càng ngày càng được mở rộng ra, thì thời thế đang trông như thế này:
Một điều đầu tiên là giống với kết luận từ trên, tiền tuyến này không có bằng phẳng - tùy vào tính chất công việc mà các tác động khác nhau. Và kết quả của nghiên cứu chỉ ra, có 2 nhóm khá rõ ràng: “Inside” và “Outside”.
Nhóm “Inside” được định nghĩa là nhóm kĩ năng thiên về sáng tạo, đề xuất và phát triển ý tưởng.
The inside-the-frontier experiment focused on creative product innovation and development.
Ở phạm trù này thì nghiên cứu chỉ ra rằng sử dụng tích hợp AI có thể tăng năng suất tới gần 30% và tăng chất lượng đầu ra hơn 40% của các đối tượng nằm trong bottom-half performers.
Nhóm “Outside” được định nghĩa là nhóm kĩ năng liên quan tới việc đưa ra quyết định từ nhiều nguồn data khác nhau, và có kết luận đối lập nhau.
[…] We designed the task outside the frontier using as a starting point the type of business cases that BCG uses for its highly competitive job interviews. […]
To be able to solve the task correctly, participants would have to look at the quantitative data using subtle but clear insights from the interviews. […] When considered in totality, this information led to a contrasting conclusion to what would have been provided by AI when prompted with the exercise instructions, the given data, and the accompanying interviews.
AI trong trường hợp này vẫn giúp các consultant hoàn thành đánh giá nhanh hơn, và đưa kết luận được đánh giá là chất lượng hơn - tuy nhiên tỉ lệ kết luận đúng của nhóm dùng AI trung bình thấp hơn 19% so với nhóm không dùng AI.
Một điều thú vị ở research này? - Dùng AI gần như chắc chắn sẽ giúp tăng năng suất dù cho có là nhóm kĩ năng nào, nhưng tính đúng sai phụ thuộc rất nhiều vào tính chất của việc được giao cho AI và kĩ năng của người sử dụng AI.
Với những consultant vốn đã được đánh giá trong upper half của nhóm kĩ năng được đánh giá, mức tăng được ghi nhận thấp hơn nhiều so với nhóm trong bottom half về cả độ chính xác và chất lượng.
Dùng AI có thể cho bạn cảm giác là đáp án đưa ra là chất lượng và đầy đủ hơn - nhưng nếu bạn không có hiểu để verify là nó đúng hay sai, thì sẽ dễ bị rơi vào cái bẫy đưa ra kết luận hay nhưng sai bét.
Có thể thấy khi công nghệ thay đổi, thì luật chơi khác, cách chơi cũng phải khác.
Vậy những top performer đang xài strategy gì để thành công trong kỉ nguyên quá độ AI này?
(To be continued)
Note tác giả: tính viết tất cả trong cùng 1 phần nhưng viết xong mới nhận ra bài đã dài quá nên tạm dừng ở đây. Comment nếu bạn thấy bài có ích và muốn mình viết tiếp phần 2 nhé, Cheers!
Further readings (on AI)
