Viết code đã dễ hơn. Nhưng chiến thắng với sản phẩm AI thì chưa.

Gần đây, Boris Cherny, người điều hành Claude Code tại Anthropic, đã nói một điều khiến tôi phải dừng lại suy nghĩ:

“Tôi nghĩ đến thời điểm này có thể nói rằng việc viết code phần lớn đã được giải quyết. Ít nhất với kiểu lập trình tôi làm, đó gần như là một vấn đề đã được giải quyết vì Claude có thể làm được. Và giờ chúng tôi đang nghĩ đến bước tiếp theo — điều gì nằm sau đó.”

Ông không nói một cách dè dặt. Đó là thực tế công việc của ông: Claude viết code, review code, tạo bug report và thậm chí đề xuất nên ship gì tiếp theo. Mọi người trong team đều code — kể cả người làm tài chính.

Theo Boris, đến cuối năm nay, chức danh “software engineer” có thể biến mất và được thay bằng “builder”.

Chúng ta đã nghe quá nhiều dự đoán về việc các nghề nghiệp “biến mất”. Nhưng nếu nhận định của ông dù chỉ đúng một phần, thì nó đặt ra một câu hỏi lớn đã bị che lấp bởi hype AI suốt hai năm qua:

Khi việc “xây dựng” không còn là giới hạn nữa, điều gì mới là giới hạn?

Khi việc xây dựng không còn là rào cản

Một tài khoản có nhiều góc nhìn sắc sảo về sản phẩm trên X là Signull từng viết rằng vai trò quan trọng tiếp theo sẽ là người quyết định nên xây cái gì.

Điều thú vị là anh ấy cho rằng vai trò đó không phải product manager. Nhưng mô tả này thực ra rất giống với vai trò mà nhiều CPO và Product Lead đã theo đuổi suốt thập kỷ qua — một vai trò kết hợp:

• tầm nhìn sản phẩm

• cảm nhận thiết kế

• hiểu biết sâu về domain

Dù gọi nó là gì, điểm mấu chốt vẫn là:

Vai trò product thinker / builder mà nhiều người cho rằng sẽ biến mất có thể trở nên quan trọng hơn bao giờ hết.

Nhưng cả Boris và Signull đều cho rằng biên giới tiếp theo là quyết định nên xây cái gì.

Tôi không nghĩ vậy.

AI cũng đang giúp quyết định “nên xây gì”

Ngày nay, các PM giỏi đã dùng AI để:

• phân tích bản ghi cuộc gọi bán hàng

• đọc Slack threads

• tổng hợp ticket hỗ trợ

• phân tích backlog Jira

• đọc feedback từ khách hàng

AI có thể:

• đề xuất experiment

• phát hiện pattern

• tạo hypothesis nhanh hơn bất kỳ chu kỳ planning nào

Con người vẫn đưa ra quyết định cuối cùng, nhưng vai trò này đang dần trở thành reviewer.

Nói cách khác, “quyết định xây gì” cũng đang được AI hỗ trợ.

Vấn đề thực sự nằm sau khi bạn đã ship sản phẩm.

Khoảng cách giữa “AI feature” và “AI product”

Một nghiên cứu năm 2025 của MIT NANDA initiative dựa trên:

• 150 cuộc phỏng vấn lãnh đạo cấp cao

• 300 dự án AI triển khai công khai

kết luận rằng:

95% pilot AI trong doanh nghiệp không tạo ra ROI đo lường được.

Lý do là có một khoảng cách lớn giữa:

• một AI feature hoạt động được

• và một AI product mà người dùng tin tưởng, trả tiền và tiếp tục sử dụng

Khoảng cách này đầy rẫy những trở ngại mà không có AI hay product judgment nào tự động giải quyết được.

Dưới đây là 7 “headwinds” (lực cản cấu trúc) mà các team AI thường gặp.

Headwind 1: Bạn ship nhiều hơn nhưng khách hàng không có thêm sự chú ý

Một doanh nghiệp trung bình hiện nay dùng 100+ SaaS apps.

Nhân viên dành phần lớn thời gian chỉ để chuyển đổi giữa các công cụ.

Khách hàng không chờ update của bạn. Họ đã quá tải.

Vì vậy, mỗi release mới đều phải cạnh tranh với sự mệt mỏi của người dùng.

Giải pháp không phải là ship ít hơn, mà là ra mắt có kỷ luật hơn.

Ví dụ framework launch:

