Mở đầu — vì sao bài này quan trọng
Hãy hình dung công việc theo dõi đối thủ của một PM truyền thống: mỗi sáng thứ Hai, bạn mở 7-8 tab trình duyệt, lướt blog của đối thủ, đọc changelog, soi bảng giá, lượn vào group review trên Facebook, rồi copy-paste những gì đáng chú ý vào một file Google Docs. Tốt thì làm được 30 phút, xấu thì cả buổi sáng trôi qua mà chỉ ghi được vài dòng. Tệ hơn: vì nó tốn sức, bạn bỏ bê nó. Đến khi đối thủ ra tính năng mới ba tháng trước mà sếp hỏi "sao mình không biết?" thì đã muộn.
Competitive intelligence (CI — tình báo cạnh tranh) là một trong những việc PM ai cũng biết là quan trọng nhưng gần như không ai làm đều đặn, đơn giản vì nó là lao động thủ công lặp đi lặp lại. Và đây chính xác là loại việc mà research agent sinh ra để giải quyết: một hệ thống AI tự động thu thập, lọc, tổng hợp thông tin đối thủ theo lịch, rồi đẩy cho bạn một bản tóm tắt có giá trị thay vì một đống dữ liệu thô.
Bài này không nói về việc dùng ChatGPT để "phân tích đối thủ" theo kiểu hỏi một câu được một câu — đó là việc một lần. Bài này nói về việc xây dựng một cỗ máy chạy liên tục: bạn thiết kế kiến trúc, cắm nguồn dữ liệu, định nghĩa cách xử lý, rồi để nó tự vận hành. Mục tiêu cuối cùng rất rõ ràng: continuous competitive intelligence without manual labor — tình báo cạnh tranh liên tục mà không cần lao động thủ công.
Khái niệm cốt lõi
Research agent khác gì so với một câu prompt?
Một câu prompt là phản ứng: bạn hỏi, AI trả lời, hết. Một agent là chủ động và có vòng lặp: nó nhận một mục tiêu ("theo dõi đối thủ X về giá và tính năng"), tự quyết định cần làm gì (truy cập nguồn nào, đọc gì), thực thi các bước đó bằng công cụ (tools), đánh giá kết quả, và lặp lại theo lịch mà không cần bạn gõ lại.
Bài trước trong khóa (Bài 33) đã giải thích agent là gì ở mức tổng quát. Bài này đi sâu vào một loại agent rất cụ thể dành cho PM: research agent cho competitive intel. Vì vậy ta sẽ tập trung hoàn toàn vào kiến trúc và cách dựng nó.
Kiến trúc một research agent cho CI
Tôi thường mô tả kiến trúc này bằng năm khối ghép lại như một dây chuyền. Hiểu năm khối này là bạn hiểu 80% bài học.
1. Inputs — Đầu vào. Đây là phần bạn khai báo. Gồm hai thứ:
- Danh sách đối thủ (competitor list): không chỉ tên, mà nên kèm "hồ sơ" mỗi đối thủ — họ thuộc nhóm nào (đối thủ trực tiếp, gián tiếp, mới nổi), mình quan tâm điều gì ở họ (giá, tính năng, tuyển dụng, vốn).
- Nguồn cần giám sát (sources to monitor): với mỗi đối thủ, liệt kê các điểm dữ liệu cụ thể — trang pricing, trang changelog/release notes, blog, tài khoản LinkedIn công ty, trang tuyển dụng, store listing (App Store/Google Play), thậm chí review của khách trên Shopee/các diễn đàn.
3. Change detection — Phát hiện thay đổi. Đây là khối mà người mới hay bỏ quên, nhưng nó là trái tim của một CI agent tốt. Agent cần so sánh trạng thái hiện tại với lần trước (snapshot) để chỉ báo cái gì mới/thay đổi. Nếu không có khối này, mỗi tuần bạn sẽ nhận lại nguyên một bản tóm tắt giống hệt tuần trước — vô dụng và gây nhiễu.
4. Processing & synthesis — Xử lý và tổng hợp. LLM vào cuộc ở đây: đọc đống thay đổi thô, phân loại (giá / tính năng / marketing / tuyển dụng), đánh giá mức độ quan trọng, và quan trọng nhất là rút ra hàm ý cho sản phẩm của bạn ("đối thủ vừa giảm giá gói Pro 20% — có thể họ đang đẩy mạnh giành thị phần SMB").
5. Output & delivery — Đầu ra và phân phối. Bản tóm tắt cuối phải đến đúng nơi bạn thực sự đọc: email, một tin nhắn Slack/Telegram, hoặc một dòng mới trong Notion/Google Sheet. Một insight nằm trong file không ai mở thì bằng không.
Nguyên tắc thiết kế: "signal, không phải noise"
Sai lầm chí mạng của CI agent là tạo ra quá nhiều thông tin. Mục tiêu không phải gom thật nhiều, mà là lọc ra thật ít nhưng đáng hành động. Một agent tốt một tuần có thể chỉ gửi bạn 3 dòng — nhưng cả 3 đều khiến bạn muốn họp ngay với team.
Tình huống thực tế
Ví dụ 1 — Startup SaaS gọi xe nội bộ doanh nghiệp theo dõi Grab và be
Bối cảnh: Bạn là PM của một startup tên "FleetGo" (giả định) làm phần mềm quản lý đưa đón nhân viên cho doanh nghiệp tại TP.HCM. Hai đối thủ tham chiếu lớn là Grab for Business và be Group. Trước đây bạn theo dõi họ thủ công, một tháng được một lần, thường là khi sếp nhắc.
Bạn dựng một research agent với inputs: hai đối thủ trên, nguồn gồm trang pricing dịch vụ doanh nghiệp, blog/newsroom, và trang tuyển dụng (vì tin tuyển dụng tiết lộ hướng đi sản phẩm rất sớm). Agent chạy mỗi sáng thứ Hai.
Diễn giải: Sau ba tuần, agent gửi một tóm tắt có dòng: "be đăng 4 tin tuyển dụng cho vị trí liên quan 'corporate billing' và 'API integration' — tín hiệu họ đang xây tính năng tích hợp kế toán cho khách doanh nghiệp." Đây là thông tin bạn sẽ không bao giờ bắt được nếu chỉ nhìn trang pricing, vì tính năng đó còn chưa ra mắt — nó mới đang được tuyển người để xây.
Bài học: Nguồn dữ liệu gián tiếp (tuyển dụng, LinkedIn) thường cho tín hiệu sớm hơn nguồn trực tiếp (pricing, changelog) vài tháng. Một CI agent tốt phải giám sát cả tín hiệu đi trước, không chỉ kết quả đã công bố.
Ví dụ 2 — PM thương mại điện tử và bẫy "nhiễu giá"
Bối cảnh: Một PM ở sàn TMĐT theo dõi giá của 5 đối thủ. Họ dựng agent crawl trang sản phẩm mỗi ngày và gửi cảnh báo mỗi khi giá thay đổi. Tuần đầu hào hứng. Tuần thứ hai, hộp mail ngập 40 cảnh báo/ngày vì giá trên sàn TMĐT nhảy liên tục theo flash sale, mã giảm giá, biến động tỷ giá. Cả team tắt thông báo sau ba ngày.
Diễn giải: Vấn đề không nằm ở thu thập mà ở khối processing/change detection. Họ thiếu ngưỡng (threshold) và thiếu tầng tổng hợp. Sau khi sửa lại: agent chỉ báo khi giá thay đổi >10% và duy trì >48 giờ (lọc flash sale tạm thời), đồng thời thay vì gửi từng cảnh báo lẻ, nó gom thành một bản tóm tắt thứ Sáu hằng tuần: "3/5 đối thủ giảm giá nhóm hàng gia dụng bền vững 12-15% trong tuần — có vẻ là một đợt điều chỉnh ngành, không phải động thái lẻ."
Bài học: Dữ liệu thô không phải là intelligence. Giá trị của agent nằm ở tầng lọc và tổng hợp. Một agent tốt biết im lặng khi không có gì đáng nói.
Ví dụ 3 — Agent đọc nhầm và "bịa" một tính năng
Bối cảnh: Một PM fintech dùng agent tổng hợp tin đối thủ. Một tuần, bản tóm tắt khẳng định chắc nịch: "Đối thủ MoMo vừa ra mắt tính năng cho vay mua trả góp lãi suất 0%." PM mừng rỡ đem vào họp, sếp hỏi nguồn — hóa ra đó là một bài blog phỏng đoán của một KOL, không phải thông báo chính thức. LLM đã đọc một nguồn không đáng tin và trình bày phỏng đoán như sự thật.
Diễn giải: Đây là hallucination kết hợp với nguồn kém chất lượng — một rủi ro cố hữu của research agent. Bài 16 trong khóa nói riêng về cách phát hiện hallucination; ở đây, ở góc độ thiết kế agent, bài học là agent phải gắn nguồn (citation) cho mỗi khẳng định và phân tầng độ tin cậy của nguồn (thông báo chính thức > báo lớn > blog/diễn đàn).
Bài học: Không bao giờ để agent tạo ra khẳng định không có link nguồn. Yêu cầu mỗi dòng tóm tắt đính kèm URL và phân loại "chính thức / chưa xác nhận".
Hướng dẫn từng bước
Đây là quy trình dựng một research agent CI mà bạn có thể bắt đầu ngay trong tuần này, kể cả khi không biết code (dùng các nền tảng no-code/AI có sẵn).
Bước 1 — Định nghĩa câu hỏi tình báo, không phải danh sách đối thủ. Đừng bắt đầu bằng "theo dõi 5 đối thủ". Hãy bắt đầu bằng quyết định bạn cần dữ liệu để ra: "Tôi cần biết khi nào đối thủ thay đổi chiến lược giá ở phân khúc SMB" hay "Tôi cần phát hiện sớm tính năng mới của đối thủ ở mảng thanh toán". Câu hỏi rõ thì việc chọn nguồn mới đúng.
Bước 2 — Lập bảng Inputs. Tạo một bảng (Google Sheet là đủ): mỗi dòng là một cặp (đối thủ × nguồn). Ví dụ: Grab × trang pricing, Grab × newsroom, be × LinkedIn jobs. Ghi rõ URL và tần suất kiểm tra mong muốn. Đây chính là "cấu hình" của agent.
Bước 3 — Chọn cơ chế thu thập. Tùy nguồn:
- Trang có RSS (nhiều blog/changelog): dùng feed, đơn giản và sạch nhất.
- Trang không có feed: dùng tool web scraping (Firecrawl, Browse AI) hoặc tính năng research của Claude/ChatGPT/Perplexity.
- Tin tức rộng: dùng web search với từ khóa "[tên đối thủ] + ra mắt / giá / vòng gọi vốn".
Bước 5 — Viết prompt tổng hợp. Đây là phần PM kiểm soát nhiều nhất. Một khung prompt tốt: "Bạn là chuyên viên CI. Dưới đây là các thay đổi phát hiện được tuần này từ các đối thủ [danh sách]. Hãy: (1) lọc bỏ thay đổi không quan trọng; (2) phân loại theo Giá/Tính năng/Marketing/Nhân sự; (3) với mỗi điểm đáng chú ý, nêu hàm ý cho sản phẩm của chúng tôi (bối cảnh: [mô tả sản phẩm bạn]); (4) đính kèm URL nguồn và đánh dấu 'chính thức' hoặc 'chưa xác nhận'. Nếu tuần này không có gì đáng kể, hãy nói thẳng điều đó."
Bước 6 — Chọn kênh phân phối. Đẩy output về nơi bạn thực sự đọc mỗi tuần. Với team Việt Nam, Telegram hoặc email thường hiệu quả hơn một dashboard ít ai mở.
Bước 7 — Đặt lịch và chạy thử 3 tuần. Dùng cron/scheduler để chạy tự động (ví dụ 8h sáng thứ Hai). Quan trọng: ba tuần đầu hãy đọc kỹ và tinh chỉnh — siết ngưỡng nhiễu, thêm/bớt nguồn, sửa prompt. Agent không "set xong là quên"; nó cần nuôi.
Lỗi thường gặp & mẹo
Lỗi 1 — Gom dữ liệu nhưng không lọc. Như ví dụ 2, agent gửi quá nhiều khiến team tắt thông báo. Mẹo: thiết kế để agent được phép gửi tin nhắn "tuần này không có gì đáng kể". Sự im lặng có chủ đích làm tăng độ tin cậy của những lần nó lên tiếng.
Lỗi 2 — Bỏ qua change detection. Mỗi tuần nhận lại bản tóm tắt y hệt. Mẹo: luôn so sánh với snapshot trước; chỉ tổng hợp phần delta (thay đổi).
Lỗi 3 — Tin agent tuyệt đối. Như ví dụ 3, hallucination + nguồn rác dẫn đến quyết định sai. Mẹo: bắt buộc citation cho mọi khẳng định; bản thân bạn vẫn phải verify trước khi đưa vào họp quan trọng.
Lỗi 4 — Quên khía cạnh pháp lý và đạo đức. Scraping quá tay có thể vi phạm điều khoản dịch vụ của website đối thủ. Mẹo: ưu tiên nguồn công khai và RSS chính thức; tôn trọng robots.txt; không thu thập dữ liệu cá nhân. CI phải dựa trên thông tin công khai một cách hợp pháp.
Lỗi 5 — Theo dõi quá nhiều đối thủ. Theo 15 đối thủ thì không theo ai cho sâu. Mẹo: bắt đầu với 2-3 đối thủ trực tiếp quan trọng nhất, làm cho chuẩn, rồi mới mở rộng.
Mẹo nâng cao — Tách agent theo nguồn. Thay vì một agent khổng lồ làm mọi thứ, hãy chia nhỏ: một agent chuyên giá, một agent chuyên tính năng/changelog, một agent chuyên tin tuyển dụng. Mỗi agent đơn nhiệm thì dễ debug, dễ chỉnh ngưỡng, và kết quả sạch hơn. Đây cũng là tiền đề cho việc chaining nhiều agent (sẽ học sâu ở Bài 36).
Bài tập thực hành
- Định nghĩa câu hỏi tình báo (15 phút). Viết ra đúng một quyết định kinh doanh mà bạn cần CI để hỗ trợ, theo mẫu: "Tôi cần biết khi nào ___ để có thể ___."
- Lập bảng Inputs (30 phút). Chọn 2 đối thủ thật trong ngành của bạn. Với mỗi đối thủ, liệt kê tối thiểu 3 nguồn cụ thể kèm URL (pricing, changelog/blog, LinkedIn jobs hoặc store listing). Đánh dấu nguồn nào có RSS.
- Dựng agent tối giản (60 phút). Dùng tính năng research của Claude/ChatGPT/Perplexity hoặc một tool no-code, tạo một agent chạy được prompt tổng hợp ở Bước 5 cho 2 đối thủ trên. Chạy thủ công một lần và đánh giá output.
- Kiểm thử chống nhiễu và hallucination (30 phút). Đọc output vừa tạo và tự hỏi hai câu: (a) Có dòng nào không cần thiết, gây nhiễu không? (b) Có khẳng định nào không kèm nguồn, hoặc nguồn không đáng tin không? Chỉnh lại prompt để khắc phục, rồi chạy lại.
- Đặt lịch (15 phút). Thiết lập agent chạy tự động hằng tuần và đẩy kết quả về kênh bạn thật sự đọc (email/Telegram). Cam kết theo dõi và tinh chỉnh trong 3 tuần.
Tóm tắt
Research agent cho competitive intel biến một việc thủ công, hay bị bỏ bê, thành một cỗ máy chạy liên tục. Kiến trúc gồm năm khối: Inputs (đối thủ + nguồn), Collection (thu thập qua scraping/search/RSS), Change detection (chỉ giữ phần thay đổi), Processing & synthesis (LLM phân loại và rút hàm ý), và Output & delivery (đẩy về nơi bạn đọc). Nguyên tắc xuyên suốt là signal chứ không phải noise: một agent tốt biết im lặng khi không có gì đáng nói và biết gắn nguồn cho mọi khẳng định.
Ba bài học từ thực tế: nguồn gián tiếp (tuyển dụng, LinkedIn) cho tín hiệu sớm; dữ liệu thô không phải intelligence — giá trị nằm ở tầng lọc và tổng hợp; và đừng bao giờ tin agent tuyệt đối khi chưa có citation. Hãy bắt đầu nhỏ với 2-3 đối thủ, dựng agent tối giản trong tuần này, rồi nuôi nó qua ba tuần tinh chỉnh. Khi vận hành tốt, bạn sẽ có thứ mà phần lớn PM mơ ước nhưng ít ai có: tình báo cạnh tranh đều đặn, đáng hành động, mà gần như không tốn công sức.