Marketing cho lập trình viên Web3 và DevRel: giúp SDK dễ dùng và dễ giữ chân

Marketing cho lập trình viên mang lại điều gì

Kiểm tra nhanh: Nhờ một lập trình viên bên ngoài nhóm của bạn chạy quickstart. Tính thời gian. Nếu mất hơn 15 phút, hãy sửa tài liệu trước.

Marketing cho lập trình viên Web3 giúp một sản phẩm kỹ thuật giải thích giá trị của nó và cho lập trình viên một bước tiếp theo rõ ràng. DevRel là công việc liên tục xoay quanh mối quan hệ đó: giáo dục, hỗ trợ, phản hồi và cơ hội để dùng thử sản phẩm. Dịch vụ này hữu ích khi SDK hoặc giao thức của bạn đã sẵn sàng để được đánh giá nhưng lập trình viên vẫn gặp khó khăn trong việc hiểu bắt đầu từ đâu.

Chúng tôi bắt đầu bằng cách lập bản đồ hành trình từ khám phá đến lần sử dụng sản phẩm có ý nghĩa đầu tiên. Điều đó làm lộ ra những khoảng trống: một lập trình viên có thể tìm thấy dự án nhưng không hiểu trường hợp sử dụng, đến được tài liệu nhưng bị kẹt ở bước thiết lập, hoặc hoàn thành một hướng dẫn mà không biết cách tiếp tục. Kế hoạch gắn từng khoảng trống với một phản hồi thực tế thay vì coi hoạt động cộng đồng là mục tiêu tự thân.

Công việc này có thể bao gồm:

• Phác thảo đối tượng lập trình viên và trường hợp sử dụng cho sản phẩm.
• Đánh giá quy trình onboarding, tài liệu và giải thích SDK.
• Kế hoạch hỗ trợ cộng đồng, giáo dục kỹ thuật và hackathon.
• Cách đơn giản để theo dõi câu hỏi, nội dung đã xuất bản và các hành động tiếp theo.

Nếu việc ra mắt rộng hơn cần định vị hoặc phối hợp kênh, chúng tôi có thể kết nối công việc này với chiến lược go-to-market. Để chẩn đoán rộng hơn về các ưu tiên marketing, hãy xem tư vấn marketing crypto.

Tài liệu nên hỗ trợ việc áp dụng SDK như thế nào?

Tài liệu hỗ trợ việc áp dụng SDK khi một lập trình viên có thể hiểu trường hợp sử dụng, điều kiện tiên quyết và hành động đầu tiên mà không cần phải đoán. Chúng tôi xem xét lộ trình như một người dùng mới sẽ trải nghiệm, sau đó đề xuất các thay đổi giúp bước tiếp theo dễ tìm và dễ làm theo hơn.

Khi bắt đầu, MarketingExtra thực hiện đánh giá tài liệu và onboarding dựa trên các tài liệu mà nhóm của bạn đã có. Chúng tôi tìm kiếm sự không khớp giữa ngôn ngữ sản phẩm, hướng dẫn quickstart và nhiệm vụ thực tế của lập trình viên. Đánh giá có thể chỉ ra thuật ngữ không rõ ràng, thiếu ngữ cảnh, ví dụ lỗi thời hoặc những chỗ người đọc được yêu cầu đưa ra quyết định mà không có đủ hướng dẫn. Nhóm kỹ thuật của bạn xác nhận chi tiết triển khai; vai trò của chúng tôi là làm cho lộ trình học tập mạch lạc và nội dung dễ điều hướng.

Một đánh giá hữu ích tạo ra các hành động cụ thể, không phải yêu cầu mơ hồ là “cải thiện tài liệu.” Ví dụ, nó có thể tách hướng dẫn sử dụng lần đầu khỏi tài liệu tham khảo chuyên sâu, xác định câu hỏi SDK nào cần một bài viết giải thích, và làm rõ người dùng nên đến đâu để được trợ giúp. Chúng tôi cũng có thể giúp lên kế hoạch nội dung và trình tự biên tập, với sự xem xét từ các chuyên gia chủ đề của bạn trước khi xuất bản.

Chuẩn bị tài liệu hiện tại, tổng quan SDK, các trường hợp sử dụng lập trình viên mục tiêu và những câu hỏi mà nhóm của bạn nghe thấy thường xuyên nhất. Nếu ưu tiên là hỗ trợ liên tục thay vì đánh giá một lần, hãy kết hợp công việc này với hỗ trợ sau ra mắt.

Khi nào thì hackathon có ý nghĩa?

Hackathon phù hợp khi lập trình viên có thể xây dựng thứ gì đó có ý nghĩa với sản phẩm trong suốt sự kiện và nhóm của bạn có thể hỗ trợ họ trong quá trình làm việc. Nó ít hữu ích hơn như một thông báo độc lập nếu SDK, tài liệu hoặc lộ trình tiếp theo chưa sẵn sàng cho người tham gia.

Trước khi chọn sự kiện hoặc hình thức, hãy kiểm tra xem bạn có thể trả lời những câu hỏi này không:

