Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Assumption testing & prototype

Vì sao Assumption testing & prototype quan trọng

Khi đã có giải pháp trên cây, cám dỗ lớn nhất là xây luôn phiên bản đầy đủ. Nhưng mỗi giải pháp ẩn chứa hàng loạt giả định: khách có nhận ra tính năng không, có hiểu cách dùng không, có sẵn lòng đổi hành vi không, và cả về mặt kỹ thuật lẫn kinh doanh có khả thi không. Nếu một giả định sai, cả giải pháp sụp đổ, dù bạn đã đổ hàng tháng công sức xây.

Assumption testing là nghệ thuật tìm ra giả định nguy hiểm nhất rồi kiểm chứng nó bằng cách rẻ và nhanh nhất, thường là qua prototype, trước khi cam kết delivery. Cái giá của việc bỏ qua bước này rất đắt: bạn xây trọn vẹn một tính năng dựa trên giả định chưa kiểm, ra mắt, rồi phát hiện khách không hiểu hoặc không cần.

Ở Việt Nam, một lỗi phổ biến là coi prototype là bản đẹp gần hoàn thiện. Thực ra prototype tốt nhất thường thô, đôi khi chỉ là vài màn hình bấm được, thậm chí một trang landing giả. Mục tiêu không phải làm đẹp mà là thu về một câu trả lời rõ ràng cho một giả định cụ thể với chi phí nhỏ nhất.

Bức tranh lớn

Quy trình gồm bốn bước: liệt kê giả định, xếp hạng theo mức rủi ro, thiết kế thí nghiệm nhỏ nhất, và đọc kết quả để quyết định đi tiếp hay xoay hướng.

graph TD
A[Liet ke gia dinh cua giai phap] --> B[Xep hang theo rui ro]
B --> C[Chon gia dinh nguy hiem nhat]
C --> D[Thiet ke thi nghiem nho nhat]
D --> E[Chay va doc ket qua]
E --> F[Di tiep hoac xoay huong]

Bốn loại giả định cần soi: giá trị (khách có muốn không), khả dụng (khách có dùng được không), khả thi (kỹ thuật làm được không), và sống còn kinh doanh (có bền không). Rủi ro cao nhất thường nằm ở giả định giá trị, nơi nhiều team chủ quan bỏ qua.

Ví dụ chi tiết

Một ví điện tử ở Hà Nội muốn ra tính năng chia hoá đơn nhóm khi đi ăn.

Bước 1, liệt kê giả định. Team viết ra: khách sẽ chủ động chia bill qua app, người trong nhóm sẽ chịu tải app để nhận tiền, và luồng chia đủ đơn giản để dùng ngay tại bàn ăn.

Bước 2, xếp hạng rủi ro. Giả định nguy hiểm nhất là "người trong nhóm sẽ tải app chỉ để nhận vài chục nghìn". Nếu sai, cả tính năng vô nghĩa.

Bước 3, thiết kế thí nghiệm nhỏ. Thay vì xây, team làm một prototype Figma bấm được và một luồng nhận tiền giả không cần tải app, chỉ cần link. Họ mời 12 người thử tại một quán ăn thật.

Bước 4, đọc kết quả. 10 trong 12 người từ chối tải app, nhưng tất cả đều dùng link nhận tiền không cần cài đặt. Giả định gốc sai, nhưng phát hiện một hướng đúng.

Bước 5, xoay hướng. Team bỏ yêu cầu tải app cho người nhận, chuyển sang luồng nhận qua link. Nhờ prototype rẻ, họ tránh xây một tính năng chết và tìm ra hướng khả thi chỉ trong một tuần.

Lộ trình từng bước để làm chủ

graph TD
A[Viet ra moi gia dinh] --> B[Danh gia rui ro va do chac chan]
B --> C[Chon gia dinh rui ro cao chua chac]
C --> D[Chon phuong phap test re nhat]
D --> E[Chay tren nguoi dung that]
E --> F[Quyet dinh dua tren du lieu]

Nguyên tắc: luôn test giả định rủi ro cao nhưng độ chắc chắn thấp trước. Đừng test thứ bạn đã biết chắc. Chọn phương pháp rẻ nhất đủ để trả lời câu hỏi, prototype thô hơn bản hoàn chỉnh gần như luôn tốt hơn ở giai đoạn này.

Thói quen & kỷ luật

NhịpThói quen
Trước khi xâyLiệt kê giả định của mọi giải pháp
Hàng tuầnChạy ít nhất một thí nghiệm nhỏ
Sau mỗi testGhi rõ giả định đúng hay sai
Mỗi sprintRà lại giả định nào còn chưa kiểm
Working mindset: "Trước khi xây, tôi hỏi giả định nào nếu sai sẽ giết chết giải pháp này."

Cần luyện tập gì (drills)

Drill 1: Lấy một giải pháp trong backlog, liệt kê ít nhất tám giả định thuộc bốn loại giá trị, khả dụng, khả thi, kinh doanh.

Drill 2: Với một giả định, thiết kế ba cách test khác nhau, xếp từ rẻ nhanh nhất tới đắt chậm nhất, rồi chọn cái rẻ nhất đủ dùng.

Drill 3: Dựng một prototype thô trong một giờ, chỉ đủ để kiểm một giả định, không tô vẽ thêm.

Checklist hành động tuần này

  • [ ] Chọn một giải pháp và liệt kê toàn bộ giả định
  • [ ] Xếp hạng giả định theo rủi ro và độ chắc chắn
  • [ ] Chọn giả định nguy hiểm nhất để kiểm trước
  • [ ] Dựng một prototype thô đủ để test giả định đó
  • [ ] Chạy thử với ít nhất năm người dùng thật

Chỉ số & North Star

North Star: số giả định rủi ro cao được kiểm chứng trước khi bỏ công sức xây.

Chỉ sốTốtXấu
Chi phí mỗi thí nghiệmRẻ, dưới vài ngàyXây gần đủ mới test
Giả định test trước khi xâyCái nguy hiểm nhấtCái dễ nhất, an toàn
Kết quả dẫn tới quyết địnhRõ đi hay xoayMơ hồ, không kết luận

Dấu hiệu bạn đã thành thạo

Bạn phản xạ hỏi "giả định nào giết giải pháp này" trước mọi lần xây. Bạn dựng được prototype thô trong vài giờ và không ngại nó xấu. Bạn thoải mái bỏ hoặc xoay hướng một giải pháp khi dữ liệu nói vậy, thay vì bám vào nó vì đã lỡ đầu tư.

Cạm bẫy thường gặp

Cạm bẫyThay bằng
Xây đầy đủ rồi mới kiểmPrototype thô test trước
Test giả định dễ, an toànTest giả định nguy hiểm nhất
Prototype phải đẹpĐủ thô để trả lời câu hỏi
Bám giải pháp khi số liệu xấuSẵn sàng xoay hướng

Chốt lại

  • Mỗi giải pháp ẩn nhiều giả định, một cái sai có thể giết cả giải pháp.
  • Kiểm giả định rủi ro cao nhất bằng cách rẻ nhất trước khi xây.
  • Prototype thô thường tốt hơn bản đẹp ở giai đoạn kiểm giả định.
  • Dữ liệu quyết định đi tiếp hay xoay hướng, không phải cái tôi.
Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi