Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 37 — Competitor Analysis as Discovery Input

Customer Discovery & Jobs-To-Be-Done Bài 37/60

Mở đầu — vì sao bài này quan trọng

Trong suốt khóa học, chúng ta đã nhấn mạnh rằng nguồn sự thật quan trọng nhất của discovery là khách hàng — qua phỏng vấn, qua quan sát, qua dữ liệu hành vi. Nhưng có một nguồn tín hiệu mà rất nhiều PM Việt Nam hoặc là phớt lờ, hoặc là dùng sai cách: đối thủ cạnh tranh.

Phớt lờ thì nguy hiểm, vì đối thủ chính là một "phòng thí nghiệm miễn phí" đã chạy hàng trăm thử nghiệm thay cho bạn. Họ đã đổ tiền marketing, đã build tính năng, đã thử mô hình giá — và thị trường đã phản hồi. Bạn có thể đọc kết quả của những thí nghiệm đó mà không tốn một đồng nào.

Nhưng dùng sai cũng nguy hiểm không kém. Đa số PM khi "phân tích đối thủ" thực ra chỉ làm một việc: liệt kê tính năng của đối thủ rồi yêu cầu team build lại cho bằng. Đây là tư duy "feature parity" (cào bằng tính năng) — và nó là một trong những cái bẫy giết chết sản phẩm nhanh nhất. Bạn copy tính năng mà không hiểu job đằng sau nó, không biết tính năng đó có thực sự thành công hay không, và bạn luôn đi sau đối thủ một nhịp.

Bài học này dạy bạn cách thứ ba: dùng đối thủ như một tín hiệu discovery (discovery signal). Nghĩa là không copy, không phớt lờ, mà đọc đối thủ như đọc một bộ dữ liệu — để tìm ra: vấn đề nào đã được kiểm chứng là đáng giải quyết, mô hình giải pháp nào đã được chứng minh hoạt động, và mức giá nào thị trường sẵn sàng trả. Đây là kỹ năng giúp bạn rút ngắn vòng discovery và tránh đi vào những ngõ cụt mà người khác đã đi.

Khái niệm cốt lõi

Đối thủ nói gì với bạn về thị trường

Hãy đổi tư duy: mỗi đối thủ còn tồn tại trên thị trường là một bằng chứng sống. Họ tồn tại được nghĩa là có người trả tiền, có người dùng, có một job nào đó đang được giải quyết đủ tốt để khách hàng không bỏ đi. Một đối thủ tồn tại 5 năm với 100.000 người dùng đã validate (kiểm chứng) một loạt giả thuyết mà bạn vẫn còn đang phân vân.

Có ba thứ chính mà đối thủ tiết lộ cho bạn:

1. Vấn đề nào đã được kiểm chứng — và ở quy mô nào. Nếu có ba startup cùng giải quyết bài toán quản lý công nợ cho tiểu thương, đó là tín hiệu mạnh rằng bài toán này có thật và đủ đau để nhiều người đặt cược vào. Nhưng quan trọng hơn là quy mô: một đối thủ có 500 khách doanh nghiệp lớn nói lên điều khác hẳn so với một đối thủ có 50.000 người dùng cá nhân. Quy mô tiết lộ phân khúc nào thực sự có tiền và sẵn sàng chi.

2. Mô hình giải pháp đã được chứng minh. Đối thủ đã thử nhiều cách tiếp cận. Cách nào họ giữ lại sau nhiều năm là cách đã sống sót qua chọn lọc tự nhiên. Nếu mọi đối thủ trong ngành đều có cùng một luồng onboarding, một cấu trúc thông báo, một mô hình tích hợp — đừng vội cho rằng họ thiếu sáng tạo. Rất có thể họ đều đã thử cách khác và thất bại, rồi hội tụ về cùng một pattern. Đó là "convergent evolution" trong thiết kế sản phẩm.

3. Giá mà thị trường chấp nhận. Pricing của đối thủ là kết quả của vô số thử nghiệm A/B, vô số cuộc đàm phán bán hàng, vô số lần khách bỏ giỏ hàng. Bảng giá công khai của họ là một bản tóm tắt cô đọng về willingness to pay (mức sẵn sàng chi trả) của thị trường. Đặc biệt, cách họ chia gói (tier) tiết lộ họ nghĩ ai là khách, ai trả nhiều, và tính năng nào đáng để đặt sau "paywall".

