РАЗРАБОТКА MVP - КАК ДЕЛАТЬ НЕ НАДО
С чего начать разработку MVP? Каким он должен быть? Какие ошибки чаще всего совершают руководители? В этой статье поделюсь своим опытом.
Если вам удобнее слушать, то включайте мое видео.
Меня зовут Валерий Комягин, я основатель и руководитель SVK.Digital. Помимо заказной разработки, мы работаем как венчурная студия и занимаемся со-инвестированием в стартапы, предоставляя ресурсы разработки, маркетинга, юридическую поддержку и техническую экспертизу. Сегодня в нашем портфеле игровая платформа PARTYstation и парольный менеджер BearPass, на который недавно получили грант Фонда содействия инновациям.
Казалось бы, про MVP уже всё обсуждено 10.000 раз. Но я в своей практике сталкиваюсь раз за разом с довольно типичными ошибками. Итак, начнем! Сейчас очень распространены теории, что перед тем, как переходить к разработке MVP, нужно провести массу исследований. Есть множество фреймворков: customer development (глубинное интервью), customer journey map (составление пользовательских карт), концепция jobs to be done (изучение мотивации пользователя). Это очень хорошие и правильные фреймворки, но я не советую ими увлекаться. Важно всё — таки помнить, что любой стартап, любой продукт — это бизнес. Суть бизнеса — это решение проблемы клиента и получение за это прибыли. Поэтому, на старте, когда вы запускаете свой продукт, у вас должна быть одна стартовая гипотеза, которую нужно протестировать. И здесь возникает первая ошибка. Вам кажется, что вы нашли боль, за которую клиенты готовы платить. Ключевое слово здесь «кажется». Я сталкивался с ситуациями, когда предприниматели говорят: «Я рассказал свою идею друзьям и все сказали, что это классная идея, они бы за это заплатили»; «Я провел несколько опросов и потенциальные клиенты сказали, что они с радостью заплатили бы за такой продукт». Правда в том, что между обещанием заплатить и деньгами на счету большая пропасть. Поэтому основная задача на старте — это как раз понять, будут они платить или нет. Как раз MVP помогает проверить правдивость обещаний ваших респондентов. Это так называемая ловушка перфекциониста: «Продукт ещё недостаточно хорош, чтобы показать его клиентам. Мы не сможем вернуть людей, если им не понравится. Они уйдут и никогда к нам не вернутся». И тогда основатель продукта закладывает в MVP такое количество функций, что разработка может занять полгода, год, а может быть даже годы. Каждый раз он обосновывает это тем, что без этих функций мой продукт не будет работать, всё это будет работать только в комплексе. Ответственно заявляю, что это ошибочное мнение! Это так называемая ловушка эксперта, когда созданием продукта занимается человек, хорошо разбирающийся в отрасли. В этом случае он говорит: «Я прекрасно знаю отрасль и боли рынка. Мне не нужны никакие исследования. Мне не нужно ничего тестировать. Я точно знаю, как нужно сделать». Это приводит к тому, что продукт уходит зачастую в тупиковую ветку. То есть создаётся продукт, который на деле нужен только вот этому одному эксперту, а на рынке такой боли нет. В далеком 2015 году, когда мы только начинали работу со стартапами, к нам обратились голландцы с идеей проекта TastyClub. Это была система лояльности для кафе и ресторанов в Нидерландах. Нас попросили создать функционал почти полноценного продукта. Тогда, по своей неопытности, мы не смогли убедить клиента срезать функционал MVP до минимума. В итоге продукт не нашел спроса на рынке, владельцы ресторанов не проявили должного интереса. Проект пришлось закрыть. Но это можно было выяснить, потратив меньшее количество денег и времени, если бы MVP содержал только ключевую функцию. Совсем иначе сложилась судьба другого нашего проекта PARTYstation. Это игровая платформа для Smart TV. На рынок мы выходили с пилотом, который содержал только квизы, построенные на видеороликах с вопросами и ответами. Его мы сделали за 3 месяца. Пользователи встретили наш продукт очень тепло и благодаря обратной связи, мы начали активно его развивать. База игр разрослась до сотни. Мы заключили договор с Xiaomi, Сбером, Ростелеком, Google.Play. Каждый месяц аудитория проекта увеличивается на 30-50%, сотни подписчиков, десятки тысяч посещений! 1. Зафиксируйте основные требования к вашему проекту Подготовьте краткое описание. Оно не должно быть большим, это не техническое задание. Зафиксируйте ключевые функции, которые по-вашему мнению пользователь продукта должен будет выполнить, чтобы получить пользу. 2. Сократите ваши требования Оставьте только самую важную функцию, которая решает ключевую проблему потребителя. Выкиньте оттуда всё лишнее. Мы пытаемся протестировать гипотезу, поэтому нам нужен компактный небольшой продукт, выполняющий единственную функцию. 3. Обязательно ограничьте себя в сроках Наша цель—запустить MVP максимум за 3 месяца, а лучше за 3-4 недели. Чем короче срок, тем лучше. За это время вы должны успеть создать не только mvp продукта, но и лендинг, если он нужен для привлечения продаж. 4.Обязательно ограничьте себя в деньгах Если вы этого не сделаете, вы попадете в самую частую ловушку и уйдете в бесконечную разработку, в «вечнострой», как я его называю. На это вы потратите неограниченное количество денег, особенно, если они у вас есть. И это будет ошибкой. 5.Разработав mvp, запускайте! Начинайте продавать, не ждите. Пытайтесь найти людей, которые увидят ваш продукт, посмотрят вашу презентацию, пощупают продукт и будут готовы вам заплатить. 6.Получайте обратную связь как можно быстрее Когда вы запустили MVP, начинайте общаться с теми, кто купил. Начинайте общаться с теми, кто не купил. Фиксируйте мнения и улучшайте ваш продукт, стремясь сделать как можно больше продаж! Ключевой совет — MVP нужно делать как можно быстрее и за как можно меньшие деньги. А дальше действовать по концепции MVP + итерационные улучшения шаг за шагом.
ПЕРВАЯ ОШИБКА
ВТОРАЯ ОШИБКА
ТРЕТЬЯ ОШИБКА
КАК ЗАПУСТИТЬ MVP МАКСИМАЛЬНО ЭФФЕКТИВНО И БЕЗБОЛЕЗНЕННО
ИТАК, КАКОЙ ЖЕ МОЖНО СДЕЛАТЬ ВЫВОД?
