Методы проверки гипотез. Результаты беседы с продактом из ВТБ. Разговор с продактом из ВТБ

Недавно я готовил курс для Нетологии для новичков-продактов. Есть ощущение, что у всех разное представление о том, какие бывают инструменты проверки гипотез и для чего они используются. Информация из статей в медиа разнится между собой. Хочется создать некую универсальную “памятку”, которая разложила бы по полочкам все по этой теме. В рамках статьи я подчеркнул базовые мысли и выводы, к которым мы пришли в рамках стрима с автором канала https://t.me/productgames.

Кому не подходит вариант статьи, то есть стрим https://youtu.be/-Bnzohta2ng

Пару слов про гостя

Основное место работы - ВТБ. Там я работаю над мобильным приложением для малого и среднего бизнеса и являюсь его PO. В качестве дополнительных увлечений введу блог (product gains), консультирую стартапы по тестированию и запуску идей, а также веду проекты по типу кейс клубов и продуктовые интенсивы.

— Как ты попала в продакт-менеджмент? Пришла туда изначально или занималась чем-то смежным?

— В продакт-менеджмент я пришла не сразу. Начинала с консалтинга, работала консультантом PWC. Сначала занималась налогами, а потом поняла, что все наши проекты бесполезны. Как раз тогда я познакомилась с девочкой, которая работала в Яндекс Такси. Мы начали активно его развивать, и это показалось мне интересным. Я начала искать возможность устроиться на продакта. Так получилось, что в стартапе моих знакомых как раз была вакансия. Они искали человека, который настроит процессы и поведет дальше их продукт. Я присоединилась и с тех пор больше не уходила из технологий.

— Что ты думаешь по этому поводу и какой разрез было бы лучше использовать, чтобы расположить все инструменты для проверки гипотез?

— Интересный вопрос. В целом, я бы исходила из стадии развития продукта и располагала бы инструменты в зависимости от неё.

Этапы жизненного цикла продукта

Давай подробнее поговорим о том, какие этапы жизненного цикла продукта можно выделить:
- Preseed - этап перед привлечением инвестиций
- Product market fit
- Вывод на рынок
- Рост
- Зрелость
- Упадок

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

Инновации в ВТБ

— Кстати, давай поговорим о корпоративных инновациях в больших компаниях. В 2018 я побывал в корпоративном стартапе, и это было отвратительно. Сейчас ты работаешь в ВТБ, в большой организации. Как там с этим обстоят дела?

— ВТБ сейчас следует Сберу. В целом, мы сотрудничаем со стартапами: у нас есть внутренний акселератор, который подбирает стартап проекты и предлагает им программы для создания пилотов вместе с банком. Это происходит так:

1. Приходит стартап, рассказывает про свой продукт, а мы, как подразделение, в том числе отвечающее за отбор стартапов, смотрим, чтобы продукт не был зеленым и был уже был опробован.

2. Далее акселератор собирает все продукты и рассылает их по подразделениям. Те из них, к которым выразили интерес, подразделения, могут начать пилотирование внутри банка. По завершении пилотирования успешным стартапам акселератор выплачивает деньги.

Всё это реализуется не без затруднений. Возникает множество бюрократических моментов, так как заключение контрактов с внешним контрагентом - это всегда непросто. Сейчас эту проблему пытаются решить. Насколько я знаю, в других местах существуют типовые формы, которые могут быстро заключаться. У нас их пока нет, и из-за сложного процесса бюрократии и длительной реализации суть инновации немного теряется. Есть еще один момент - если есть внешнее решение, внутри которого передается чувствительная информация, банк будет склонен его выкупить, чтобы настроить внутреннюю систему. Этот процесс также реализуется недостаточно быстро. Что касается внутренних стартапов, они тоже есть. Например, проверка контрагентов. Но это отдельное подразделение, у них есть свои заказчики, для которых они делают модели.

Ходим от рисков

Я люблю ходить от рисков. На этапе preseed у нас есть только идея и мы выделяем самые рискованные гипотезы. Я выписываю все свои рискованные предположения и вижу, что самое рискованное предположение, например, связано не со спросом, а с рынком. Например, объемы рынка недостаточно велики. Первое, что я пойду делать - изучать рынок. Но если я, например, понимаю, что у меня есть сомнения о востребованности продукта среди юзеров, то один из самых дешевых методов тестирования моей идеи - кастдевы. Можно провести Jobs to be Done интервью, чтобы узнать, есть ли у пользователя задачи, которые мой продукт сможет закрыть, и если есть, то перейти далее к проблемным интервью. Если на этапе preseed мы выявили возможные проблемы со спросом на продукт, то cusdev - один из самых дешевых методов проверки на начальном этапе.

