{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Ultimate MVP: Как делать классные digital-продукты в кратчайшие сроки

Алёна Паньшина, Senior Product Manager в TalentTech, о том, почему для валидации MVP не нужны месяцы подготовки и как проверять гипотезы с минимальной разработкой.

Фотография с конференции ProductSense Минск'18

Меня зовут Алёна, я занимаюсь сервисами рекрутинга в команде TalentTech. У меня всегда одна цель: я хочу выпустить стартап в кратчайшие сроки. Идеальный вариант – это сервис, запущенный без разработки. Мы должны людям предоставлять услугу, их вообще не интересует программное обеспечение, которое мы делаем. Поэтому в команде всегда должен быть продакт-менеджер - его задача качественно валидировать гипотезы и не пропускать ничего лишнего в разработку.

Запускать сервисы за день-два возможно. Для этого необходимо научиться одному контр-интуитивному навыку - ставить себе неудобные дедлайны. Для выхода MVP не нужны длительные сроки как обычно любит ставить разработка. Я как продакт должна вмешаться и сказать команде, что у нас есть всего лишь месяц. В ситуации ограниченности мы начинаем думать по-другому, искать лазейки, придумывать различные варианты реализации.

Покажу на конкретных примерах, как это может быть.

Пример 1. MVP: погрузка грузов через электронную почту

Решение. Это моя любимая история, и случилась она в то время, когда я работала в сервисе для американских дальнобойщиков. Мы подумали, что было бы классно сделать так, чтобы заказчики отправляли список грузов через e-mail. Сроки разработки MVP оценили в месяц и сразу решили, что месяц - это много. Проверить гипотезу мы можем и быстрее.

Поэтому я написала сообщение в Intercom и буквально за пять минут получила фидбек от реальных пользователей. Фидбек был негативным - оказалось, что такая функция вообще не была никому нужна. Так мы себя избавили от месяцев ненужной разработки.

Пример 2. MVP: биржа для грузоперевозок

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

Сначала было страшно. “Наверное, биржу нужно делать месяцами или даже годами”, - думала я. А нам вообще хотелось бы в принципе понять, стоит ли вкладываться в эти месяцы разработки.

Для верификации гипотезы мы сделали специальную кнопку в приложении. Нажатием кнопки инициировалась email-переписка со ставкой за груз, которая “роутилась” на почты. То есть человек кликает на кнопку в приложении, затем выставляет сумму, после чего уходят два письма. Первое - брокеру: “Привет, тебе сделали предложение”, а второе - дальнобойщику: “Привет, ты сделал ставку”.

И всё, у них начинаются торги - та самая биржа. За две недели с помощью этой кнопки были сделаны десятки тысяч ставок, мы закрыли MVP и уже реализовали нормальный полноценный сервис. Вместо трех месяцев работы команды из 12 человек валидация гипотезы заняла две недели разработки с одним инженером.

Пример 3. MVP: хипстерская кофейня в Сан-Франциско

Решение. У одного кафе в Сан-Франциско есть свое приложение, которое позволяет сделать предварительный заказ блюд. После онлайн-бронирования официанту приходит смс или электронное письмо с деталями заказа.

Сделать сервис и прикрутить к нему смс\email - просто, это занимает буквально неделю. Но зато в головах клиентов вы - крутое технологичное молодежное кафе. Все фичи и плюшки можно докрутить постепенно, ведь сервис-то уже есть.

Пример 4. MVP: найм персонала

Недавно запустился Яндекс.Таланты - сервис по поиску работы. Ребята сделали сервис из одного лендинга, который, по ощущениям, можно сверстать за десять минут. И добавили бота.

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

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

ШАГ 1. У вас есть идеальное представление об MVP, вы о нем много думаете, представляете всё в деталях, и разработка говорит, что это займёт минимум 2 месяца. И тут нужно поступить контр-интуитивно: специально поставить цель - сделать за месяц и ни минутой больше. А лучше вообще за две недели.

ШАГ 2. Идеальное представление вы препарируете по функциональным составляющим: формы заполнения, смс-оповещения, push-уведомления, интерфейс и так далее. Просто дробите всё наполнение на мелкие части. И потом для каждого элемента находите аналог, который можно позаимствовать. Например, UI можно заменить google-табличками, и они также будут выполнять функцию заполнения.

ШАГ 3. Люди - лучший бэкэнд! Например, у вас есть товары и есть покупатели. Человек может руками собрать заказ по запросу клиента, и вот вам алгоритм метчинга.

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

ШАГ 4. Вы получаете финальный MVP: всё, что нужно было заменить - заменили, а всё, что нужно оставить - оставили. Минималистичное и лаконичное решение.

Подытожу, самое главное - мы должны предоставлять услугу/сервис. При этом сервис может не иметь интерфейса, но если человек хочет получать продукты по четвергам – он получит продукты по четвергам. Это то, что ему ценно. И наша задача предоставить эту ценность.

0
10 комментариев
Написать комментарий...
Sam Beckett

Хм, либо я что-то не так понял из статьи, либо тут какая-то лютая дичь описана.

Ответить
Развернуть ветку
Arseni Buinitski

Вы что-то не так поняли :)

