Как проверять гипотезы и запускать MVP в финтехе, если это страшно, дорого и занимает годы

Финтех — одна из лидирующих отраслей по скорости изменений и цифровизации процессов. На развитие финтеха влияют три фактора:

• Формат клиентского обслуживания меняется с традиционного на гибридный и дистанционный: клиенту всё реже нужно приходить в отделение банка, большинство продуктов можно оформить в банковском приложении и на сайте.
• Банки постоянно выводят на рынок новые продукты и быстро дорабатывают имеющиеся. К этому их вынуждает конкуренция — банковские услуги сравнялись между собой по стоимости и качеству, поэтому финансовым организациям нужно искать новые способы привлечения клиентов.
• В отдельный пункт можно вынести развитие небанковских продуктов. Крупные банки создают собственные экосистемы в сфере медиа, доставки, телекома и других услуг.

Конкуренция и темпы развития финтех-рынка увеличивают спрос на создание цифровых продуктов, поэтому в банках всё чаще встречается методология продуктового подхода.

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

На какие вопросы отвечает продакт в своей работе:

• какова ценность продукта для клиента;
• как увеличить выручку банка при помощи нового продукта;
• как удовлетворить потребность клиента;
• как максимально упростить продукт для проверки гипотезы;
• как измерить результат проверки гипотезы;
• какие этапы нужны, чтобы собрать обратную связь, проанализировать данные и скорректировать гипотезу и продукт.

Чтобы вывести на рынок востребованный продукт, продуктовая команда выполняет работу по этапам: исследует потребности рынка, формулирует и прорабатывает идеи, запускает и проверяет MVP (Minimum Viable Product — тестовой версии продукта), анализирует обратную связь от пользователей, обрабатывает полученные данные, дорабатывает продукт и запускает его полноценную версию. Этот цикл позволяет найти новые перспективные идеи и сэкономить время и деньги.

Использование продуктового подхода позволяет сократить количество неэффективных действий и быстрее прийти к результату, однако ошибки в работе продакта могут сделать этот путь длиннее и запутаннее. По данным ИТ-директора Урал ФД Сергея Герценштейна, в банках часто встречается 6 типов ошибок.

1. При формировании MVP забыли о клиенте и ценностях продукта и начали думать, как заработать

Как исправить: не пытаться реализовать продукт до проверки гипотезы.

Сначала нужно создать целевую группу и протестировать MVP на ней. Если найдутся доработки — нужно изменить MVP, заново протестировать и только тогда запускать. Нельзя забывать, что если даже MVP не приносит клиенту ценность, то полноценный продукт точно никому не будет нужен.

2. Руководителю «не нравится» продукт, на этом основании он его сворачивает

Как исправить: проверять гипотезы и прототипы на целевой аудитории, а не на руководителе.

3. Жалко признавать гипотезу неудачной, ведь на неё потратили много усилий

Как исправить: сформировать критерии успешности гипотез. Учитывать, что выявленная ошибочная гипотеза экономит время и деньги, поэтому нужно относиться к таким идеям более лояльно.

4. Вместо проверки гипотезы начали сразу реализовывать продукт и потратили слишком много денег

Как исправить: ограничить бюджет на проверку гипотезы — можно проверить продукт даже небольшой точечной автоматизацией и ручной обработкой.

5. Концентрируясь на продаже продукта, забыли про его обслуживание, в итоге бэк-офис тратит своё время на поддержку никому не нужных продуктов

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

Смотрите запись доклада Сергея Герценштейна об ошибках в продуктовых гипотезах на онлайн-митапе по ссылке →

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

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

Head of product Eqvanta group, ex-product Тинькофф Роман Верко поделился инсайтами, как эффективно использовать подход MVP для тестирования банковских продуктов.

1. При выводе каждого проекта нужен MVP.

Чтобы выделить MVP, нужно разделить проект на несколько итераций, обычно хватает 2-3 релизов.

2. На скорость создания MVP и проверки гипотезы влияют несколько факторов.

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

3. Гипотеза, подтверждаемая с помощью MVP, может не подтвердиться.

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

4. Чтобы выделить MVP, будущий клиентский и технический процесс нужно разложить по блокам и оценить их работоспособность.

Например, пометить блок «галочкой», если он протестирован и работает, «вопросом», если блок будет внедряться или есть у конкурентов, и «крестиком» — если он не работает. На основании этих блоков MVP поделится на 2 или 3 части. Каждая часть должна быть «отключаемой» и содержать целостную функцию как технически, так и для клиента.

5. Первая итерация разработки MVP, как правило, самая длительная.

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

Подробнее об опыте использования MVP Роман Верко рассказал на онлайн-митапе о проверке продуктовых гипотез

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

