Через год приложение готово. В нём личный кабинет с уровнями, программа лояльности, чат с поддержкой, push-уведомления с сегментами, админка, где можно настроить почти всё, и три роли пользователей.
Пользуются одним экраном. Деньги закончились. На то, чтобы привести людей и разобраться, почему они не возвращаются, бюджета уже нет.
Историю ниже я собрал из повторяющихся разговоров, а не из одного проекта: ко мне приходят и до запуска, и после — со словами «у нас уже есть приложение, но с ним что-то не так». Детали каждый раз разные, а механика одна.
И главное в ней вот что: ненужной функция становится видна потом. В момент, когда её добавляют, решение выглядит вполне разумным — а бюджет уходит не на одну большую ошибку, а на цепочку таких решений.
В этом и сложность: типичные ошибки стартапа на этом этапе выглядят не как ошибки, а как забота о продукте. Ниже — шесть ошибок MVP, из которых и складывается такой год.
1. Функция попала в список, потому что её никто не оспорил
Обсуждение продукта устроено так, что предложить легче, чем отказать. Один человек говорит «нужен ещё чат с поддержкой», остальные не возражают — возражать неловко и нечем: аргументов против ещё не существует, продукта тоже.
Через месяц чат стоит в техническом задании как решённый вопрос. Никто его не защищал — просто никто не снял.
Вопрос, который это ловит, звучит неудобно: какую задачу человек решит этой функцией сразу после запуска — и что сломается, если её пока не будет? Не «пригодится ли она когда-нибудь»: пригодиться может почти всё, и на этом вопросе не отсеивается ничего.
2. «Раз уже делаем — давайте добавим, это же мелочь»
Мелочь измеряется не собственным размером, а числом связей, которые она тянет.
«Добавить роль администратора» звучит как один экран. На деле это права доступа в каждом разделе, отдельный вход, отдельные состояния интерфейса, страница со списком пользователей, логика «что видит администратор, чего не видит клиент» и проверка всего этого при тестировании.
Такие добавления не выглядят решениями. Они выглядят уточнениями — и именно поэтому проходят без обсуждения бюджета.
3. Ориентиром взяли конкурента, а не собственного пользователя
«У них есть подборки — значит, нам тоже нужны».
У конкурента за этой функцией может стоять что угодно: три года данных, накопленная аудитория, отдел, который её ведёт, или собственная ошибка, которую он ещё не признал. Вы копируете результат, не зная ни причины, ни того, работает ли это у него вообще.
Приложение конкурента — это витрина. По витрине не видно, что продаётся, а что стоит для вида.
4. Сначала построили фундамент «на вырост»
Решение звучит по-инженерному ответственно: заложим архитектуру так, чтобы потом легко добавлять что угодно.
Проблема в том, что «что угодно» — это функции, которых, возможно, не будет. Универсальность стоит денег сразу, а окупается только в том будущем, где вы угадали направление роста.
Здесь важно не перепутать две разные вещи. Архитектуру первой версии всё равно надо делать нормальной — не загонять себя в технический тупик, из которого потом не выбраться без переписывания. Но это не то же самое, что заранее оплачивать универсальную систему под пять будущих сценариев, которых пока не существует. Первое — обязательная работа, второе — ставка на угаданное направление роста.
5. Никто не сформулировал, что считается успехом
Это ошибка, из которой растут все остальные.
Пока не сказано, какую именно гипотезу проверяет первая версия и по какому признаку станет понятно «сработало», отрезать нечем. Любая функция защищается фразой «а вдруг без неё не пойдёт», и возразить на это нечего: критерия нет.
Критерий не обязан быть сложным. «Люди, которым мы показали продукт, возвращаются на второй раз без напоминания» — уже критерий. Из него сразу видно, что в первую версию входит, а что к проверке отношения не имеет.
У другого продукта критерий будет другим: оставленная заявка, оплаченный заказ, приглашённый коллега, повторное действие через месяц. Важно не само число и не его красота, а то, что команда договорилась заранее, какое поведение людей считается подтверждением гипотезы.
6. Показ пользователям отложили до готовности
«Покажем, когда будет прилично».
Год без пользователей — это год без единого возражения извне. Все решения принимаются внутри команды, где у всех примерно одинаковые представления о продукте, и проверить их не на ком. Ошибка первого месяца доживает до релиза просто потому, что её некому назвать.
Здесь же и объяснение, почему первая версия должна быть небольшой: её ценность не в том, что она умеет, а в том, что она отвечает на вопрос. Продукт, показанный на третьем месяце и вызвавший разочарование, дешевле продукта, показанного на двенадцатом и вызвавшего то же самое.
Ошибка, которой нет в этом списке
Из разговора про экономию иногда делают обратный вывод: MVP — это когда сделано по-быстрому и криво, лишь бы дёшево.
Так не работает, и путаница обходится дороже всех шести пунктов выше. Сырой продукт не проверяет гипотезу: если человек ушёл, вы не узнаете, идея ему не нужна или просто кнопка не нажималась. Ответить на вопрос «нужно ли это людям» может только та версия, которой можно нормально пользоваться.
Урезается не качество, а объём. Один сценарий, доведённый до конца, вместо пяти начатых.
Почему ошибки MVP не видно по дороге
Ни одна из шести ошибок при разработке первой версии не заметна в тот момент, когда её совершают. У этого три причины.
Каждое решение по отдельности дешёвое. Никто не утверждает бюджет на чат с поддержкой — его добавляют в список. Стоимость появляется не в момент решения, а в момент сложения.
Функции дорожают друг от друга. Десять функций — это не десять работ, а десять работ плюс связи между ними: как ведёт себя лояльность при отмене заказа, что видит администратор в чужом чате, что происходит с уведомлениями у пользователя, который вышел из аккаунта. Проверять приходится сочетания, а их всегда больше, чем пунктов в списке.
Обратной связи нет вовсе. Пока продукта нет у людей, единственный источник мнений — команда. Год работы вслепую выглядит изнутри как год нормальной работы: задачи закрываются, экраны появляются, движение есть.
Сколько это стоит в деньгах
Полноценное приложение для iOS и Android у меня начинается от 950 000 ₽, MVP — от 250 000 ₽ (все три формата запуска и их состав). Разница между этими суммами — не разница в качестве работы. Это разница между «сделали всё, что придумали» и «сделали то, что проверяет гипотезу».
Дорогая часть истории даже не в первой сумме. Она в том, что после года разработки деньги кончаются ровно тогда, когда начинается настоящая работа: привлечение людей, наблюдение за тем, что они делают, и переделка продукта под увиденное. Из чего складывается бюджет приложения и почему одна и та же задача стоит по-разному — я разбирал в статье сколько стоит мобильное приложение, там три сценария запуска и состав каждого.
Что делать вместо этого
Не «делать поменьше». Делать под гипотезу. На этом уровне всё сводится к трём вещам.
Назвать гипотезу. Одно предложение: какое поведение людей подтвердит, что продукт нужен.
Оставить только то, без чего её нельзя проверить. Остальное не отменяется, а ждёт своей очереди.
Показать продукт живым людям как можно раньше. Дата показа дисциплинирует состав первой версии сильнее любого списка требований.
По срокам скажу честно и без чисел: MVP с одним главным сценарием — это ориентировочно несколько недель, полноценный продукт заметно дольше, а точный срок называется после разбора задачи. Что входит в первую версию и как она устроена — на странице разработки MVP; там же реальный проект, собранный именно по такому принципу.
Если приложение уже сделано
Отдельно про тех, кто читает это с готовым продуктом на руках. Ошибки при запуске приложения тем и неприятны, что обнаруживаются, когда деньги уже потрачены.
Год потрачен, и вернуть его нельзя — но данные, которых не было в начале, теперь есть. Видно, каким экраном пользуются, а каким нет; видно, где люди останавливаются. Это ровно та информация, ради которой затевается первая версия, только досталась она дороже.
Дальше работает тот же принцип: выбрать одну гипотезу, снять с неё всё лишнее и проверить. Разница лишь в том, что теперь у вас есть продукт, на котором это можно сделать быстрее и дешевле, чем с нуля.
А если вы как раз собираете первую версию и список функций уже начал разрастаться — пришлите идею и главный пользовательский сценарий. Посмотрю на список с одним вопросом: что отсюда можно убрать, не потеряв проверку гипотезы.
И ещё одно, из-за чего эту статью стоило писать: ошибки MVP не заканчиваются на первой версии. Тот же список работает при каждом крупном обновлении — функция, которую никто не оспорил, и фундамент «на вырост» приходят снова, просто теперь у них есть оправдание в виде уже написанного кода.