Как стать автором
Обновить
170.26
JUG Ru Group
Конференции для Senior-разработчиков

«Когда ты рассказываешь правдивую историю, ей верят гораздо больше» — Интервью с Олегом Шелаевым, часть 2

Время на прочтение 20 мин
Количество просмотров 3.7K


Несколько месяцев назад мы встретились с Олегом Шелаевым, Developer Advocate компании ZeroTurnaround (далее — ZT). С тех пор Олег успел стать Java Champion (поздравляем!) и… покинуть ZT. Да, если откладывать интервью в долгий ящик, с героем может случиться разное.

Интервью получилось длинным, поэтому я разбил его на две части. Первую часть я опубликовал на хабре ещё в декабре, а сейчас пришло время для второй части. В ней мы поговорили:

  • о гипотезах и их проверке;
  • о блоге RebelLabs;
  • о разнице между продуктами и услугами;
  • о профилировщике XRebel;
  • о конференции GeekOUT и проекте VirtualJUG;
  • о простых и сложных цепочках в маркетинге.

Вот видео:


Для тех, кто предпочитает читать, а не слушать, ниже — полная расшифровка нашего с Олегом разговора. Приятного вам просмотра или прочтения.



Пробовать и думать


— Как говорил кто-то из великих (Джон Уонамейкер — прим. авт.) : «Половина моего рекламного бюджета тратится впустую, проблема в том, что я не знаю, какая именно половина».

— Это очень сложно. Например, я пишу пост для нашего блога. Может быть, я должен писать больше постов, может быть, нам не нужно делать занимающих много времени отчетов.

— Может, нужно видео снимать, а не посты делать?

— Это очень сложно понять. Самое главное, когда ты просто попробуешь, ты думаешь: «Сейчас я запишу видео, и, основываясь на количестве просмотров и кликов на ссылку на страницу продукта, я буду знать, делать мне видео или нет». Таким образом ты эти данные не получишь. Тебе эти видео нужно делать регулярно, в течение какого-то времени, уже только потом ты сможешь посмотреть и сказать, что у тебя выросли трафик, конверсии между страницей с видео и страницей продукта, теперь оно работает, но вначале ты этого точно сказать не можешь, так как там влияет очень много факторов. Скорее всего то, что ты стал делать обучающие видео, тебе помогает, но ты не знаешь наверняка. Единственный способ узнать точно, сколько денег тебе принесла какая-то инициатива, вроде обучающих видео, — это прекратить это делать и посмотреть, сколько денег до тебя не дойдёт.

— Мы живём не в замкнутом пространстве, мы живём в системе, в которой очень много внешнего шума. Эффект, который ты увидишь от прекращения чего-то — падение/рост каких-то продаж, в большинстве случаев нивелируется другими воздействиями — землетрясением, чемпионатом мира по футболу, чем-нибудь ещё.

— Конечно. Но когда ты начинаешь что-то делать, у тебя этот эффект шума будет гораздо более заметен. Ты начал что-то делать, ты не понимаешь, правильно это или нет. Когда ты заканчиваешь что-то делать, ты можешь чётко осознать: мы показываем рекламные баннеры на сайте или ещё где-то, за это мы компаниям, которые это предоставляют, платим деньги. Больше денег — больше показов рекламы, больше трафик, больше покупок. Меньше денег — меньше всего остального.

— Там есть сложные вещи. Есть latency — длина цикла сделки: сколько времени прошло от того момента, как будущий клиент прочитал пост или увидел рекламу до продажи. И если я сейчас выключил рекламу, перестал писать посты, ещё непонятно, когда я увижу этот результат. Мне для этого всё равно нужны всякие метрики, вроде средней длины цикла сделки. Это всё считается?

— Все метрики, относящиеся к сделкам и продажам, считаются. Нельзя посчитать, сколько проходит времени с того момента, как я прочитал пост, до момента, когда моя компания купила мне лицензию. А вот метрики трафика очень простые. Я сам слежу за ними, так как курирую наш блог, стараюсь следить за трафиком, в основном использую банальный Google Analytics и немного Webmaster Tools для понимания, какой трафик куда приходит, ключевых слов, что люди ищут, какой у нас ранг в Google на какие-то запросы. Дальше это не конвертируется.

