Bên em vừa setup xong phòng Customer Success anh ạ. Có 5 bạn chuyên gọi điện cho khách. Em set KPI cho team tỷ lệ Renew phải 80 phần trăm và doanh số Upsell mỗi tháng 200 triệu.

Nghe câu này từ một bạn Founder B2B SaaS mình chỉ biết cười trừ. Bạn vừa mới đổi tên phòng “Telesales” thành “Customer Success” chứ đâu có xây dựng team CS nào.

Đây là một thực trạng đáng buồn một “vở kịch” mang tên CS Theater đang được công diễn ở rất nhiều startup Việt Nam. Chúng ta học lỏm các thuật ngữ hào nhoáng nhưng lại áp dụng nó với tư duy đi buôn truyền thống. Và cái giá phải trả không hề rẻ: theo báo cáo năm 2024 của Gainsight nền tảng CS hàng đầu thế giới những công ty SaaS có team CS thực sự (không phải CS giả danh) đạt Net Revenue Retention trung bình 120%, nghĩa là doanh thu từ khách hàng cũ tự tăng 20% mỗi năm mà không cần đội Sales đi săn hợp đồng mới. Ngược lại, những công ty có CS rỗng ruột thường chịu Net Revenue Retention dưới 90% tức là doanh thu “rò rỉ” âm thầm từng tháng.

The Theory: CS sinh ra để làm gì?

Triết lý Customer Success được sinh ra từ một nhận thức đơn giản nhưng cực kỳ sâu sắc: trong mô hình SaaS, giá trị thực sự nằm ở năm thứ 2, thứ 3, thứ 5 — chứ không phải ở cú chốt hợp đồng đầu tiên. Nghiên cứu của Bain & Company (đơn vị sáng tạo ra chỉ số NPS) chỉ ra rằng chi phí để có được một khách hàng mới đắt gấp 5-25 lần so với việc giữ chân khách hàng cũ. Khi bạn bán gói SaaS đầu tiên, bạn mới chỉ thu hồi được chi phí marketing và sales. Lợi nhuận thực sự chỉ bắt đầu chảy về từ lần gia hạn thứ hai trở đi.

Customer Success khác biệt hoàn toàn với Customer Support và Sales ở một điểm cốt lõi: nó là chức năng duy nhất trong công ty mà KPI gắn liền với kết quả kinh doanh thực tế của KHÁCH HÀNG, chứ không phải kết quả kinh doanh của MÌNH.

Customer Support ngồi chờ khách gặp lỗi rồi fix bị động hoàn toàn. Sales chạy số, chốt tiền, rồi rũ bỏ chuyển khách sang cho ai đó “chăm sóc”. Còn CS thì chủ động theo dõi hành trình sử dụng sản phẩm, đo lường xem khách hàng đã đạt được kết quả mong muốn hay chưa, và can thiệp trước khi vấn đề nổ ra. Khi khách hàng thành công, họ tự nhiên sẽ gia hạn đó mới là logic đúng.

Slack là một ví dụ kinh điển. Trong giai đoạn tăng trưởng bùng nổ từ 2015-2019, Slack không set KPI doanh số cho team CS. Thay vào đó, họ đo một thứ rất đơn giản: số lượng tin nhắn được gửi mỗi ngày trong tổ chức của khách hàng. Khi con số này tăng, Slack biết chắc team đó đang thực sự adoption sản phẩm và lúc đó, việc upsell lên gói Enterprise gần như tự động diễn ra. Đó là CS thật.

The Breaking Point: “Vở kịch” CS ở Việt Nam

Nhưng thực tế ở thị trường nội địa, các team CS thường hoạt động theo một kịch bản rất khác. Và mình sẽ gọi tên từng “màn kịch” luôn.

Màn 1: “Bạn bè 1 tháng, rồi Người lạ cả năm”

Tháng 1 đến tháng 10, khách hàng loay hoay không biết dùng phần mềm, không ai quan tâm. Đến tháng 11, một bạn xưng là “Customer Success Manager” gọi điện giọng ngọt ngào: “Dạ anh ơi, dạo này anh dùng phần mềm bên em có tốt ko ạ? Tháng sau anh hết hạn rồi, anh gia hạn gói 1 năm em giảm 10% nhé.”

Khách hàng không cảm thấy được chăm sóc. Họ cảm thấy bị “làm phiền để vòi tiền”. Và phản ứng tự nhiên của họ là: “Dùng chả mấy, có gì đâu mà gia hạn.” Theo số liệu của Totango nền tảng CS hàng đầu, khách hàng SaaS nào mà 90 ngày đầu tiên không đạt “First Value” — tức không cảm nhận được giá trị cụ thể từ sản phẩm thì xác suất churn lên tới 73%. Nói cách khác, nếu bạn bỏ mặc khách hàng suốt 10 tháng rồi mới nhào vô “chăm sóc” ở tháng 11, bạn đã thua cuộc từ tháng thứ 4.

Mình nhớ có lần mentor cho một startup HRTech ở Sài Gòn. Team CS của họ có 6 người, nhưng khi mình hỏi “Trong 100 khách hàng hiện tại, bao nhiêu khách đang active dùng tính năng cốt lõi?” thì cả team ngớ ra. Không ai biết con số đó. Họ chỉ biết ai sắp hết hạn hợp đồng thôi.

Màn 2: CS = Đội dọn rác cho Product

Sản phẩm làm ra UI/UX quá tệ, luồng đi rườm rà, khách hàng không tự onboarding được. Thay vì yêu cầu team Product sửa lại luồng, ban giám đốc tuyển thêm 5 bạn CS để “dắt tay” từng khách hàng qua từng màn hình. Đây không phải là Success, đây là dùng sức người để vá lỗi cho một cái sản phẩm tồi, cần thì làm thôi nhưng nó ko ổn để scale.

Hệ quả? Chi phí CS phình to, nhưng không ai nhìn vào gốc rễ vấn đề. Zoom trong giai đoạn đầu đã chọn cách tiếp cận hoàn toàn ngược lại: thay vì thuê đội CS khổng lồ để hỗ trợ onboarding, Eric Yuan ép team Product phải làm sao cho bất kỳ ai kể cả bà ngoại 70 tuổi cũng có thể vào meeting chỉ bằng 1 click duy nhất. Khi sản phẩm tự giải thích được, chi phí CS giảm xuống gần bằng 0 cho phần onboarding, và team CS được giải phóng để tập trung vào việc thực sự tạo giá trị: tư vấn cho khách hàng Enterprise cách tích hợp Zoom vào quy trình vận hành nội bộ.

Màn 3: Set KPI kiểu “Sói đội lốt cừu”

Khi bạn giao chỉ tiêu Doanh số cho team CS, bạn đã biến họ thành những con sói đội lốt cừu. Thay vì ngồi phân tích xem tại sao khách hàng A chưa dùng tính năng X để tối ưu công việc, bạn CS sẽ chỉ nhăm nhăm tìm cách nhét thêm một gói add-on dư thừa vào mồm khách hàng để đạt số.

