Интервью и дискуссии
Promotrøll Agency
28.10.2024
ADPASS рекомендует материал к прочтению
ИП Борисова М.А.
Максим Нечаев: «Главная задача — не пытаться создать идеальный продукт, а тестировать гипотезы»
iOS-разработчик, эксперт в программировании Максим Нечаев рассказал зачем IT-специалисты делают MVP (минимально жизнеспособный продукт) и как он позволяет экономить деньги.
MVP (Minimal Viable Product) — это пробная версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.
Когда нужен MVP?
Большинство молодых проектов сейчас начинают именно с MVP. Не только малые, но и большие корпорации предпочитают тестировать продукты в MVP формате перед выходом на рынок с полноценным софтом.
Когда мы с командой решили закрыть проблему создателей контента (а именно организацию, фильтрацию, генерацию и хранение), стало понятно, что скорее всего, продукт будет пользоваться спросом. Мы исходили из того, что в данный момент ниша создания контента разрастается быстрее, чем когда-либо. У нас не было больших ресурсов, дорогостоящей аналитики рынка и опросов пользователей. Более того, не было даже прямых конкурентов. Естественно, гипотезу нужно проверять.
С какой платформы начать разработку iOS или Android?
Я занялся разработкой приложения iOS, так как это сейчас самая эффективная платформа для выхода на рынок молодому продукту. iOS более платежеспособен и менее конкурентен, чем Android. Так мы и вышли на рынок с iOS-приложением Lum: Create & Organize Content.
Когда можно обойтись без MVP?
Я встречал некоторые кейсы, когда MVP был действительно не обязателен. Например, если у вас уже есть некий продукт, есть аудитория и сквозная аналитика. Вы понимаете, что ваше текущее направление устаревает и становится неактуальным. И на этапе гипотезы и аналитических данных вы выстраиваете новый продукт и совершаете, так называемый, «pivot». Резко меняете направление и выходите с новым продуктом. В таком случае, полагаю, что можно обойтись без MVP.
Но это рискованный путь (особенно в нише приложений под iOS и Android). Создание MVP в IT-индустрии — это обязательный шаг. Иначе можно сжечь огромное количество ресурсов (времени и денег) и не окупиться даже на базовом уровне.
На каком этапе надо подключать полноценное решение взамен MVP?
Переход из одного в другое чаще всего достаточно плавный.
Создавая MVP, я не трачу время на выстраивание грамотных и правильных архитектур, не пишу самописные времязатратные модули, а используя всем известные фреймворки, то есть заранее написанные другими программистами модули, подключаю их в проект и собираю из этого MVP. Когда мое приложение может выполнять основные ключевые функции, ради которых оно создавалось, я «причесываю» UI-дизайн и добавляю системы оплаты. После чего регистрирую приложение в системе Apple и начинаю первые тесты. После релиза приложения я запускаю рекламные активности. В мире iOS — это App Store Optimization (поисковая оптимизация по ключам) и Apple Search Ads (поисковая реклама по ключам, как например, Яндекс.Директ). Далее я начинаю выкатку обновлений, каждые 2–3–4 дня добавляю функционал, исправляю баги, меняю некоторые решения, провожу более качественную аналитику.
То есть в течение первых двух-трех месяцев после релиза MVP приложение «наращивает массу». При этом все это время я смотрю на показатели. Если вижу, что как минимум приближаюсь к самоокупаемости, значит, с этим можно работать. Потому что с точки зрения маркетинговых активностей, первые 2–3 месяца — самые дорогие. Нужно найти лучшие формулы привлечения новых пользователей, которые оплачивают подписку, а вы окупаете вложения в рекламу. Благодаря постоянным обновлениям с исправлениями ошибок в работе приложения, оно становится полноценным сервисом, нежели MVP.
Какой должен быть функционал у MVP?
Здесь 2 разные позиции.
-
Одни предприниматели создают минимальный продукт. Зачастую, он плохо выглядит, плохо работает и выполняет максимум одну функцию (причем делает это сомнительно).
-
Вторые делают MVP ближе к первой версии полноценного приложения.
Я выбрал второй лагерь. Функционал и визуал MVP надо делать хорошо. Необязательно нанимать большую команду разработчиков и делать лучший продукт на рынке. Делать надо оптимально. Для меня это самое важное слово. Не минимально, не максимально, а оптимально для первой версии. На примере нашего бизнеса iOS-приложений, когда мы готовим первый запуск MVP, работают минимум 3–4 человека. Backend разработчик (он выносит часть логики из iOS, что ускоряет и упрощает платформенную разработку), UX/UI дизайнер, который прорабатывает основной функционал и делает его удобным и красивым. И iOS разработчик, который пишет непосредственно само приложение. Обычно, именно я беру на себя роль последнего.
Мы стараемся работать по системе 1–3–5.
-
Одна главная функциональность, которая является ключевой для наших будущих пользователей, именно за нее они и готовы платить и скачивать приложение.
-
Три дополнительных функциональности, которые упрощают работу с первой и расширяют возможности (они должны быть на порядок проще).
-
Пять микро-функциональных, которые создают эффект полноценного приложения в MVP-варианте. Например, возможность поделиться приложением, увидеть свой рейтинг, исходя из активности в приложении, менять фон карточек — то есть что-то простое, но понятное пользователю.
Скачивая такое приложение, наш пользователь не удивляется тому, что в магазине ему продавали классное решение, а на деле это «скелет» продукта. Поэтому я бы советовал систему 1–3–5 при создании MVP.
Как определить перспективность проекта на этапе MVP?
В целом MVP — это история про тестирование спроса. Ключевые для нас показатели — это реакция людей в AppStore, процент скачиваний, цена за привлечение подписчика и конверсию в оплату. Но учитывая, что наши MVP уже достаточно рабочие, то многие пользователи сразу оформляют подписки, и это позволяет нам окупать маркетинговые затраты.
Какие бывают ошибки в MVP?
В нашей нише (как и во многих других) главная ошибка — создавать чересчур комплексные и сложные iOS-приложения. Важно помнить, MVP должен быть простым и быстрым. В идеале, собрать его за период от 2 недель до 2 месяцев, не более. Как раз за 2–3 недели собираются скелеты, за 1,5–2 месяца более полные MVP. Но готовить приложение (или веб-сервис) в течение года или двух — это сомнительно решение. Только если это не обусловлено спецификой ниши, где любой минимальный продукт создается столько времени.
Надо ли создавать несколько MVP для проекта, чтобы выбрать наилучший вариант?
Я бы не рекомендовал запускать несколько MVP для одного проекта. Достаточно одного. Если у вас есть желания попробовать преподнести MVP по-разному и решить, что работает лучше, а что хуже, на помощь приходят А/Б тесты. В рамках мобильной iOS-разработки у нас для этого большое количество решений: А/Б тесты логики и функциональности с помощью сервиса Firebase, А/Б тесты экранов оплаты с помощью сервиса RevenueCat и так далее.
Создавайте одно MVP и тестируйте, добавляйте, удаляйте, переделывайте фичи. Будто бы играетесь с кубиками Lego. Суть в том, чтобы через все попытки получить тот продукт, который купит ваша целевая аудитория. На начальных этапах главная задача — тестировать гипотезы, а не создавать идеальный продукт. Тестируйте, анализируйте, ошибайтесь, теряйте и зарабатывайте — всё это часть процесса, и это нормально.
Лучшее в блогах
13 часов назад
Вам понравится
Фестиваль рекламы Red Apple
28.10.2024
В шаге от награды: шорт-лист Red Apple 2024
![]()
В 34-ом сезоне Red Apple собрал рекордное количество заявок — 865, из которых 340 вошли в шорт-лист. Международное жюри из 35 стран мира оценивало работы участников по четырём основным направлениям: Creative, Media, Marketing и Young Creators — смотрите список претендентов на награды.
Aigital
18.10.2024
ARNIKA
16.10.2024
Новости 
Кейсы 
How to 
Маркетинговые исследования 
Просто о сложном 
Проверено ADPASS 
Рекламные кампании