Web3 Geliştirici Pazarlama Ajansı ve DevRel: SDK'yı denemesi ve kullanması kolay hale getirin

Geliştirici pazarlama ne sağlar

Hızlı test: Ekibiniz dışındaki bir geliştiriciden quickstart'ı çalıştırmasını isteyin. Süreyi ölçün. 15 dakikadan uzun sürerse önce dokümantasyonu düzeltin.

Web3 geliştirici pazarlama, teknik bir ürünün değerini açıklamasına ve geliştiricilere net bir sonraki adım vermesine yardımcı olur. DevRel, bu ilişki etrafındaki sürekli çalışmadır: eğitim, destek, geri bildirim ve ürünü deneme fırsatları. Bu hizmet, SDK'nız veya protokolünüz değerlendirilmeye hazır olduğunda ancak geliştiriciler nereden başlayacaklarını hâlâ anlamakta zorlandığında faydalıdır.

Ürünün ilk anlamlı kullanımına kadar olan yolculuğu haritalayarak başlıyoruz. Bu, boşlukları görünür kılar: bir geliştirici projeyi bulabilir ancak kullanım senaryosunu anlamayabilir, dokümantasyona ulaşabilir ancak kurulumda takılı kalabilir veya bir öğreticiyi tamamlayabilir ancak nasıl devam edeceğini bilemeyebilir. Plan, her boşluğu topluluk etkinliğini kendi başına bir hedef olarak ele almak yerine pratik bir yanıtla ilişkilendirir.

Bu çalışma şunları içerebilir:

• Ürün için bir geliştirici hedef kitlesi ve kullanım senaryosu taslağı.
• Kayıt süreci, dokümantasyon ve SDK açıklamalarının incelenmesi.
• Topluluk desteği, teknik eğitim ve hackathon'lar için bir plan.
• Soruları, yayınlanan içeriği ve takip eylemlerini izlemek için basit bir yol.

Daha geniş lansman konumlandırma veya kanal koordinasyonu gerektiriyorsa, bu çalışmayı go-to-market stratejisi ile bağlayabiliriz. Pazarlama önceliklerinin daha geniş bir teşhisi için kripto pazarlama danışmanlığı bölümüne bakın.

Dokümantasyon SDK benimsenmesini nasıl desteklemeli?

Dokümantasyon, bir geliştirici kullanım senaryosunu, ön koşulları ve ilk eylemi tahmin etmeden anlayabildiğinde SDK benimsenmesini destekler. Yolu yeni bir kullanıcının deneyimleyeceği şekilde inceliyor, ardından sonraki adımı bulmayı ve takip etmeyi kolaylaştıran değişiklikler öneriyoruz.

Başlangıçta MarketingExtra, ekibinizin zaten sahip olduğu materyallere karşı bir dokümantasyon ve kayıt incelemesi yürütür. Ürün dili, quickstart talimatları ve gerçek geliştirici görevi arasındaki uyumsuzlukları ararız. İnceleme, belirsiz terminolojiyi, eksik bağlamı, güncel olmayan örnekleri veya okuyucunun yeterli rehberlik olmadan bir karar vermesinin istendiği yerleri işaretleyebilir. Teknik ekibiniz uygulama ayrıntılarını onaylar; bizim rolümüz öğrenme yolunu tutarlı ve içeriği gezinmesi kolay hale getirmektir.

Faydalı bir inceleme, "dokümantasyonu iyileştirin" gibi belirsiz bir istek değil, belirli eylemler üretir. Örneğin, ilk kullanım rehberliğini daha derin referans materyalinden ayırabilir, hangi SDK sorularının açıklayıcı bir makaleyi hak ettiğini belirleyebilir ve kullanıcıların yardım için nereye gitmesi gerektiğini netleştirebilir. Ayrıca, yayın öncesi konu uzmanlarınızın incelemesiyle içerik ve editoryal sırayı planlamaya yardımcı olabiliriz.

Mevcut dokümantasyonu, SDK genel bakışını, hedef geliştirici kullanım senaryolarını ve ekibinizin en sık duyduğu soruları hazırlayın. Öncelik tek seferlik bir inceleme yerine sürekli destekse, bu çalışmayı lansman sonrası destek ile eşleştirin.

Hackathon ne zaman mantıklıdır?

Bir hackathon, geliştiriciler etkinlik sırasında ürünle anlamlı bir şey inşa edebildiğinde ve ekibiniz onları çalışırken destekleyebildiğinde iyi bir uyumdur. SDK, dokümantasyon veya takip yolu katılımcılar için hazır değilse, bağımsız bir duyuru olarak daha az kullanışlıdır.

