Как выйти на рынки США, Европы, Азии и оставаться лидером локального рынка? CMO JavaRush Алексей Еленевич делится опытом масштабирования украинского продукта.

Алексей Еленевич

Как появился JavaRush

В 2012 году мы запустили онлайн-курс для самостоятельного изучения языка программирования Java с нуля — JavaRush. Необычная механика (в виде игры), возможность получить много практических навыков программирования и автоматическая проверка решения задач помогли продукту быстро вырасти. JavaRush стал для пользователей удобной альтернативой обучению с ментором.

Довольно скоро возник вопрос: как развиваться дальше, если местный рынок обучающихся Java так или иначе ограничен?

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

Как мы (неудачно) выходили на рынок США

Рынок Штатов мы выбрали не потому, что «все туда идут, и мы пойдем». Мы довольно детально изучили несколько регионов, в том числе в европейском и азиатском направлениях.

Помимо объемов, перспективности роста рынка и интенсивности конкуренции мы обратили внимание на еще один важный момент: перевод. Переводить курс с русского практически на любой другой язык, помимо английского (условно — китайский, хинди и так далее), оказалось несоразмерно дорого. При этом перевод на те же языки с английского стоил вполне адекватных денег.

Поэтому мы решили начать с самого крупного и при этом доступного нам англоязычного рынка (в первую очередь — рынка США), а затем расширяться на другие языки и страны. Это был 2014 год.

Мы наняли несколько переводчиков, чтобы перевести весь контент курса, и запустились с надеждой, что «вот сейчас вообще взлетим». Но не взлетели.

Перевод, как оказалось, был очень плох. Не потому, что переводчики схалтурили, а потому, что они перевели курс так, как перевел бы его любой человек, имеющий смутное представление о программировании на Java, и никогда не проживавший в США.

Нельзя сказать, что это был полный провал. Хотя… наверное, можно. Выяснилось, что мы были не готовы к такому шагу. Ресурсов на переводчиков-нейтивов, владеющих Java, у нас тогда не было. Да и организационно мы бы не потянули полноценный запуск продукта и быстрый рост команды.

Так что идею о масштабировании на какое-то время отложили. За пару лет мы доработали продукт, собрали достаточно ресурсов и сформировали сильную команду, способную выводить продукт на новые рынки.

Что мы делали, чтобы в следующий раз всё получилось

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

Это не просто переводчик. Точнее, совсем не переводчик. Менеджер по локализации организовывает весь процесс адаптации продукта под новые рынки, а именно:

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

Наш новый пилотный англоязычный продукт (CodeGym) мы разрабатывали уже с учетом адаптации под местный рынок.

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

Например, в результате выполнения одной из задач на экран пользователя выводится сообщение: «Я хочу в подарок на Новый год машинку». В США не особо дарят подарки на Новый год — в основном на Рождество. Подобные нюансы мы не просто переводим, а адаптируем под целевой рынок.

Кроме того, в курсе есть лекции о современных IT-технологиях и ситуации на рынке. Здесь не так много культурных особенностей, но есть, например, данные о зарплатах в Украине. Эта информация не релевантна для американцев. Поэтому ссылки на, скажем, rabota.ua мы меняем на Glassdoor.

А еще мы перестроили работу команды поддержки.

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

Когда мы перешли на международный рынок, оказалось, что американцы не привыкли писать в чат. Им проще обратиться через страницу в Facebook. Стало понятно, что нужно объединить все каналы общения с пользователями в один удобный интерфейс, чтобы поддержка могла оперативно реагировать на запросы из разных источников. Мы использовали для этого стандартный Intercom.

Во-вторых, для нового рынка пришлось адаптировать график работы сотрудников саппорта. Раньше поддержка у нас не работала на выходных, но в США люди привыкли, что саппорт должен постоянно быть на связи. Теперь наша служба поддержки работает 7 дней в неделю. Чтобы сделать это, не увеличивая команду или нагрузку, мы разработали новые посменные графики.

Как мы выходили на рынки Европы и Азии

