Bài 6 — Problem Discovery vs Solution Discovery

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

Có một sự thật phũ phàng trong nghề làm sản phẩm: phần lớn đội ngũ khởi nghiệp và product team không thất bại vì họ xây dở. Họ thất bại vì xây thứ chẳng ai cần. Họ viết code rất giỏi, thiết kế rất đẹp, marketing rất mượt — nhưng giải một vấn đề mà thị trường không thực sự quan tâm. Và gốc rễ của sai lầm chết người đó gần như luôn nằm ở việc người ta nhảy quá sớm sang phần "giải pháp" mà chưa từng nghiêm túc xác nhận "vấn đề".

Bài học hôm nay tách bạch hai pha discovery mà rất nhiều người Việt làm sản phẩm vẫn gộp làm một: Problem Discovery (khám phá vấn đề) và Solution Discovery (khám phá giải pháp). Đây không phải hai cách gọi khác nhau của cùng một việc. Chúng là hai pha có mục tiêu khác nhau, câu hỏi khác nhau, phương pháp khác nhau, và tiêu chí "xong" khác nhau. Lẫn lộn hai pha này là một trong những antipattern tốn kém nhất mà tôi từng chứng kiến trong các startup Việt Nam.

Khi bạn nắm vững ranh giới giữa hai pha, bạn sẽ tiết kiệm được hàng tháng trời và hàng trăm triệu đồng. Bạn sẽ biết khi nào nên hỏi user "bạn đang khổ vì cái gì" và khi nào nên hỏi "giải pháp này có giúp được bạn không". Bạn sẽ ngừng yêu giải pháp của mình một cách mù quáng.

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

Hai pha, hai mục tiêu hoàn toàn khác nhau

Problem Discovery là pha bạn đi tìm và xác nhận một vấn đề ĐÁNG GIẢI cho một nhóm user thật. Câu hỏi trung tâm ở đây là: "Vấn đề này có tồn tại không? Nó đau đến mức nào? Ai đang chịu đựng nó? Họ đang đối phó tạm bợ ra sao? Họ có sẵn lòng trả tiền hoặc thay đổi hành vi để thoát khỏi nó không?" Ở pha này, bạn TUYỆT ĐỐI chưa được phép nghĩ về sản phẩm của mình. Output của pha này không phải là tính năng, mà là một mệnh đề kiểu: "Nhóm X đang gặp vấn đề Y với mức độ nghiêm trọng Z, và hiện chưa có cách giải quyết thỏa đáng."

Solution Discovery là pha bạn đi tìm và xác nhận một giải pháp KHẢ THI và HẤP DẪN cho vấn đề đã được xác nhận ở pha trước. Câu hỏi trung tâm chuyển thành: "Cách giải này có thực sự gỡ được nỗi đau không? User có hiểu nó không? Họ có dùng được không? Nó có đủ tốt hơn giải pháp hiện tại để họ chịu chuyển đổi không? Ta có làm ra được nó với nguồn lực đang có không?" Output của pha này là một concept giải pháp đã được validate — đủ bằng chứng để bắt đầu xây.

Hãy ghi nhớ thứ tự bất di bất dịch: Problem trước, Solution sau. Bạn không thể đánh giá một giải pháp tốt hay dở nếu chưa biết rõ nó đang giải vấn đề gì và vấn đề đó nặng nhẹ ra sao.

Vì sao não chúng ta luôn muốn nhảy thẳng sang Solution

Đây là chỗ tinh tế. Bộ não con người, đặc biệt là não của những người thông minh, giỏi kỹ thuật, có xu hướng "solution-first". Bạn vừa nghe một khách hàng phàn nàn vài câu, lập tức đầu bạn đã bật ra ba ý tưởng app, hai luồng tính năng. Cảm giác đó rất sướng — nó cho ta ảo giác mình đang tiến bộ. Nhưng nó là cái bẫy. Khi đã có giải pháp trong đầu, bạn sẽ vô thức đi tìm bằng chứng ủng hộ giải pháp đó (confirmation bias) thay vì đi tìm sự thật về vấn đề.

Người làm discovery giỏi rèn được kỷ luật "ngồi yên trong vấn đề" (sit with the problem). Họ chịu được sự khó chịu của việc chưa-có-giải-pháp, để hiểu vấn đề thật sâu trước khi cho phép mình thiết kế.

