Product Management
Đăng nhập
ESC

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

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

Bài 62 — Problem brief và tiêu chí dừng, viết trước khi xây

Đã đọc 0/6 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Vì sao phải viết trước

Một MVP chạy xong luôn cho ra số liệu. Câu hỏi là ai đọc số liệu đó và theo tiêu chuẩn nào. Nếu tiêu chuẩn được đặt sau khi có số, gần như chắc chắn nó sẽ được đặt sao cho kết quả trông ổn: 4% chuyển đổi là "khá tốt cho giai đoạn đầu", 20 khách trả tiền là "tín hiệu tích cực". Không ai nói dối; chỉ là đội đã bỏ công sức và muốn công sức đó có ý nghĩa.

Problem brief là một trang viết trước khi xây, chốt lại: ta đang giải vấn đề gì, cho ai, ta tin điều gì, MVP này hỏi câu gì, và con số nào khiến ta tiếp tục, con số nào khiến ta dừng. Nó khác danh sách kiểm tra trước khi xây ở Bài 54: danh sách đó hỏi "đã sẵn sàng chưa", còn brief là cam kết về cách đọc kết quả. Nó cũng là đầu vào cho Bài 56: muốn dừng một MVP đúng lúc, phải có tiêu chí dừng từ trước.

Cấu trúc một problem brief

MụcCâu hỏi phải trả lờiLỗi hay gặp
Vấn đềAi gặp chuyện gì, bao lâu một lần, đang xử lý thế nào?Viết giải pháp thay cho vấn đề
Bằng chứngTa biết điều này từ đâu? Bao nhiêu cuộc phỏng vấn, dữ liệu gì?"Ai cũng biết", "thị trường lớn"
Giả định rủi ro nhấtNếu điều gì sai thì cả ý tưởng sụp?Liệt kê 15 giả định ngang hàng
Câu hỏi của MVPMVP này trả lời đúng một câu nào?Muốn một MVP trả lời mọi thứ
Loại MVPFake door, concierge, pre-sale, prototype...?Mặc định "làm app"
Tiêu chí thành côngCon số nào, trong bao lâu, trên mẫu nào?"Người dùng thích"
Tiêu chí dừngCon số nào thì ta dừng hoặc đổi hướng?Bỏ trống
Giới hạnBao nhiêu tuần, bao nhiêu tiền, bao nhiêu người?Không có hạn chót
Danh sách "không"Những gì cố ý không làm trong lần này?Bỏ qua, rồi phạm vi phình ra
Mẫu đầy đủ có tại Problem brief template. Đừng điền cho đủ ô; mỗi ô chỉ cần một đến ba câu, và cả brief nên đọc xong trong năm phút.

Viết tiêu chí cho đúng

Một tiêu chí tốt có bốn thành phần: con số, mẫu số, thời gian, và người quyết. Thiếu một thành phần là có kẽ hở để diễn giải lại.

Tiêu chí mơ hồTiêu chí dùng được
"Nhiều người quan tâm"≥ 8% khách truy cập trang đích bấm "Đăng ký dùng thử", trên tối thiểu 600 lượt truy cập, trong 3 tuần
"Khách hài lòng"≥ 6/10 khách dùng thử quay lại dùng lần hai trong 14 ngày
"Có người chịu trả tiền"≥ 5 khách chuyển khoản đặt trước, giá 300.000đ, trong 4 tuần
"Xem kết quả rồi tính"Dưới 3% sau 600 lượt: dừng. Từ 3% đến 8%: phỏng vấn 5 người rồi chạy lại một lần. Trên 8%: làm bản tiếp theo
Dòng cuối minh họa điểm quan trọng nhất: chia kết quả thành ba vùng chứ không phải hai. Vùng giữa là nơi hầu hết MVP rơi vào, và nếu không quy định trước, vùng giữa sẽ luôn được đọc thành "tiếp tục". Quy định trước rằng vùng giữa chỉ được chạy lại một lần, với một thay đổi cụ thể.

Ba nguyên tắc khi đặt ngưỡng:

  • Đặt ngưỡng từ kinh tế, không từ cảm giác. Nếu mô hình kinh doanh cần 5% chuyển đổi để có lãi, ngưỡng thành công không thể là 2%.
  • Đặt mẫu số tối thiểu. 3 trên 5 người không phải 60%; đó là 3 người.
  • Người quyết phải được ghi tên. Một người, không phải "cả đội".

Ví dụ giả định: phần mềm sổ sách cho nhà thuốc

Ví dụ dưới đây là giả định, dùng để minh họa.

Một nhóm ở TP.HCM muốn làm phần mềm quản lý hạn dùng thuốc cho nhà thuốc nhỏ lẻ. Brief của họ:

MụcNội dung
Vấn đềNhà thuốc 1-2 người hủy thuốc hết hạn vài triệu đồng mỗi quý vì theo dõi bằng sổ tay
Bằng chứng14 cuộc phỏng vấn chủ nhà thuốc ở 3 quận; 10 người kể tự kiểm kho bằng tay mỗi tháng
Giả định rủi ro nhấtChủ nhà thuốc chịu nhập lô và hạn dùng khi nhận hàng, mỗi lần nhập
Câu hỏi của MVPSau 4 tuần, họ có còn nhập đều không?
Loại MVPConcierge: nhóm cung cấp mẫu bảng tính và gọi nhắc; chưa viết phần mềm
Thành công≥ 6/10 nhà thuốc vẫn nhập ≥ 80% lô hàng ở tuần thứ 4
Dừng≥ 7/10 nhà thuốc bỏ nhập trước tuần thứ 3
Vùng giữaPhỏng vấn lại, thử nhập bằng chụp ảnh hóa đơn, chạy lại 4 tuần một lần duy nhất
Giới hạn6 tuần, 2 người, không quá 15 triệu đồng
Không làmKhông làm app, không kết nối máy bán hàng, không làm báo cáo doanh thu
Người quyếtTrưởng nhóm sản phẩm
Kết quả tuần 4: 4/10 nhà thuốc còn nhập đều. Rơi vào vùng giữa. Vì đã viết trước, nhóm không tranh luận "4 là tốt hay xấu" mà làm ngay việc đã cam kết: phỏng vấn lại và thử nhập bằng ảnh hóa đơn. Lần chạy thứ hai đạt 7/10. Họ có lý do thật để viết phần mềm, và biết rõ tính năng đầu tiên phải là nhập bằng ảnh.

Ký trước, đọc sau

Một thói quen nhỏ khiến brief có hiệu lực: trước khi bắt đầu, gửi brief cho người tài trợ hoặc quản lý và xin họ đồng ý với tiêu chí dừng, không chỉ với kế hoạch. Khi kết quả về, đọc to tiêu chí trước, rồi mới mở số liệu. Cách làm đơn giản này giảm đáng kể việc dời cột gôn.

Làm ngay

  • Mở Problem brief template và viết brief cho MVP bạn đang làm hoặc sắp làm, tối đa một trang.
  • Viết tiêu chí theo ba vùng: thành công, vùng giữa (chạy lại một lần với thay đổi gì), dừng.
  • Kiểm tra từng tiêu chí có đủ con số, mẫu số, thời gian, người quyết.
  • Gửi brief cho một người ngoài đội và hỏi: "Với con số nào thì bạn nghĩ ta nên dừng?" Nếu câu trả lời khác của bạn, thống nhất trước khi xây.
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