Ответить
Развернуть ветку
Alexandr Tokmakov

Статья поверхностная, с очень маленькой пользой.

Название: "Как делать классные digital-продукты в кратчайшие сроки".
MVP никак не может быть классным продуктом. Это следует из его определения.
Из 4 предоженных кейсов только 2 имеет отношение к Minimum Viable Function
Из 4 шагов, ценны только 2 и 3

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

2 кейс: Отличный пример.
Делал такое с е-мейлом как средством коммуникации не раз. Но выходило дольше 2х дней, т.к. продукт был не стартап и был Web с долгим процессом тестирования.

3 кейс: Трэш. MVF за неделю? Ради "в головах клиентов вы - крутое технологичное молодежное кафе"???

4 кейс: Странный пример. В рамках Яндекса и обучения Бота, на которого ушло XXXX разработки, возможно. Но какое это отношение имеет к MVP? Какая проблему решает, какие выгоды относительно других способов имеет?
Я ввел первичные данные, возраста, образования, гео и он мне предложил работу в магазине Перекресток. Ну ок, я не ЦА, тогда зачем мне его показывать?

Шаги:
1. Цель не сделать за месяц, а как так верифицировать, чтобы доказать что нужно делать и тратить ресурсы.
2. Согласен на 100%. Дробишь на CJM, блок-схему, просто записи в таблице, а дальше препарируешь.
3. Согласен. НО а) нужна лояльная аудитория (ранние последователи), б) нужен ресурс людей/экспертов , а это не всегда удается делать за 2 дня
4. Вода

Ответить
Развернуть ветку
Олег Нечаев

Супер! Абсолютно согласен. Таким образом запускал проекты. Не осветили одну деталь - нужно попасть в свою ЦА на запуске. Желательно иметь инструмент массированного привлечения трафика. Желательно свой, ну в крайнем случае покупать с тщательной фильтрацией. То есть выборка должна быть репрезентативной. Если вы показали свой сервис сотне человек из 100% вашей аудитории, то проверять на тысячах большого смысла нет, можно просто увеличивать аудиторию плавно. А если вы загнали 10 000 пользователей из которых треть ботов, треть индусов и треть непойми кого, то любой ваш MVP схлопнется. Не все делается за пару дней, но 2 недели подходящий срок для того, чтобы выкатить что-то осмысленное. Естественно, когда есть люди, заготовки и мысли.

Ответить
Развернуть ветку
Григорий Бурачевский

Подписываюсь по каждым словом.

Ответить
Развернуть ветку
Dima Kotobotov

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

Ответить
Развернуть ветку
Da Apricot

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

Также мне кажется без слаженной и опытной команды такие вещи трудно реализовать.

Ответить
Развернуть ветку
TETA ETA

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

Ответить
Развернуть ветку
Dmitry Turmyshev

сам так делаю, все должно пройти «коленку»

Ответить
Развернуть ветку
Цой жив

"У меня всегда одна цель: я хочу выпустить стартап в кратчайшие сроки. "
У такого метода есть даже свое название:

Ответить
Развернуть ветку
7 комментариев
Раскрывать всегда