Nghịch lý của Product Discovery: làm thế nào ra quyết định nhanh và hợp lý?

Trong công việc phát triển sản phẩm, đôi khi những con số sẽ chỉ cho chúng ta biết khi nào nên hành động thật nhanh, và khi nào cần chậm lại. Đây là bài toán cân bằng giữa rủi ro, nghiên cứu và chu kỳ phát hành sản phẩm.

Làm cái này xong, kết quả sẽ tốt lên như thế nào?

Đây là cách hỏi phổ biến để biết liệu công sức bỏ ra có đáng không, có tăng doanh thu, giữ chân người dùng, hay tạo ra thay đổi tích cực rõ ràng nào không. Một câu hỏi hoàn toàn hợp lý, và nó xuất hiện ngay giữa buổi review sản phẩm của bạn.

Bạn đang trình bày một tính năng mới sẽ mất một tháng (4 tuần làm việc) để phát triển. Bạn tin rằng nó có thể cải thiện tỷ lệ quay lại của người dùng, nhưng cũng có khả năng không mang lại thay đổi gì đáng kể.

Các stakeholder quan trọng thì muốn sự chắc chắn. Bạn thì cần sự rõ ràng. Và không ai muốn lãng phí một tháng vào một thứ không đem lại giá trị.

Thế là bạn sẽ phải làm bài tập: phân tích dữ liệu, tìm insights khách hàng, nghiên cứu đối thủ, đủ cả. Bạn mất ít nhất bốn tuần. Nghe thì bốn tuần discovery có vẻ không quá nhiều.

Nhưng thử tính xem: đó là mức tăng 100% thời gian ra thị trường. Thay vì deliver sau 4 tuần, giờ bạn đang nhìn vào mốc 8 tuần.

Tôi biết có nhiều bạn từng trải qua rằng ngay cả khi đã nghiên cứu kỹ lưỡng đến đâu, không gì đảm bảo thành công. Bạn từng thấy những ý tưởng được xác thực kỹ vẫn thất bại.

Cái giá của Discovery

Hiểu đơn giản trước: mỗi ngày bạn dành để tìm hiểu insight người dùng, phân tích dữ liệu là một ngày không được dùng để xây dựng sản phẩm.

Hiểu sâu sắc hơn: việc nghiên cứu chỉ đáng làm nếu nó giúp giảm nguy cơ làm sai một cách rõ rệt.

Nếu team của bạn có thể xây dựng một tính năng trong 20 ngày, nhưng việc nghiên cứu đúng bài bản mất 10 ngày, thì thời gian ra mắt đã bị kéo dài thêm 50%. Chưa kể đến các resources khác sẽ được sử dụng. Khoản đầu tư này chỉ hợp lý khi nó thực sự giúp giảm đáng kể rủi ro ra mắt một giải pháp tệ.

Hãy nghĩ đến discovery như việc mua bảo hiểm rủi ro: bạn bỏ ra một khoản chi phí (nỗ lực để khám phá ra các vấn đề thực sự) để giảm khả năng gặp một tổn thất lớn hơn (tốn công build tính năng sai). Bảo hiểm chỉ đáng giá khi phần tổn thất tiềm ẩn lớn so với khoản chi phí bạn bỏ ra.

Cốt lõi của phát triển sản phẩm là chuyển đổi tài nguyên (thời gian dev, công sức thiết kế, hạ tầng) thành giá trị. Dù là nghiên cứu quá đà hay build sai thứ, đều được tính là lãng phí.

Vì vậy, đây là một bài toán tối ưu: làm sao để tăng kiến thức (hiểu đúng vấn đề) trong khi giảm thiểu chi phí cơ hội do chậm triển khai?

Lợi nhuận ngầm của Discovery

Không phải giá trị nào từ discovery cũng hiện rõ trên bảng tính rủi ro. Đôi khi, mục tiêu không chỉ là tránh thất bại, mà là khám phá ra một hướng đi tốt hơn.

Discovery không chỉ là một gói bảo hiểm, mà còn là chiếc đèn pin trong bóng tối để giúp bạn dò đường.

Vì vậy trước đây tôi hay nói vui với mọi người rằng: Giờ mua bảo hiểm hay là xác định đi dò đường?

Bạn có thể bắt đầu với ý định kiểm chứng Tính năng A, nhưng trong quá trình đó, bạn nhận ra Tính năng B giải quyết vấn đề hiệu quả gấp 10 lần, hoặc thậm chí vấn đề ban đầu chưa chắc đã đúng.

Những bước ngoặt như vậy không chỉ giúp tiết kiệm chi phí, mà còn định hình lại hướng phát triển sản phẩm, theo đúng điều khách hàng thực sự quan tâm.