Và đây là cái bẫy hệ thống (systemic trap) mà John Cutler hay nhắc đến: vấn đề không nằm ở cá nhân bạn CS đó lười hay xấu tính. Vấn đề nằm ở cấu trúc incentive của tổ chức. Khi CEO gắn thưởng của CS vào Upsell Revenue, CEO đang gửi đi một thông điệp rõ ràng: “Tao không quan tâm khách hàng có thành công hay không, tao chỉ quan tâm doanh số tháng này.” Bạn CS nào ngồi 3 tiếng phân tích usage data thay vì gọi 20 cuộc telesales sẽ bị đánh giá “không năng động”. Kết quả? Những người giỏi nhất những người thực sự hiểu CS sẽ nghỉ việc. Còn lại toàn Telesales đội mũ CS.

Màn 4: Thiếu data, thừa cảm tính

Một điều khiến mình ngạc nhiên là rất nhiều team CS ở VN hoạt động gần như mù dữ liệu. Không có health score cho từng khách hàng. Không track được feature adoption rate. Không biết khách hàng nào đang “chết lâm sàng” (vẫn trả tiền nhưng không dùng gì). Cũng ko chỉ mỗi VN mà thế giới cũng thế á Theo khảo sát của ChurnZero năm 2024 với hơn 1,000 CS professionals toàn cầu, 68% team CS tại các công ty có ARR dưới 10 triệu USD thừa nhận rằng họ không có Customer Health Score và đây chính là đặc điểm phổ biến nhất của nhóm công ty có churn rate trên 15%/năm.

Ở Việt Nam, con số này chắc chắn cao hơn nhiều. Mình từng hỏi 8 startup B2B SaaS: chỉ 1 cái có health score tử tế. 7 cái còn lại “chăm sóc khách hàng” dựa vào... trí nhớ của bạn CS và mấy dòng ghi chú trên Google Sheets hay cái Crm giả cầy.

The Patch: Trả CS về đúng bản chất

Để dừng vở kịch này lại, Product Manager và CEO cần thiết lập lại từ nền tảng. Gồm 4 cách như sau theo mình bạn có thể áp dụng.

T.D,
T10.2026

Suốt nhiều năm lăn lộn làm quản lý cấp trung rồi cấp cao, đây chính là cái kịch bản văn mẫu mà mình gặp nhiều nhất ở mấy anh Founder và Manager người Việt. Cái văn hóa Á Đông này nó ngộ lắm. Lúc nào cũng đề cao cái tình, sự gắn bó keo sơn, rồi tự huyễn hoặc coi công ty như một cái gia đình.

Nhưng nói thật bớt mộng mơ đi. Công ty không bao giờ là gia đình. Công ty là một đội bóng chuyên nghiệp và chúng ta có thể đối xử nhau chuyên nghiệp và đủ tử tế mới quan trọng. Mục tiêu duy nhất là vô địch. Và huấn luyện viên bắt buộc phải lạnh lùng đẩy những cầu thủ tốt nhất ra sân.

Thực ra, việc không dám cho ai đó nghỉ việc đôi khi không phải vì thương người ta, mà vì sếp không muốn tự làm mình khó chịu. Nhưng cái việc trì hoãn đó lại đang đẩy gánh nặng sang những người còn lại trong team.

Cái giá đắt đỏ của sự “nhân đạo giả tạo”

Thử tưởng tượng thế này. Một cái team Product có đúng 5 người. Bạn C là người yếu kém nhất, liên tục trễ deadline lồi lõm, code rồi spec thì bới ra nguyên một rổ bug. Nhưng vì bạn làm sếp, bạn yếu lòng, bạn không nỡ mở miệng sa thải. Chuyện gì sẽ tiếp diễn?

4 người còn lại sẽ phải còng lưng ra gánh vác phần việc của C. Họ phải nhịn nhục ở lại muộn để fix bug dọn rác cho C. Trong khi đó, đến cuối tháng C vẫn nhởn nhơ nhận lương đều đặn. Lúc này sự công bằng trong team gần như không còn. Những người làm tốt sẽ phải gánh thêm việc, còn người làm kém thì vẫn yên vị. Dần dần cả team sẽ hiểu rằng: làm qua loa cũng không sao. Và khi đã hiểu vậy thì ít ai còn muốn cố gắng nữa. Khi C liên tục tạo ra những kết quả tồi tệ mà không hề mảy may bị trừng phạt, cái bar tiêu chuẩn của cả team sẽ tự động hạ thấp xuống bằng đúng cái mức bết bát của C. Các thành viên khác sẽ ngầm hiểu: à, làm ăn hời hợt mà vẫn yên vị giữ được ghế, vậy thì mình cố sống cố chết cày cuốc để làm khỉ gì?

Uy tín của bạn người ngồi ghế Leader cũng chạm đáy, không nói được gì. Team sẽ nhìn vào cách bạn hành xử và nó ngầm đánh giá đơn giản vậy thôi. Một thằng sếp mà đến cái việc loại bỏ một kẻ yếu kém cũng không dám làm, thì đó là một thằng sếp nhu nhược. Chấm hết. Bạn tự tay vứt bỏ đi sự nể trọng của chính những anh em đang kề vai sát cánh gánh vác dự án cùng bạn.

Cho nghỉ tử tế, không phải phũ phàng

Sa thải khéo không phải là chuyện đuổi người ta ra khỏi cửa cho nhanh. Nó là chuyện làm sao để cả hai bên chia tay mà vẫn còn tôn trọng nhau.

Đầu tiên, phải có PIP Performance Improvement Plan. Đừng bao giờ chơi cái trò lôi đầu người ta vào phòng họp rồi bất thình lình ném toẹt một câu: Em bị sa thải. Cái đó gọi là tạo sốc và gieo rắc thù hằn. Hãy set một buổi 1-on-1 thẳng thắn, nói chuyện sòng phẳng như những người trưởng thành. “Anh thấy 2 tháng nay em làm chưa ổn — cụ thể là 3 việc này này này. Anh cho em 30 ngày để cải thiện, cần đạt được 3 mục tiêu này. Nếu 30 ngày mà vẫn không được thì mình phải chia tay nhau thôi.”

Cứ nói thẳng, nói rõ như vậy.. Và đôi khi, chính cái PIP sòng phẳng này lại là gáo nước lạnh giúp nhân sự bừng tỉnh vì có thể họ chỉ đang bị kẹt cứng trong một mớ rắc rối cá nhân nào đó mà chẳng có ma nào thèm hỏi han.

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

Làm sếp tử tế không bao giờ đồng nghĩa với việc làm một người sếp dễ dãi. Đôi khi việc cho người ta nghỉ cũng là cách để cả team còn có cơ hội đi tiếp. Không phải vì bạn lạnh lùng, mà vì bạn không thể để cả đội kéo nhau đi xuống. Cuối cùng, dù cho ai nghỉ thì cũng nên tôn trọng họ. Ở chỗ bạn họ chưa hợp, không có nghĩa là họ không giỏi ở nơi khác.

