Меня зовут Иван Кесель, я владелец продукта «Операции с недвижимостью» в ДомКлик, ранее был владельцем продукта мобильного приложения «Спасибо от Сбербанка».
Я работаю в Sbergile три года.
Доход от продажи услуг нашей команды измеряется сотнями миллионов рублей, а количество сделок с недвижимостью измеряется десятками тысяч в год. Я расскажу о том, как запустить продукт с ограниченное количество ресурсы и время.
Но сразу предупрежу: если необходимый Если у вас нет ресурсов, вы не запустите продукт. Волшебной таблетки не существует. Хватит верить в сказки.
Но если вам нужен практический совет, то читайте дальше.
Мы рассмотрим три основные проблемы, которые могут возникнуть при быстрой проверке гипотез.
Расскажу на примерах конкретных запусков продуктов нашей команды.
ДомКлик — это не только операции с ипотечным кредитом, но и продажа недвижимости без кредита, когда покупатель и продавец уже нашли друг друга и им нужна помощь в обмене недвижимости на деньги.
На момент запуска продукта и проверки гипотезы, о которой я буду говорить, у нас уже было несколько отдельных сервисов:
- безопасный платежный сервис;
- электронная регистрация службы прав собственности;
- услуга по проверке юридической чистоты квартир.
Наша гипотеза заключалась в следующем.
Если покупатель и продавец где-то нашли друг друга и обо всем договорились, то в услугах сторонних специалистов они больше не нуждаются.
Все, что им нужно сделать, это заключить сделку.
И мы верили, что найдутся клиенты, которые не захотят разбираться в каждом отдельном продукте, который у нас есть, и им понравится идея купить один пакет услуг, не требующий никакого изучения.
Это именно тот продукт и гипотеза, которые мы тестировали.
Запуск продукта и проверка любой гипотезы начинается с MVP — минимального продукта.
Почему средний ряд не является MVP? Казалось бы, функциональность постепенно увеличивается, почему бы и нет? Конечно, эта серия подойдет, например, если вы развозите заказы, то вполне можно сначала доставить их на скутере, а потом дорасти до грузовика.
Но для многих ИТ-продуктов такая схема не подходит.
Первая проблема
Вы выдвинули большую гипотезу, хотите запустить большой продукт, но у вас нет мало ресурсов .Идея кажется ошеломляющей, и вы не знаете, с чего начать.
Здесь «нет ресурсов для запуска продукта» может означать что угодно.
В такой ситуации четко сформулируйте свою гипотезу.
Ответьте себе, что именно вы хотите проверить? Можно ли упростить гипотезу, а вместе с ней и продукт? Действительно ли все ее компоненты необходимы для ответа на гипотезу? Отрежьте все ненужное.
Вы придумали большую идею, которая, похоже, разрушит рынок.
Похоже, это большой грузовик, который невозможно запустить в эксплуатацию.
Нужен ли MVP автопоезд-мигалка на крыше? Вам нужен такой большой корпус? И нужно ли вообще тело? А теперь то же самое на примере нашей гипотезы «Сделка под ключ».
Мы начали представлять, что должно быть в этом товаре, чтобы его купили.
Естественно, личный кабинет, в котором клиент может просмотреть всю информацию.
Должна быть интеграция со всеми сервисами, чтобы автоматически подтягивались данные и отправлялись заявки.
Должен быть менеджер, какая-то богатая витрина с объектами для подключения.
Запуск такого продукта потребует огромного количества ресурсов.
Но если нет возможности их выбить или задержать запуск MVP, то нужно обратить внимание на функционал.
Важное правило : Нельзя просто так отказаться от некоторых частей.
Если что-то удаляете, обязательно проверьте текст гипотезы.
Например, мы хотим проверить, есть ли люди, готовые зарегистрироваться и автоматически активировать услугу.
в вашем личном кабинете , или нам достаточно просто подтвердить наличие те, кто хочет одолжения ? Пока вы задаете такие вопросы, вы можете постепенно потерять часть функционала.
Может оказаться, что для проверки отдельного пакета можно обойтись не только без личного кабинета, но и без автоматической интеграции с сервисами – менеджер сам может подключиться и заполнить все необходимые заявки.
Мы пришли к выводу, что для запуска нашего MVP достаточно одного менеджера.
Он может передать по телефону всю информацию, которую мы хотели отобразить в личном кабинете.
Вторая проблема
Мы придумали большую гипотезу, потом сократили ее, но оказалось, что необходимой команды для быстрого запуска и тестирования такого продукта нет. Например, нет разработчиков, а есть только менеджеры или дизайнеры, или наоборот, вся команда состоит из разработчиков и совершенно нет людей, которые бы рисовали интерфейсы и прототипы.На момент запуска в нашем проекте не было менеджеров по работе с клиентами.
Если вы работали в крупной компании, вы можете себе представить, каково это – бороться за нужные ресурсы.
На одобрение и подтверждение эффективности могут уйти месяцы.
У нас не было этого времени.
Команда состояла только из бэкенд- и фронтенд-разработчиков, и ничего хорошего из этого не получилось бы, если бы мы попытались привлечь их к обзвону клиентов.
Что делать, если вы считаете, что вы или ваша команда слабы?
Здесь помогут Т-образные принципы развития навыков: откажитесь от стереотипных ролей в коллективе.
Не относитесь к командным ролям как к чему-то высеченному в камне.
Что бы ни было написано в письме о приеме на работу человека, не бойтесь открыто обсуждать со своим коллективом возможности сотрудничества и дублирования ролей.
Мы думали, что обидим старшего или среднего инженера, если попросим его за день разобраться с запросами клиентов.
Или полдня отвечать на звонки клиентов, слушать людей, получать обратную связь.
Но на деле все оказалось не так.
Когда мы пригласили наших ребят-разработчиков помочь нам разобраться в запросах клиентов, они оказались очень заинтересованы и воодушевлены.
Для них было радостью отдохнуть от повседневной работы в редакторе и отправиться в поле, общаться с клиентами и узнавать об их опыте и потребностях.
Смена ролей дает очень хорошие результаты:
- доставляем продукцию быстрее;
- команда остается очень мотивированной, потому что видит, что делает каждый день;
- ценность продукта увеличивается, потому что мы не тратим время на формулирование задачи получения обратной связи и передачу ее туда и обратно;
- Сотрудники непосредственно участвуют в разработке продукта и эффективно определяют функции, которые повышают ценность для клиентов.
Третья проблема
Вы определились с продуктом и согласились поменяться ролями в команде.И теперь ты не знаешь, куда идти, ты нет плана действий по разработке и запуску гипотезы .
В результате команда не знает, что делать, и не имеет единого списка задач.
Все начинают ожидать от сотрудников бизнеса — менеджеров или специалистов по работе с клиентами — подготовки задач, а разработчики тем временем могут сидеть сложа руки.
Конечно, в самом начале проекта никто не может точно представить, как должна работать система.
Этого понимания все ждут от руководителя.
И существует очень большой дисбаланс между бизнес-служащими и техническими специалистами.
Менеджерам предстоит проделать большую работу по описанию всех задач, и их ресурсы не безграничны.
Если бы мы работали по водопадной модели управления проектами, мы бы столкнулись с так называемым аналитическим параличом, связанным с необходимостью разработки технических требований перед началом работ. Мне пришлось бы рисовать диаграмму Ганта и следить за ростом графика аналитики.
Нам пришлось бы пить ромашковый чай и расстраиваться.
А при гибкой модели управления графики на диаграмме разбиваются на короткие спринты, постепенно чередуя анализ, программирование и релиз.
Но я хочу предложить другое решение.
Чтобы избежать аналитического паралича, необходимо, чтобы команда сама описывала и анализировала все предстоящие задачи.
Даже если вы уже давно работаете в Agile, все равно есть команды, работающие по гибкой методологии, в которой большая часть ресурсов владельца продукта посвящена описанию задач и формулированию целей.
И он не только растрачивает свои ресурсы, но и берет на себя одеяло ответственности за те или иные решения.
Это не правильно.
Важно доверять своей команде, по-настоящему сотрудничать, перекладывать ответственность на команду полностью или частично, чтобы команда сама обсуждала, спорила, искала какие-то решения и анализировала.
Во-первых, это приводит к неожиданным решениям.
То, что могло не прийти в голову разработчику бизнеса, может внезапно и легко прийти в голову техническому специалисту, потому что он уже сталкивался с этим раньше.
Кроме того, ошибок будет меньше, поскольку технические специалисты непосредственно видят результаты своей работы.
Наконец, команда видит ошибки и поэтому заинтересована в написании наилучшего кода.
Одно дело, когда ты работаешь за столом, пишешь задачи, которые никому не видны, и совсем другое, когда ты четко видишь свои результаты и общаешься с клиентами, твоя мотивация значительно возрастает.
Выводы
Три описанных примера позволили нашей команде запустить и проверить нашу гипотезу в рекордно короткие сроки: от идеи до первых денег в кассе за 15 дней.Они не просто совершили какую-то холодную или горячую продажу, получив согласие клиента по телефону, а заработали – клиент заплатил за услугу.
Таким образом, мы подтвердили нашу гипотезу о том, что есть такие смелые люди, которые нашли друг друга и готовы довериться стороннему сервису в Интернете, а не общаться с человеком вживую.
Важно не останавливаться после подтверждения гипотезы и не забывать, что вы отключили какой-то функционал.
Впереди еще много работы для полного тестирования и запуска продукта.
Если у вас есть успех сейчас в виде запуска и быстрого тестирования гипотез, это не значит, что рынок не отвергнет ваш продукт позже.
Это не означает, что продукт станет самоокупаемым.
Вероятно, вам понадобится смелость, чтобы закрыть продукт в какой-то момент в будущем.
Если обобщить весь наш опыт, то можно вывести 4 простых правила:
- Четко формулируйте свои гипотезы.
- Не стесняйтесь экспериментировать в команде.
- Описывайте не задачи, а потребности.
- Поделитесь своими результатами.
Теги: #Разработка стартапа #Управление проектами #стартап #Управление продуктом #mvp #запуск нового продукта #проверка гипотез #владелец продукта
-
Леденец Для Всей Z-Серии!
19 Oct, 24 -
Грамотный Аудит Безопасности Сайта
19 Oct, 24
