Запуск мобильного стартапа с помощью GROWTH Method

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

Сегодня, как и обещали, остановимся подробнее на GROWTH Method. Рассмотрим на кейсах INOSTUDIO, как этот метод работает. Напоминаем, что статья подготовлена по материалам вебинара Екатерины Королевой, project-менеджера INOSTUDIO.

Goal — Пойми, что должно получиться.

Reality — Анализируй, что есть сейчас.

Obstacles — Продумывай, как поменять продукт.

Way Forward — Меняй и запускай. Смотри, что происходит.

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

Мы сделали запрос номера третьим шагом. На первом спрашивали данные пользователя, среди них был email адрес, по которому потом писали и узнавали проблему. Этим в офлайне занимались основатели стартапа, они таким образом возвращали тех, кто не завершил регистрацию. То есть цепочка действий выглядела так: увидели, что первый шаг поломан, проанализировали и придумали, как это поменять, оценили действия.

Упрощение

Важно, чтобы изменения были минимальны для бюджета и срока реализации. То есть вы упрощаете свое решение. Если не работает регистрация, это не значит, что нужно все бросать и говорить: «Ага, люди боятся делиться номером телефона, давайте срочно выкинем регистрацию по номеру телефона, которую разрабатывали пару недель. И еще за лишние пару недель разработаем регистрацию через email».

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

Короткие итерации

В идеале по GROWTH итерация может быть один день. Но специфика, например, мобильных стартапов заключается в том, что есть сторы — App Store и Google Play. И мы не можем сделать так, чтобы каждый день в магазинах появлялась новая версия приложения. Но в течение, условно говоря, недели можно легко делать обновление, выпускать новые версии и продумывать гипотезы, как изменить продукт. Это более комфортный срок.

Прекращение работ

Часто бывает, что разрабатывается функционал, который не востребован пользователем. И важно понимать, что незачем сейчас тратить на него бюджет. Лучше пустить его на дополнительную рекламу или на функции, которые нужны пользователям или инвесторам. GROWTH-метод как раз позволяет увидеть, что именно не работает. И если через несколько итераций ситуация не меняется, возможно, проблема не в самой реализация, а в том, ЧТО реализуется. И можно попробовать что-то другое.

Остановимся подробней на том, кто же входит в GROWTH-команду.

Аналитик, дизайнер, разработчик, тестировщик — это стандартные роли, которые есть, наверное, в любом цифровом решении, при разработке любого ПО. Но есть одно большое «но» — это отдельная команда, у нее другие цели.

Аналитик, который работает в GROWTH-подразделении, нацелен не столько на то, каким должен быть крутым новый функционал или как у него развит UI и UX. Он понимает, какие воронки нужно оценивать, какие данные собирать. Этими данными делится с GROWTH-командой, и все вместе решают, как сделать так, чтобы достичь той цели, которая стоит перед проектом в данный момент. То есть он обеспечивает команду аналитикой, формирует гипотезу и обозначает, какую проблему необходимо решить. В его зоне ответственности находятся все инструменты аналитики, которые используются на проекте.

Дальше работает дизайнер, это может быть UI/UX-дизайнер. Он отвечает за то, как модернизировать продукт. Вспомним кейс с регистрацией. У нас дизайнер говорила: «Давайте поменяем шаги местами, чтобы не отпугивать пользователей сразу». В другом случае предлагала добавить дополнительное поле, чтобы люди могли загрузить свою фотографию. Дизайнер работала над улучшением UX.

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

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

Отдельная команда

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

Первый выход = сразу ценность

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

Если брать приложение для поиска работы, то это может быть автоматическое создание резюме. Или, например, готовый шаблон резюме, составленный для ускорения работы с приложением. Чтобы человек зарегистрировался и получил шаблон, который можно заполнить.

Быстрый темп изменений и параллельные изменения

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

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

А теперь настало время рассказать о кейсах, в которых мы применяли GROWTH-метод, и что изменилось в стартапах.

Изменение модели бизнеса

Работали со стартапом, который придумал интересную технологию — AR-примерочную. То есть примерочная в дополненной реальности, когда можно на сайте магазина выбрать блузку и примерить на себя. Или выбрать наручные часы и примерить. Наводишь телефон и видишь, как вещи на тебе смотрятся. Сама идея интересная, но модель бизнеса была такая: клиент хотел сделать магазин, условно говоря, свой Aliexpress, только где будет примерка в дополненной реальности.

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

Это был пример, когда основатель модернизировал модель бизнеса и по-другому зашел на свою целевую аудиторию. А стартап вышел из точки безубыточности.

Изменение позиционирования

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

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

Изменение платформы

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

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

Изменение дизайна

Все тот же сайт для строителей. Изначально разработали такой дизайн:

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

Кстати, редизайн сайта тогда сделали за две недели и выпустили с совсем новым видом. Как мы говорили, в GROWTH важны скорость и итерации. Даже больше скажем, были редизайн и ребрендинг. Провели исследования и выяснили, что в названии проекта слово “journey” не для нашей целевой аудитории, а опять же больше для нас. Американский строитель реагирует на другое слово — “core”. И теперь проект называется Core.

Изменение функционала

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

Некоторые pop-up люди не находили, потому что нужно было нажать иконку редактирования — «карандашик». Это непонятный шаг для нашей целевой аудитории, они строители, а не инженеры веб-разработки. Аналитика показала, что многие блоки не заполняются.

Тогда на сайт добавили помощник, который, как квиз, проводил человека по этим блокам:

Мы не переделывали блоки, мы просто добавили маленькое всплывающее окно, где по очереди открывали эти pop-up и не заставляли людей идти искать «карандашик». Благодаря изменениям пользователи стали заполнять больше полей в резюме, и оно стало более информативным для работодателей.

Еще один пример с этого же проекта. Мы придумали, что навыки люди будут заполнять через pop-up. Реализовали умный поиск, который по введенным нескольким буквам подсказывал из базы данных, какие скиллы бывают. Нам казалось, что это очень удобно, но статистика показала, что люди практически не пользуются добавлением навыков на сайте. И уж тем более верификацией этих навыков.

Поэтому мы придумали, что у нас не будет ручного заполнения. Мы автоматически подскажем людям навыки, опираясь на их изначальный скилл. Пользователь указывает, что он строитель, мы показываем, какие у строителей бывают навыки. Указывает, что он маляр, и мы показываем, что в нашей базе для маляров есть такие навыки: работа с акриловой краской, распылитель и т.д. И единственное, что остается сделать пользователю, это нажать на «плюсик». Люди стали заполнять скиллы. То есть мы упростили взаимодействие и стали запрашивать информацию по-другому.

Трудоемкое MVP и отсрочка выхода на рынок

Один из принципов GROWTH — это упрощение. В начале важно понимать, что первая версия продукта может состоять из регистрации и одной главной функции — все.

Были у нас случаи, когда сложно было определиться с MVP, какой функционал минимальный, а какой не минимальный. И в итоге MVP получался очень большим, естественно, это увеличивало бюджет. И потом продукт сложно было модернизировать.

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

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

Крупные изменения и необоснованные гипотезы

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

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

Изобретение велосипеда

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

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

Несвоевременность

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

Вот такие сложные кейсы GROWTH-метода были у нашей компании.

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

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

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

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

Для тех, кто интересуется темой стартапа, сотрудники INOSTUDIO подготовили полезности. Вы найдете список книг и ссылки на фонды и акселераторы, которые занимаются стартапами. Вдруг в каком-то из них вам посчастливится найти своего бизнес-ангела или консультанта, который поможет грамотно подойти к развитию идеи.