8 Strategi proses tangkas untuk tim pemasaran yang ramping

Kami adalah pecinta teknologi yang antusias, kami bekerja dari jarak jauh dan kami membangun aplikasi kami sendiri (termasuk Turbine, aplikasi HR dan Fizz+Ginger, aplikasi SEO teknis untuk pengguna HubSpot). Kami bekerja untuk perusahaan teknologi termasuk Microsoft, Symantec, LinkedIn, dan HP dan kami berasal dari latar belakang pengembangan perangkat lunak (CEO kami menjalankan perusahaan game komputer selama sepuluh tahun).

Jadi Anda berharap kami memiliki lebih banyak pendekatan teknik untuk pemasaran, bahkan jika sebagian besar dari kami adalah 'kreatif'. Dan, faktanya, metodologi agile menginspirasi banyak praktik kerja kami.

Kami membagikannya di sini untuk menunjukkan bahwa orang pemasaran dan inovator teknologi dapat berbicara dalam bahasa yang sama. Kami percaya bahwa Anda dapat menjalankan pemasaran sebagai aktivitas yang ramping dan hemat biaya DAN meminjam praktik terbaik yang gesit dari rekayasa perangkat lunak untuk membuatnya bekerja secara efisien. Begini cara kami melihatnya.

Konten ini awalnya tersedia sebagai bagian dari ebook kami 'Pemasaran hemat biaya untuk perusahaan B2B yang ambisius' (dari hal.21). Dengan demikian, Anda memiliki opsi untuk mengunduh materi asli sebagai PDF jika Anda mengisi formulir ini:

1. Pengeditan rekan

Pemrogram yang menggunakan metode tangkas sering bekerja berpasangan, baik mengkodekan bersama atau membalik kode bolak-balik antara keduanya untuk peer review. Ini kebalikan dari gambaran biasa tentang programmer heroik yang membakar minyak tengah malam, tetapi berhasil. Ini meningkatkan kualitas dan produktivitas kode.

Di Articulate, kami menugaskan tim untuk setiap tugas menulis. Biasanya, satu orang akan menulis dan orang kedua akan mengedit. Mereka mungkin bolak-balik beberapa kali. Seringkali, kami merotasi peran pada kampanye yang sama untuk salinan yang berbeda. Akhir-akhir ini, kami mempekerjakan seorang Pemimpin Redaksi untuk menjaga kami juga.

2. Pemasaran yang digerakkan oleh tes

Dengan pengembangan yang gesit, setiap perubahan yang Anda lakukan pada kode dicocokkan dengan pembaruan pada perangkat lunak pengujian otomatis untuk memastikan bahwa perubahan tidak merusak apa yang sudah berfungsi.

Dalam pemasaran, khususnya pemasaran online, hampir semuanya (dan harus) dapat diuji. Apakah halaman ini mendapatkan lebih banyak konversi daripada halaman itu? Apakah CTA ini lebih baik? Dan seterusnya. Ini memberi kami gambaran yang jelas tentang apa yang terbaik untuk memaksimalkan ROI.

Tetapi gagasan pengujian regresi juga berarti bahwa apa yang berhasil hari ini perlu terus diuji untuk memastikannya masih berfungsi besok.

3. Tidak ada crunch, tidak ada burnout

Pengembang yang berpikiran gesit tidak melakukan sit-up. Tidak ada kafein dan bahan bakar pizza sepanjang malam. Sebaliknya, mereka merencanakan pekerjaan mereka di sekitar 40 jam kerja seminggu yang dapat dikelola tetapi terfokus.

Pemasar harus melakukan hal yang sama, meskipun itu berarti mengatakan 'tidak' untuk pekerjaan yang terburu-buru. Seperti yang mereka katakan di Texas, 'kurangnya perencanaan di pihak Anda bukan merupakan keadaan darurat di pihak saya.' Lagi pula, pekerjaan yang terburu-buru seringkali merupakan pekerjaan yang ceroboh.

Lebih baik mengumpulkan data dan secara iteratif merevisi rencana Anda berdasarkan apa yang Anda pelajari. Kami menyadari bahwa kami tidak dapat melakukannya dengan benar setiap saat, tetapi kami berusaha untuk melakukannya.

4. Cerita pengguna, bukan spesifikasi

Pengembangan tangkas tidak berurusan dengan metode formal, spesifikasi terperinci, atau cara lain apa pun yang coba dilakukan oleh manajer proyek untuk melindungi diri dari keinginan klien. (Lihat Kamus Pemasaran Setan untuk informasi lebih lanjut.)