Phân biệt: tín hiệu discovery vs. bản đồ cạnh tranh

Cần phân biệt rõ hai mục đích. Competitive intelligence truyền thống phục vụ chiến lược kinh doanh — định vị, định giá, go-to-market. Còn ở đây, chúng ta dùng đối thủ phục vụ discovery — để hiểu khách hàng và job của họ sâu hơn. Hai cái dùng chung dữ liệu nhưng đặt câu hỏi khác nhau.

Khi làm discovery, bạn không hỏi "Làm sao thắng đối thủ này?". Bạn hỏi: "Đối thủ này đang dạy tôi điều gì về khách hàng mà tôi chưa biết?". Mỗi tính năng họ có là một giả thuyết về một job. Mỗi review một sao là một insight về nỗi đau chưa được giải quyết. Mỗi gói giá là một giả thuyết về phân khúc.

Ba lớp tín hiệu: validated, signal, noise

Không phải mọi thứ ở đối thủ đều đáng tin như nhau. Hãy phân loại:

  • Validated (đã kiểm chứng): Những thứ tồn tại lâu, ở nhiều đối thủ, gắn với doanh thu. Ví dụ: tính năng cốt lõi mà mọi đối thủ đều có và tính phí. Độ tin cậy cao.
  • Signal (tín hiệu): Những thứ mới xuất hiện, đối thủ đang đặt cược nhưng chưa rõ kết quả. Ví dụ: một tính năng AI vừa ra mắt 2 tháng. Đáng chú ý nhưng cần thêm bằng chứng.
  • Noise (nhiễu): Những thứ có thể là sai lầm của đối thủ. Một tính năng nằm sâu trong menu, không ai nhắc tới, có thể là "tính năng thây ma" mà chính đối thủ cũng muốn bỏ. Đừng copy noise.
Sai lầm lớn nhất là đối xử với cả ba lớp như nhau — copy noise tưởng là validated.

Nguồn dữ liệu đối thủ cho discovery

Đối thủ để lại dấu vết ở khắp nơi, và phần lớn là miễn phí:

  • Review của khách hàng: App Store, Google Play, Capterra, G2, các nhóm Facebook. Đặc biệt giá trị là review 2-3 sao — đó là người muốn dùng nhưng thất vọng vì một điểm cụ thể. Đó chính là cơ hội cho bạn.
  • Trang pricing và changelog: Pricing tiết lộ phân khúc và willingness to pay. Changelog (lịch sử cập nhật) tiết lộ họ đang ưu tiên gì, đoán được job nào đang nóng.
  • Tài liệu marketing và landing page: Headline họ chọn chính là job-to-be-done mà họ tin là quan trọng nhất với khách. Họ đã A/B test câu chữ đó.
  • Job postings (tin tuyển dụng): Đối thủ tuyển kỹ sư mảng thanh toán nghĩa là họ sắp làm gì đó với thanh toán. Đây là cửa sổ nhìn vào roadmap của họ.
  • Cộng đồng và forum hỗ trợ: Nơi khách hàng phàn nàn công khai. Mỏ vàng insight về nỗi đau chưa được giải quyết.

Tình huống thực tế

Ví dụ 1 — Đọc review đối thủ để tìm job chưa được giải quyết (fintech Việt Nam)

Một startup giả định tên SoBan muốn làm app quản lý bán hàng cho các quán cà phê và nhà hàng nhỏ ở Việt Nam. Thị trường đã có những tay chơi lớn như KiotViet, Sapo, iPOS. Phản xạ đầu tiên của team là liệt kê tính năng của KiotViet rồi build lại — đúng cái bẫy feature parity.

PM của SoBan làm khác. Cô lấy 800 review của KiotViet và Sapo trên Google Play, lọc ra các review 2-3 sao, rồi gắn thẻ (tag) theo chủ đề. Kết quả phân loại: 34% than phiền về việc đồng bộ dữ liệu chậm khi mạng yếu, 22% về việc khó dùng trên điện thoại đời cũ, 18% về phí ẩn và việc khóa tính năng đột ngột khi hết hạn gói.