• Tier 1: sản phẩm mới → PR + chiến dịch lớn

• Tier 2: workflow thay đổi đáng kể → webinar + targeted push

• Tier 3: update nhỏ → changelog

• Tier 4: ship âm thầm

Nguyên tắc:

Bạn nên announce ít hơn số lần bạn ship.

Headwind 2: Biên lợi nhuận bị bào mòn

SaaS truyền thống có 75–85% gross margin.

AI SaaS thường chỉ 25–40%.

Mỗi lần gọi LLM là chi phí biến đổi.

Nếu:

• 10.000 khách hàng

• mỗi người 10 inference/ngày

→ bạn có thể tiêu tốn hàng chục nghìn USD token mỗi tuần.

Ví dụ điển hình là Replit.

Khi họ ra mắt AI coding agents, gross margin dao động từ 30% đến âm vì chi phí compute tăng mạnh.

Họ phải chuyển sang hybrid pricing gắn với compute usage.

Một số nguyên tắc:

• match model với task

• dự đoán cost ở scale trước khi launch

• cache query lặp lại

• theo dõi cost theo user và request

Headwind 3: Monetization không rõ ràng

Nhiều SaaS đã thêm AI.

Nhưng chỉ khoảng 1/7 công ty monetise thành công.

Các team thành công chuyển sang:

• outcome-based pricing

• hybrid pricing

Ví dụ:

• Zendesk: $1.50 mỗi interaction được giải quyết

• Intercom Fin: $0.99 mỗi query resolved

Nguyên tắc:

Giá nên gắn với giá trị tạo ra, không phải “chúng tôi có AI”.

Headwind 4: Messaging giống hệt nhau

Trang chủ của nhiều AI product ngày càng giống nhau:

• AI-powered

• faster

• smarter

• automate everything

Trong khi layer feature ngày càng giống nhau, sự khác biệt phải đến từ positioning.

Ba nguyên tắc:

1. Nói bạn thay thế cái gì
   Ví dụ Loom: “Skip the meeting. Send a Loom.”

2. Tuyên bố mà đối thủ không thể nói
   Ví dụ Harvey AI: legal reasoning cho luật.

3. Cụ thể hóa claim AI

“AI-powered” không nói lên điều gì.

Headwind 5: Khoảng cách niềm tin

AI có vấn đề về độ tin cậy.

Trong nhiều tác vụ phức tạp, hallucination vẫn ở 10–20%.

Trong nghiên cứu pháp lý, LLM chung có thể hallucinate tới 58–82%.

Ví dụ nổi tiếng:

Air Canada chatbot case

Chatbot hứa giảm giá tang lễ không tồn tại → khách kiện → Air Canada thua.

Giải pháp:

• xây hệ thống LLM evals

• human-in-the-loop cho tác vụ quan trọng

• audit trail minh bạch

Headwind 6: Cái bẫy traction ban đầu

Nhiều team nhầm novelty với product-market fit.

Người dùng thử một lần rồi rời đi.

62% công ty mắc kẹt trong cái gọi là “pilot purgatory”.

Metric kiểu:

“10.000 AI queries tháng này”

không có ý nghĩa nếu workflow không thay đổi.

Metric tốt hơn:

• activation depth

• time-to-value

• repeat usage

Headwind 7: Sales không theo kịp sản phẩm

Product ship hàng tuần.

Nhưng:

• sales

• support

• legal

• CS

không theo kịp.

Kết quả:

• oversell

• undersell

• khách hàng không biết feature tồn tại

Giải pháp:

• internal launch trước external launch

• release brief 1 trang

• demo nội bộ

• just-in-time enablement

Điểm chung của tất cả các headwind

AI làm tăng supply:

• feature

• content

• output

Nhưng demand-side constraints như:

• attention

• trust

• budget

không tăng nhanh như vậy.

Phần lớn team tối ưu shipping nhiều hơn.

Nhưng team chiến thắng sẽ tối ưu:

• launch đúng

• thu hút attention

• monetise đúng cách

Tóm lại

• Sự chú ý là hữu hạn → tier hóa launch

• AI làm giảm margin → kiểm soát cost

• Monetization phải dựa trên value

• Messaging cần khác biệt

• Trust phải được thiết kế

• Traction ban đầu dễ gây hiểu nhầm

• Sales cần enablement liên tục

Viết code giờ đã dễ.

Nhưng xây dựng một sản phẩm AI thực sự thắng trên thị trường thì vẫn cực kỳ khó.