T.D,
T10.2026

P/s : Nếu bạn bị layoff vì bất cứ điều gì thì nó diễn ta việc bạn không còn phù hợp với tổ chức ở thời điểm đó. Hoặc chỉ đơn giản là bạn là người ít phù hợp nhất vậy thôi.

• Nếu lý do từ bạn thì chỉ bạn mới fix đc hãy thay đổi bản thân vì cuối cùng đi làm là thể hiện sự hiệu quả không phải nhân tình thế thái hay đi xây dựng các mối quan hệ không trên công việc.

• Nếu từ công ty và tổ chức thì xem như nó là vấn đề của công việc đó. Hãy tự tin làm lại.

• Nếu vì thị trường khó khăn thì bạn có tốt hay chưa tốt thì bạn điều có thể bị layoff hoặc bị letgo theo nghĩa nào đó. Hãy luôn xây dựng để bản thân bạn điều là sự lựa chọn đáng giá cho tổ chức mới.

Nếu có 1 lời khuyên chân tình cho ngừoi đi làm thì hãy.
Hãy xây dựng cách làm chuyên nghiệm giảm các việc chính trị không cần thiết, tập trung giá trị và value bản thân. Giá trị công việc bạn làm đc thì cuối cùng vẫn là thứ cuối cùng ghi nhận được.Và chính bạn nếu thấy tổ chức không phù hợp hãy cũng Letgo tử tế bàn giao hoàn chính. Ra đi trong tâm thế phù hợp không trở thành Zombie rồi kì vọng người khác Letgo mình tử tế, hãy tự Letgo …

“Thành công hiện tại là vô cùng humble. Phải làm tốt. Từ góc nhìn đội ngũ.”

Bùi Hải Nam, CEO SoBanHang

Hôm trước đội Product và Tech Lead ở Cty được ngồi nghe anh Nam chia sẻ chừng hơn một tiếng đồng hồ. Mình ghi vài cẩm nang khởi nghiệp của ảnh. Vì sao? Cái kiểu Founder thực chiến này, bình thường anh em lôi nhau ra quán cafe chém gió thì nhiều khi chỉ toàn nói chuyện business trên mây trên gió. Rất hiếm khi họ chịu rạch ròi, nói sâu về các thứ nội tại bên trong. Nhân buổi anh Nam chia sẻ dốc ruột cho anh em trong team, mình cố gắng note lại hết. Hi vọng sẽ những bài học xương máu này cho ae làm product.

Dân ngành làm sản phẩm, nghe tên anh Nam có khi thấy hơi lạ tai. Nhưng thử mò lên LinkedIn của ảnh mà xem, giật mình ngay. Một chuỗi startup kéo dài đằng đẵng gần chục năm trời. Mỗi cái ở một giai đoạn hoàn toàn khác biệt. Mỗi cái giải một bài toán khác nhau. Và cái nào cũng có cửa exit cực kỳ rõ ràng. OnPoint (e-commerce enabler, 2016). Datamart Solutions (vô địch Startup Việt 2018 của VnExpress, sau đó M&A với Intrepid Group). Swift247 (logistics hàng không, cũng M&A với Vietjet Air). Rồi gần đây nhất là SoBanHang (Finan Pte Ltd), cái ứng dụng quản lý bán hàng cho dân tiểu thương, quán quân Techfest Vietnam 2022, rinh về 4 triệu USD ngon ơ trong hai vòng gọi vốn đầu tiên.

Đấy. Mới chỉ là phần bề nổi mà bạn có thể search thấy trên báo mạng thôi.

Cái khiến mình nể phục tận sát đất hơn cả, lại là cái hành trình ẩn chìm trước đó. Anh Nam gốc gác là dân Toán. Rồi rẽ ngang sang làm Tài chính (chinh chiến qua Credit Suisse, HSBC, Techcombank). Sau đó lại bất ngờ nhảy dù qua mảng Tech (vào Lazada). Chuỗi chuyển đổi liên tục đó không hề mang cái màu sắc “nhảy việc tìm lương cao” tầm thường. Nó là cả một quá trình của một con người không ngừng tự đẩy mình ra, thử nghiệm cái đường biên giới giới hạn của chính bản thân. Từ phân tích dữ liệu còm cõi ở một ngân hàng đầu tư bên Singapore. Lên thẳng chức Director phụ trách Analytics tại ngân hàng Techcombank. Rồi lại băng qua làm VP, rồi Commercial Director tại Lazada. Mỗi một bước nhảy có vẻ vô cùng ngược đời đối với người ngoài đứng nhìn. Nhưng nếu cất công nối chúng lại với nhau, bạn sẽ thấy nó là một đường thẳng hoàn hảo. Hiểu data. Hiểu tiền. Hiểu thị trường. Và cuối cùng là xây sản phẩm.

Buổi chia sẻ hôm đó hoàn toàn không có ba cái slide màu mè bóng bẩy. Không có mấy cái framework xịn xò phức tạp. Anh Nam nói chuyện bằng đúng cái kiểu rút ruột từ những bài học đẫm máu của anh, và những thứ anh nhìn thấy nhan nhản ở ngoài đời. Mình tổng hợp lại những thứ đọng lại sâu nhất. Hi vọng thay a Nam share thêm cho các bạn.

Tinh thần doanh nhân hoàn toàn không phải thứ tự nhiên bạn có khi lập công ty

Cái đầu tiên anh Nam nhấn mạnh. Và nhấn đi nhấn lại rất nhiều lần. Chuyện entrepreneurial spirit (tinh thần doanh nhân). Nghe từ này thì sáo rỗng vô cùng. Nhưng ảnh đã kể bằng chính trải nghiệm vấp váp của bản thân.

Khoảng thời gian quan trọng nhất trong toàn bộ cái hành trình của ảnh, bất ngờ thay, không phải là lúc ảnh hì hục lập cái startup đầu tiên đâu. Mà chính là cái giai đoạn ảnh còn đang đi làm thuê ở Lazada.

Hồi đó, Lazada giai đoạn 2015-2016 là một cái chiến trường thương mại điện tử khốc liệt và đẫm máu nhất cái vùng Đông Nam Á này. Tiki, Sendo, Shopee — ông nào cũng điên cuồng lao vào burn tiền như thiêu thân. Anh Nam khẳng định chắc nịch rằng chính ở cái lò luyện Lazada đó, ảnh mới vỡ lẽ ra một điều. Tư tưởng làm doanh nhân là cái duy nhất định hình bạn, bất kể lúc đó bạn đang ngồi ở cái vị trí chết tiệt nào.

Nói thì nghe dễ. Nhào vô làm thì nó lại là một câu chuyện rất, rất khác.

Ảnh thẳng tay chẻ cái tư tưởng đó ra làm ba cái trụ cột. Thứ mà ảnh tự rèn giũa mỗi ngày, kể cả khi vẫn còn đang mang thân phận đi làm thuê.

Thứ nhất trong nguy bắt buộc phải có cơ. Không phải cái kiểu động viên tinh thần sến súa vớ vẩn rỗng tuếch đâu. Mà là khi mọi thứ xung quanh bạn đang bốc cháy hừng hực, bạn phải giữ cho đầu lạnh để tìm ra đâu là cái thứ duy nhất quan trọng nhất đáng để tập trung vào. Không phải tất cả mọi thứ đều đáng được lao vào cứu. Trong lúc khủng hoảng, chọn sai thứ tự ưu tiên thì chết lẹ hơn rất nhiều so với việc đứng im không làm mẹ gì cả.

Thứ hai accountability. Trách nhiệm cá nhân. Phải biết take ownership. Làm bất cứ cái thứ gì cũng phải làm với cái tâm thế coi nó quan trọng y như tài sản máu mủ của mình. Nhận lấy cái trách nhiệm lớn nhất. Chấm dứt ngay trò đổ lỗi. Đã làm thì phải làm cho đến tận cùng. Nghe quen tai không? Mấy cuốn sách dạy làm leadership đầy đường nào cũng nhai đi nhai lại. Nhưng, thử tưởng tượng cảnh bạn đang ngồi chết trân trong phòng họp lúc dự án cháy khét lẹt, KPI thì đỏ lòm rỉ máu, sếp lớn chỉ mặt hỏi “Đứa nào chịu trách nhiệm vụ này?” lúc đó, có bao nhiêu con người thực sự dám mạnh dạn giơ tay lên?

Thứ ba tự vấn mỗi ngày. Thứ mình đang cắm mặt làm tạo ra được cái giá trị quái gì? Bất kể là bạn đang làm vì tiền hay không, bất kể đang là một cậu nhân viên quèn hay một founder cao ngạo, cái câu hỏi đó phải chạy văng vẳng trong đầu bạn liên tục. Anh Nam nhấn giọng: “Phải luôn nhìn cơ hội, vì cơ hội không nhanh thì khó nắm bắt lại.”

Cá nhân mình ngồi nghe đến đoạn này mà tự nghĩ nhiều. Tự vấn kinh khủng. Đã từng có những cái giai đoạn mình cắm đầu chạy, chạy bục mặt theo roadmap mà quên bẵng đi việc phải khựng lại hỏi: cái khỉ gió này làm xong rồi thì người dùng họ sống khác đi ở cái chỗ nào? Cái câu hỏi đơn giản đó, đôi khi lại bị chìm nghỉm và nghiền nát bét trong cái máy xay thịt của quy trình Agile.

Xây liên tục cái mindset điên rồ của một serial founder

Anh Nam tự nhìn nhận thế này. Ảnh đã kiên trì xây liên tục 4-5 cái công ty startup rồi. Mindset của ảnh là mỗi sáng thức dậy tự nhủ mình đang làm cho chính mình. Không phải cày cuốc cho ai khác.

Nghe có vẻ hơi ngạo mạn. Nhưng mớ data ngoài kia lại hoàn toàn ủng hộ cái cách suy nghĩ này. Dựa theo một nghiên cứu từ đại học danh giá Harvard Business School, serial entrepreneur người khởi nghiệp liên tục có cái tỉ lệ thành công rơi vào khoảng 30%. Chênh lệch hẳn so với con số 18% thảm hại của đám first-time founder khởi nghiệp lần đầu. Hoàn toàn không phải vì bọn họ thông minh hay thiên tài hơn đâu. Mà là vì pattern recognition cái khả năng ngửi thấy mùi nguy hiểm và nhận ra mấy cái bẫy trước cả khi lỡ sa chân vào nó. Anh Nam từng chứng kiến Datamart của mình vươn lên tới đỉnh rồi bán mình M&A. Từng tận mắt thấy Swift247 cất cánh vèo vèo rồi hợp nhất trơn tru với Vietjet dù được nhiều hỗ trợ. Trải qua mỗi vòng đời trọn vẹn của một startup, ảnh lại đắp thêm cho mình một bộ cảm biến rủi ro mới tinh.

Nhưng trò đời, cái gì cũng có mặt trái của nó. Nghiên cứu đó cũng rành rành chỉ ra rằng cái lợi thế này nó không hề tịnh tiến mãi mãi. Bước sang cái founder thứ 4, thứ 5, đôi khi hiệu quả lại lao dốc. Tại sao? Vì họ bắt đầu quá tự tin, thậm chí tự mãn vào những cái kinh nghiệm cũ rích của mình. Anh Nam có vẻ nhận thức cực kỳ sắc bén về điều này khi ảnh khựng lại và nói: “Thành công hiện tại là vô cùng humble.”

7 cái sai cơ bản, chết người mà founder nào cũng hay mắc phải

Đây chính là cái phần đáng tiền nhất của cả buổi hôm đó. Anh Nam không thèm gọi đây là “bài học” màu hồng mộng mơ. Ảnh gọi thẳng mặt nó là “cái sai”. Sai từ cá nhân Founder. Sai lan ra từ hệ thống. Sai vì thằng nào cũng ôm khư khư cái tư tưởng ảo tưởng rằng mình là ngoại lệ.

Không thèm chấp nhận thực tại

Ảnh ngồi kể: “16 tháng 8 năm 2017, ngồi xem Jack Ma nói chuyện vẫn sướng lắm. Nhưng ra ngoài kia, biz đang chảy máu.”

Đây không phải là cái thứ chuyện bi quan tếu. Mà là câu chuyện bạn bắt buộc phải liên tục không được quyền chấp nhận cái thực tại theo cái nghĩa: đừng bao giờ tự lừa dối bản thân rằng mọi thứ xung quanh mình đang ổn. Người khác bảo “Sản phẩm 10 điểm” lập tức đi kiểm tra lại. Khách hàng xoa đầu khen “Thích sản phẩm này lắm” phải đè ra hỏi tiếp: Thích đến cái mức độ nào? Có đủ thích để rút ví trả tiền không?

Cái chìa khóa sinh tử ở đây là phải biết biến những cái không thể thành có thể. Bằng cái cách quái nào? Làm cho nó rẻ hơn. Làm cho nó nhanh hơn. Tư duy ở đây là chi phí rẻ hơn chứ tuyệt đối không phải là thỏa hiệp cho chất lượng rẻ tiền đi. Một khi bạn đẩy bản thân vào thế chân tường, ép não phải nghĩ ra cái cách giải bài toán với vỏn vẹn 1/10 chi phí ban đầu, thực tại sẽ tự động bóp méo và thay đổi theo.

