Khi Scout vào private beta cuối 2025, chúng tôi nhận được không ít lời hỏi theo kiểu: "Khi nào mở cho mọi người?" Câu trả lời ngắn là chúng tôi cố tình không vội. Không phải vì sản phẩm chưa sẵn sàng về mặt kỹ thuật, mà vì mở rộng sớm quá dễ làm hỏng những thứ quan trọng hơn số đăng ký.
Số đăng ký không phải mục tiêu giai đoạn đầu
Có một áp lực ngầm khi làm sản phẩm: càng nhiều người dùng thì trông càng có tín hiệu. Số đăng ký đẹp, tổng tài khoản tăng đều, nhìn có vẻ đang đi đúng hướng. Chúng tôi không phủ nhận điều đó quan trọng về lâu dài, nhưng ở giai đoạn đầu nó dễ trở thành một loại nhiễu nguy hiểm.
Nếu mở rộng sớm, chúng tôi sẽ có nhiều tài khoản hơn. Nhưng người dùng đến từ một bài đăng viral hay một đợt giới thiệu rộng thường có ngữ cảnh rất khác nhau: hàng khác, quy mô khác, cách vận hành khác. Phản hồi từ 500 người dùng khác ngữ cảnh lộn xộn hơn, khó tổng hợp hơn, và dễ kéo roadmap về những hướng không ai thực sự cần.
Điều chúng tôi cần là phản hồi sâu từ một nhóm nhỏ người dùng hiểu rõ bài toán, dùng công cụ trong quy trình thật, và sẵn sàng nói thẳng khi cái gì đó không đúng. Đó là thứ khó có được khi bạn mở cửa cho tất cả.
Vì sao người dùng đúng quan trọng hơn nhiều người dùng
Scout được xây dựng cho một bài toán cụ thể: người bán Việt nhập hàng từ 1688 bán trên TikTok Shop, Shopee, hoặc Lazada, cần lọc sản phẩm theo biên lãi thật chứ không phải nhập theo cảm tính. Người đó phải tự mình thấy nỗi đau này hàng tuần. Nếu không, phản hồi của họ không cùng ngôn ngữ với bài toán.
Ví dụ thực tế: trong những tháng đầu, chúng tôi nhận ra một tính năng trên giao diện Scout bị hiểu theo hai cách hoàn toàn khác nhau giữa người đang nhập hàng và người mới tìm hiểu thị trường. Nếu chúng tôi có hai đầu phản hồi lẫn lộn vào nhau mà không tách được, chúng tôi sẽ sửa nhầm. Nhóm hẹp cho phép chúng tôi biết chính xác ai đang nói gì.
Người dùng đúng cũng dùng sản phẩm thật, không phải thử một lần rồi thôi. Họ vào lại tuần sau, dùng trong một đợt tìm nguồn hàng thật, và khi có gì đó vướng thì họ nói. Đó là tín hiệu chất lượng hơn nhiều so với hàng trăm người đăng ký xong không bao giờ quay lại.
Giai đoạn hẹp giúp chúng tôi nhìn thấy vấn đề rõ hơn
Margin Engine v0.2 ra đầu 2026, tính giá vốn đầu vào từ tỷ giá và cước thật, rồi đối chiếu với giá bán dự kiến và phí sàn. Batch import ra tháng 3, cho phép kéo nhiều SKU vào cùng lúc thay vì nhập từng cái. Orders beta mở tháng 4 để quản lý đơn mua từ nhà cung cấp.
Mỗi tính năng trên nếu ra trước một lượng lớn người dùng không quen workflow sẽ tạo ra hàng trăm ticket hỗ trợ chồng lên nhau, đội nhỏ không xử lý hết, và không có thời gian nhìn ra pattern thật đằng sau câu hỏi. Trong nhóm hẹp, chúng tôi có thể ngồi xem người dùng dùng sản phẩm thật sự, theo dõi chỗ họ dừng lại, và sửa trước khi trở thành vấn đề có quy mô.
Có một vấn đề không nhỏ mà chúng tôi phát hiện được nhờ giai đoạn hẹp: thứ tự mà người dùng muốn nhìn thấy thông tin về một sản phẩm rất khác so với thứ tự chúng tôi ban đầu đặt ra. Người vận hành nhập hàng hỏi biên lãi trước tiên, sau đó mới hỏi nhu cầu. Chúng tôi đã đặt ngược. Sửa điều đó trên 20 người dùng mất một buổi. Sửa sau khi mở cho 2.000 người dùng sẽ là câu chuyện khác.
Rollout có chủ ý không phải là giữ bí mật
Điều này đáng phân biệt rõ: chúng tôi không giữ Scout trong bí mật để tạo cảm giác độc quyền, và cũng không giữ vì sợ cạnh tranh. Chúng tôi nói công khai về cái mình đang làm, tại sao, và cả những gì chưa hoạt động. Bài này là một phần của điều đó.
Rollout hẹp là quyết định vận hành: chúng tôi cần thời gian để sản phẩm đủ tin cậy trước khi nó gặp người dùng với bối cảnh và kỳ vọng đa dạng hơn. Mở rộng quá sớm với một sản phẩm còn nhiều góc cạnh thô không khác gì bảo người đến xem một căn nhà chưa trát tường. Nếu họ không hình dung được, họ ra về với ấn tượng sai và khó sửa.
Với người đang làm vận hành nhập hàng 1688, chúng tôi muốn lần đầu họ dùng Scout là một trải nghiệm đủ tốt để họ quay lại. Không phải một trải nghiệm đủ tệ để họ kết luận "tool này không làm được gì".
Tiêu chí để mở rộng
Chúng tôi không vạch một ngày cụ thể trên lịch và nói "hôm đó sẽ mở". Tiêu chí mà chúng tôi đặt ra có dạng hành vi, không phải ngày tháng.
Khi người dùng trong vòng hẹp dùng lại ít nhất ba lần trong một tháng mà không cần ai nhắc, tức là sản phẩm đang giải quyết được bài toán thật. Khi các vấn đề phát sinh trong một đợt dùng không còn là "tính năng cơ bản bị vỡ" mà là "muốn thêm cái này thêm cái kia", tức là nền móng đã đủ vững. Khi chúng tôi có thể onboard người mới mà không cần giải thích thủ công từng bước, tức là sản phẩm đủ rõ để tự đứng.
Chưa đủ cả ba thứ đó, mở rộng chỉ là đẩy thêm người vào một hệ thống chưa sẵn sàng đón họ.
Bài học từ giai đoạn beta
Chúng tôi học được nhiều hơn từ hai mươi người dùng dùng thật trong ba tháng so với những gì chúng tôi nghĩ sẽ học được nếu mở sớm cho vài trăm người.
Một số điều cụ thể. Người dùng đầu tiên của chúng tôi không gọi cái họ làm là "sourcing". Họ gọi là "tìm hàng" hoặc "tìm nguồn". Sự khác biệt không nhỏ vì nó ảnh hưởng đến ngôn ngữ của giao diện, của onboarding, của cả cách chúng tôi viết hướng dẫn. Nếu chúng tôi giữ từ "sourcing" trong sản phẩm vì đó là từ quen trong ngành, chúng tôi sẽ tạo ra một khoảng cách ngay từ đầu với người dùng mình đang phục vụ.
Một điều nữa: cách người dùng thật dùng tính năng filter khác xa với cách chúng tôi tưởng họ sẽ dùng. Họ không lọc từ trên xuống theo điểm số. Họ bắt đầu từ một danh mục ngành hàng quen thuộc, rồi thu hẹp dần. Chúng tôi điều chỉnh. Điều đó không thể phát hiện được từ data analytics đơn thuần, nó cần quan sát thật.
Tạm kết
Mở rộng chậm hơn kế hoạch ban đầu không phải dấu hiệu trục trặc. Với chúng tôi, đó là kết quả của việc đặt câu hỏi đúng trước: ai là người dùng mà phản hồi của họ thực sự có giá trị ở giai đoạn này, và cần bao nhiêu vòng lặp trước khi sản phẩm đủ tin để gặp người dùng rộng hơn. Câu trả lời dẫn đến một lộ trình hẹp có chủ ý, và chúng tôi không hối hận vì điều đó.