Хорошая и плохая практика запуска цифровых продуктов на примере мобильного приложения

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

От чего, в таком случае, зависит судьба мобильного продукта?

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

Во второй части статьи мы рассмотрим предложенный подход на примере работы с Meinestadt — нашим клиентом из Германии.

Немного безжалостной статистики

ежедневно активных пользователей отказываются от приложения в течение 7 дней после установки, согласно исследованию Similarweb.

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

пользователей проявляют интерес к приложению спустя 3 месяца после установки.

Исключение составляют только наиболее популярные продукты: Facebook на момент исследования терял в первую неделю после установки только 22% пользователей, «ВКонтакте» — 30%.

Приложения с низким показателем удалений после установки

К приложениям, которые удаляют реже других, относятся мессенджеры, социальный сети, почтовые и музыкальные сервисы — все то, без чего трудно обойтись современному человеку. В 2016 году самый низкий показатель отказов имели WhatsApp (около 6%), «Поиск» Яндекса (7,7%), «ВКонтакте» (10,3%) и некоторые другие.

← Диаграмма предоставлена SimilarWeb и основана на данных более чем 4 миллионов пользователей.

Приложения из других категорий пользователи удаляют намного чаще, не делая никаких исключений. В маркетах сотни тысяч приложений, и если не удовлетворяет одно – всегда можно скачать другое.

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

Плохая практика разработки

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

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

Но реальность сильно отличается от этих представлений. Ни один проект не застрахован от трудностей и непредвиденных ситуаций:

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

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

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

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

Хорошая практика разработки

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

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

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

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

Как перейти от плохой практики к хорошей?

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

Мы как можно скорее стараемся проверить гипотезы монетизации. Если они не работают, придумываем и тестируем новые. Чем раньше удастся найти рабочие модели, тем раньше в проекте появятся доходы. Узнать больше о KPI-калькуляторе как помощнике в поиске моделей монетизации.
Мы избегаем громоздкого технического задания на разработку мобильного приложения. Вместо этого мы создаем прототипы, на основе сформированных требованиях к MVP. Узнать больше о методологии формирования функционала MVP.
На запуск MVP может уйти до 60% всего бюджета, но это не страшно. Главное, чтобы идеи были полезными для потребителя. Узнать больше о подходе Customer Journey Map, который помогает донести ценность до потребителя.

КАК ЭТО РАБОТАЕТ на примере?

В 2017 году мы перезапустили мобильное приложение для немецкого гиперлокального медиа Meinestadt. Meinestadt App – это большой информационно-развлекательный проект с функционалом для поиска мероприятий, кафе, заправок, арендного жилья и других объектов. Сегодня приложение установлено каждым восьмым жителем Германии.

Таймлайн

12 месяцев – общий срок разработки.

6 промежуточных релизов за это время.

4 месяца от старта проекта — запуск MVP (minimum viable product, минимальный жизнеспособный продукт).

Старт Работ

ЯНВАРЬ 2017 — у клиента было старое мобильное приложение, которое не пользовалось успехом у аудитории.

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

Вот как выглядел бы процесс работы:

Продукт не нравится пользователям, среднемесячная оценка — 2.
Разработка завершена, а средств и времени на изменения не осталось.
Временные и материальные ресурсы на изменения закончились.

Поэтому мы выбрали другую стратегию. Убрали в сторону техническое задание на разработку, работа по которому израсходует 100% бюджета, взамен выбрав из ТЗ наиболее важные функции и запустив MVP. Далее мы анализировали поведение аудитории и выпускали обновления, постепенно приближаясь к требуемым KPI.

ПОСМОТРИТЕ, КАК ШАГ ЗА ШАГОМ
МЫ ПРИБЛИЖАЛИСЬ К успеху

АПРЕЛЬ 2017

В первом релизе, через 4 месяца после старта проекта, мы сделали общий редизайн продукта и реализовали опцию геолокационных push-уведомлений. Они приходят пользователю, если он оказывается рядом с заведением рекламного партнера приложения (кафе, магазином, заправкой). Этот функционал позже помог коммерческому отделу Meinestadt усилить уникальность их предложения и подписать контракты с Mercedes-Benz, McDonald’s, Sony Television.

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

