Çevik Uygulamalar: Pazarlama Ekibimizin Yaptığı Hatalardan Nasıl Kaçınılır?

Yayınlanan: 2020-12-22

hatalar-çevik-pazarlama-ekibi Sır açığa çıktı. Çevik proje yönetimi oyunun kurallarını değiştiriyor ve artık bunu bilenler yalnızca geliştiriciler ve BT çalışanları değil.

Bir pazarlamacı olarak, kesinlikle Agile'ı duymuşsunuzdur. Ekibiniz proje sprintleri ve stand-up toplantıları gibi bazı Agile uygulamaları kullanıyor olabilir. Eğer öyleyse, azınlıktasın. Çevik'in faydalarından pazarlama ekipleri tarafından hâlâ büyük ölçüde yararlanılmamıştır. Workfront ve MarketingProfs tarafından hazırlanan yeni bir rapora göre, pazarlama ekiplerinin yalnızca% 30'u süreçlerini yönetmek için Agile yaklaşımı kullanıyor. Diğer% 70 muhtemelen Agile işe koyulmadan önce ekibimin yaşadığı aynı hayal kırıklıklarını yaşıyor.

#Pazarlama ekiplerinin yalnızca% 30'u, @workfront_inc @MarketingProfs aracılığıyla süreçleri yönetmek için #Agile yaklaşımını kullanıyor. Tweet İçin Tıklayın

Emplify'deki yedi kişilik pazarlama ekibimiz neredeyse bir yıldır Agile uyguluyor. İyi uygulama noktasına gelmemiz altı ayımızı aldı: daha iyi, daha hızlı ve daha fazla enerji ve katılımla iş üretmek.

Agile'ı uygulamaya başladığımızda birçok hata yaptık. Aslında o kadar çok hata ki, bir gün ekibimizin yarısını bir konferans odasına kilitledik ve yaklaşımımızdaki bazı önemli eksiklikleri tespit edip giderene kadar ayrılmadık. Neyse ki bira vardı ve bir Cuma günüydü. Yine de acı vericiydi ve süreç odaklı derin deliklerden kendimizi çıkarmak zaman aldı.

Bu yazıda, bizimki gibi acı verici bir kilitlenmeden kaçınmanız için bu hataları paylaşıyorum. Çevik, sürecin sizin için çalışmasını taahhüt ederseniz, pazarlama ekibinizin işbirliği yapma ve işi daha hızlı teslim etme becerisinde devrim yaratabilir.

Başlamadan önce birkaç temel konuyu ele alalım:

Çevik uygulamalar nelerdir?

Çevik uygulamalar (genellikle "Çevik" olarak anılır), haftalar veya aylar sürebilen (geleneksel olarak şelale tarzı yönetim olarak adlandırılır) daha büyük birbiriyle bağlantılı görevlere sahip projeler üzerinden daha küçük iş bölümlerinin sürekli sunulmasını vurgular.

Çevik temeller şunları içerir:

  • Scrum ekibi: Bir scrum ustası altında organize edilen bu son derece işbirlikçi ekip, karmaşık sorunları çözer ve bir haftadan 30 güne kadar sürebilen, sprint adı verilen sabit uzunlukta yinelemelerde çözümler sunar. Örneğin, içerik üzerinde çalışan bir saldırı ekibi, yeni bir infografik veya veri sayfası oluşturmayı taahhüt ederek iki haftalık bir sprint başlatabilir.
  • Minimum uygulanabilir ürün (MVP): Bir teslim edilebilir ürün planlarken, Çevik ilkeler, ekibinizin gerçek sorunlara erken yanıt verebilmesi için projeyi olabildiğince hızlı bir şekilde ortaya çıkarmayı vurgular. Bir sürekli teslimat modeli elde etmek için, scrum ustaları ekipleri MVP'yi tanımlamaya ve ürünü sprint sınırları içinde bitirmenin en yaratıcı yollarını bulmaya teşvik eder. Örneğin, MVP'niz olarak bir e-kitap oluşturmak için iki haftalık bir sprint başlatırsanız ve tasarımcınız hastalanırsa, o sprint'in MVP'sini bir dizi blog yazısı olarak yeniden tanımlamaya ve sonraki e-kitabı tasarlamaya karar verebilirsiniz. sürat koşusu.
  • Günlük stand-up toplantısı: Takım üyeleri, scrum takımının tamamlanmış görevlerini, odak alanlarını ve kendilerine verilen sprint çalışmalarını bitirmelerini engelleyebilecek engelleyicileri tartışmak için her sabah 15 dakika kadar bir daire içinde dururlar. Sprint sonunda, Agile takımları bir sonraki sprintte değerlendirilip iyileştirilen tanımlanmış bir proje seti sunar. Bazı scrum takımları, bir sonraki sprintte ele alınabilecek süreç eksikliklerini tartıştıkları geçmişe dönük toplantılar da içerir.

