На разработку и успешность сервиса влияет то, как его будут запускать — внутри существующего продукта или отдельным приложением. В этом посте — как мы в 2ГИС решаем, где запускать: внутри или снаружи.
Михаил Мельников
Продакт-лид сервиса Отелло
Новые сервисы — важная часть жизни больших технологических компаний. Они расширяют аудиторию, повышают частоту использования и создают новые сценарии монетизации. Они необходимы, чтобы не отставать от трендов и рынка.
Но чем основной продукт масштабнее, тем сложнее внутри него запускать новинки. Их нужно интегрировать с существующими инструментами и технологиями, они должны логично вписаться в основные сценарии использования приложения и его интерфейс. Новые сервисы увеличивают нагрузку на команду основного продукта и попадают в медленный релизный цикл больших приложений.
Решая, будут ли новые сервисы запускаться внутри основного приложения или как отдельный продукт, мы взвешиваем плюсы и минусы по трём основным категориям.
-
Уровень неопределённости. Новый сервис — это гипотеза или стабильный проект
Какие-то сервисы естественно вписываются в сценарий использования основного приложения. Мы знаем, как их делать, и уверены, что они нужны нашим пользователям. Другие — новая территория. Их нужно тестировать, «прогревать» аудиторию и экспериментировать с форматом.
-
Скорость запуска. Будет ли быстрее, если запустить снаружи?
2ГИС — большое приложение со множеством сценариев использования и насыщенным интерфейсом. Интеграция нового сервиса в такое приложение занимает больше времени, чем запуск снаружи. Кроме этого, релизный цикл больших приложений может занимать несколько недель, поэтому оперативно выпускать обновления не получится.
При запуске снаружи создать и обновлять рабочую версию, как правило, быстрее.
-
Конфликты. Вписывается ли новый сервис в систему 2ГИС?
2ГИС пользуется более 70 млн человек, и новый инструмент может повлиять на их опыт. Мы оцениваем, как обновление впишется в популярные сценарии использования, есть ли на него запрос у пользователей. Другой важный фактор — монетизация. Важно, чтобы новинка не конфликтовала с тем, как мы взаимодействуем с бизнес-партнёрами и рекламодателями.
Подробнее — на реальных кейсах.
Кейс №1: Навигатор
Навигатор сегодня — стандартный инструмент любой онлайн-карты. Но так было не всегда. В 2017 году в 2ГИС была возможность строить маршруты, и ей пользовались несколько миллионов человек ежемесячно. А вот проехать по этим маршрутам они не могли — навигатора не было.
В тот период у того же Яндекса навигатор был отдельным приложением. Мы задумались: делать свой навигатор отдельно или интегрировать в основное приложение 2ГИС.
Уровень неопределённости. Навигатор — стабильный и понятный продукт. У нас было много обратной связи с просьбами его сделать.
Лучше делать: в продукте
Скорость запуска. За пределами релизного цикла основного приложения выпустить навигатор быстрее. Скорость разработки — важный фактор, так как его требовала значительная часть нашей аудитории.
Лучше делать: отдельно
Конфликты. 2ГИС помогает людям находить компании и обращаться к ним. Построить маршрут к этим компаниям — один из сценариев поиска и обращения. Соответственно, нет конфликта с монетизацией и пользовательским опытом.
Лучше делать: в продукте
Решение было непростым и болезненным — мы могли быстрее сделать навигатор снаружи, но другие факторы говорили в пользу запуска внутри основного приложения. После долгих дискуссий мы запустили навигатор внутри, и это оказалось стратегически правильным решением.
Он гармонично вписался в сценарий использования 2ГИС, в нашу схему монетизации и стратегию развития. Уже в первый год треть мобильной аудитории пользовалась навигатором, сейчас — 45%.
Кейс №2: Аптеки 2ГИС
Мы несколько раз пытались добавить в 2ГИС поиск товаров. Как и в истории с навигатором, это был довольно частый запрос от пользователей. С другой стороны у нас было несколько миллионов открытий карточек аптек — пользователи хотели позвонить, чтобы уточнить наличие лекарств, сравнить цены и т. д. Кажется, запуск поиска по лекарствам был очевиден. Обратились к оценке по категориям.
Уровень неопределённости. Высокий, многое нужно было проверять. Во-первых, выяснить, получится ли хранить и качественно апдейтить большие объемы данных. Во-вторых, мы не понимали, как новый инструмент вписывается в привычный сценарий использования 2ГИС — поиска по фирмам, а не по товарам. В-третьих, мы не нашли на тот момент удачных референсов, сравнить проект было не с чем.
Лучше делать: отдельно
Скорость запуска. Запуск внутри 2ГИС занял бы больше времени, так как нам бы пришлось делать сервис на нативных технологиях и для двух платформ (iOS и Android). Отдельный продукт можно было делать полностью на веб-технологиях.
Лучше делать: отдельно
Конфликты. Ощутимый конфликт с основной моделью монетизации 2ГИС. Мы зарабатываем на внимании к компаниям. В новом сервисе пользователь вместо компаний ищет товары, и далеко не для всех наших партнеров такая модель работает. Кроме этого, товарный поиск должен как-то существовать с поиском по фирмам, интегрируясь в выдачу, либо отдельным интерфейсом. Для проверки гипотезы внутри 2ГИС это было бы слишком дорого.
Лучше делать: отдельно
Мы решили начать тестирование в отдельном проекте. За 3 месяца мы разработали приложение на React Native и начали «подливать» в него аудиторию из 2ГИС через пуш-уведомления. Параллельно с запуском мы работали с поставщиками данных, чтобы обеспечить своевременные апдейты.
Сейчас проект «Аптеки» закрыт, но он помог проверить несколько важных гипотез. В том числе и ту, что удержать аудиторию в отдельном продукте может быть в два раза дешевле, чем в основном.
Кейс №3: Бронирование отелей «Отелло»
В 2022 году мы разработали сервис для бронирования отелей. У нас было несколько предпосылок, чтобы пойти в эту область:
После ухода Booking.com и Airbnb на рынке образовалась свободная ниша
Ежемесячно несколько миллионов пользователей ищут отели в 2ГИС
У нас есть все ресурсы, чтобы быстро и недорого проверить гипотезу и сделать MVP — карта, поиск, уникальный контент про отели (отзывы, рейтинги, атрибуты)
На первый взгляд всё хорошо подходит для основного продукта 2ГИС, но мы запустили Отелло отдельным приложением.
Уровень неопределённости. Мы не понимали, сможем ли сделать конкурентный продукт без необходимой экспертизы. У нас были хорошие ресурсы, но бронирование отелей — новый для нас продукт.
Лучше делать: отдельно
Скорость запуска. Запускать нужно было как можно быстрее — рынок бронирования отелей после ухода Booking перераспределялся между российскими компаниями, и мы хотели успеть занять нишу.
Лучше делать: отдельно
Конфликты. Из приведенных кейсов у Отелло самая серьёзная ситуация с конфликтами. В Отелло мы зарабатываем на комиссии от бронирования — это совершенно другая бизнес-модель, чем у основного продукта 2ГИС.
Лучше делать: отдельно
MVP нам удалось запустить за два месяца. В Отелло практически не используются нативные инструменты — сервис работает только на веб-технологиях. Это позволяет нам быстро выпускать обновления практически ежедневно, без длительных ревью в сторах.
Так где же запускать?
Эти три критерия: уровень неопределённости, скорость запуска и конфликты — только часть того, на что можно ориентироваться, решая вопрос запуска сервиса. И конечное решение может опираться на куда большее количество условий: от стоимости разработки основного сервиса до сложности его маркетинга.
Но ответы уже на эти вопросы и понимание степени их влияния на ваш продукт, помогут понять принципиальные плюсы и минусы каждого подхода.
Откликается наш подход? Заглядывайте в вакансии продактов и будете вместе с нами работать над сервисами, которыми пользуются десятки миллионов пользователей.