Sebaliknya, ia meminta pelanggan dan pengembang untuk berkolaborasi dalam menggambarkan hasil yang diinginkan. Formatnya sederhana, cerita pendek pengguna – misalnya: 'pengguna dapat membuat akun baru' atau 'Sebagai X, saya ingin Y karena manfaat Z'. Semakin spesifik kisah-kisah ini, semakin baik. Pemasar dapat mengambil pendekatan serupa, menentukan keluaran, seperti gaya atau topik artikel, daripada masukan seperti jumlah jam yang diperlukan untuk menulisnya. (Inilah yang kami lakukan. Tidak ada lembar waktu di Articulate!) Kolaborasi dengan klien kami adalah sesuatu yang sangat kami hargai – ini menghasilkan keluaran yang lebih baik dan lebih berharga.

Juga, daftar periksa pengarahan proyek kami berfokus pada tujuan bisnis dan audiens (kata kami untuk 'pengguna') daripada spesifikasi terperinci.

5. Hitung kesulitannya, jangan perkirakan durasinya

Anda mungkin menggunakan Jira atau ClickUp atau sesuatu untuk manajemen proyek. Alat manajemen proyek ini menghindari metodologi air terjun biasa dan lembar waktu. Alih-alih meminta pengembang untuk menentukan berapa lama 'cerita' akan berlangsung, alat manajemen proyek yang gesit menanyakan seberapa rumit dan seberapa penting itu relatif terhadap tugas lain.

Seiring waktu, mereka melacak berapa lama Anda menyelesaikan berbagai jenis tugas, dan setelah beberapa saat mereka dapat memprediksi kapan Anda akan menyelesaikan berbagai tugas yang akan datang. Di Articulate, misalnya, kami cenderung menggunakan panjang kata sebagai proksi kerumitan dalam hal penulisan konten, dengan beberapa peringatan terutama untuk bagian teknis. Kami menggunakan poin untuk memperkirakan upaya, waktu, biaya, dan sebagainya.

6. Rapat 'berdiri'

Alih-alih rapat status dan panggilan konferensi yang tak berkesudahan, pengembang yang gesit mengadakan rapat 'berdiri' di awal minggu (atau hari) untuk berbagi informasi. Kami melakukan hal yang sama (hampir, kami bekerja dari jarak jauh). Dan, seperti namanya, jika orang berdiri, mereka cenderung tidak banyak bicara!

7. Harapkan perubahan, jangan melawannya

Sebagian besar proyek perangkat lunak melibatkan spesifikasi terperinci yang ditetapkan setelah pengembangan dimulai. Masalah dengan pendekatan semacam itu adalah keadaan berubah, dan, seringkali, pelanggan tidak tahu apa yang cocok untuk mereka sampai mereka melihatnya dalam kode.

Pengembangan tangkas mendorong keterlibatan klien dan mengasumsikan bahwa proyek akan berubah seiring waktu. Dengan memecahnya menjadi sprint pendek (lihat poin berikutnya) dan peluru kecil yang terdefinisi dengan baik, proyek tangkas menjadi lebih fleksibel.

Secara umum, kami menggunakan pendekatan ini di Articulate, mengizinkan dan mengharapkan klien untuk memberikan umpan balik bahkan melalui beberapa revisi. Umpan balik dan penulisan ulang bisa membuat frustrasi, tentu saja. Tetapi mengharapkan mereka, bahkan merangkul mereka, membantu kami melakukan pekerjaan yang lebih baik untuk klien kami. Dengan alasan.

8. Sprint, bukan maraton

Pengembangan tangkas bertujuan untuk 'produk layak minimum' sejak awal, dan peningkatan bertahap kecil dari waktu ke waktu. Itu menghindari proyek epik dan pawai kematian yang melanda generasi pengembangan perangkat lunak sebelumnya.

Proyek pemasaran harus sama: situs web Anda tidak pernah benar-benar selesai tetapi tidak perlu waktu ribuan tahun untuk membuatnya. Demikian pula, penjangkauan pemasaran saluran Anda adalah proyek yang berkelanjutan — bukan tugas satu kali untuk magang.

Agensi pemasaran, seperti setiap bisnis lainnya, tidak boleh berpuas diri, tetapi inovasi itu sulit. Belajar dari bidang lain dan menerjemahkan pelajaran tersebut ke bisnis kita sendiri adalah strategi yang cerdas dan hemat biaya — dan itu bisa sangat bermanfaat, menurut kami!

Jadi, tim pemasaran, berhati-hatilah. Anda tidak harus menjadi insinyur perangkat lunak atau master Yogi untuk menjadi gesit.