Sổ Bán Hàng là một cái ví dụ sống sờ sờ. Đẻ ra ngay giữa tâm bão Covid-19, hoàn toàn cấm cửa không thể đi gặp khách hàng trực tiếp. Tình thế ép buộc họ phải thiết kế ra một cái app tinh gọn, đơn giản đến cái mức bất kỳ ai tải về cũng tự dùng được rẹt rẹt trong vòng 5 phút mà đéo cần... à nhầm, không cần đến một tờ giấy hướng dẫn nào. Cái trói buộc “không gặp được user” tưởng chừng chí mạng đó lại trở thành cái lợi thế cạnh tranh vô địch: sản phẩm dễ xài đến cái mức cô tiểu thương bán bánh mì đầu hẻm cũng tải về xài trơn tru.

Thử và sai, nhưng tuyệt đối không được chờ đợi

Tinh thần thứ hai. Phải thấy được kết quả càng sớm càng tốt. Dẹp mẹ cái trò ngồi phòng máy lạnh planning 6 tháng trời rồi mới dám hắng giọng launch. Anh Nam nói một câu cực kỳ sắc và thẳng: “Thử và sai là một tinh thần. Không chờ đợi.”

Lấy Datamart năm 2017 làm minh chứng sống. Ban đầu, nguyên một đội ngũ anh em hì hục xây cái nền tảng bán hàng đa kênh PowerSell. Bơm AI và Big Data xịn xò vào để giúp đám seller tự động hóa quy trình trên mớ sàn Lazada, Shopee, Tiki. Sản phẩm lộng lẫy đó giật luôn cúp quán quân Startup Việt 2018 do VnExpress tổ chức, ẵm kèm cái gói đầu tư 5 tỷ đồng thơm phức. Nhưng nằm sâu đằng sau cái cúp vàng lấp lánh đó, là cả chục lần pivot đau đớn, hàng trăm lần cắn răng test concept thất bại sấp mặt, trước khi họ thực sự tìm ra cái product-market fit ngon lành.

Think Big, Start Small

Câu này thì ông nào cũng thuộc nằm lòng như kinh thánh. Nhưng thề luôn, rất ít kẻ làm tới nơi tới chốn được cái chữ “small”. Anh Nam phán một câu xanh rờn, rất thẳng: “Nếu không làm rõ thì burn bao nhiều tiền cũng không biết.”

Think Big ở đây có nghĩa là bạn bắt buộc phải có một cái vision khổng lồ và rõ ràng. SoBanHang không được sinh ra chỉ để làm một cái app ghi sổ quèn, vision của nó là một cái hệ điều hành tài chính đồ sộ cho hàng triệu tiểu thương. Nhưng Start Small là như thế nào? Là cái đợt đầu tiên tung ra, chỉ làm đúng duy nhất một thứ thôi: ghi chép thu chi thẳng trên điện thoại. Thế thôi. Chấm hết. Không đẻ thêm bán hàng online, không rườm rà thanh toán điện tử, không nhét AI học máy gì hết. Xây một thứ duy nhất cho thật đã, thật xịn, rồi từ từ hãy há mồm mở rộng ra.

Remind và remind nữa

Cái này nghe tưởng chừng nhỏ như con thỏ mà thực ra nó giết startup hàng loạt ngoài kia. Anh Nam bảo: “Giao việc mà không remind là không đơn cử.”

Bỏ ngay cái suy nghĩ trade-off vớ vẩn giữa trust (sự tin tưởng) và micromanage (quản lý vi mô). Trong cái lò startup, mọi thứ nó chạy nhanh cuồng phong đến mức, nếu bạn giao xong một cái task rồi ung dung giả định người kia sẽ tự nhớ, sẽ ngoan ngoãn nộp đúng deadline, sẽ chủ động kêu ré lên báo cáo khi có vấn đề — bạn đang chơi một ván bài đánh bạc với tử thần. Phải cực kỳ hệ thống. Phải cực kỳ rõ ràng rành mạch. Giao cái gì. Cụ thể deadline là bao giờ. Output mong đợi ra cái hình thù sao. Và phải đè ra remind liên tục.

Thú thật là mình cũng từng dính trấu vụ này. Hồi cắm mặt build team ở Onemount, mình quá tin tưởng giao hẳn một module lõi cho một ông senior lead rồi yên tâm lặn mất tăm suốt hai tuần. Lúc ngoi lên quay lại check thì mọi thứ đã trôi tuột đi hoàn toàn chệch hướng. Không phải ông lead đó dở đâu mà là vì cái context của cty nó biến đổi nhanh đến mức, trôi qua hai tuần cứ như trải qua cả một thế kỷ vậy.

Cash is King (Tiền mặt là vua)

Đây chính là cái đoạn anh Nam nói với tone giọng nặng nề nhất. Giọng trầm hẳn xuống. Chậm lại.

“Nhiều khi công ty sa đà vào bài toán xây nhiều quá. Anh em tech tự hào feature này xịn, architecture kia clean. Nhưng phải sống. Phải có tiền.”

Dòng tiền là thứ phải được plan chặt chẽ. Đừng quan tâm đến bất cứ cái gì khác ngoài dòng tiền đang chảy. Anh Nam vứt ra một câu mà làm cả cái phòng họp chết lặng: “Tôi cố gắng tốt, còn xin. Không còn cơ hội phải đi kiếm tiền.”

Nếu sản phẩm làm ra không đẻ ra tiền thì vĩnh viễn không ngóc đầu lên nổi. Chấm.

Cái mớ data toàn cầu cũng xác nhận y chang thực tế khốc liệt này. Khoảng 29-38% startup chết sặc tiết vì hết nhẵn tiền. Và có tới 82% vụ thất bại có dính líu trực tiếp đến kỹ năng quản lý dòng tiền quá kém cỏi. Không hề phải do thiếu idea hay ho. Không hề do thiếu talent xuất chúng. Họ chết vì thiếu tiền. Hoặc nói chính xác và cay đắng hơn: do Founder đéo biết đếm tiền.

SoBanHang từng trải qua giai đoạn “suýt chết” — cái này chính anh Nam đã dũng cảm thừa nhận trong một bài phỏng vấn trên tờ Doanh Nhân Sài Gòn. Chuyện xảy ra khi tốc độ tăng trưởng user nóng quá, nhanh ngoài tầm kiểm soát, chi phí server và vận hành phình ra như thổi bong bóng. “Càng nhiều user đăng ký, gánh nặng chi phí càng lớn, tiền đốt càng nhanh.” Bài học đắt giá nhất, xương máu nhất của ảnh hoàn toàn không phải là lúc đứng lên bục ẵm cái quán quân Techfest. Mà là vào cái buổi tối tĩnh lặng ngồi đếm từng đồng tiền còn sót lại trong tài khoản và rợn người nhận ra cái runway chỉ còn cầm cự đúng vài tháng nữa là tắt thở.

Không sợ cạnh tranh, sợ nhất là không có nổi một thằng đối thủ

Cái này nghe cực kỳ phản trực giác cho những ai không có kinh nghiệm.

