Khoe khoang vụ scale team lên 50 mạng trong 6 tháng. Oai đấy. Nhưng bê cái P&L đặt lên bàn cho nhà đầu tư xem, thứ đập vào mắt họ chỉ là cái máy đốt tiền.

Kịch bản quen thuộc cực kỳ. Gọi vốn Series A xong, tiền về. Phản xạ đầu tiên của đa phần founder là xách giỏ đi lùa người. Bế nguyên cụm 15 dev sang. Đắp thêm 3 PO, 2 QA cho đủ mâm. Giăng cái bảng “go fast and break things” to đùng. Quyết đập đi xây lại hệ thống đang lết bết từ thời seed.

Nhìn ánh mắt rực sáng của bạn, mình chỉ muốn hỏi đúng một câu: “Tháng trước team 5 người của em ship 3 tính năng. Tháng này 20 người, em tính ship bao nhiêu?”

Dự đoán. Thực tế thì sau một tháng onboarding sấp mặt, team 20 người đó ship được đúng 1 tính năng. Cả tháng trôi vào họp sync requirement, vào việc QA dò lại đống lỗi cũ, vào chuyện dev cũ conflict code với dev mới. Đến tuần thứ ba thì Slack bắt đầu có mùi thuốc súng.

Cái bẫy này mình gặp đi gặp lại, ở startup lẫn ở công ty đã vài trăm người: Bệnh cuồng headcount.

Khi sự đông đúc là biểu tượng của quyền lực

Ở ta, thước đo ngầm cho một người quản lý vẫn là số lính dưới trướng. Quản 5 người thì là manager. Quản 50 người thì đã là Giám đốc. Có 200 lính thì thành V.I.P, đi đâu cũng có người xách cặp. Và cái tôi thì được vỗ về mỗi ngày: văn phòng đông nghịt, tiếng gõ phím lạch cạch, All-hands kín cả hội trường.

Xưa, mình cũng từng rơi vào cái bẫy cảm xúc này. Nhìn sơ đồ tổ chức phòng ban mình to lên mỗi quý, cảm giác quyền lực nó dễ gây nghiện lắm. Giờ chỉ muốn rất ít, càng ít report line càng thích.

Thời trước 2023, điều này có thể hiểu được. Headcount là rào cản gia nhập. Bạn muốn code nhanh hơn? Thuê thêm code. Bạn muốn test kỹ hơn? Thuê thêm QA. Sức mạnh của công ty công nghệ tỷ lệ thuận với số lượng kỹ sư họ có thể gom được vào một tòa nhà.

Nhưng 2026 rồi. AI đã nằm trong hầu hết các khâu làm sản phẩm, và bộ máy phình to bây giờ không nói lên sức mạnh. Nó nói lên là bạn chậm. Và nó ăn tiền của bạn đều đặn mỗi tháng, kể cả những tháng chẳng ship được gì.

The Theory: Lầm tưởng về AI như một chiếc bàn phím chỉ cần gõ là tốc độ tăng siêu tốc.

Khi nói về AI trong Product Development, đa số các C-level và Tech Lead ngoài kia đều hiểu sai bản chất. Họ coi Github Copilot, Cursor hay các hệ thống AI Orchestrator như một cái bàn phím gõ nhanh hơn. Tư duy của họ rất tuyến tính: Dev ngày xưa gõ 100 dòng code một giờ, giờ có AI gõ được 500 dòng.

Ngon ơ, nhiều Founder nghĩ. “Vậy thì giữ nguyên team 20 người, mua thêm cho mỗi ông một cái license AI 20 đô một tháng, năng suất sẽ tăng gấp 5 lần!”

Rồi ba tháng sau nhìn lại. Năng suất không tăng gấp 5. Có team còn tụt. Code merge vào thì rác, technical debt chất lên, mà anh em thì mệt hơn hẳn hồi chưa có AI.

Lý do đơn giản: bottleneck của làm phần mềm chưa bao giờ là tốc độ gõ. Nó là tốc độ hiểu nhau. Hiểu bài toán kinh doanh, rồi chốt được với nhau một phương án và không lật lại vào tuần sau. AI gõ hộ bạn thật, nhưng nó không làm 20 con người kia hiểu ý nhau nhanh hơn.

The Breaking Point: Chi phí chìm của Agile Theater

Hãy quay lại bài toán cơ bản của kỹ nghệ phần mềm: Định luật Brooks (trong cuốn The Mythical Man-Month năm 1975, vẫn đúng sau 50 năm). Cứ thêm một người vào một dự án đang chậm tiến độ, dự án đó càng chậm hơn. Mình không có số liệu ngành để dẫn ở đây, chỉ có số của chính mình: mấy squad quá 8 người mà mình từng quản, cycle time từ lúc commit đến lúc lên production luôn dài hơn hẳn squad 3-5 người, dù làm cùng một loại việc. Nhưng đó mới là phần nhìn thấy được. Soi vào P&L thì còn sợ hơn.

Khi bạn có 20 người trong team Product & Tech, bạn không chỉ trả lương cho 20 người. Bạn đang phải cõng một đống Operational Expenditure (OpEx) tàng hình:

Ma trận giao tiếp: 20 người đồng nghĩa với 190 đường dây giao tiếp chéo nhau công thức N*(N-1)/2. Nếu không quản trị khéo, 190 đường dây này sẽ biến thành 190 kênh cãi lộn mỗi ngày.

Thuế hội họp: Buổi planning, buổi grooming, mỗi buổi ba tiếng, phần lớn thời gian dành cho việc cãi xem nút kia màu xanh hay màu đỏ.

Thuế chờ đợi: Mười giờ đêm Slack vẫn sáng đèn: “Anh ơi API này bao giờ xong?”, “Em ơi spec chỗ này chưa rõ, confirm giúp em”. Dev chờ QA, QA chờ PO duyệt, PO chờ sếp trả lời tin nhắn. Chuỗi đó đứt ở mắt xích nào cũng được, và gần như ngày nào cũng đứt.

Layer quản lý trung gian: Scrum Master, Agile Coach, Delivery Manager... những người mà việc chính là đảm bảo 20 con người kia không giẫm chân lên nhau.

Nuôi nguyên một cái rạp hát Agile để phục vụ cho sự đông đúc đó, rồi tự nhủ là team mình làm việc có quy trình.

Trong lúc đó, đâu đó có một team 3 người với vài con AI đang lặng lẽ ăn dần thị trường của bạn.

Họ thắng vì gần như không có độ trễ giao tiếp. Hai Senior Engineer và một PM cứng nghề, ngồi chung phòng hoặc chung một kênh Discord. Cursor lo phần boilerplate, AI agent viết unit test và review pull request rồi đẩy thẳng lên CI/CD. Không có PRD 50 trang, vì người viết spec cũng là người code, và người đó hiểu business đến tận cùng. Nói vậy không có nghĩa là họ nhàn. Họ vẫn cày, chỉ là cày vào đúng việc chứ không cày vào việc giải thích cho nhau nghe.

Phản biện tý: Nhưng AI hay bị ngáo, sao làm được hệ thống lớn?

Đến đây, chắc chắn sẽ có những bác Tech Lead nhảy dựng lên: “Anh xạo! Em thử dùng mấy con AI rồi, toàn code rác, bịa đặt hallucination từ lưa. Đưa nó làm core banking hay hệ thống thanh toán có mà sập server à? Vẫn phải cần QA chạy tay, cần team 20 người review chéo nhau thôi!”

Mình từng nghĩ y hệt, khoảng hai năm trước. Cái sai không nằm ở chỗ đánh giá AI thấp, mà ở chỗ đang dùng nó như một thực tập sinh: giao việc xong rồi bỏ đó.

Đúng, AI sẽ sinh ra code rác nếu bạn quăng cho nó một cái prompt hời hợt kiểu “Làm cho tôi cái app giống Tinder”. Nhưng trong tay một Senior Engineer người hiểu rõ architecture, biết cách chia nhỏ bài toán decomposition, biết viết test-driven development (TDD) khắt khe AI trở thành một siêu vũ khí.

Chưa ai bảo AI tự dựng được một hệ thống lớn. Cái đang xảy ra là AI giúp một con người xuất chúng làm được khối lượng công việc của 10 người. Mười bạn junior ráp màn hình thì giờ không cần nữa. Cần một Senior chắc kiến trúc, ngồi đọc lại đống code AI vừa ráp trong ba phút và vặn ngược logic khi thấy sai.

Sự phức tạp của hệ thống lớn không nằm ở số dòng code, nó nằm ở cấu trúc. Và cấu trúc thì cần một cái đầu có sạn của con người, chứ không cần 20 đôi bàn tay gõ phím.

The Patch: Framework Cắt giảm OpEx

Vậy gỡ bằng cách nào. Dưới đây là mấy thứ mình đang làm và thấy có tác dụng. Không phải framework gì to tát, và cũng không chắc hợp với mọi công ty.

Hãy bấm theo dõi để đọc miễn phí nhé.

Want to see the rest of this awesome Post ?
Just hit that subscribe button for free to unlock the full post!

Subscribe now

T.D,
T9.2026

P/s : 3 Người / 20 Người : là khái niệm 3 nhóm việc với chuyên môn cao, ko phải đại diện số lượng mà nhân sự thay thế 20 người. 20 Người ý việc 1 việc cần nhiều người làm dù có thể làm bởi 1 nhóm nhỏ hơn.

Anh Quang thì dân trong ngành của ảnh quá rành nhưng không nhiều anh em làm Tech/Product biết đến.

Profile ảnh đúng kiểu khủng long từ thế giới bán lẻ và dược phẩm vươn ra global: đi lên từ quản lý nhãn hàng ở Unilever, P&G ở VN rồi 10 năm ở Mỹ, cho đến Senior Director của Pfizer khu vực EMEA (phụ trách tận 43 thị trường, EMEA = Europe Middle East and Africa), rồi quay về làm CEO cho mảng Digital Platform của Masan Group, và hiện tại tư vấn cho nhiều doanh nghiệp bán lẻ và tận hưởng cuộc sống Việt Nam.

Góc nhìn của một tay chơi lão lõi đi từ FMCG (hàng tiêu dùng nhanh) rồi nhảy sang làm Tech / Tư vấn và cả kinh doanh nên nó cực kỳ khác biệt. Không có chuyện vẽ vời tech specs hay khoe architecture ở đây, mọi thứ đều bị lột trần dưới góc độ một chữ duy nhất: Insight.

Cái bẫy “Logic của dân Tech” và đi tìm Insight thật

Dân làm product và tech tụi mình hay bị một cái bệnh rất nặng: quá logical. Mình từng chứng kiến hồi làm Zalo hay đợt cắm mặt build nền tảng mới ở VinID rồi Onemount, anh em Dev, PM cứ tự giam mình trong phòng máy lạnh, gõ bàn phím êm ru rồi kháo nhau: “Chỗ này mình làm flow mượt thế này, thời gian load app nhanh, kiểu gì user chả sướng user cứ dùng thôi sợ gì và rất tự tin bản thân”.

Nhưng sự thật nó phũ phàng lắm: khách hàng nhiều khi không cư xử hay suy nghĩ như cách chúng ta tưởng tượng. Nếu bạn từng tự hỏi tại sao startup hay tẻo sớm, thì report của CB Insights chỉ đích danh: 42% startup chết ngắc là vì “No market need” chẳng ai thèm xài. Con số này dẫn đầu mọi nguyên nhân, bỏ xa hết tiền (29%) hay sai team (23%). Và cái đáng sợ nhất: nhiều founder cứ nghĩ mình chết vì hết tiền, nhưng thực ra hết tiền chỉ là triệu chứng, gốc rễ vẫn là không ai cần cái bạn đang build. Bệnh này đến từ việc tự áp đặt cái logic của mình lên khách hàng.

Và đây là lúc góc nhìn của anh Quang làm mình khựng lại. Anh chốt hạ một định nghĩa sắc lẹm về Insight:

“Insight không phải là thứ bạn có thể tự ngồi rồi ‘nặn’ hay suy luận ra được. Insight thực chất là việc giải quyết một Tension - một sự giằng xé nội tâm chưa có lối thoát của người dùng.”

Nghe thì đơn giản nhưng mấy ai làm được? Làm Research không phải là đi làm survey để chứng minh mình đúng. Nếu bạn chạy cái survey xong, nhìn cái chart và tặc lưỡi: “Ừ, đúng như mình đoán”, thì dẹp mẹ cho rảnh nợ. Quan trọng của research là phải tìm ra được cái KHÔNG obvious, cái mà nếu không tóm cổ user ra hỏi thì bạn sẽ té ngửa vì không bao giờ nghĩ tới.

Dân MKT chuyên nghiệp hay chơi cái bài Truth – Tension – Motivation. Hiểu nôm na là bạn phải dòm ra được cái sự thật tụi nó đang làm (Truth), tìm ra cái nỗi bứt rứt giằng xé trong lòng tụi nó (Tension), rồi từ đó mới khều đúng cái động lực sâu xa (Motivation) để tụi nó xuống tiền.

Ví dụ kinh điển nhất của a Quang ? Nhớ cái vụ sữa tắm Dove hồi xưa? Tụi anh đi hỏi mấy ngàn chị em thì phát hiện chả ai dám tự nhận mình đẹp. Cái kẹt (tension) ở đây đâu phải là họ thiếu kem bôi cho trắng, mà là mấy bả đang tự ti thấy bà nội vì bị mấy cái chuẩn mực người mẫu chân dài dội vô mặt mỗi ngày. Dove nó móc đúng cái cục tức đó ra, đẻ ra cái campaign Real Beauty. Xong rồi sao? Bán đắt như tôm tươi, doanh thu nhân đôi luôn. Đâu phải nhờ sữa tắm nó thơm hơn, mà nhờ nó khều trúng cái chỗ ngứa mà chưa brand nào dám gãi.

Unique Selling Point vs. Reason To Believe:
Sự thật khoảng cách từ miệng đến tim

Bất cứ startup nào khi pitch cũng hô hào về điểm mạnh độc nhất của mình thường gọi là USP. Nhưng USP suy cho cùng chỉ là cái mà mình nghĩ hoặc mình nói. Câu hỏi tử huyệt là: Làm sao để user thực sự buy-in và cảm nhận được cái đó?

Đó chính là Reason to Believe, gọi tắt là RTB một concept cốt lõi trong xây dựng product mà dân Tech hay ngó lơ.

Có một số thứ thì USP và RTB là một. Ví dụ bạn định vị “giá siêu rẻ”, thì cái giá dán trên app chính là cái để user tin. Chả cần nói nhiều.

Nhưng đa số những thứ còn lại, bạn không thể ép user tự động tin. Ví dụ bạn rao giảng: “App tôi nhanh lắm, privacy lắm, bảo mật dữ dằn lắm”. Đừng hòng tụi nó tin nếu bạn không tạo ra được RTB thông qua design, trải nghiệm hoặc một lời bảo chứng thực sự. Phải nhìn từ góc độ người dùng và hiểu văn hóa của market mình nhắm vào.

Đem chuông đi đánh xứ người mà thiếu RTB thì khác nào mang kiếm gỗ đi chém xe tăng.

Lấy ví dụ cụ thể về thị hiếu khách hàng EU từ chính kinh nghiệm đánh thị trường khu vực EMEA (Châu Âu, Trung Đông, Phi) của anh Quang. Pfizer hoạt động ở khoảng 200 quốc gia, nhưng riêng khu vực EMEA mà anh Quang phụ trách đã là 43 thị trường mỗi nơi một kiểu chơi. Ai cũng biết EU nổi tiếng với luật GDPR khắt khe, nhưng theo anh Quang, cách mỗi quốc gia “buy-in” vào cái RTB đó lại cực kỳ khác nhau:

Cả EU đều đánh giá Privacy cực kỳ cao. Đó là luật chơi chung. Nhưng khi bóc tách ra: Đức, UK, hay Hà Lan lại chuộng sự nhanh gọn, efficient, họ cần speed và performance để tin vào chất lượng. Ngược lại, Pháp hay Ý thì có xu hướng chậm và bảo thủ hơn. Họ cần văn hay chữ tốt, thiết kế phải hoa hòe hoa sói, tinh tế. Ở mấy thị trường này, ứng dụng của bạn có chạy nhanh êm ru thì cũng chưa chắc họ đã thèm dùng.”

Mà không phải anh Quang nói suông đâu, data thị trường cũng chứng minh điều này rõ ràng đến mức không cãi nổi mình có tự tìm hiểu thêm sau buổi chia sẽ của ảnh không phải không tin ảnh nói, mà vì cái gì chưa biết hay tò mò kaka. Bữa mình có lướt cái báo cáo tụi Kantar làm cho IAB Europe. Đi hỏi hơn vạn người bên đó mới lòi ra chuyện vầy: tính ra mỗi tháng một khứa bên EU xài ké mớ dịch vụ free (search, đọc báo...) cũng đáng giá cả hai trăm Euro. Thành ra phân nửa trong số đó gật đầu cái rụp, chịu đưa data cá nhân để được xài chùa tiếp. Nhưng ngặt cái mỗi nước mỗi nết. Mấy ông Đức với Hà Lan thì thực dụng, app cứ chạy vèo vèo, minh bạch là xài.

Còn Pháp và Ý? 73% consumer EU sẵn sàng trả thêm tiền cho sản phẩm được thiết kế đẹp hơn, và ở hai thị trường này, con số đó còn đậm đặc hơn. Bạn bán cái app chạy nhanh như điện cho dân Pháp mà giao diện trông như phần mềm kế toán thì coi như vứt.

Đó chính là sức mạnh của RTB: Khi bạn hiểu insight cốt lõi của từng local market, bạn mới biết nên dùng “Speed” hay dùng “Design” làm vũ khí để chốt đơn.

Cú bẻ lái: Go-To-Market Global

Nói thêm một chút về vụ Go-To-Market Global ở đây: Nếu bạn đã xác định làm global và đang trong giai đoạn test, thì việc launch ở Việt Nam rồi bê qua một nước Đông Nam Á có tính chất sêm sêm nhau thật ra không mang lại nhiều giá trị học hỏi. Thà ném product vào hai quốc gia có tính chất hoàn toàn trái ngược nhau để vỡ mộng sớm, bạn sẽ rút ra được bài học đẫm máu nhưng xứng đáng hơn nhiều.

Mình từng có viết nhanh 2 bài GTM ở đây. Hi vọng thêm 1 góc nhìn cho bạn về GTM.

Segmentation: Không phải là rập khuôn Nam/Nữ, 18-35 tuổi

Nhắc tới phân khúc khách hàng (Segmentation), dân Tech hay lôi đống data trong dashboard ra khè nhau: “Tập khách hàng của em là nữ, dân văn phòng, 18-35 tuổi, thu nhập khá”.

Nghe quen không? Đối thủ của bạn cũng đang vẽ y chang cái tệp đó. Nếu tất cả đều nhắm chung tới một standard segment như độ tuổi, giới tính, thu nhập thì lấy đâu ra đất mà cạnh tranh? Cuối cùng cũng chỉ có một thằng sống sót bằng cách đốt tiền quảng cáo sấp mặt.

Mà data cũng chỉ rõ luôn: các nghiên cứu marketing gần đây cho thấy behavioral segmentation Data nó vỗ mặt luôn: xài behavioral segmentation thì tỉ lệ chốt đơn gấp đôi, gấp ba, mà tiền chạy Ads kéo user về (CPA) rẻ đi phân nửa. Khách quay lại mua hàng cũng tăng hơn ba chục phần trăm. Demographic cho bạn biết ai đang xài, nhưng behavioral mới cho bạn biết họ đang định làm gì. Cái thứ hai mới là thứ kiếm ra tiền.

Chia sẻ về nghệ thuật phân khúc, anh Quang đập tan cái tư duy chia rổ data máy móc đó như sau:

Hãy bấm theo dõi để đọc đầy đủ
về nội dung còn lại miễn phí nhé.

Want to see the rest of this awesome Post ?
Just hit that subscribe button for free to unlock the full post right now!

Subscribe now

P/s : Seri Bài viết của the-founders-lens là bài viết dạng tổng hợp được trích dẫn từ các chia sẽ cá nhân trong phạm vi buổi chia sẽ cho nội bộ team mình và đã được xác nhận chia sẽ lên Blog. Các trích dẫn view của người nêu tên chia sẽ trong bài viết một phần thì cần/nên có xác nhận để tránh các góc nhìn sai lệch. Bài viết sử dụng cho mục tiêu tạo ra góc nhìn thực tế cho cộng đồng Product Việt Nam.

Công ty tìm PM giỏi Data, tư duy chiến lược như CEO, biết phân tích A/B Testing mượt mà, và phải chịu được áp lực cao ...mức lương 25-30M

Chuyện là mấy tháng trước, có ông anh Founder quen ném qua cái JD tuyển Senior PM nhờ kiếm người hộ.

Mình lướt cái JD mà mệt ngang. Khúc đầu ổng ghi công ty startup mười mấy nhân sự, mà khúc dưới yêu cầu đọc vô tưởng đang tuyển CEO cho thung lũng Silicon. Nào là “tầm nhìn chiến lược”, “data-driven”, rồi “dẫn dắt cross-functional team”.

Mình mới nhắn lại: Ủa anh, bên anh xài Mixpanel rớt data lên rớt xuống mà đòi ứng viên vô chạy A/B testing kiểu gì? Rồi lỡ nó vô nó đòi đập bỏ cái tính năng anh tâm đắc nhất thì anh có để yên cho nó làm không?

Ổng rep vầy nè: “Thì... data rác thiệt. Còn tính năng anh chốt hết rồi, tuyển PM vô chủ yếu để gõ spec cho Dev nó code mượt thôi em.”

Nghe chán không? Mà nói trắng ra đây là cú lừa kinh điển của giới tech nhà mình bao năm nay.

Mấy nay cái hội chứng ngáo JD nó lây lan quá. HR với sếp rảnh rảnh toàn lên mạng lượm mấy cái văn mẫu JD của FAANG về, xóa tên người ta đi rồi đắp logo công ty mình vô. Xong mấy bạn ứng viên chiếu mới lại lôi case study ra cày, học vẹt dăm ba cái framework, ảo tưởng sức mạnh vô làm sẽ thành Mini-CEO cầm số liệu đi dẹp loạn.

Tới lúc on-board mới ngã ngửa.

The Theory: Product Manager là Mini-CEO

Lý thuyết đã nói rằng PM là Mini CEO của sản phẩm. Bạn là giao điểm của Business, UX, và Tech. Bạn được trao quyền để tìm ra vấn đề của người dùng, đề xuất giải pháp, và chịu trách nhiệm với outcome chứ không phải output.

Lý thuyết này rất hay. Nó là chân lý. Nhưng nó chỉ đúng khi bạn đang làm việc ở một công ty có Product Culture thực sự trưởng thành.

Cái này khỏi cần thống kê cũng thấy, đa phần mấy công ty tech mình biết đa phần là xưởng gia công tính năng và hiếm được làm product và có làm product cũng còn nhiều thứ phải xem lại. Ở mấy chỗ này làm gì có chuyện vẽ roadmap từ nỗi đau khách hàng. Roadmap toàn đẻ ra lúc sếp đi nhậu nảy số, hoặc do mấy anh chị Sales lỡ mồm hứa bừa với khách để chốt deal, xong quăng nguyên cục nợ về cho Product. Thỉnh thoảng thấy đối thủ có cái nút mới cũng cay cú ép dev copy y chang.

Lúc này thì mác Mini-CEO vứt sọt rác. PM bản chất bị giáng cấp thành thợ cook PRD trồng thêm 1 vài PM là là P trong Project.

Chả ai quan tâm bạn thắc mắc tại sao phải làm. Việc của bạn là cầm xấp tài liệu đi dỗ dành Dev, dí deadline bằng được. Chậm thì bạn ăn chửi, lỡ app ra không ai xài thì sếp bĩu môi bảo UX làm dở ẹc.

Thành ra tuyển mấy ông mộng mơ kiểu tiểu Steve Jobs về làm thợ gõ spec thì trụ được mấy hồi? Cãi nhau ỏm tỏi, ức chế rồi nghỉ. Sếp lại lên mạng than thở sao giờ tuyển PM khó thế, tụi nhỏ ảo tưởng quá.

Nói thiệt, trước khi ném tiền chạy tuyển dụng, các sếp soi gương nhìn lại cái ruột công ty mình xíu đi. Nếu công ty sống nhờ Sales, đụng chuyện gì sếp cũng phải duyệt cuối, thì dẹp cái trò tuyển PM chiến lược giùm. Tiền đó đi thuê mấy bạn PO hay BA cứng tay về cày spec, gõ ticket dí Dev có phải sướng hơn không. Đừng có ép người ta vẽ biểu đồ Cohort hay tính LTV trong khi cái tool tracking cài còn chưa xong. Thà kiếm một bạn chịu lết xác ra ngoài, bị khách chửi thẳng mặt để thấm cái app nó lởm chỗ nào còn ngon hơn vạn lần mấy cái bảng băm data ảo. Sòng phẳng ngay từ đầu cho đỡ phiền. Còn lương trả 25-30 củ thì bớt bắt người ta gánh sinh tử công ty lại, muốn nhân viên bán mạng thì cổ phần hay thưởng bét nhè ra.

The Patch: Định vị lại thực tại

Để đỡ lừa nhau rồi vài tháng lại chia tay, các sếp cứ soi gương chốt thẳng mấy vấn đề này trước khi viết JD để giảm thiểu tình trạng turnover rate cao ngất ngưởng với 3 điểm dưới đây :

Hãy bấm theo dõi để đọc đầy đủ
về nội dung còn lại miễn phí nhé.

Want to see the rest of this awesome Post ?
Just hit that subscribe button for free to unlock the full post right now!

Subscribe now

T.D,
T8.2026

Các giá trị tốt không nhất thiết đứng cùng một phía. Đến một thời điểm nào đó, chúng ta sẽ phải lựa chọn giữa hai thứ đều tốt. Và đó mới là việc khó nhất.

Một trong những bài viết sâu về người làm sản phẩm của người Việt. Bạn nên đọc bài a Khải trước khi đọc bài của mình. Nếu có thể hãy đọc nó vài lần để hiểu quan điểm của anh Khải vì sau đây là chia sẽ quan điểm cá nhân của mình về bài chia sẽ của a Khải đã được public. Ex Zalo / Pass Pv anh Khải.

Nhớ lại măm 2014, mình có cơ hội được ngồi trong phòng phỏng vấn với anh Khaivq.

Dù trước đó mình đã tự vọc vạch build vài app cùng team nhỏ tận dụng hiểu biết làm game, cũng gom được vài trăm ngàn user, nhưng thú thật, chừng đó chả là gì cả do hên và một phần cũng clone ý tưởng. Làm một cái app nhỏ cho vui nó khác một trời một vực với việc làm Product toàn diện ở scale hàng chục triệu người dùng. Quyết định sau khi pass đắn đo rồi khăn gói chuyển hẳn vào lại TP.HCM làm việc hồi đó thực sự đã thay đổi toàn bộ quỹ đạo sự nghiệp của mình. Email trao đổi ý chính đơn giản vậy thôi việc process nhanh và hỗ trợ từ Hr đợt đó là giúp mình bỏ các lo lắng phải rời Đn khi chưa có nhiều chuẩn bị.

Nếu không có cơ duyên được Zalo ngỏ lời mời làm việc, có lẽ mình đã không có giai đoạn 4-5 năm vùi đầu thuần túy vào việc build Product dù nhiều khi thấy toàn dính các dự án khù khầm fail nhiều. Nhưng mỗi anh ở Zalo hồi đó đều là một nhân vật riêng: khác tính, khác phương pháp, nhưng đều chung một chất: mê nghề và muốn làm và trái tính. Môi trường đó rèn cho mình đọc nhiều đủ thứ trên đời, để sau này có tý bản lĩnh qua những tổ chức tiếp theo. Đến tận bây giờ, mình vẫn luôn tin Zalo là một trong những lò luyện tốt nhất ở Việt Nam để học cách làm Product. Các bạn trẻ quan tâm có thể tìm hiểu các chương trình đào tạo PM mà Zalo tuyển hằng năm mà thời trước chả ai đào tạo.

Quay lại việc Anh Khải đã có một bài chia sẻ cực kỳ hiếm hoi dành cho các bạn trẻ về triết lý làm sản phẩm của ảnh. Mình được gửi đọc tuần trước và cho quan điểm, nên mình cũng viết bài này luôn, thực ra đây là bài khó viết với mình với blog nữa mùa gần 1 năm nay, khi nào ảnh và Zalo public thì mình chia sẽ cùng cho nóng =))

Ai từng làm việc trực tiếp với anh Khải đều biết: ở Zalo xưa có văn hoá ít lên đàn chém gió lắm, làm là chính, không thích màu mè, có khi mấy anh còn chửi te le nếu ai làm ngược lại và các bạn ngoài chả bao giờ thấy ai chia sẽ thế nào là người làm sản phẩm trong Zalo. Toàn bộ nội dung chia sẻ lần này của anh không kiểu slide đào tạo, không có mấy từ khóa buzzword. Bài viết ngắn gọn, đập thẳng vào vấn đề bằng đúng ngôn ngữ của một builder thực chiến, chắc có khi anh đã mất ngủ sửa tới lui hi vọng ae hiểu ý đúng ý ảnh viết và còn thấy nhấn mạnh “Tất cả những gì tôi chia sẻ từ đầu tới giờ có thể hoàn toàn sai” 😅

Hôm được nhận, mình đọc đi đọc lại vài lần,và đồng ý đa phần (đọc đến đây vẫn chưa đọc thì đọc đã nhé). Nếu bạn đã đọc các bài mình viết gần đây, có khi sẽ thấy nhiều ý gần tương tự. Không phải tình cờ, anh em ở Zalo thời trước đa phần tự học là chính, và nhiều thứ như thấm từ đâu ko rõ có thể từ cách tổ chức và mindset từ các anh leader, có lẻ thế. Nhưng cũng có vài điểm mình có quan điểm khác, và nếu tranh luận với ảnh về vụ làm product mình cũng sẽ nói các ý mình không đồng ý.