С точки зрения маркетинга мы считаем какие-то метрики, часть сделок связывается со сделками в отделе продаж, но в основном это всё берётся на веру. У нас есть свои метрики. Мы знаем, что когда трафик растёт, то это хорошо, мы молодцы. В принципе, это сильно перекликается с миссией «awareness» — «узнаваемость бренда» и то, как много людей нас посетило. Когда на наш сайт заходит мало людей — это не очень хорошо. Напрямую усилиями наших Developer Advocate мы не продаём. Мы подчиняемся маркетологам. Во многих компаниях команды Developer Advocacy работают бок-о-бок с командами продуктов, с теми людьми, которые говорят: «Сейчас мы будем делать фичу Х».

— Это ты про JetBrains, где есть PMM (Product Marketing Manager), или нет?

— Это про JetBrains, это про компании, которые предоставляют платформы, облако или ещё что-то.

— То есть это транслирует человек, глубоко инкорпорированный в продукт, который просто знает, чем живёт команда разработчиков.

— И у них метрики и ключевые показатели могут быть прямо встроены в развитие продукта и идти вместе с командой разработки. Например, вовремя рассказать про все новые фичи. Команда разработчиков выкатила новую фичу Х. Продукт-менеджмент сказал, что нам нужна эта фича Х, команда Developer Advocacy рассказала всем про эту фичу Х. Если через 5 месяцев фичей Х не пользуются 50% наших клиентов, то виноваты все. И там команда Developer Advocacy в основном работает именно как помощь продукту, в коммуникациях и в понятиях. И у них метрики общие. У нас метрики немножко объединены с маркетинговыми, но не с отделом продаж.

— Есть же известная шутка: «Вы маркетинговая команда, получаете деньги за входящие звонки. Скажите, сколько вы имеете с каждого такого звонка, платите 30% от этой суммы нам, и мы будем вам звонить по нужному номеру в нужных объемах».

— Практически любая метрика, которая не привязана прямо к деньгам или к каким-то осязаемым вещам, достаточно обманчива. Например, я пишу посты для блога. Я бы хотел писать технически грамотные, глубокие посты про интересные вещи для Х тысячи людей. Например, как написать Java-агента и value types с новыми байт-код инструкциями, прям что-то глубокое. Классно? Офигеный же пост.

— Я бы прочитал с удовольствием.
— Прочитает этот пост, скажем, миллион пользователей, и принесёт он мне 100 тысяч на сайт. Это здорово, я молодец. Если я напишу пост про то, как в Hibernate подключить ID generation strategy, sequence, на стороне Java или нет, ко мне придёт десять миллионов человек. Если у меня метрика — это просто трафик и какая-то узнаваемость бренда, то трафик генерить нужно таким образом, чтобы больше ориентироваться на Junior-программистов, описывать какие-то интересные им проблемы.

— С точки зрения воронки продаж есть охват и захват. Это — охват.

— А с точки зрения захвата, даже если я буду писать очень интересные посты про какие-то низкоуровневые штуки, которые интересны более опытным разработчикам, сколько таких постов мне надо? Сколько таких разработчиков ещё не знают про наши продукты? Сколько таких разработчиков узнают про них и заинтересуются? В конце концов, нужно ли их писать так часто, как мне было бы интересно их писать? Писать какие-то банальные шутки не интересно.

— Да и читать такое тоже никому не интересно.

— Нет, читать интересно. Люди погуглят и придут, вон, на Stack Overflow. Там много, ты знаешь, очень глубоких и интересных вопросов.

— Ну они, скорее, какие-то частные задачи решают.

— У них процентов пятнадцать трафика — это «Как выйти из Vim»! Они недавно публиковали свою статистику, и это большая цифра. Писать про это не очень интересно, про это сложно писать, и не совсем понятно, зачем. С другой стороны, ты получаешь вот такие метрики трафика.

О RebelLabs


— Ты уже несколько лет пишешь посты для вашего блога RebelLabs. Не надоело ли тебе?

— Перед тем, как написать пост, мне нужно изучить какой-то предмет. С бухты-барахты это не совсем разумно писать, потому что это не будет интересно никому. Там должен быть какой-то смысл. Чтобы люди узнавали что-то новое. Сложно писать регулярно. Это профессия. Сколько мы знаем писателей? Каждый в душе — писатель, но успешных писателей не очень много. Это тяжело. Играть метриками гораздо проще, но какой смысл это несёт — не очень понятно.

В каких-то других компаниях, где продукт легче отслеживать, ты знаешь, кто туда логинится, откуда, какие вещи они используют. Клиенты приходят к тебе на серверы и что-то там делают. Это немного проще связать в цепочку. У тебя есть разрыв между виртуальным миром, где они сидят, и физическим миром, где они пробуют твои продукты и что-то делают, потом это снова виртуальный мир, где ты с ними общаешься, и снова физический, они сидят за файерволом и не шлют тебе никакую информацию — тут происходит разрыв, и смотреть гораздо сложнее.

