Khi mọi thứ đều có vẻ hợp lý
Founder hiếm khi dừng một sản phẩm vì nó tệ rõ ràng. Vấn đề khó hơn thường nằm ở vùng xám: khách hàng có vẻ quan tâm, đội ngũ vẫn còn ý tưởng, roadmap còn nhiều việc hay, nhưng tiền và thời gian thì đang chảy đi từng tuần.
Năm 2026, vùng xám này còn dày hơn. AI code giúp làm prototype nhanh hơn. No-code làm landing page, form, chatbot, luồng tự động trông khá thuyết phục. Một đội hai người có thể dựng demo trong vài ngày. Vì vậy cảm giác “mình gần tới rồi” xuất hiện thường xuyên hơn, kể cả khi sản phẩm chưa chứng minh được nhu cầu thật.
Một scorecard không thay founder ra quyết định. Nó chỉ ép cả đội nhìn cùng một mặt bàn. Ít tranh luận bằng cảm giác hơn, nhiều câu hỏi cụ thể hơn.
Nếu bạn đang ở giai đoạn rất sớm, nên đọc thêm bài 5 câu hỏi trước khi xây MVP. Bài này đi tiếp một bước: khi đã có bản thử, đã nói chuyện với khách hàng, đã có vài tín hiệu, bạn nên làm gì tiếp?
Scorecard không phải bảng chấm điểm cho đẹp
Một scorecard tốt có hai đặc điểm.
Nó đủ ngắn để dùng trong một cuộc họp 60-90 phút. Nếu cần cả ngày để điền, đội nhỏ sẽ bỏ qua. Nó cũng phải đủ thẳng để lộ ra chỗ yếu. Không phải ô nào cũng cần số chính xác, nhưng mỗi ô phải buộc bạn kể lại bằng chứng đang có.
Đừng bắt đầu bằng câu “chúng ta có nên tiếp tục không?”. Câu đó quá rộng. Hãy tách ra thành vài nhóm câu hỏi:
- Khách hàng có tự mô tả vấn đề bằng lời của họ không?
- Có ai đã làm việc gì tốn công để thử sản phẩm chưa?
- Phạm vi hiện tại có đang phình ra vì mình né quyết định khó không?
- Đội ngũ có học được điều mới sau mỗi vòng thử nghiệm không?
Một chi tiết nhỏ nhưng đáng làm: hãy ghi lại nguồn tín hiệu ngay trong scorecard. Ví dụ: “5 cuộc gọi với chủ shop trong tháng 8”, “2 khách dùng thử bản demo khi có người hướng dẫn”, “1 khách hỏi báo giá nhưng chưa chốt vì thiếu tích hợp kế toán”. Những dòng như vậy không phải bằng chứng hoàn hảo, nhưng tốt hơn nhiều so với “thị trường có vẻ thích”.
Bốn vùng cần chấm trước khi xây tiếp
Bạn có thể dùng thang 0-2 cho từng vùng. 0 là yếu hoặc chưa có bằng chứng. 1 là có tín hiệu nhưng còn mỏng. 2 là đủ rõ để ra hành động tiếp theo. Tổng điểm không quan trọng bằng cuộc trò chuyện phía sau từng điểm.
1. Vấn đề có đủ đau không?
Nhiều sản phẩm chết vì giải quyết một bất tiện nhẹ. Khách hàng gật đầu trong buổi phỏng vấn, nhưng khi phải đổi thói quen thì họ biến mất.
Dấu hiệu tốt là khách hàng đã có cách xử lý tạm, dù xấu. Họ dùng Google Sheet rối rắm. Họ nhắn tin tay cho từng đơn. Họ thuê người nhập liệu. Họ ghét việc đó, nhưng vẫn làm vì bỏ thì ảnh hưởng tiền, thời gian hoặc uy tín.
Nếu vấn đề chưa đủ đau, đừng vội xây thêm tính năng. Hãy quay lại phần xác định vấn đề trong bài xác định đúng vấn đề sản phẩm.
2. Người dùng có hành động thật không?
Lời khen rẻ. Lịch hẹn, dữ liệu thật, tiền cọc, thời gian onboarding mới đắt hơn.
Ở giai đoạn sớm, không nhất thiết phải có doanh thu ngay. Nhưng phải có một hành động cho thấy người dùng đang đặt cược chút gì đó. Họ gửi file thật để bạn xử lý. Họ mời thêm đồng nghiệp vào buổi demo. Họ đồng ý thử trong quy trình đang chạy, dù chỉ là một nhánh nhỏ.
Nếu mọi tín hiệu chỉ dừng ở “ý tưởng hay đó”, điểm vùng này nên thấp.
3. Phạm vi có còn kiểm soát được không?
Khi sản phẩm chưa chạy, founder thường thêm tính năng để tăng cơ hội thuyết phục. Thực tế lại ngược. Phạm vi rộng làm đội chậm hơn, khó học hơn, khó biết vì sao khách hàng chưa mua.
Một MVP gọn không phải bản thiếu thốn. Nó là bản có chủ đích. Chỉ giữ những phần cần để kiểm tra giả định chính. Nếu đang phân vân, bài MVP nhỏ nhưng có ích là điểm quay lại tốt.
Hãy hỏi: nếu bỏ 30% phạm vi hiện tại, ta có còn kiểm tra được giả định quan trọng nhất không? Nếu câu trả lời là có, phạm vi đang thừa.
4. Đội có học được sau mỗi vòng thử không?
Một đội đang đi đúng hướng thường có câu trả lời sắc hơn sau mỗi vòng thử. Không nhất thiết là tin vui. Có khi kết quả tốt nhất của tuần là biết một nhóm khách hàng không phù hợp.
Ngược lại, nếu sau ba vòng demo mà câu chuyện vẫn y như cũ, đội có thể đang diễn lại bài bán hàng thay vì học. Lúc này cần thay đổi cách thử nghiệm: đổi nhóm khách, đổi lời hứa, giảm phạm vi hoặc đưa sản phẩm vào một tình huống thật hơn.
Cách đọc kết quả mà không tự lừa mình
Sau khi chấm, đừng vội cộng điểm rồi ra quyết định máy móc. Hãy nhìn mẫu hình.
Nếu vấn đề đau và hành động thật đều thấp, nên dừng hoặc quay lại nghiên cứu. Xây thêm lúc này dễ chỉ làm demo đẹp hơn.
Nếu vấn đề đau nhưng hành động thật thấp, có thể lời hứa chưa đủ rõ, kênh bán chưa đúng hoặc rào cản dùng thử quá cao. Hành động tiếp theo nên là thử một đề nghị nhỏ hơn, không phải viết thêm code.
Nếu hành động thật có nhưng phạm vi mất kiểm soát, hãy cắt. Giữ lại luồng có khả năng tạo ra kết quả rõ nhất. Đây là lúc một buổi Product Consultant có thể giúp founder tách phần cần xây khỏi phần chỉ làm đội yên tâm.
Nếu cả bốn vùng đều khá ổn, bạn có lý do để xây tiếp. Nhưng vẫn nên đóng khung vòng tiếp theo trong 2-4 tuần, có mục tiêu học cụ thể. Đừng biến kết quả tốt thành vé mở rộng vô hạn.
Một mẫu họp 75 phút cho đội nhỏ
Đừng biến scorecard thành nghi thức nặng nề. Một buổi gọn là đủ.
- 10 phút: nhắc lại khách hàng mục tiêu và giả định chính.
- 20 phút: đọc bằng chứng mới, chỉ dùng dữ liệu, ghi chú khách hàng, lịch hẹn, hành vi dùng thử.
- 25 phút: chấm bốn vùng, cho phép bất đồng điểm nhưng phải nói lý do.
- 15 phút: chọn một quyết định, xây tiếp, sửa hướng, tạm dừng hoặc dừng.
- 5 phút: ghi hành động tuần tới và người chịu trách nhiệm.
Điểm quan trọng là không để cuộc họp kết thúc bằng câu “để xem thêm”. Nếu cần xem thêm, phải nói xem cái gì, từ ai, trước ngày nào.
Dừng lại cũng là một quyết định sản phẩm
Founder thường sợ dừng vì cảm giác mất công. Nhưng chi phí chìm không trả lại bằng cách xây tiếp. Sản phẩm chỉ nên nhận thêm thời gian khi nó giúp đội học được điều đáng giá hoặc tiến gần hơn tới nhu cầu thật.
Có lúc quyết định đúng là thu nhỏ. Có lúc là đổi nhóm khách hàng. Có lúc là giữ ý tưởng nhưng bỏ cách triển khai hiện tại. Và có lúc nên dừng thẳng, để dành năng lượng cho một bài toán rõ hơn.
Một scorecard tốt không làm quyết định bớt khó. Nó làm quyết định bớt mù.
Nếu bạn đang đứng giữa “xây tiếp hay dừng”, hãy gom bằng chứng lại trước khi mở sprint mới. Một buổi nhìn thẳng có thể tiết kiệm cho đội vài tuần làm việc trong sương mù.