Insight quan trọng: nhóm khách quán nhỏ ở tỉnh thường dùng điện thoại cấu hình thấp, mạng 3G chập chờn. Các đối thủ lớn được thiết kế cho cửa hàng thành phố mạng tốt. Đây là một job — "quản lý bán hàng mượt mà ngay cả khi mạng yếu" — đã được gián tiếp kiểm chứng là chưa ai giải quyết tốt, qua chính nỗi bực bội của khách đối thủ.

SoBan đặt cược vào kiến trúc offline-first và app nhẹ. Trong 6 tháng họ đạt 4.000 cửa hàng ở các tỉnh, hầu hết chuyển từ đối thủ. Bài học: review 2-3 sao của đối thủ là bản đồ chỉ đường tới những job chưa được phục vụ. Đối thủ đã chứng minh job "quản lý bán hàng" là thật và đáng tiền; review chỉ ra phân khúc nào đang bị bỏ rơi.

Ví dụ 2 — Pricing của đối thủ tiết lộ phân khúc và willingness to pay (SaaS B2B)

Một team xây dựng công cụ quản lý nhân sự cho doanh nghiệp vừa và nhỏ tại Đông Nam Á. Họ phân vân: nên định giá theo đầu người (per-seat) hay theo gói cố định? Phân khúc nào là "điểm ngọt"?

Thay vì đoán, họ lập bảng so sánh pricing của 6 đối thủ trong khu vực. Họ nhận ra một pattern rõ rệt: gần như tất cả đối thủ đều có một "bậc nhảy giá" lớn ở khoảng 50 nhân viên — dưới mức đó là gói tự phục vụ giá rẻ, trên mức đó là gói "liên hệ sale" đắt hơn nhiều lần. Đồng thời, tính năng chấm công và tính lương luôn nằm ở gói trả phí, không bao giờ free; còn tính năng đánh giá hiệu suất thì thường nằm ở gói cao cấp nhất.

Đọc tín hiệu này: thị trường đã kiểm chứng rằng chấm công + tính lương là job mà SMB sẵn sàng trả tiền ngay (nó liên quan trực tiếp đến tiền và tuân thủ pháp luật). Còn đánh giá hiệu suất là job "nice to have" mà chỉ công ty lớn hơn mới trả. Ngưỡng 50 nhân viên là nơi nhu cầu và ngân sách thay đổi về chất.

Team quyết định nhắm thẳng phân khúc 20-80 nhân viên với gói tự phục vụ tập trung vào lõi lương + chấm công, và cố tình giữ giá đơn giản, minh bạch để khác biệt với mô hình "liên hệ sale" gây khó chịu của đối thủ. Bài học: bảng giá đối thủ không phải để copy, mà để giải mã xem thị trường định giá từng job ở mức nào và phân khúc nào có sẵn ngân sách. Họ đã tốn nhiều năm để tìm ra ngưỡng 50 nhân viên đó — bạn đọc nó trong một buổi chiều.

Ví dụ 3 — Changelog và tin tuyển dụng tiết lộ job đang nóng (E-commerce khu vực)

Một PM tại một sàn thương mại điện tử nhỏ muốn biết nên đầu tư discovery vào đâu tiếp theo. Cô theo dõi changelog của hai đối thủ lớn trong khu vực suốt 4 tháng và đọc các tin tuyển dụng của họ.

Cô nhận thấy cả hai đối thủ đồng loạt tung ra tính năng "mua trước trả sau" (BNPL) và đăng tuyển dồn dập kỹ sư mảng tín dụng, rủi ro. Đây không phải trùng hợp — đó là tín hiệu rằng cả hai đều đã làm discovery độc lập và cùng kết luận rằng job "mua được món hàng dù chưa đủ tiền ngay" là một nhu cầu lớn đang nổi trong nhóm khách trẻ.

Nhưng cô không vội copy. Thay vào đó, cô coi đây là giả thuyết để xác minh, không phải kết luận để build. Cô tổ chức 12 cuộc phỏng vấn switch story với khách hàng trẻ và phát hiện một sắc thái mà đối thủ chưa chạm tới: nỗi sợ "mắc nợ" khiến nhiều người Việt ngần ngại BNPL, nhưng họ lại rất cởi mở với "tích điểm trả góp không lãi" do người thân bảo lãnh. Cô tìm ra một biến thể của job phù hợp văn hóa hơn.