Anh Nam bảo: “Làm startup sợ nhất là làm thứ không có đối thủ. Không có đối thủ thì có vẻ thị trường không tồn tại.”

Bạn phải luyện cho bằng được một năng lực đặc thù. Phải tự tạo ra một cái competitive edge thật sự sắc nét và rõ ràng. Nhưng nếu bạn cất công scan banh chành hết cái thị trường mà không mót ra nổi bóng dáng một thằng nào đang rục rịch làm cái thứ tương tự bạn thì đó là một tín hiệu đáng lo ngại hơn gấp vạn lần so với việc bị bủa vây bởi 10 đối thủ. Đơn giản thôi. 10 thằng đối thủ gào thét cắn xé nhau chứng minh rành rành rằng cái thị trường đó là có thật. Còn không có mống nào? Hoặc bạn là một thiên tài ngàn năm có một nhìn xa trông rộng trước nhân loại cả 10 năm. Hoặc cái khả năng cao hơn và phũ phàng hơn rất nhiều bạn đang cắm đầu đi vào một cái ngõ cụt tăm tối mà vẫn tự huyễn hoặc hít hà ảo tưởng đó là “đường ngách.”

Tránh hết đường ngách, đi thẳng vào đường tắt. Đau nhói. Cay.

Đạo đức tài chính sống còn của Founder

Cái cuối cùng. Và có lẽ cũng là cái thứ khó nói nhất. Anh Nam trực tiếp động đến câu chuyện vận hành cái startup bằng tiền cả tiền dốc túi từ founder, và tiền rót vào từ nhà đầu tư.

“Phải rất rõ ràng với nhà đầu tư. Làm nhanh thì phải vay nợ, phải trả nợ. Mindset quan trọng nhất: luôn phải exit được rõ ràng. Founder phải ethical. Vay gì phải trả thế.”

Đây chính xác là cái mảng tối mà cả hệ sinh thái startup Việt Nam đang thiếu trầm trọng. Lên mặt báo dạo gần đây nhan nhản đầy rẫy những phi vụ bóc phốt founder nhận vốn ngàn đô rồi quản lý tài chính nhếch nhác, mờ ám. Anh Nam nói toạc ra luôn trong cái bài phỏng vấn trên HTV: “Có một lỗi mà rất nhiều startup mắc phải đó là quản lý tài chính không rõ ràng và minh bạch.” Khi nhà đầu tư đã mất sạch niềm tin, thì không phải chỉ một cái startup lẻ loi đó lăn ra chết mà kéo theo cả cái hệ sinh thái bị vạ lây, chết chùm chết chùm với nhau.

Nếu bị ép chọn đúng một thứ quan trọng nhất để thành công?

Đến cuối buổi, có một bạn bạo gan hỏi anh Nam cái câu hỏi kinh điển đó.

Ảnh trả lời gọn lỏn, không tốn một giây ngần ngại: “Quản trị tài chính là key. Idea là một trong những thứ kém hiệu quả nhất.”

Rồi chốt thêm một câu đinh: “Founder phải đi bán hàng. Phải tìm cơ hội. Phải giúp công ty chọn hướng đi.”

Ngay lập tức có bạn trong phòng bật thắc mắc. Ủa vậy nếu founder bản chất không có nền tảng học về tài chính, không hề giỏi ba cái chuyện mồm mép bán hàng thì sao? Anh Nam cười khẩy: “Cái này không phải không học được. Con người luôn thay đổi. Nếu 30 tuổi rồi mà bảo không thay đổi được thì không đúng.”

Ảnh kể thêm có từng làm một bài test tính cách. Ngó lại, phần lớn mọi người trong cái phòng họp này đều rơi tõm vào cái nhóm C — cẩn thận, tuân thủ răm rắp quy trình, thích phân tích nát bét vấn đề trước khi chịu hành động. Nhưng cái dân founder thứ thiệt thì thường xuyên chui vào nhóm D — dũng mãnh sẵn sàng take risk, da mặt dày chịu áp lực như trâu, và có khả năng ra quyết định chớp nhoáng dù thiếu thông tin trầm trọng. “Hoặc là là người sẵn sàng take risk, hoặc là người thất bại. Phải tập. Phải có kinh nghiệm. Các thứ đều là skill.”

Ngồi nhai đi nhai lại mớ kiến thức suốt một tiếng đồng hồ, mình rút ra được đúng một cái chân lý giản dị nhưng đau điếng. Một cái startup sống được lâu hoàn toàn không phải nhờ vào ba cái idea đột phá trên trời rơi xuống. Nó tồn tại được là nhờ vào thằng founder biết quản lý chặt từng đồng tiền, biết ngẩng mặt lên nhận trách nhiệm, và có đủ sự lỳ lợm kiên nhẫn để pivot liên tục cho đến lúc mò ra được cái thứ thị trường thật sự cần.

Sống càng lâu thì mới lên hàng lão làng được.

Anh Nam hì hục xây 5 công ty. Không phải vì ảnh sở hữu IQ cao hay giỏi giang hơn ai. Mà là vì mỗi lần ngã sấp mặt, ảnh lồm cồm đứng dậy nhanh hơn cái lần ngã trước đó một chút xíu. Và cái quan trọng hơn tất thảy — ảnh không bao giờ não cá vàng mà quên đếm tiền trong ví trước khi mơ mộng ảo tưởng về tương lai xán lạn.

Bạn đang cắm mặt xây product. Thế dòng tiền của bạn hiện tại sống sót được bao nhiêu tháng nữa? Bạn có đủ can đảm nhìn thẳng vào cái con số tàn khốc đó không, hay vẫn đang tự ru ngủ mình bằng mấy cái dashboard MAU tăng vọt xanh lè giả tạo?

T.D,
T10.2026

Anh em Tech chốt rồi nha. Mình sẽ tự build hệ thống Data Analytics thay vì xài Mixpanel hay Amplitude. Mấy cái nền tảng SaaS đó chém giá ác quá, scale lên tí là ngốn cả ngàn đô mỗi tháng. Bản chất trò này chỉ là bắn event rồi insert vô Database thôi mà. Tự code cỡ 2 tháng là xong, vừa tiết kiệm mà data lại nằm trong nhà mình, an tâm hơn nhiều.

Chắc nhiều ae sẽ nghe cái văn mẫu này là từ một tay CTO ở công ty nào đó. Anh chàng CTO có thể là một kỹ sư giỏi, code sạch, tư duy sắc bén khỏi bàn. Nhưng luôn có thể một cái bệnh nan y mà 9 trên 10 Tech Lead xứ này đều mắc: Hội chứng Not-Invented-Here đồ ko phải do team nhà code thì kiên quyết ko xài có xài cũng chê lên xuống.