Подключенные системы аналитики (Localytics, Fabric, Google Analytics) показали, что одним из самых востребованных разделов в приложении является «Прогноз погоды», туда заходит 43% пользователей. В связи с новыми данными задача по улучшению раздела с погодой получила более высокий приоритет.

МАЙ 2017

Системы аналитики дают всё новые данные. Люди интересуются разделом подбора арендной недвижимости (он интегрирован с партнерским сервисом), но не совершают там достаточное количество целевых действий (отправка заявки в сервис аренды жилья). Мы полностью переработали дизайн раздела, целевых действий стало больше, а среднемесячная оценка приложения изменилась с 2 звезд до 3,75.

Уже на этом этапе доходы от монетизации стали покрывать расходы на ежемесячный бюджет разработки.

ИЮЛЬ 2017

Мы опубликовали раздел с расширенным прогнозом погоды, после чего оценка приложения выросла с 3,75 до 4 звезд, а у Meinestadt появился новый партнер — крупнейшая сеть ресторанов фаст-фуда, заинтересованная в рекламе через геолокационные push-уведомления.

АВГУСТ 2017

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

В результате к сентябрю ARPU (Average revenue per user, средняя выручка на одного пользователя) раздела знакомств возросла в 4 раза.

ОКТЯБРЬ 2017

К этому моменту системы аналитики собирали несколько миллиардов внутренних событий в месяц. Эти данные показывали нам, какими путями пользователи предпочитают двигаться в приложении и где встречаются с барьерами. Учитывая эти данные, мы сделали редизайн раздела «События» и добавили панель инструментов (toolbar), которая ускоряла навигацию.

ДЕКАБРЬ 2017

Аналитика показала, что люди активно пользуются фильтрами поиска недвижимости, которые появились в мае. Для тех пользователей, кто не находил себе квартиру, мы организовали рассылку push-уведомлений, которые сообщали о появлении объектов, соответствующих их фильтрации. Это позволило повысить ARPU еще в 3 раза. Среднемесячная оценка продукта в магазинах мобильных приложений выросла до 4,67 звезд.

На текущий момент мы ежемесячно рассылаем порядка 17 тысяч таких уведомлений. Проделанная работа помогла нам увеличить количество людей, которые находят квартиры для аренды через Meinestadt, в 3 раза.

Вот как выглядел процесс работы в итоге:

Среднемесячная оценка выросла с 2 до 4,67.
Мы начали получать доход уже на 4 месяце работы над приложением.
Итерационная разработка позволила выпустить 6 обновлений за год, что раз за разом воскрешало интерес аудитории.

К концу года рост выручки составил 138% относительного планового показателя, установленного владельцем продукта.

Что помогло добиться успеха?

Частые обновления. Вместо того, чтобы целый год делать приложение строго по техническому заданию и опубликовать его в декабре, мы запустили MVP в начале второго квартала, а затем делали релизы с периодичностью в 1-2 месяца, каждый раз внедряя в проект что-то радикально новое.
Появление выручки еще до основного релиза. Приложение начало приносить доход уже на этапе запуска MVP. Нам потребовалось около 9 месяцев, чтобы выручка «догнала» ежемесячный бюджет разработки и даже начала превышать его.
Реализация подхода Data Driven Development. Все изменения и доработки в продукте делались на основе анализа поведения пользователей. Мы не внедряли непроверенные гипотезы, какими бы результативными они ни казались. Так, например, аналитика не показала большого интереса пользователей к созданию собственного контента, и мы не стали тратить ресурсы на этот функционал.

простых шага к итерационной разработке

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

Необходимое время: 30 минут

1. Запуск MVP позволяет сэкономить до 40% общего бюджета. Работа только над ключевыми функциями экономит талант и время команды. Узнайте о 3 методах, которые позволят выделить главное в MVP.

Необходимое время: 1 час

2. Найти рабочую модель монетизации, которая покроет расходы — задача непростая. Проверяйте гипотезы быстро и без сожалений отбрасывайте неработающие. Протестируйте 4 готовых модели монетизации уже сегодня с помощью KPI-калькулятора.

Необходимое время: 4 часа

3. Сбор первых данных после запуска MVP позволит понять, куда двигаться дальше. Главное — не забывать о счастье пользователей. Познакомьтесь с инструментом Customer Journey Map. Он поможет найти фичи, которые люди полюбят.

Данная статья написана на основе опыта работы наших немецких клиентов и партнёров.