Bài học: changelog và tin tuyển dụng là cửa sổ nhìn vào roadmap tương lai của đối thủ — chúng cho bạn biết job nào đang nóng trước khi nó trở thành chuẩn ngành. Nhưng tín hiệu đối thủ chỉ là điểm khởi đầu của discovery, không phải điểm kết thúc. Bạn vẫn phải phỏng vấn khách hàng để tìm sắc thái mà đối thủ bỏ lỡ.

Hướng dẫn từng bước

Đây là quy trình dùng đối thủ làm tín hiệu discovery một cách có kỷ luật:

Bước 1 — Xác định đúng tập đối thủ. Đừng chỉ liệt kê đối thủ trực tiếp. Bao gồm cả: đối thủ trực tiếp (cùng giải pháp), đối thủ gián tiếp (giải pháp khác cho cùng job), và "giải pháp hiện tại" của khách (Excel, sổ tay, nhờ người quen). Trong JTBD, đối thủ thực sự của bạn là bất cứ thứ gì khách đang dùng để hoàn thành job.

Bước 2 — Chốt câu hỏi discovery trước khi đào. Đừng đào dữ liệu vô định. Hãy viết ra 3-5 câu hỏi cụ thể, ví dụ: "Job nào khách sẵn sàng trả tiền?", "Phân khúc nào đang bị bỏ rơi?", "Mô hình giá nào thị trường chấp nhận?". Câu hỏi định hướng việc thu thập.

Bước 3 — Thu thập dữ liệu từ nhiều nguồn. Gom review (ưu tiên 2-3 sao), pricing, changelog, landing page, tin tuyển dụng, thảo luận cộng đồng. Lưu lại có hệ thống — đừng để trong đầu.

Bước 4 — Gắn thẻ và phân loại theo job, không theo tính năng. Khi đọc một tính năng hay một lời than phiền, hỏi: "Tính năng/lời than này đang phục vụ job nào của khách?". Nhóm các tín hiệu theo job. Đây là điểm tách biệt PM giỏi với người chỉ làm bảng so sánh tính năng.

Bước 5 — Phân loại tín hiệu theo độ tin cậy. Gắn nhãn validated / signal / noise cho từng phát hiện. Chỉ dồn nguồn lực vào validated và những signal đáng đặt cược.

Bước 6 — Chuyển thành giả thuyết, không thành yêu cầu build. Mỗi insight từ đối thủ phải viết thành một giả thuyết kiểm chứng được: "Chúng tôi tin rằng [phân khúc] có job [X] chưa được giải quyết tốt, bằng chứng là [tín hiệu đối thủ]." Sau đó mới mang đi xác minh bằng phỏng vấn và dữ liệu.

Bước 7 — Xác minh bằng tiếng nói khách hàng. Đây là bước không được bỏ qua. Tín hiệu đối thủ giúp bạn hình thành giả thuyết nhanh hơn, nhưng khách hàng mới là người xác nhận. Phỏng vấn để tìm sắc thái, ngữ cảnh, và bối cảnh văn hóa mà đối thủ có thể đã bỏ lỡ.

Lỗi thường gặp & mẹo

Lỗi 1 — Feature parity (cào bằng tính năng). Copy tính năng đối thủ để "không bị thua kém". Đây là cách đảm bảo bạn luôn đi sau và không bao giờ tạo khác biệt. Mẹo: mỗi khi muốn copy một tính năng, bắt buộc trả lời "Tính năng này phục vụ job nào, và job đó có thật với khách của tôi không?".

Lỗi 2 — Cho rằng đối thủ luôn đúng. Đối thủ cũng đoán, cũng sai. Tính năng họ build chưa chắc thành công. Mẹo: phân loại validated/signal/noise; chỉ tin những gì có bằng chứng tồn tại lâu, đa đối thủ, gắn doanh thu.

Lỗi 3 — Chỉ nhìn đối thủ trực tiếp. Bỏ qua giải pháp thay thế thật sự của khách. Nhiều khi đối thủ lớn nhất của một app quản lý chi tiêu là... cuốn sổ tay và trí nhớ. Mẹo: trong mọi phỏng vấn, hỏi "Trước khi có công cụ X, anh/chị làm việc này bằng cách nào?".