Bảng so sánh nhanh để khắc vào đầu

Ranh giới không phải là bức tường, mà là cánh cửa một chiều

Một hiểu lầm phổ biến: nghĩ rằng làm xong Problem Discovery thì đóng lại, sang Solution Discovery là quên hẳn vấn đề. Sai. Bạn vẫn liên tục đối chiếu giải pháp ngược về vấn đề. Nhưng có một nguyên tắc: bạn không nên quay lại "phát minh thêm vấn đề mới" để biện minh cho một giải pháp bạn lỡ yêu. Cánh cửa đi một chiều — từ vấn đề đã xác nhận sang giải pháp, chứ không phải từ giải pháp ngược về bịa ra vấn đề.

Tình huống thực tế

Ví dụ 1 — Startup giao đồ ăn cho dân văn phòng (thất bại vì bỏ qua Problem Discovery)

Năm 2019, một nhóm ba bạn trẻ ở TP.HCM lập startup tên tạm gọi là "CơmTrưa". Ý tưởng: app đặt cơm trưa theo tuần cho dân văn phòng, đặt một lần ăn cả tuần, giảm phiền phức quyết định mỗi ngày. Họ yêu ý tưởng này đến mức bỏ ra 5 tháng và khoảng 400 triệu đồng để xây app hoàn chỉnh: chọn món theo tuần, thanh toán ví điện tử, lịch giao thông minh.

Họ launch. Tải về được vài trăm lượt. Nhưng tỷ lệ đặt-lại sau tuần đầu chỉ khoảng 6%. Khi cuối cùng họ chịu đi phỏng vấn user, sự thật lộ ra: dân văn phòng ở khu vực họ nhắm tới không coi việc quyết định ăn gì mỗi trưa là một nỗi đau. Ngược lại, nhiều người coi đó là khoảnh khắc thư giãn duy nhất trong ngày — đi bộ ra ngoài, tán gẫu với đồng nghiệp, đổi món tùy hứng. "Đặt cả tuần" giết mất sự linh hoạt mà họ thích.

Bài học: CơmTrưa đã làm Solution Discovery rất tốt (app mượt, đẹp) nhưng chưa từng làm Problem Discovery. Họ giả định nỗi đau "mệt vì phải quyết định ăn gì" mà không xác nhận. Hóa ra cái họ tưởng là vấn đề lại là một thói quen được yêu thích. 400 triệu đồng đáng lẽ tiết kiệm được chỉ bằng 20 cuộc phỏng vấn vấn đề trước khi viết một dòng code.

Ví dụ 2 — Một fintech làm đúng thứ tự (Problem trước, Solution sau)

Hãy nhìn cách các đội làm ví điện tử thời kỳ đầu ở Việt Nam tiếp cận. Lấy một tình huống điển hình: đội sản phẩm phát hiện trong Problem Discovery rằng các bà bán hàng ở chợ truyền thống có một nỗi đau rất thật — cuối ngày phải đếm tiền mặt, lo tiền giả, lo trộm cắp, và khó vay vốn vì không có lịch sử giao dịch chứng minh được. Họ phỏng vấn hàng chục tiểu thương, ghi nhận đi ghi nhận lại cùng một câu chuyện, thậm chí có người đã tự "đối phó" bằng cách ghi sổ tay nguệch ngoạc. Đó là tín hiệu Problem Discovery đạt: nỗi đau lặp lại, người ta đã trả giá (thời gian, rủi ro) để đối phó.

Chỉ sau khi xác nhận vấn đề, họ mới bước sang Solution Discovery: thử nghiệm mã QR thanh toán dán tại quầy. Họ không xây nguyên một hệ thống khổng lồ ngay. Họ đưa cho 15 tiểu thương ở một khu chợ thử trong vài tuần, quan sát: bà nào dán QR lên, bà nào gỡ xuống, khách có quét không, người bán có tin con số hiện trên điện thoại không. Phản hồi hành vi (chứ không phải lời khen) mới quyết định họ đi tiếp.