Discovery cũng là cách giúp cả team hiểu và đồng thuận với nhau. Khi designer, engineer và stakeholder cùng nhau khám phá vấn đề, họ ít tranh luận hơn và xây dựng nhiều hơn.

Sự hiểu biết chung là liều thuốc xóa tan mơ hồ hiệu quả nhất. Lúc đó bạn không chỉ đang thu thập ý kiến, xây dựng cách giải quyết vấn đề, mà đang tạo ra sự rõ ràng.

Và đôi khi, bạn cần nhìn rộng ra hơn. Một quá trình discovery tốt có thể thách thức các giả định cũ, làm mới lại roadmap, và thổi sinh khí cho một tầm nhìn đã cũ kỹ.

Nó giúp bạn nối kết giữa điều người dùng thực sự muốn và nơi sản phẩm có thể vươn tới, không phải nhờ làm khảo sát, mà nhờ lắng nghe với sự tò mò thực sự.

Đối với tôi, kỹ năng lắng nghe và khả năng duy trì sự tò mò trong một thời gian dài là hai điều quan trọng bậc nhất ở giai đoạn này.

Vì thế, đúng là discovery có chi phí, nó có cái giá của nó. Nhưng nếu nó giúp bạn nhìn thấu vấn đề, xây dựng được sự đồng thuận, và tự tin hơn trong chặng đường dài, thì đó không chỉ là chi phí, mà chính là nơi giá trị thật bắt đầu hình thành.

Tình thế phổ biến: Làm luôn hay tìm hiểu trước?

Khi bạn có một ý tưởng mới, thường sẽ đứng trước hai lựa chọn:

1. Dành thời gian để kiểm chứng xem ý tưởng đó có tốt không trước khi bắt tay vào làm
2. Làm luôn, rồi xem kết quả ra sao

Để quyết định đi theo hướng nào, bạn cần cân nhắc hai loại chi phí chính:

• Chi phí Discovery: Bạn sẽ tốn bao nhiêu thời gian, tiền bạc và công sức để kiểm tra hoặc xác thực ý tưởng mà chưa cần xây dựng nó?
• Chi phí thất bại: Nếu bạn build xong, tung sản phẩm ra, rồi ý tưởng đó thất bại thì hậu quả sẽ nặng nề thế nào? Có thể là phải làm lại, khách hàng bực bội, đánh giá 1 sao, hoặc phổ biến nhất là lãng phí công sức về mặt resources.

Bạn cũng cần cân nhắc thêm yếu tố:

• Xác suất thất bại: Không phải ý tưởng nào cũng sai. Bạn cần ước lượng xem khả năng thất bại của ý tưởng này cao đến đâu?

Xác suất thất bại (probability of failure) trong product development không thể tính chính xác như trong toán học, nhưng có thể ước lượng một cách hợp lý dựa trên dữ liệu, kinh nghiệm và bối cảnh.

(Người thực sự thông minh sẽ còn cân nhắc thêm: "Liệu nếu mình hiểu rõ thêm, cơ hội thành công có tăng lên không?", nhưng tạm thời bài này chưa đi sâu đến vậy.)

Bài toán đặt ra

Đây là lúc cần suy nghĩ thực tế. Hãy tự hỏi:

1. Điều tệ nhất có thể xảy ra là gì?

Đây chính là chi phí thất bại. (Ví dụ: lãng phí 1 tháng công sức, mất lòng tin người dùng, ảnh hưởng đến roadmap)

2. Mình có chấp nhận được rủi ro đó không?

Nếu có thể sống chung với rủi ro đó, có thể cân nhắc build luôn.

3. Nếu không thể chấp nhận, vậy có cách nào để giảm rủi ro đó không?

Việc bỏ công tìm hiểu trước (chi phí Discovery) có thấp hơn so với cái giá của thất bại không?

Nếu CÓ: Làm discovery.
Nếu KHÔNG: Build luôn rồi đo kết quả.

Hai kịch bản thực tế

Trong thực tế, chỉ cần ước lượng bằng man-hours hay T-shirt sizes là đủ.

Kịch bản #1: Low-Risk Feature

Tính năng: Thêm filter sản phẩm theo màu sắc.

• Chi phí khám phá (Discovery): $4,000 (khảo sát, tìm hiểu insights người dùng, phân tích dữ liệu)
• Xác suất thất bại: 15% (người dùng có thể không dùng bộ lọc màu nhiều như kỳ vọng)
• Chi phí thất bại: $2,500 (chi phí phát triển, QC, chỉnh sửa UI nếu cần gỡ bỏ)