Ты спрашивал, какие метрики мы мониторим — это трафик, здесь мне интересно, в основном, какую часть нашего трафика составляют органические посетители, я смотрю, какие посты в последнее время набирали хороший трафик и понимаю, в каком посте было что-то, что привлекает людей, могу вернуться, подправить его текст. Скажем, во введении написать более чётко, о чём он, поправить SEO-трюки. Ну, не трюки, там просто нужно написать чётко и понятно, чтобы даже Google-робот понял, о чём этот пост и какая в нём польза.

— Очень интересно Яндекс на эту тему рассказывал: если десять лет назад были популярны SEO и другие трюки для оптимизации поиска, то сейчас они рекомендуют писать контент на сайте максимально чётко, как есть, а их поисковые машины уже сами разберутся.

— И они очень хорошо разбираются. Но мой опыт подсказывает, что, если посмотреть на данные, там тоже есть искажение. Если ко мне на какую-то конкретную страницу приходят по запросу веб-фреймворка и не заходят по запросу Java-фреймворка, то у меня не будет этой информации в метриках. Я могу улучшить какие-то существующие, но это достаточно сложно сделать с нуля. Про то, что говорит Яндекс и другие подобные компании — «пишите, как есть, не надо выдумывать», скорее всего они говорят про то, что, если вы хотите захватить какой-то сегмент, вам не нужно начинать с выдумывания ключевых слов, создания искусственного текста, чтобы привлечь посетителей. Напишите хороший пост, в котором будет понятно, что и как, какую пользу получает читатель. И когда туда придут пользователи, когда пост станет популярным, когда на него посыпятся ссылки, тогда робот сам разберётся, насколько это хороший пост и куда его поставить.

Первое место в Google конвертируется очень хорошо. Если ты по какому-то запросу сидишь на первой позиции, это очень хорошо видно: impression — сколько раз показывается, клик — сколько раз на него ткнули, и у тебя будет 60% кликов от impression (click through ratio). Если ты на пятой позиции, то у тебя будет 13%, что уже очень большая разница. Но, с другой стороны, ты знаешь, что написал хороший контент и хочешь, чтобы тебя больше кликали. И ты смотришь, а там на первой позиции сидит сайт Coca-Cola. И ты просто не сможешь победить этот сайт. Или Википедия. Против Википедии не попрёшь. Там есть свои лимиты. Ты можешь играть с этими метриками, но это всё опять будет упираться в то, пишешь ли ты хороший контент, делаешь ли ты полезную работу не просто для себя — как ты шутку рассказал, люди будут звонить на номер и оставлять свои данные, и ты будешь генерировать, у тебя будет lead generation выше крыши. А работает ли это?

— Общаетесь ли вы с другими продуктовыми или интернет-компаниями на предмет того, как у кого работает отдел продаж, маркетинг, у кого какие модели продаж сверху и снизу? Или вы просто стараетесь больше читать об этом? Скажем, ваши инвесторы говорят: здесь так, а здесь вот так, а пообщайтесь с теми, с этими. Или это больше гуглёж?

— Я думаю, на тех уровнях, где это имеет смысл, инвесторы, конечно, помогают. Лично мне несколько сложно судить, поскольку я — рядовой Developer Advocate.

— У некоторых наших друзей, например, у Hazelcast, JFrog и так далее, уровень того, что происходит, модели того, как это всё происходит — они похожи на ваш? Насколько у вас типичная для этой среды модель?

— Я думаю, достаточно типичная. В какой-то момент практически все компании, которые производят ПО, стали переходить с лицензий и коробок продукта на подписку. В какой-то момент JetBrains перешли на subscription-модель, мы это сделали немножко раньше, чем они, но они молодцы, у них была очень простая концепция того, что они хотели сделать: упростить свои расходы на операции и логистику внутри, сделать проще. Они это упростили, и мы тоже — в какой-то момент наши продукты продавали, скажем, по полгода. Это не очень прикольно. У тебя есть какое-то время на заключение сделки, а потом становится непонятно, какие клиенты у тебя на полгода, какие — на год. Когда у тебя всё идёт за один год, это всё становится проще, у тебя повышается предсказуемость, поэтому мы перестали продавать по полгода.

О продуктах и услугах