Çevik Pazarlama Hataları_1

ELLEÇLENEN İLGİLİ İÇERİK:
Üretkenliği Yüksek İçerik Takımlarının 30 Alışkanlığı [İnfografik]

Pazarlamacılar neden Agile kullanmalı?

National Public Radio, yeni programlama oluşturmak ve test etmek için Agile metodolojilerini kullanır. Bir sonraki "araba yolu anınızda" bunu düşünün. Agile'ın kökleri BT yönetiminde olmasına rağmen, bu tür bir proje teslimi, pazarlama dahil olmak üzere bir işletmenin birçok işlevine uygulanabilir.

Çevik bir sürekli yineleme modelini benimsemek, pazarlama ekibinizin yeni mesajları veya kampanyaları hızla test etmesine, ürün güncellemelerine daha hızlı tepki vermesine ve ekibinizden iş isteyen paydaşlarla beklentiler belirlemesine olanak tanır.

Çevik yolculuğumuza başladıktan neredeyse dokuz ay sonra, ürün mesajlarımızda bazı değişiklikler yapmak için web sitemizdeki içeriği yenilediğimizde ekibimin parlayan anı geldi. Bir haftada neler başarabileceğimizi belirledik ve bu işi planlandığı gibi teslim ettik. O sprintte güncellemek için zamanımız olmayan içeriği navigasyondan sakladık. Sonraki sprintlerimiz sırasında bu sayfalardaki mesajları sürekli ekliyor ve yeniliyoruz.

ELLEÇLENEN İLGİLİ İÇERİK:
Çevik Pazarlama Hakkında Kafanız mı Karışık? Sorularınızın Cevapları [Videolu]

Hangi hatalardan kaçınılmalıdır?

Takımınızda Agile'ı benimsemeyi düşünüyorsanız, sadece pazarlama ekibinizdeki süreçleri düzene sokmak istiyor olsanız bile, ekibimizin yaptığı bu dört Çevik pazarlama hatasından kaçınmak isteyeceksiniz:

  1. Ödevimizi yapmadan kendimize Çevik dedik.
  2. Sorunlu sahipleri belirleyemedik.
  3. Sorunlardan çok çıktılara odaklandık.
  4. Öncelik vermek yerine tıkıştık (ve her şeyi halledebilecekmişiz gibi yaptık).

Hata 1: Ödevimizi yapmadan kendimize Çevik derdik

Pazarlama ekibimle başladığımda, projeleri kontrol etmenin hızlı ve acısız bir yolunu sağlamak için hızlı bir şekilde günlük stand-up'lar başlattım. Eski rollerde stand-up yaptığımı ve sprintler düzenlediğimi düşündüm, bu yüzden Agile ile deneyimim oldu, değil mi? Yanlış.

Bir Pazartesi günü işe gelmeyin ve benim yaptığım gibi "Agile" olduğunu duyurmayın. Sırf iki haftalık sprintlerde çalışıyor olmanız ve günlük stand-up'larınız olması, Agile takımı olduğunuz anlamına gelmez. Çevik'in güzelliği, ekibinize projelere birlikte taahhüt verme ve belirlenen bir zaman aralığında kaliteli bir çıktı tanımlama gücü vermesidir. Mümkün olduğunca çok işi iki haftaya sığdırmaya çalışıyorsanız ve bitiş çizgisini geçmek için kaliteden ödün veriyorsanız, bu güzellik reddedilir.