Thế là cả bầy xúm lại build hệ thống Tracking từ con số không. Hứa 2 tháng. Kết quả thì sao? Sang tháng thứ 4, hệ thống rục rịch lên production. Nhưng hễ bên Marketing đòi xuất báo cáo Funnel là dev lại hì hục cắm mặt viết SQL mất đứt cả buổi sáng. Đòi xem Real-time Dashboard á? Server treo đứng luôn vì nghẽn lock database. Tay CTO lúc đó chỉ xoa tay cười trừ bảo do server chưa tuning, xin thêm mấy con máy ảo rồi Sprint sau đẩy qua tool data nào đó là mượt ngay.

Cuối cùng cái side-quest đó ngốn hết nửa năm của 4 ông Data Engineer cứng cựa nhất team. Tính sương sương cả tỷ bạc tiền lương. Đổi lại được một đống bòng bong ko ai dám xài vì số liệu lệch bét nhè. Tính năng thì xách dép cho gói Free của Amplitude.

Thất bại. Hoàn toàn.

Code chưa bao giờ là Tài Sản

Mình thấy nhiều ae làm product thậm chí cả mấy sếp CEO tay ngang toàn tự hít copium với nhau rằng công ty tech thì code là lõi, nắm càng nhiều code thì valuation càng cao.

Hoang tưởng.

Thế giới này tàn khốc lắm, code là cục nợ. Bạn gõ ra một dòng code hôm nay tức là bạn vừa ký cái giấy nợ kỹ thuật cho tương lai. Phải còng lưng ra maintain nó. Phải hì hục fix bug mỗi đợt iOS hay Android nó update OS. Rồi thử đến cái ngày cậu dev viết ra đống code đó đâm đơn nghỉ việc đi, cả đám ở lại nhìn mớ legacy code nát bươm đó chắc khóc thét.

Bữa đọc báo cáo bên Gartner chỉ ra chi phí bảo trì nó ăn hết 80% ngân sách vòng đời của một cái phần mềm tự trồng. Tám mươi phần trăm. Cái số liệu đó nó tát thẳng mặt những ai hay mở miệng ra khoe vụ tự làm cho tiết kiệm.

Nhìn những gã khổng lồ mà học. Netflix bự chà bá lửa vậy có rảnh đi tự build server đâu, xài AWS hết. Uber hồi đầu khởi nghiệp cũng cắm API Stripe vô mà thu tiền chứ code cổng thanh toán làm gì. Tụi nó hiểu một cái đạo lý rất cơ bản: Cái gì đẻ ra tiền và là lợi thế cạnh tranh cốt lõi thì giữ chặt. Còn ba cái tool hỗ trợ râu ria thì quẹt thẻ mua cho lẹ. Đơn giản vậy thôi.

Động cơ thật sự: Có thể là bài toán làm đẹp CV hay đôi khi là mong muốn chứng tỏ bản thân.

Nhìn sâu vô cái động lực hệ thống một tí, bạn sẽ thấy sự thật chả ai kiếm chứng: Cái ghế của PM và cái ghế của CTO đôi khi phải lệch nhau và cũng có thể ít khi ngồi chung một mâm.

PM lúc nào cũng muốn xài SaaS để ship tính năng lẹ lẹ, vứt ra thị trường đo lường. Chạy ngon thì PM hưởng credit. Nhưng CTO thì khác. Cắm API của bên thứ ba vô hệ thống nó dễ ợt, chán ốm. Nó ko làm mấy ổng có cái hype của một kỹ sư siêu phàm. Phải tự tay design architecture phức tạp, tự tay thiết kế database, giải ba cái toán hóc búa từ số không... cái cảm giác đó nó gây nghiện. Khổ nỗi là mấy ổng đang phê pha bằng tiền của công ty.

Nói toẹt ra nhé, đầy rẫy Tech Lead đang lấy ngân sách startup đi làm R&D để build một phần CV cho cá nhân.

Nghĩ thử coi lúc đi phỏng vấn chỗ mới, cái dòng CV ghi “Tự thiết kế hệ thống tracking chịu tải chục triệu requests từ số không” nó khét lẹt và ngạo nghễ hơn gấp vạn lần so với câu “Tích hợp thành công Mixpanel”.

Thành thử ra thay vì lo giải bài toán cho user, các ông xúm lại vẽ ra mấy cái rủi ro viễn vông kiểu lỡ bên SaaS sập thì sao, lỡ nó đổi bảng giá thì sao... đem đi hù mấy sếp. Mà cái rủi ro lớn nhất là công ty khô máu chết ngắt trước khi tìm thấy PMF thì chẳng thấy ông nào đả động tới. Chỗ này nó xoáy thành cái lặp vô tận: Build xong maintain ko nổi -> đắp vá -> code nát bét -> dev mới vô ko hiểu lại đè ra code tiếp. Xoáy thẳng xuống lòng đất.

Lằn ranh đỏ để cãi tay đôi với Tech

Làm PM, bạn phải đóng vai ác gác cổng cái tỷ suất đầu tư của sản phẩm. Ko thể để mấy ông Tech tự bơi dựa trên đam mê cá nhân đc. Vạch lằn ranh rõ ràng ra. Cứ lấy một câu duy nhất này mà nã: Việc tự build chức năng này có giúp mình dập chết đối thủ và bắt user chọn mình thay vì bên khác ko?

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!

Subscribe now

T.D,
T9.2026

Set giá 50k thôi cho dễ kéo user anh em nhỉ? Chứ bán bằng giá thì ai thèm dùng.”

B2B SaaS mang cái mô hình giá Pricing Model gởi để nhờ giới thiệu ai mua không. Bạn ấy có vẻ rất tự hào vì đã tìm ra một chiến lược đột phá: Bán rẻ đứt đuôi đối thủ để cướp thị phần.

Mình nhìn chằm chằm vào cái giá và dự phóng tài chính của bạn, lắc đầu ngán ngẩm. “Với cái giá 50k/tháng này, em tính chạy Ads tốn bao nhiêu tiền để có một user? Em tính lấy ngân sách đâu để support họ khi app lỗi? Em định trả lương team Dev bao nhiêu để họ duy trì cái hệ thống này?”

Giống như 99% các startup Việt Nam khác, bạn đang bị kẹt trong một nỗi sợ hãi nguyên thủy: Sợ tăng giá. Sợ bị chê đắt. Sợ user bỏ đi.

Và kết quả là, các bạn chọn cách tự sát từ từ: Chết vì cạn tiền trước khi kịp tìm ra Product-Market Fit (PMF).

Lời nguyền Cost-Plus Pricing

Hầu hết những người làm Product ở Việt Nam đều bước ra từ nền tảng Kỹ thuật. Chúng ta rất giỏi giải quyết vấn đề bằng code, nhưng lại cực kỳ mù mờ về dòng tiền.

Khi phải định giá một tính năng hay một gói dịch vụ, tư duy mặc định của chúng ta thường là Cost-Plus Pricing (Định giá cộng chi phí). Cách tính này rất ngây ngô: À, server AWS tốn từng này, lương Dev tốn từng này, chia cho 1000 user thì cost mỗi người là 20k. Mình bán 40k là lãi gấp đôi rồi! Quá ngon!