— Я бы добавил, что когда мы только пытаемся найти проблему/боль/пользовательский инсайт, нам как раз-таки нужен инструмент, с помощью которого мы будем исследовать пользователя. На этом этапе это актуально как никогда: у тебя нет никакой информации, а проблему найти нужно.Давай рассмотрим другие стадии. Для зрелых продуктов и вообще для тех, кто уже вышел на рынок, насколько этот инструмент применим и нужен?

— У меня был интенсив с основателем Мартех-стартапа, и он сказал, что хороший продакт знает своих юзеров. И, соответственно, даже при зрелых продуктах надо периодически общаться с пользователями, чтобы вы не теряли с ними связь, знали их боли и жили их проблемами и задачами.

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

— Можешь пару слов сказать о Jobs to be Done? В принципе, все так или иначе слышали об этом. Но что именно вы вкладываете в этот инструмент?

— Jobs to be Done фактически формулируется следующим образом: когда я хочу что-то сделать, чтобы что-то получить, мы исходим не из персоны пользователя, а из задачи, которая перед ним стоит. Используем его для того, чтобы сформулировать, зачем мы делаем ту или иную фичу, как она поможет нашему пользователю. Перед JTBD интервью мы выделяем направления, про которые будем спрашивать, и формулируем вопросы. Например, если нам интересно, как человек проверяет своих контрагентов, мы спрашиваем его про весь процесс проверки. Потенциальный пользователь рассказывает, через какие шаги он проходит, а мы пытаемся понять, что ему нравится и как часто он этим занимается. На основе этой информации мы понимаем контекст ситуации, его мотивацию и конкретные желания. Если человек делает проверку контрагентов перед заключением договоров с мелкими фирмами и когда делает платеж, мы понимаем, где конкретно нам лучше встроить эту фичу. Его мотивация состоит в том, что его не обманут и налоговая не заберет положенные ему выплаты за связь с недобросовестным контрагентом. Мы собираем всю эту информацию и исходя из этого можем более точечно спроектировать фичу под запросы пользователя, чтобы она логично ложилась в его привычный распорядок.

— То есть, если говорить про акторов, userstory - это фокус на эмпатию? А здесь я - это как таковая система? Или же здесь есть обязательная привязка к человеку/лицу/роли?

— В Userstory есть привязка к именно профилю юзера, что, как мне кажется, дает не очень много информации с точки зрения продукта, как именно Jobs to be Done. Здесь происходит замен профиля юзера на конкретную ситуацию. Сравнение JTBD и Userstory - классический случай. Это как батончик сникерса. Вне зависимости от того, каким юзером ты являешься, у тебя есть задача. Причем задача одна и та же и ученика, и у учителя, и у банкира - быстро насытиться. Для нас неважно, что за профиль у юзера, мы должны просто решить задачу.

Посадочная страница

— Давай двигаться дальше: ты создала lending page с каким-то трафиком и value proposition. Скажи, пожалуйста, где это использовать?

— Его можно использовать для того, чтобы протестировать спрос на продукт. Получается, что у нас есть идея продукта, в котором мы уверены. Уверенность может рождаться из нашей экспертности. Например, я учитель и вижу проблему Х, ощущаю ее на себе и хочу потестить. Считаем, что нам незатратно сделать лендинг: за 2 часа собрать его на Тильде. Если я не уверен, есть вероятность, что мне придется несколько раз на лендинге ее переделывать, и, возможно, с точки зрения времени, есть более дешевый способ проверки гипотез. Например, кастдевы. Соответственно, лендинг пишется, когда у меня есть сформированная идея, понимание ЦА и того, что я могу предложить с точки зрения ценности для клиента. Я описываю это на лендинге и оставляю на нем форму для записи с лид-магнитом. Если пользователь оставляет контакты, то мы можем считать, что он хоть как-то заинтересован в нашем продукте.

— Это такой элемент фиксации намерений, да? В решенческих интервью это письмо, гарантия о будущем сотрудничестве.

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

Это большая боль и проблема, когда ты бредишь: создал себе мир, в котором твой продукт необходим, и в нем находишься.

Есть еще очень важный момент. Бизнес, стартап - это про масштабирование воронки. Чтобы это масштабировать, желательно, чтобы это число было положительное и было в принципе: ноль масштабировать смысла нет. Хотя нет - легко масштабировать, умножаешь на что угодно и получаешь ноль