Bài học: Vì vấn đề đã được xác nhận trước, Solution Discovery của họ tập trung và rẻ. Họ không phải đoán "liệu người ta có cần không" — họ chỉ cần tìm ra "hình hài nào của giải pháp thì khớp". Đó là sức mạnh của việc tách đúng hai pha.

Ví dụ 3 — Nhầm lẫn tinh vi: hỏi giải pháp trong khi tưởng đang khám phá vấn đề

Một học viên cũ của tôi làm ứng dụng học tiếng Anh. Bạn ấy tự tin nói "Em đã làm Problem Discovery rồi, phỏng vấn 30 người". Tôi xin xem bảng câu hỏi. Hóa ra câu chính là: "Nếu có một app dạy phát âm bằng AI chấm điểm thì anh/chị có thích không?" và 80% trả lời "có, hay đấy".

Đó không phải Problem Discovery. Đó là hỏi ý kiến về một giải pháp đã định sẵn — và còn hỏi sai cách (hỏi tương lai giả định, dễ được khen lịch sự). Bạn ấy tưởng đang xác nhận vấn đề, thực ra đang thu thập những lời "ừ hay đấy" vô giá trị.

Tôi yêu cầu bạn ấy làm lại đúng pha vấn đề: "Lần gần nhất anh/chị cố cải thiện tiếng Anh là khi nào? Lúc đó cụ thể làm gì? Khúc nào nản nhất khiến anh/chị bỏ cuộc?" Câu trả lời thật bất ngờ: nỗi đau lớn nhất không phải phát âm, mà là duy trì động lực và không biết mình tiến bộ hay chưa. Cả định hướng sản phẩm xoay 90 độ.

Bài học: Hỏi "bạn có thích giải pháp X không" là Solution-talk đội lốt Problem Discovery. Problem Discovery thật sự đào vào hành vi quá khứ và nỗi đau cụ thể, không nhắc tới giải pháp.

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

Bước 1 — Tự kiểm tra: bạn đang ở pha nào? Trước mỗi cuộc trò chuyện với user, viết ra một câu: "Buổi này tôi đang xác nhận VẤN ĐỀ hay đang test GIẢI PHÁP?" Nếu không trả lời được rõ ràng, bạn chưa nên ngồi với user.

Bước 2 — Làm Problem Discovery cho ra ngô ra khoai trước. Mục tiêu: tìm bằng chứng nỗi đau có thật. Hỏi về quá khứ và hành vi cụ thể, không hỏi giả định tương lai. Tìm dấu hiệu user đã tự bỏ công sức đối phó (workaround) — đó là chỉ dấu mạnh nhất của vấn đề đáng giải. Dừng lại khi nhiều user độc lập kể cùng một nỗi đau và bạn mô tả được nó bằng ngôn ngữ của họ.

Bước 3 — Viết "Mệnh đề vấn đề" rõ ràng. Theo mẫu: "[Nhóm user cụ thể] đang gặp [vấn đề] khi [bối cảnh], hiện họ đối phó bằng [workaround] và điều này gây [hậu quả/chi phí]." Nếu chưa điền được đầy đủ mẫu này bằng dữ liệu thật, đừng sang pha sau.

Bước 4 — Chuyển sang Solution Discovery một cách có ý thức. Bây giờ mới cho phép não brainstorm giải pháp. Nhưng kỷ luật: mỗi giải pháp phải nối thẳng về mệnh đề vấn đề ở bước 3. Nếu một tính năng không gỡ được nỗi đau đã xác nhận, gạch bỏ.

Bước 5 — Test giải pháp bằng hành vi, không bằng lời khen. Cho user dùng thử bản thô nhất có thể (prototype, bản vẽ, thậm chí làm tay). Quan sát họ làm gì, không chỉ nghe họ nói gì. Tín hiệu thật: họ đăng ký, họ quay lại, họ giới thiệu, họ trả tiền — chứ không phải "ý tưởng hay đấy".

Bước 6 — Đối chiếu ngược, lặp lại. Sau mỗi vòng, hỏi: giải pháp có thực sự khớp vấn đề không? Nếu lệch, quay về tinh chỉnh giải pháp — chứ đừng bịa thêm vấn đề mới để cứu giải pháp bạn lỡ yêu.

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

