Какие задачи решает MVP мобильного приложения

8 min readJun 4, 2024

Формируем правильные ожидания и метрики перед запуском

Как определить, что такое MVP? Сколько оно делается и стоит? Как понять, что MVP справилось со своей задачей и нужно идти дальше?

Мой опыт показывает, что не все, что называют MVP, таковым является. Также часто предъявляются нереалистичные ожидания от MVP от: собственников, продактов, а также user acquisition специалистов.

Давайте разберемся, как не стать заложником некорректных ожиданий от MVP мобильного приложения.

Что такое MVP?

MVP = Minimum Viable Product или Минимально жизнеспособный продукт. Т.е. продукт обладающий минимальным, но достаточным набором решений и функций для получения достоверных результатов по гипотезам.

Задача MVP: дешево проверить гипотезу продукта или фичи в мобильном приложении.

Всегда ли MVP — это разработка приложения? Не всегда, но в большистве случаев в мобайле это так. Тестирование через fake store, на другом приложении или через креативы — специфические тесты. Web Acqusition (когда мы ведем на лендинг) и Mobile Acqusition (когда мы тянем людей в магазин приложений) — в большинстве случаев это разные аудитории, которые обладают разными поведенческими характеристиками, а следовательно и закупочной ценой.

Цель — основа разработки MVP

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

Если цель сформирована правильно, то уже проще понять, что будет MVP, а что нет. Ведь MVP решает конкретную задачу, а не создается “по приколу”.

Какие могут быть цели?

Протестировать источники трафика и конкретные подходы в креативах. Условно: понять CTR, конкретные источники и какие креативы работают.
Проверить гипотезу, что мы можем добывать дешевый трафик для приложения в конкурентной нише. Условно: понять стоимость установки (CPI), стоимость клика (CPC)
Проверить, можно ли монетизировать трафик с положительной экономикой. Условно: CAC, конверсии и т.д.
Проверить потребности, а также ценность приложения. Условно: Retention
Привлечение инвестиций на проект. Условно: важно показать, что есть продукт, клиенты и им пользуются
Экономия ресурсов: вы четко понимаете, что продукт будет урезанным в силу бюджета, а не из-за веры в его успех.

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

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

Пример: запустили MVP в магазин приложений и уже 3–6 месяцев пытаетесь сделать приемлемый CPI. Стоит это того? Скорее всего решение можно было принять после 1 месяца работы.

Когда делать MVP, а когда нет

Отвечу просто — если вы сделали домашнюю работу, провели какое-никакое исследование, проверили гипотезы о существовании рынка и т.д. — можно.

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

Что такое MVP в привычном понимании людей и компаний

И тут есть два убеждения: верное и неверное.

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

Неверное: это урезанная версия полного продукта, где ценность размазана по всему приложению.

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

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

Почему я говорю про одну решаемую задачу для пользователя:

Одна задача — возможность быстро сделать и проверить ваше решение
Две задачи — это уже дорого
Три задачи — это уже 3 задачи, сделанные плохо
Ну вы поняли

Есть мемная картинка, но давайте разберем ее смысл:

В первом варианте решение собирается из каких-то частей, а не представляет собой хоть и небольшое, но законченное решение.

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

Пример: представьте, что вы делаете веб-приложение, которое автоматизирует работу логистических компаний. У вас есть компания на 100 водителей и компания на 1000 водителей — задача может быть одна, но проблемы разные.

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

Про ожидания: если вы сделали только корпус автомобиля, а продаете сам автомобиль, то стоило сделать лендинг MVP и собирать предзаказы, чтобы доставить автомобиль.

Что такое MVP в уже существующем продукте

Важный момент — MVP может существовать и в уже готовом продукте. Как? А очень просто — представим, что вы ищите способы повысить Retention/LTV в приложении по медитации. Возникает ряд гипотез и вы останавливаетесь на решении — ИИ чат-бот, который через компьютерное зрение дает обратную связь по технике выполнения. Сделать такое решение сразу — подписать себе приговор, поэтому вы пойдете делать MVP.

Как можно проверить эту гипотезу через MVP:

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

Почему 3 вариант будет иметь низкую достоверность? А это вопрос вам подумать.

Большинство команд выбрали бы 2 вариант или придумали другое решение. Суть в том, что в существующем приложении MVP-подход также существует.

Есть ли еще варианты реализации MVP — безусловно. У меня нет задачи рассмотреть все возможные варианты.

Про MLP, MMP и RAT

Что это за аббревиатуры:

MLP — Minimum Loveable Product (продукт/фича, достаточный, чтобы его полюбили)
MMP — Minumum Marketable Product (продукт/фича, достаточный, чтобы его можно продать)
RAT — Riskiest Assumption Test (продукт/фича, где вы тестируете самую рискованную гипотезу с самым большим потенциальным выхлопом)

Нужно ли вам использовать эти подходы? А посмотрите на цели, по факту это просто разные версии MVP. Это фреймворки и руководства к действию, которое принесет 100% положительный результат.

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

Что не является MVP

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

Как не перегрузить MVP

Если делаете что-то уникальное: сделайте все, что является базой в решении. Все конфетти, которое не является ценность продукта — выкидывайте.
Если повторяете за конкурентами: отталкивайтесь от целей, если знаете, что сможете заработать — делайте сразу полноценный продукт, а не MVP. Если нет, то определите функционал, на котором они зарабатывают — ваша задача сделать его не хуже. Посмотрите, что конкуренты продают на экране подписки.
Во всех остальных случаях: отталкивайтесь от ожидаемых результатов и бюджетов. Тратить $100k на MVP продукта, который сможет вам потенциально приносить $5k в месяц — не целесообразно. Вы должны целиться в минимальные затраты, которые вы сможете легко окупить.

Как определить, что должно входить в MVP, а что нет

Определите задачу, ради которой покупают приложение у конкурентов
Определите решение, за которое готовы платить люди
Определите, что входит в CORE (БАЗУ) этого решения, а что является дополнительным функционалом
Добавьте CORE и вложитесь в сильный дизайн, сильные текста и т.д.

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

Как определить, что MVP было успешным

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

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

Главная ошибка после успешного теста MVP

— Это продолжать дорабатывать продукт через мелкие изменения или совершенно новый функционал.

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

Например: протестировали каналы, увидели, что 1–2% юзеров покупают подписку — ваша задача понять, а может ли текущее решение дать конверсию выше 2%, например 8%? Т.е. можно долго тюнить монетизацию, пейволы и т.д., но если сам продукт не может дать такую конверсию, то зачем тратить время.

А как понять, что нужно делать полноценный продукт вместо MVP?

И опять, всё будет зависеть от целей.

Заключение

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

Если ваша цель — сразу заработать деньги, а вы сделали продукт, который не отвечает этой цели, то вы сделали MVP неверно. Но и если вы сделали продукт, который решает задачу только частично, то это тоже не MVP, а просто набор функций.

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

Я пишу материалы для Medium, LinkedIn и VC.ru, чтобы быть в курсе всех материалов, рекомендую подписаться на мой канал в телеграме: https://t.me/productcrafting

Я также развиваю стартап T-BOX — AI продукты для повышения эффективности бизнеса.