— А мне кажется, здесь вот какой важный момент — извини, что перебил — компания была продуктовой и продавала какой-то продукт, скажем, JRebel, IntelliJ IDEA, а сейчас это больше похоже на сервисную модель: мы продаём не конкретный продукт, а мы продаём некий сервис, который будет ваш бизнес в течение такого-то времени обеспечивать некоторой функцией. Скажем, вы в вашей компании сможете перезагружать классы на лету, не перезапуская сервер. И мы предоставляем уже не JRebel, а некий сервис.

Тебе не кажется, что произошёл какой-то такой переход? Ведь есть продуктовые и сервисные компании. Продукт — это какая-то шутка, которую можно взять, потрогать, ткнуть пальцем. А сервис (услугу) клиент проживает.


— С одной стороны, да. Но так не совсем правильно говорить. Мы себя позиционируем как продуктовая компания, это не сервис. Грубо говоря, мы продаём байты, которые составляют лицензию.

— Это с точки зрения доставки до клиента.

— Но это именно то, что приходит, всё остальное они сами скачивают, там всё самостоятельно запускается. С точки зрения функциональности сервиса, о котором ты говорил, — сервис, который мы продаём — это то, что наш продукт запускается. Без лицензии он просто не запускается. Говорят, что ты продаёшь не свой продукт, а видение того, каким классным будет твой клиент, когда он будет этот продукт использовать. Да, мы продаём этот Experience. Например, у JRebel это перезагрузка классов на лету, то, как программист будет более продуктивен, будет меньше отвлекаться и, соответственно, экономить тебе время и деньги. Клиенты это покупают, используют, они довольны, потому что это так и есть. Это пример хорошего маркетинга, когда ты рассказываешь правдивую историю, и ей верят гораздо больше. Но называть это сервисом было бы немного неправильно.

— Это похоже на некую смешанную модель. С точки зрения лицензирования она явно как сервис работает.

— С точки зрения лицензирования — это просто годовая подписка. Предоставляем ли мы какой-то сервис и есть ли у нас какие-то затраты? Запускаем ли мы своё облако где-то в гараже и на эти компьютеры что-то приходит? Нет!

— Ну это уже другой сервис, ты ещё только ресурсы продаёшь.

— Наши продукты — они в коробках.

— Тогда такой вопрос. Когда меня учили маркетингу, мне объясняли, что есть несколько обязательных моментов, которые должны быть у B2B-продаж. Например, люди должны понимать, что они покупают. С этой точки зрения вы проводите большую информационную работу. Ещё, вы должны уметь отвечать на вопрос, чем ваша технология отличается от конкурирующих, например, от Hot Swap. Кстати, для JRebel, кто ваши конкуренты, кроме Hot Swap?

— Есть какие-то фреймворки со встроенной способностью себя перезагружать. Это началось достаточно давно. Был агент Spring Loaded, потом были Tapestry 5, фреймворк Play, который всё релоадил. У них у всех есть какие-то свои недостатки.

— Play пошёл по модели Ruby on Rails, я так понимаю.

— В основном происходит просто функциональная замена всего приложения и деинициализация. Основной их недостаток — это то, что они заточены под какую-то одну конкретную платформу. «Используйте нашу технологию, и тогда у вас всё будет работать». Самый большой непрямой конкурент JRebel — это, конечно, test-driven development.

— Не продукт, а подход!

— Да. Как раз большинство отказов объясняется использованием TDD, люди делают тесты вперед.

— То есть, грубо говоря, ваша война за души разработчиков ведётся с Кентом Беком и Мартином Фаулером, а не с Oracle, IBM и так далее.

— Это не совсем война. Это очень непростой технологический продукт, его сложно сделать, мы его писали десять лет. Если ты соберёшь тысячу программистов, они, может, напишут это за год. Так, конечно, не работает. Но это надо поддерживать, иметь какую-то экспертизу, это надо прожить, чтобы знать, как это работает.

Это всё очень сложно, поэтому прямых конкурентов у нас нет. Команды, которые пытались это сделать, — чаще просто отмирают, потому что это сложно. Казалось бы, можно было встроить в JVM такую функциональность, но это не так просто и не очень кому-то нужно. И все фреймворки, которые это делают, у них очень много фокуса уходит на продакшн, потому что им там нужно быть молодцами. Соответственно, на разработку фокус идёт уже меньше.

— То есть порог входа — это первое, что помогает. Второе — это ниша, что JRebel работает не в продакшене, а на этапе разработки. Тут сознательное заужение области применения. Мол, мы не про всё, у нас вот такая специализация.

