#62 - Discovery dã chiến
"Chúng ta chỉ có một vài tuần nữa để ship feature này"
"Chúng ta chỉ có một vài tuần nữa để ship feature này"
CEO nói trong một buổi họp với team product và engineering. Không khí trong phòng chùn xuống, cảm giác như có gì đó đè lên hai lá phổi, và người PM ấy không kịp tự ngăn mình buông tiếng thở dài.
Tạm biệt bình yên, khóc xong rồi thì thôi cất gọn poster núi và biển vào góc, mình tạm thời không nhìn nhau nhé ....
Đó là khung cảnh mình mường tượng khi nói chuyện với Sarah - Product Manager tại một công ty B2B SaaS. Công ty của bạn quyết định đặt cược vào một cuộc tái định vị để đi theo AI. Một thứ cần phải làm là ship tính năng mới và đưa được AI vào workflow của người dùng. Sarah kể lại với một tông giọng dõng dạc và tự hào, vì bạn đã dẫn dắt được team để hoàn thành deadline đó, không phải bằng cách mù quáng build, mà bằng cách lồng ghép đan xen discovery vào trong quá trình build.
Trong quá trình làm tool mới tên là CLRA (đọc là "clearer"), tụi mình đã nói chuyện với nhiều bạn làm sản phẩm lâu năm trong nghề, nhằm mở rộng góc nhìn cũng như có thêm thấu cảm về cách mọi người làm discovery trong thực tế. Trong bài viết này, mình muốn chia sẻ một câu chuyện thú vị về discovery dã chiến (on the field) giống như vậy.
CLRA - product discovery tool
AI can ship your weekly report - it cannot do your discovery for you. We give you the structure to stay engaged with your users, your evidence, and your problem space until the right answer emerges.
From Sarah with love.
Sarah (--fake name--) là Product Manager tại một công ty B2B SaaS đang bước vào một cuộc tái định vị gần như sống còn. Ban lãnh đạo tin rằng AI sẽ là theme màu chủ đạo trong chương tiếp theo của công ty, và họ muốn một tính năng AI mới trở thành trung tâm cho câu chuyện đó. Deadline thì sát tới mức không có những xa xỉ thường thấy của product discovery: không có hàng tháng để interview users, không có thời gian vẽ đầy đủ job map, càng không có chuyện chờ đến mức bão hòa thông tin rồi mới quyết định build cái gì.
Nhưng điều thú vị là Sarah không phản ứng với áp lực bằng cách bỏ qua discovery. Bạn chỉ làm discovery theo một cách khác.
Thay vì bắt đầu bằng user research, Sarah bắt đầu bằng việc sử dụng AI để làm competitor research để xem đối thủ có những tính năng gì, và dựa vào trực giác của mình để viết viết ra chiếc PRD đầu tiên trong một tuần. Gần như không dựa vào interview nào cả. Nó được dựng lên từ common sense mà bạn đã tích lũy nhiều năm trong domain đó: chỗ nào trong workflow người dùng đang có vấn đề, chỗ nào người dùng đang phải workaround, và AI sẽ chen chân vào chỗ nào.
Nhưng Sarah cũng không ngây thơ tới mức nghĩ rằng mình “biết hết”. Bạn chủ động tách problem space thành hai lớp rất rõ. Đầu tiên là biết được vấn đề này đáng giải quyết hay không. Từ leadership cũng như nghiên cứu thị trường, bạn biết rằng tính năng này chắc chắn cần tồn tại nếu sản phẩm muốn đi theo hướng AI. Bạn không tiêu tốn băng thông discovery cho việc hiểu được bức tranh lớn cũng như vấn đề này nằm trong workflow ra sao nữa. Những thứ đó đã biết rõ rồi.
Phần thật sự mới, thật sự bất định - việc người dùng sẽ nhìn nhận tính năng AI như thế nào - như một trợ lý ảo, hay một công cụ, hay mối đe dọa, và họ có những tiêu chí nào khi đánh giá đầu ra của AI - mới trở thành trọng tâm khám phá. Discovery không biến mất. Discovery bị nén lại và được tập trung cực kỳ chính xác vào khu vực có nhiều sự bất định rủi ro nhất, nhưng discover không bao giờ được giao hoàn toàn cho AI làm cả.
Minh Thanh To
Tới tuần thứ hai, Sarah đã vibe-code ra được một chiếc prototype đầu tiên chạy được. Khi team của Sarah bắt đầu nói chuyện với khách hàng, không phải đi từ bản vẽ trắng mà đã có một giả thuyết rất cụ thể. Những cuộc trò chuyện lúc này không còn là “hãy kể tôi nghe về vấn đề của bạn” nữa, mà là va chạm trực tiếp giữa prototype của Sarah và cách người dùng nhìn nhận. Thứ Sarah đem ra bàn luận không chỉ là PRD nữa mà chủ yếu là prototype.
Cách Sarah tổ chức dòng thông tin cũng phản ánh mindset này. Bạn không ưu tiên nguồn thông tin này "chuẩn" hơn nguồn thông tin khác. Thay vào đó, bạn ưu tiên những nguồn thông tin ở gần tầm tay trước, rồi sau đó mới đến chất lượng. Thí dụ, enterprise customers nào đang đòi tính năng này thì nói chuyện trước vì họ có động lực phản hồi ngay. Sau đó thì kéo internal team vào (vì họ có cùng JTBD với khách) để xem solution khớp vào ngữ cảnh của họ như thế nào. Rồi làm competitor research để hiểu được thị trường đang có những pattern nào đang trồi lên. Bạn dựng prototypes cực nhanh, không chỉ để validate solution, mà còn là một cách để khai phá xem problem cụ thể là gì.
Lúc đem prototype nói chuyện với internal team, bạn nhận ra rằng họ không hiểu ngay được output đầu ra của AI, trừ một số người có domain knowledge sâu. Ban đầu Sarah nghĩ rằng cần làm cả một sơ đồ khái niệm để map output AI map với từng khái niệm nào và diễn tả mối liên hệ của chúng với nhau, nhưng ràng buộc về mặt technical không cho phép, nên cuối cùng Sarah quyết định bản MVP sẽ chỉ đơn giản đánh tag các output AI theo một số chiều không gian nhất định. Đó là một khoảnh khắc discovery với internal users đã giúp Sarah tinh chỉnh lại hình thái của tính năng.
Minh Thanh To
Mỗi luồng thông tin mới được đưa vào một vòng lặp gần như liên tục. AI Agent giúp Sarah ghi lại các cuộc họp, trích xuất ra bằng chứng, highlight những gì đang mâu thuẫn với cách hiểu của mình hiện tại được ghi trong PRD, rồi đẩy ngược về cho Sarah review. Không có khoảnh khắc nào là “discovery phase kết thúc” và "deliver bắt đầu". Việc frame vấn đề, học được insights, ship bản mới, rồi reframe hình thái sản phẩm - tất cả diễn gần như đồng thời trong một vòng lặp cực ngắn.
Trông thì có vẻ nó rất thiếu "bài bản", nhưng thực chất nó hoàn toàn hợp lý trong ngữ cảnh nhu cầu business cấp bách và leadership ép deadline xuống. PM phải dùng chính trực giác của mình, kết hợp với discovery để nén vòng lặp càng ngày càng nhỏ lên để vừa khai phá vấn đề vừa cải tiến giải pháp.
Và có lẽ đó là điểm đáng suy nghĩ nhất trong câu chuyện này. Product Management thường được dạy theo những giai đoạn rõ ràng: discovery trước, delivery sau; problem space trước rồi solution space sau; do the right thing mới do the thing right. Trong thực tế, đặc biệt khi thời điểm thị trường chuyển dịch mạnh và với sự tác động của AI - thực tế nhiều khi không cho chúng ta điều kiện xa xỉ để đi theo cái "bài bản" đó.
Đôi khi, thứ cần thiết không phải là sự chắc cú trước khi hành động, mà là khả năng hành động trong khi vẫn liên tục cập nhật lại mô hình của chúng ta về thực tại người dùng, thị trường, vấn đề và giải pháp. Đây không phải “cứ move fast build đi không cần discovery”, mà là discovery được "nhúng" vào từng khoảnh khắc build hàng ngày.
Đó không phải con đường dành cho những người ít kỷ luật. Thậm chí, nó đòi hỏi nhiều kỷ luật hơn hẳn, vì rất dễ để chúng ta bỏ qua chuyện discovery mà chỉ cần build nhanh nhanh rồi launch cho xong chuyện. Cho dù áp lực phải build nhanh lớn tới mức nào đi nữa, PM vẫn cần discovery để thu hẹp không gian vấn đề đến phạm vi đủ nhỏ để chúng ta tập trung build.
Nếu Sarah hoàn toàn dùng trực giác của mình mà không chủ động nói chuyện với enterprise customers, internal teams và làm competitor research, thì chắc chắn tính năng đã không được shipped với mức độ tinh gọn tốt nhất trong thời hạn một vài tuần. Thậm chí, lúc ấy Sarah có khi còn không buồn quan sát cách người dùng sử dụng thông qua customer support, sales và product analytics. Trong thế giới song song đó, Sarah đã không tinh chỉnh trực giác của mình trước khi build, thì khả năng cao bạn cũng sẽ không tinh chỉnh trực giác của mình từ user feedback sau khi build.
Bạn cần làm discovery tốt hơn bao giờ hết
Mình chưa thấy business nói rằng chúng ta không được làm discovery. Trái lại, discovery đặc biệt quan trọng để quản trị rủi ro và làm ra sản phẩm phù hợp với nhu cầu từ business.
Trong thời đại AI, rất dễ để nghĩ rằng chúng ta có thể bớt tập trung vào discovery. Nhưng mình lại thấy rằng, bây giờ chính là lúc PMs phải upskill discovery hơn bao giờ hết, vì để nén discovery vào lại trong vòng lặp ngắn một cách hiệu quả, để biết rủi ro nào cần quản trị với user insights, để đánh giá được khi nào đủ độ tự tin để build, khó hơn nhiều so với lúc chúng ta có dư dả thời gian ngồi research, develop deliver rất nhiều.
Câu hỏi mình đặt ra khi nghĩ về discovery cho các bạn chưa phải senior:
Nếu bạn không đi theo mô hình discovery giống sách vở nói theo từng giai đoạn, vốn đã giả định rằng chúng ta có băng thông để làm như vậy, làm sao bạn có thể đi theo mô hình discovery dã chiến được?
Có lẽ, chúng ta cần phải chơi theo luật lệ, để hiểu nó đủ sâu, và để biết khi nào cần phải phá luật. Nói cách khác, chúng ta cần phải đầu tư để xây dựng chuyên môn tốt hơn nữa trong thời đại AI.
CLRA - Product Discovery Workspace
AI can ship your weekly report - it cannot do your discovery for you. We give you the structure to stay engaged with your users, your evidence, and your problem space until the right answer emerges.
