#60 - Bạn có nên để AI làm problem discovery không?
Những gì bạn nên để cho AI làm, và những gì bạn không nên
Có một câu hỏi mình đã suy nghĩ khá lâu trong vài tháng gần đây, khi quan sát cách các product team xung quanh mình đang tích hợp AI vào quy trình làm sản phẩm. Câu hỏi đó là:
"tại sao có những công đoạn AI làm rất tốt, nhanh hơn con người nhiều lần, mà chúng ta vẫn cảm thấy có gì đó lệch khi để AI làm thay?"
Câu trả lời, mình nghĩ, không nằm ở giới hạn kỹ thuật của AI. Nó nằm ở chỗ chúng ta đang nhầm lẫn giữa hai loại công cụ rất khác nhau.
Hai loại interface
Trước khi nói về AI, hãy nói về interface. Không chỉ là những gì hiện ra trên màn hình, mà là bất kỳ cơ chế nào giúp con người tương tác với thế giới để đạt được một mục tiêu.
Ngôn ngữ là interface để suy nghĩ và giao tiếp. Chữ viết là interface để lưu trữ và truyền đạt tri thức qua thời gian. Hệ thống số cũng là một interface, một cách để chúng ta thao tác với những khái niệm trừu tượng như lượng và phép toán. Như câu thường được nhắc đến: "We shape our tools, and thereafter our tools shape us."
Thử đặt mình vào bối cảnh thời La Mã. Nếu bạn là một người làm kế toán thời đó, việc tính toán với I, V, X… không chỉ bất tiện mà còn giới hạn khả năng xử lý những phép tính phức tạp. Những phép cộng nhiều chữ số như 12 + 53 + 63 trở nên cồng kềnh, khó kiểm soát, và dễ sai sót - không phải vì con người thời đó không thông minh bằng, mà vì interface mà họ đang sử dụng không phù hợp với loại vấn đề họ cần giải quyết.
Linus Lee - Head of AI tại Thrive Capital và cựu Research Engineer tại Notion, có một bài viết về chủ đề này mang tên "Instrumental Interfaces, Engaged Interfaces." Trong đó, anh ta phân biệt rõ giữa hai loại interfaces - instrumental interface và engaged interface, dựa trên cách chúng ta sử dụng chúng:
- Instrumental interface phục vụ những người dùng khá là goal-oriented. Người dùng chỉ muốn có một giải pháp đủ tốt cho vấn đề của họ, và không quan tâm đến quá trình. Một bài kiểm tra Linus đề xuất khá hay: nếu bạn có một nút thần kỳ để hoàn thành tác vụ ngay lập tức, bạn có nhấn không? Nếu câu trả lời là có, thì bạn đang nhìn vào một instrumental interface. Grab, app giao đồ ăn, form điền đơn xin việc đều thuộc loại này.
- Engaged interface thì khác. Người dùng muốn được tham gia trực tiếp vào cơ chế của interface. Họ sử dụng nó không phải để check off một thứ phải làm, mà vì có giá trị nội tại trong việc tương tác với chính nó. Một nhạc cụ, một bàn cờ, một bộ flash card đều thuộc loại này. Người chơi nhạc không muốn nghe một bản thu sẵn, họ muốn cảm giác tự mình chơi. Người học bằng flash card không muốn được trao kết luận, họ muốn quá trình tự ghi nhớ.
Đến đây có thể bạn sẽ nghĩ: vậy engaged interface là dành cho những việc mình muốn enjoy, còn việc nào mình không enjoy thì cứ xài instrumental cũng được.
Mình muốn mở rộng ý của Linus thêm một bước, vì cách hiểu trên chưa đủ. Engaged interface không chỉ dành cho những việc mình thấy vui. Nó còn dành cho loại công việc mà giá trị thực sự được tạo ra trong chính quá trình làm, chứ không phải ở output cuối cùng. Một tác vụ có thể không vui nhưng vẫn cần engaged interface, nếu bản chất của nó là việc nhận thức được hình thành dần qua quá trình, không thể nén lại thành kết luận.
Lấy ví dụ như chuyện luyện đàn: nếu bạn outsource việc luyện đàn cho AI, như kiểu bấm một cái nút để chơi nhạc, bạn không trở thành người chơi đàn giỏi được, vì kỹ năng chỉ hình thành qua chính quá trình tập. Câu hỏi mình muốn đặt ra trong bài này là: problem discovery thuộc loại nào? Nó giống đặt xe (giá trị ở kết quả) hay giống luyện đàn (giá trị ở quá trình)?
Những gì nên để AI làm
Khi bạn cần di chuyển từ điểm A đến điểm B, điều duy nhất bạn quan tâm là đến được nơi cần đến. A và B đã rõ ràng trong đầu bạn, và bạn cũng chẳng mặn mà gì với chuyện một chiếc xe được cấu trúc ra sao ở bên trong. Đây chính là bối cảnh mà một instrumental interface như Grab phát huy giá trị: bạn book xe, tài xế đến điểm A, đưa bạn đến điểm B, và cuộc trao đổi kết thúc ở đó.
AI Agents có thể được xem như một instrumental interface tương đối lý tưởng, bởi vì nó giúp cho bạn đi từ A đến B một cách hiệu quả hơn, với điều kiện bạn miêu tả đủ rõ hai trạng thái và không cần quá chấp niệm về các chi tiết cụ thể trong quá trình di chuyển đó.
Ví dụ điển hình là chuyện viết report hàng tuần. Bạn có input rõ ràng là các nguồn thông tin, có output rõ ràng là một văn bản đi theo cấu trúc và tông giọng đã định sẵn, và bạn cũng không mấy bận tâm đến quá trình chuyển từ input sang output diễn ra như thế nào.
Đây là use case mà AI Agents gần như được sinh ra để giải quyết, bởi không mấy ai enjoy chuyện viết report, và bản thân công việc này cũng không phải là thứ giúp bạn làm dày được kỹ năng nội tại qua thời gian. Nếu bạn như mình, bạn sẽ muốn cái report được xong càng nhanh càng tốt, để dành thời gian cho những việc mà quá trình mới là nơi tạo ra giá trị. Sử dụng AI Agents trong bối cảnh đó là hoàn toàn hợp lý.
Nhưng product discovery thì nó không vận hành theo logic đó.
Bản chất của vấn đề
Trong làm sản phẩm, việc tìm kiếm và định nghĩa được vấn đề, hay problem discovery, đã là phân nửa cuộc chiến. Phân nửa còn lại là solution discovery, dựa vào chuyên môn cũng như domain knowledge của bạn, cũng là một bài toán nan giải bất định không kém. Trong bài viết này mình sẽ chủ yếu xoay quanh problem discovery, bởi đây là phân khúc mình quan sát thấy nhiều vướng mắc nhất.
Nếu chúng ta định nghĩa được "vấn đề" là gì, thì câu trả lời tại sao problem discovery lại khó giao cho AI Agent sẽ trở nên rõ ràng hơn. Bản chất của thứ chúng ta gọi là vấn đề có thể được phân rã thành ba cấu thành, mình sẽ miêu tả thông qua ví dụ sau (cũng là một vấn đề mình thường gặp):
- Trạng thái hiện tại (current state). Khi tôi có ba mẹ hoặc người thân lớn tuổi ở xa đang cần di chuyển từ nhà họ đến một địa điểm nào đó, và họ lại nhờ tôi đặt xe công nghệ cho họ, nhưng giờ di chuyển của họ lại vào 3-4 giờ sáng lúc tôi vẫn còn đang ngủ.
- Trạng thái mong muốn (desired state). Đảm bảo rằng người thân của tôi có xe công nghệ đến đón đúng giờ, ở đúng địa chỉ và di chuyển đúng nơi cần đến, mà không cần tôi phải thức dậy lúc 3-4 giờ sáng.
- Khoảng cách giữa hai trạng thái (gap). Hiện tại tôi đang phải lựa chọn giữa việc thức dậy lúc 3-4 giờ sáng để đặt xe, hoặc để lỡ và rủi ro ba mẹ không có xe. Mong muốn là một cơ chế cho phép tôi không cần thức dậy mà vẫn đảm bảo được việc đưa đón.
Không gian vấn đề (problem space) là không gian chứa đựng mọi trạng thái khả dĩ mà bài toán có thể ở trong đó, với current state và desired state chỉ là hai điểm đặc biệt trên không gian này.
Mỗi chiều của không gian là một biến số mà giải pháp phải thỏa mãn. Trong ví dụ trên, có thể kể ra các chiều như: độ tin cậy của tài xế, khả năng có backup khi tài xế hủy, độ chính xác của địa chỉ đón và trả, mức độ yên tâm của người đặt xe, chi phí, và còn nhiều chiều khác chưa được phát hiện ra. Các chiều này không trực quan như thế giới vật lý ba chiều, và chúng có sự phụ thuộc với nhau theo những cách không phải lúc nào cũng nhìn thấy ngay được: tăng độ tin cậy có thể đẩy chi phí lên, cải thiện luồng có tài xế backup có thể làm phức tạp hóa UX. Mỗi quyết định ở một chiều đều tạo nên gợn sóng ở các chiều khác.
Một "vấn đề" trong không gian này được khai phá bằng phương pháp tương tự như nhắm mắt và dùng hai bàn tay chạm vào một vật thể: bạn cảm nhận đường nét ở chỗ này, chất liệu ở chỗ kia, và dần dần một hình dạng tổng thể hiện ra trong đầu. Khác biệt với vật thể vật lý là không gian vấn đề không có sẵn hình dạng cố định để khám phá. Chính cách bạn chạm, chạm ở đâu, theo thứ tự nào, sẽ tham gia vào việc định hình nó. Cùng một tình huống có thể được khái niệm hóa thành nhiều không gian vấn đề khác nhau tùy vào framing của người làm sản phẩm. Đây là lý do hai PM cùng nhìn vào một đống dữ liệu có thể đi đến hai problem space rất khác nhau, và từ đó đi đến hai sản phẩm rất khác nhau.
Quay trở lại vấn đề mình gặp ở trên, chức năng đặt xe trước của Grab hay Be là giải pháp hiển nhiên nhất, nhưng nó chỉ giải quyết được phần nổi. Phần chìm là nỗi lo của mình: nếu tài xế hủy thì sao, app có tự tìm tài xế khác cho đến khi được không, và nếu không thì ba mẹ mình lấy gì mà đi. Chính nỗi lo đó, chứ không phải nhu cầu đặt xe từ A đến B, mới là trạng thái hiện tại thực sự của mình. Nó nằm ở một chiều khác trong không gian vấn đề, chiều của sự yên tâm, mà chỉ khi PM ngồi đủ lâu với context mới phát hiện ra được. Đây là loại chi tiết mà người làm sản phẩm cần khai phá, và nó cần chúng ta ở trong không gian vấn đề đủ lâu để cảm nhận được các chuyển động và diễn biến giữa các chiều với nhau.
Ví dụ trên minh họa một điểm mình cho là cốt lõi của problem discovery: công việc này về bản chất là quá trình khai phá được landscape của không gian vấn đề, nhận diện được các chiều quan trọng, hiểu được dependencies giữa chúng, và định vị được current state lẫn desired state trên landscape đó. Các kỹ thuật mà bạn hay nghe, từ phỏng vấn người dùng đến research định tính định lượng, đều không phải là đích đến, mà là phương tiện để đạt được độ sâu đó. Độ sâu này quan trọng, vì chất lượng của giải pháp không thể vượt qua giới hạn hiểu biết của bạn về không gian vấn đề.
Bạn không nên để AI làm discovery thay bạn
Đến đây, lý do problem discovery khó giao cho AI Agents dần trở nên rõ ràng, và nó không nằm ở giới hạn kỹ thuật của AI. Nó nằm ở chỗ input cần thiết cho quá trình này vốn dĩ không tồn tại sẵn ở đâu để cung cấp.
Chúng ta hiếm khi biết được trạng thái hiện tại của người dùng một cách chính xác, bởi tiên đoán của một người đứng ngoài domain, hoặc chưa gầy dựng đủ thấu cảm qua thời gian, gần như luôn lệch so với thực tế. Trạng thái mong muốn còn khó hơn một bậc, bởi những gì chúng ta nghĩ rằng người dùng muốn thường là sự phóng chiếu từ chính những thứ chúng ta muốn, chứ không phải là quan sát khách quan. Conviction và intuition có vai trò của chúng, đôi khi còn là thứ quyết định, nhưng bản chất của chúng vẫn là giả thuyết, và giả thuyết chỉ có giá trị khi được kiểm chứng qua va chạm với thực tế.
Vấn đề then chốt là như sau: nếu chính người làm sản phẩm còn chưa thể phát biểu rõ ràng được trạng thái hiện tại, trạng thái mong muốn, và khoảng cách giữa chúng, thì AI Agents lấy gì làm nguyên liệu để làm việc đây?
Hãy thử làm lại bài kiểm tra mà Linus đề xuất ở đầu bài. Nếu có một nút thần kỳ giúp bạn hoàn thành tác vụ ngay lập tức, bạn có nhấn không? Với viết báo cáo, đặt xe, điền form, câu trả lời gần như luôn là có. Nhưng với problem discovery, câu trả lời phức tạp hơn nhiều.
Giả sử có một AI Agent nói với bạn rằng: "Tôi đã phỏng vấn 50 người dùng của bạn, và đây là ba vấn đề lớn nhất của họ."
Bạn có tin không? Quan trọng hơn, bạn có dám ra quyết định dựa trên output đó không? Có lẽ là không. Không phải vì bạn nghi ngờ năng lực của AI, mà vì bản thân quá trình đi qua từng cuộc phỏng vấn, từng quan sát, từng lần bị bất ngờ bởi một câu trả lời không giống với giả thuyết ban đầu, chính là cách mà sự hiểu biết về không gian vấn đề được hình thành trong đầu bạn. Nếu bạn bỏ qua quá trình đó, cái bạn nhận được là kết luận, không phải sự thấu hiểu. Rất khó để đặt cược sự sinh tồn của cả một sản phẩm lên kết luận của một cỗ máy vô hồn.
Hợp lý không có nghĩa là đúng
Đây là điểm mà sự phân biệt khái niệm của Linus trở nên cực kỳ hữu dụng. Problem discovery không phải là một tác vụ có thể outsource judgement cho đến khi có output cuối cùng. Nó là một quá trình mà chính bản thân việc tham gia vào nó tạo ra giá trị. Giống như một nhạc sĩ không thể outsource việc luyện đàn cho AI rồi kỳ vọng rằng mình sẽ biết chơi, một PM không thể outsource việc hiểu người dùng và kỳ vọng rằng mình sẽ biết phải build gì.
Cái được rèn ra trong quá trình đó không phải là một bản research report, mà là một thứ tinh tế hơn nhiều: khả năng nhận ra đâu là signal và đâu là noise, đâu là điều người dùng nói ra, và đâu là điều họ thực sự muốn nhưng không biết cách diễn đạt.
Christopher Alexander, trong Notes on the Synthesis of Form, gọi đây là công việc tìm kiếm sự phù hợp giữa form và context. Cái khó không phải là thiết kế form, cái khó là hiểu context. Và context, theo Alexander, không bao giờ được trao sẵn. Nó phải được khám phá, mô tả, phân rã, rồi dựng lại trong đầu người làm sản phẩm, từng mảnh một. Mỗi lần phỏng vấn người dùng là một mảnh. Mỗi lần nhìn dữ liệu là một mảnh. Mỗi lần thử nghiệm một giải pháp rồi thất bại cũng là một mảnh. Không có con đường tắt nào để có được bức tranh tổng thể, bởi vì bức tranh đó không tồn tại sẵn ở đâu để lấy về. Nó được dựng lên trong đầu bạn, qua thời gian, qua va chạm, qua sửa sai. Nó không nằm trong dữ liệu đã được train sẵn của LLM.
Điều này dẫn đến một nghịch lý thú vị. AI càng mạnh, càng có khả năng tạo ra output nhanh, thì nguy cơ của việc bỏ qua quá trình discovery càng lớn. Bạn có thể yêu cầu ChatGPT sinh ra một user persona trong 30 giây, một danh sách pain points trong một phút, một product requirement document trong năm phút. Và tất cả đều nghe hợp lý.
Vấn đề là, hợp lý không có nghĩa là đúng. Một persona được sinh ra từ các pattern chung chung trong dữ liệu training sẽ không bao giờ capture được cái nuance đặc thù của người dùng cụ thể mà bạn đang phục vụ. Nó chỉ capture được cái trung bình, cái phổ biến, cái dễ được diễn đạt thành ngôn ngữ. Nhưng lợi thế cạnh tranh trong product thường không nằm ở cái trung bình. Nó nằm ở những insight riêng biệt, những quan sát mà chỉ người trong cuộc mới nhìn thấy.
Lấy lại ví dụ đặt xe cho ba mẹ. Nếu bạn hỏi AI làm sao giúp người dùng đặt xe sớm cho người thân, nó sẽ đưa ra những gợi ý rất hợp lý: đặt xe trước, thông báo cho tài xế, xác nhận địa điểm đón. Nhưng cái insight thực sự, rằng bản thân việc đặt trước cũng không đủ vì nỗi lo tài xế hủy, rằng cái người dùng thực sự cần là một cơ chế đảm bảo chứ không phải là một tính năng đặt trước, đó là thứ chỉ xuất hiện khi bạn ngồi đủ lâu với vấn đề. Bạn phỏng vấn những người dùng có cùng hoàn cảnh. Bạn nghe họ kể về những lần tài xế hủy. Bạn quan sát sự bất an trong giọng nói của họ. Và rồi bạn nhận ra, đây không phải là bài toán về tính năng đặt xe, mà là bài toán về sự yên tâm. Cái insight đó khó để AI tạo ra được. Nó phải được giành lấy và kiểm chứng.
Engaged interface cho discovery
Đây là lý do mình tin rằng problem discovery cần một engaged interface, không phải một instrumental interface. Cần một công cụ giúp bạn ở lại trong không gian vấn đề đủ lâu, đủ có cấu trúc, đủ có trật tự, để quá trình khám phá có thể diễn ra mà không bị lạc. Không phải để thay thế việc suy nghĩ, mà để hỗ trợ việc suy nghĩ. Không phải để đưa ra kết luận, mà để làm rõ các giả thuyết. Không phải để giảm số lượng cuộc phỏng vấn bạn cần thực hiện, mà để tăng chất lượng của những gì bạn học được từ mỗi cuộc phỏng vấn.
Engaged interface không có nghĩa là từ chối AI. AI vẫn có vai trò trong quá trình discovery, nhưng vai trò đó phải được định nghĩa lại. AI không phải là người ra kết luận thay bạn, mà là một đối tác để bạn đào sâu vào những điểm dữ liệu bạn đã thu thập.
Cụ thể hơn, sau khi bạn đã phỏng vấn người dùng và bắt đầu thấy một bức tranh sơ bộ, bạn có thể hỏi AI những câu kiểu: "Có pattern nào trong những gì họ không nói ra mà tôi đang bỏ lỡ không?" hoặc "Nếu giả thuyết hiện tại của tôi sai, thì lời giải thích thay thế hợp lý nhất là gì?". Đây là những câu hỏi AI làm tốt, vì chúng chỉ yêu cầu xử lý dữ liệu bạn đã thu thập, không yêu cầu nó tự phỏng vấn hay tự kết luận thay bạn. Cùng một công cụ, nhưng được dùng để mở rộng tầm nhìn của bạn, không phải để thay thế nó.
Sự khác biệt giữa hai cách dùng AI này tinh tế nhưng quan trọng. Trong cách dùng instrumental, bạn đưa cho AI một input và mong nhận được output cuối cùng. Trong cách dùng engaged, bạn đưa cho AI một bức tranh đang dở dang và mong nó giúp bạn nhìn rõ hơn những phần đang còn mờ. Cả hai đều dùng cùng một công nghệ, nhưng triết lý đứng sau là khác nhau.
Một câu hỏi kết bài
Mình không nghĩ mọi PM đều cần đồng ý với góc nhìn này. Có những team, những sản phẩm, những giai đoạn mà tốc độ quan trọng hơn độ sâu, và việc dùng AI như một instrumental tool để đẩy nhanh quá trình là một lựa chọn hợp lý. Nhưng nếu bạn là kiểu người tin rằng công việc làm sản phẩm không chỉ là việc ship tính năng, mà là một quá trình lâu dài của việc rèn giũa thấu cảm và phán đoán, thì có lẽ bạn cũng đang đi tìm một công cụ thuộc về thế giới thứ hai đó.
Câu hỏi mình muốn để lại là: trong cách làm discovery hiện tại của bạn, đâu là chỗ bạn đang vô tình dùng AI như một instrumental interface cho một vấn đề vốn dĩ cần engaged? Và nếu có thể thiết kế lại từ đầu, bạn sẽ giữ lại cái gì, bỏ đi cái gì?
Mình không có câu trả lời chung cho mọi PM, vì cách trả lời sẽ phụ thuộc vào context cụ thể của từng team, từng sản phẩm. Nhưng nếu câu hỏi này khiến bạn dừng lại một chút, có lẽ bạn cũng đang trên cùng một hành trình tìm tool phù hợp cho công việc discovery.
Tụi mình cũng đang trên con đường suy nghĩ xem engaged interface cho việc làm discovery như thế nào:
Tụi mình đang build một engaged interface cho product discovery. Sản phẩm tên là CLRA và hiện tại đang Closed Alpha.