— Для разработки у нас очень много экспертизы именно в специализации: что мы можем делать, как мы можем делать, сколько у нас свобод на машине разработчика. Менять на лету любые классы в продакшене — это риски в безопасности: придут специально обученные люди и дадут тебе по рукам.

— Ты очень интересно ответил на вопрос о ваших конкурентах, о TDD. TDD находится в вашем предметном поле, но это не продукт, это больше функция — «сначала пишите тесты». Вопрос, который задают потенциальные клиенты, если ответ на второй вопрос не очень уверенный, — о том, кто ваши конкуренты. Я приду в Hazelcast, мне правильно назовут GridGain и так далее. И когда возникнет вопрос о том, что функционал похожий, я их спрошу об их лучшей цене. Я попытаюсь понять: здесь Grid, тут Grid — что дешевле. В вашем случае, как я понимаю, нужно отвечать, что дешевле: использовать JRebel или использовать TDD. Но TDD — это тоже дорого, в некотором смысле. Пытались ли вы такого типа исследования сделать?

— Насколько это дорого?

— Ну, условно говоря, JRebel экономит вот тут и вот тут. TDD тоже экономит.

— У нас в этом плане очень хорошая позиция — у нас есть продукт, который хорошо работает и очень чётко привязан ко времени программиста. У тебя есть приложение, ты знаешь, что у тебя сервер стоит две минуты, ты хочешь его стартовать каждые 15 минут, ты что-то написал и хочешь посмотреть, работает это или нет — ты в час теряешь 8 минут. Это ты умножаешь на количество часов, количество разработчиков и получаешь какую-то цифру. Её очень легко сравнить с ценой JRebel. Ты смотришь и понимаешь, что JRebel стоит копейки по сравнению с зарплатами, которые надо платить программистам за то, что они пьют кофе раз в 15 минут.

— При работе без JRebel программист вынужден переключать контекст, отвлекаться от задачи.

— Да, ты запускаешь WebLogic, и у тебя есть пять минут, пока он запустится. Ты идёшь на Facebook, через два часа возвращаешься и пытаешься вспомнить, что же ты делал. Ах да, баг починил. Это время очень хорошо измеряется, как и его стоимость. Поэтому нам очень просто: когда мы даём trial, мы прямо говорим — вот здесь будут метрики, вот так сконфигурируйте и посмотрите, сколько денег вы экономите. Вот наш ROI. Есть другие продукты, в которых не такой явный процесс от использования продуктов до пользы, например, XRebel, где ты посмотрел и понял, что избежал каких-то проблем с перформансом. Эти проблемы дошли бы до продакшна, кто-то бы сказал, что тут медленно, пришлось бы вернуться — ты понимаешь, что это было бы очень долго и дорого, но ты не знаешь, сколько именно. К тому же, у XRebel немного другая проблема с конкурентами — там есть профайлеры, APM, ещё какие-то вещи.



О XRebel


— JRebel и конкуренция с TDD — понятно. Как обстоят дела с XRebel? Профилировщиков Java там, наверное, штук пять. Как вы с ними конкурируете?

— Напрямую. Когда мы начинали XRebel, мы прямо заявили, что это профайлер. Было немного сложно, потому что это новый продукт, есть матрица функциональности, есть какие-то ожидания от того, что он умеет делать. Профайлер должен тебе показывать таблицы горячих методов, что занимает время и не только. Когда ты делаешь что-то другое, ты должен объяснять, что ты — другой профайлер.

— Объяснять, что у других неправильный подход?

— Нет, что у тебя другой подход, который в каких-то ситуациях более полезен.

— То есть, XRebel — инструмент для поиска и устранения простых перформансных проблем?

— Или для менее опытных разработчиков, чтобы показать им какие-то большие проблемы. Мы заужаем спецификацию того, что мы делаем, и отсюда уже можно говорить о том, что делает наш продукт. Вообще, есть две большие стратегии, как выводить продукт на рынок. Или подстраиваешь маркетинг и отдел продаж под свой продукт или наоборот — подстраиваешь продукт под нужды рынка и под поведение, ожидаемое на рынке. То есть, берешь некоторый рынок, оцениваешь, насколько он большой, насколько легко его заполучить, сколько денег это принесёт, и делаешь запрос инженерам делать то-то и то-то.