Nhưng ở thế giới thật, Cost-Plus Pricing là công thức hoàn hảo để sập tiệm trong tương lai. Theo nghiên cứu của ProfitWell (nay là Paddle) phân tích hơn 10,000 công ty SaaS: các startup định giá bằng phương pháp cost-plus có tỷ lệ churn cao hơn 2x so với những công ty dùng value-based pricing.

Nó bỏ qua chi phí chìm, bỏ qua chi phí R&D, và quan trọng nhất: Nó bỏ qua chi phí Mua lại khách hàng CAC. Nếu bán 40k, bạn chỉ có vỏn vẹn 20k tiền lãi để chạy Ads, làm marketing, trả hoa hồng Sales. Trong thời buổi giá quảng cáo Facebook/Google đắt đỏ như hiện nay, 20k không đủ để ai đó thèm liếc nhìn cái banner của bạn, chứ đừng nói là click vào và trả tiền.

The Breaking Point: Lầm tưởng về Khách Hàng Rẻ.

Khi bạn dùng giá rẻ để cạnh tranh, bạn không cướp được thị phần của đối thủ đâu. Bạn chỉ đang thu hút những khách hàng tồi nhất trên thị trường.

Đây là một thực tế tàn nhẫn Reality Check mà mình đã rút ra sau hàng chục dự án: Khách hàng sẵn sàng mặc cả từng đồng cũng chính là những người sẽ bào sức team bạn nhiều nhất.

Họ sẽ gọi điện chửi bới CSKH lúc 12h đêm vì một lỗi nhỏ. Họ sẽ đòi hỏi bạn phải code thêm hàng tá tính năng custom chỉ cho riêng họ. Và ngay khi đối thủ của bạn tung ra một cái voucher giảm giá 5%, họ sẽ lập tức bỏ app của bạn mà đi không một lời từ biệt.

Bạn sợ tăng giá vì sợ mất user? Đúng, tăng giá sẽ làm rụng một lượng user. Nhưng hãy hỏi ngược lại: Những user rời bỏ bạn vì mức chênh lệch 50k/tháng, liệu họ có thực sự nhìn thấy giá trị của sản phẩm không? Hay họ chỉ ở lại vì bạn đang làm từ thiện rẻ bèo?

Sự thật là, giá cả Pricing không chỉ là một con số trên bảng P&L. Nó là một bộ lọc. Patrick Campbell, CEO ProfitWell, gọi đây là Price as a Filter theo nghiên cứu của ông trên 18,000+ doanh nghiệp SaaS chỉ ra rằng các công ty tăng giá 10-20% chỉ mất trung bình 1-2% lượng khách hàng, trong khi doanh thu tổng tăng 15-25%.

Khi bạn tăng giá, bạn đang lọc ra những khách hàng thực sự đau đớn vì vấn đề mà bạn đang giải quyết. Họ sẵn sàng trả tiền để mua sự yên tâm, mua thời gian, mua sự tiện lợi. Đó mới là những user bạn cần giữ lại để build PMF.

The Patch: Định giá theo giá trị

Để thoát khỏi vòng lặp “rẻ = chết”, các Product Manager và Founder cần phải tái thiết lập lại tư duy về Pricing. Giá cả là một phần của Product. Nó phải được thiết kế, test, và iterate liên tục giống như bất kỳ tính năng nào khác.

Dưới đây là framework để bạn thoát khỏi hội chứng sợ tăng giá:

1. Định giá dựa trên Nỗi đau hay gọi là Value-Based Pricing

Đừng bao giờ hỏi: “Tính năng này tốn bao nhiêu công Dev để làm?” Hãy hỏi: “Tính năng này tiết kiệm cho khách hàng bao nhiêu tiền/bao nhiêu thời gian mỗi tháng?”

Nếu phần mềm SaaS của bạn giúp một doanh nghiệp tiết kiệm được 1 nhân sự lương 10 triệu/tháng, thì việc bạn thu phí 2 triệu/tháng là quá rẻ. Khách hàng B2B không quan tâm bạn tốn bao nhiêu tiền server. Họ quan tâm bạn mang lại cho họ cái gì. Nếu bạn tạo ra giá trị 10 đồng, bạn hoàn toàn có quyền thu về 2-3 đồng.

2. Dùng Giá cao làm vũ khí Marketing

Đôi khi, định giá cao lại là một lợi thế cạnh tranh. Hãy nhìn Apple. Họ không bao giờ bán rẻ. Định giá cao gửi một tín hiệu ngầm đến não bộ người dùng: “Sản phẩm này xịn, cao cấp, đáng tin cậy.” Trong mảng B2B, nếu đối thủ bán 100k, bạn bán 300k. Kèm theo đó là lời cam kết: “Chúng tôi đắt gấp 3, vì hệ thống của chúng tôi không bao giờ sập vào mùa sale, và team CSKH của chúng tôi trả lời trong vòng 5 phút.” Doanh nghiệp sẵn sàng trả 300k để mua sự yên tâm, thay vì trả 100k để rước bực vào người. Tin mình đi, các anh IT Director rất ghét đồ rẻ vì lỡ sập thì các anh ấy mất việc. Nhưng đã định giá cao thì sản phẩm bạn phải xứng đáng. Đừng treo đầu dê bán thịt chó và sản phẩm tệ hại dùng Vibecode nữa vời rồi nói nó như sản phẩm đứng đầu thế giới.

3. Nguyên tắc Tăng giá đến khi họ kêu la.

Nếu bạn vừa ra mắt sản phẩm và 100% người hỏi giá đều gật đầu mua ngay lập tức, bạn đang định giá quá thấp. Bạn đang để tiền rơi lả tả trên bàn. Theo kinh nghiệm của mình, mức giá tối ưu là khi có khoảng 20-30% khách hàng tiềm năng nhăn mặt chê đắt. Lúc đó, bạn đã tiệm cận được đường cong Willingness to Pay tối đa. Hãy liên tục test các mức giá mới với user mới cho đến khi lực cản chốt sale trở nên quá lớn, rồi lùi lại một bước. Và việc tăng giá xứng đáng với cái bạn đang cải thiện từng ngày.

Tóm lại, trong trò chơi Product, sợ hãi tăng giá là con đường ngắn nhất dẫn đến nấm mồ startup. Bạn không thể nuôi một team Dev tài năng, một hệ thống ổn định với những đồng bạc cắc.

Nếu bạn tự tin sản phẩm của mình giải quyết được một nỗi đau có thật, hãy ngẩng cao đầu và thu phí cho xứng đáng. Đừng để cái tôi của một kẻ làm kỹ thuật thích được nhiều người dùng bóp chết cơ hội sống sót cần dòng tiền của cả công ty.

Và nếu ngày mai bạn tăng giá mà khách hàng vẫn ở lại? Chúc mừng, bạn đã thực sự tìm thấy Product-Market Fit.

T.D,

T9.2026

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á.