Lỗi 4 — Phân tích đối thủ thay cho phỏng vấn khách hàng. Một số PM dùng phân tích đối thủ như cái cớ để né việc nói chuyện với khách. Mẹo: coi đối thủ là nguồn giả thuyết, khách hàng là nguồn xác nhận. Không bao giờ ship dựa trên tín hiệu đối thủ chưa qua xác minh.

Lỗi 5 — Bỏ qua bối cảnh thị trường. Copy một mô hình thành công ở Mỹ vào Việt Nam mà không tính tới khác biệt văn hóa, hạ tầng, hành vi chi trả. Mẹo: luôn hỏi "Tín hiệu này có chuyển được sang bối cảnh khách của tôi không?" (chủ đề này sẽ được đào sâu ở các bài về thị trường VN).

Mẹo cộng thêm: Lập một "bảng theo dõi đối thủ" cập nhật định kỳ hằng quý — không phải để ám ảnh, mà để bắt sớm các tín hiệu changelog và tuyển dụng. Discovery dùng đối thủ hiệu quả nhất khi nó liên tục, nhẹ nhàng, không phải một dự án lớn một lần.

Bài tập thực hành

Chọn một sản phẩm bạn đang làm hoặc quan tâm, rồi thực hiện:

  • Lập tập đối thủ mở rộng. Liệt kê 3 đối thủ trực tiếp, 2 đối thủ gián tiếp, và 1 "giải pháp hiện tại" phi phần mềm mà khách đang dùng để làm cùng job.
  • Đào review. Lấy ít nhất 50 review của một đối thủ chính, lọc các review 2-3 sao, gắn thẻ theo chủ đề. Tìm ra 3 job hoặc nỗi đau lặp đi lặp lại mà đối thủ chưa giải quyết tốt.
  • Giải mã pricing. Lập bảng so sánh gói giá của ít nhất 3 đối thủ. Trả lời: tính năng nào luôn nằm sau paywall (job đáng tiền)? Có "bậc nhảy giá" ở phân khúc nào không? Điều đó nói gì về willingness to pay?
  • Đọc tương lai. Xem changelog 3 tháng gần nhất và tin tuyển dụng của 1 đối thủ. Đoán xem họ đang đặt cược vào job nào sắp tới.
  • Viết giả thuyết. Từ các phát hiện trên, viết 2 giả thuyết discovery theo mẫu: "Chúng tôi tin rằng [phân khúc] có job [X] chưa được phục vụ tốt, bằng chứng từ đối thủ là [tín hiệu]. Chúng tôi sẽ xác minh bằng [phỏng vấn/dữ liệu]." Gắn nhãn validated/signal/noise cho mỗi giả thuyết.
Sản phẩm cuối: một trang giấy gồm tập đối thủ, bảng tag review, bảng giải mã pricing, và 2 giả thuyết sẵn sàng mang đi phỏng vấn.

Tóm tắt

Đối thủ cạnh tranh là một nguồn tín hiệu discovery cực kỳ giá trị nhưng thường bị dùng sai. Đừng phớt lờ họ, và đừng copy họ. Hãy đọc họ.

Ba điều cốt lõi đối thủ tiết lộ: (1) vấn đề nào đã được kiểm chứng và ở quy mô nào — sự tồn tại của họ là bằng chứng job có thật; (2) mô hình giải pháp nào đã được chứng minh — những pattern sống sót qua thời gian; (3) mức giá thị trường chấp nhận — pricing là bản tóm tắt cô đọng của willingness to pay.

Nguồn dữ liệu phong phú và phần lớn miễn phí: review (đặc biệt 2-3 sao), pricing, changelog, landing page, tin tuyển dụng, cộng đồng. Hãy phân loại mọi tín hiệu thành validated / signal / noise, và luôn gắn tín hiệu với job chứ không phải tính năng.

Cuối cùng, nguyên tắc vàng: đối thủ là nguồn giả thuyết, khách hàng là nguồn xác nhận. Tín hiệu đối thủ giúp bạn hình thành giả thuyết nhanh hơn và tránh ngõ cụt người khác đã đi, nhưng không bao giờ thay thế được việc nói chuyện trực tiếp với khách hàng. PM giỏi dùng đối thủ để discovery nhanh hơn và thông minh hơn — chứ không phải để discovery thay cho khách hàng.