Ты должен свести вместе рынок и свой продукт. Когда у тебя есть конкуренты, тут сложнее, потому что ты должен быть в какой-то степени как они, иначе клиенты не поймут, о чём речь. Если ты заявляешь о том, что хочешь быть в какой-то нише, то нужно этой нише соответствовать. С другой стороны, ты должен в нужной степени отличаться от них, чтобы говорить, почему клиенты должны выбрать наш продукт, а не конкурирующий.

Это гораздо более сложная проблема с точки зрения маркетинга, чем продавать JRebel, потому что, когда у тебя мало конкурентов и есть хороший продукт, тебе гораздо легче показать свою уникальность и объяснить, что ты нужен. С XRebel другая ситуация: люди им пользуются, люди довольны, люди продлевают свои лицензии на следующий год. Чтобы захватить больший кусок рынка, нам нужно каким-то образом играть с маркетингом, с той историей, которую мы рассказываем. И это тоже не очень просто. Если ты расскажешь историю, которая не соответствует действительности, какой бы классной она ни была, ты продашь продукт один раз, получишь какие-то деньги от клиента. Но если твоя история не проходит проверку практикой, то на второй раз ты от этого клиента уже ничего не получишь. Это путь в тупик. Поэтому для такого продукта, как XRebel, маркетинг играет гораздо более важную роль.

— Управление ожиданиями — это очень важный момент. Яков Файн, наш с тобой общий друг, всё время об этом говорит. Если ты сделаешь ожидания от продукта завышенными, его одноразово больше купят, но будет меньше повторных покупок. Если ты занизишь ожидания, скажешь, что ваш продукт особо ничего полезного клиенту не делает, то даже первых покупок будет мало. Как вы с этим играете? Как вы в этой ситуации находите для себя золотую середину?

— Достаточно просто — опираясь на данные от продаж. Точно так же, как идёт игра с ценообразованием. Мы знаем, сколько стоит один час работы разработчика. Мы представляем, какие проблемы с производительностью предотвращает XRebel. Мы знаем, что производительность — это важно, и клиенты признают, что, если их приложение — медленное, то клиенты их не любят, и это выливается в деньги.

Мы знаем, что это важно, что процесс релиза функциональности и исправления любых ошибок занимает две недели, у тебя один спринт, ты не можешь это быстрее делать. (Если можешь — молодец, тебе исправление выйдет уже дешевле). Мы примерно можем представить цену, можем ориентироваться на цены конкурентов и каким-то образом играть. XRebel стоит несколько сот долларов в год. Если ты продаёшь по этой цене, если ты в отзывах видишь «нет, мы не купим ваш продукт по этой цене, потому что они слишком высокая», то это проблема цены, и ты должен её снижать. Если ты не встречаешь таких проблем, это показывает, что рынок готов платить, просто твой продукт ещё не находится в той точке, где он выигрывает у конкуренции по функциональности.

— На любых пятерых потенциальных покупателей найдётся один, который скажет, что ему слишком дорого. Всегда, при любой цене, будут люди, которые будут говорить, что дорого, и будут люди, которым всё равно, сколько платить. Понятно, что находить в этом балансе оптимальную цену — довольно тяжёлое занятие.

— Это сложно. Цену ты не можешь менять каждую неделю. Это просто некорректно, даже невежливо. Это сложный процесс, как внешний — объяснить, что мы сейчас меняем цену, так и внутренний, где ты должен перестроить какие-то процессы в команде, потому что ты изменил цену. Но это нужно делать.

— Мне нравится ваша маркетинговая идея: рассказывать потенциальным клиентам о том, сколько времени вы им экономите, потому что это попытка рационального объяснения, почему оно столько стоит. Попытка прийти на рынок и сказать: вот здесь 500, а здесь 600, поэтому у нас цена ниже, чем у конкурентов — это попытка показать деньги, который сэкономит компания или команда от использования вашего продукта, а не продукта вашего конкурента.

— Это попытка объяснить ценность для клиента и описать видение того, что же на самом деле он покупает. Если клиенту не понравилось, он, конечно, может зааплоадить этот jar-файл нам обратно на сервер!

GeekOUT и VirtualJUG


— У вас есть ещё два интересных мне направления деятельности. Во-первых, это GeekOUT — прекрасная конференция в Таллине, я был на ней раза четыре, собираюсь снова приехать в начале июня. И всех наших зрителей приглашаю: хорошие и интересные спикеры. Второе — это виртуальная Java юзер-группа. Если я правильно понимаю, за эту юзер-группу вы получили Duke's Choice Award. Расскажи, кому принадлежала идея виртуального JUG'а, что это такое, с чем это едят. Мы тоже делаем Java User Group, поэтому мне очень интересно послушать.