• Người tham gia nên có thể xây dựng, kiểm tra hoặc học được gì?
• Họ sẽ cần những tài liệu sản phẩm nào, và ai có thể làm rõ các câu hỏi kỹ thuật?
• Quy trình nộp bài và đánh giá là gì, và ai sẽ giải thích nó?
• Làm thế nào các dự án hoặc phản hồi hữu ích nhận được bước tiếp theo sau sự kiện?

Chúng tôi có thể giúp xác định thử thách cho lập trình viên, chuẩn bị nội dung hỗ trợ, phối hợp truyền thông và tổ chức kế hoạch tiếp theo với nhóm của bạn. Kế hoạch nên phù hợp với mức độ trưởng thành của sản phẩm: một SDK sớm có thể cần onboarding có hướng dẫn và phản hồi, trong khi một lộ trình tích hợp đã ổn định hơn có thể hỗ trợ một brief dự án rộng hơn. Trong cả hai trường hợp, người tham gia cần một điểm khởi đầu rõ ràng và một cách đáng tin cậy để nhận câu trả lời.

Đối với kế hoạch sự kiện, hãy thống nhất nội bộ về đầu mối kỹ thuật, trách nhiệm đánh giá và bất kỳ tiêu chí tham gia nào trước khi bắt đầu quảng bá. Kết nối sự kiện với kế hoạch launch token và tăng trưởng chỉ khi sản phẩm và mục tiêu lập trình viên thực sự hỗ trợ hoạt động rộng hơn đó.

Danh sách 6 điểm DevRel của bạn

Kiểm tra 6 điểm này trước khi bạn lên kế hoạch sự kiện. Chúng giúp SDK dễ dùng, đó là điều mà hackathon, bài nói chuyện và bài đăng không thể sửa chữa một khi lập trình viên đã từ bỏ ngay lần thử đầu tiên.

1. Chạy quickstart với một lập trình viên bên ngoài.
2. Cung cấp một ứng dụng mẫu hoạt động.
3. Liên kết repo, tài liệu và changelog.
4. Nêu rõ nơi lập trình viên đặt câu hỏi.
5. Trả lời câu hỏi mới trong vòng một ngày.
6. Lên kế hoạch một sự kiện với kết quả rõ ràng.

Thuật ngữ trong một dòng

SDK: bộ công cụ phát triển phần mềm, các công cụ và mã mà lập trình viên sử dụng để xây dựng với sản phẩm của bạn.

DevRel (nói đơn giản: quan hệ lập trình viên, công việc giúp lập trình viên thành công với một sản phẩm).

Điều gì giữ cho cộng đồng lập trình viên hữu ích giữa các sự kiện

Nguyên tắc chung: Một ứng dụng mẫu hoạt động tốt hơn mười trang giải thích.

Một cộng đồng lập trình viên hữu ích mang đến cho mọi người một nơi để đặt câu hỏi về sản phẩm, so sánh cách tiếp cận và tìm hướng dẫn đáng tin cậy. Nó nên bổ sung cho tài liệu, không trở thành nơi duy nhất tồn tại thông tin thiết lập cần thiết.

Chúng tôi giúp định hình trải nghiệm cộng đồng xoay quanh những câu hỏi mà lập trình viên thực sự mang đến: bắt đầu, hiểu một khái niệm kỹ thuật, khắc phục sự cố tích hợp hoặc quyết định xây dựng gì tiếp theo. Điều đó có nghĩa là xác định loại câu hỏi mà nhóm sẽ trả lời, ai chịu trách nhiệm trả lời kỹ thuật, và khi nào một cuộc thảo luận nên dẫn đến cập nhật tài liệu. Ranh giới rõ ràng cũng quan trọng; các thành viên cộng đồng nên biết tuyên bố nào là hướng dẫn chính thức của sản phẩm và nơi báo cáo sự cố.

Một kế hoạch vận hành thực tế có thể bao gồm:

• Mục đích cộng đồng, đối tượng và hướng dẫn tham gia.
• Lộ trình phản hồi và leo thang cho các câu hỏi kỹ thuật.
• Nhịp điệu nội dung định kỳ dựa trên nhu cầu phổ biến của lập trình viên.
• Cách chuyển phản hồi hữu ích đến nhóm sản phẩm.

Chúng tôi có thể phối hợp kích hoạt cộng đồng và chương trình giáo dục trong khi các kỹ sư của bạn giữ quyền sở hữu về độ chính xác kỹ thuật. Nếu dự án của bạn cần hoạt động cộng đồng rộng hơn ngoài hỗ trợ lập trình viên, hãy xem xét quản lý cộng đồng. Lựa chọn đúng là kế hoạch mà nhóm của bạn có thể duy trì và giúp lập trình viên tiến bộ, không chỉ đơn giản là kênh trông bận rộn nhất.

Một hợp đồng DevRel được triển khai như thế nào

Một hợp đồng DevRel bắt đầu bằng việc xem xét sản phẩm, tài liệu hiện có và mục tiêu lập trình viên trước mắt của bạn. Từ đánh giá đó, chúng tôi thống nhất những gì nhóm sẽ bàn giao, ai cần phê duyệt nội dung kỹ thuật và cách báo cáo tiến độ.