Со временем англоязычный продукт стал интересен не только пользователям из США, хотя на тот момент мы еще не целились на другие рынки.

Мы провели серию интервью с пользователями из Бразилии, Франции, Польши и других стран. IT в этих регионах развивается хорошими темпами, но как показал опрос, комплексно изучить Java там особо негде (или неудобно). Так эти пользователи и оказались на англоязычном CodeGym.

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

Программирование и так занятие не из простых. Стало понятно, что людям будет гораздо комфортнее учиться на их родных языках, а продукт таким образом охватит большую аудиторию.

Интервью и опросы показали, что люди в Бразилии, Индии, Польше начинают проходить наш курс на английском, но стопорятся именно из-за языкового барьера. Учиться на родном языке гораздо легче, а значит, и вовлечение будет выше. Помимо прочего, практически ни в одной из этих стран не оказалось качественных неанглоязычных продуктов, обучающих Java. Это сразу повысило конкурентоспособность CodeGym на местных рынках в случае выхода с локализированной версией. В результате мы перевели продукт еще на 12 языков.

Как мы тратим минимум ресурсов на локализацию и за 1-2 месяца понимаем, работать ли с рынком дальше

Мы хотели посмотреть, как локализированные версии продукта «заходят» пользователям на новых рынках, и уже потом решить, стоит ли масштабироваться на другие страны. Исходя из аналитики мы выбрали 12 перспективных языков и перевели первые 2 уровня курса (всего их 40). Это позволило нам быстро получить фидбек от пользователей и сразу понять, как работают локальные версии.

Чтобы понять, «зашел» язык или нет, мы детально изучали ключевые метрики на каждом этапе воронки. На что смотрели:

1. В соцсетях — на охват поста, CTR, комментарии. Например, таким способом мы выяснили, что наш перевод на бенгальский был «не очень» — об этом нам писали пользователи под рекламными постами.
2. На лендинге — в первую очередь на показатель конверсии в регистрацию. У нас уже был средний показатель для русскоязычной и англоязычной версий продукта. По отклонениям в плюс или в минус на других языках мы могли понять, попали в цель с месседжами и качеством перевода или нет.
3. В продукте — на то, как люди проходят курс. В разных языковых версиях процент пользователей, которые доходили до конца пробных уровней, отличался. Например, в польской версии «доходимость» до конца 2-го уровня была даже лучше, чем в английской.

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

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

Советы по выходу на новые рынки

Мы масштабировались своими силами, не привлекая внешнюю экспертизу и капитал на постоянной основе. Не считая первой неудачной попытки выхода на американский рынок, у нас все получилось. И все же есть несколько вещей, которые мы бы сделали иначе, с учетом опыта. Это довольно универсальные советы, они подойдут для любых IT-продуктов, которые хотят масштабироваться за счет выхода за рубеж:

1. Изучать специфику местных платежных систем

Когда люди думают про США, им в голову, скорее всего, приходит необходимость установки на сайте PayPal, Visa/Mastercard, American Express, Apple Pay и Google Pay. А как насчет Китая, где банковские карточки не так распространены, как у нас, зато есть AliPay и WeChatPay?

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

2. Учитывать культурные особенности региона

Местные традиции, искусство и даже юмор всегда нужно учитывать, при необходимости адаптируя и перестраивая продукт.

Например, в ранних версиях нашего курса была картинка-шутка про то, что Санта уволил своих оленей и вместо них нанял за миску риса людей из Бангладеша, которые работают 7 дней в неделю. У нас люди посмеялись и забыли, а вот в Штатах к вопросам политкорректности относятся куда серьезнее — это сразу вызывает шквал недовольств и накладывает негативный отпечаток на репутацию продукта.

3. Не завышать ожидания

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

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

Конкуренция на рынке, масштабы локализации, особенности пользовательского опыта, которые не видны «отсюда», — все это может сказаться на том, насколько легко и быстро вы сможете войти и закрепиться на новом рынке.

К масштабированию продукта нужно подходить рационально. Запаситесь ресурсами, терпением и прагматично идите по намеченному плану.

Источник: vctr.media