Mình không biết giờ ở Zalo không biết giờ còn ai cãi nhau với ảnh như ngày trước không ? Xưa phòng kính họp hay ào ào. Thực ra, nếu ai đó hỏi mình ngoài công việc, đồng nghiệp ra thì nhớ nhất điều gì về văn hoá Zalo ngày xưa, mình sẽ chọn cái văn hoá “được phép cãi nhau” khịa nhau ra mặt. Vào phòng họp cải nhau ầm ĩ để bảo vệ quan điểm đến cùng, nhưng bước ra khỏi cửa là không ai để bụng, việc ai nấy làm. Và quan trọng nhất: chưa bao giờ mình có cảm giác “không an toàn” khi dám nói thẳng, nói ngược lại với các sếp. Có thể thời đại bây giờ đã khác, người ta chuộng sự dĩ hòa vi quý, cá nhân cũng từ tốn hơn, cứ phải “tôn trọng nhau” rào trước đón sau mới được coi là một văn hoá làm việc an toàn chăng?

Bệnh Đẽo cày giữa đường và cú lừa A/B Testing

Giới làm Product ở Việt Nam hiện tại đang mắc một căn bệnh rất khó chữa: Tôn thờ số liệu một cách mù quáng. Cứ hễ tranh luận không ngã ngũ là lôi data ra làm câu chuyện phản biện che thân.

Có một đoạn anh Khải viết làm mình cực kỳ tâm đắc: “Trường hợp có nhiều hơn một giải pháp, nhiều người sẽ muốn A/B testing để chọn phương án. Tôi đặc biệt ghét cách tiếp cận này... Thiết kế sản phẩm dựa trên kết quả A/B testing giống như câu chuyện Đẽo cày giữa đường, tạo ra một sản phẩm chắp vá không có thiết kế tổng thể.”

