Product Discovery (JTBD, Mom Test)

Discovery là gì — và vì sao "hỏi khách hàng muốn gì" không phải discovery

Discovery là công việc tìm ra nên xây cái gì và vì sao, trước khi bỏ tiền xây. Nó song song với việc xây dựng, không phải một giai đoạn đứng trước.

Hiểu lầm phổ biến nhất: discovery không phải là đi hỏi khách hàng muốn gì rồi làm theo. Khách hàng mô tả rất giỏi vấn đề họ đang gặp, và rất kém trong việc thiết kế giải pháp — đó không phải việc của họ.

Khi ai đó nói "tôi cần một nút xuất Excel", công việc của bạn là hỏi tiếp tới khi hiểu họ định làm gì với file đó. Rất thường xuyên, thứ họ cần là một báo cáo tự gửi hằng tuần, và nút xuất Excel chỉ là giải pháp duy nhất họ hình dung ra được.

Bốn loại rủi ro mà discovery tồn tại để giảm:

Đội thường chỉ kiểm rủi ro khả thi, vì đó là rủi ro duy nhất có người trong phòng thạo. Rủi ro giá trị bị bỏ qua nhiều nhất và là rủi ro đắt nhất.

Vòng lặp discovery — bốn bước, chạy liên tục

Bước 2 là bước tạo ra khác biệt lớn nhất và tốn ít thời gian nhất. Cách làm: viết ra từng câu bắt đầu bằng "Chúng ta đang tin rằng…". Rồi với mỗi câu hỏi hai điều — nếu sai thì thiệt hại bao nhiêu, và hiện có bao nhiêu bằng chứng. Giả định thiệt hại cao mà bằng chứng thấp là thứ phải kiểm trước.

Phần lớn đội bỏ qua bước này và kiểm những thứ dễ kiểm thay vì những thứ nguy hiểm nhất.

Chọn cách kiểm — rẻ nhất trước, đừng nhảy sang xây thử

Cách "làm thủ công phía sau" bị đánh giá thấp nhất. Người dùng thấy một tính năng hoạt động; thực tế phía sau có người làm tay. Nó kiểm được nhu cầu thật với chi phí bằng một phần nhỏ so với xây thật — và nếu không ai dùng, bạn vừa tiết kiệm được vài tháng.

Tình huống thực tế — yêu cầu "cần xuất Excel"

Yêu cầu ban đầu: ba khách hàng doanh nghiệp đều xin nút xuất Excel cho báo cáo. Kinh doanh thúc ép. Có vẻ rõ ràng và dễ làm.

• Đóng khung: ai xin? Kế toán trưởng ở ba công ty. Họ cần gì? Chưa biết.
• Phơi bày giả định: (1) họ cần dữ liệu thô — bằng chứng thấp; (2) họ sẽ tự phân tích trong Excel — bằng chứng thấp; (3) xuất file giải quyết xong vấn đề — bằng chứng thấp, thiệt hại cao nếu sai.
• Kiểm rẻ nhất: gọi 30 phút cho từng người. Hỏi: "Lần gần nhất anh/chị cần dữ liệu này là khi nào, và sau khi có file thì làm gì tiếp?"
• Phát hiện: cả ba đều dán dữ liệu vào cùng một mẫu báo cáo, tính vài con số giống hệt nhau, rồi gửi email cho giám đốc vào thứ Hai hằng tuần. Mất khoảng 90 phút mỗi tuần mỗi người.
• Quyết định: không làm nút xuất Excel. Làm báo cáo tự gửi email thứ Hai với đúng những con số đó. Ít việc hơn, và giải quyết vấn đề thật.

Điều đáng chú ý: nếu làm đúng yêu cầu ban đầu, đội vẫn "giao hàng đúng hẹn", khách vẫn mất 90 phút mỗi tuần, và không ai biết đã bỏ lỡ điều gì. Đó là lý do discovery tồn tại — nó ngăn việc thành công trong việc làm sai thứ.

Discovery chạy song song với xây dựng

Discovery không phải giai đoạn trước dự án. Đội hiệu quả chạy hai luồng song song: luồng xây những thứ đã đủ chắc chắn, và luồng tìm hiểu những thứ sắp tới.

Quy tắc thực tế: tới lúc một việc được đưa vào sprint, những giả định rủi ro cao nhất của nó phải đã được kiểm. Nếu đội thường xuyên bắt đầu làm rồi mới phát hiện hiểu sai vấn đề, nghĩa là luồng discovery đang chạy chậm hơn luồng xây dựng.

Ai làm: bộ ba PO + designer + engineer cùng tham gia. Nếu chỉ PO đi phỏng vấn rồi về kể lại, đội mất phần lớn sắc thái — và engineer mất cơ hội nói "cái này có cách làm rẻ hơn nhiều".

Hiccups thường gặp và cách xử lý

Vì sao vai trò của bạn cần cái này

Definition of done

• Vấn đề được viết thành một đoạn: ai, gặp gì, thành công trông ra sao.
• Giả định được liệt kê đánh số và xếp theo thiệt hại × bằng chứng.
• Giả định rủi ro cao nhất đã được kiểm bằng cách rẻ nhất có thể.
• Trước mỗi lần kiểm, đã ghi rõ kết quả nào sẽ khiến đội đổi hướng.
• Có bộ ba PO + designer + engineer tham gia, không chỉ một người.
• Việc vào sprint chỉ khi giả định rủi ro cao của nó đã được kiểm.