MVP мобильного приложения. Как минимизировать риски?
2 часть

Начало разработки
Итак, ты провел тесты и нашел нужные связки креатив + ЦА. Уже можно рискнуть и заложив квартиру/продав почку заказать разработку приложения. Чтобы чуть поднять шансы на выкуп закладной/качественный диализ осталось 3 простых шага:

1. Разбей разработку на этапы

2. Определи целевые показатели каждого этапа

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

1. Базовые. Регистрация и поиск для приложения знакомств, оплата для интернет-магазина, чтение статьи для журнала

2. Опциональные. Суперлайк в знакомствах, рекомендуемые товары в магазине, кнопка поделиться в журнале

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

А если пользоваться приложением стало НЕВОЗМОЖНО — это базовый функционал.

Без базового функционала приложение невозможно. Без опционального не принесет тебе прибыль. Чтобы снизить риски ненужных затрат тебе необходимо отделить полезные функции от моста имени господина Манилова.

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

ПС. Есть второй вариант. Начни с проверки самой РИСКОВАННОЙ гипотезы. Этот метод будущих единорогов.
Определи целевые показатели каждого этапа
Не достиг желаемого? Сделай вид, что желал достигнутого. Оставь деньги и славу другим.
Каждая новая фича приложение это отдельный этап разработки. У каждого действия должна быть цель. У каждого этапа должны быть отсечки — развиваем/сворачиваем.

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

Даже "так все делают", "это логично", "может в будущем пользователи начнут это использовать" не аргументы в защиту ненужной фичи. Если это не приносит денег, зачем вы продолжаете, мистер Андерсон?

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

Ты видишь в числах положительный эффект? Значит масштабируй фичу.
Любой положительный эффект можно измерить в числах. Retention, прибыль, время в приложении, etc. И пропорционально увеличивать инвестиции.

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

Улучшений нет и ты видишь это в числах — результат достигнут.

Если ты не можешь точно сказать — результат не достигнут.

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