1. Для начала нужно выделить много времени на построение и контроль новой команды. Если в проектно-продуктовую команду входят специалисты из разных подразделений, которые подключаются на частичную занятость, они могут посчитать новый проект непонятным факультативом к основным обязанностям.
2. Новой команде нужно дать методологию проектной продуктовой работы и список инструментов. Позже команда сможет сама определиться с наиболее эффективным инструментарием, но на начальном этапе руководство должно быть более чётким.
3. Команде нужно единое информационное пространство для отчётов. В нём участники команды смогут фиксировать все артефакты, возникающие в процессе работы по продукту: хронологию, согласования, доработки.
4. Риски — это нормально, если сразу их идентифицировать и адекватно оценивать.
5. Не нужно отнимать время на разработку у других этапов, например тестирования. Это повышает риск, что придётся вернуться на предыдущий этап.
6. После запуска продукта нужно вернуться к его проверке: заново провести аудит, проверить, какие аномалии есть в продукте и как их оперативно устранить.
7. Нельзя давать команде одновременно два проекта или продукта. Большой соблазн накинуть что-то новое, когда команда практически завершила работу, — это плохая идея.
8. Нельзя закладывать в план организации потенциальные доходы от нереализованных продуктов.

Смотрите доклад Дмитрия Банникова о переходе банка к проектно-продуктовому подходу по ссылке.

Структура банковской системы в России сложилась таким образом, что около 80% активов приходится на топ-10 крупнейших банков. Чтобы догнать лидеров, остальным банкам нужны серьёзные инвестиции. Один из способов их привлечь — создание новых услуг и повышение качества обслуживания. Поэтому многие банки цифровизируют не только основной пул классических продуктов, но и выходят на рынок небанковских услуг. Ex-product manager Точки Лера Кадочникова рассказала, какой опыт она вынесла, запуская продукты на стыке рынков: e-commerce, FinTech, PropTech и маркетплейсов.

1. Время инвестиций закончилось

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

2. Специфический рынок — длинные сроки создания продукта

Классическая схема создания продукта проста: появилась идея – продакт исследует рынок, проверяет гипотезу, замыкает HADI-цикл, делает предварительные офферы, проводит А/В-тесты, затем реализовывает MVP – запускает и проверяет на клиентах. На практике длительность каждого из этих этапов может быть огромной.

3. Клиенты ещё не готовы к вашему продукту

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

4. MVP – не всегда панацея

Быстрый запуск гипотезы по непрофильному продукту может не дать результатов, поскольку он не закрывает критичные потребности клиента, в отличие от банковских продуктов.

5. Рано останавливаться после первой неудачной проверки гипотезы

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

Смотрите запись доклада Леры Кадочниковой о проработке непрофильных гипотез в банкинге здесь.

Часто продакты в банках выгорают быстрее, чем успевают найти жизнеспособную идею. Обычно на запуск одного MVP уходит около года, из 10-20 гипотез удачной оказывается только одна. Продакт может так и не найти подходящую идею для масштабирования в полноценный продукт, и со временем у него становится всё меньше денег, клиентов и желания проводить эксперименты.

Дополнительно работу продуктовой команды осложняют:

• Внешние изменения на рынке: валютные качели, санкции, государство вводит цифровой рубль, постоянно меняются требования регулятора. Продакту и команде разработки приходится бесконечно отвлекаться на изменения.
• Банковское ПО: оно начало формироваться еще в начале 90-х, затем дорабатывалось, различный функционал покупался у вендоров и других банков. И в итоге нынешнее ПО часто состоит из огромного количества разнородных кусочков, которые могут непредсказуемо взаимодействовать друг с другом.
• Длительные процессы внутри банков: заказчики-банки могут 7 месяцев согласовывать пилотный запуск проекта, а затем столько же времени уйдёт на реализацию полноценного сервиса. В итоге продакт тратит год, чтобы запустить одно работоспособное MVP.

В таких условиях продакт нуждается в решении, которое позволяет быстро создавать и проверять MVP, гибко интегрировать его с имеющимися банковскими системами и дорабатывать его до полноценной версии продукта после тестирования. Product manager Abanking Digital Office Жанна Коренкова рассказала, как nocode-механики помогают продакту без участия разработки подтверждать гипотезы реальным спросом на реальных клиентах.

1. Собрать и запустить MVP из готовых компонентов и преднастроенных интеграций

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

2. Протестировать спрос на реальных клиентах и быстро получить обратную связь

Nocode-платформа позволяет создать кастомизированный сервис по индивидуальному ТЗ на базе готового шаблона, что ускоряет запуск MVP от 1 месяца.

3. Доработать MVP, основываясь на полученных данных

В готовом MVP можно менять наполнение: тарифы, анкетную форму, сценарий, маркетинговые посылы — всё, что угодно.

4. Доработать MVP до полноценного продукта: добавить функционал, настроить внутренние процессы и интерфейс, — и получить продуктовое решение нового уровня.

Узнайте, как подтверждать гипотезы реальным спросом, если рынок, Центробанк и банковское ПО работает против банка по ссылке.

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

Как избежать ошибок при запуске банковских продуктов, эксперты отрасли рассказали на онлайн-митапе, организованном Abanking. Смотрите двухчасовой онлайн-митап в записи по ссылке, чтобы запускать новые продукты быстро и с минимальными трудозатратами.