Разработка MVP для стартапа и нового продукта

Новый сервис можно проверить на настоящих клиентах задолго до того, как на него уйдёт бюджет полной разработки. Для этого собирают MVP, первую версию продукта, в которой от начала до конца работает один главный сценарий. Мы делаем такие версии для стартапов, которым нужно показать продукт первым клиентам и инвесторам, и для компаний, которые запускают новый кабинет, платную услугу, внутренний сервис или приложение. До первой строки кода договариваемся, какое поведение пользователей будет означать «продолжаем», и закладываем в продукт аналитику, которая это поведение покажет. Работа начинается с обследования длиной около двух недель.

Этапы разработки MVP

Порядок у нас один и тот же, меняется только содержание шагов:

1. Выписываем допущения, на которых держится идея, и находим самое дорогое из них: если оно неверно, остальное теряет смысл.
2. Собираем кликабельный прототип и показываем его нескольким будущим пользователям.
3. Делаем первую рабочую версию одного сценария, с настоящими данными, ролями и обработкой ошибок.
4. Выпускаем её к пользователям вместе с аналитикой: сколько человек дошли до конца сценария, сколько вернулись, сколько заплатили.
5. По цифрам решаем, что дальше: развивать продукт, менять предложение или остановиться.

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

Личный кабинет с одной операцией

Возьмём компанию, где 3 000 клиентов звонят менеджерам за документами и статусами заявок, и руководство думает о личном кабинете с 12 разделами. Первая версия получается гораздо уже. Клиент входит, проводит одну частую операцию, например заказывает документ или проверяет статус заявки, и получает уведомление, когда всё готово.

Зато эта операция работает целиком, от входа до уведомления, и данные в ней настоящие, из вашей учётной системы. Набор экранов без такого сквозного пути выглядит как продукт, но ничего не проверяет. Вскоре после запуска у компании есть ответ на главный вопрос: сколько клиентов провели операцию сами и стало ли меньше звонков менеджерам. Ради этого кабинет и затевался. Если за первый месяц это сделали 300 человек из 500 приглашённых, кабинет стоит развивать. Если 20, разговор пойдёт о том, что клиентам мешает, и остальные 11 разделов подождут ответа.

Сигнал, по которому решают о следующем бюджете

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

«Клиенты не станут пользоваться первой версией»

Если так и выйдет, MVP сделал свою работу, причём раньше, чем на продукт ушли большие деньги. Аналитика покажет, на каком шаге люди уходят. Бывает, что продукту нужна не новая функция, а другое предложение или другой первый экран. Иногда честный вывод звучит как «идею закрыть», и лучше услышать его на первой версии, чем после года разработки.

Обследование начинается с допущений

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

Выпускать продукт к настоящим пользователям мы умеем и на своём примере: Tuto, наше приложение для iPhone и Android, вышло в App Store и RuStore и разбирает банковские выписки и результаты анализов. После запуска действует трёхмесячная гарантия, она уже учтена в цене, а исходный код, документацию и доступы к серверам получаете вы.

Вопросы о создании MVP