Một trình tự điển hình là:

1. Chia sẻ tổng quan sản phẩm, tài liệu SDK hiện tại và các câu hỏi lập trình viên bạn nghe thấy nhiều nhất.
2. Xem xét quy trình onboarding, tài liệu và các điểm tiếp xúc cộng đồng hiện có với nhóm của bạn.
3. Chọn các ưu tiên phù hợp với mức độ sẵn sàng của sản phẩm, hỗ trợ kỹ thuật có sẵn và thời điểm ra mắt.
4. Sản xuất hoặc phối hợp nội dung đã thống nhất, hoạt động cộng đồng hoặc chuẩn bị hackathon.
5. Xem xét công việc đã hoàn thành, các câu hỏi còn bỏ ngỏ và các bước tiếp theo được đề xuất với nhóm của bạn.

Kế hoạch có thể là một đánh giá tập trung hoặc hỗ trợ liên tục; nó không nên giả định rằng các kỹ sư của bạn có thời gian không giới hạn cho việc đánh giá hoặc tham gia sự kiện. Chúng tôi tính đến các chu kỳ phê duyệt khi thiết lập lịch trình, và giữ các quyết định kỹ thuật cho những người sở hữu sản phẩm. Các cập nhật nên làm rõ những gì đã hoàn thành, những gì đang chờ đầu vào và quyết định nào cần được đưa ra tiếp theo.

Để đánh giá xem công việc có hữu ích hay không, hãy theo dõi các tín hiệu thực tế mà nhóm của bạn có thể quan sát: các câu hỏi đã được giải quyết, khoảng trống tài liệu đã được xử lý, các bước onboarding đã hoàn thành và các cuộc trò chuyện SDK có liên quan. Định dạng báo cáo nên làm cho những quan sát đó hữu ích cho việc lập kế hoạch, không biến hoạt động thành một tuyên bố về việc áp dụng. Đối với công việc bao gồm nhiều ưu tiên ra mắt, hãy kết nối kế hoạch với hỗ trợ marketing tăng trưởng.

Cần xác minh điều gì trước khi cam kết với một kế hoạch

Một kế hoạch DevRel hợp lý phù hợp với mức độ sẵn sàng của sản phẩm với khả năng hỗ trợ lập trình viên của nhóm. Trước khi cam kết, hãy xác nhận rằng SDK có trường hợp sử dụng rõ ràng, tài liệu phản ánh sản phẩm hiện tại và một chủ sở hữu kỹ thuật có thể xem xét hướng dẫn công khai. Cũng thống nhất ai xử lý các câu hỏi cần đầu vào kỹ thuật và điều gì được coi là bước tiếp theo hữu ích sau một hackathon hoặc thảo luận cộng đồng.

Ban tổ chức sự kiện đặt ra các quy tắc, lịch trình và quyết định lựa chọn của riêng họ, và lập trình viên quyết định có tiếp tục tích hợp sau sự kiện hay không. Chúng tôi có thể bàn giao tài liệu, hỗ trợ và công việc sự kiện đã thống nhất, nhưng không thể hứa hẹn việc chấp nhận vào một sự kiện của bên thứ ba hoặc các tích hợp SDK kết quả.

Gửi 3 thứ: liên kết tài liệu của bạn, repo SDK của bạn và nhóm lập trình viên bạn muốn tiếp cận. Với những thứ đó, chúng tôi xem xét lộ trình từ lần đầu tiếp cận đến cuộc gọi đầu tiên và xác nhận chi phí bằng văn bản trước khi công việc bắt đầu.

Cách hoạt động

1. Chia sẻ bối cảnh sản phẩmGửi tổng quan sản phẩm, tài liệu SDK, đối tượng lập trình viên và các ưu tiên hiện tại của bạn. Bao gồm các câu hỏi mà nhóm của bạn nghe thấy nhiều lần.
2. Xem xét hành trình lập trình viênChúng tôi đánh giá lộ trình qua tài liệu và các điểm tiếp xúc hỗ trợ của bạn, sau đó xác định các khoảng trống cản trở một hành động rõ ràng tiếp theo.
3. Thống nhất kế hoạch và người phụ tráchChọn công việc phù hợp với mức độ sẵn sàng của sản phẩm, thiết lập trách nhiệm đánh giá và xác nhận các quyết định kỹ thuật nào vẫn thuộc về nhóm của bạn.
4. Bàn giao công việc đã thống nhấtChúng tôi phối hợp tài liệu, hỗ trợ cộng đồng hoặc chuẩn bị hackathon và giữ cho các yêu cầu mở được hiển thị cho các chủ sở hữu có liên quan.
5. Xem xét và lên kế hoạch tiếp theoBạn nhận được một báo cáo ngắn gọn về công việc đã hoàn thành, các câu hỏi chưa được giải quyết và các hành động tiếp theo được đề xuất cho quy trình onboarding lập trình viên.