— Virtual JUG — это виртуальная Java юзер-группа, она официальная и не принадлежит корпорации ZeroTurnaround. Это организация, сделанная на общественных началах. Идея появилась в 2013 году. У истоков стоял Simon Maple. Сейчас, оглядываясь назад, кажется очевидным, что было бы очень классно, если бы концепция юзер-группы с регулярными встречами и интересным контентом от спикеров производилась бы в онлайне. Тогда мы подумали, почему бы нам так и не сделать и не попробовать.

Технология достаточно простая, потому что сейчас видеоконференции легко делать. Мы используем банальный Hangouts, это всё автоматически транслируется на YouTube, и люди просто приходят и смотрят видео. У нас есть чат, где люди могут общаться. Самый большой бонус — у нас маленькие расходы на организацию спикеров даже мирового класса, потому что им не нужно никуда прилетать, они коннектятся из дома, рассказывают свой доклад, общаются с аудиторией, с нами, проводят встречу с минимальными затратами. Эта концепция очень понравилась людям, мы стали достаточно быстро расти. На Virtual JUG у нас примерно 11 тысяч сочувствующих — подписчиков meetup.com. Мы зарегистрировали VirtualJUG как официальный митап, люди туда «приходят», мы там вывешиваем расписание будущих докладов, они могут ответить. Это та база, где есть email-ы и список зарегистрированных людей. Не знаю, сколько у нас точно подписчиков на YouTube, это вторичная метрика.

— Как ZeroTurnaround интегрируется с VirtualJUG? Я видел какие-то варианты откручивания рекламы на YouTube, использование email-базы подписчиков, а также нативная реклама, когда внутри видео Саймон Мэйпл говорит о какой-нибудь новой фиче вашего продукта.

— ZeroTurnaround полностью спонсирует VirtualJUG, мы организовываем его на время ZT.

— То есть часть твоего рабочего времени — это Virtual JUG?

— Да, это поддержка и организация Virtual JUG и участие в этом комьюнити. Мы не вставляем рекламу в видео, в начале доклада говорим, что спонсор — ZeroTurnaround, мы их благодарим, у них есть основные продукты для Java-разработчиков, если вы их посмотрите — всем будет хорошо, если вам понравится — здорово. Мы не используем список участников для промоушена нашего контента.

— Понятно. Но наверняка ваши sales требуют у вас список email-ов?

— Конечно. Есть шутка о том, как работает агрессивный эстонский продавец: он приходит утром в офис, садится и начинает агрессивно ждать звонка, чтобы совершить сделку. ZT начинал как маленькая компания, мы очень тесно связаны с комьюнити. Для того, чтобы быть успешным в индустрии в целом, у нас должно быть большое комьюнити, где люди рады учиться, работать, узнавать что-то новое и обмениваться знаниями. Мы с удовольствием это поддерживаем. VirtualJUG — это отдельная организация, которая спонсируется ZT, мы не используем список её участников при решении sales-задач ZeroTurnaround.

— Сейчас нужно заключать соглашение с клиентом о том, кто и в каких целях будет использовать его персональные данные. В России это очень актуальная тема.

— Я даже не знаю, можем ли мы технически список участников c meetup.com скачать в Excel и положить в Marketo. Мы можем им писать email-ы, периодически это делаем, когда ZT проводит вебинары, например.

— Можно более аккуратно общаться с аудиторией: скажем, вон, смотрите, на RebelLabs вышла интересная статья вот этого спикера, который был у нас два месяца назад. Такого типа вещи.

— Или, например, когда мы делали некоторый обзор индустрии и высылали опрос участникам Virtual JUG, попросили ответить, потому что знаем, что это — целевая аудитория, и им будет интересно. Когда мы его сделаем, мы им тоже пошлём готовый репорт. Но прямой монетизации нет.

О простых и сложных цепочках в маркетинге


— Последний вопрос. Вот есть простые механизмы маркетинга, например, в Virtual JUG написать про свой новый продукт или про суперскидку для пользователя. То есть, какая-то простая встроенная реклама. И есть второй, сложный, путь: например, прошёл Virtual JUG, через два месяца этот спикер выпустил статью на RebelLabs, вы сделали рассылку, что, если кто пропустил, можете прочитать на RebelLabs, люди дальше подписываются на RebelLabs, идёт рассылка сети и так далее.