Chi phí thất bại kỳ vọng = 15% × $2,500 = $375

Bạn có sẵn sàng bỏ ra $4,000 chỉ để tránh rủi ro mất $375 không?

Không đáng. Tốt hơn là triển khai nhanh, đo lường hành vi thực tế, và cải thiện sau nếu cần.

Kịch bản #2: High-Risk Feature

Tính năng: Tích hợp hệ thống thanh toán trả góp (Buy Now Pay Later)

• Chi phí Discovery: $25,000 (nghiên cứu pháp lý, khảo sát hành vi tài chính người dùng, test API với đối tác BNPL)
• Xác suất thất bại: 35% (rủi ro nằm ở việc người dùng không dùng nhiều, hoặc gây ra vấn đề về quản lý dòng tiền)
• Chi phí thất bại: $400,000 (chi phí tích hợp API phức tạp, lỗi tài chính, mất lòng tin, tăng khiếu nại, và các vấn đề về bảo mật, fraud)

Chi phí thất bại kỳ vọng = 35% × $400,000 = $140,000

Bạn có sẵn sàng bỏ ra $25,000 để tránh nguy cơ mất $140,000?

Đáng làm. Đây là khoản đầu tư cần thiết để kiểm tra kỹ trước khi can thiệp vào hệ thống thanh toán phức tạp, có ảnh hưởng lớn đến cả vận hành lẫn trải nghiệm người dùng.

Nhưng rủi ro không phải lúc nào cũng nằm trên bảng tính.

Vài năm trước, tôi từng tham gia một sản phẩm về insurtech, với mục tiêu xây dựng hệ thống quản lý, thẩm định, và cấp hợp đồng bảo hiểm điện tử trên nền tảng e-commerce.

Chúng tôi dành hơn hai tháng để xác thực hướng đi trước khi lập team: phối hợp với đội tư vấn chiến lược từ McKinsey, tổ chức workshop cùng chuyên gia định phí của phía nhà bảo hiểm, phỏng vấn nhóm khách hàng mục tiêu, và xây dựng mô hình yêu cầu bồi thường bảo hiểm (claim)

Thậm chí, chúng tôi còn mô phỏng hàng loạt edge case hiếm gặp như như người dùng cố tình làm giả giấy tờ để vượt qua eKYC, dùng danh tính người khác để mua bảo hiểm, hoặc phối hợp bên thứ ba để dàn dựng hồ sơ đòi bồi thường, nhằm đảm bảo hệ thống thẩm định đủ thông minh và phát hiện được các hành vi gian lận tiềm ẩn ngay từ đầu.

Nhưng đến khi bắt đầu thử nghiệm thực tế, chúng tôi mới phát hiện rằng chỉ cần một bộ quy tắc phòng chống gian lận đơn giản, như kiểm tra chéo thông tin giấy tờ với dữ liệu định danh quốc gia (thông qua bên thứ 3 uy tín về eKYC), giám sát hành vi đăng ký mua bảo hiểm trên hệ thống, và đánh dấu các hồ sơ có tần suất yêu cầu bồi thường bất thường là đã đủ để phát hiện phần lớn các hành vi gian lận phổ biến. Không cần xây dựng hệ thống kỹ thuật quá phức tạp.

Trong thời gian đó, đội vận hành phía nhà bảo hiểm đã tạm thời triển khai một quy trình bán thủ công: lọc hồ sơ qua Google Sheet, kiểm tra định kỳ theo checklist có sẵn, đối chiếu thủ công với danh sách nghi vấn nội bộ. Bất ngờ là phương án này lại cho kết quả rõ ràng và nhanh hơn mong đợi, khách hàng đánh giá cao vì dễ triển khai, dễ kiểm soát, và phản hồi cho khách hàng cũng nhanh hơn nhiều so với giải pháp “chưa hoàn thiện” của nhóm sản phẩm.

Kết quả là: chúng tôi không chỉ tiêu tốn thời gian và nguồn lực phát triển, mà còn đánh mất thời điểm thị trường. Một vấn đề vốn cần một giải pháp thực dụng, dễ triển khai và linh hoạt lại bị biến thành một bài toán kỹ thuật phức tạp, chỉ vì chúng tôi quá kỳ vọng vào việc phải “làm ra thứ gì đó đột phá”.

Vì sao những ý tưởng đơn giản nên làm luôn

Nếu rơi vào trường hợp này, tôi hay nói vui với mọi người rằng "Idea is cheap"