Pazarlama ekibinizde Çevik süreçler oluşturmadan önce ev ödevinizi yapın. Bir veya iki kitabı kırın. Scrum by Jeff Sutherland (çoğu kişi tarafından Agile'ın babalarından biri olarak bilinir) ve Scott Brinker tarafından Hacking Marketing ile başlamanızı öneririm. Ayrıca, CMI'nin Çevik pazarlama hakkındaki mükemmel makalelerinden bazılarını okuyun.

Ödevinizi yaptıktan sonra, ekibiniz için işe yarayacak bir Agile yaklaşımı oluşturmaya başlamak için mevcut sürecinizde birkaç basit değişikliğe öncelik verin.

@Evacjackson, #contentmarketing ekibinizde #Agile süreçlerini başlatmadan önce ev ödevinizi yapın diyor. Tweet İçin Tıklayın

Hata 2: Sorunlu sahipleri belirleyemedik

Aşağıdaki senaryo gerçekleşmediyse bu bölümü atlayabilirsiniz; Henüz keşfetmediğim bir tür pazarlama süreci nirvana elde ettiniz.

Geri kalanınız şunu hayal edin:% 98'i net bir son teslim tarihine sahip büyük bir ekip projesinden geçiyorsunuz ve son saatte sürpriz bir paydaş düzinelerce revizyonla adım atıyor. Ardından, ekibiniz bu değişiklikleri ele almak için projeyi iki hafta daha uzatmak zorunda kalır çünkü kimse bu paydaşın yanlış olduğunu iddia edemez.

Hala okuyor? Ben de öyle düşünmüştüm.

Ekibimizin tanımlanmış sahiplik eksikliği, Agile pazarlama departmanı olarak ilerlememizin önündeki en büyük engeldi. İşten bunalmıştık. Birden fazla paydaş proje kalitesine ağırlık verdiğinde hayal kırıklığına uğradık. Ve son dakika düzenlemeleri ve düzeltmeleri nedeniyle kapıdan hiçbir şey alamıyorduk.

Pazarlama ekibiniz bizimki gibi bir şeyse, bir projenin nihai sahibinin kim olduğunu bilmekte zorlanırsınız. Bir çıktının başarısından doğrudan sorumlu kişi kimdir? Takımın uyum sağlayabileceği bir görev için ölçülebilir sonuçları kim belirler? Bu projenin başarılı olması için kimin nihayetinde başarılı olabilmesi için kimin ihtiyacı var?

Son dakikada yeniden çalışmayı önlemek için, artık her projeye böyle bir kişiyi - sorun sahibi - atıyoruz.

Son dakikada yeniden çalışmayı önleyin, # Çevik # içerik stratejisinde her kanala bir sorun sahibi atayın. @evacjackson Tweet İçin Tıklayın

Her üç ayda bir, ana pazarlama kanallarımızın her biri için satışa uygun bir müşteri adayı hedefi belirleriz: reklamcılık, etkinlikler, organik web sitesi liderleri vb. Ardından, bu kanalların her birine ekibimizde bir sahip atanır ve bu kanal sahibi, bu kanalın kapsamına giren tüm teslimatlar için başvurulacak kişi olur.

Ekibimiz için sorun sahipliği, birkaç nedenden ötürü özellikle başarılı oldu:

  • Başarı sorumluluğunu, hedeflere ulaşılmazsa sorumlu tutulan bir kişiye yükler .
  • Ekibin proaktif olarak bunları çözebilmesi için kanal sahibini sorunları erken ortaya çıkarmaya zorlar .
  • Tüm ekibin bir çözüm için beyin fırtınası yapmasına ve bir düzeltmenin uygulanmasına katılmasına olanak tanır .
  • Herhangi bir projenin kalitesine rehberlik etmesi için bir kişiye yetki verir.

Ekibiniz içerik projelerinizde son sözü kimin söyleyeceği konusunda net değilse, departmanınızla oturun ve şaşırtıcı derecede basit ama zorlu bir soru sorun: "Kim neye sahip?" Bu soruyu cevaplamak ve cevaplarınızı herkesin görmesi için kaydetmek, ölçülemez bir sorumluluk yaratacaktır.

ELLEÇLENEN İLGİLİ İÇERİK:
İçerik Ekibinizde İşbirliğine Dayalı Aşırı Yüklenmeyi Önleme

Hata 3: Sorunlardan çok çıktılara odaklandık

Çevik ekibimiz için oyunun kurallarını değiştiren bir başka an da, işimize bir dizi çıktı olarak bakmayı bırakıp, çözülmesi gereken bir dizi problem olarak çalışmamızı düşünmeye başladığımız zamandı.

Ekibinizdeki bireysel katkıda bulunanları düşünün: geliştiriciler, metin yazarları, tasarımcılar ve diğer benzer uygulama rolleri. Neden yaptıkları konusunda ne sıklıkla "bu slaydı tasarlamaları" veya "bu e-kitabı yazmaları" çok az bağlamla isteniyor?

Ekibinizin projenin arkasındaki gerçek amacı anlamasına yardımcı olmadan yapılacaklar listesine bir görev atamak, ekibinizin kişisel yatırımı olmadan yetersiz çalışmaya yol açar.

@Evacjackson, ekibinizin amacı anlamasına yardımcı olmadan bir görev atamanın yetersiz çalışmaya yol açtığını söylüyor. Tweet İçin Tıklayın

Aslında, amaca yönelik çalışma eksikliğine sahip olmak, pazarlama taktiklerinizden daha fazlası üzerinde ciddi etkilere sahip olabilir. LinkedIn üyeleri arasında yapılan bir ankette, amaca yönelik işlerde bulunmayan katılımcıların% 60'ından fazlası, şirketlerini üç yıl veya daha kısa bir sürede terk etmeyi planladı.

3 yıl veya daha kısa sürede ayrılmayı planlayan amaca yönelik işlerde bulunmayanların% 60'ı araştırıldı. @LinkedIn @Imperative Tweet İçin Tıklayın

Ekibimizde, herhangi bir projeye önceden belirlenmiş bir çıktıyla başlamaya karşı güçlü bir kuralımız var. Kabul edelim, paydaşlar her zaman ne istediklerini bilmezler. Sorun çözme, daha iyi sonuçlar için işbirliğini geliştirmeye yardımcı olur.

Bunun yerine, her projeye, Agile geliştirme dünyasında düzenli olarak kullanıcı hikayeleri adı verilen bir formatı izleyen bir sorun bildirimi ile başlıyoruz. Bu format şuna benzer:

__________ olduğunda, bu ölçülebilir sonucu elde etmemiz için ________ istiyorum: ___________.

İşte varsayımsal bir projeden bu tür bir problem ifadesinin (veya kullanıcı hikayesinin) bir örneği:

Çevik Pazarlama Hataları_2

Her projenin sorun sahibi, ekibin o proje için hangi sorunları çözeceğini belirler. Örneğin, web sitesi belirli bir anahtar kelime için sıralamada değilse veya yaklaşan bir ticaret fuarı için mesajın güncellenmesi gerekiyorsa, site sahibi bunu bir sorun olarak görebilir. Sorun ne olursa olsun, sorun ifadesi asla bir çözüm içermez. Belirli bir soruna öncelik vermeye karar verdikten sonra, ekibimiz sorunu birlikte analiz eder ve nihayetinde bir sonraki sprintimizde uygulayabileceğimiz bir çözümün kapsamını belirler.

Ekip olarak bir sorunu çözmek, herkesin sonuçta pay sahibi olmasını sağlar.

Ek olarak, bu yaklaşım ekibi, gösterişli talepler yerine temel ihtiyaçları karşılayan bir çözüme ulaşmak için yüzey seviyesindeki sorunun arkasındaki sorunlu noktaları ortaya çıkarmaya zorlar.

Örneğin, satış ekibimiz bazı potansiyel müşterilerin planlanan demo toplantılarına gelmediğini ve yeniden planlama taleplerine yanıt vermediğini bildirdi. Satış başkan yardımcımız, pazarlama ekibinden, aylar sürecek olsa bile toplantıları için en iyi olasılıkları artıracak animasyonlu bir açıklayıcı video oluşturmalarını istedi.

Satış süreciyle ilgili bazı sorular sorduktan sonra, satış ekibinin temel sorunlarının demo toplantısından önce geliştirilmiş e-posta mesajlarıyla çözülebileceğini fark ettik. Bir toplantı planlanır yapılmaz tetiklenen üç e-posta damla kampanyası başlattık. Bu çözümü oluşturmak, ekibin yalnızca iki gününü aldı. Bu kampanyayı oluşturduğumuzdan beri, toplantıları yeniden planlaması gereken kişi sayısını yarıdan fazla azalttık.

Bir ekip üyesine bir görev atamadan önce, kendinize bu işin neden önemli olduğunu sorun. Bir sorun bildirimi oluşturarak ve bir çözüm üzerinde işbirliği yaparak, ekibimize kazanç sağlayan hızlı bir düzeltme belirledik. Animasyonlu bir video oluşturmuş olsaydık, satış ekibi düzeltmemizi beklerken aylardır aynı sorunla uğraşabilirdi.

Hata 4: Önceliklendirmek yerine tıkıştık (ve hepsini halledecekmişiz gibi yaptık)

Her Çevik pazarlama sprintine bizim yaptığımız gibi mümkün olduğunca sığmaya çalışırsanız, yanlış yapıyorsunuz demektir.

Paylaşılan bir öncelik duygusu olmadan, zamanınızı nereye odaklayacağınız konusunda hiçbir fikriniz yok. Ve odaklanma olmadan, her şeye evet demeye başvurursunuz. Ve her şeye evet dediğinizde ve projeleriniz için sorunlu sahipleriniz olmadığında, kendinizi çok sayıda yarı bitmiş ürünle dolu stresli bir çeyreğin ortasında bulursunuz.

Birçok Agile takımı, bir takım olarak işe öncelik vermek ve hızı artırmak için tahmin kullanır. Bir projenin gerektireceği çaba miktarını tahmin ederler veya bireylerin görevlerini tamamlamasının kaç saat alabileceğini tartışırlar. Zamanla, birçok Agile takımı sprint başına ortalama çıktı hissine ulaşır ve bu da yeni görevleri planlamalarına yardımcı olur.

Agile ekibi olarak ilk aylarımızda, bu tür bir tahmin yapmaya başladık. Maalesef, her şeyi halledebileceğimizi göstermek için tahminlerimizi manipüle ettik. Bir projenin ne kadar çalışma gerektireceğini tahmin ettik ve ardından diğer üç istek için yer açmak için gereksinimleri pazarlık ettik. Sonunda, amansız bir stres ortamını sürdürerek işi tahmin etmenin değerini yadsıyorduk.

Hız takip etmek için iki veya üç yöntem denedik (işi tahmin etmenin yaygın bir yolu olan planlama pokeri dahil). Tahmin etmeyi, daha verimli bir ekip olmanın bir yolu olarak değil, çok sayıda işi bitirebileceğimizi kanıtlamanın bir yolu olarak kullanmaya odaklandık. BU bizim hatamızdı.

Kısa süre önce, ürün ekibimiz için Agile sürecini yöneten şirketimizin mühendislik müdürü ile bir sohbet yaptım. Ekibimizin hiçbir zaman tahmin konusunda ustalaşmadığını söylediğimde şunu söyledi:

Paydaşlarınız sürekli olarak ekibinizden hız raporları veya iyileştirilmiş tahminler istiyorlarsa, muhtemelen ekibinizin kendilerine zamanında iş teslim etme yeteneğini bozan daha büyük süreç sorunları yaşıyorsunuzdur.

#AgileMarketing hızıyla veya genel proje teslimi ile ilgili bir sorununuz mu var? @evacjackson Tweet İçin Tıklayın

İyi işleyen Agile ekibiniz düzenli olarak bir projenin hızlı yinelemelerini sunduğunda ve son teslim tarihi makul olmadığında paydaşlara endişeleri işaret ettiğinde, doğal olarak ekibinizdeki çıktı veya üretkenlikle ilgili sorulardan kaçınırsınız. Proje yöneticisi veya scrum yöneticisi, iş geride kaldığında bu değişiklikleri düzeltmek ve iletmekle sorumludur.

Bir sonraki sprintinizde sadece bir veya iki yeni projeye (veya problemlere veya hikayelere) öncelik vermekten korkmayın çünkü mevcut sprintinizde birkaç kalan projeniz var. Sadece kalan çalışmayı paydaşa zamanında ilettiğinizden ve projeyi mümkün olan en kısa sürede bitirmek için planlarınızı paylaştığınızdan emin olun.

Ve neye öncelik verilmesi gerektiğine dair nihai kararı vermesi için bir lider belirlemekten korkmayın. Örneğin ekibimiz, pazarlama başkan yardımcımız dışında tüm kişilerin Trello kartlarını "öncelikli" sprint sütununa taşımasını yasakladı. Bu, tüm işi en iyi şekilde gören kişiye öncelik verme sorumluluğunu yükledi.

Sonuç

Ekibimiz, her Agile ekibi gibi, Agile ilkelerini bizim için işe yarayacak şekilde uyarlamaktadır. Ekibiniz Agile yaklaşımı ne olursa olsun, yalnızca süreçle ilgili açık geri bildirim için fırsatlar sağlarsanız ve iş akışınızı düzenli olarak değiştirecek kadar esnekseniz işe yarar. Şu ana kadar Agile yaklaşımımızda yaptığımız her ince ayarın bir günlüğüne sahip olsaydım, bu gönderiden daha uzun olurdu.

Çevik süreçleri uygularken ekipleriniz ne gibi hatalar yaptı? Bu hataları nasıl ele aldınız? Bir yorumda bize bildirin.

İçerik pazarlamasının etkinliği için yapınızı geliştirmek mi istiyorsunuz? Baş içerik danışmanı Robert Rose'un özel analizlerini içeren haftalık Pazarlamacılar için İçerik Stratejisi haber bültenimize kaydolun. Tanıştığımız diğer birçok pazarlamacı gibiyseniz, her Cumartesi onun düşüncelerini dört gözle bekleyeceksiniz.

Kapak resmi Joseph Kalinowski / Content Marketing Institute