Biên tập viên: Trong ngành công nghiệp mã hóa, cuộc thảo luận về "có nên xây dựng cơ sở hạ tầng hay không" và "độ phức tạp kỹ thuật có phải là rào cản cạnh tranh" chưa bao giờ ngừng lại. Nhưng bài viết này cung cấp một mẫu ngược lại từ một nhà sáng lập trực tuyến: từ việc liên tục đặt cược vào hạ tầng (infra) thất bại, đến chuyển hướng sang sản phẩm cấp người dùng (consumer-grade) mà mọi người thực sự sẵn sàng sử dụng và sẵn sàng trả phí, tác giả dùng trải nghiệm cá nhân để phân tích lại độ khó thực sự của việc "làm sản phẩm" trong ngành công nghiệp mã hóa.
So với độ phức tạp kỹ thuật và tầm nhìn lớn, bài viết tập trung hơn vào người dùng, phân phối và chi tiết thực thi. Trong lĩnh vực mã hóa cấp người dùng, giá trị không phải được "chứng minh", mà là được "dùng ra".
Dưới đây là nguyên văn:
Là một nhà sáng lập khởi nghiệp lần đầu, tôi đã dành nhiều năm để đầu tư vào ba giao thức cơ sở hạ tầng, nhưng cuối cùng tất cả đều thất bại. Đến năm 2025, tôi bắt đầu chuyển sang xây dựng một sản phẩm cấp người dùng thực sự có người muốn sử dụng. Nội dung này chia sẻ những kinh nghiệm tôi đúc kết được sau khi "vấp ngã" trong tăng trưởng người dùng và gọi vốn.
Tôi bước vào ngành này khoảng 4 năm.
Năm 2023, tôi bắt đầu khởi nghiệp trong hệ sinh thái EVM, khi đó "Abstract Account" (Tài khoản trừu tượng) là khái niệm nóng nhất. Hầu như tất cả mọi người đều đang phát triển SDK xung quanh ví tài khoản trừu tượng. Đồng thời, hệ sinh thái Rollup nóng lên nhanh chóng. Optimism, Arbitrum, và các dự án RaaS khác nhau chiếm lĩnh tầm nhìn chủ đạo.
Là một người yêu thích toán học, tôi bị ZK thu hút sâu sắc, cho rằng nó sẽ thay đổi thế giới (bây giờ tôi vẫn tin rằng cuối cùng nó sẽ như vậy).
Một sai lầm cốt lõi tôi mắc phải lúc đó là: đánh đồng "Độ phức tạp" với "Độ tin cậy".
Khi các nhà đầu tư mạo hiểm (VC) hỏi tôi về các trường hợp ứng dụng, tôi sẽ rất tự tin liệt kê các hướng như zkML, zk identity, zk voting — mà trên thực tế, cho đến tận hôm nay, những thứ này hầu như không được sử dụng thực sự. Tôi đã nhầm lẫn công nghệ trông có vẻ hay ho thành đây là một sản phẩm hữu ích.
Theo thời gian, tôi thậm chí bắt đầu tin rằng: ý tưởng càng phức tạp, thì xác suất khởi nghiệp thành công càng cao.
Nhiều nhà đầu tư cũng nói với tôi, trong ngành công nghiệp mã hóa, chỉ có làm cơ sở hạ tầng mới có cơ hội thành công. Mãi đến gần hai năm, trải qua hơn 500 lần bị từ chối, tôi mới nhận ra: con đường này không phù hợp với tôi.
Vì vậy, tôi đã bước vào hệ sinh thái Solana.
Đối với tôi, đây là một thế giới hoàn toàn mới. Những người ở đây quan tâm đến các trường hợp sử dụng thực tế. Ngay cả là meme, nhưng doanh thu rất quan trọng. Tốc độ rất quan trọng. Phân phối rất quan trọng. (Cũng đặc biệt cảm ơn @superteamin đã giúp đỡ trong quá trình.)
Cho đến nay, chúng tôi đã ứng dụng cấp người dùng trong hệ sinh thái này được gần 7 tháng. Ở giai đoạn thử nghiệm kín, chúng tôi đã xử lý hơn 12 triệu đô la khối lượng giao dịch. Dưới đây là một số kinh nghiệm tôi tổng kết được:
1. Xây dựng cho những người dùng trẻ tuổi sẵn sàng thử nghiệm những điều mới
Hãy cố gắng thiết kế sản phẩm cho một nhóm đối tượng vốn dĩ sẵn sàng chấp nhận sản phẩm mới hơn.
Trong các sản phẩm mã hóa cấp người dùng, điều này thường có nghĩa là "trenchers" hoặc những người dùng trẻ tuổi hơn, nhiều người tập trung trong khoảng 13–21 tuổi.
Năm 2024, một nghiên cứu của Hiệp hội Công nghệ Tiêu dùng Mỹ (CTA) nhắm vào Thế hệ Z (11–26 tuổi) cho thấy: 86% Thế hệ Z cho rằng công nghệ là một phần không thể thiếu trong cuộc sống, tỷ lệ này cao hơn bất kỳ nhóm tuổi lớn hơn nào. Họ áp dụng công nghệ mới sớm hơn, trung bình mỗi gia đình sở hữu 13 thiết bị, mỗi ngày sử dụng khoảng 6 thiết bị trong số đó, với thời gian sử dụng gần 12 giờ.
Thế hệ Z cũng có nhiều khả năng sở hữu cá nhân các sản phẩm công nghệ mới nổi hơn, chẳng hạn như ứng dụng mã hóa (ví dụ: 58% sở hữu máy chơi game, tỷ lệ này cao hơn đáng kể so với các nhóm tuổi lớn hơn). Họ có xu hướng chi tiêu mạnh hơn cho công nghệ mới, đăng ký nhiều dịch vụ hơn, thói quen thay đổi và tốc độ thử nghiệm cũng nhanh hơn rõ rệt so với Thế hệ Millennials, Thế hệ X hoặc Thế hệ baby boomer.
Họ sẵn sàng hơn trong việc thử nghiệm ứng dụng mới, thử nghiệm và thay đổi thói quen sử dụng nhanh chóng.
Ngược lại, người dùng lớn tuổi hơn (trong nhiều trường hợp là trên 25 tuổi) thường không muốn thay đổi quy trình hiện có, trừ khi động lực khuyến khích rất mạnh. Lưu ý bổ sung: nếu bạn làm sản phẩm hướng đến tổ chức, kết luận này có thể không áp dụng.
Nhiều nghiên cứu cũng cho thấy sự khác biệt hành vi rõ rệt: người dùng trẻ tuổi giao tiếp xã hội với nhiều người hơn mỗi ngày, điều này có nghĩa là họ có nhiều khả năng chia sẻ "sản phẩm thú vị mà họ phát hiện" cho bạn bè. Vào khoảng 20–21 tuổi, hoạt động nhắn tin xã hội thường đạt đỉnh điểm, điều này chủ yếu liên quan đến giai đoạn đại học hoặc đi học.
Xu hướng này mang lại một hàm ý rất trực tiếp: các sản phẩm được thiết kế cho người dùng trẻ tuổi hơn, vốn dĩ đã có tính lan truyền mạnh hơn.
2. Làm cho bản thân sản phẩm có thể chia sẻ được, để giảm chi phí marketing
Nếu bạn không có ngân sách quảng bá thị trường hoặc quảng cáo dồi dào, thì bản thân sản phẩm của bạn phải đảm nhận vai trò "kênh phân phối".
Nói cách khác, sản phẩm chính là marketing, sản phẩm chính là truyền bá.
Một sản phẩm có khả năng chia sẻ mạnh có thể giảm đáng kể chi phí marketing.
Điều này đặc biệt quan trọng trong ngành công nghiệp mã hóa, lý do là:
· Chi phí marketing KOL cao
· Mức độ tin cậy của người dùng nói chung thấp
· Phần lớn người dùng đều mong đợi phần thưởng hoặc cơ chế khuyến khích trước khi tham gia
Trong môi trường như vậy, việc phụ thuộc vào các phương thức marketing truyền thống thường hiệu quả hạn chế, trong khi sự lan truyền tự nhiên được thúc đẩy bởi chính sản phẩm lại bền vững hơn.
Nếu sản phẩm của bạn có thể cho người dùng một lý do để chia sẻ tự phát, dù là chia sẻ cho bạn bè, nhóm hay cộng đồng, bạn sẽ đạt được hiệu quả phân phối mà không tiêu tốn nhiều tiền bạc.
Điều này trong ngành mã hóa không dễ thực hiện, nhưng việc tối ưu hóa cho điều này ngay từ ngày đầu tiên, về lâu dài là rất đáng giá.
3. Phản hồi phản hồi của người dùng càng sớm càng tốt
Khi người dùng phản hồi rằng trải nghiệm sử dụng có vấn đề, hoặc gặp phải trải nghiệm tương tác tồi tệ, nhất định phải sửa chữa ngay lập tức, đặc biệt là những vấn đề sẽ chặn trực tiếp quy trình sử dụng.
Cách làm trước đây của tôi là để dành việc sửa lỗi đến cuối ngày mới xử lý. Nhưng có một lần, một người dùng nhắn tin riêng nói: "Ứng dụng của các bạn chưa có tính năng này, tôi dùng Y trước vậy."
Lúc đó tôi tỏ ra thông cảm, nhưng kết quả là, đối phương sau đó cứ dùng sản phẩm Y. Tôi sau đó nhiều lần nhắn tin riêng cố gắng kéo anh ta quay lại, nhưng đã rất khó khăn — anh ta đã hình thành thói quen sử dụng Y.
Suy cho cùng, một khi người dùng đã xây dựng thói quen sử dụng trên sản phẩm khác, chi phí để chuyển họ quay lại sẽ trở nên cực kỳ cao.
Vì vậy, hãy cố gắng đạt được: sửa lỗi trong vòng 2–5 giờ.
Nếu có nhiều người dùng liên tục đề xuất một tính năng mới nào đó mà họ cho là rất quan trọng và khả thi về mặt kỹ thuật:
· Hoàn thành phát triển và ra mắt trong vòng 2–3 ngày
· Nói rõ với họ rằng đây là tính năng được ra mắt dựa trên phản hồi của họ
· Thậm chí có thể cho một số khuyến khích kinh tế (điều này có thể biến họ thành người truyền bá tích cực nhất cho sản phẩm của bạn)
Việc giao tính năng xoay quanh nhu cầu người dùng sẽ mang lại ba điều: cải thiện trực tiếp bản thân sản phẩm, nâng cao tần suất sử dụng của người dùng, thiết lập mối quan hệ tin tưởng sâu sắc
Khi người dùng thấy phản hồi của họ được đối xử nghiêm túc và thực sự chuyển hóa thành tính năng sản phẩm, họ sẽ bắt đầu nảy sinh cảm giác: sản phẩm này "có một phần của họ".
Cảm giác "sở hữu" ở cấp độ tình cảm này, trong các sản phẩm cấp người dùng giai đoạn đầu cực kỳ quan trọng và cũng cực kỳ mạnh mẽ.
4. Tên App rất quan trọng
Nghe có vẻ rất cơ bản, nhưng nhiều người — bao gồm cả bản thân tôi — đã từng mắc sai lầm nghiêm trọng ở bước này.
Tên App của bạn phải có độ ghi nhớ cực cao, và đủ dễ dàng để kể lại và chia sẻ. Nếu không, bạn sẽ thường xuyên nhận được những tin nhắn như thế này (người dùng muốn giới thiệu, nhưng lại không nói rõ tên bạn là gì).
Sự thật cũng đúng như vậy — bản thân cái tên "encifher" đã rất khó nhớ, điểm này tôi thực sự không thể trách người dùng.
Thậm chí có không ít nhóm chat do các nhà đầu tư hoặc đối tác lập, tên sản phẩm đều viết sai, bây giờ nghĩ lại chỉ có thể cười khổ.
Chính vì vậy, chúng tôi sau đó đã đổi tên thành encrypt.trade.
Về cách đặt một cái tên "dễ nhớ và dễ chia sẻ", trên mạng thực sế có không ít phương pháp và tài liệu có sẵn để tham khảo.
5. Giao tiếp với người dùng rất khó, nhưng không thể thỏa hiệp
Việc tìm người dùng và thực sự giao tiếp với họ, bản thân nó đã là một việc rất khó khăn, đặc biệt là khi hướng đi của bạn không nằm trong luận thuyết chủ đạo hiện tại.
Lúc tôi mới làm sản phẩm liên quan đến quyền riêng tư, đây không phải là một lĩnh vực được săn đón. Mặc dù nhiều người dùng nhỏ lẻ có nhu cầu thực sự về quyền riêng tư, nhưng họ rất phân tán và cũng khó tìm.
Vì vậy tôi đã làm một việc mà hầu hết mọi người đều cố tình tránh: trong giai đoạn xác thực ý tưởng, tôi chủ động nhắn tin riêng lạnh (cold DM) cho gần 1000 người.
Nếu may mắn, khoảng 100 người thì sẽ có 10 người phản hồi; và trong những phản hồi đó, thực sự có thể cho bạn phản hồi hữu ích, có lẽ chỉ có 3–4 người.
Trong quá trình thực tế, chỉ cần có người biểu lộ dù chỉ một chút hứng thú, tôi đều trao đổi sâu với họ, và vừa giao tiếp với người dùng, vừa lặp lại sản phẩm.
Trên thực tế, bản thân việc nhắn tin lạnh cũng là một quá trình cần được lặp lại liên tục. Khi soạn và gửi cold DM, có mấy điểm then chốt cần chú ý: cố gắng bắt đầu bằng một mở đầu tương đối "ôn hòa", đặt thông tin có trọng lượng nhất lên trước (ví dụ tình hình gọi vốn, khối lượng giao dịch đã xử lý, v.v.), giải thích bạn đã thấy hoặc biết về đối phương ở đâu, giữ một lời kêu gọi hành động (CTA) thân thiện, không mang tính xâm phạm, nhất định phải theo dõi, đừng chỉ gửi một lần rồi kết thúc
Không tồn tại cái gọi là "cold DM hoàn hảo". Bạn cần liên tục kiểm tra A/B các phiên bản khác nhau, tìm ra những cách nào thực sự hiệu quả với người dùng mục tiêu của bạn.
Dưới đây là một mẫu cold DM chất lượng cao (cảm ơn @realsimon, từ @alliance), bạn có thể tham khảo sử dụng trực tiếp:
Nhưng cần phải rõ ràng là, quá trình này tiến triển chậm, và về mặt tâm lý rất hao tổn con người.
Trong ngành công nghiệp mã hóa, những người thực sự sẵn sàng trả lời cold DM rất ít, bởi vì lừa đảo có ở khắp nơi. Tỷ lệ phản hồi thấp là chuyện thường (thực sự hơi nản lòng).
Nhưng ngay cả như vậy, bạn vẫn phải làm.
Ở giai đoạn này, mục tiêu của bạn không phải là có được 1000 người dùng. Mục tiêu của bạn là 10–20 người dùng đầu tiên, họ cần có đặc điểm sau: thực sự quan tâm đến vấn đề bạn muốn giải quyết, sẵn sàng thử nghiệm sản phẩm của bạn, có thể đưa ra phản hồi trung thực, trực tiếp
Những người dùng đầu tiên này, sẽ dần dần trở thành hệ thống hỗ trợ của bạn. Sản phẩm giai đoạn đầu hầu như chắc chắn sẽ thường xuyên gặp vấn đề, và chính những người dùng này, giúp bạn vượt qua giai đoạn mong manh nhất.
6. Lặp lại nhanh chóng
Nhịp độ của ngành công nghiệp mã hóa cực kỳ nhanh. Luận thuyết thay đổi nhanh chóng, và thời gian chú ý của người dùng thì càng ngắn hơn.
Nếu bạn xây dựng một sản phẩm không có giá trị thực, bản thân nó đã khó có được sự chú ý; ngay cả khi bạn tạm thời có được sự chú ý trong tình trạng không có giá trị, sự chú ý này cũng sẽ không kéo dài.
Nhiều nhất chỉ có thể mang lại một làn sóng nhiệt tình ngắn hạn, nhưng bản thân sản phẩm không thể sống sót lâu dài.
Đây là lời khuyên của toly dành cho các nhà phát triển tại Breakpoint 2025.
Hàm nghĩa cốt lõi chỉ có ba điểm: giao hàng càng sớm càng tốt, lặp lại tần suất cao, dám điều chỉnh triệt để
Tôi còn học được một điều rất quan trọng: người dùng không phải lúc nào cũng trực tiếp nói cho bạn biết bước tiếp theo nên làm gì.
Bạn cần phải thông qua quan sát hành vi của họ để phán đoán: họ đang làm đi làm lại việc gì? Họ đang sử dụng những giải pháp tạm thời hoặc đường vòng nào? Họ đã sẵn sàng trả tiền cho cái gì?
Rất nhiều ý tưởng nghe có vẻ hợp lý, nhưng phần lớn người dùng chưa chắc đã sẵn sàng trả tiền cho nó.
7. Hãy làm cho trang web của bạn "ngu ngốc cũng dùng được"
Tôi không biết tại sao việc này lại cần được nhấn mạnh lặp đi lặp lại, nhưng vẫn phải nói một câu: "Đừng làm bất kỳ giả định nào về người dùng."
Nếu bạn nghĩ người dùng nên có thể hiểu, thì bạn đã sai. Những thứ đối với chúng tôi, những nhà phát triển đã đầu tư hàng trăm giờ xây dựng sản phẩm, là hiển nhiên, thì đối với người dùng tiếp xúc sản phẩm lần đầu, hoàn toàn là xa lạ.
Đừng giới thiệu bất kỳ khái niệm hoặc quy trình thao tác mới nào. Chỉ sử dụng những thứ đơn giản, quen thuộc, có thể thực sự làm cho cuộc sống người dùng dễ dàng hơn. Đường dẫn nhấp chuột nên càng tinh giản càng tốt, người dùng trong vòng 5 giây sau khi vào ứng dụng, nên có thể nhìn thấy, hiểu hoặc cảm nhận được giá trị của sản phẩm (điểm này chúng tôi vẫn đang tiếp tục tối ưu hóa).
Tôi không thể đính kèm ảnh chụp màn hình, nhưng tôi đã nhận được rất nhiều tin nhắn riêng, người dùng hoàn toàn hiểu sai mục đích sử dụng của một tính năng nào đó.
Kết luận
Xây dựng sản phẩm mã hóa cấp người dùng, vừa thú vị, cũng đầy thử thách.
Tốc độ, sự tập trung tối đa vào người dùng, và khả năng phân phối, thường quan trọng hơn "công nghệ hoàn hảo".
Điều này rất khác với sản phẩm B2B, nhưng tôi vẫn cho rằng, đây là lựa chọn đúng đắn mà chúng tôi đã làm.
Bài viết này đã đủ dài rồi, về kinh nghiệm gọi vốn, tôi sẽ để dành nói trong bài tiếp theo. Cuối cùng, hãy cứ dùng trực tiếp encrypt.trade :)
Nếu những nội dung này có cộng hưởng với bạn, hoặc bạn cũng đang làm sản phẩm mã hóa cấp người dùng, muốn nói chuyện về GTM, phân phối hoặc bản thân sản phẩm, hoan nghênh nhắn tin riêng cho tôi.
Tôi luôn sẵn lòng trao đổi với các nhà sáng lập, nhà phát triển khác.