Bir etkinlik veya format seçmeden önce şu soruları yanıtlayabildiğinizi kontrol edin:

• Katılımcılar ne inşa edebilmeli, test edebilmeli veya öğrenebilmeli?
• Hangi ürün materyallerine ihtiyaç duyacaklar ve teknik soruları kim netleştirebilir?
• Gönderim ve değerlendirme süreci nedir ve bunu kim açıklayacak?
• Etkinlikten sonra faydalı projeler veya geri bildirimler nasıl bir sonraki adım alacak?

Geliştirici zorluğunu tanımlamaya, destekleyici içeriği hazırlamaya, iletişimi koordine etmeye ve ekibinizle takip planını düzenlemeye yardımcı olabiliriz. Plan, ürünün olgunluğuyla eşleşmelidir: erken bir SDK, rehberli kayıt ve geri bildirim gerektirebilirken, daha yerleşik bir entegrasyon yolu daha geniş bir proje briefini destekleyebilir. Her durumda, katılımcıların net bir başlangıç noktasına ve güvenilir bir yanıt alma yoluna ihtiyacı vardır.

Etkinlik planı için, tanıtım başlamadan önce teknik iletişim, inceleme sorumlulukları ve katılım kriterleri üzerinde dahili olarak anlaşın. Etkinliği token lansman ve büyüme planınıza yalnızca ürün ve geliştirici hedefleri bu daha geniş etkinliği gerçekten destekliyorsa bağlayın.

6 maddelik DevRel kontrol listeniz

Etkinlikleri planlamadan önce bu 6 maddeyi kontrol edin. Bunlar SDK'yı denemeyi kolaylaştırır; hackathon'lar, konuşmalar ve gönderiler, geliştiriciler ilk denemede pes ettikten sonra bunu düzeltemez.

1. Quickstart'ı dışarıdan bir geliştiriciyle çalıştırın.
2. Çalışan bir örnek uygulama sağlayın.
3. Depoyu, dokümantasyonu ve değişiklik günlüğünü bağlayın.
4. Geliştiricilerin soru sorduğu yeri adlandırın.
5. Yeni soruları bir gün içinde yanıtlayın.
6. Net bir sonucu olan bir etkinlik planlayın.

Tek satırda terimler

SDK: yazılım geliştirme kiti, geliştiricilerin ürününüzle inşa etmek için kullandığı araçlar ve kod.

DevRel (sade bir dille: geliştirici ilişkileri, geliştiricilerin bir ürünle başarılı olmasına yardımcı olma işi).

Etkinlikler arasında bir geliştirici topluluğunu ne faydalı tutar

Temel kural: Çalışan bir örnek uygulama, on sayfa açıklamadan iyidir.

Faydalı bir geliştirici topluluğu, insanlara ürün soruları sormak, yaklaşımları karşılaştırmak ve güvenilir rehberlik bulmak için bir yer verir. Dokümantasyonu tamamlamalı, temel kurulum bilgilerinin bulunduğu tek yer haline gelmemelidir.

Topluluk deneyimini geliştiricilerin gerçekten getirdiği sorular etrafında şekillendirmeye yardımcı oluyoruz: başlama, teknik bir kavramı anlama, bir entegrasyonu giderme veya sırada ne inşa edeceğine karar verme. Bu, ekibin yanıtlayacağı soru türlerini, teknik yanıtlardan kimin sorumlu olduğunu ve bir tartışmanın ne zaman dokümantasyon güncellemesine yol açması gerektiğini tanımlamak anlamına gelir. Net sınırlar da önemlidir; topluluk üyeleri hangi ifadelerin resmi ürün rehberliği olduğunu ve bir sorunu nereye bildireceklerini bilmelidir.

Pratik bir işletim planı şunları içerebilir:

• Topluluk amacı, hedef kitle ve katılım kuralları.
• Teknik sorular için bir yanıt ve yükseltme yolu.
• Yaygın geliştirici ihtiyaçlarına dayalı yinelenen bir içerik ritmi.
• Faydalı geri bildirimi ürün ekibine taşımanın bir yolu.

Topluluk aktivasyonunu ve eğitim programlarını koordine edebiliriz; mühendisleriniz teknik doğruluğun sahipliğini korurken. Projeniz geliştirici desteğinin ötesinde daha geniş topluluk operasyonları gerektiriyorsa, topluluk yönetimi bölümünü düşünün. Doğru seçim, ekibinizin sürdürebileceği ve bir geliştiricinin ilerlemesine yardımcı olan plandır; sadece en meşgul görünen kanal değil.