Từ "cheap idea" trong ngữ cảnh này không chỉ nói đến chi phí tiền bạc thấp, mà còn bao hàm ý đơn giản, dễ làm, rủi ro thấp, và không tốn nhiều nguồn lực. Với những ý tưởng đơn giản và ít rủi ro, tốt nhất là cứ làm rồi học từ thực tế.

Bài toán đơn giản: khi chi phí thất bại thấp, thì đầu tư quá nhiều vào nghiên cứu trước khi làm là không đáng.

Điều này càng đúng hơn trong bối cảnh hiện tại khi có AI, khi các phương pháp triển khai hiện đại đã trở nên phổ biến hơn nhiều so với 5 năm về trước.

Tất cả những lợi thế mới đều giúp việc “thất bại” trở nên rẻ và an toàn hơn rất nhiều. Vì thế, nếu kịch bản tệ nhất chỉ là “ngày mai mình rollback”, thì không có lý do gì để tốn hàng tuần chỉ để build một thứ có thể click được.

Vì vậy, những ý tưởng tốn ít nguồn lực thì càng nên triển khai sớm để học nhanh.

Nếu bạn không thích tính toán

Thì đây là một checklist mang tính cảm tính hơn: Hãy nghĩ đơn giản như mua bảo hiểm: khi nào nên "mua bảo hiểm cao cấp", và khi nào thì không cần.

Nên “mua bảo hiểm” (tức là làm discovery kỹ lưỡng) khi:

• Giải pháp cần nhiều thời gian và công sức để triển khai
• Giải pháp liên quan đến các luồng và vấn đề cực kỳ quan trọng (như thanh toán, bảo mật dữ liệu)
• Giải pháp ảnh hưởng đến phần lớn người dùng
• Giải pháp khó rollback sau khi đã triển khai
• Giải pháp có thể tác động đến thương hiệu hoặc uy tín công ty

Có thể “không mua bảo hiểm” (tức là triển khai nhanh) khi:

• Giải pháp đơn giản, dễ xây
• Có thể dễ dàng rollback nếu có vấn đề
• Chỉ ảnh hưởng đến một nhóm nhỏ người dùng
• Có thể ra mắt thông qua feature flag để kiểm soát rủi ro đối với 1 nhóm nhỏ người dùng (nếu kiểm soát được về mặt technical)
• Không phụ thuộc nhiều vào kỹ thuật hay hệ thống khác
• Giống với những tính năng bạn đã từng làm thành công trước đó

Thu hẹp khoảng cách niềm tin

Ngay cả khi các con số cho thấy rõ ràng: “nên triển khai luôn”, thì người làm sản phẩm vẫn thường phải đối mặt với những stakeholder muốn có mức độ xác thực rất cao trước khi đồng ý.

Trong những trường hợp như vậy, hãy cân nhắc gọi đây là một thử nghiệm (experiment) hoặc chỉ đơn giản là bản test nội bộ (nếu công ty có hàng trăm nhân viên) thay vì một bản phát hành chính thức (launch), một thứ có thể tắt bất cứ lúc nào nếu dữ liệu cho thấy nó không hiệu quả.

Bạn cũng nên trình bày những con số bạn đang có, và dự đoán sẽ có. Cách tiếp cận này giúp biến dự án thành một thử nghiệm có kiểm soát, tiết kiệm tài nguyên, và không mang dáng dấp một canh bạc rủi ro, từ đó dễ nhận được sự đồng thuận hơn từ stakeholder.

Cân bằng giữa nghiên cứu và triển khai

Là những người xây dựng sản phẩm, chúng ta luôn phải sống trong giới hạn: thời gian có hạn, nguồn lực giới hạn, và mỗi giờ làm việc đều là sự đánh đổi với những việc khác.

Những team làm sản phẩm thông minh sẽ tránh được cả hai loại lãng phí:

• Dành quá nhiều công sức cho những ý tưởng nhỏ, vốn có thể kiểm chứng nhanh trong thực tế
• Triển khai vội vàng những tính năng mà nếu thất bại sẽ gây thiệt hại lớn

Cách ra quyết định nhanh và hiệu quả (kể cả không cần tính toán chi tiết):

• Khi chi phí thất bại thấp: ưu tiên tốc độ
• Khi chi phí thất bại cao: ưu tiên sự chắc chắn

Và nếu bạn chưa thực sự hiểu người dùng đang gặp vấn đề gì, thì chắc chắn bạn cần thực hiện nghiên cứu khám phá (generative research) trước.

Những người làm sản phẩm giỏi không chỉ chọn giữa tốc độ và sự chắc chắn, họ biết lúc nào nên chọn cái nào.

Đó mới chính là bản chất thật sự của "discovery".