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

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

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

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

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

— В продакт-менеджмент я пришла не сразу. Начинала с консалтинга, работала консультантом 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 часа собрать его на Тильде. Если я не уверен, есть вероятность, что мне придется несколько раз на лендинге ее переделывать, и, возможно, с точки зрения времени, есть более дешевый способ проверки гипотез. Например, кастдевы. Соответственно, лендинг пишется, когда у меня есть сформированная идея, понимание ЦА и того, что я могу предложить с точки зрения ценности для клиента. Я описываю это на лендинге и оставляю на нем форму для записи с лид-магнитом. Если пользователь оставляет контакты, то мы можем считать, что он хоть как-то заинтересован в нашем продукте.

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

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

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

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

Коридорные тесты

Окей, сделали УТП, лендинг, все собрали. Какие есть еще инструменты для проверки гипотез? Я тут себе написал про коридорный тест. Расскажу про свой опыт в ВК. Мы обновляли интерфейс у вебинарной площадки, которую используют там как сервис. Мы пилили достаточно много гипотез. Делали это в рамках HADI (Гипотеза, Действия, Данные, Инсайты) - инструмента для приоритизации веры, команды и затрат в какую-то гипотезу. Мы используем этот фреймворк для того, чтобы понять, что нам делать.

Понятно, что вкусовщины много: дизайнер хочет одно, мы - другое. А гипотезу нужно проверять и ты идешь, проводишь 30 коридорных тестов, люди смотрят, сравнивают с текущей версией, между версиями и дальше ты считаешь и смотришь, что получается. Это очень сильный инструмент, который помогает не бредить, а взять релевантную аудиторию и с ней поговорить.

— Да, коридорки - отличный вариант для решенческого интервью для проверки гипотезы. Можно быстро в Figm’е сделать прототипчик. Figm’a - очень классный инструмент. Можно даже сразу на телефоне посмотреть приложение.

Fake button

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

— Это такой dark pattern своего рода, когда мы немного обманываем, но получаем информацию. Это мне напомнило паттерны в Амазоне, когда для того, чтобы удалить там аккаунт нужно пройти 20 экранов и несколько дать согласие, что это точно произойдет. В конце же нужно отправить запрос в форме заявки в support Амазона. По-другому ты не можешь сделать это. Просто невероятно.

— Не очень люблю dark pattern истории, я люблю крутой сервис. Где бы я не находилась, если там плохой сервис, это меня очень раздражает. Поэтому я стараюсь смотреть на вещи, как пользователь: чтобы ему было максимально комфортно и все нравилось.

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

Ухудшающие тесты

— Ты часто приводишь пример из корпорации, а можешь рассказать, насколько часто вы там используете ухудшающие тесты.

— В ВТБ мы такое не использовали. Я знаю, что такое делает Райффайзен. Недавно читала их статью про то, что ухудшающие тесты очень сильно недооценены. Они помогают сконцентрироваться на самом важном. Например, мы спроектировали процесс обслуживания наших пользователей. Если мы с помощью ухудшающего теста понимаем, что пользователь готов подождать время дозвона с 5 на 7 минут и это не снижает конверсию, то мы можем снизить нагрузку на наш коллцентр и сфокусировать наши ресурсы на более важной вещи для пользователя.

— Большинство тестов помогают понять, что мы получим, если добавим какую-то фичу. Этот тест говорит: “а вдруг ты ошибаешься, и на самом деле это фича вообще не влияет на результат”. Например, скорость загрузки страницы. Когда я работал с IT сервисами, они очень много драли за то, чтобы увеличить скорость загрузки страницы. Это сложная технологическая задача - изменить стек технологии. IT команде пришлось бы очень много переделывать. Мы провели тестирование, которое разумеется показало, что скорость загрузки вообще не влияет на конверсию. Влияет другое: текст и понятность интерфейса.

Прототипы

Для тестировании ценности продукта можно использовать разные прототипы, не только в Figm’е. Сейчас достаточно популярны No Code инструменты. Есть на любой вкус и цвет: можно сделать и веб приложение, и адаптив для мобильного, и интегрировать с Google таблицами. У этого есть плюсы, и минусы.

Плюсы. Можно обойти создание продукта своим ресурсами, если на приличном уровне шаришь в UX/UI дизайне, а можно и без него. если используешь шаблоны.

Минусы. Во-первых, No code - это отстающая история. Например, когда на рынке появляются популярные маркетплейсы, No cоd’ы постепенно перенимают эту историю и тоже предлагают им легкую возможность создать такой маркетплейс. Но вы не в первых рядах. Вряд ли получится создать инновации с помощью них. Во-вторых, есть зависимость от платформы. Если платформа легла, то это будет влиять и на продукт. В краткосроке, это дешевле и выгоднее, но в долгосроке на No Cod’е не посидишь, потому что если оставаться на нем, накопится legacy, нужно будет переводить клиентов, вставлять ключи… В принципе, для тестирования прототипа ок, но дальше - нет.

Есть еще такой вопрос: “Кому принадлежит кодовая база?”. Например, когда ты сделал сайт на no code, можешь ли ты зарегистрировать его и свой продукт на себя или она пренадлежит условному bubbl’у.

Значит, возникает юридический момент: ты собрал сайт на Тильде - а кому принадлежит эта собственность. Это хороший вопрос. Вот, например, у меня школа на 1.5 тысяч платящих пользователей, но мы не используем ни одного программного продукта, который бы написали сами. Мы используем Тильду, Формы, SaaS решения и все прочее. Я не очень хочу платить за разработку - сейчас все дорого и хочется пока есть возможность, справляться так. Сейчас наш оборот меньше 100 миллионов рублей в год. Когда мы перейдем определенный порог, нам точно нужно будет все эти элементы модифицировать

Итог

— Мы говорим про лендинг как про инструмент, хотя правильно исходить из цели. Цель - это протестить спрос. Как я могу это сделать?

Я могу это сделать разными нативными способами там, где обитает моя ЦА. Один из вариантов - условный телеграм канал или создание группы в соцсетях.

Есть такая фишка, которую делала знакомая SMM. Она искала треды, где что-то обсуждалось, и нативно вставляла свои услуги. Рассказывала свой кейс и приглашала поговорить об их ситуации, а дальше продавала. Лендинг - не единственное, на чем нужно зацикливаться. Нужно смотреть на цель.

— Согласен с тем, что важно задавать вопрос: “Для чего и как мы это делаем”. Каждое из перечисленного можно рассматривать и как инструмент, и как метод. Вещи могут давать нам гипотезы, а может быть инструментом для их проверки. Поэтому при их использовании нужно думать и осознавать, что мы используем и как. Второе - большое количественно инструментов - это большая ответственность, как говорил дядя П.

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