Bir DevRel angajmanı nasıl teslim edilir

Bir DevRel angajmanı, ürününüzün, mevcut materyallerinizin ve acil geliştirici hedeflerinizin bir incelemesiyle başlar. Bu incelemeden, ekibin ne teslim edeceği, teknik içeriği kimin onaylaması gerektiği ve ilerlemenin nasıl raporlanacağı konusunda anlaşırız.

Tipik bir sıra şudur:

1. Ürün genel bakışını, mevcut SDK materyallerini ve en çok duyduğunuz geliştirici sorularını paylaşın.
2. Kayıt sürecini, dokümantasyonu ve mevcut topluluk temas noktalarını ekibinizle inceleyin.
3. Ürün hazırlığına, mevcut teknik desteğe ve lansman zamanlamasına uyan öncelikleri seçin.
4. Üzerinde anlaşılan içeriği, topluluk etkinliğini veya hackathon hazırlığını üretin veya koordine edin.
5. Tamamlanan işi, açık soruları ve önerilen takipleri ekibinizle gözden geçirin.

Plan, odaklı bir inceleme veya sürekli destek olabilir; mühendislerinizin incelemeler veya etkinlik katılımı için sınırsız zamanı olduğunu varsaymamalıdır. Programı ayarlarken onay döngülerini hesaba katar ve teknik kararları ürüne sahip olan kişilerde tutarız. Güncellemeler, neyin tamamlandığını, neyin girdi beklediğini ve sırada hangi kararın gerektiğini netleştirmelidir.

Çalışmanın yardımcı olup olmadığını değerlendirmek için ekibinizin gözlemleyebileceği pratik sinyalleri izleyin: çözülen sorular, giderilen dokümantasyon boşlukları, tamamlanan kayıt adımları ve ilgili SDK konuşmaları. Raporlama formatı bu gözlemleri planlama için faydalı hale getirmeli, etkinliği benimsenme iddiasına dönüştürmemelidir. Birden fazla lansman önceliğini kapsayan işler için planı büyüme pazarlama desteğine bağlayın.

Bir plana bağlanmadan önce ne doğrulanmalı

Sağlam bir DevRel planı, ürünün hazırlığını ekibin geliştiricileri destekleme yeteneğiyle eşleştirir. Taahhüt etmeden önce, SDK'nın net bir kullanım senaryosuna sahip olduğunu, dokümantasyonun mevcut ürünü yansıttığını ve teknik bir sorumlunun kamuya açık rehberliği inceleyebileceğini doğrulayın. Ayrıca, mühendislik girdisi gerektiren soruları kimin ele aldığı ve bir hackathon veya topluluk tartışmasından sonra neyin faydalı bir takip sayıldığı konusunda anlaşın.

Etkinlik organizatörleri kendi kurallarını, programlarını ve seçim kararlarını belirler ve geliştiriciler bir etkinlikten sonra bir entegrasyona devam edip etmeyeceklerine karar verir. Üzerinde anlaşılan dokümantasyon, destek ve etkinlik işini teslim edebiliriz, ancak üçüncü taraf bir etkinliğe kabul veya sonuçta ortaya çıkan SDK entegrasyonlarını vaat edemeyiz.

3 şey gönderin: dokümantasyon bağlantınız, SDK deponuz ve ulaşmak istediğiniz geliştirici grubu. Bunlarla, ilk bakıştan ilk çağrıya kadar olan yolu inceler ve maliyeti iş başlamadan önce yazılı olarak onaylarız.

Nasıl çalışır

1. Ürün bağlamını paylaşınÜrün genel bakışınızı, SDK materyallerinizi, geliştirici hedef kitlenizi ve mevcut önceliklerinizi gönderin. Ekibinizin tekrar tekrar duyduğu soruları ekleyin.
2. Geliştirici yolculuğunu inceleyinDokümantasyonunuz ve destek temas noktalarınız aracılığıyla yolu değerlendirir, ardından net bir sonraki eylemi engelleyen boşlukları belirleriz.
3. Plan ve sorumlular üzerinde anlaşınÜrün hazırlığına uyan işi seçin, inceleme sorumluluklarını belirleyin ve hangi teknik kararların ekibinizde kaldığını onaylayın.
4. Üzerinde anlaşılan işi teslim edinDokümantasyon, topluluk desteği veya hackathon hazırlığını koordine eder ve açık istekleri ilgili sorumlulara görünür tutarız.
5. İnceleyin ve takibi planlayınTamamlanan işin, çözülmemiş soruların ve geliştirici kaydı için önerilen sonraki adımların kısa bir hesabını alırsınız.