Lỗi 1 — Nhảy thẳng sang Solution. Triệu chứng: bạn đã có wireframe trước khi nói chuyện với 10 user về nỗi đau. Mẹo: cấm bản thân vẽ giao diện cho tới khi viết xong Mệnh đề vấn đề.

Lỗi 2 — Hỏi ý kiến về giải pháp và tưởng đó là xác nhận vấn đề. "Bạn có thích app này không?" cho ra câu trả lời lịch sự, vô dụng. Mẹo: ở pha vấn đề, không bao giờ nhắc đến sản phẩm của bạn. Chỉ đào hành vi quá khứ.

Lỗi 3 — Coi lời khen là validation. "Hay đấy", "tôi sẽ dùng" là tín hiệu rác. Mẹo: chỉ tin commitment có chi phí — tiền đặt cọc, email đăng ký thật, thời gian dùng thử thực tế.

Lỗi 4 — Yêu giải pháp đến mức bóp méo vấn đề. Khi giải pháp không khớp, người ta hay đi tìm "user khác" hoặc "vấn đề khác" để biện minh. Mẹo: nếu phải liên tục đổi định nghĩa vấn đề để cứu giải pháp, đó là dấu hiệu giải pháp sai.

Lỗi 5 — Làm Problem Discovery hời hợt rồi tự nhủ "đủ rồi". Ba cuộc trò chuyện thân quen với bạn bè không phải là Problem Discovery. Mẹo: nói chuyện với người lạ trong nhóm mục tiêu, tới khi câu chuyện bắt đầu lặp lại (saturation).

Mẹo vàng: Mỗi khi bí, hãy tự hỏi: "Tôi đang yêu vấn đề hay đang yêu giải pháp?" Người làm discovery giỏi yêu vấn đề một cách kiên định và giữ thái độ lạnh lùng với giải pháp — sẵn sàng vứt bỏ bất cứ giải pháp nào không gỡ được nỗi đau.

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

• Phân loại pha. Lấy 5 câu hỏi bạn từng định hỏi (hoặc đã hỏi) user. Với mỗi câu, dán nhãn: đây là Problem-talk hay Solution-talk? Viết lại mọi câu Solution-talk lỡ trá hình thành câu Problem-talk đúng nghĩa (đào hành vi quá khứ).

• Viết Mệnh đề vấn đề. Cho ý tưởng sản phẩm bạn đang ấp ủ, điền đầy đủ mẫu ở Bước 3 chỉ bằng dữ liệu thật bạn đang có. Chỗ nào phải đoán, đánh dấu đỏ — đó chính là lỗ hổng Problem Discovery bạn cần lấp.

• Thiết kế hai kịch bản. Viết outline 5 câu cho một buổi Problem Discovery, và outline cho một buổi Solution Discovery của cùng ý tưởng. So sánh hai outline để tự thấy rõ sự khác biệt về mục tiêu và cách hỏi.

• Săn workaround. Tìm trong nhóm user mục tiêu một bằng chứng cho thấy họ đã tự bỏ công đối phó với vấn đề (file Excel tự chế, nhóm Zalo, ghi sổ tay...). Nếu không tìm được workaround nào, hãy nghi ngờ nghiêm túc rằng vấn đề chưa đủ đau.

Tóm tắt

Problem Discovery và Solution Discovery là hai pha tách biệt với mục tiêu, câu hỏi và tiêu chí hoàn thành khác nhau. Problem Discovery trả lời "vấn đề có thật và đáng giải không" — bạn đào nỗi đau và hành vi quá khứ, không được nhắc tới sản phẩm. Solution Discovery trả lời "giải pháp có gỡ được vấn đề và khả thi không" — bạn cho user thử và đo hành vi, không nghe lời khen suông.

Thứ tự là bất di bất dịch: vấn đề trước, giải pháp sau, và cánh cửa đi một chiều. Sai lầm tốn kém nhất là nhảy thẳng sang giải pháp (như CơmTrưa mất 400 triệu) hoặc ngụy trang Solution-talk thành Problem Discovery (như app tiếng Anh hỏi "bạn có thích AI chấm điểm không"). Khi bạn rèn được kỷ luật yêu vấn đề và giữ khoảng cách với giải pháp, bạn đã có vũ khí mạnh nhất để không xây thứ chẳng ai cần.