Chính xác. (Mình từng nói vấn đề này trong bài The Reality Check #8: Sự hoang tưởng của Data-driven, anh em có thể đọc lại).

Nhiều PM hiện nay cứ mở mồm ra là để em chạy A/B test. Làm như A/B test là đũa thần không bằng.

Người dùng không biết họ thực sự muốn gì cho đến khi bạn đưa nó ra trước mặt họ. Nếu cứ ngoan ngoãn vâng lời p-value từ 10,000 user, những người thậm chí chả rảnh để hiểu cái vision tổng thể của sản phẩm, bạn sẽ đẻ ra một cái quái thai Frankenstein mỗi tính năng, mỗi cái nút bấm tối ưu cho một chỉ số cục bộ, nhưng ráp lại thì tổng thể cái app trông như một mớ rác bèo nhèo. Đẹp theo từng mảnh vụn nhưng lại xấu toàn cục.

Anh Khải nhắc đến giai thoại Google từng test 41 sắc độ xanh năm 2009. Dân kỹ thuật rất khoái trò này vì nó an toàn. Bạn đẩy trách nhiệm ra quyết định cho số liệu. App mà xịt thì cứ bài “do data nó bẩu thế, em làm đúng quy trình” mà cãi. Nhưng làm sản phẩm đủ tầm đòi hỏi người PM phải dám ra quyết định bằng trực giác, bằng trải nghiệm và sự thấu cảm (User Empathy). Data chỉ ra chỗ nào đang chảy máu, nhưng phương thuốc chữa trị phải đến từ khối óc con người. Thế nên mấy bài báo xạo sự bảo AI sẽ thay thế PM nghe nó buồn cười. AI chỉ thay thế được mấy ông PM tồi thôi.

Nói trắng ra: Data giỏi lắm thì chỉ báo cho bạn cái What, luồng nào đang drop, bước nào user bỏ ngang. Nhưng Why và How thì quên đi, không cái dashboard nào trả lời hộ bạn đâu. Tại sao họ bỏ? Sửa thế nào mới đúng? Câu trả lời nằm trong trực giác của một người đã nếm đủ đòn để thực sự hiểu user.

Trade-off: Lựa chọn máu me giữa hai cái TỐT

Bất kỳ ai làm PM đủ lâu, ăn sh*t qua vài product lớn đều sẽ nếm qua cảm giác này: Sale muốn nhét thêm pop-up banner để ra số, Dev muốn bóp bớt luồng cho nhẹ server, UX thì đòi mọi thứ mượt mà bóng bẩy không tì vết. Nghe ai cũng có lý, ai cũng vịn vào cái cớ “vì sản phẩm”. Có khi chính mấy ông PM sáng sớm nghe sếp khen một tính năng của đối thủ, sợ sếp phật ý thế là lật đật nhét luôn vào sprint ngày mai bất chấp nó có phá nát luồng hiện tại hay không.

Nhưng làm gì có chuyện ngon ăn thế. Anh Khải định nghĩa sự đánh đổi (Trade-off) rất rõ ràng như sau:

• Bạn muốn Mạnh mẽ? Bạn sẽ đánh mất sự Đơn giản.

• Bạn muốn Vui vẻ? Bạn sẽ làm giảm đi độ Tin cậy.

• Bạn muốn Hiệu quả? Chắc chắn sẽ ảnh hưởng tới tính Riêng tư.

Làm Zalo, áp lực cạnh tranh với các con quái vật như Facebook, WhatsApp, Viber hay Wechat thời đấy là cực lớn. Nhưng cái thú vị nhất trong bài của anh Khải là anh kể và cũng thừa nhận về Zing Me mạng xã hội năm 2009, từng chạm đến 10 triệu user nhưng cuối cùng vẫn hụt hơi trước Facebook và phải đóng cửa. Thất bại đó buộc anh phải tư duy lại từ đầu: không thể làm sản phẩm tương tự rồi cạnh tranh trực diện, cách duy nhất là tiến vào ngách đối thủ không xem trọng. Zalo được build trên luận điểm đó: không đua vũ trang tính năng, tập trung vào đúng ba điểm yếu mà đối thủ ngoại xem nhẹ trên hạ tầng viễn thông Việt Nam thời đó: Tốc độ, Ổn định và Riêng tư.

Mấu chốt ở đây là: Làm sản phẩm không có chân lý tuyệt đối, quan trọng là chọn cái gì hợp với ngữ cảnh lúc đó. Zalo ở một đất nước khác, với nguồn lực khác, ở thời điểm khác, có lẽ đã được build theo một triết lý hoàn toàn khác. Hiểu điều này là hiểu tại sao copy-paste framework từ người khác về dùng bậy là ảo tưởng hay đứng ngoài phán xét là dỡ hơi bạn không ở vị trí đó để quyết, nói luôn dễ hơn làm.

Việc nhắm mắt say Yes để thêm một tính năng vào app thì quá dễ. Nhưng cắn răng chặt bỏ một tính năng mà anh em Dev đã tốn hàng tháng trời code sấp mặt ngày đêm, chỉ vì nó phá vỡ sự “Đơn giản” của tổng thể. Đó mới là bản lĩnh thực sự của người cầm trịch. Anh Khải có nói trong bài rằng chính anh từng phải tự tay gỡ bỏ những tính năng liên quan đến hiệu quả công việc mà bản thân anh rất thích xài, chỉ vì 80 triệu người dùng phổ thông ngoài kia không cần nó.

Mình hiểu tại sao anh Khải chọn thế. Zalo là mass market. 80 triệu user đa phần không phải power user. Họ chỉ muốn nhắn tin nhanh, gọi được, không crash. Trong trường hợp đó, hy sinh tính năng productivity để giữ đơn giản là quyết định hợp lý. Nhưng quyết định đó có được copy sang mọi sản phẩm không?

Slack không thể bỏ tính năng productivity vì đó chính là lý do tồn tại của họ. Microsoft Teams không thể bỏ thiết lập quyền truy cập phức tạp chỉ vì user phổ thông thấy khó. Triết lý đảo ngược hoàn toàn. Càng làm B2B hoặc tool cho power user, bạn đôi khi càng phải thêm độ phức tạp chứ không phải bớt. Trade-off của bạn sẽ khóa chẳng khóa dây, nó phụ thuộc hoàn toàn vào ai là người dùng của bạn.

Phân biệt đúng sai thì dễ quá, ai chả làm được. Bản chất Trade-off chẳng qua là cắn răng chọn giữa hai thứ ĐỀU ĐÚNG, rồi chấp nhận nhìn một bên rỉ máu để giữ cho cái cốt lõi còn sống.

Founder Mindset: Niềm tin cực đoan và tố chất Builder

Trong bài Founder Mode: Lời nói dối ngọt ngào nhất thung lũng Silicon, mình từng nói cái trào lưu Founder lấy cớ micromanage để tàn phá quy trình của team. Mình đã nói về sự độc hại khi Founder can thiệp thô bạo vào sản phẩm ở giai đoạn scale-up.

Nhưng khi đọc bài của anh Khải, mình lại thấy một mảng ghép khác của câu chuyện: Sự cực đoan cần thiết của Founder ở giai đoạn Zero-to-One.

Để bắt đầu build một product mới toanh, nếu KHÔNG CÓ Founder Mindset, bạn gần như cầm chắc cái chết. Tinh thần làm product mới không chấp nhận sự dân chủ nửa vời. Nó đòi hỏi một sự cực đoan, một niềm tin vào công việc gần như cuồng tín.

Anh Khải nói một thứ mình thấy chả có gì bàn cải: anh tự gọi mình là “Người dùng số 0”. Khái niệm “Người dùng số 0” giúp Founder build sản phẩm từ chính nỗi đau thực sự của bản thân thay vì những giả định trên giấy. Chặng từ 0 lên 1 mà không có Founder Mindset với chút cực đoan thì cầm chắc phần thất bại.

Nhưng ranh giới giữa trực giác bén và định kiến cá nhân nó mong manh lắm. Bước sang bài toán scale-up hay B2B mà Founder vẫn tự coi mình là user đại diện thì hỏng. Cố chấp lúc này chỉ biến sản phẩm thành chỗ phục vụ cái Ego của sếp, chứ thị trường chẳng ai cần. Anh Khải cũng có lưu ý một vấn đề khá quan trọng là nếu chỉ tập trung vào chính mình thì góc nhìn rất dễ bị lệch, vì người làm sản phẩm thường không phải người dùng tiêu biểu. Do đó, cần liên tục tự điều chỉnh để suy nghĩ như một “người dùng ngây thơ phổ thông”, tức một người không quá rành công nghệ vẫn có thể hiểu và sử dụng sản phẩm một cách tự nhiên.

Nhưng để tự tách được bản thân và đặt mình thực sự vào đúng người dùng ngây thơ thì không dễ. Ở các Zalo hay chính các sản phẩm nhỏ. Nói thì dễ nhưng để làm được thì khó.

Vậy rõ ràng quá cố chấp vào trực giác cá nhân của Người dùng số 0, sản phẩm dễ rơi vào cái bẫy làm sản phẩm cho chính sếp dùng chứ không phải cho thị trường.

Tạm bỏ qua câu chuyện định kiến. Nếu bây giờ được chọn một ai đó, cấp cho họ nguồn lực, cơ hội và team để build lại một product thành công từ đống tro tàn và đưa nó đến scale như Zalo, mình vẫn hay nói với anh em trong ngành hỏi mình, mình hay trả lời chắc cũng chỉ biết trả lời: Chưa thấy ai qua được anh Khải (Zalo) hay anh Tường (MoMo). Đó không phải là học kỹ năng mà có, đó là tố chất của những “quái vật” sinh ra để làm builder. Còn nhiều anh em khác nữa cũng xịn, nhưng random kể ngay về digital product thì 2 ảnh là nổi trội nhất.

Còn nếu hỏi nhanh ngay trong nội bộ Zalo hiện tại còn ai kế thừa cái DNA làm sản phẩm mà anh Khải nhắc tới, mình sẽ nghĩ ngay đến anh Cường và 1 phần anh Chính. Anh Cường có lẽ là người mang style giống anh Khải nhất với sự gai góc và quyết liệt bảo vệ vision, còn anh Chính lại thể hiện một cách tổ chức sản phẩm thông minh theo một hướng rất riêng ... Dù khác biệt, họ đều có chung độ lỳ đòn, quái. Nhưng câu hỏi làm mình trăn trở là: Vậy sau anh Chính, anh Cường, thế hệ kế cận tiếp theo cầm lữa Product của Zalo sẽ là ai hoặc lâu quá ko update nên không biết.

Nhìn rộng ra lứa trẻ hơn một chút ở bên ngoài, nếu làm product B2C thì có thể kể đến nhanh HuyNX; còn ở mảng B2B thì Quân Trương là những cái tên hiếm hoi mang rõ style Founder Mindset mình từng gặp và hiểu đủ. Họ có một tinh thần tự học đáng nể.

Đã mang trong mình cá tính Founder mạnh mẽ, rõ ràng bạn sẽ nhận về cả sự nể trọng lẫn gạch đá. Nhưng bạn phải sẵn sàng bị người ta ghét, bị chửi là độc tài hay bảo thủ để bảo vệ lý tưởng và chiến đấu đến cùng với nó. Đó không chỉ là sự đánh đổi, mà là giá trị và trách nhiệm tối cao của người cầm trịch. Không có cái “Ego” gai góc đó ở vạch xuất phát, sản phẩm sẽ chết yểu ngay từ khi còn nằm trên giấy vì bị pha loãng bởi hàng tá ý kiến đóng góp ba phải của những kẻ ngoài cuộc hoặc người ngại trách nhiệm.

Nhưng đây cũng là câu hỏi mình ko hoàn toàn nghĩ có câu trả lời: Liệu Founder Mindset có lão hóa theo giai đoạn của sản phẩm không? Anh Khải tự đặt câu hỏi này theo cách khác: thông qua iPhone. Anh viết rằng năm ngoái, dùng thử Google Pixel và nhận ra: Pixel trông có cảm giác Apple hơn cả iPhone hiện tại. Ở góc độ UX hay sự đột phá bề mặt, có thể anh đúng. Nhưng nếu nhìn sâu hơn, mình lại nghĩ khác ảnh: Bản chất Apple vẫn là Apple.

Dù đôi khi người ta cảm thấy Apple chậm chạp hay UX giảm đi sự ngỡ ngàng, nhưng tinh thần làm sản phẩm tốt cốt lõi của Steve Jobs chưa bao giờ thay đổi. Google Pixel là bản lề để Google thử nghiệm tính năng cho các bên OEM, nên việc chấp nhận thiếu ổn định là bản chất của họ. Còn Apple chọn sự khắt khe và an toàn triệt để cho người dùng. Dù Steve Jobs không còn, cái chất đấy nó thấm sâu vào máu của bộ máy rồi. Nhìn cách họ làm bảo mật cho user mà xem: khắt khe và lì lợm khủng khiếp. Thế nên mới nói, Founder đi rồi nhưng nguyên lý làm sản phẩm của Apple có mất đi đâu. Tinh thần Founder hóa ra chả nằm ở mấy việc vi mô hằng ngày, mà nó ăn sâu vào văn hóa để ae kế cận tự chạy tiếp.

Nói thật, Zalo của 10 năm tới sẽ ra sao thì chả ai đoán trước được? Nếu một ngày anh Khải không còn trực tiếp cầm trịch, anh kỳ vọng linh hồn của Zalo sẽ tiếp tục tồn tại một cách kiên định với cái DNA ban đầu như cách a Viết là Dna của Zalo, hay di sản lớn nhất anh để lại chính là một đội ngũ kế cận đã đủ trưởng thành để tự bảo vệ và viết tiếp câu chuyện của sản phẩm theo cách mới? Đâu là điều làm nên sự vĩ đại tiếp theo của làm sản phẩm ở Zalo.

Lật ngược vấn đề một chút: Sự nguy hiểm có thể có của việc Núp bóng quyết định Lãnh đạo.

Tuy nhiên,và đây là vấn đề mình không hoàn toàn đồng tình với góc nhìn của anh Khải trong 1 số đoạn trong bài viết, mình ko còn đủ thông tin hiện tại sẽ áp dụng vào việc quản lý đội ngũ lúc high scale.

Anh Khải nói: Lãnh đạo cấp cao phải là người “đưa ra những quyết định trái chiều dư luận”, chịu trách nhiệm bảo vệ linh hồn sản phẩm, và chấp nhận làm người đóng vai ác gạt bỏ công sức của anh em kỹ sư. Tại sao không hạn chế làm cái đó từ đầu ? Có cách nào giảm ma sát đó sớm hơn không ?

Điều này rất đúng để giữ cho sản phẩm không bị hỏng sớm. Nhưng, với tư cách là một người cũng từng đứng ở vị trí cao để build các sản phẩm hệ sinh thái gần đây, mình thấy cách làm này nếu không chuẩn và nếu không có phương pháp hợp lý, hay có một văn hoá rõ ràng cho việc quyết định ưu tiên nó lại gây hại một phần cho đội ngũ.

Ở một tổ chức nào đó nếu Leader luôn đóng vai anh hùng cứu thế, đứng ra để làm mọi phán quyết “cái này giữ, cái kia bỏ”, thì team bên dưới dần dần giảm năng lực tư duy phản biện và ra quyết định. Họ biến thành những “thợ” ngoan ngoãn. Họ an toàn. Họ không bao giờ phải nếm cái sai lầm của việc tự ra một quyết định tồi, và cứ thế sẽ có thể mượn danh “sếp chỉ đạo” để lấp liếm khi trễ deadline hay không giữ lời với anh em bên dưới như một người đại ka. Họ khó học cách ra quyết định trade-off ở team để giữ cho sản phẩm không bị toang hay đơn giản chính trực nhận lỗi do họ mà bảo do quyết định cấp trên.

Anh Khải cũng có nhắc đến việc nhiều người rời đi. Mình nghĩ một phần vì Zalo phát triển quá nhanh và giờ lúc cần ổn định hơn và quyết định thận trọng hơn, giờ đòi hỏi sự ổn định cao hơn so với lúc trước và phục vụ mass user với các bài toàn rõ ràng nhất để kiếm tiền thông qua việc phân chia user như a Khải nói, nên không có nhiều cơ hội để nhiều người trẻ tự tay ra các quyết định trade-off hằng ngày. Thế nên, nhiều anh em rời Zalo không hẳn vì bất mãn hay chuyện bị gạt bỏ tính năng. Mình và hay nhiều anh em khác ra đi trước đây đa phần đơn giản vì một khao khát thuần túy của người làm nghề: muốn được tự tay cầm trịch, được dấn thân vào những bài toán gai góc do chính mình tạo ra. Hoặc đơn giản là không còn phù hợp với cách quản trị Zalo thời điểm đấy hoặc không nằm trong nhóm sản phẩm được ưu tiên thời điểm đó đơn giản vậy thôi, mình nghĩ vậy.

Ở Zalo, cái nền móng các anh lớn xây dựng với nhiều triệu user đã quá vững chãi và an toàn. Rời đi đơn giản là để bước ra khỏi vùng an toàn đó, đi tìm một khoảng trời riêng nơi mình được thực sự làm chủ cuộc chơi. Dù vậy, mình tin những người từng đi qua Zalo vẫn luôn giữ một tình cảm đặc biệt và hiếm nơi nào được làm sản phẩm theo cách ở Zalo được làm, đa phần sẽ sẵn sàng support lại khi có cơ hội, chờ ngày ai đó bảo dựng cờ được gọi là Zalo Mafia như kiểu PayPal Mafia.

Đó là lý do mình lại tin rằng: quan điểm founder hay người làm product owner như ảnh nói thay vì ôm khư khư việc ra quyết định trade-off để giữ cho sản phẩm lúc nào cũng hoàn hảo theo cách founder nghĩ, nhiều khi nên nhắm mắt thoải mái để team quyết định SAI lại là nước cờ sống còn. Hoặc thoải mái việc ae chưa làm theo đúng 100% ý mình.

Một đội ngũ thiện chiến chỉ được rèn giũa khi họ tự nếm mùi thất bại. Hãy để họ hăm hở launch một tính năng thừa thãi, rồi tự ôm đầu bứt tóc, thức trắng đêm khi thấy user chửi rủa, retention cắm đầu xuống đất. Leader xuất sắc không phải là người đứng ra quyết thay mọi thứ, mà là người vẽ ra vùng rủi ro cho phép để team được phép làm sai mà không tổn hại đến sự sống còn của doanh nghiệp. Tất nhiên, sai lầm phải nằm trong giới hạn kiểm soát.

Mình vẫn còn nhớ luồng cập nhật chính sách chia sẻ dữ liệu của Zalo dạo nọ. Nhìn cái màn hình đó, mình đứng hình mất 5s vì không tin nổi một sản phẩm vốn nổi tiếng về sự chỉn chu hạn chế tối đa cái không cần thiết lại có thể push lên một trải nghiệm cộc lốc như vậy. UX lởm thì có thể thông cảm, nhưng quăng cái luồng thu thập thông tin cá nhân vào mặt user một cách ép uổng thì đúng là tự bắn vào chân. Việc này có thể không làm app sập, cũng chẳng ai bị đuổi việc, nhưng hình tượng trong mắt một bộ phận user bị mất điểm trầm trọng. User có thể nhắm mắt xài một cái nút xấu, nhưng họ sẽ nổi điên nếu cảm thấy quyền riêng tư của mình không được tôn trọng. Mình trộm nghĩ không rõ đúng ko: Nếu không cho team tập SAI ở những việc nhỏ, họ sẽ vấp ngã rất đau ở những quyết định lớn.? Hi vọng chỉ là do xui.

Nhưng rõ ràng chính cái cảm giác khó chịu, khi phải nai lưng dọn dẹp đống rác do mình tạo ra sẽ dạy cho anh em về Trade-off ngấm hơn ngàn vạn lời thuyết giáo từ Leader. Team sẽ bén hơn rất nhiều nếu tự đi qua cái quy trình quyết sai → vấp ngã → sáng mắt ra, thay vì cứ há miệng chờ sếp phán. Tốc độ học hỏi và sự trưởng thành của tổ chức nhiều khi đáng giá hơn việc giữ cho các quyết định hoàn hảo. Mình không cổ xúy việc cố ý làm sản phẩm tệ đi để team học hỏi, nhưng đôi khi chấp nhận một mức độ rủi ro nào đó để anh em được quyền tự quyết và tự chịu trách nhiệm cho từng feature, từng con số 0.01% KPI đó lại là cách nhanh nhất để mài giũa một thế hệ lãnh đạo kế cận cho công ty.

Góc khuất của người đứng đầu

Thực ra, làm Leader rất khó để chia sẻ sao cho anh em bên dưới hiểu hết được góc nhìn và áp lực và cả tinh thần làm của mình.

Ngồi ngoài phán thì lúc nào chả dễ hơn xắn tay vào làm app cho chục triệu người xài. Nhưng đọc bài anh Khải là thấy lại ngay cái chất Zalo xưa giờ: kỹ tính, lì đòn và chả care mấy cái chỉ số màu mè.

Nhìn vào sản phẩm là rất dễ để biết ngay tính cách người tạo ra nó. Bạn chọn ôm khư khư cái linh hồn sản phẩm, hay chấp nhận lùi lại nhìn anh em vấp ngã để lớn lên đó mới là quả Trade-off đau đớn nhất của người làm sếp.

Share Datht's Reflections

T8.2026
T.D

Chuyện kể rằng
Chúng tôi đã chuyển sang mô hình Squad. Founder một startup 80 người ở Quận 1, nói với vẻ tự hào trong buổi meetup PM tháng trước.

“Squad lead report cho ai?”
Anh ấy ngập ngừng: “Ờ... vẫn report cho Head of Engineering.”
Vậy đó không phải squad. Đó là team cũ đổi tên trên Slack.

Khoảng giữa 2024, mình ngồi review lại cách tổ chức product team cho một dự án nội bộ ở OneMount. Lúc đó hệ sinh thái đang scale mạnh VinID, VinShop, Onehousing nhiều vertical chạy song song, mỗi vertical có PM riêng, có dev riêng, nhưng nhiều service thì share chung.

Nghe quen không? Đúng rồi, kinh điển matrix.

Và matrix thì có một vấn đề kinh điển không kém: PM nói mình cần 2 backend dev cho tính năng loyalty tuần này, Head of Engineering nói 2 backend dev đó đang fix bug cho team Payment, đợi sprint sau. PM escalate lên CPO. CPO escalate lên CTO. CTO bảo để anh xem. Rồi không ai xem gì cả.

Tính năng loyalty trôi thêm 3 sprint.

Mình kể chuyện đó không phải để than vãn. Mà vì đó chính xác là cái bệnh mà Spotify Model hứa sẽ chữa. Cross-functional squad, mỗi squad có đủ PM + Engineer + Designer, tự chủ hoàn toàn, không phải xin resource từ ai. Nghe như thiên đường.

Rồi nửa ngành tech VN đọc cái whitepaper đó xong, đổi tên team thành squad, đổi tên department thành tribe, đổi tên line manager thành chapter lead. Xong.

Xin chúc mừng: bạn vừa hoàn thành cuộc cách mạng tổ chức bằng cách... đổi tên trên Confluence.

Nếu bạn đọc nhiều và có tìm hiểu thay vì cứ nghe cho biết giống 80% người ra rả họ có bằng cấp về Agile nên rất hiểu thì Spotify chưa bao giờ chạy Spotify Model.

Đây là cái twist mà ít người biết, và khi biết rồi thì khó nuốt.

Năm 2012, Henrik Kniberg và Anders Ivarsson hai Agile Coach ở Spotify xuất bản một whitepaper mô tả cách Spotify tổ chức engineering team: squads, tribes, chapters, guilds (Mình có tìm được bảng dịch tiếng Việt ở đây). Kèm theo một cái video animation rất đẹp trên YouTube. Video đó viral khắp cộng đồng Agile, được chia sẻ hàng triệu lần, in ra slide deck, treo lên tường phòng họp khắp thế giới.

Vấn đề: cái whitepaper đó mô tả một trạng thái ước mơ, không phải thực tế vận hành. Chính Joakim Sundén đồng tác giả sau này thừa nhận nó là “part ambition, part approximation.” Nghĩa là: một phần mong muốn, một phần ước chừng. Spotify lúc đó đang thử vận hành theo cách đó, không phải đã chạy thành công.

Nghe có điên rồ không nhưng có vẻ giống truyện cười học võ công tự cung xong học hết sách mới biết có đoạn sau. Cay

Và đến 2020, Jeremiah Lee cựu PM tại Spotify viết một bài dài có tựa đề thẳng thừng: “Spotify’s Failed #SquadGoals.” Trong đó Lee nói rõ: mô hình squad tại Spotify đã thất bại. Công ty dần quay về cấu trúc quản lý truyền thống hơn khi scale lên hàng nghìn người. Squad autonomy gây ra coordination debt nghiêm trọng các squad trùng lặp effort, không ai chịu trách nhiệm cho những thứ nằm giữa ranh giới của 2 squad, và PM thường xuyên rơi vào trạng thái có trách nhiệm deliver nhưng không có quyền ra quyết định kỹ thuật.

Lee cũng nói một điều đắng lòng: Spotify giữ cái narrative “Spotify Model” sống lâu vì nó là recruitment tool cực tốt.

“Chúng tôi có văn hóa tự chủ, chúng tôi chạy squad” câu đó giúp tuyển engineer giỏi. Còn bên trong thì... khác.

Vậy là cả ngành tech toàn cầu bao gồm VN đã bỏ hàng triệu giờ để copy một thứ mà chính nơi sinh ra nó cũng không chạy được và để chạy được 1 phần như Spotify thì nếu có cơ hội nói chuyện bạn sẽ hiệu những nhân sự trong đó giỏi như nào.

Mình đã từng nhắc đến kiểu “cargo cult” này ở Tập #5 — Agile Theater. Cùng một DNA: copy nghi thức, bỏ qua bản chất.

Ở VN, squad thường chỉ là functional org đội mũ mới.

Nói thẳng luôn cho nhanh. Mình đã nói chuyện với PM ở ít nhất 30 công ty tech VN trong 2 năm qua từ startup 10 người đến tập đoàn nghìn người tự xưng chạy squad model. Khi hỏi kỹ, pattern gần như giống nhau:

Pattern 1: PM xin resource từ EM ngược hoàn toàn với squad.

Trong squad model chuẩn, PM và Engineer nằm trong cùng một squad, report cho cùng một squad lead. PM không cần xin resource vì resource đã thuộc về squad. Nhưng ở hầu hết công ty VN mình thấy, Engineer vẫn report solid-line cho Head of Engineering hoặc Engineering Manager. PM report cho Head of Product hoặc thậm chí CEO. Hai đường solid-line khác nhau.

Khi PM cần dev, PM phải negotiate với EM.

Đó không phải squad. Đó là matrix. Và matrix thì có từ thập niên 70 rồi không cần đọc whitepaper Spotify để biết nó gãy ở đâu.

Pattern 2: Squad nhưng không có Design chỉ có PM và Dev.

Squad chuẩn là cross-functional: PM + Engineer + Designer + Data (tùy context). Nhưng team Design ở nhiều công ty VN quá ít người, không đủ rải vào mỗi squad.

Kết quả: Design thành shared service. Squad phải đặt lịch với Design team, chờ slot, rồi Design xong quăng file Figma qua rồi chạy sang squad khác. Không có ownership, không có context liên tục.

Mình gọi đó là squad hỏng chân. Bạn bảo đó là cross-functional nhưng thiếu một function quan trọng nhất cái function quyết định user experience.

Pattern 3: “Tribe Lead” = Director cũ đổi chức danh.

Trong mô hình Spotify, Tribe Lead được kỳ vọng là người tạo điều kiện cho squad hoạt động tự chủ facilitator, không phải commander. Ở VN, Tribe Lead thường là cái ông Director vẫn approve mọi PR (pull request), vẫn duyệt mọi spec, vẫn họp review hàng tuần với từng squad để track progress. Hoặc một ông/bà Project Director có title nhưng không có thực quyền, Squad autonomy ở đâu?

Trên Confluence à ?. Trên thực tế, mọi quyết định vẫn chạy lên trên rồi chạy xuống.

Mà nói đi cũng phải nói lại. Tại sao các công ty VN làm vậy? Có phải vì họ ngu / hay họ dỡ hơi không biết không ?

Không. Họ làm vậy vì có những constraint rất thực mà Henrik Kniberg ngồi ở Stockholm không bao giờ phải nghĩ tới và có nghĩ cũng chả giải được.

Constraint 1: Engineer giỏi quá ít, không đủ rải

Spotify năm 2012 có khoảng 1,500 nhân viên, đặt tại Stockholm một trong những thị trường tech trả lương cao nhất châu Âu. Họ có điều kiện tuyển đủ senior engineer cho mỗi squad.

Startup VN 80 người? Backend senior chỉ có 3-4 người. Bạn có 6 squad nhưng chỉ đủ senior cho 3. Mấy squad còn lại chạy toàn junior và junior thì cần guidance từ senior, cần review từ EM. Không thể tự chủ được. Autonomy cần competence làm nền tảng. Chưa có nền thì không thể xây nhà.

Constraint 2: Văn hóa quyết định theo cấp bậc

Mình đã nói ở Tập #3 — Empowered Teams, nhưng nói lại cho context.

Squad autonomy yêu cầu CEO/CTO tin tưởng squad ra quyết định mà không cần xin phép. Ở Thụy Điển nơi Power Distance Index (PDI) thuộc hàng thấp nhất thế giới điều này tự nhiên. Sếp và nhân viên gọi nhau bằng tên. Intern dám challenge ý kiến VP trong meeting.

Ở VN, PDI cao gần gấp đôi. “Anh chỉ đạo, em thực thi” vẫn là norm. CEO nói “làm cái này đi” thì cả squad dừng mọi thứ đang làm để chạy theo. Không phải vì squad yếu mà vì hệ thống incentive reward việc tuân thủ, không reward việc phản biện. Bạn muốn squad tự chủ nhưng review performance hàng quý vẫn do Director chấm điểm Director thích người nghe lời.

Hôm trước mình ngồi cà phê với một anh EM ở một công ty fintech top VN. Anh ấy kể: “Squad mình trên giấy thì tự chủ. Nhưng mỗi tuần CEO nhắn Slack hỏi ‘feature X đến đâu rồi’ thì squad tự chủ kiểu gì?”

Mình cười: “Vậy squad của em tự chủ... cho đến khi CEO mở Slack.”

Constraint 3: Turnover rate quá cao để maintain squad stability.

Squad model hoạt động tốt khi team ổn định cùng nhau đủ lâu để build trust, hiểu context sản phẩm, phát triển nhịp làm việc chung. Spotify recommend squad nên gắn bó ít nhất 6-12 tháng.

Ở VN, turnover rate ngành tech trung bình 20-25% mỗi năm. Một số startup con số đó lên tới 40%. Squad 6 người, cứ 3 tháng mất 1, sau 1 năm squad chỉ còn 3 người gốc. Context bị rửa trôi liên tục. Mỗi lần có người mới vào lại mất 1-2 tháng onboard. Squad trở thành một cái xô thủng đổ nước vào bao nhiêu cũng rỉ ra.

Vậy nên tổ chức product team kiểu gì?

Mình sẽ không đưa ra một framework mới rồi đặt tên đẹp đẽ vì bản thân cái việc copy framework là gốc rễ của vấn đề. Thay vào đó, mình chia sẻ 3 nguyên tắc mà mình thấy hoạt động, cả ở những chỗ mình từng build team lẫn những chỗ mình chia sẽ để áp dụng thử.

Hãy bấm theo dõi để đọc đầy đủ
nội dung còn lại hoàn toàn miễn phí nhé.

Want to see the rest of this awesome Post ?
Just hit that subscribe button for free to unlock the full post right now!

Subscribe now

Bạn đang ở đâu? Squad thật hay squad cosplay?

T.D,

T8.2026

Đời startup của anh chuyển từ một nền tảng thuần digital (VNG, Uiza,…) sang trận chiến platform gọi xe đầy máu me (Be Group), và giờ là một business sặc mùi O2O (Online-to-Offline) kết hợp phần cứng như chuỗi rửa xe tự động Jetx.

Bạn ủng hộ thêm startup mới của anh Jimmy ở đây một Biz mình tin sẽ là một tay chơi mới thứ thiệt thời gian tới và sẽ phủ khắp VN.

Download ở đây.

Sự chuyển dịch đó mang theo cực kỳ nhiều bài học mà anh đã chia sẽ. Bữa đó hai anh em nói chuyện nhiều về chuyện build product, làm mướn vs làm chủ. Và sau đó là buổi ảnh chia sẽ khá nhiều với team product lead ở cty bọn mình.

Mình có note lại mấy cái gạch đầu dòng khá tâm đắc và xin ý kiến anh về việc chia sẽ một số nội dung lên blog này, nên viết lại ở đây cho anh em nào đang có ý định nhảy ra làm riêng hoặc đang làm PM mà muốn bơi ra biển lớn.

Đừng làm Founder, trong khi mindset vẫn còn nghĩ đi làm chỉ để nhận lương, trong chính công việc hằng ngày của bạn.

Cái danh xưng “Product Builder” dạo này đang bị lạm dụng một cách khủng khiếp. Lên LinkedIn, nhìn đâu cũng thấy mấy bạn tự xưng là builder, làm ba cái app nho nhỏ, kéo thả mấy cái tool no-code rồi tự gán mác. Anh Jimmy bóc tách chuyện này cực kỳ hay.

Product builder là người luôn trong trạng thái “muốn tìm và thấy bài toán muốn giải”. Họ có sự tò mò. Nhưng để bước lên làm Founder và tự gọi là một builder, bạn phải có một tinh thần Entrepreneur (doanh nhân), chứ không chỉ là một builder như thợ hay clone bề mặt đơn thuần làm không kinh doanh thì builder nổi gì.

Tiền nhiều thì giải bài toán lớn (kiểu hệ thống rửa xe tự động), tiền ít thì nhảy vào bài toán nhỏ (như xe đẩy bán bánh mì). Chẳng có gì sai cả.

Nhưng cái cốt lõi làm nên một Founder là gì? Bạn phải là người có cá tính riêng biệt và sẵn sàng thể hiện, áp đặt tầm ảnh hưởng lên người khác. Nếu bạn chỉ thích núp sau cái màn hình gõ phím, né tránh việc va chạm với con người và dòng tiền, thì muôn đời bạn chỉ là thợ code hay thợ vẽ spec thôi. Đừng gọi mình là Founder.

Tư duy Build to Win: Cái chết của kỷ nguyên Đốt tiền làm từ thiện.

Nói về chuyện làm sao để thắng, anh Jimmy có mấy cái rule of thumb đẫm máu từ chiến trường thực tế và một số nổi đau nếu có dịp ngồi với ảnh các bạn nên hỏi. Đầu tiên, một product khi ra mắt phải chọn ra được những điểm mạnh cốt lõi. Giả sử bạn list ra 10 yếu tố, thì giai đoạn đầu cần thắng được ít nhất 2 cái để có cơ hội ngóc đầu lên. Không ai làm xuất sắc được cả 10 thứ ngay từ Day One.

Nhưng bài học quan trọng nhất được rút ra từ người từng có cơ hội xây cty hằng chục hằng trăm triệu đô từ anh Jimmy là: Không bao giờ bán dưới giá thành, ko bán lỗ.

PHÂN TÍCH LẠI TÝ: Chúng ta đã đi qua cái thời đại mà các nền tảng (platform) cắn răng chịu lỗ sặc máu để thu hút user bất chấp. Nhìn lại thị trường gọi xe Việt Nam giai đoạn 2018-2020 là thấy sự điên rồ: Grab từng ôm khoản lỗ lũy kế lên tới 4.300 tỷ đồng vào cuối năm 2019, Gojek (lúc đó là GoViet) đốt gần 5.700 tỷ đồng sau 6 năm rồi phải xách vali rời Việt Nam vào tháng 9/2024. Chính Be Group trong năm 2019 cũng phải chịu lỗ hơn 1.500 tỷ đồng để trụ lại trong cuộc chiến voucher.

Cái bài lỗ để mua user đó chết ngắc rồi. Giờ là lúc bạn phải giảm chi phí để tăng trưởng user mà KHÔNG LỖ.

Tất nhiên, làm kinh doanh sẽ có lúc này lúc kia. Bạn có thể chấp nhận một tỉ lệ under-perform tức là lỗ nhẹ hoặc hòa vốn ở một tệp khách nhất định miễn là phần medium/high perform cover lại được để tổng thể cái P&L (Profit & Loss) vẫn có lời. Khi scale lên, cứ thẳng tay cắt bớt hoặc tăng giá ở nhóm under-perform đi để đảm bảo biên lợi nhuận. Đừng có cố gắng ôm đồm làm từ thiện.

Góc nhìn ngược: Customer Obsession là một cái bẫy

Đây là cái mình khoái nhất trong cuộc trò chuyện của anh với team. Sách vở thì cứ leo lẻo dạy PM phải lấy người dùng làm trung tâm, nghe lời user như nghe lời thánh. Nhưng góc nhìn của anh Jimmy thì tát thẳng vào mặt lý thuyết đó: Không cố gắng đáp ứng mọi nhu cầu của user.

Sẽ luôn có những khách hàng không bao giờ chọn product của bạn, và bạn không nên cố gắng bằng mọi cách để hầu hạ tập đó làm gì cho rước họa vào thân vì bạn ko thể làm hài lòng họ hoàn toàn hãy giữ nguồn lực để phục vụ khách hàng phù hợp.

Ví dụ thực tế với bài toán JETX (chuỗi hệ thống rửa xe tự động) của ảnh: sẽ luôn có một tệp khách có thời gian rảnh, thích mang xe ra tiệm, ngồi nhâm nhi ly cà phê cả tiếng đồng hồ để nhìn ông thợ xịt gầm, dòn nội thất, rửa kỹ càng từ trong ra ngoài. Kệ họ, mình không phục vụ tập đó. Không cần phải thay đổi hoặc bẻ cong sản phẩm cốt lõi rửa tự động bằng máy để đáp ứng nhu cầu xoi mói tỉ mỉ này.

JETX đánh thẳng vào tệp cần sự nhanh gọn và affordable. À, có một cái mẹo nhỏ về định vị: dùng chữ affordable (hợp túi tiền) thay vì dùng chữ rẻ nghe nó rất phèn. JETX nhấn mạnh yếu tố tốc độ (5 phút xong) và giá cả hợp lý, nhưng không bao giờ điêu ngoa hứa hẹn là “sẽ rửa sạch 100% không tì vết” vì máy móc thì không thể nào bằng con người soi từng ngóc ngách được. Xác định điểm mạnh, điểm yếu rõ ràng, không giấu cái yếu đi nói rõ cái mình chọn và chỉ chém mạnh vào cái mình giỏi.

Nhìn từ vĩ mô là quan trọng của làm startup: Ví dụ bài toán anh Jimmy chọn giải. Tại sao lại là bài toán rửa xe lúc này?

Làm product mà chỉ cắm mặt vào user feedback là dở, phải biết nhìn bức tranh vĩ mô (Macro). Anh Jimmy chọn JETX-Wash24h vì data thị trường quá rõ ràng: Theo thống kê gần đây, tỷ lệ sở hữu ô tô tại Việt Nam hiện nay loanh quanh mức 63 xe/1.000 dân. Con số này cực kỳ thấp nếu so với hàng xóm: Thái Lan là ~275 xe/1.000 dân, còn Malaysia lên tới hơn 500 xe/1.000 dân.

Nghĩa là gì? Dư địa tăng trưởng của quá trình “ô tô hóa” ở Việt Nam đang bước vào giai đoạn bùng nổ khi GDP đầu người rục rịch vượt mốc 5.000 USD. Chơi ở một thị trường đang đón sóng lớn thì việc tìm ra một mô hình rửa xe chuẩn hóa, cắt bớt sức người chính là một mỏ vàng. Nhìn ra nước ngoài tham khảo rồi ốp về Việt Nam điều chỉnh lại. Đó là tầm nhìn của một người chơi hệ vĩ mô.

Chuyện con người là một yếu tố cần rõ ràng khi làm startup.

Hãy theo bấm theo dõi để đọc đầy đủ
về nội dung còn lại miễn phí nhé.

Want to see the rest of this awesome Post ?
Just hit that subscribe button for free to unlock the full post right now!

Subscribe now

T.D

T6.2026.

P/s : Seri Bài viết của the-founders-lens là bài viết dạng tổng hợp được trích dẫn từ các chia sẽ cá nhân trong phạm vi buổi chia sẽ cho nội bộ team mình và đã được xác nhận chia sẽ lên Blog. Các trích dẫn view của người nêu tên chia sẽ trong bài viết một phần thì cần/nên có xác nhận để tránh các góc nhìn sai lệch. Bài viết sử dụng cho mục tiêu tạo ra góc nhìn thực tế cho cộng đồng Product Việt Nam.

“Nếu bạn không xấu hổ với phiên bản đầu tiên của sản phẩm, bạn đã launch quá trễ.” Reid Hoffman, LinkedIn Co-founder. Câu nói này đã được in lên áo thun, dán lên tường office, chép vào slide pitch deck của hàng nghìn startup.

Và ở Việt Nam, nó cũng đã giết không ít trong số họ.

Tháng 12/2020, làng game thế giới chứng kiến một thảm họa mang tên Cyberpunk 2077. CD Projekt Red, studio lừng danh đứng sau siêu phẩm The Witcher 3, đã rush launch một tựa game chưa hoàn thiện sau nhiều lần trì hoãn.

Kết quả? Game đầy lỗi, crash liên tục, và đồ họa thảm hại trên các hệ máy cũ. Làn sóng phẫn nộ bùng nổ. Hậu quả tàn khốc nhất đến vào ngày 18/12/2020: Sony đưa ra quyết định vô tiền khoáng hậu là gỡ bỏ hoàn toàn Cyberpunk 2077 khỏi PlayStation Store và hoàn tiền vô điều kiện. Từ một kỳ quan công nghệ được kỳ vọng nhất thập kỷ, tựa game trở thành case study kinh điển của việc ship một sản phẩm chưa sẵn sàng.

Bạn có thể nói: “Đó là game AAA, Nếu startup của mình làm app nhỏ xíu giao đồ ăn chay thì sao, so sánh thế nào được?”

Đúng là quy mô khác nhau. Nhưng bản chất hành vi của người dùng thì không. Gõ vào thanh tìm kiếm của Facebook: “app lỗi bị bóc phốt.” Bạn sẽ thấy một dòng timeline dài không có điểm kết thúc ở thị trường Việt Nam.

Screenshot order giao sai địa chỉ. Hình chụp push notification bắn lúc 3 giờ sáng. Các bài đăng trong hội nhóm ngành (Ăn chay HCM 80K member, Hội review app 200K member) với nội dung: “Warning anh chị em: app X vừa ra mắt, mình khuyên thật là đừng dùng...” Kèm theo là hàng trăm comment đồng tình, share qua Story.

Đây là pattern mình quan sát thấy ở nhiều startup trong vài năm qua: rush launch vì “tinh thần MVP”, bị bóc phốt, im lặng, rồi chật vật phục hồi hoặc chết hẳn.

Mình tạm gọi hiện tượng này là “Bóc Phốt Theater” không phải vì cộng đồng sai khi phản ứng, mà vì rất nhiều startup đang dùng chữ “MVP” như một cái giấy phép để ship thứ chưa đủ tiêu chuẩn tối thiểu, rồi ngạc nhiên khi thị trường không bao dung như họ nghĩ. Và cái giấy phép đó có nguồn gốc từ một câu nói bị trích dẫn sai bối cảnh đến mức nguy hiểm.

Subscribe now

The Theory: Tại sao Reid Hoffman lại nói vậy?

Muốn phản bác đúng chỗ, phải hiểu câu đó ra đời trong bối cảnh nào.

Năm 2011, Reid Hoffman đưa ra câu đó không phải trong một keynote hoành tráng. Đó là câu ông chia sẻ từ kinh nghiệm build LinkedIn một sản phẩm mà theo ông, khi launch phiên bản đầu tiên, cả team đều thấy xấu hổ vì nó quá sơ sài. Nhưng nó hoạt động. Nó thu hút được early adopters. Và từ feedback của nhóm người đó, LinkedIn mới biết nên build gì tiếp theo.

Tinh thần gốc của MVP không phải là ship đồ nát. Nó là đừng để sự hoàn hảo là kẻ thù của đủ tốt học nhanh hơn là build hoàn hảo. Eric Ries trong cuốn The Lean Startup định nghĩa MVP là phiên bản sản phẩm cho phép team thu thập được maximum validated learning với minimum effort.

Từ khóa là validated learning không phải minimum quality.

Ý tưởng đó hoạt động rất tốt trong một số bối cảnh cụ thể:

Thứ nhất: thị trường unknown nơi user chưa có baseline kỳ vọng vì chưa ai làm sản phẩm tương tự.

• Dropbox launch beta bằng một cái landing page + video demo năm 2007 không có app thật. 70,000 người đăng ký chỉ sau 24 giờ. Vì không ai biết file sync trên cloud sẽ trông như thế nào, họ không có gì để so sánh và phán xét.

Thứ hai: sản phẩm có vòng feedback ngắn và chi phí thất bại thấp B2C SaaS, consumer app, internal tool. Bạn launch, user dùng thử 3 ngày, feedback, bạn fix, launch lại. Cycle ngắn. Damage có thể recover.

Thứ ba: market mà reputation damage có thể repair được thường là thị trường ở giai đoạn cao điểm của hype cycle, nơi user bao dung hơn vì họ cũng đang học cùng sản phẩm.

Vậy vấn đề không phải là MVP sai. Vấn đề là ngành PM Việt Nam đã take câu đó ra khỏi context và biến nó thành cái giấy phép lái xe hạng nặng mà không ai phải thi bằng.

The Breaking Point: 3 lý do MVP Tệ hại là công thức tự sát ở VN

Lý do 1: Mạng xã hội VN không có vùng thử nghiệm chỉ có sân xử tội, và vấn nạn thích chê bai hơn động viên sản phẩm khác. Toxic hoá vấn đề không cần thiết.

Dropbox năm 2007 ra mắt khi Twitter chưa phổ biến, Facebook chỉ mới mở cho public, smartphone chưa phổ cập. Feedback loop chủ yếu qua email và tech blog. Một cái bug hay UX lủng củng? Một số người phàn nàn, team fix, xong.

Bây giờ, 2026, bạn ra mắt app giao đồ ăn chay ở Việt Nam. Ngay trong 24 giờ đầu, nếu có gì không ổn:

• Người dùng chụp màn hình.

• Đưa lên group Facebook ngành nếu ví dụ ứng dụng quán ăn (Ăn Chay HCM: 80K members; Hội review app Việt: 200K members; các group tập trung dân ngành tech, startup, PM hàng chục nghìn người mỗi nhóm).

• TikTok review. Reels. Story.

• Báo mạng tech VN pick up nếu đủ drama.

Tốc độ lan truyền của một cái “bóc phốt” ở VN năm 2026 gần như bằng thời gian thật. Không có sợ chờ đợi khi hạnh phúc con người là cảm thấy sướng khi mình chửi hay chê sớm. Không có cơ hội giải thích. Bạn bị xét xử trước khi kịp viết blog post xin lỗi.

Và điều tàn nhẫn hơn: trust ở VN mất đi là không lấy lại được. Mình không nói điều này như một cái thành kiến đây là hệ quả của nhiều năm thị trường bị lừa dối bởi quá nhiều sản phẩm “xổ bừa ra rồi mất tiêu.” User VN có lý do để không tin tưởng. Cái app giao đồ ăn cho người ăn chay kia đã “rửa tội” bằng cách nào? Founder kể: team fix hết bug, app chạy tốt, nhưng số lượng download sau vụ bóc phốt không bao giờ phục hồi về mức trước. Cái tên brand đã bị gắn với “app lỗi” trong tâm trí một cộng đồng 80K người — và không có budget quảng cáo nào đủ để ghi đè ký ức đó.

Lý do 2: “Launch and ghost” bệnh đặc thù của startup VN

Có một biến thể của cái bệnh MVP mà mình thấy rất nhiều ở VN, và nó nguy hiểm hơn cả việc launch sản phẩm lỗi: launch xong im lặng khi bị chỉ trích. Nói bài mkt báo chí thì như rồng, nhưng phượng nhưng làm ăn thì mèo mửa.

Quy trình thường thấy:

1. Startup launch app với nhiều lỗi, vì cần learn nhanh.

2. Người dùng phàn nàn trên mạng.

3. Startup... không phản hồi. Hoặc phản hồi muộn 3-5 ngày. Hoặc phản hồi một cách defensive: “Cảm ơn mọi người đã góp ý, team đang cố gắng cải thiện.” Generic. Không có timeline. Không có acknowledgment cụ thể.

4. Cộng đồng đọc sự im lặng đó như một tín hiệu: “Họ không care.” Bóc phốt leo thang.

5. Startup sập.

Cái “launch and ghost” này không phải vì founder ác ý. Nó xuất phát từ việc team quá nhỏ, quá bận fix bug, không có người chuyên trách community management. Nhưng user không quan tâm đến lý do nội bộ của bạn. Họ chỉ thấy một cái sản phẩm lỗi và một đội ngũ biến mất. Nhưng tệ nhất nếu làm do founder thích chém gió thích mkt lấy tiếng. Thích phong trào startup lấy danh.

Reid Hoffman build LinkedIn với một đội team ngay từ ngày đầu đã có kinh nghiệm quản lý khủng hoảng, cộng với một hệ sinh thái Silicon Valley sẵn sàng bao dung cho sản phẩm đang trong giai đoạn beta. Đó là infrastructure mà đa phần startup VN không có.

Lý do 3: VN không phải thị trường “unknown” đây là thị trường hypercompetitive với kỳ vọng cao

Bất kỳ category nào bạn muốn làm ở VN năm 2026 giao đồ ăn, fintech, edtech, healthtech đều đã có ít nhất 2-3 sản phẩm chạy trước, trong đó có international players với UX cực kỳ mượt mà và budget marketing khổng lồ.

User VN đã dùng Grab, đã dùng ShopeeFood, đã dùng MoMo. Đến các app từ Bank còn chịu update thay đổi phù hợp khách hàng hơn các nước hiện đại top đầu thế giới. Kỳ vọng baseline của họ không còn là “app chạy được là tốt” nữa. Baseline của họ là Grab level, Tele... Bất kỳ sản phẩm nào xuất hiện sau đó đều bị so sánh với Grab.

Bạn launch một cái app giao đồ chay mà order bị nhầm địa chỉ, push notification bắn loạn, thì user không nghĩ “ồ startup mới đang học.” Họ nghĩ “tại sao mình không dùng Grab cho xong?”

MVP tệ chỉ hoạt động khi không có sản phẩm nào tốt hơn để so sánh. Khi thị trường đã bão hòa với alternatives tốt hơn, bạn không có quyền tệ. Bạn phải ra sân với ít nhất ngang bằng chất lượng của đối thủ dù scope của bạn hẹp hơn nhiều.

The Patch: Nên có thể thử nghiệm việc chuyển SLC Không phải khai tử MVP,Chỉ mà là nâng chuẩn.

(Đây là chỗ mình sẽ nói rõ: mình không bảo bỏ hẳn tư duy lean/MVP. Mình bảo chúng ta cần một phiên bản nâng cấp cho thị trường VN.)

Mình để xuất các nâng chuẩn cụ thể như sau …

Hãy bấm “Theo dõi” để đọc đầy đủ
về nội dung còn lại miễn phí nhé.

Want to see the rest of this awesome Post ?
Just hit that subscribe button for free to unlock the full post right now!

Subscribe now

T.D,
T7.2026

Hiểu khách hàng là bước đầu tiên. Mọi cuốn sách PM trên đời đều mở đầu bằng câu này. Nhưng chưa cuốn nào nói cho bạn biết: vẽ ra một nhân vật hư cấu có tên, có ảnh stock, có quote giả rồi dán lên tường phòng họp thì hiểu được cái gì?

Có thể ở đâu đó có một PM mới nhận việc ở một startup fintech tại Quận 7. Tuần đầu, sếp bảo: “Em research đi, vẽ User Persona cho sản phẩm mới.”

Hai tuần sau, PM trình bày một bộ Persona 4 nhân vật hoành tráng:

• Chị Hạnh, 28 tuổi. Marketing Executive. Thu nhập 18 triệu/tháng. Thích nghe nhạc indie, hay uống cà phê specialty, chạy bộ vào buổi sáng.

  • Quote: “Mình muốn quản lý tài chính cá nhân tốt hơn.”

• Anh Minh, 35 tuổi. Team Lead IT. Thích đọc TechCrunch, Tinh Tế. Có 2 con nhỏ.

  • Quote: “Mình cần một app đơn giản để theo dõi chi tiêu gia đình.”

• Bé Tú, 22 tuổi. Fresh graduate. Lương 10 triệu. Dùng iPhone cũ.

  • Quote: “Mình muốn tiết kiệm nhưng không biết bắt đầu từ đâu.”

• Cô Lan, 45 tuổi. Chủ tiệm tạp hóa ở Bình Dương. Dùng Samsung J7.

  • Quote: “Mình chỉ cần biết hôm nay lãi hay lỗ.”

Mỗi Persona có ảnh stock đẹp, infographic bắt mắt, pain points liệt kê gọn ghẽ. Trình bày xong, cả phòng vỗ tay.

CEO nhìn 10 giây. Rồi hỏi đúng một câu:

OK. Bốn người này, ai sẵn sàng trả 49K/tháng cho app mình? Và tại sao?

Im lặng.

PM ấp úng: “Dạ... em cần research thêm ạ.”

CEO gật: “Vậy 2 tuần vừa rồi em research cái gì?”

PM dành hàng tuần trời vẽ Persona, trình bày hoành tráng, rồi file Slide đó nằm chết dí trong Google Drive. Không ai mở lại. Không ai ra quyết định product dựa trên chị Hạnh thích nhạc indie.

Mình gọi hiện tượng này là Persona Theater anh em ruột của Dashboard Theater và Agile Theater mà chúng ta đã thử nhìn nhận ở các tập trước. Cùng một bệnh: làm để trông cho có, không phải để dùng.

Subscribe now

The Theory: Alan Cooper và giấc mơ thiết kế cho con người cụ thể.

User Persona ra đời từ thập niên 90, cha đẻ là Alan Cooper một trong những người tiên phong về Interaction Design. Ý tưởng gốc rất hay: thay vì thiết kế cho user nói chung một khái niệm có thể chung chung, mơ hồ, hãy tạo ra một nhân vật cụ thể dựa trên research thực tế, rồi thiết kế mọi thứ xoay quanh nhu cầu của nhân vật đó.

Nguyên bản, Cooper yêu cầu Persona phải được xây dựng từ ethnographic research nghiên cứu thực địa, quan sát hành vi thật, phỏng vấn sâu. Persona không phải tưởng tượng ra. Nó phải là bức chân dung chắt lọc từ hàng chục cuộc trò chuyện thật với người thật.

Rồi từ cái ý tưởng thanh lịch đó, ngành PM biến nó thành một quy trình công nghiệp. Product School dạy. Reforge dạy. Bootcamp PM, Google PM online nào cũng có một module Cách vẽ User Persona. Template đầy trên Notion, Miro, Figma. Bạn chỉ cần fill vào ô: Tên, tuổi, nghề nghiệp, sở thích, pain points, goals. Xong. Chụp screenshot. Dán lên tường.

Ở Google, Facebook nơi có hàng tỷ data points và team research hàng trăm người Persona có thể hoạt động vì nó được xây trên nền tảng data cực kỳ dày. Nhưng khi PM VN ngồi trong phòng họp, không có budget research, không có data team, và nghiên cứu user bằng việc hỏi 5 người bạn thân xem họ có dùng app này không thì cái Persona vẽ ra thực chất là fan fiction. Mà đáng lưu tâm hơn PM không nhiều người có Skill Research đúng nghĩa. Research đúng cũng cần có chuyên môn đấy nhé.

Bạn không đang mô tả khách hàng thật. Bạn đang viết tiểu thuyết.

The Breaking Point: 3 cái bẫy của Persona ở thị trường Việt Nam

Bẫy 1: Persona trả lời “Who” nhưng né “How Much”

Đây là cái bẫy chết người nhất.

Chị Hạnh, 28 tuổi, Marketing Executive, thích indie. OK. Vậy chị Hạnh có sẵn sàng bỏ 49K/tháng cho app quản lý tài chính không? Hay chị ấy sẽ dùng bản free rồi lướt qua feature premium mà không bao giờ upgrade? Persona không trả lời được câu này.

Ở Mỹ, câu hỏi “Who” quan trọng vì sức mua purchasing power đã ở mức đủ cao. Một developer Mỹ lương $150K/năm quẹt thẻ $10/tháng cho Notion mà không cần suy nghĩ. Vấn đề là tìm đúng người, thiết kế đúng trải nghiệm. “Who” giải quyết được 80% bài toán.

Ở VN? Sức mua thấp hơn 10-15 lần. Willingness to pay sự sẵn sàng chi trả gần đáy. User VN cài 3-4 app cùng loại để so giá, dùng bản free mãi mãi, hack mọi thứ có thể hack. Trong bối cảnh này, biết “Who” mà không biết “How Much” thì giống như biết địch đóng quân ở đâu mà không biết quân số bao nhiêu vô dụng.

CEO hỏi: “Khách hàng của mình là ai?” PM trả lời tự tin: “Chị Hạnh, 28 tuổi, thích indie!” CEO hỏi tiếp: “Chị Hạnh sẽ trả bao nhiêu?” PM: “Ờ...”

Cái “Ờ” đó tốn 2 tuần đấy nhé.

Bẫy 2: User ≠ Buyer và Persona chỉ vẽ User

Đây là bẫy kinh điển trong B2B mà PM VN gần như không bao giờ nhắc tới.

Ở B2B SaaS, người dùng sản phẩm hàng ngày (User) và người quyết định mua (Buyer) thường là hai người khác nhau. User là anh developer muốn tool chạy nhanh. Buyer là chị Procurement hoặc anh Director người cầm ngân sách, người ký hợp đồng, người quan tâm đến ROI và compliance chứ không quan tâm UI đẹp hay xấu.

Cooper’s Persona được thiết kế cho Interaction Design tức là cho User. Nó giúp designer biết phải đặt nút ở đâu, flow nào mượt. Nhưng nó hoàn toàn mù lòa trước Buying Committee cái nhóm 3-5 người gồm User, Influencer, Blocker, và Economic Buyer mà bạn phải chinh phục để chốt deal.

Ở VN, vấn đề này nặng gấp bội với cái quy trình 6 bước mua software ở doanh nghiệp VN. Bạn vẽ Persona cho “anh Minh, 35 tuổi, Team Lead IT, thích TechCrunch.” Anh Minh thích sản phẩm của bạn. Anh Minh demo cho team xong ai cũng khen. Nhưng chị Hà Director phòng Mua hàng yêu cầu 3 bảng báo giá từ 3 vendor. Anh Tuấn CFO gạt phắt vì năm nay không có budget cho software mới. Và ông Hùng CEO muốn gặp mặt Sales trực tiếp vì anh chưa tin cái app nào mà không gặp người.

Cái Persona đẹp đẽ của anh Minh không giúp gì ở đây. Vì anh Minh không phải người mở ví.

Bẫy 3: Persona là ảnh tĩnh trong thị trường động

Persona vẽ xong là đóng băng chị Hạnh mãi mãi 28 tuổi, mãi mãi thích indie, mãi mãi thu nhập 18 triệu. Nhưng thị trường VN thay đổi với tốc độ kinh hoàng.

Năm 2024, Gen Z đang chơi TikTok Shop. Năm 2025, TikTok Shop bị siết nhưng 2026 Tiktok Shop bá đạo ăn gần hết thị phần ở VN. Năm 2027 có khi AI agent bắt đầu mua hàng thay con người. Hành vi tiêu dùng thay đổi theo quý, không theo năm. Cái Persona bạn vẽ tháng 1 đến tháng 6 đã là bức chân dung của một người không còn tồn tại.

Và đây là chỗ mà nhiều team mắc sai lầm: họ vẽ Persona một lần, dán lên tường, rồi coi đó là tài liệu reference cho cả năm. Không update. Không validate lại. Vì đã research rồi mà, đọc lại đi. Persona trở thành tượng đài đẹp, uy nghiêm, và hoàn toàn vô dụng.

Mình nhớ có lần nghe về một startup edtech, team vẫn đang dùng Persona vẽ từ năm trước khi Covid vẫn còn là yếu tố ảnh hưởng lớn đến hành vi học online. Năm sau đó mọi người quay lại offline hết rồi mà cái Persona vẫn ghi Pain point: không có chỗ học online chất lượng, khỉ gió giờ AI còn kéo cả việc học Online ít đi chứ đừng nói không có. Mình hỏi: “Cái Persona này lần cuối update khi nào?” Im lặng. “Vậy các em đang build sản phẩm cho khách hàng của năm ngoái.”

Rồi, nãy giờ đập nhiều quá. Nhưng mình phải nói rõ: mình nhắc lại không bỏ Persona. Ý tưởng gốc của Cooper thiết kế cho con người cụ thể thay vì ai cũng được là đúng. Cái sai là cách chúng ta thực hiện nó ở VN: copy template, fill thông tin bịa, rồi gọi đó là “User Research.”

Giống như Agile triết lý đúng, thực thi sai, kết quả thành kịch.

The Patch: Demand-Side Persona Vẽ bằng tiền, không vẽ bằng sở thích

Mình đề xuất một cách tiếp cận khác mà mình gọi là Demand-Side Persona” persona xây dựng từ phía cầu (demand), tập trung vào 3 trụ cột: Money (Tiền), Job (Công việc cần làm), và Trigger (Điểm kích hoạt mua hàng). Không cần có ảnh stock. Không có sở thích. Không có quote fake tự bịa.

Theo mình 3 cách quan trọng sẽ là.

T.D
T7.2026

Kỷ nguyên nhồi nhét tính năng để ép user ở lại đã chết. Sắp tới là thời đại của app dùng 1 lần ? Thay vì cưỡng lại nó, hãy học cách sống chung.

Tuần trước, mình lại có dịp setup với anh Tuấn Anh cựu Giám đốc điều hành Grab Việt Nam, hiện đang là Founder của Alpha Asimov. Câu chuyện của những người làm product lâu năm thường hiếm khi xoay quanh những framework đao to búa lớn. Để chia sẽ với đội Product Leader trong cty.

Trong suốt buổi nói chuyện, có một ý mà anh Tuấn Anh nhắc đi nhắc lại khiến mình phải suy nghĩ rất nhiều: “Phải quyết định các thứ hiệu quả hơn, làm cách nào cũng được nhưng dứt khoát phải rẻ hơn.”

Nghe thì có vẻ hiển nhiên và câu truyện này cũng không khác việc nhanh của Quang với The Founder’s Lens #1 chỉ là 2 góc nhìn, đúng không? Khái niệm rẻ hơn đang bị hiểu lầm tai hại là làm sản phẩm nhôm nhựa hơn không hẳn đúng rẻ hơn đc hiểu đủ gọn đủ đơn giản để có giá rẻ. Đa số startup Việt Nam vẫn mang cái mindset rẻ hơn sẽ tuyển người chất lượng trẻ hơn hoặc dùng ai nhiều hơn thay con người. Bài viết thứ hai trong series The Founder’s Lens này, mình muốn bóc tách lăng kính của một cựu lãnh đạo Big Tech về quyền lực của Productivity, câu chuyện app dùng 1 lần, và bài toán tìm kiếm tệp user cuồng.

Tìm hiểu thêm về Alpha Asimov

Lời nguyền Đông Quân và Vũ khí của Solo Founder

Hãy nhìn thẳng vào sự thật: Từ góc nhìn anh TA. Đông người giờ không hẳn là lợi thế.

Trong kỷ nguyên AI và các công cụ AI Coding / Design … lên ngôi, có quá nhiều cơ hội cho các dạng 1 người làm (Solo Founder). Khả năng leverage công nghệ đã xóa nhòa khoảng cách về nhân lực.

Hãy nhìn Midjourney. Năm 2023, họ tạo ra 200 triệu USD doanh thu chỉ với một đội ngũ vỏn vẹn khoảng 40 người. Hay Pieter Levels gã Solo Founder khét tiếng đằng sau hàng loạt micro-SaaS (như PhotoAI, InteriorAI) đang bỏ túi hàng triệu đô mỗi năm mà chẳng cần tuyển thêm ai. User cuối cùng không hề quan tâm app của bạn được code bởi một tập đoàn ngàn tỷ hay bởi một gã thợ code đang cày cuốc sấp mặt ở quán cà phê. Cái họ quan tâm là: Nó có giải quyết đúng cái tôi cần ngay lúc này không?

Khi bạn có một team quá đông, mọi quyết định đều trở nên đắt đỏ. Bạn phải họp hành, bạn phải align, bạn phải vẽ spec, rồi QA test tới test lui. Trong khi đó, một Solo Founder với Productivity tối đa có thể thử nghiệm, gãy, và đập đi làm lại 5 lần với chi phí gần như bằng không.

Chìa khóa ở đây không chỉ là quyết định đúng vì chả ai đoán đúng thị trường 100%, mà là làm sao để những quyết định hiệu quả hơn và rẻ hơn. Thử sai là tất yếu, nhưng cái giá của việc thử sai sẽ quyết định bạn sống hay chết trước khi tìm thấy Product-Market Fit.

Câu chuyên vấn đề lớn và Tệp User Cuồng

Một trong những cái bẫy nguy hiểm nhất của PM và Founder là đâm đầu vào giải quyết những bài toán lớn của toàn nhân loại, nhưng lại thất bại trong việc tạo ra một nhóm người dùng cuồng sản phẩm (fanatical users).

Ví dụ, hãy nhìn vào bài toán chống lừa đảo trực tuyến (Anti-scam). Scam rõ ràng là một vấn nạn nhức nhối, là vấn đề của tất cả mọi người. Chẳng ai muốn bị lừa cả. Vậy thì thị trường quá lớn, đúng không? Nhưng nếu bạn chỉ làm một công cụ cảnh báo chung chung, user tải về rồi... để đó.

Một vấn đề lớn của số đông chưa chắc đã tạo ra user cuồng.

Để sống sót, sản phẩm của bạn phải có một điểm chạm cực kỳ bén vào một nhóm nhỏ. Lấy Superhuman làm một minh chứng kinh điển trên thế giới. Email là vấn đề của tất cả mọi người, và Gmail giải quyết nó hoàn toàn miễn phí. Nhưng Superhuman chọn đánh vào một ngách cực nhỏ: Những vị sếp, những Founder bận rộn thèm khát tốc độ. Họ thu phí tận 30 USD/tháng cho một cái app đọc mail. Kết quả? Nhóm nhỏ này phát cuồng vì nó tiết kiệm cho họ hàng giờ đồng hồ mỗi tuần.

Đánh trúng một ngách nhỏ và làm họ phát cuồng như Superhuman đã làm còn hơn là cố làm hài lòng tất cả mọi người bằng một giải pháp làng nhàng miễn phí.

Nguyên lý này không hề mới, nhưng khi đứng trước những bài toán vĩ mô mang tính xã hội, chúng ta rất dễ ngáo và quên mất nó và gì cũng muốn. App Tốt nhất, App đẹp nhất, App xịn nhất …

Nghệ thuật Cắm rễ và Sự Trung Thực Tàn Nhẫn

Làm sao để biết mình có đang đi đúng hướng hay không? Câu trả lời chắc chắn là: Honest Reflection.

Rất nhiều Founder và PM luôn tự hào rằng mình có mindset mở, “willing to learn”, “willing to adapt”. Nhưng cái quan trọng hơn vạn lần sự hiếu học bề nổi, là khả năng nhìn nhận thẳng thắn vấn đề của bản thân đang mục nát ở đâu.

Bạn phải trung thực đến tàn nhẫn với hai câu hỏi:

1. User có thực sự có cái nhu cầu mà mình ảo tưởng là họ có hay không?

2. Sản phẩm có thực sự đang tiến bộ lên hay không?

Ở vế thứ hai, anh Tuấn Anh có một hình ảnh so sánh cực kỳ thấm: So sánh với quá trình ươm mầm 1 hạt cây mới. Đại ý :

"Sản phẩm có thể chưa tăng trưởng rầm rộ (chưa nảy mầm cao rõ ràng), nhưng bạn phải quan sát xem nó có đang thực sự tạo ra giá trị để giữ chân người dùng hay không (đang mọc rễ)."

Khi build một product mới, những tháng đầu tiên metrics có thể lẹt đẹt, MAU/DAU nhìn phát chán. Đó là bề mặt chưa nảy mầm. Nhưng nếu bạn deep dive vào data, bạn phải thấy được những tín hiệu ngầm weak signals chứng tỏ sản phẩm đang mọc rễ. Có thể là một nhóm nhỏ user quay lại liên tục High Retention ở một cohort cụ thể, hoặc thời gian họ tương tác với một tính năng cốt lõi đang tăng lên.

Nếu rễ không mọc mà bạn cứ đổ thêm tiền marketing để đắp đất che đậy, cái cây đó sớm muộn cũng chết khô.

⚡ Cẩm nang sinh tồn: Đối mặt với App dùng 1 lần.

Từ những quan sát trên, góc nhìn của anh Tuấn Anh chốt lại một insight khá ngược ngạo nhưng mang tính thời đại: Sắp tới là thời đại của app dùng 1 lần.

Người dùng ngày càng lười, dung lượng sự chú ý attention span ngày càng ngắn. Khả năng cao là bạn không thể cưỡng lại được luồng sóng này. Vậy theo góc nhìn của mình thay vì nhồi nhét cả chục tính năng gamification rườm rà hòng ép user phải mở app bạn mỗi ngày trong vô vọng, hãy thay đổi lăng kính:

1. Nhìn nhận & Chấp nhận nó

Đừng ảo tưởng mình sẽ là Super App tiếp theo của Đông Nam Á. Nếu sản phẩm của bạn bản chất là một công cụ tiện ích utility, hãy chấp nhận việc user xài xong rồi xóa, hoặc cất vào một xó. Đừng tốn nguồn lực bào mòn team Dev để build những tính năng giữ chân vô nghĩa. Thậm chí, giới VC toàn cầu hiện nay cũng đang bắt đầu rẽ hướng đánh giá cao các công cụ Micro-SaaS hoặc AI làm đúng 1 việc nhưng xuất sắc, thay vì các bánh vẽ nền tảng platform cồng kềnh.

2. Tìm cách sống chung với lũ

Nếu biết chắc user chỉ dùng app 1 lần (ví dụ: app sửa ảnh AI, app xóa background), bài toán không phải là tăng DAU. Theo một góc nhìn độc lập từ các nhà phân tích hành vi người dùng áp dụng framework Jobs-To-Be-Done, khi user chỉ có nhu cầu xong việc rồi đi, bài toán của bạn là làm sao để thu được giá trị ngay trong lần dùng duy nhất đó chốt sale, gắn quảng cáo, viral loop bắt họ share thành quả ra mạng xã hội. Bạn tối ưu hóa cho cú hit đầu tiên, làm nó mượt mà và xịn đến mức họ sẵn sàng trả tiền ngay lập tức, hoặc ít nhất là lan truyền nó.

3. Tối ưu chi phí quyết định

Quay lại câu chuyện đầu tiên: “Làm cách nào cũng được, nhưng phải rẻ hơn”. Nếu vòng đời của app ngắn, chi phí sản xuất cũng phải cực kỳ rẻ và ra quyết định cực kỳ nhanh. Bạn không thể mang quy trình waterfall 6 tháng của tập đoàn vào build một cái app dùng 1 lần được. Gãy là chắc chắn.

Lăng kính cho Kỷ nguyên mới

Nhìn lại toàn bộ cuộc trò chuyện với anh Tuấn Anh, chúng ta có thể xâu chuỗi lại một hệ tư tưởng (mental model) cực kỳ sắc bén dành cho những ai đang làm Product theo góc nhìn của mình như sau:

Sự trỗi dậy của “App dùng 1 lần” không phải là một trào lưu ngắn hạn để chúng ta bĩu môi chê bai. Nó là bản án tử hình cho những cỗ máy cồng kềnh lấy số lượng nhân sự ra làm lợi thế cạnh tranh. Khi user chỉ cần “đúng một thứ” và sẵn sàng vứt bỏ app của bạn ngay sau khi xong việc, vòng đời sản phẩm bị thu hẹp lại tới mức cực đoan.

Đứng trước sự tàn nhẫn đó, bạn chỉ có 3 vũ khí để bấu víu:

1. Quyền lực của Productivity: Đừng tự hào vì bạn có thể làm mọi thứ. Hãy tự hào vì bạn có khả năng đưa ra những quyết định thử sai hiệu quả hơn và rẻ hơn bất kỳ ai. Trong cuộc đua này, một Solo Founder được trang bị tận răng công cụ AI hoàn toàn có thể lấy mạng một startup 50 người đang bị mắc kẹt trong mớ bùng nhùng của những cuộc họp.

2. Sự tỉnh táo trước Vấn đề lớn: Hãy ngừng ảo tưởng về việc giải cứu thế giới bằng một nền tảng (platform) phục vụ tất cả mọi người. Thay vào đó, hãy ám ảnh với việc tìm ra một nhóm nhỏ — những người sẽ phát cuồng vì cái đinh ốc nhỏ xíu mà bạn vừa chế tạo ra.

3. Nghệ thuật Tự Soi Gương (Honest Reflection): “Willing to learn” Sẵn sàng học hỏi là câu cửa miệng sáo rỗng nhất của các Founder. Cái khó nhất không phải là học cái mới, mà là đủ trung thực để thừa nhận nhu cầu mình đang giải quyết chỉ là ảo tưởng, và đủ dũng khí để nhìn thẳng xuống bùn sâu xem: Sản phẩm của mình có thực sự đang đâm rễ, hay chỉ là một cành cây cắm hờ trên mặt đất để báo cáo sếp?

Thị trường không bao giờ nói dối. Kỷ nguyên mới đã gõ cửa và nó không dành cho những kẻ lấy đông quân ra dọa nạt. Nó là sân chơi của năng suất, của khả năng cắm rễ thật sâu vào một ngách nhỏ xíu, dù bên ngoài nhìn vào tưởng chừng như chỉ là một cái “app dùng 1 lần”.

Bạn đã sẵn sàng soi gương chưa?

T.D,

T7.2026

P/s : Seri Bài viết của the-founders-lens là bài viết dạng tổng hợp được trích dẫn từ các chia sẽ cá nhân trong phạm vi buổi chia sẽ cho nội bộ team mình và đã được xác nhận chia sẽ lên Blog. Các trích dẫn view của người nêu tên chia sẽ một phần thì cần/nên có xác nhận để tránh các góc nhìn sai lệch. Bài viết sử dụng cho mục tiêu tạo ra góc nhìn thực tế cho cộng đồng Product Việt Nam.

Câu chuyện bé A đợt này năng nổ, present trong họp management team rất tự tin, chốt roadmap đâu ra đấy. Anh định đợt review này cho bạn ấy lên Senior. Còn cậu B (Senior hiện tại), anh thấy dạo này làm việc hơi chậm, lúc nào giao dự án cũng vạch ra một đống rủi ro rồi đòi test thêm, ko được xông xáo cho lắm.

Bạn đã từng nghe nhận xét như vậy trong kỳ Performance Review Chưa? Hay bạn tự nghĩ như thế bao giờ chưa ?
Nếu có có thể đã dính một cái bẫy tâm lý kinh điển mà hầu hết các team Product/Tech ở Việt Nam đang mắc phải: Dunning-Kruger Effect.

Hiểu đơn giản, hiệu ứng Dunning-Kruger là khi một người biết rất ít về một vấn đề, nhưng lại cực kỳ tự tin vào khả năng của mình. Ngược lại, những người có kinh nghiệm sâu sắc lại thường đánh giá thấp bản thân và cực kỳ thận trọng vì họ biết rõ những điểm mù của hệ thống.

Vấn đề ko nằm ở tâm lý cá nhân, vấn đề nằm ở việc hệ thống đánh giá của chúng ta đang vô tình tưởng thưởng cho sự tự tin rỗng, và trừng phạt sự cẩn trọng.

Bức tranh thực tế có thể như này: Trong cuộc họp Review Roadmap.

Hãy lấy một ví dụ thực tế cực kỳ phổ biến. Công ty định launch một tính năng thanh toán mới tích hợp với bên thứ ba.

• Bạn Junior PM Người đang ở đỉnh sự tự tin: Bật slide lên, dõng dạc tuyên bố “Tính năng này làm cực dễ, Dev bảo 2 tuần là xong. Em cam kết ra mắt vào ngày 15, đem về tăng trưởng 20% conversion rate.” Dù thống kê của Y Combinator cho thấy chưa tới 5% các A/B test thực sự mang lại tăng trưởng trên 10%. Ban Giám đốc vỗ tay rào rào. “Đấy, tuổi trẻ phải thế, can đảm, dám nghĩ dám làm!” Không chỉ Junior PM mà có thể cả 1 Senior PM mới từ tổ chức khác vào khi chưa hiểu hết vấn đề cũng có thể nói ý chang vậy.

• Bạn Senior PM. Người đang ở “Thung lũng của sự tuyệt vọng” : Cau mày suy nghĩ rồi phát biểu: “Chưa được đâu anh. Tích hợp bên thứ ba thường hay bị miss webhook khi rớt mạng, rồi cả tỉ thứ ko chắc chắn. Mình phải thiết kế thêm cơ chế xyz, rồi phải test rollback tiền nếu fail giữa chừng. Nhanh nhất cũng phải 4 tuần mới an toàn.” Ban Giám đốc thở dài: “Sao em lúc nào cũng làm phức tạp vấn đề lên thế? Mình phải Agile lên chứ!”

Kết quả? Đến ngày 15, tính năng của bạn Junior ra mắt. Nó crash tanh bành. Tiền user bị trừ nhưng đơn hàng không ghi nhận. Nhưng trớ trêu thay, ai là người phải thức đêm fix bug và dọn dẹp đống rác đó? Chính là bạn Senior. Và đến cuối năm, ai là người được khen vì “đã có tinh thần xông pha dấn thân”? Bạn Junior.

Hệ quả tàn phá P&L âm thầm.

Khi một tổ chức liên tục ưu ái những người “nói to, cam kết bừa” và gạt đi những lời cảnh báo của người có chuyên môn sâu, hệ quả không chỉ dừng lại ở cảm xúc bất mãn. Nó đánh thẳng vào P&L.

1. Tech Debt phình to: Những tính năng được push nhanh gọn lẹ thường là những tính năng xây trên một cái móng rỗng. Công ty tốn 2 tuần để launch, nhưng mất 6 tháng để fix bug và maintain. Chi phí bảo trì đội lên gấp bội.

2. Chảy máu chất xám: Những nhân sự Senior những người thực sự hiểu hệ thống và bảo vệ nó khỏi sụp đổ sẽ nản chí và rời đi. Bạn sẽ chỉ còn lại một đội ngũ toàn những người “chém gió” rất hay nhưng đụng tay vào là gãy.

3. Mất niềm tin từ Khách hàng: User không quan tâm bạn Agile thế nào hay team bạn xông xáo ra sao. Họ chỉ biết là app bị lỗi lúc họ cần nhất.

Giải pháp nên là: Đo lường bằng Impact thực chất.

Với tư cách là một người làm Leadership, làm sao để phá vỡ vòng lặp độc hại này?

Thứ nhất, đừng đánh giá PM qua kỹ năng thuyết trình. Kỹ năng present tốt là một điểm cộng, nhưng không phải là cốt lõi. Cốt lõi của một PM là khả năng ra quyết định dựa trên dữ liệu và quản trị rủi ro. Hãy hỏi họ: “Em đã cân nhắc những rủi ro nào? Nếu plan A fail thì plan B là gì?” Người trả lời được câu này mới là người thực sự hiểu sản phẩm.

Thứ hai, tách biệt giữa “Xông xáo” và “Liều lĩnh”. Khuyến khích team thử nghiệm nhanh, nhưng phải có ranh giới. Launch một cái landing page marketing lỗi một tí thì không sao. Nhưng launch một tính năng liên quan đến tiền bạc, dữ liệu người dùng mà không có cơ chế rollback thì đó là sự thiếu trách nhiệm, không phải là sự dấn thân.

Thứ ba, ghi nhận những “Người hùng thầm lặng”. Hãy đưa việc “Phát hiện và ngăn chặn rủi ro” trở thành một KPI quan trọng. Khi một bạn Senior chỉ ra được một lỗ hổng chí mạng trước khi code, hãy khen ngợi bạn ấy công khai, giống như cách bạn khen một người chốt được hợp đồng lớn. Phòng bệnh bao giờ cũng rẻ hơn chữa bệnh.

Tổ chức của chúng ta cần những tiếng nói phản biện. Đừng để Dunning-Kruger giết chết sự tử tế và thận trọng của những người kỹ sư lành nghề.

T.D,

T7.2026

Tương lai không thuộc về PM biết viết PRD đẹp nhất. Nó thuộc về PM biết điều khiển 5 cái AI agent chạy song song mà không đứa nào đâm vào đứa nào ???

Chuyện này xảy ra dạo gần đây thường hay như thế này.

Một bạn PM mid-level được sếp mình vừa cho xem cái demo. Con AI agent của team Data viết xong cái PRD cho Data build Dashboard trong 4 phút.Chỉ Bốn phút.Trong khi việc đó bình thường viết mất 2 ngày. Sếp bạn nhìn bạn rồi cười. Từ đó bạn không ngủ được.

Nhưng bạn nên nghĩ theo hướng sau

“Con AI viết đúng không?”

“Đúng tầm 70-80%. Phần còn lại cần sửa.”

“Vậy thực sự bạn mất bao lâu để sửa cái 20-30% còn lại?”

“...2 tiếng.”

“Tổng cộng: 4 phút AI + 2 tiếng em sửa = nửa ngày. So với 2 ngày trước đó. Vậy rõ ràng bạn không bị thay thế. Em được nâng cấp đấy chứ”

Rồi bạn lại nghĩ: “Nhưng sếp có nghĩ mình được nâng cấp không ? ”

Đó là bài toán thật sự. Không phải AI có thay thế PM được không mà là sếp bạn có nghĩ AI thay thế PM được không. Và trong nhiều trường hợp, nhận thức quan trọng hơn thực tế bạn khó chứng minh.

Chín tập Reality Check. Chúng ta đã đi một chặng đường dài từ PMF ảo tưởng, qua Retention gãy gánh, sếp HiPPO, Growth đốt tiền, Agile Cosplay, OKR Karaoke, PLG Fundamentalism, Dashboard Theater mỗi bài đập một ảo tưởng lớn hoặc một sai lầm nhỏ tuỳ bạn nghĩ và ứng dụng vào thực tế công việc của bạn ở tổ chức.

Bài hôm nay thử đập vào cái ảo tưởng theo mình khá lớn: vai trò PM bản thân PM nghĩ gì ?

Nếu AI làm được 80% công việc hàng ngày của PM viết PRD, tóm tắt meeting, generate test case, phân tích data, draft email cho stakeholder, thậm chí suggest priority cho backlog thì PM còn tồn tại để làm gì?

Mình sẽ nói thẳng: Nếu bạn là Process PM người mà công việc chủ yếu là viết Jira ticket, chạy ceremony, update status thì bạn có khoảng 12-18 tháng trước khi cỗ máy làm việc đó rẻ hơn và nhanh hơn bạn. Mình đã cảnh báo điều này từ bài Process PM vs Specialist PM hồi tháng 3. Bây giờ nó không còn là cảnh báo. Nó đang xảy ra.

Nhưng và đây là cái “nhưng” quan trọng nhất bài viết này nếu bạn hiểu đúng vai trò mới của PM trong thời đại AI, bạn không chỉ sống sót. Bạn sẽ mạnh hơn bao giờ hết.

The Theory: PM như Mini CEO của sản phẩm phiên bản 2020

Hãy quay lại định nghĩa cũ một chút. Trong suốt thập niên 2010-2020, PM được dạy rằng mình là “CEO of the product” mình đã có 1 bài nói vụ này để nói về cái ảo tưởng này rồi. Công việc cốt lõi gồm:

1. Discovery: Research user, tìm pain point, xác định opportunity.

2. Definition: Viết PRD, user stories, specs.

3. Delivery: Quản lý backlog, chạy sprint, coordinate team, đảm bảo ship đúng hạn.

4. Data: Đo lường impact, phân tích metrics, report.

Bốn cái D. Nghe đầy đủ. Nhưng hãy nhìn kỹ: trong 4 cái này, AI agent năm 2026 đã làm được bao nhiêu?

• Definition (Viết PRD/specs): AI viết PRD dựa trên input từ meeting notes và user feedback — đạt 70-80% chất lượng, PM sửa 20-30% còn lại.

  • ✅ AI thay được phần lớn. Nhưng core value thì thường không chốt được.

  • 🔥 Nhưng Lựa chọn ưu tiên / deep về trải nghiệm là cái bạn phải làm tốt.

• Delivery (Quản lý backlog, update status): AI agent tự sync Jira, tự generate sprint report, tự remind blocker.

  • ✅ AI thay hoàn toàn.

• Data (Phân tích metrics): AI tự query data, tự vẽ biểu đồ, tự detect anomaly.

  • ✅ AI thay phần lớn.

  • 🔥 Nhưng Lựa chọn làm gì và focus gì vẫn của bạn.

• Discovery (Research user, tìm insight): AI tóm tắt được interview transcript, tổng hợp survey. Nhưng... ngồi đối diện user, đọc ngôn ngữ cơ thể, cảm nhận sự do dự trong giọng nói, hỏi câu follow-up đúng lúc?

  • ❌ AI chưa thay được tất các là của bạn.

Vậy 3/4 cái D đang bị xâm lấn. Cái D còn lại Discovery ở level deep empathy là cái duy nhất hiện tại AI chưa chạm tới.

The Breaking Point: Prompt Jockey và sự ngáo của AI PM.

Thị trường lao động PM đang phản ứng theo hai thái cực, cả hai đều sai:

Thái cực 1: Phủ nhận. “AI chỉ là hype, PM vẫn cần, đừng lo.”

Đây là kiểu đà điểu chui đầu xuống cát. Mình gặp nhiều PM senior ở VN vẫn tin rằng công việc của mình an toàn vì PM cần soft skills mà AI không có. Đúng. Nhưng sếp bạn có biết phân biệt soft skills với hard skills không? Hay sếp bạn chỉ thấy: AI viết PRD trong 4 phút, em viết trong 2 ngày vậy tại sao tôi trả lương em 50-70 triệu/tháng?

Thái cực 2: Ngáo AI. “Mình sẽ trở thành AI Product Manager! Học prompt engineering! Tương lai là của mình!”

LinkedIn tràn ngập những title mới: AI Product Manager, Head of AI Product, PM for Generative AI. Nghe oai. Nhưng 90% trong số đó, khi mình hỏi sâu vào, công việc thực tế là: viết prompt và cook AI model và vẽ vời 1 số usecase AI vào sản phẩm, evaluate output, rồi copy-paste vào Doc để đẩy cho team làm.

Mình xin phép gọi đó là Prompt Jockey người cưỡi ngựa prompt mà tưởng mình là kỵ sĩ AI.

Biết viết prompt không phải là biết làm AI Product. Giống như biết lái xe không phải là biết thiết kế động cơ. Prompt engineering là kỹ năng cơ bản basic literacy nó sẽ sớm trở thành kỹ năng mà mọi người đều có, giống như biết dùng Google là kỹ năng mà mọi người đều có từ 2010. Nó không phải lợi thế cạnh tranh.

Vấn đề thật sự ở VN? PM không thiếu tool AI. PM thiếu khả năng nghĩ đúng về cách AI thay đổi bản chất công việc của mình. Họ vẫn đang suy nghĩ trong framework cũ: “Làm sao để dùng AI nhanh hơn?” thay vì “Nếu AI làm được 80% công việc cũ, thì 100% công việc MỚI của mình là gì?”

Mình đang build product ở lĩnh vực AI/Security, và hàng ngày team mình dùng AI agent cho mọi thứ: draft idea, viết doc, thậm chí suggest architecture decisions. Chúng ta không nên sợ AI và cá nhân mình tin AI sẽ giúp phát huy những kinh nghiệm tốt nhất trước giờ.

Mình sợ những PM không chịu thay đổi rồi một ngày wake up nhận thấy mình đã trở thành thừa thãi mà không hiểu tại sao.

The Patch: The Irreplaceable PM và 3 thứ máy KHÔNG làm thay bạn được

Đây không phải lý thuyết. Đây là bộ lọc mà mình tự dùng mỗi ngày để kiểm tra: “Cái mình đang làm, AI có thể làm thay không? Nếu có, mình nên dừng lại và làm cái khác.”

1. Navigate Organizational Politics : Vấn đề không muốn nói đến nhất nhưng nó là sự thật.

AI không biết rằng anh Head of Engineering đang giận sếp vì bị cắt headcount. AI không biết rằng chị Director Marketing đang lobby để team mình không bị merge. AI không biết rằng nếu bạn ship tính năng X trước tính năng Y anh Sales Lead sẽ hậm hực và ngầm phá hoại adoption.

Organizational politics thứ mà sách PM không dạy và AI không đọc được là kỹ năng sống còn. Biết khi nào nên push, khi nào nên lùi, khi nào cần đồng minh, khi nào nên im lặng. Đây là trò chơi con người thuần túy. Và ở Châu Á, nơi relationship-driven quan hệ là vua callback Tập #3 — kỹ năng này còn quan trọng gấp bội.

Nếu bạn giỏi navigate politics, bạn không thể bị thay thế. Vì AI không biết rằng cái email ok noted của sếp thật ra có nghĩa là tao không đồng ý nhưng tao chưa muốn nói thẳng. Nhưng hãy nhớ hãy dùng kỹ năng politics cho một mục tiêu duy nhất là giúp tổ chức hiệu quả và sản phẩm hiệu quả. Mọi kỹ thuật politics khác điều khiến bạn trở nên kém đi thay vì tập trung cho làm tốt công việc nó sẽ dành cho việc làm sao sống sót. Mà khi bạn tập trung cho sự sống sót thì những việc bạn làm ra thường tệ.

P/s nhỏ : Khi mọi cuộc trao đổi điều là politics thì là tổ chức bắt đầu không còn làm việc hiệu quả.

2. Thấu cảm với Cảm xúc hỗn loạn.

AI tổng hợp feedback tuyệt vời. AI phân tích sentiment analysis ngon lành. Nhưng AI không ngồi đối diện một bà mẹ 40 tuổi ở Bình Dương, nghe bà ấy kể rằng bà dùng app của bạn mỗi đêm lúc 11 giờ sau khi con ngủ vì đó là lúc duy nhất bà có cho bản thân mình. Và từ câu chuyện đó, nhận ra rằng notification lúc 8 giờ sáng giờ đưa con đi học là hoàn toàn sai thời điểm.

Deep empathy loại empathy mà bạn phải ngồi xuống, nhìn vào mắt, lắng nghe giọng nói run run không có AI nào gọi tên được được. Và PM nào bỏ kỹ năng này để ngồi optimize prompt thì đang bỏ vũ khí mạnh nhất của mình để làm thứ máy giỏi.

3. Đặt cược với sự bất định.

Pivot toàn bộ business model. Quyết định rút khỏi một thị trường. Chọn giữa 2 con đường chiến lược mà data nói 50-50. Đây là những quyết định Type 1 (callback Tập #8) cửa một chiều, không quay lại được.

AI có thể simulate 1000 kịch bản. Nhưng AI không chịu trách nhiệm. AI không đặt sự nghiệp, uy tín, và đội ngũ của mình lên bàn cược. Con người phải quyết. Con người phải chịu trách nhiệm.

Khả năng ra quyết định lớn dưới sự bất định và sống với hậu quả của quyết định đó là đặc quyền và gánh nặng của con người. AI advisor rất giỏi. Nhưng AI không bao giờ là người ký vào quyết định hay nói đùa AI ko ở Tù thay bạn, không xin lỗi được ae cộng sự ở bên cạnh bạn khi quyết định khiến tổ chức gặp rủi ro.

Vậy PM 2026 & 2027 phải biết thêm gì?

Ngoài 3 thứ không thể thay thế ở trên, có 3 kỹ năng mới mà PM cần trang bị ngay theo mình:

Thiết kế Đánh giá: Khi AI generate output, ai đánh giá output đó đúng hay sai? PM phải biết thiết kế bộ tiêu chí đánh giá cho AI không phải ở level output này có vẻ ổn mà ở level output này đạt 8/10 tiêu chí chất lượng, fail ở tiêu chí #3 và #7, cần iterate. Đó là kỹ năng Engineering PM không phải Prompt PM.

Context Engineering: AI giỏi đến mấy cũng ngu nếu bạn cho nó context sai. PM phải biết thiết kế context package tổng hợp user research, business constraints, technical limitations, competitive landscape thành bộ briefing chuẩn để agent hiểu đúng bài toán. Garbage in, garbage out. <Good: Context in, Best: Quality out>.

Guardrail Architecture: AI agent tự chạy, tự quyết. Nhưng nếu nó quyết sai ví dụ tự gửi email xin lỗi khách hàng khi không cần, hoặc tự thay đổi pricing page thì ai chịu? PM phải thiết kế hàng rào khi nào agent tự chạy được, khi nào phải dừng lại hỏi con người. Đó là PM dạng mới: không quản người, quản hệ thống agent.

Suốt 9 tập Reality Check trong hơn 2 tháng, từ PMF đến AI có một sợi chỉ đỏ xuyên suốt mà mình muốn bạn nhớ: mọi framework, mọi công cụ, mọi quy trình kể cả AI đều chỉ là phương tiện. Cái quyết định bạn là PM giỏi hay dở không phải là bạn biết bao nhiêu framework. Mà là bạn biết khi nào nên dùng, khi nào nên vứt, và khi nào nên tin vào trực giác đã được rèn giũa bằng hàng ngàn giờ ngồi với user thật, deal với sếp thật, và ship sản phẩm thật.

AI sẽ không giết nghề PM. Nhưng AI sẽ giết những PM không chịu tiến hóa.

Bạn thuộc loại nào?

T.D
T7.2026

Cẩm nang sinh tồn cho Product Manager.

Tốc độ không phải là việc bạn gõ code nhanh gấp đôi hay bắt team OT trắng đêm. Tốc độ thực sự là khả năng khai tử một tính năng thất bại trong vòng 5 phút, thay vì mất 5 tháng để cố cưu mang nó chỉ vì tiếc công.

Hôm trước, nhân dịp Quang vào HCM mình có setup cho team product leader ở VP tại Sài Gòn để anh em được giao lưu học hỏi nhiều thứ từ Quang, À Quang là Founder của Snapedit, FitRoom … một trong những startup AI hiếm hoi của Việt Nam tự tay build sản phẩm và đi global ngon ơ, thu hút hàng chục triệu người dùng trên toàn thế giới mà không cần những chiến dịch marketing đao to búa lớn.

Câu chuyện của chia sẽ xoay quanh một bài toán sống còn: Làm thế nào để một team nhỏ có thể sống sót và chiến thắng trong kỷ nguyên mà Big Tech ?

Tìm hiểu thêm về Snapedit : Link

Get SnapEdit mobile app

Quang Founder chia sẻ đội PM Leader của mình nhiều thứ có 1 câu Key rất đỉnh mình note lại một vài ý quan trọng “Lợi thế duy nhất của quốc gia này có thể xây dựng dc bây giờ là chữ nhanh thôi“ và “Nhưng nhanh nó là hệ quả muốn nhanh dc thì phải setup đúng Con người + automation with AI sắp xếp điều cần nghệ thuật cả“

Nhận định này đánh trúng phóc cái tử huyệt đang bào mòn không ít team product mình từng gặp suốt 15 năm qua kể cả thời kỳ mình ở Zalo, chuyển sang VinID, OneMount, hay đi tư vấn. Các bạn PM thường rất hăng máu khi vẽ spec, đẻ tính năng mới, nhưng lại yếu bóng vía và chùn tay khi phải nhấc kéo lên cắt phăng chính đứa con đẻ của mình. Sau buổi gặp Quang mình nghĩ sẽ viết tuyến bài mới này vì không dễ ae được nghe những chia sẽ từ các bạn founder Top 1 VN.

Bài viết mở màn cho Series The Founder’s Lens này, mình muốn cùng bạn mổ xẻ triết lý “Làm nhanh, Cắt nhanh” thứ vũ khí tối thượng của startup thời đại mới, và cách để bạn thoát khỏi cái bẫy của những tính năng Zombie.

Căn bệnh ung thư thầm lặng mang tên Tính năng Zombie.

Trong y học, zombie là những xác sống không có nhận thức nhưng vẫn di chuyển và ăn mòn người sống. Trong Product Management, Tính năng Zombie là những cái xác ngấp ngoải: metrics lẹt đẹt, user không thèm đụng tới hoặc lượng dùng cực thấp, nhưng nó vẫn sống nhăn răng trong app của bạn.

Tại sao chúng ta không giết chúng?

Câu trả lời nằm ở tâm lý học hành vi: Ảo tưởng chi phí chìm.

Cả team PM, Designer, và Dev đã cày sấp mặt ròng rã 3 tháng trời, OT liên tục để ship được tính năng đó lên store. Bây giờ bảo khai tử nó? PM sẽ thấy như công sức của mình đổ sông đổ bể, sợ sếp đánh giá năng lực. Dev thì xót xa vì đống code tâm huyết bị vứt vào sọt rác. Thế là chúng ta chặc lưỡi: “Thôi cứ để đấy, từ từ optimize sau”, “Hay tại mình chưa làm marketing mạnh?”, “Chắc tại UI/UX chưa tối ưu, để sửa lại tí xem sao”.

Nhắc chuyện này lại nhớ dạo còn chinh chiến ở những công ty scale bự, những trận cãi vã phòng họp chỉ để giành giật lại sự sống cho một đoạn code chết yểu diễn ra như cơm bữa. Nhiều khi biết tỏng là vớ vẫn không có số, nhưng lỡ hứa với sếp trên slide năm ngoái rồi nên đành cắn răng ôm vào.

Nhưng cái giá phải trả cho sự chần chừ này là vô cùng đắt đỏ. Những tính năng Zombie không nằm yên một chỗ. Chúng âm thầm hút cạn sinh lực của tổ chức:

• Gánh nặng bảo trì code: Mỗi lần refactor hệ thống, nâng cấp thư viện là Dev lại phải test lại đống code cũ kỹ đó.

• Làm nghẽn tiến độ QA: Đội Tester phải test đi test lại một tính năng không ai dùng để đảm bảo nó không làm sập app khi cập nhật.

• Tăng nợ UX (UX Debt): App ngày càng phình to, menu rườm rà, user mở app lên rối rắm chả biết bấm vào đâu.

• Tê liệt tư duy: Cả team bị cuốn vào vòng xoáy sửa lỗi cho cái cũ thay vì tập trung nguồn lực quý giá để tìm kiếm điểm đột phá cốt lõi.

Nếu bạn không dám cắt bỏ nhanh, bạn đang tự sát bằng sự phức tạp do chính mình tạo ra.

Những cú chém sấm sét từ các huyền thoại công nghệ

Để bạn thấy triết lý của Founder Snapedit không phải là nói suông hay chỉ đúng ở quy mô startup nhỏ, hãy nhìn vào cách các gã khổng lồ công nghệ thế giới đã từng sống sót nhờ kỹ năng cắt bỏ sấm sét này.

1. Instagram: Cú chém 90% tính năng để tạo nên đế chế tỷ đô

Trước khi trở thành mạng xã hội chia sẻ ảnh lớn nhất hành tinh, Instagram có tên là Burbn một siêu ứng dụng thời sơ khai chạy trên iPhone. Burbn cực kỳ phức tạp: nó cho phép check-in địa điểm, lên kế hoạch đi chơi, tích điểm thưởng, chơi game nhóm, và... chia sẻ hình ảnh sau khi check-in.

Sau vài tháng ra mắt, app dậm chân tại chỗ. Người dùng ngơ ngác trước một đống tính năng lộn xộn. Nhưng hai nhà sáng lập Kevin Systrom và Mike Krieger đã làm một việc cực kỳ dũng cảm: Họ nhìn thẳng vào data.

Họ phát hiện ra user hoàn toàn phớt lờ check-in hay game nhóm, nhưng lại cực kỳ cuồng nhiệt với việc đăng ảnh và áp các filter màu mè.

Không một chút do dự, Kevin và Mike quyết định vứt bỏ 90% code của Burbn. Họ khai tử sạch sành sanh các tính năng dư thừa. Họ chỉ giữ lại đúng ba thứ: đăng ảnh, áp filter, và comment. Họ đập đi xây lại ứng dụng hoàn toàn mới chỉ trong vòng vài tuần và đặt tên là Instagram.

Nếu ngày đó họ tiếc công sức build Burbn mà cố “optimize” đống tính năng check-in rác kia, thế giới đã không bao giờ biết đến Instagram.

2. Flickr: Cái chết của một tựa game mở đường cho kỷ nguyên chia sẻ ảnh

Tương tự như Instagram, Flickr ban đầu không phải là một công cụ chia sẻ ảnh. Nó là một tính năng phụ nằm trong một tựa game nhập vai trực tuyến có tên là Game Neverending.

Khi tựa game gặp khó khăn và metrics sụt giảm nghiêm trọng, đội ngũ sáng lập nhận ra người dùng trong game cực kỳ thích công cụ kéo-thả để chia sẻ và lưu trữ hình ảnh thời gian thực với nhau.

Họ đưa ra quyết định sấm sét: Đóng cửa hoàn toàn dự án game đồ sộ mà họ đã mất nhiều năm phát triển, trích xuất đúng tính năng chia sẻ ảnh ra và xây dựng nó thành Flickr. Quyết định dứt khoát đó đã cứu sống toàn bộ đội ngũ và biến Flickr thành thương hiệu trị giá hàng chục triệu đô thời kỳ Web 2.0.

3. Apple năm 1997: Khi Steve Jobs cầm “lưỡi hái” cứu mạng công ty

Năm 1997, khi Steve Jobs quay trở lại Apple sau 12 năm bị sa thải, công ty đang đứng trên bờ vực phá sản, chỉ còn đủ tiền mặt để hoạt động trong vòng chưa đầy 90 ngày.

Khi bước vào phòng họp nghiên cứu sản phẩm, Jobs té ngửa khi thấy Apple đang sản xuất hàng chục phiên bản máy tính Macintosh khác nhau, cộng với một đống thiết bị ngoại vi cà chớn như máy in, máy quét, và cả chiếc máy tính cầm tay Newton (tiền thân của PDA) — một dự án cực kỳ đột phá về mặt công nghệ lúc bấy giờ.

Steve Jobs đã làm gì? Ông không thuê thêm kỹ sư để cải tiến. Ông vẽ một chiếc bảng chia làm 4 ô:

• Cột: Cá nhân vs Chuyên nghiệp.

• Hàng: Máy bàn vs Máy xách tay.

Và ông tuyên bố: “Chúng ta sẽ cắt bỏ toàn bộ sản phẩm khác. Apple chỉ tập trung làm đúng 4 chiếc máy tính xuất sắc nhất nằm trong 4 ô này thôi.”

                 Consumer              Professional
            +-------------------+-------------------+
Desktop     |      iMac         |     Power Mac     |
            +-------------------+-------------------+
Portable    |     iBook         |    PowerBook      |
            +-------------------+-------------------+

Ông đã khai tử chiếc PDA Newton huyền thoại, dẹp bỏ mảng máy in, đóng cửa các chương trình cấp phép chạy clone Mac OS. Gần 70% dự án phần cứng và phần mềm của Apple bị vứt vào sọt rác chỉ trong vài tuần.

Cả Thung lũng Silicon thời đó chửi Jobs là điên rồ, là phá hoại. Nhưng chính sự dũng cảm cắt bỏ đó đã giải phóng nguồn lực, giúp Apple tập trung tinh hoa để tạo nên iMac, rồi iPod, iPhone những sản phẩm thay đổi lịch sử loài người.

Cẩm nang sinh tồn cho PM: Làm sao để Làm nhanh, Cắt nhanh?

Nói thì dễ, nhưng khi đối mặt với thực tế chiến trường, làm sao để một PM hay Founder có thể đưa ra những quyết định cắt bỏ sấm sét mà không làm team hoang mang hay sứt mẻ tình cảm?

Dưới đây là 3 đề xuất thực chiến mà mình đã đúc kết và áp dụng cho các dự án của mình:

1. Thiết lập Kill Criteria TRƯỚC khi viết dòng code đầu tiên

Sai lầm lớn nhất của các PM là chỉ chăm chăm đặt Success Metrics mà lờ đi Failure Metrics.

Khi bạn vẽ spec cho một tính năng mới, hãy bắt cả team bao gồm cả Founder và Lead Dev chốt vào một bản giao kèo: Tiêu chí khai tử (Kill Criteria).

Ví dụ: “Tính năng AI Magic Eraser này sau khi launch 30 ngày, nếu Retention Rate D7 dưới 5%, hoặc lượng user sử dụng hàng tuần quá thấp, chúng ta sẽ KHAI TỬ nó hoàn toàn vào ngày thứ 45. Không tối ưu thêm, không ngụy biện, không gia hạn.”

Khi đã thống nhất luật chơi từ đầu, việc cầm kéo cắt bỏ sẽ trở thành một quy trình vận hành tiêu chuẩn (SOP), chứ không còn là một cuộc chiến cảm xúc cá nhân.

2. Thiết kế hệ thống theo triết lý Build to Kill.

Nhiều startup gãy cánh vì code quá rối rắm. Tính năng A dính chặt vào tính năng B, tính năng B lại cắm rễ vào database lõi. Đến khi muốn bỏ tính năng A thì Dev khóc thét bảo: “Anh ơi bỏ cái này là sập luôn cả hệ thống đấy!”.

PM giỏi phải nói chuyện được với Engineering Lead để thống nhất triết lý kiến trúc phân tách (Decoupled Architecture).

Hãy coi mỗi tính năng mới như một thiết bị cắm ngoài. Khi cần, ta chỉ cần rút phích cắm ra là xong, phần còn lại của app vẫn chạy êm ru. Viết code sạch, cô lập database của các tính năng thử nghiệm chính là cách bạn chuẩn bị đường lui cho mình khi cần tháo chạy.

3. Draft MVP Chấp nhận sự thô ráp để test Market-Fit

Trong thời đại AI này, tốc độ thay đổi của công nghệ tính bằng tuần. Nếu bạn mất 6 tháng để thiết kế một quy trình UX hoàn hảo, vẽ 50 màn hình Figma bóng bẩy, viết đống code tối ưu hóa... thì khi bạn ship ứng dụng ra, đối thủ đã đi trước bạn 3 bước, và nhu cầu của user đã đổi khác.

Hãy chuyển sang tư duy Draft MVP nhưng chất lượng cao. Hãy ra mắt một phiên bản thô ráp nhất có thể, thậm chí UI hơi quê một tí, tính năng chỉ chạy được 80% trường hợp (Bắt buộc là không lỗi nghiêm trọng).

Mục tiêu là đưa nó ra ánh sáng thật nhanh để test xem user có thực sự thèm khát nó không. Nếu họ thèm khát, họ sẽ la ó đòi bạn nâng cấp lúc đó hãy đắp thêm thịt, làm đẹp giao diện. Nếu họ phớt lờ, bạn có thể giết nó ngay ngày mai mà không hề tiếc nuối, bởi vì bạn chỉ mất 3 ngày để build nó, chứ không phải 3 tháng!

🧐 Đừng để bị lừa bởi “Speed Delusion”

Một lưu ý cuối cùng mình muốn nhắn nhủ các bạn PM và Founder trẻ. Có một ranh giới rất mong manh giữa “Làm nhanh, cắt nhanh” và chạy bừa phá hoại.

Nhiều startup Việt đang mắc chứng Speed Delusion (lầm tưởng về tốc độ). Họ nghĩ mình đang đi nhanh vì team sáng nào cũng họp standup, PM vẽ spec sấp mặt, Dev code thâu đêm suốt sáng, mỗi tuần đẩy 2 bản update lên store. Nhưng khi nhìn lại sau 1 năm, sản phẩm vẫn dậm chân tại chỗ, người dùng vẫn rời bỏ app.

Tại sao?

Bởi vì họ đang chạy hì hục trên một chiếc máy chạy bộ đổ rất nhiều mồ hôi nhưng không tiến lên được phân nào. Họ chạy nhanh nhưng mù hướng và không đọng lại bài học gì. Cứ nhồi nhét tính năng vô tội vạ lên người dùng, thấy không ai xài là vứt đi làm cái khác mà chẳng buồn mổ xẻ lý do thất bại.

“Làm nhanh, cắt nhanh” chỉ thực sự phát huy tác dụng khi vòng lặp học hỏi của bạn cũng phải nhanh. Khi khai tử một tính năng, cả team phải ngồi lại làm một buổi Post-mortem nghiêm túc: Tại sao user không dùng? Giả thuyết ban đầu sai ở đâu? Lần tới làm sao để không giẫm lại vết xe đổ này?

Và quan trọng nhất: Dù cắm đầu chạy nhanh cỡ nào, cái bạn làm ra phải mang lại giá trị khác biệt cốt lõi.

Đôi khi, cái guồng quay điên cuồng của chữ “nhanh” dễ khiến người ta ảo tưởng. Vắt chân lên cổ vẽ spec, nhồi nhét cả đống tính năng làng nhàng chỉ để đối phó, để báo cáo sếp, hoặc để tự trấn an nỗi sợ tụt hậu. Nhưng nếu bạn làm bán sống bán chết chỉ để đẻ ra những thứ mà đối thủ đã làm nhan nhản (hoặc làm tốt hơn), bạn thực chất chỉ đang phóng xe ở tốc độ cao trên đường hẹp lao xuống vực.

Mỗi tính năng được ship đi sấm sét phải được thiết kế và kiểm chứng xoay quanh câu hỏi cốt tủy: Nó có làm nổi bật lý do tại sao sản phẩm của chúng ta khác biệt không? Nó có tạo ra một lợi thế độc bản, một killer feature mà đối thủ không dễ dàng bắt chước bằng AI trong vài nốt nhạc không?

Nếu bạn chạy nhanh nhưng sản phẩm làm ra không có bất kỳ điểm khác biệt nào mang lại giá trị thật sự, bạn đang chạy vô hướng. Nhanh là kim chỉ nam, nhưng Sự Khác Biệt Độc Bản mới là cái neo giữ vị thế sống còn của startup trên thị trường.

Nếu bạn cắt bỏ một tính năng mà không rút ra được bài học nào, hoặc tiếp tục cắm đầu làm những thứ vô thưởng vô phạt, bạn chỉ đang lãng phí tài nguyên của startup một cách nhanh hơn đối thủ mà thôi.

Lăng kính từ chiến trường: Lối đánh du kích của Snapedit và 3 bài học “xương máu”

Sau thành công lớn của Snapedit, đội ngũ của Quang không dừng lại. Họ liên tục tìm tòi, mày mò, xây dựng và thử nghiệm hàng loạt sản phẩm mới để tìm kiếm sản phẩm phù hợp với thị trường Product-Market Fit tiếp theo. Ưu điểm lớn nhất của họ là tốc độ thử nghiệm cực kỳ nhanh. Nhưng thị trường AI thay đổi quá chớp nhoáng, và việc lặp lại kỳ tích đó là bài toán đầy thử thách.

Nếu được nhận định nhanh thì rõ ràng Quang và đội ngũ “Đánh trận du kích và thực dụng.”

Đó không phải là một lời nhận xét tiêu cực, mà là sự phản ánh thực tế khốc liệt của chiến trường. Ở thế trận du kích đó, Quang đã đúc kết ra những bài học sống còn mà bất kỳ PM hay Founder nào đang muốn cưỡi sóng AI đều phải thuộc nằm lòng.

1. Cưỡi trend ngắn và UI/UX đẹp chỉ là mồi nhử, không phải Product-Market Fit

Trong thế giới AI, việc tạo ra một sản phẩm có giao diện bắt mắt (Good UI/UX) và bắt kịp một trào lưu chỉnh ảnh hay tạo avatar đang hot trên mạng xã hội là không khó. Bạn có thể nhanh chóng tận dụng các trào lưu ngắn và UI/UX tốt này để thu hút một lượng lớn người dùng ban đầu acquire users.

Nhưng Quang nhấn mạnh: Trend ngắn hạn không phải là câu trả lời cho Product-Market Fit. Khi cơn sốt qua đi, nếu sản phẩm không giải quyết được một vấn đề thực tế, lâu dài và mang lại giá trị cốt lõi, người dùng sẽ rời đi nhanh chóng. Đừng nhầm lẫn giữa sự bùng nổ traffic nhất thời với một mô hình sản phẩm bền vững.

2. Sự khác biệt độc bản là Cửa thắng là chìa khóa sinh tồn

Khi thị trường ngập tràn các ứng dụng “bình mới rượu cũ” clone từ API của các ông lớn công nghệ, câu hỏi quan trọng nhất mà Founder và PM phải trả lời trước khi bắt tay làm là: Sản phẩm này có đủ khác biệt và có cửa thắng hay không?

Nếu sản phẩm không đủ khác biệt tạo ra giá trị độc bản, nó sẽ không thể trở thành một sản phẩm phát triển bền vững. Quang chia sẻ một nguyên tắc rất thực tế: Nếu không nhìn thấy cửa thắng rõ ràng sau vài lần thử nghiệm, hãy dũng cảm khai tử nó ngay lập tức. Cố chấp níu kéo một sản phẩm thiếu bản sắc chỉ làm tiêu hao nguồn lực cốt lõi của startup.

3. Tự chủ công nghệ tối đa để tối ưu chi phí vận hành AI

Đây có lẽ là bài học thực tế nhất trong bối cảnh các AI startup đang phải đối mặt với hóa đơn vận hành đắt đỏ. Để sống sót lâu dài, triết lý của Quang là tự chủ tối đa các hạng mục tốn kém chi phí.

Thay vì phụ thuộc hoàn toàn vào việc gọi các API đắt đỏ ra các dịch vụ AI bên ngoài, team tập trung nâng cao năng lực quản trị hiệu quả chi phí sử dụng AI. Họ tìm cách tối ưu hóa tài nguyên, tự làm chủ mô hình và hạn chế tối đa việc gọi API ra ngoài để duy trì sự tự chủ tài chính tối đa. Trong lối đánh du kích, giảm thiểu chi phí vận hành chính là kéo dài đường chạy để tiếp tục tìm kiếm cơ hội lớn tiếp theo.

Trong kỷ nguyên biến động này, tốc độ đẻ ra sản phẩm mới chỉ là một nửa phương trình. Nửa còn lại quyết định sống chết chính là dũng khí trảm những thứ vô dụng. Hãy giữ cho sản phẩm thật tinh gọn để có thể xoay trục sấm sét khi thời cơ đến.

Bạn nghĩ sao? Trong app hay sản phẩm bạn đang quản lý hiện tại, có bao nhiêu tính năng Zombie đang âm thầm hút máu team của bạn mà bạn chưa dám cầm dao để cắt? Bạn đang giữ nó lại vì lợi ích của người dùng, hay chỉ vì cái tôi và nỗi sợ đối diện với thất bại của chính mình?

Chúc các bạn luôn tỉnh táo và quyết đoán trên chiến trường Product.

T.D,

T7.2026

P/s : Seri Bài viết của the-founders-lens là bài viết dạng tổng hợp được trích dẫn từ các chia sẽ cá nhân trong phạm vi buổi chia sẽ cho nội bộ team mình và đã được xác nhận chia sẽ lên Blog. Các trích dẫn các view của người nêu tên chia sẽ trong bài viết một phần thì cần/nên có xác nhận để tránh các góc nhìn sai lệch. Bài viết sử dụng cho mục tiêu tạo ra góc nhìn thực tế cho cộng đồng Product Việt Nam.

Next : The Founder’s Lens #2 [Founder Alpha Asimov / Ex Ceo Grab VN / VinID]: Sự trỗi dậy của App dùng 1 lần và Quyền lực của Solo Founder.

Nếu Henry Ford hỏi data, người ta sẽ bảo họ muốn một con ngựa nhanh hơn chứ làm gì có xe ôtô. Tương tự nếu PM 2026 hỏi dashboard, dashboard sẽ bảo hãy đổi màu nút CTA từ xanh sang đỏ và các tiểu tiết nhỏ lẻ.

Có một cảnh tượng mà mình gặp đi gặp lại ở các startup đến mức nhàm. Đây, diễn ra y chang mỗi lần:

Buổi sáng thứ Ba. Phòng họp Product Review. PM mở màn hình laptop, chiếu lên tường một cái dashboard đầy ắp biểu đồ. Funnel xanh đỏ vàng tím. Cohort analysis 12 tuần. Heatmap click. Session recording. Đẹp lung linh như một tác phẩm nghệ thuật trừu tượng.

CEO nhìn 30 giây rồi hỏi: “Vậy tính năng mới mình nên làm gì?”

PM: “Dạ... em cần chạy thêm A/B test để biết ạ.”

A/B test chạy 3 tuần. Kết quả: variant A thắng variant B với confidence 87%. PM report lên sếp. Sếp hỏi: “87% có đủ không?” PM ấp úng. Chạy thêm 2 tuần. Confidence lên 93%. Ship variant A.

Tổng thời gian từ câu hỏi đến quyết định: 5 tuần. Cho một cái nút thay đổi màu.

Trong khi đó, đối thủ không có dashboard nào cả, nhưng founder của họ ngồi quán cà phê nói chuyện với 10 khách hàng, rồi về ship một tính năng mới trong 1 tuần. Tính năng đó ăn đứt cái nút đổi màu của bạn.

Mình gọi hiện tượng này là Dashboard Theater xây dashboard để show sếp, để chứng minh team em data-driven lắm, chứ không phải để ra quyết định. Và nó đang giết chết rất nhiều sản phẩm.

The Theory: “In God We Trust, All Others Bring Data”

Câu nói huyền thoại này thường được gán cho W. Edwards Deming đã trở thành tôn chỉ của ngành PM hiện đại. Ý tưởng rất đẹp: thay vì dựa vào cảm tính hay ý kiến sếp (HiPPO callback Tập #3), hãy dựa vào dữ liệu khách quan. Chạy test, đo lường, rồi quyết định.

Các chương trình đào tạo PM hàng đầu Reforge, Product School, ngay cả chứng chỉ Mixpanel PAC đều nhấn mạnh:

1. Mọi quyết định sản phẩm nên dựa trên data.

2. A/B test là gold standard để so sánh giải pháp.

3. Xây dashboard để track metrics liên tục.

4. “If you can’t measure it, you can’t improve it.”

Ở Google, Facebook nơi có hàng tỷ user, hàng triệu data points mỗi giây triết lý này chạy ngon là chuẩn. Một thay đổi nhỏ trên newsfeed Facebook ảnh hưởng 3 tỷ người. Bạn PHẢI test trước khi ship. Đó là trách nhiệm không phải triết lý khỉ gì.

Nhưng khi triết lý đó được photocopy và dán vào một startup VN 500 DAU thì sao?

The Breaking Point: Bốn cái bẫy của “Data-Driven” ở thực tế VN

Bẫy 1: Streetlight Effect Chỉ đo cái dễ đo

Có một câu chuyện nổi tiếng: Đêm khuya, một người say rượu bò dưới cột đèn đường tìm chìa khóa. Cảnh sát hỏi: “Anh đánh rơi chìa khóa ở đây à?” Anh say lắc đầu: “Không, đánh rơi ở bên kia đường. Nhưng bên kia tối quá, tìm ở đây sáng hơn.”

PM VN đang làm y chang. Đo pageview, đo click, đo DAU, đo bounce rate vì mấy cái này các công cụ cho sẵn, bật lên là thấy. Nhưng những thứ quan trọng thật sự customer trust, delight, long-term brand perception, real willingness to pay thì không có dashboard nào đo được. Và vì không đo được nên giả vờ nó không tồn tại.

Kết quả? PM tối ưu cho click, tối ưu cho conversion nhỏ lẻ, nhưng bức tranh lớn sản phẩm có thật sự giải quyết được nỗi đau của khách hàng không thì không ai trả lời được. Bạn biết chính xác bao nhiêu % user click vào nút “Mua ngay” nhưng không biết tại sao họ click rồi lại thoát. Data cho bạn cái “What” nhưng hiếm khi cho bạn cái “Why.”

Bẫy 2: A/B Test mọi thứ = tê liệt quyết định

A/B test cần hai điều kiện cơ bản: traffic đủ lớn và thời gian đủ dài để đạt statistical significance (ý nghĩa thống kê). Ở Google với 8 tỷ searches/ngày, bạn có kết quả A/B test trong vài giờ.

Ở startup VN 500 DAU? Chạy A/B test, chia 50/50, mỗi bên 250 user. Muốn đạt 95% confidence cho một cải thiện 5% conversion? Bạn cần chạy 4-8 tuần tùy baseline conversion rate.

Bốn tuần. Cho một cái thay đổi UI. Trong khi thị trường VN thay đổi hàng ngày.

Mình từng thấy một team mất 6 tuần A/B test vị trí đặt nút đăng ký trên landing page. Sáu tuần. Kết quả cuối cùng: variant A thắng variant B... 2.3%. Với 500 users, sự khác biệt đó nằm hoàn toàn trong biên sai số (margin of error). Nó là noise, không phải signal. Nhưng PM vẫn tự hào report: “A/B test chứng minh variant A tốt hơn.”

Đó không phải data-driven. Đó là confirmation bias mặc áo khoa học.

Bẫy 3: Dashboard Overload 50 biểu đồ, 0 insight

Mình hay hỏi PM trong các buổi nói chuyện: “Mỗi sáng thức dậy, em mở dashboard nào đầu tiên?”

80% trả lời: “Em mở tất cả.”

“Mở tất cả nghĩa là em không biết cái nào quan trọng.”

Có một startup mình biết team Product 5 người sở hữu 47 dashboards trên Mixpanel, Google Analytics, Hotjar, và Amplitude. Bốn mươi bảy cái. Mỗi tuần product review, PM chiếu 15-20 biểu đồ khác nhau. CEO ngồi nghe, gật gù, cuối buổi hỏi: “Vậy tuần này mình cần làm gì?” Và mọi người lại nhìn nhau.

Dashboard nhiều ≠ insight nhiều. Thường thì ngược lại. Càng nhiều dashboard, não bộ càng bị quá tải (information overload), và con người có xu hướng cherry-pick cái dashboard nào confirm niềm tin sẵn có của mình. Tìm data ủng hộ quyết định đã có sẵn trong đầu đó là Confirmation Bias kinh điển.

Bẫy 4: Data nhìn về quá khứ, sản phẩm phải nhìn về tương lai

Đây là cái bẫy sâu nhất. Data tất cả data là ảnh chụp của quá khứ. Nó cho bạn biết chuyện gì đã xảy ra. Nó không cho bạn biết chuyện gì sẽ xảy ra.

Không ai A/B test được iPhone trước khi Steve Jobs tạo ra nó. Không ai survey được nhu cầu gọi xe qua app trước khi Uber xuất hiện. Không dashboard nào predict được TikTok sẽ giết Facebook ở tệp Gen Z.

Những sản phẩm đột phá nhất lịch sử không sinh ra từ data. Chúng sinh ra từ trực giác được trui rèn khả năng nhìn thấy pattern mà data chưa capture được. Data confirm những gì bạn biết. Intuition reveal những gì bạn chưa biết.

Và ở VN, nơi sếp chỉ tin data nhưng lại chọn data theo ý mình callback Tập #3), PM mất dần khả năng đó. Họ không dám đề xuất bất kỳ điều gì mà không có data chống lưng. Và cái data chống lưng đó, nếu không phù hợp ý sếp, cũng bị gạt phắt. Vậy data dùng để làm gì?

Mình thú thật: hồi mới vào nghề, mình cũng nghiện data. Mở Data mỗi sáng trước khi uống cà phê. Nhìn retention curve lên xuống mà tim đập như xem World Cup sắp đến. Đến khi mình nhận ra: con số trên dashboard không phải sản phẩm. Người dùng ngoài kia mới là sản phẩm. Và muốn hiểu họ, đôi khi phải tắt laptop, đi ra đường, và hỏi thẳng.

The Patch: “Data-Informed, Intuition-Calibrated” Không phải Data-Driven cũng không phải Gut-Feeling

Mình không khuyên vứt data đi. Data là vũ khí cực mạnh khi dùng đúng cách. Cái mình bảo vứt đi là ảo tưởng rằng data sẽ ra quyết định thay bạn. Data inform cung cấp thông tin. Bạn quyết định. Hai việc khác nhau.

1. “Minimum Viable Dashboard” 3 metrics, không hơn

Mỗi team, mỗi sản phẩm, tại mỗi giai đoạn, chỉ cần theo dõi 3 core metrics. Ba thôi. Bạn cần chọn:

• 1 metric đo Health: Sức khỏe sản phẩm (ví dụ: Weekly Active Users hoặc Organic Retention D7).

• 1 metric đo Growth: Tốc độ phát triển (ví dụ: New sign-ups/week hoặc Activation rate).

• 1 metric đo Money: Kiếm tiền (ví dụ: MRR hoặc Contribution Margin per transaction — callback Tập #4).

Tất cả 44 dashboards còn lại? Archive. Chỉ mở khi cần deep dive một vấn đề cụ thể. Dashboard hàng ngày = 3 con số trên 1 trang. Mở lên, nhìn 10 giây, biết sản phẩm ổn hay không. Xong. Đi làm việc thật.

2. Phân loại quyết định: Reversible vs. Irreversible

Jeff Bezos phân biệt 2 loại quyết định:

• Type 1 (Cửa một chiều / Irreversible): Một khi đi qua, không quay lại được. Ví dụ: Pivot toàn bộ business model. Đóng cửa product line. Merger.

• Type 2 (Cửa hai chiều / Reversible): Đi qua rồi không ổn thì quay lại. Ví dụ: Thay đổi UI, thử pricing mới, launch feature nhỏ.

Quy tắc: Type 2 → quyết nhanh, dùng intuition + lightweight data (xem 3 metrics), ship rồi observe. KHÔNG cần A/B test. Type 1 → research sâu, hỏi user, xem data kỹ, thậm chí chạy pre-mortem (callback bài Pre-mortem).

80% quyết định PM phải ra hàng ngày là Type 2. Nhưng vì nghiện data-driven nên PM VN đối xử với Type 2 như Type 1 A/B test mọi thứ, delay mọi thứ, ship cái gì cũng mất 2 tháng. Đối thủ ship 5 features trong khi bạn vẫn đang chờ A/B test cái nút.

3. Hypothesis First Viết giả thuyết TRƯỚC khi mở data

Đây là kỹ thuật chống Confirmation Bias hiệu quả nhất. Trước khi mở bất kỳ dashboard nào, hãy viết ra:

• “Mình tin rằng [X] đang xảy ra vì [Y].”

• “Nếu đúng, mình sẽ thấy [metric Z] có giá trị [khoảng nào].”

• “Nếu sai, mình sẽ thấy [metric Z] có giá trị [khoảng nào].”

Viết xong rồi MỚI mở data. Cách này ép bạn phải suy nghĩ trước khi nhìn số thay vì nhìn số rồi mới bịa ra narrative cho khớp. Teresa Torres gọi đây là Compare and Contrast và đó là kỹ năng PM mà không tool analytics nào dạy được.

4. Mỗi quý: 1 ngày Data Detox tắt hết dashboard, đi gặp user

Cái này nghe buồn cười nhưng nghiêm túc. Mỗi quý, dành nguyên 1 ngày tắt hết Mixpanel, Amplitude, GA. Ra quán cà phê. Gọi 5-10 user thật. Ngồi xuống. Hỏi: “Kể cho mình nghe cái lúc cuối cùng em mở app của tụi mình. Em đang làm gì? Em cảm thấy sao?”

Cái insight bạn nhận được từ 30 phút ngồi nghe một user kể chuyện đôi khi giá trị hơn 3 tháng nhìn dashboard. Vì user sẽ cho bạn cái “Why” thứ mà Data không bao giờ cho.

Đi qua 8 tập Reality Check, có một sợi chỉ đỏ xuyên suốt: chúng ta rất giỏi copy công cụ của người ở Tây/Tàu nhưng rất tệ trong việc hiểu bối cảnh mà công cụ đó được thiết kế. PMF, Retention Loop, Empowered Teams, Growth Hacking, Agile, OKR, PLG, và bây giờ là Data-Driven tất cả đều là những framework tuyệt vời.

• Ở đúng bối cảnh.

• Với đúng điều kiện.

• Cho đúng đối tượng.

Công cụ không tốt không xấu. Cái tốt xấu nằm ở việc bạn có đủ tỉnh táo để biết khi nào nên dùng nó, và khi nào nên vứt nó vào sọt rác để tin vào trực giác đã được luyện tập qua hàng ngàn giờ ngồi với user thật và được làm sản phẩm thật.

Bạn là PM. Công việc của bạn không phải là nhìn dashboard. Công việc của bạn là ra quyết định. Dashboard chỉ là một trong nhiều input. Và đôi khi, input quan trọng nhất không nằm trên màn hình nó nằm ở cái nhíu mày của khách hàng khi dùng sản phẩm của bạn.

Tuần tới là chúng ta sẽ bàn: Reality Check #9 AI Orchestrator. Khi AI agent làm được 80% công việc Process PM, thì PM còn lại để làm gì? Đây sẽ là bài quan trọng nhất tuyến bài này mình muốn chia sẽ với bạn.

T.D,

T6.2026

Em 34 tuổi, làm PM được 8 năm. Lương hiện tại 7X triệu. Nhưng dạo này công ty cắt giảm, nhìn sang trái toàn mấy bạn Gen Z 22-24 tuổi làm nhanh như máy, cày ngày cày đêm. Nhìn lên trên thì ghế Head of Product chỉ có một và ông sếp mới 32 tuổi. Em đang tự hỏi: 3 năm nữa tôi sẽ đứng ở đâu?”

Đó là tâm sự mình nhận được từ một bạn PM Senior tuần trước. Không có gì lạ. Nếu bạn lên các diễn đàn rôm rả nhất của dân tech, “khủng hoảng tuổi 35” là keyword lặp đi lặp lại.

Các báo cáo toàn cầu chỉ ra độ tuổi trung bình của một Product Manager ở Mỹ/Châu Âu rơi vào khoảng 39-40 tuổi. Ở độ tuổi đó, họ được coi là độ chín của sự nghiệp ”Tech Sage Age”. Nhưng ở Việt Nam một thị trường tech cực kỳ non trẻ với độ tuổi trung bình nhân sự chỉ loanh quanh 25-28 thì 35 tuổi tự nhiên biến thành một cái dớp.

Làn sóng sa thải năm 2023-2024 đã lột trần một sự thật tàn khốc: khi công ty cạn tiền, những người dễ bị đưa lên thớt nhất không phải là mấy bạn Fresher lương thấp, mà chính là tầng lớp “Middle Management” những người đang hưởng mức lương Senior nhưng giá trị thực tế mang lại không vượt trội hơn một bạn Junior đang được trang bị AI.

Thực tế data từ thị trường tuyển dụng cho thấy: hơn 70% PM ở Việt Nam bị kẹt ở level Senior/Mid-level khi bước qua tuổi 35.

Tại sao lại có cú gãy rất Việt Nam này? Và bản đồ career path thực tế cho PM sau 35 tuổi trông như thế nào, gạt bỏ hết mấy câu motivation quote rẻ tiền đi?

1. Tại sao bạn kẹt? Tại The Middle Management Trap

Có hai lý do cốt lõi dẫn đến việc PM tuổi 35 bị kẹt cứng:

Lý do 1: Ngộ nhận về chức danh

Nhiều người mặc định:
Junior PM → Mid PM → Senior PM → Head of Product / Director.

Đây là một cú lừa ngoạn mục. Sự khác biệt giữa một Senior PM và một Head of Product không phải là số năm kinh nghiệm. Bạn không thể cứ ở lì vị trí Senior PM 10 năm và hy vọng một ngày đẹp trời người ta sẽ bốc bạn lên làm Director vì bạn sống lâu lên lão làng.

Senior PM vẫn là người giải bài toán Product Execution làm sao để ship tính năng này tốt nhất. Nhưng Head of Product / Director là bài toán về Organization Design và P&L (Profit & Loss). Nếu đến 35 tuổi, bạn vẫn chỉ ngồi đo đếm Conversion Rate của một cái nút bấm mà không hiểu cấu trúc chi phí (Cost Structure) của công ty đang đốt tiền như thế nào, bạn sẽ vĩnh viễn kẹt ở level thực thi. Bạn trở thành một resource bị overpriced (giá quá đắt).

Lý do 2: Việt Nam thiếu trầm trọng Individual Contributor Track. (Hay gọi là IC Level)

Ở các công ty Big Tech (Google, Meta, Stripe) họ có hai cái thang song song: Thang quản lý (Management Track: Group PM → Director) và Thang chuyên gia (Individual Contributor - IC Track: Staff PM → Principal PM).

Nếu bạn không thích quản lý con người chuyện rất bình thường vì quản trị con người ở VN cực kỳ đau đầu và mệt mỏi, bạn vẫn có thể làm IC, nhận lương ngang ngửa Director, miễn là bạn giải quyết được những bài toán kỹ thuật/product có độ phức tạp khổng lồ.

Nhưng ở Việt Nam? Rất hiếm công ty có IC Track cho PM. Họ ép tất cả những người làm chuyên môn giỏi phải lên làm Manager. Và thảm họa xảy ra: công ty mất đi một PM giỏi, và có thêm một Manager tồi. Nếu bạn làm Manager tồi, tuổi 35 của bạn sẽ là chuỗi ngày họp hành triền miên, gánh KPI sấp mặt, và sớm muộn gì cũng bị thay thế.

2. Bản đồ Career Path thực tế sau 35 tuổi (The Path Forward)

Nếu bạn sắp, hoặc đã bước qua tuổi 35, đừng cố đua tốc độ viết ticket Jira hay vẽ wireframe với mấy bạn 24 tuổi. Chơi trò đó bạn thua chắc. Tụi nhỏ có thể thức đến 3h sáng để vẽ Figma mà nâng lực đẹp của GenZ là nổi trội. Bạn thì có vợ con, cột sống rên la, và trách nhiệm gia đình.

Lợi thế của bạn ở tuổi 35 không phải là sức trâu, mà là sự lọc lõi , khả năng đàm phán chính trị, và góc nhìn toàn cảnh (Business Acumen).

Hãy bấm “subscribe” để đọc đầy đủ về nội dung còn lại nhé.

Want to see the rest of this awesome Post ?
Just hit that subscribe button for free to unlock the full post right now!

Subscribe now

T.D,
T7.2026

Sản phẩm tốt sẽ tự bán. Nếu bạn phải thuê Sales thì sản phẩm chưa đủ tốt. Lời nói dối ngọt ngào nhất mà giới SaaS từng thì thầm vào tai nhau.

Một founder mà mình angel invest khá lâu hào hứng gọi Meet khoe: “Đạt, tụi anh vừa ra mắt 5000 người dùng miễn phí! Growth rate 40% month-over-month!”

Mình hỏi: “Nice. Bao nhiêu người trả tiền anh ơi?”

Im lặng.

“...14 người em”

Năm nghìn người dùng. 14 trả tiền. Conversion rate: ~0.28%.

Founder vẫn cười: “Nhưng em ơi, PLG mà. Cứ để sản phẩm tự nói. User miễn phí sẽ dần chuyển sang trả tiền khi thấy giá trị.”

Tám tháng sau, startup đó đóng cửa. Burn rate mỗi tháng 50 triệu nhưng revenue tháng cao nhất chỉ 8 triệu. Sản phẩm tốt thật. User khen hay thật. Nhưng không ai chịu mở ví.

Đó không phải là câu chuyện cá biệt. Đó là epidemic trong giới Phần mềm Việt Nam.

Từ Tập #1, chúng ta đã thấy: PMF ở VN bị bóp méo bởi voucher. Tập #4 chứng minh: Growth mà không nhìn P&L là đang đốt tiền. Hôm nay, chúng ta đào sâu vào một ảo tưởng tầng cao hơn nữa: Product-Led Growth triết lý tưởng như hoàn hảo nhưng có một cái trần kính mà Founder nào cũng đập đầu vào, đặc biệt tại thị trường Đông Nam Á.

Mình gọi cái ảo tưởng này là PLG Fundamentalism niềm tin cực đoan rằng sản phẩm sẽ tự bán mọi thứ, và việc xây Sales team đông và đuổi liên tục là biểu hiện của sản phẩm chưa mạnh.

The Theory: Slack, Notion, Figma và huyền thoại sản phẩm tự bán.

Product-Led Growth là chiến lược mà sản phẩm bản thân nó là kênh Acquisition (thu hút), Retention (giữ chân), và Revenue (doanh thu) chính. Thay vì thuê một đội Sales đi pitch từng khách hàng, bạn để user tự tải app, tự dùng thử (free trial hoặc freemium), tự trải nghiệm “aha moment,” rồi tự nâng cấp lên bản trả phí.

Những case study huyền thoại:

• Slack: Nhân viên dùng trước, rồi kéo cả team dùng, rồi team yêu cầu công ty mua license. Bottom-up adoption hoàn hảo.

• Notion: One người dùng tạo workspace → mời đồng nghiệp → cả phòng ban adopt → IT phải duyệt enterprise license.

• Figma: Designer dùng miễn phí → dev dùng để xem design → PM dùng để comment → CTO nhìn thấy cả công ty đang dùng → mua hẳn.

Cơ chế chung: Viral loop tự nhiên từ individual user → team → organization. Không cần Sales gọi điện. Không cần demo 60 phút. Sản phẩm tự lan như virus.

Đẹp. Rẻ. Hiệu quả. Với điều kiện: bạn đang ở Mỹ.

The Breaking Point: Tại sao PLG đụng trần tại Việt Nam và Đông Nam Á

Cái trần thứ nhất: ACV quá thấp, unit economics không chạy

Ở Mỹ, một SaaS tool giá $15-50/user/tháng là bình thường. Một team 10 người tự mua license qua credit card: $500/tháng, không cần ai duyệt. PLG hoạt động vì purchasing power (sức mua) cá nhân cao, và việc quẹt thẻ mua software dễ như mua cà phê.

Ở Việt Nam? Đầu tiên, giá phải hạ xuống cho phù hợp sức mua: $3-5/user/tháng thay vì $15-50. ACV (Annual Contract Value) tụt thê thảm. Một team 10 người trả $30/tháng = $360/năm. Bạn cần 2,800 team trả phí chỉ để đạt $1M ARR.

Trong khi đó, CAC (chi phí kiếm 1 khách trả tiền) ở VN cho SaaS B2B dao động $50-200 vì content marketing tiếng Việt reach hẹp, SEO cạnh tranh thấp nhưng cũng khó rank. Với ACV $360/năm và CAC $100, payback period là... 3-4 tháng. Nghe ổn nhưng chỉ ổn nếu churn rate thấp. Và ở VN, churn SaaS B2B trung bình 15-25%/năm vì doanh nghiệp nhỏ VN thay tool như thay áo.

Kết quả? LTV thấp. CAC không rẻ. Unit economics chạy ì ạch. PLG với miễn phí mà conversion chưa đc 1% thì càng làm càng chết nhanh hơn.

Cái trần thứ hai: Enterprise buyer Châu Á không quẹt thẻ mua software.

Đây là cái trần văn hóa mà sách Mỹ không nhắc tới.

Ở Mỹ, một Engineering Manager có thể tự quyết mua tool $5,000/năm cho team mà không cần xin phép ai. Credit card công ty quẹt cái rẹt. Đó là nền tảng của PLG bottom-up.

Ở VN? Bạn muốn mua cái gì trên $200/tháng là phải qua:

1. Trình sếp trực tiếp duyệt.

2. Sếp trình lên Director/VP.

3. Director gửi qua Procurement (Phòng mua hàng).

4. Procurement đòi 3 bản báo giá từ 3 vendor khác nhau.

5. Legal review hợp đồng.

6. Tài chính duyệt ngân sách.

Quy trình này mất 2-6 tháng cho một deal $3,000-10,000/năm. Trong khi PLG giả định user tự mua trong 5 phút.

Và đó chưa kể: nhiều doanh nghiệp VN vẫn muốn gặp mặt Sales, muốn demo riêng, muốn customization. “Em ơi, cái dashboard này chỉnh cho anh cái logo công ty anh vào được không? hay Sửa giúp anh cái này thì anh mới mua” Bạn nghe câu này bao nhiêu lần rồi?

Cái trần thứ ba: Free user không phải khách hàng đó là chi phí

Mỗi free user trên server của bạn tiêu tốn hosting, bandwidth, support ticket. Với SaaS Mỹ có margin 80-90%, nuôi free user là đầu tư. Với SaaS VN margin 40-60% vì giá thấp, chi phí nhân sự/hạ tầng VN không rẻ như mọi người tưởng, mỗi free user là một cục nợ đang nằm trên bảng cân đối kế toán.

Mình từng thấy một startup VN có 10,000 free users. Server bill hàng tháng: 25 triệu. Revenue từ 50 paying users: 15 triệu. Startup đó đang lỗ 10 triệu/tháng chỉ riêng tiền nuôi free users. Và founder vẫn lên LinkedIn khoe: “Chúng tôi có 10K users!”

Nhưng mình không hẳn chỉ anti-PLG tuyệt đối. Vấn đề không phải PLG sai. Vấn đề là người ta đối xử với PLG như một tôn giáo thay vì một chiến thuật. Và mọi chiến thuật đều có scope để áp dụng phù hợp.

The Patch: Product-Led Sales|Hybrid Model cho thực tế Đông Nam Á

1. PLG là kênh đầu phễu, không phải toàn bộ phễu

Hãy nghĩ PLG là cái loa kéo kẹo kéo để khách vào cửa hàng. Nó thu hút attention, tạo trải nghiệm ban đầu, xây dựng trust. Nhưng khi khách muốn mua deal lớn ($5,000+/năm), bạn cần một người bán hàng đứng bên trong để tư vấn, negotiate, và close.

Mô hình hybrid hoạt động thế này:

• PLG → Free trial / Freemium → User tự dùng → Hit usage threshold → Trở thành PQL (Product-Qualified Lead).

• Sales → Nhận PQL → Outreach → Demo cho buying committee → Negotiate → Close enterprise deal.

PQL khác MQL (Marketing-Qualified Lead) ở chỗ: PQL đã dùng sản phẩm thật và đạt ngưỡng hành vi (ví dụ: team 5+ người, dùng trên 3 tính năng, active 3 tuần liên tiếp). Sales không cần pitch từ đầu họ đã biết khách đang dùng gì, thích gì, cần gì. Cuộc conversation hoàn toàn khác level.

2. Biết khi nào phải bật nút Cần ae Sales

Đây là những tín hiệu đỏ cho thấy PLG thuần túy đã đụng trần:

• Self-serve conversion rate cho deal > $20K/năm dưới 15%.

• Chu kỳ bán hàng kéo dài vì buying committee bắt đầu xuất hiện (procurement, legal, IT).

• Top 20% account đóng góp hơn 50% ARR nghĩa là growth đang tập trung, cần quản lý chuyên biệt.

• Khách hàng bắt đầu hỏi: “Em có thể setup một buổi demo riêng cho team anh không?” — đó không phải complaint, đó là buying signal.

Khi thấy các dấu hiệu này, đừng cứng đầu giữ PLG pure. Thuê 1-2 Account Executive, arm họ bằng dữ liệu in-product (khách đã dùng gì, bao lâu, pain point ở đâu), và để họ close deal mà PLG không thể close.

3. Đặc biệt cho VN: Freemium phải nên luôn có Trap Door chứ ko nên No_Rule style.

Ở thị trường mà user nhạy cảm giá cực độ (callback Tập #1 đội quân săn voucher), freemium thuần túy là tự sát. User VN sẽ dùng bản free mãi mãi và hack mọi thứ có thể hack để tránh trả tiền. Gần đây các luật mới chắc sẽ giảm nhưng cần thời gian để mọi người quen việc trả tiền cho sản phẩm phần mềm nhiều hơn.

Trap Door là gì? Là một điểm trong user journey mà sản phẩm trở nên không thể dùng tiếp nếu không upgrade nhưng vào thời điểm đó user đã invest đủ nhiều (dữ liệu, workflow, thói quen) nên chi phí chuyển đổi cao hơn giá subscription.

Ví dụ:

• Cho dùng miễn phí với 3 projects. Project thứ 4 trở đi → trả tiền. Nhưng 3 projects đầu tiên đã chứa toàn bộ data quan trọng của team.

• Cho export PDF miễn phí với watermark. Bỏ watermark → trả tiền. Nhưng khách đã quen dùng tool để tạo report hàng tuần.

Trap Door phải đau đúng chỗ đau ở đúng thời điểm user đã “nghiện” chứ không phải đau ngay từ đầu kiểu “dùng thử 7 ngày rồi mất hết” cái này ở VN chỉ khiến user uninstall và chuyển sang tool khác.

Mình cũng từng ngồi với một founder SaaS ở Quận 2, anh ấy kể: “Anh Đạt, em đọc blog của Notion, của Figma, của Lenny Rachitsky. Tất cả đều nói Product-Led Growth là tương lai. Em tin và em all-in. Em không thuê Sales. Em để sản phẩm tự bán.”

Mình chia sẽ lúc đó : “Notion có 30 triệu user em có bao nhiêu” Lúc này thì thì gần nhất 2024 Ivan Zhao đã share có hơn 100M.

“hơn 5,000 sẵn sàng trả phí”

“Vậy em đang so sánh mình với Notion ở đoạn... nào?”

Notion, Slack, Figma họ có PLG motion ngon vì họ giải quyết pain point universal ai cũng cần ghi chú, chat, design, target thị trường giàu Mỹ, Châu Âu, và có hàng chục triệu user base trước khi bật Revenue engine đúng nghĩa. Bạn đang ở VN, với thị trường B2B SaaS non trẻ, sức mua thấp, và văn hóa mua hàng qua relationship mối quan hệ chứ không qua credit card và thuần tuý B2B chứ ko như Notion mix giữa C và B.

Tạm thời khi chưa lớn hãy thực sự PLG là một kênh acquisition. Không hơn, không kém. Đừng biến nó thành tôn giáo rồi hy sinh cả revenue của sản phẩm sẽ tự bán.

Câu hỏi cuối cùng: Bạn đang build product cho user hay cho investor pitch deck? Vì nếu cái bạn show trên deck là “10K free users” mà investor hỏi “bao nhiêu trả tiền?” và bạn ấp úng thì product-led hay investor-led cũng sẽ dẫn bạn đến cùng một đích: hết tiền.

Reality Check #8 tuần tới sẽ tấn công vào đức tin thiêng liêng nhất của PM: “Data-Driven.” Khi nào data giúp bạn ra quyết định đúng, khi nào nó chỉ là cái cớ để trì hoãn quyết định? Chuẩn bị.

T.D,

T6.2026

P/S : Bài này được viết lúc thị trường phần mềm có thay đổi bởi việc nhà nước sẽ kiểm phối hợp kiểm tra và thúc đẩy các luật liên quan sở hữu trí tuệ. Phần này sẽ thúc đẩy tích cực việc sử dụng và giá trị phầm mềm ở VN. Ngoài ra văn hoá chuộng tây chê ta ở VN vẫn còn tồn tại đến từ văn hoá thích đồ ngoại và cũng chính từ các sản phẩm VN chưa thực sự tốt. Nên để thúc đẩy các việc trên không có cách nào bằng việc từ chính việc chúng ta hiểu rõ sản sản phẩm chúng ta có gì khách biệt và làm nó phù hợp ở market chúng ta hướng đến. Thay vì clone 1 sản phẩm Tây vô hồn rồi bảo nó là vô giá.

Measure What Matters nhưng ở Việt Nam, cái duy nhất mà ai cũng muốn measure là tiền thưởng cuối năm.

Câu chuyện bắt đầu tại một buổi All-Hands meeting của một startup fintech ở Đà Nẵng, tầm giữa năm 2024.

CEO một anh Việt kiều học ở Mỹ về hào hứng chiếu lên màn hình cuốn sách “Measure What Matters” của John Doerr. Anh ấy thao thao bất tuyệt về cách Google dùng OKR để đi từ 40 nhân viên lên công ty nghìn tỷ đô. Về cách Intel dưới thời Andy Grove đã phát minh ra framework này để đập tan IBM. Về sự khác biệt giữa OKR (đầy cảm hứng, mơ mộng, cho phép fail 30%) và KPI (cứng nhắc, đo lường hiệu suất, bắt phải đạt 100%).

Cả team vỗ tay rần rần. HR lập tức thuê một anh consultant về đào tạo 2 ngày. Tốn 150 triệu. Xong xuôi, mỗi team ngồi set OKR đầu quý.

Quý 1 kết thúc. CEO hí hửng review. Mở dashboard OKR ra xem.

Kết quả: 92% team đạt trên 80% OKR.

CEO mừng quýnh: “Tụi mình giỏi thiệt!”

Mình ngồi nghe kể lại mà muốn khóc. 92% đạt trên 80%? Ở Google, nếu bạn đạt 100% OKR, điều đó có nghĩa là bạn đã set mục tiêu quá dễ. OKR chuẩn phải có moonshot mục tiêu trên trời và đạt 60-70% mới là tốt. Đạt 100% = bạn đang chơi an toàn.

Nhưng ở cái câu chuyện startup Đà Nẵng kia? Ai cũng set OKR vừa phải, dễ nuốt. Vì sao? Vì CEO đã mắc một sai lầm chí mạng: gắn OKR vào bảng tính bonus cuối quý.

Thế là OKR biến thành KPI đội mũ sang chảnh. Mình gọi cái này là OKR Karaoke mọi người hát theo bài hát của Google nhưng không hiểu lời hoàn toàn, và điều duy nhất họ quan tâm là điểm số.

The Theory: John Doerr và cuốn kinh thánh OKR

OKR — Objectives and Key Results có nguồn gốc từ Intel những năm 1970, do Andy Grove phát minh. Sau đó, John Doerr một nhà đầu tư huyền thoại từ Kleiner Perkins mang nó vào Google năm 1999 khi Google còn là một startup garage 40 người.

Cơ chế rất đơn giản:

• Objective (O): Bạn muốn đạt được điều gì? (Định tính, truyền cảm hứng, dễ nhớ). Ví dụ: “Trở thành ứng dụng thanh toán được yêu thích nhất tại Việt Nam.”

• Key Results (KR): Làm sao biết bạn đã đạt được Objective? (Định lượng, đo đếm được). Ví dụ: “Tăng MAU từ 1M lên 3M”, “Tăng NPS từ 35 lên 55.”

Đặc trưng quan trọng nhất của OKR theo sách là:

1. Moonshot thinking: Set mục tiêu cao ngất — đạt 60-70% coi như thành công.

2. Tách khỏi lương thưởng: OKR KHÔNG dùng để đánh giá nhân sự. Nó là la bàn chiến lược, không phải thước kẻ xét lương.

3. Minh bạch: OKR của CEO, của VP, của từng team tất cả đều public. Ai cũng thấy ai đang làm gì.

4. Chu kỳ ngắn: Thường theo quý, review liên tục, điều chỉnh khi cần.

Nghe hay quá đúng không? Google dùng nó mà thành công vang dội cơ mà. Intel cũng vậy. Thì mình cũng dùng thôi!

Rồi, đem về VN áp dụng nào.

The Breaking Point: Bốn điều chưa đúng của OKR kiểu Việt Nam

Ở Tập #4, mình đã nói rằng PM phải biết đọc P&L. Bài hôm nay tiếp tục câu chuyện đo lường — nhưng lên một tầng cao hơn: không chỉ đo sai metrics, mà cả hệ thống mục tiêu cũng sai.

Cú sấp mặt 1: OKR gắn lương = KPI đội mũ.

Đây là sai lầm phổ biến nhất, chết người nhất, và gần như 100% các công ty VN mình từng tiếp xúc đều mắc phải.

Khi bạn bảo nhân viên: “OKR của em đạt 80% thì em được bonus 2 tháng lương, dưới 60% thì không có” bạn đã biến OKR thành KPI trong vòng 1 phút. Nhân viên sẽ lập tức chuyển sang chế độ “sandbagging” thuật ngữ chỉ việc cố tình set mục tiêu thấp để dễ đạt.

Anh dev set KR: “Giảm bug count từ 50 xuống 40.” Thật ra anh ấy biết đang có 50 bug nhưng anh ấy có thể fix xuống 20 nếu cố. Nhưng set 20 thì rủi ro quá. Set 40 cho chắc ăn. Cuối quý report: “Đạt 100% KR!” Sếp vỗ vai. Bonus đầy túi.

Google tách bạch rõ ràng: OKR dùng để align mục tiêu chiến lược, KHÔNG dùng để đánh giá performance. Performance review ở Google dựa trên peer feedback, impact assessment, và nhiều yếu tố khác OKR chỉ là một input nhỏ trong bức tranh lớn. Nhưng mấy công ty VN? Copy cái framework, bỏ cái nguyên tắc sống còn nhất, rồi thắc mắc sao nó gãy.

Cú sấp mặt 2: Objective viết kiểu KPI.

Mình đã đọc OKR của ít nhất 20 startup và vài công ty vừa tại VN. Pattern quen thuộc nhất:

Objective: Tăng doanh thu 30% so với quý trước.

Xin lỗi. Đó không phải Objective. Đó là KPI. Objective đáng lẽ phải trả lời câu hỏi “Tại sao?” tại sao cần tăng doanh thu? Mục đích lớn hơn đằng sau là gì?

Objective đúng có thể là: “Chứng minh Product-Market Fit cho phân khúc doanh nghiệp nhỏ” và “Tăng doanh thu 30%” là một Key Result bên dưới. Nghe giống nhau nhưng khác nhau trời vực. Khi Objective là con số, team chỉ lo đạt số. Khi Objective là ý nghĩa, team sẽ phải suy nghĩ: “Đạt doanh thu 30% bằng CÁCH NÀO mới đúng? Tăng giá? Tăng volume? Hay mở segment mới?”

Cú sấp mặt 3: Set xong quên luôn đến cuối quý mới mở ra xem.

Mình gọi đây là OKR Thờ Cúng. Đầu quý, cả công ty ngồi set OKR hoành tráng. Ghi vào Google Sheet / Jira Goal. Rồi cất vào cái folder tên “Q2-2026-OKR” và quên béng mất.

Không có weekly check-in. Không có mid-quarter review. Không ai nhắc nhau. Đến cuối quý, mở ra thấy: “À, cái KR tăng retention lên 50%... ừm... chắc khoảng 35% gì đó... mà thôi ghi 45% cho đẹp báo cáo.”

OKR mà không có cadence với nhịp review đều đặn thì vô nghĩa. Nó giống như tập gym mua membership đầu năm, đi 2 tuần, rồi quên luôn cho đến khi thẻ hết hạn. Cái membership không giúp bạn giảm cân. Cái thói quen đi gym hàng tuần mới giúp.

Cú sấp mặt 4: Quá nhiều Objective, quá ít trọng tâm.

Một team 8 người nhưng có 5 Objectives, mỗi Objective có 4 Key Results. Tổng cộng: 20 KR phải track. Hai mươi cái. Cho 8 người. Mỗi sprint.

Không ai nhớ hết. Không ai focus được. Cuối cùng team chạy như gà mất đầu, cái gì cũng đụng một chút mà không cái nào sâu. Focus bị giết. Và khi focus chết, OKR chỉ còn là một cái todo-list oai vệ.

Mình nhớ hồi 2018-2019, có một đợt mà gần như mọi CEO startup VN đều hít hà cuốn Measure What Matters.

LinkedIn tràn ngập bài chia sẻ về OKR. Consultant OKR mọc lên như nấm sau mưa. Rồi tầm 1 năm sau, cũng đội CEO đó bắt đầu âm thầm quay lại dùng KPI truyền thống. Không ai nói gì. Không ai thừa nhận.

Cái dashboard OKR trên Notion vẫn nằm đó, phủ bụi, như một lời nhắc nhở về mùa hè ngây thơ.

The Patch: Lightweight Alignment OKR không phải cho tất cả mọi người

Mình nghĩ OKR sai. OKR chỉ hoạt động tốt ở đúng bối cảnh. Vấn đề là đa số công ty VN dùng sai bối cảnh, sai cách, sai mục đích. Đây là Bản vá theo góc nhìn của mình và mình nghĩ sẽ còn điều chỉnh dài vì cá nhân cũng đang tìm cách đưa OKR vào sao cho hiệu quả:

1. Tách OKR ra khỏi bảng lương ngay lập tức, không thương lượng

Đây là nguyên tắc sống còn số 1. OKR là la bàn chiến lược. Nó dùng để trả lời: “Team mình đang đi đâu quý này?” KHÔNG phải để trả lời: “Anh Nam có xứng đáng tăng lương không?”

Đánh giá nhân sự phải dựa trên: Impact thực tế (đo bằng đóng góp cho output/outcome), peer review, leadership assessment. OKR chỉ là một trong nhiều input, không phải input duy nhất.

Nếu sếp bạn nhất quyết gắn OKR vào bonus, hãy đề xuất compromise: chia thành Committed OKR (cam kết — phải đạt, gắn performance) và Aspirational OKR (kỳ vọng — moonshot, KHÔNG gắn performance). Đây là cách Google phân loại. Committed thường chiếm 60%, Aspirational chiếm 40%.

*Nhưng có một lưu ý bonus của một người nên gắp liền với tỉ trọng cao với thành tích chung của cả team dù có OKR hay ko OKR. Key thành công của 1 team sẽ luôn là thước đó tốt nhất cho kết quả. Chỉ là ở level càng cao thì tỉ lệ chịu trách nhiệm chung càng cao.

2. Startup < 30 người? Bỏ OKR, dùng “Weekly Priority Stack”

Cái này mình học được từ quá nhiều lần chứng kiến sai lầm và cả những thành công các team. OKR sinh ra để giải bài toán alignment khi tổ chức lớn, nhiều team, cần căn chỉnh mục tiêu chung. Nhưng startup 15-20 người thì cần alignment cái gì? Mọi người ngồi cùng phòng, ăn cơm trưa chung, biết rõ đồng nghiệp đang làm gì.

Thay vì OKR nặng nề, hãy dùng Weekly Priority Stack: Mỗi thứ Hai, mỗi team (hoặc cả công ty nếu nhỏ) chốt 3 priorities duy nhất cho tuần này. Ba thôi. Không bốn, không năm. Ba.

Viết lên whiteboard hoặc Slack channel. Mỗi thứ Sáu, review: hoàn thành chưa? Chưa thì tại sao? Tuần sau priority nào đổi?

Gọn. Nhẹ. Không cần consultant. Không cần dashboard. Và quan trọng nhất: không ai quên vì nó lặp lại mỗi tuần, không phải mỗi quý.

3. Tổ chức > 100 người mới nên nghĩ tới OKR và phải có Operating Rhythm.

Khi tổ chức lớn, nhiều team chạy nhiều hướng, OKR bắt đầu có giá trị thật sự vì nó tạo ra visibility ai đang làm gì, có đang chạy cùng hướng không.

Nhưng phải kèm theo nhịp vận hành nghiêm ngặt:

• Weekly check-in (15 phút): Mỗi team update tiến độ KR. Không phải để kiểm soát mà để phát hiện sớm nếu đang chệch hướng.

• Mid-quarter review (1 buổi): Giữa quý, tất cả team cùng đánh giá: OKR nào cần điều chỉnh? Thị trường đã thay đổi gì? Có KR nào đã trở nên vô nghĩa?

• End-of-quarter scoring (1 buổi): Chấm điểm trung thực. 0.6-0.7 = tốt. 1.0 = set quá dễ. Dưới 0.3 = cần phân tích tại sao.

Không có cadence này thì OKR chỉ là một cái file Google Sheet chết.

4. Mỗi team tối đa 2 Objectives, mỗi Objective tối đa 3 KRs

Quy tắc ngón tay cái: Nếu bạn không thể nhớ hết OKR của team mình mà phải mở file ra xem, bạn có quá nhiều OKR. Cắt bớt cho đến khi team có thể đọc vanh vách OKR mà không cần nhìn màn hình.

2 Objectives × 3 KRs = 6 con số cần track. Vừa đủ để focus. Vừa đủ để nhớ. Vừa đủ để tạo ra impact thật.

Có một câu mình hay nói với các PM khi hỏi về OKR: OKR, Scrum, PLG, Growth Hacking... tất cả chỉ là công cụ. Cái nguy hiểm nhất không phải là chọn sai công cụ. Cái nguy hiểm nhất là tôn sùng công cụ như tôn giáo rồi khi tôn giáo thất bại, bạn không dám vứt bỏ vì sợ mang tiếng không tiến bộ.

Google thành công không phải nhờ OKR. Google thành công vì họ có talent, có tiền, có văn hóa đủ trưởng thành để OKR hoạt động. Bạn photocopy cái framework mà không photocopy được cái văn hóa, thì kết quả nhận lại chỉ là một bản sao mờ nhạt, méo mó, và tốn kém.

Trước khi set OKR quý tới, hãy tự hỏi một câu thật thà: “Team mình đang dùng OKR để đi nhanh hơn, hay đang dùng OKR để trông có vẻ chuyên nghiệp hơn?”

Nếu đáp án là cái sau tắt cái dashboard đi, mở cái whiteboard ra, viết 3 thứ quan trọng nhất tuần này lên. Bắt đầu từ đó.

Tuần tới, Reality Check #7 sẽ đụng vào một thần tượng còn lớn hơn: Product-Led Growth. Slack, Notion, Figma tất cả đều tự bán mà không cần Sales. Nhưng khi startup VN làm theo, tại sao MAU thì cao mà revenue thì... bằng 0?

Subscribe để nhận được bài sớm khi có nhé.

T.D,

T6.2026

Chúng tôi chạy Agile! Câu nói có sức hủy diệt ngang ngửa “Chúng tôi lấy khách hàng làm trung tâm!” trong giới Tech Việt Nam. Nói thì dễ, làm thì... sấp mặt.

9 giờ sáng thứ Hai. Phòng họp của một công ty công nghệ tại Quận 1.

Mười hai người ngồi quanh một cái bàn dài. Scrum Master một bạn trẻ cầm chứng chỉ PSM I mới thi tuần trước mở Jira lên máy chiếu và bắt đầu gọi tên từng người: “Anh Nam, hôm qua anh làm gì, hôm nay anh làm gì, có blocker gì không?” Anh Nam — một Senior Dev 8 năm kinh nghiệm thở dài, đọc y nguyên cái status đã ghi sẵn trong Jira từ tối hôm trước. Mười một người còn lại ngồi lướt điện thoại chờ đến lượt.

Ba mươi hai phút sau, buổi standup kết thúc. Không ai đứng. Không ai giải quyết được gì. Mọi người túa ra khỏi phòng họp và bắt đầu... làm việc thật.

Và nếu bạn đọc The Reality Check từ đầu, bạn sẽ thấy một pattern: Chúng ta cứ mang sách Tây về, bê nguyên xi quy trình vào, rồi tự hỏi tại sao nó gãy. Tập #3 đã nói về chuyện Empowered Teams thành ảo tưởng vì văn hóa sếp. Hôm nay, chúng ta sẽ đào sâu hơn một tầng nữa: không chỉ cách quản lý sai, mà cả quy trình cũng sai. Sai từ đầu.

Bài này sẽ phân tích một hiện tượng mà mình gọi là “Agile Cosplay” team mặc đồ Agile ra trận nhưng bên trong vẫn chạy Waterfall, và cái giá phải trả cho vở kịch này đắt hơn bạn tưởng.

The Theory: Agile Manifesto và giấc mơ đẹp năm 2001

Năm 2001, 17 ông lớn ngành phần mềm ngồi lại ở một khu trượt tuyết tại Utah và viết ra Agile Manifesto với 4 giá trị cốt lõi và 12 nguyên tắc. Nói gọn lại thì thế này:

• Coi trọng con người và tương tác hơn quy trình và công cụ.

• Coi trọng phần mềm chạy được hơn tài liệu đầy đủ.

• Coi trọng cộng tác với khách hàng hơn đàm phán hợp đồng.

• Coi trọng phản ứng với thay đổi hơn bám theo kế hoạch.

Đẹp. Thông minh. Rất đúng.

Rồi từ cái Manifesto thanh lịch đó, người ta đẻ ra cả một đế chế: Scrum, Kanban, SAFe, LeSS, Nexus, Disciplined Agile... mỗi framework đi kèm một hệ sinh thái chứng chỉ, khóa học, và consultant có giá từ $2,000 đến $50,000 một đầu người. Agile không còn là một triết lý. Nó trở thành một ngành công nghiệp.

Scrum framework phổ biến nhất quy định rõ ràng: Sprint 2 tuần, Daily Standup 15 phút, Sprint Review, Sprint Retro, Sprint Planning. Ba vai trò: Product Owner, Scrum Master, Development Team. Mọi thứ được đóng gói gọn gàng, dễ triển khai.

Ở Mỹ, với văn hóa flat hierarchy rõ ràng, quyền tự quyết cao, và team đã quen với việc challenge ý kiến sếp Scrum chạy ngon lành. Nhưng khi cái framework đó bay 16,000 km từ San Francisco về Sài Gòn hay Hà Nội thì sao?

The Breaking Point: “Water-Scrum-Fall” và vở kịch 15 tiếng/tuần

Mình sẽ không vòng vo. Thực tế ở phần lớn các công ty tech Việt Nam là thế này: họ không chạy Agile. Họ chạy một thứ mà dân trong nghề gọi là Water-Scrum-Fall viết spec kiểu Waterfall (trên xuống, không thay đổi), meeting kiểu Scrum (ceremony đủ cả), và trễ deadline y hệt Waterfall truyền thống.

Nhưng trên LinkedIn và trong JD tuyển dụng, vẫn viết rất mạnh mẽ: “We are an Agile organization.”

Mình hay gọi đó là Agile Cosplay dân giả hơn là Agile Giả Cầy

Và đây là 3 triệu chứng bệnh nặng nhất:

Triệu chứng 1: Standup biến thành buổi báo cáo.

Theo Scrum Guide, Daily Standup là buổi đồng bộ ngắn do team tự tổ chức. 15 phút, đứng, chỉ nói blocker. Nhưng ở nhiều nơi, standup biến thành buổi trình diễn cho Scrum Master hoặc tệ hơn cho Engineering Manager ngồi ghi chép ai có vẻ làm ít.

Khảo sát của một công ty tư vấn Agile cho thấy hơn 60% developer coi standup là waste of time đặc biệt với team remote. Họ phải dậy sớm join Zoom, đọc lại cái đã viết sẵn trên Jira, rồi tắt camera đi uống cà phê. Cái buổi họp 15 phút đó, cộng thêm thời gian chuẩn bị và context switching, thực tế ngốn 30-45 phút mỗi ngày. Nhân lên 5 ngày. Nhân lên 10 người. Mỗi tuần bay mất 37-75 giờ làm việc của cả team chỉ để mọi người đọc to cái Jira ticket cho nhau nghe.

Bạn có thấy cái sự cà chớn ở đây không?

Triệu chứng 2: Retro thành buổi team building cho xong.

Sprint Retrospective đáng lẽ là buổi tự soi gương tàn nhẫn nhất: cái gì sai, tại sao sai, và sửa ra sao. Nhưng ở nơi văn hóa dĩ hòa vi quý thấm vào xương retro biến thành buổi khen nhau.

“Sprint này team làm tốt lắm!”, “Ừ, cải tiến thêm chút nữa là ngon!”

Không ai dám nói rằng cái tính năng vừa ship ra là vớ vẫn đầy lỗi vì sếp chỉ đạo. Không ai dám chỉ ra rằng Scrum Master chẳng giải quyết được blocker nào suốt 2 tuần. Và chắc chắn không ai dám đề xuất cắt bớt ceremony vì sợ bị quy kết là không Agile.

Kết quả? Mỗi sprint retro đẻ ra 5-7 action items mà không ai follow up. Sprint sau lặp lại y chang. Cái vòng lặp cải tiến liên tục (Continuous Improvement) linh hồn của Agile chết từ trong trứng nước.

Triệu chứng 3: Scrum Master trở thành Jira Admin sang chảnh.

Đây là vấn đề nhạy cảm nhất mà ít ai dám nói. Trong nhiều công ty , Scrum Master thực chất chỉ làm mấy việc này: tạo sprint trên Jira, nhắc mọi người update ticket, book phòng họp, và facilitate (dẫn dắt) các ceremony.

Nghe quen không? Đó là mô tả công việc của một Project Coordinator với mức lương thấp hơn 2-3 lần.

Năm 2026, khi AI đã có thể tự generate sprint report, tự tổng hợp blocker từ Slack, thậm chí tự suggest story point — thì câu hỏi đặt ra là: Scrum Master còn tạo ra giá trị gì? Thị trường đang trả lời câu hỏi đó bằng cách sáp nhập vai trò Scrum Master vào các title rộng hơn: Delivery Manager, Product Operations, hoặc đơn giản là... trả lại cho PM.

(Mình biết viết đoạn này ra sẽ bị một đống người có chứng chỉ SAFe chửi. Nhưng kệ. Sự thật thì vẫn là sự thật.)

Rồi, nói xong 3 triệu chứng, bây giờ zoom out một chút để nhìn cái hệ thống đang tạo ra vấn đề này ?

Tại sao Agile Cosplay tồn tại được? Vì nó phục vụ lợi ích của rất nhiều người:

• Sếp: Có ceremony để kiểm soát team mà vẫn được tiếng dân chủ. Standup hàng ngày = báo cáo hàng ngày nhưng gọi tên hay hơn.

• HR: Có framework oai để viết vào trang tuyển dụng: Chúng tôi áp dụng Agile/Scrum.

• Consultant: Bán khóa đào tạo Agile Transformation với giá trên trời. Xong quất vài cái ceremony vào, ship cho khách cái PowerPoint đẹp, rồi biến mất.

• Scrum Master: Có job title ngon lành, lương ổn, và công việc hàng ngày chủ yếu là... book phòng họp.

• PM: Có người Scrum Master gánh mấy cái ceremony lặt vặt để mình rảnh tay làm việc khác.

Ai cũng được lợi. Trừ sản phẩm và khách hàng.

Mình từng hỏi một anh CTO startup ở Quận 7: “Cycle time trung bình của team anh là bao lâu từ lúc idea quan trọng tới lúc lên production?” Anh ấy trả lời tự tin: “2 sprint, tầm 4 tuần.”

Mình bảo: “Anh đo lại đi. Đo từ lúc idea xuất hiện lần đầu trong cuộc họp, chứ không phải từ lúc nó được ghi vào Jira.”

Anh ấy đo lại. Kết quả: 11 tuần. Vì idea phải qua 3 tầng duyệt trước khi vào backlog. Rồi nằm trong backlog 4 tuần chờ ưu tiên. Rồi mới vào sprint.

Bốn tuần sprint, nhưng 11 tuần cycle time. Agile ở chỗ nào?

The Patch: Flow-First Hãy tập trung đo Flow của team.

Mình không có ý bảo Agile là sai. Triết lý Agile thích ứng nhanh, phản hồi sớm, giảm lãng phí là đúng. Cái sai là cách chúng ta triển khai nó. Chúng ta đã biến một triết lý linh hoạt thành một tôn giáo cứng nhắc, rồi thắc mắc tại sao thần không phù hộ nó đi nhanh.

Theo mình đây là Bản vá cho Agile Cosplay. Mình gọi nó là “Flow-First” ưu tiên dòng chảy công việc thực tế, không ưu tiên ceremony.

1. Đo Cycle Time, đốt bỏ Velocity

Velocity (số story point hoàn thành mỗi sprint) là chỉ số dễ game nhất trên đời. Team cứ inflate story point lên là velocity tự tăng. Sếp vui. Biểu đồ đẹp. Nhưng sản phẩm vẫn ship trễ.

Thay vào đó, hãy đo Cycle Time thời gian thực từ lúc task bắt đầu được làm đến lúc nó lên production. Con số này không nói dối. Nếu cycle time trung bình của team bạn là 3 tuần mà sprint chỉ có 2 tuần, thì bạn biết ngay: sprint boundary (ranh giới sprint) đang trở thành nút thắt cổ chai thay vì cái mốc để ship sản phẩm nhanh.

Hỏi team bạn: “Tốc độ delivery thực sự có nhanh hơn sau khi chạy Scrum không?” Nếu câu trả lời là ấp úng bạn đang cosplay.

2. Standup → Async Check-in, chỉ sync khi có lửa

Ý tưởng gốc của standup là tốt: mọi người đồng bộ nhanh, phát hiện blocker sớm. Nhưng trong thời đại remote work và AI và ngồi gần nhau vì nhiều cty đã bỏ wfh, cách thực hiện cần thay đổi hoàn toàn.

Cách làm: Mỗi sáng, mỗi người dành 3 phút gõ update vào một channel Slack/Teams … chuyên biệt (hoặc dùng bot tự hỏi). Format siêu gọn:

• 🟢 Đang làm: [task]

• 🔴 Stuck: [blocker cụ thể + tag người cần giúp]

Chỉ khi có 🔴 blocker thật sự mới cần sync call và chỉ những người liên quan mới cần tham gia. Không có blocker? Không có meeting. Đơn giản vậy thôi.

Kết quả? Team mình thử cách này và giải phóng được trung bình 4.5 giờ/tuần/người — tương đương hơn nửa ngày làm việc. Nửa ngày đó dev dùng để code. PM dùng để research. Không ai dùng để ngồi lướt điện thoại trong phòng họp.

3. Kill the ceremony bloat Giữ lại 2, đốt bỏ phần còn lại

Scrum có 5 event: Sprint Planning, Daily Standup, Sprint Review, Sprint Retro, Backlog Refinement. Ở team 8 người, tổng thời gian ceremony mỗi sprint (2 tuần) là khoảng 15-20 tiếng.

Mười lăm tiếng. Cho ceremony. Trong 80 tiếng làm việc. Gần 20% thời gian của team bay vào phòng họp.

Cách làm: Giữ lại 2 event quan trọng nhất, gộp và tinh gọn phần còn lại:

1. Weekly Planning + Refinement (gộp 2 thành 1, tối đa 60 phút/tuần): Chốt tuần này làm gì, clarify task nào chưa rõ.

2. Bi-weekly Demo + Retro (gộp 2 thành 1, tối đa 45 phút): Show hàng cho stakeholder + 15 phút retro nhanh theo format “1 thing to keep, 1 thing to kill.”

Standup đã chuyển sang async rồi. Tổng cộng: ~2.5 tiếng ceremony/2 tuần thay vì 15-20 tiếng. Team nhẹ nhõm. Sản phẩm chạy nhanh hơn.

4. Rebundle Scrum Master hoặc nâng cấp, hoặc loại bỏ

Đây là cái đau mà nhiều người không muốn nghe. Nếu Scrum Master của bạn chỉ đang làm việc của Jira Admin thì bạn có hai lựa chọn:

• Nâng cấp thành Delivery Manager thực thụ: Người này phải biết đọc Cycle Time, biết phân tích bottleneck trong value stream, biết negotiate deadline với stakeholder. Đây không phải là người facilitate meeting đây là người tối ưu hóa dòng chảy delivery của cả team.

• Loại bỏ và trả trách nhiệm về cho PM + Tech Lead: PM lo priority và stakeholder, Tech Lead lo technical decisions và unblock. Hai người này phối hợp là đủ. Không cần người thứ ba ngồi giữa chỉ để hỏi có blocker gì không?

Lựa chọn nào cũng đau. Nhưng cứ để Scrum Master ngồi book phòng họp với mức lương 25-40 triệu/tháng thì đau hơn đau ở ngân sách.

Mình nhớ hồi 2020, có một startup mà mình mentor ở Thủ Đức. Team 12 người, thuê consultant về triển khai Scrum đúng bài. Sau 3 tháng, CEO gọi mình bảo: “Anh Đạt ơi, sao tụi em chạy Agile mà ship còn chậm hơn lúc trước?”

Mình qua nhìn cái board Jira của team, thấy mỗi sprint có 45-50 ticket, grooming session kéo dài 2 tiếng vì Product Owner ngồi giải thích từng cái ticket một, retro thì ai cũng viết sticky note khen nhau. Mình hỏi: “Trong 3 tháng qua, retro đã tạo ra bao nhiêu thay đổi thực sự?”

Im lặng.

“Vậy thì retro của các em đang phục vụ ai? Phục vụ team hay phục vụ quy trình?”

CEO im thêm 5 giây rồi nói: “Phục vụ cái chứng chỉ Agile của ông nội consultant.”

Đó là lúc mình biết: Agile Cosplay không chỉ là vấn đề quy trình. Nó là vấn đề incentive. Khi incentive của tổ chức là trông giống Agile thay vì ship nhanh và chất lượng, thì mọi ceremony đều trở thành diễn kịch.

Bốn tập trước, chúng ta đã đập PMF ảo, Retention giả, Empowered Teams trong mơ, và Growth bằng mọi giá. Bài hôm nay thêm một viên gạch nữa vào bức tường hiện thực: ngay cả cách chúng ta tổ chức công việc hàng ngày cũng đang là một vở kịch.

Nhưng tin tốt là: khác với PMF hay Growth những thứ phụ thuộc vào thị trường và tiền bạc quy trình là thứ bạn có thể thay đổi ngay trong sprint tới. Không cần xin sếp. Không cần thêm budget. Chỉ cần đủ can đảm để hỏi một câu:

Nếu ngày mai xóa hết ceremony, chỉ giữ lại một, team sẽ giữ lại cái nào?

Câu trả lời sẽ cho bạn biết team thật sự cần gì. Phần còn lại? Kịch.

Tuần tới, Reality Check #6 sẽ xé toạc một “tôn giáo” khác mà mọi công ty tech đều thờ phụng: OKR. Khi nào OKR là la bàn thật, khi nào nó chỉ là KPI đội mũ sang chảnh? Chờ xem.

T.D, T6.2026

P/s: Làm gọn, nhanh và thay đổi quy trình không đồng nghĩa với việc bạn vô kỹ luật, thiếu tôn trọng team, không update các thông tin để team hiểu bạn làm gì. Lean # Vô kỹ luật.

“Growth Hacking không phải là mua user bằng mọi giá. Nếu CAC lớn hơn LTV, thứ bạn đang hack không phải là tăng trưởng, mà là số dư tài khoản của nhà đầu tư.”

Sau khi đi qua PMF ảo tưởng (The Reality Check #1), Retention gãy gánh (The Reality Check #2), và làm PM dưới quyền ông sếp khó chìu (The Reality Check #3), hôm nay chúng ta sẽ chốt hạ tháng 5 bằng một cú lừa kinh điển nhất giới Tech: Growth Hacking.

Tầm 5-7 năm trước, chữ Growth Hacker đi đâu cũng nghe. Nó hot đến mức mấy ông thần làm Marketing Facebook Ads đổi title LinkedIn rần rần thành Growth Lead ở VN cũng có rất nhiều ae làm growth xịn nhưng nhiều ông thì chỉ có mỗi bài chạy Ads rồi tự nhận mình là growth hack. Các PM thì bị lùa bởi những câu chuyện thần thoại của Airbnb, Dropbox hay Hotmail kiểu chỉ cần sửa một dòng text hay tìm 1 CVP hay, có khi thêm một cái nút Share là user tăng trưởng x100 lần êm ru.

Thế là anh em PM Việt Nam xắn tay áo lên làm Growth. Gắn tool tracking, chạy A/B test, nhồi nhét Gamification, rải voucher khắp mặt trận để đẩy con số Acquisition (Thu hút người dùng).

Mỗi tháng chốt báo cáo, MAU tăng 30%. Sếp gật gù khen thưởng. Cả công ty đi nhậu ăn mừng vì sắp thành kỳ lân tới nơi rồi.

Nửa năm sau, bộ phận Tài chính báo tin sét đánh: Công ty đứt xích dòng tiền không gọi thêm được vốn, chuẩn bị cắt giảm 50% nhân sự.

Ủa? Chuyện gì cà chớn vậy? Tăng trưởng ầm ầm mà sao phá sản?

The Theory: Vòng lặp Tăng trưởng (Growth Loops) của Thung lũng Silicon

Sách giáo khoa của Sean Ellis và Reforge định nghĩa Growth Hacking cực kỳ khoa học. Nó không phải là một mánh khóe để hack, mà là một hệ thống:

1. Tìm ra Aha Moment: Khoảnh khắc user nhận ra giá trị cốt lõi của sản phẩm. (Ví dụ: Facebook nhận ra nếu user add đủ 7 friends trong 10 ngày đầu tiên, họ sẽ ở lại mãi mãi).

2. Xây dựng Growth Loops: Hệ thống khép kín nơi lượng user hiện tại tự động mang về lượng user mới (Ví dụ: Dropbox tặng dung lượng nếu mời bạn bè).

3. Tối ưu phễu (Funnel): Liên tục A/B test từng điểm chạm để giảm Friction (lực cản) từ lúc user tải app đến lúc họ trả tiền.

Lý thuyết này ngon dễ áp dụng. Vấn đề là, ở Mỹ, một user trả tiền cho phần mềm ví dụ SaaS có biên lợi nhuận Margin lên tới 80-90%. Bạn đổ tiền marketing mang họ về, tháng sau họ gia hạn là bạn huề vốn.

Nhưng anh em lại đem cái framework đó ốp vào mảng O2O (Online-to-Offline), E-commerce, và Food Delivery ở Việt Nam hay kể các các Saas có tiếng ở VN hiện tại.

The Breaking Point: Khi Tăng Trưởng nghĩa là Đốt Lãi.

Sự thật phũ phàng là: Đại đa số các case study Growth Hacking ở Việt Nam bản chất chỉ là Voucher Hacking.

Bạn tìm ra Aha Moment? Không, bạn tìm ra Voucher Moment. User cài app, áp mã giảm giá 100k cho đơn hàng đầu tiên, chốt đơn. Aha! Họ nhận ra app bạn bán đồ rẻ bèo.

Nhưng đằng sau cánh gà, bức tranh tàn khốc của Unit Economics Kinh tế học vi mô đang gào thét sau lưng:

• Chi phí chạy ads để user cài app (CPI): 50.000đ.

• Voucher cho đơn đầu tiên (CAC bù thêm): 100.000đ.

• Phí vận hành, logistic, server cho cái đơn đó: 30.000đ.

• Lợi nhuận gộp từ đơn hàng (Gross Margin): 10.000đ.

P/s : chỉ số này dựa vào insight từ ae đã làm.

Tức là cứ mỗi lần anh em làm Growth Hacking mang về 1 khách mới, công ty lỗ sấp mặt 170.000đ ~ tương đương 6.46 USD cho một khách hàng mới và có thể biến mất sau đó vài ngày.

Các PM cứ nghĩ: “Mình chịu lỗ lúc đầu Acquisition để lấy user, rồi mình bào họ lại ở các đơn sau và đẩy dần Lifetime Value.” Nhưng như mình đã phân tích ở The Reality Check #2, user Việt Nam nhảy app liên tục. Đơn thứ 2 bạn không phát voucher, họ qua xài app khác hoặc app cũ họ thích. Cuối cùng, LTV của bạn còn thấp hơn cả CAC.

Càng Growth, càng mau chết. Bức tranh toàn cảnh bị che mờ bởi cái Vanity Metric (chỉ số ảo) mang tên Số lượng user đăng ký mới.

Nhiều PM ở VN thích chém gió về Product-Led Growth (PLG), nhưng thực chất không hề biết sản phẩm mình đang làm có Margin âm hay dương bạn dừng lại ở đây và thực sự dành 1 phút để biết được user bạn đang phục vụ đã mất bao tiền kiếm về ko ?. Đưa cho một cái báo cáo P&L (Profit & Loss), đảm bảo 80% PM sẽ té ngửa vì không hiểu đầy đủ mấy cái thuật ngữ tài chính. Bạn đang lái một chiếc xe đua trên cao tốc mà không biết bình xăng bị rò rỉ.

The Patch: Vá lại tư duy Growth từ User sang Margin

Đã đến lúc dẹp cái ảo tưởng Growth Hacking bằng ba cái nút bấm màu mè đi. Muốn làm PM sống thọ ở thời kỳ gọi vốn khó khăn này, bạn phải trang bị ngay cái đầu lạnh này vào tư duy hiểu rõ:

1. PM bắt buộc phải đọc được P&L (Báo cáo Lời/Lỗ)

Trước khi vẽ bất kỳ luồng Onboarding hay Campaign Growth nào, bạn phải trả lời được câu hỏi cốt tử: Contribution Margin (Số dư đảm phí) là phần chênh lệch giữa doanh thu và chi phí biến đổi (biến phí) của một sản phẩm hoặc dịch vụ, cho biết số tiền còn lại để trang trải chi phí cố định (định phí) và tạo ra lợi nhuận) của một giao dịch là bao nhiêu?

• Nếu Margin dương: Ok, cứ đẩy mạnh vòng lặp Growth, bào tới bến chạy ko cần dừng lại chỉ cần có tiền.

• Nếu Margin âm: DỪNG LẠI. Nhiệm vụ của Product lúc này không phải là tìm kiếm user mới. Nhiệm vụ của Product là tìm cách tối ưu quy trình, tự động hóa bằng Tech (ví dụ: dùng AI để giảm chi phí CSKH, tối ưu thuật toán ghép cuốc để giảm phí logistic) cho đến khi Margin dương trở lại.

• Tất nhiên sẽ có phần chi phí sẽ giảm dựa theo sizing nhưng nếu như thế sẽ work với giai đoạn trước thời tiền rẻ và đầu tư dựa vào tăng trưởng nóng. Xui cho bạn thời đó đã qua.

2. Đổi thước đo: Từ Tốc độ tăng trưởng sang Thời gian hoàn vốn (CAC Payback Period)

Khoe với sếp: “Tháng này em làm Growth kéo được 10.000 user mới” là tư duy của tay gà mờ. Tư duy của Seasoned Leader: “Tháng này em kéo được 10.000 user, CAC là 5$, nhưng em đã thiết kế cái luồng Upsell (bán thêm) để rút ngắn Payback Period từ 6 tháng xuống còn 2 tháng.” Hãy đo lường xem mất bao lâu để công ty kiếm lại được số tiền đã bỏ ra mua user đó. Ở thị trường Việt Nam, Payback Period quá 1 năm là rủi ro cực cao vì user không ai ở lại lâu đến thế. Nhưng nói thế thôi chứ VN ít PM được giao đến làm cái đó đa phần sẽ dừng ở việc development tính năng.

3. Chạy Anti-Growth Checklist trước khi đốt tiền

Mỗi khi định đề xuất một tính năng Gamification hay Referral để tăng trưởng, hãy tự hỏi:

• Cấu trúc giá (Pricing) của mình đã chuẩn chưa? Hay mình đang chạy để sướng nhìn số tăng bằng cách bán phá tiền?

• Nếu user tắt tính năng này đi, cốt lõi sản phẩm còn giữ họ lại được không?

• Chi phí duy trì (Maintenance cost) của cái tính năng Growth này trong 6 tháng tới là bao nhiêu?

Sống sót qua mùa đông

Chúng ta đã đi qua một hành trình 4 tập khá thực tế nhưng đây là góc nhìn để chúng ta cùng phát triển không phải tự lùi tự thấy khó khi làm sản phẩm, đập đi xây lại hàng loạt những tuyên ngôn sáo rống của giới PM: Từ Product-Market Fit, Retention Loops, Empowered Teams, cho đến Growth Hacking.

Mục tiêu của tuyến bài này không phải là chê bai sách vở Thung lũng Silicon. Sách Tây hay kiến thức thực sự là la bàn cho sự phát triển. Nhưng khi bạn cầm la bàn đi vào rừng rậm, bạn phải biết cách tự chế thêm con dao rựa để chặt gai góc hay phải tuỳ cơ ứng biến để ra đường rừng nhưng ko chết trước khi ra miễn đúng hướng.

Đừng tự đắc vì thuộc làu làu các framework. Hãy tự hào vì bạn biết khi nào thì nên vứt cái framework đó vào sọt rác để viết lại một cái mới, thực dụng hơn, phù hợp với sự thú vị khác biệt của thị trường, và giúp công ty kiếm ra tiền thật.

T.D,
T5.2026

P/s : hẹn bạn tiếp tục ở các The Reality Check ở tháng T6. Nếu thấy thú vị thì giúp mình chia sẽ đến bạn bè. Để mình tiếp tục viết. Nếu bạn chưa đọc từ đầu có thể đọc toàn bộ Seri này ở đây.

• The Reality Check #1 Câu hỏi khó giải thích của Product-Market Fit kiểu Mỹ tại Việt Nam

• The Reality Check #2 Retention Loops vs Đội quân săn voucher

• The Reality Check #3 Empowered Teams là thức khó xây dựng nhất ở các tập đoàn Châu Á.

“Chúng tôi cần những đội ngũ missionaries, chứ không phải lính đánh thuê” Marty Cagan.

“Em bớt chém gió lại, chiều nay chốt spec cho anh để sáng mai dev còn code” Ông sếp Châu Á điển hình.

Ở Reality Check #2, chúng ta đã buồn khi nhận ra cái Retention Loop đẹp đẽ bị đập nát bởi mấy cái voucher. Hôm nay, chúng ta sẽ chuyển sang một nỗi đau khác, đau hơn, mang tính... chính trị công sở. Đó là câu chuyện về Sự trao quyền (Empowerment).

Bất kỳ PM nào đọc xong hai cuốn kinh thánh Inspired và Empowered của Marty Cagan cũng đều thấy hừng hực lửa trong tim. Cuốn sách vẽ ra một viễn cảnh quá đẹp: Sếp giao cho team một bài toán (Problem), team tự research, tự quyết định giải pháp (Solution), và mang lại impact. Ngon ơ tuyệt con bà vời!

Mình cũng từng tin sái cổ vào cái lý tưởng đó. Nhớ hồi mới nhậm chức ở một tập cty internet xịn top VN, mình gom anh em lại, dõng dạc tuyên bố: “Từ nay team mình sẽ làm việc theo kiểu Empowered Teams. Các bạn được toàn quyền sáng tạo, không ai ép tính năng xuống nữa!”

Anh em vỗ tay rần rần.

Hai tuần sau, team mình gãy tan tành. Không ai dám chốt tính năng. Dev ngồi chơi xơi nước vì chờ PM sáng tạo. Lúc review, sếp chửi cho té ngửa vì trễ chưa chốt làm gì mà sản phẩm thì như một nồi lẩu thập cẩm tệ hơn thì gọi nồi cám lợn cũng được.

Lúc đó mình mới giác ngộ: Đem cái văn hóa Empowered của Thung lũng Silicon về cắm vào một tập đoàn hay team chưa mạnh chắc đa phần các cty sẽ đang như thế, nó chẳng khác gì lấy động cơ Ferrari lắp vào chiếc xe công nông. Chạy không nổi mà còn banh luôn dàn máy để không thì công nông còn có giá trị lao động tốt chứ ko đùa.

The Theory: Sự mộng mơ của Marty Cagan

Lý thuyết của Empowered Teams rất rõ ràng:

1. Lãnh đạo cung cấp Bối cảnh (Context) và Mục tiêu (Strategic Objectives).

2. Team tự quyết định Cách làm (How to solve the problem).

3. Product Manager là Mini CEO của sản phẩm, không phải là thợ viết tài liệu spec writer.

Trọng tâm của nó là chuyển từ Feature Factory sang Problem Solving Team. Nghe êm ru đúng không? Ở Google, Netflix, nó chạy mượt mà ngon luôn.

Nhưng xin lỗi bạn, chúng ta đang ở Việt Nam.

The Breaking Point: Văn hóa HiPPO và hội chứng Lính đánh thuê.

Ở Châu Á nói chung và Việt Nam nói riêng, mô hình quản lý mặc định là Command & Control (Ra lệnh và Kiểm soát). Cấu trúc quyền lực là Top-down đa phần.

Bạn nói chuyện Empowered Teams, nhưng bạn đâm sầm vào văn hóa HiPPO (Highest Paid Person’s Opinion — Ý kiến của người lương cao nhất phòng). Ở đây, sếp không giao bài toán. Sếp đi bàn chiến lược về hay thấy cái app đối thủ có tính năng X hay quá, hôm sau sếp quăng cái link vào group chat bảo: “Team nghiên cứu làm cái tính năng y chang vậy cho anh, cuối tháng lên sóng nha”.

Bạn từ chối? Bạn lấy sách Marty Cagan ra cãi sếp? Chuẩn bị cải xong cho đã rồi vừa tức vẫn vừa làm ?

Cái rào cản thứ hai còn cà chớn hơn và đau hơn: Chính team của bạn cũng chưa sẵn sàng để được trao quyền.

Khi bạn quen làm lính đánh thuê quá lâu sếp bảo gì làm nấy, làm xong phủi tay, sai thì sếp chịu, não bộ bạn sẽ hình thành một cơ chế phòng vệ. Đột nhiên bị ép phải tự quyết định đi, team sẽ rơi vào trạng thái tê liệt tạm thời =)). Không ai muốn đưa ra quyết định vì không ai muốn gánh còng lưng nếu dự án thất bại. Đẩy trách nhiệm (blame game) là môn thể thao quốc dân. Thà làm một cái bánh vẽ thất bại nhưng là do sếp duyệt, còn hơn làm một cái sáng tạo mà mình phải tự chịu trách nhiệm.

Vậy nên, mang Empowered Teams áp dụng rập khuôn ở đây là tự sát.

The Patch: Tự do trong khuôn khổ (Bounded Autonomy) và Nghệ thuật cấy ý tưởng

Thay vì đập bàn đòi quyền tự quyết như một đứa trẻ, PM thực chiến ở Việt Nam phải chơi một trò chơi tinh tế hơn nhiều và nghệ thuật hơn. Dưới đây là đề xuất của mình đã dùng để sống sót qua các môi trường doanh nghiệp khốc liệt nhất.

1. Đổi từ Empowerment sang Managed Empowerment (Tự do có kiểm soát)

Bạn không thể thả team ra một bãi đất trống rồi bảo xây cái gì cũng được. Bạn phải xây cho họ một cái Sandbox và bảo vệ họ nếu họ làm sai không chủ đích và ít nhất được phép làm sai nếu việc đó khó.

• Hành động: Xác định rõ với sếp những cái Guardrails cho team được làm là gì. “Sếp ơi, tụi em sẽ giải quyết bài toán giảm drop-off rate ở màn hình Checkout. Sếp cho tụi em tự do test 3 UI khác nhau nhé, cam kết không đụng tới flow thanh toán cốt lõi và không tốn quá 2 sprint.

• Bằng cách khoanh vùng rủi ro, sếp sẽ an tâm hơn nhiều so với việc nghe chữ trao quyền mông lung. Trong cái sandbox nhỏ đó, team bạn thực sự được Empowered.

2. Kỹ thuật Inception (Cấy ý tưởng) và Nghệ thuật Manage Up

Làm sao để sếp giao cho bạn giải bài toán chứ không bắt làm tính năng? Đừng cãi sếp, hãy Inception sếp. Cấy ý tưởng vào đầu sếp để sếp đồng cảm và chia sẽ ý tưởng đó là ý tưởng của bạn.

• Tình huống: Sếp bảo Làm tính năng livestream bán hàng cho app đi em.

• Phản ứng thợ code: Dạ vâng, để em vẽ spec. (Kết quả: fail sấp mặt vì app bán tài chính thì ai rảnh lên mà coi livestream).

• Phản ứng PM thực chiến (Manage Up): Idea Ok anh. Ý anh là mình đang cần tăng độ trust để user chốt đơn lẹ hơn đúng không? Em thấy livestream giải quyết được cái trust này. Để em research thêm coi ngoài livestream thì còn cách nào nhẹ nguồn lực hơn mà cũng tăng trust không, thứ 6 em báo cáo anh nghen.

• Đổi từ “Tính năng Livestream” sang “Bài toán Tăng Trust”. Ngon ơ. Sếp vẫn thấy được tôn trọng, mà bạn lại lách được khỏi cái bẫy Feature Factory.

3. Bào mòn dần hội chứng Thợ viết spec.

Đừng ép dev và designer tự quyết định mọi thứ ngay lập tức. Hãy giúp đội chuyển hoá dần.

• Thay vì ném cho dev cái PRD dày 20 trang. Hãy ném cái PRD 5 trang, phần UI logic để lửng. Hỏi dev: “Chỗ xử lý error state này, anh thấy làm sao êm ru nhất? Em nghĩ cách A, anh thấy sao?

• Từ từ chuyển họ từ người nhận lệnh sang người cùng giải quyết (Co-creator) họ giỏi hơn bạn tưởng rất nhiều. Phải chơi tới bến, kiên nhẫn từng sprint một. Rụng nụ giữa chừng là quay về máng lợn cũ ngay rồi đi chê Dev là dở hơi.

Kết cục của những nhà lãnh đạo tinh thần ngây thơ

Đọc sách Tây để lấy mindset, nhưng phải mang cái não của người Châu Á ra để thực thi.

Việc đòi hỏi Empowerment ở một tổ chức chưa trưởng thành không làm bạn thành siêu nhân Product. Nó thường biến bạn thành một PM ngáo , thích nói đạo lý và chê bai công ty.

Quyền lực không bao giờ được trao tặng miễn phí. Nó phải được giành lấy thông qua sự tin tưởng, và cách duy nhất để có sự tin tưởng là giải quyết xong những bài toán nhỏ bé, hằng ngày, nằm trong đúng cái phạm vi mà tổ chức cho phép. Bạn có đủ kiên nhẫn để chơi trò chơi dài hạn này không?

Tuần tới, chúng ta sẽ khép lại tuyến The Reality Check tháng 5 bằng số Reality Check #4 mình muốn share nhất: Khám phá xem sự ảo tưởng về Growth Hacking đã đốt cháy bao nhiêu tỷ đồng của các startup Việt Nam ra sao. Chuẩn bị tinh thần soi báo cáo P&L (Lời/Lỗ) nhé.

T.D,
T5.2026

P/s : Nếu thấy chủ đề này hay hãy share và subs để mình có động lực viết tiếp.

Share

Chúng ta không tạo ra thói quen cho người dùng. Chúng ta tạo ra con nghiện voucher. Và bây giờ, khi cai thuốc, cả hệ thống run rẩy.

Ở Reality Check #1, mình đã bàn chuyện Product-Market Fit kiểu Mỹ và ra sao khi đưa vào Việt Nam. Nhưng có một thứ còn đau hơn nữa. Giả sử bạn đã tìm được PMF thật rồi đi user thật sự cần sản phẩm của bạn, không phải vì voucher. Câu hỏi tiếp theo là: Làm sao giữ chân họ?

Sách giáo khoa có câu trả lời ngon ơ: Habit Loop. Xây một vòng lặp thói quen, user sẽ tự quay lại như chuột nhấp đèn xanh. Nghe hay dữ ha, phải không?

Chắc nhiều người từng tin điều đó. Hồi 2019, lúc cty làm O2O trên một cái Super App triệu user, team làm dự án đó cặm cụi ngồi vẽ Habit Loop đúng chuẩn sách Nir Eyal. Trigger ngoại push notification dẫn tới Trigger nội thói quen. Phần thưởng biến thiên (Variable Reward). Investment đầu tư thời gian vào app. Mọi thứ y chang trong sách.

Rồi sao? Rồi Grab tung ra chương trình “Flash Sale giảm 60%” đúng cái tuần mình launch tính năng mới. Cái Habit Loop đẹp đẽ của team bị nghiền nát trong vòng vài ngày. User không thèm mở app nữa. Họ chạy đi hốt deal bên kia.

Lúc đó ae mới ngộ ra: Ở Việt Nam, bạn không chỉ cạnh tranh với đối thủ. Bạn đang cạnh tranh với cả một nền văn hóa săn deal đã ăn sâu vào máu thịt người tiêu dùng.

The Theory: Sách Nir Eyal dạy gì?

Cuốn Hooked của Nir Eyal, kết hợp với module Retention của Reforge, là kim chỉ nam mà hầu hết PM trên thế giới đều thuộc nằm lòng. Mô hình gồm 4 bước:

Trigger → Action → Variable Reward → Investment

Ý tưởng thì đơn giản: Bạn tạo ra một cái điểm tựa (Trigger) để user mở app. User thực hiện hành động (Action) rồi nhận được phần thưởng bất ngờ (Variable Reward — giống kiểu kéo feed TikTok, không biết video tiếp theo là gì nên cứ lướt hoài). Cuối cùng, user đầu tư (Investment) thời gian, dữ liệu, nội dung vào app khiến việc rời đi trở nên khó khăn hơn.

Cái hay của mô hình này là nó tự vận hành. Sau vài vòng lặp, user không cần push notification nữa. Họ tự động mở app vì não đã đưa thói quen đó vào. Đó gọi là Internal Trigger kích hoạt nội tại.

Ở Mỹ, nó chạy ngon lành. Instagram, Twitter, Duolingo đều xây trên mô hình này.

Ở Việt Nam? Chuyện khác.

The Breaking Point: Khi cả một nền kinh tế bị đầu độc bởi khuyến mãi.

Vấn đề không nằm ở mô hình Habit Loop sai. Mô hình đúng. Vấn đề nằm ở chỗ: thị trường Việt Nam đã bị đầu độc bởi cuộc chiến đốt tiền của các ông lớn, khiến mọi Internal Trigger bị thay thế bằng Voucher Trigger.

Hãy nhìn lại giai đoạn 2018-2022. Grab, ShopeeFood, Baemin, Now, MoMo, ZaloPay, VNPay... tất cả đều lao vào một cuộc chạy đua tàn khốc: Ai đốt nhiều tiền hơn, người đó thắng. Mỗi ngày, user Việt Nam nhận hàng chục cái notification: “Giảm 50% hôm nay!”, “Freeship đơn từ 0đ!”, “Hoàn tiền 30%!”.

Chuyện gì xảy ra khi bạn cho người ta ăn đường liên tục trong 4-5 năm? Họ nghiện. Và cái thứ họ nghiện không phải app của bạn mà là cảm giác được hời.

Mình từng ngồi xem data hành vi user của một ứng dụng thương mại và thấy một pattern đau lòng. Có một nhóm user tầm 35-40% tổng lượng cài cùng lúc 3-4 app cùng ngành trên điện thoại. Mỗi khi cần đặt đồ ăn, họ mở cả Grab lẫn ShopeeFood, so sánh giá sau khuyến mãi, rồi mới chốt đơn ở app rẻ nhất. Ngày mai, app khác có deal ngon hơn? Chuyển sang bên đó ngay. Không do dự. Không luyến tiếc.

Cái này trong ngành gọi là Multi-homing user trung thành với giá, không trung thành với bạn.

Khi Baemin rút lui khỏi Việt Nam, nhiều người tiếc nuối vì UI dễ thương brand hay vì giọng văn hài hước trên notification. Nhưng tiếc nuối không đổi thành mở app. Không ai mở app vì thương. Họ mở vì deal.

Vậy Internal Trigger ở đâu? Nó chết rồi. Bị chôn sống dưới đống voucher.

Hồi mới vào nghề, mình cũng thần tượng cái mô hình Hook. Cứ nghĩ thiết kế UX thật mượt, notification thật thông minh là user sẽ quay lại. Trời ơi, ngây thơ. Ở một thị trường mà đối thủ sẵn sàng bán dưới giá vốn để cướp user, UX đẹp cỡ nào cũng vô nghĩa nếu bạn không giải được bài toán: “Tại sao user phải ở lại với tao khi thằng bên cạnh đang phát tiền?”

The Patch: Quên Habit Loop đi, hãy xây Nhà giá trị không rời đi được.

Mình không nói Habit Loop là vớ vẫn. Nó vẫn có chỗ đứng nhưng ở VN, nó chỉ là lớp sơn bên ngoài. Cái nền móng thật sự để giữ chân user ở thị trường Đông Nam Á phải là thứ khác: Lock-in Effect Hiệu ứng giam cầm hay nói cho hoa mỹ hơn, xây một cái Nhà tù nhốt được user không muốn trốn ra.

1. Switching Cost phải lớn hơn Voucher Value (Chi phí chuyển đổi > Giá trị voucher)

Đây là nguyên tắc sống còn. Nếu user mất 5 giây để chuyển sang app đối thủ và tiết kiệm được 20.000đ, bạn thua. Nhưng nếu user đã tích lũy 500.000 điểm thưởng, đã lưu 200 địa chỉ giao hàng, đã có lịch sử đơn hàng 2 năm trên app của bạn việc bỏ đi sẽ đau hơn nhiều so với cái voucher 20k bên kia.

Hồi làm hệ sinh thái điểm thưởng ở một tập đoàn lớn, mình thấy rõ: nhóm user có trên 100.000 điểm tích lũy có tỷ lệ rời app churn rate thấp hơn 3 lần so với nhóm user mới. Không phải vì app hay hơn. Mà vì họ tiếc của.

Hành động cụ thể cho PM theo mình:

• Thiết kế tài sản số (digital assets) mà user tích lũy theo thời gian và không thể mang sang app khác: điểm thưởng, cấp bậc thành viên, lịch sử cá nhân hóa.

• Quy tắc ngón cái: Switching Cost phải gấp ít nhất 5 lần giá trị voucher trung bình mà đối thủ đang tung ra.

2. Content Moat — Trú trọng nội dung không thể sao chép

Grab với ShopeeFood có thể copy nhau về voucher, về UI, về thời gian giao hàng. Nhưng có một thứ không ai copy được: Dữ liệu cá nhân của user đã tích lũy trên app của bạn.

Nghĩ thử coi: Tại sao nhiều người vẫn dùng app ngân hàng chưa ngon bằng ví, UI xấu, nhưng không chịu chuyển sang app mới? Vì lương tháng nào cũng tự chuyển vào đó. Gần đây thì app ngân hàng làm quá tốt chẳn còn so sánh được việc chuyển tiền từ App Bank với App ví và có khi còn tốt hơn nhiều.

Hành động cụ thể cho PM:

• Xây tính năng khiến user tạo ra dữ liệu có giá trị cá nhân mà chỉ có trên app của bạn: Sổ thu chi, lịch sử sức khỏe, danh sách yêu thích, ghi chú cá nhân.

• Dữ liệu này phải hữu ích theo thời gian không phải tính năng làm cho chiều càng dùng lâu, càng giá trị. User rời đi mất hết. Đó mới là Lock-in thật sự.

3. Tách bạch và hiểu sâu sắc Retention Thật vs. Retention Ảo.

Cái này mình đã nói sơ ở Tập #1, nhưng nó quan trọng đến mức phải nhắc lại cho kỹ hơn.

PM Việt Nam hay gom hết Retention vào chung một cái biểu đồ rồi khoe: “D30 của tụi em là 40%!”. Nghe oai dữ. Nhưng hỏi ngược lại: Trong 40% đó, bao nhiêu phần trăm user quay lại vì đúng lúc bạn gửi push notification kèm mã giảm giá? Bỏ cái notification đó đi, còn bao nhiêu?

Hành động cụ thể cho PM:

• BẮT BUỘC tách data thành 2 cohort:

  • Organic Retention: User mở app tự nhiên, không có mã giảm giá, không có push notification trong 24h trước đó.

  • Incentivized Retention: User mở app sau khi nhận khuyến mãi.

• Chỉ có Organic Retention mới phản ánh sức khỏe thật sự của sản phẩm. Incentivized Retention là thuốc giảm đau không phải thuốc chữa bệnh.

Ở VN, mình từng thấy có sản phẩm khoe Retention D30 là 42%. Khi tách ra thì Organic chỉ có... 8%. 34% còn lại là nhờ đội Marketing bơm notification + voucher mỗi ngày. Cái 8% kia mới là con số thật. Và nó cho thấy sản phẩm đang hấp hối.

Nếu bạn đang ngồi nhìn biểu đồ Retention đẹp lung linh của mình mà trong bụng thấy hơi sai sai tin mình đi, linh cảm đó đúng đấy. Hãy tắt hết voucher, tắt hết push notification trong 2 tuần cho một nhóm user thử. Rồi nhìn lại biểu đồ. Cái còn sót lại sau cuộc thanh lọc đó dù xấu xí, dù nhỏ bé đó mới chính là nền móng thật sự để bạn xây tiếp.

Còn nếu tắt hết rồi mà biểu đồ rớt tự do về 0?

Thì ít ra bạn cũng biết sự thật trước khi hết tiền.

Tuần tới, The Reality Check #3 sẽ mổ xẻ tại sao Empowered Teams triết lý huyền thoại của Marty Cagan lại gãy tan tành khi gặp ông Sếp Châu Á và văn hóa Sếp nói gì nghe nấy.

T.D,
T5.2026

P/s : Nếu thấy chủ đề này hay hãy share và subs để mình có động lực viết tiếp.

Share Datht's Reflections