Сложная коммуникация против простой. На твой взгляд: стоит ли выстраивание этих сложных цепочек тех усилий, которые вы на них тратите? Просто у компании всегда есть большой соблазн скатиться в прямую продажу, простую, как топор. Помогает ли построение сложных механизмов в маркетинге?


— По моему опыту, не очень помогает. Да, теоретически, это звучит очень хорошо. У нас есть Journey из шести шагов:
  • известный спикер делает сессию на Virtual JUG. Люди хотят посмотреть и регистрируются;
  • большинство зарегистрированных смотрят доклад;
  • некоторые потом идут на RebelLabs, где мы напишем пост про этот доклад;
  • кое-кто его даже прочитает;
  • выжившие — кликнут дальше на пост по JRebel;
  • наконец кликнут на продуктовую страницу и
  • оттуда наконец скачают продукт;

К сожалению, ситуация такова, даже при том, что в Virtual JUG — 11000 человек, что кажется достаточно большим числом. На самом деле, если смотреть в рамках воронки — это не очень много. Если у тебя на каждом шагу отсеивается 50%, то у тебя просто сногсшибательная конверсия. При такой конверсии к концу придёт совсем мало человек. И ты это можешь сделать один раз.

— То есть к вам придёт 100 с чем-то. В 64 раза вы потеряете.

— Это очень мало. Это конверсия, за которую любой маркетолог отдаст руку и ногу.

— Это не тот охват, с которым можно работать?

— Это можно делать, если ты — компания объёма Coca Cola.

— Но это если рассматриваешь модель воронки, но у тебя же воронки нет. Воронка — это концепция, которой уже сто лет. А сейчас все говорят про некоторый граф, когда у тебя просто есть точка касания, и люди идут не сверху вниз, а непонятно как. Задача — этот граф охватить, и дальше пусть он бегает, рано или поздно он придёт в нужную нам точку.

— Да, и это работает. Если ты хорошо построишь контент, и на каждом шагу у тебя будет интересная информация, которая что-то даёт твоему читателю и посетителю, это будет работать. Можно ли на этом в рамках Java-комьюнити строить бизнес? Я сомневаюсь. На моём опыте, если у тебя пост состоит из двух частей, по ним прокликивают. Из трёх частей или же двух частей с follow-up — уже гораздо меньше трафика туда идёт. Я смогу это использовать в долгосрочной перспективе, это очень сложно, но мы к этому стремимся. Но таких результатов, чтобы мы могли говорить, что это работает, и рекомендовать всем, нет. Одноходовые комбинации работают. Просто совать рекламу везде и всюду я бы тоже не стал. Прямо скажем, инженеры, программисты, тимлиды — они все неглупые люди.

— Мне кажется, люди просто не любят топорную работу, люди любят, когда сделано тонко.

— Да все люди неглупые. Помнишь, мы были на JCrete, и там был групповой доклад про селф-промоушен. И Яков Файн говорил нам, мол, давайте писать посты. И это очень правильно, это хорошая идея. Я немного … ну, не троллил его, а скорее рассказывал ему просто про метрики, как их разыгрывать, оптимизировать. И он спросил у меня, считаю ли я, что все люди — идиоты и не видят через эту прозрачную систему воронок, что показываем им А, чтобы они купили В.

Конечно они видят. Никого нельзя считать идиотами. Я за простые комбинации, где ты чётко и честно говоришь, что ты написал, но твоё время спонсировала вот такая компания, и они молодцы. Если вам интересно, посмотрите. Это работает гораздо проще и легче, чем строить какие-то сложные воронки.

Вот вы организуете конференции, и вы часто пишете статьи на Хабр. Ты можешь посмотреть на свои метрики: выбираешь отдельный популярный пост, который хорошо генерирует трафик, смотришь, как он конвертируется, идут ли оттуда люди на статью про JPoint, Joker или какую-то другую конференцию. Но если ты попробуешь из существующих постов построить какую-то воронку или граф, то мне кажется, что ты тоже придёшь к выводу, что это может не стоить тех усилий, которые ты в это вкладываешь. Нужно честно заявить: да, вот это — наш бизнес, и мы стараемся делать хорошую работу. Если вам, как Java-программистам и инженерам, было бы интересно сходить на конференцию, вот вам прекрасная возможность. А строить какие-то замыслы — это очень сложный маркетинг.

Теги:
Хабы:
+26
Комментарии 0
Комментарии Комментировать

Публикации

Информация

Сайт
jugru.org
Дата регистрации
Дата основания
Численность
51–100 человек
Местоположение
Россия
Представитель
Алексей Федоров