Как системно проверять гипотезы в IT. Развиваем продукт в 3 раза быстрее
Рассказывая о гипотезах в рамках обучающего курса Школы продуктового трекинга ФРИИ, я всегда делаю акцент на рисках, с которыми сталкивается ИТ-команда при разработке нового продукта или функции:
- Риск ценности — продукт окажется никому не нужен.
- Риск реализуемости — не получится создать продукт.
- Риск юзабилити — будет непонятно, как пользоваться продуктом, как получать ценность.
- Риск бизнес-жизнеспособности — продукт не сможет системно зарабатывать деньги.
Риски связаны с тем, что любой новый продукт или функция — это набор гипотез. Большинство из них опровергаются: из 100% подтвердятся 10-20%, но в таком результате тоже есть ценность.
Что такое бизнес-гипотезы и где их брать
Бизнес-гипотеза — это предположение о том, как развивать бизнес, отдельный продукт или услугу. Её можно проверить в ходе тестирования на целевой аудитории.
Несколько слов о теории и научном подходе к гипотезам. Эрик Рис, автор концепции Lean Startup, предложил относиться к любому продукту как к набору гипотез. Он выделил два вида гипотез — гипотезы ценности и гипотезы роста.
Гипотезы ценности:
- о проблемах целевой аудитории;
- о технологии;
- о продукте;
- о выгодах.
Гипотезы роста:
- о каналах (или гипотезы привлечения);
- о конверсии или активации;
- о возврате или удержании;
- о виральности;
- о монетизации.
Гипотезы ценности связаны с тем, что у пользователей есть решаемые проблемы, а гипотезы роста используют для масштабирования продукта.
Александр Остервальдер, швейцарский теоретик бизнеса, автор книг, консультант и предприниматель, сформулировал три характеристики хорошей гипотезы о продукте. Их отлично иллюстрирует следующая схема:
Откуда брать гипотезы? Что можно сделать:
- Генерировать гипотезы вместе с командой (используя разные методы креативного мышления) и предполагать, что нужно аудитории.
- Изучать целевую аудиторию или клиентов — смотреть метрики, поисковую статистику, отзывы на продукты конкурентов.
- Найти гипотезы среди критических отзывов о вашем продукте.
- Провести проблемное или решенческое интервью.
Совет. Не начинайте разработку функций продукта или самого продукта без изучения реальных потребителей. Это одна из ключевых идей продуктового подхода.
Как описать гипотезы
Для описания будущего продукта можно использовать канву бизнес-модели Lean Canvas:
Если, двигаясь по этому алгоритму, у вас не подтверждается какая-то гипотеза, то идти дальше не стоит, пока не будет пройден данный этап. Пытаясь масштабировать непроверенную и неподтверждённую бизнес-модель, с высокой вероятностью вы будете масштабировать лишь убытки.
Пример проверки гипотезы
Рассмотрим кейс сервиса Insighter. Это бот в Телеграме для создания текстовой расшифровки (протокола) видеовстреч.
Гипотеза фаундера: привлечение трафика из поисковых систем обеспечит конверсию в продажу на уровне 2-5%.
Проверка гипотезы. При тестировании оказалось, что сервис привлекает два разных сегмента пользователей с разной покупательской способностью:
- Менеджеры, которые делают саммари встреч.
- Люди, возможно, студенты, которым нужно саммари видео на YouTube, например, для подготовки к экзаменам.
Эти два сегмента используют разный функционал продукта, решают разные проблемы, на них можно по-разному зарабатывать.
Решение: нужно посчитать юнит-экономику и построить отдельные бизнес-модели для менеджеров и студентов.
Рассылка: как вести бизнес в России
Раз в неделю присылаем самые важные новости и лайфхаки для развития вашего бизнеса
Что такое концепция Discovery Delivery
В российских крупных корпорациях стала популярна концепция Discovery Delivery, которую можно визуализировать так:
Внутри Discovery выделяют два этапа:
- Problem Discovery — этап, когда надо подтвердить проблемы целевой аудитории и возможную ценность продукта, которого ещё нет.
- Solution Discovery — этап, когда концепцию придуманного продукта нужно подтвердить вместе с пользователем до этапа разработки.
Получается, что должен быть отдельный бэклог для Discovery, который идёт перед Delivery. Но некоторые команды ИТ-компаний выполняют бэклог разработки без предварительного этапа исследования. Поэтому как результат они платят за функции, которые, возможно, никому не нужны.
Важно! Если запустить Discovery-цикл в компании, лишь 10-20% идей дойдёт до бэклога разработки. Значит, бизнес потратит в 5-10 раз меньше денег, потому что будет делать только востребованные истории.
Несколько важных вопросов и ответов на них:
- Кто отвечает за Discovery? Это может быть продакт, маркетолог, сейлз, аналитик или специалист, который способен делать качественные исследования.
- Сколько можно тратить на Discovery? Discovery надо проводить без продукта. Достаточно высоко реалистичного прототипа. А значит, не надо тратить время и деньги на разработку.
- Какова длительность Discovery? Чем быстрее тестируются гипотезы, тем лучше. Поэтому ответ такой: 1-3 недели у B2C. Но для B2B или B2G нужен больший срок: полгода для энтерпрайза, 3 месяца для B2B. Если не удаётся сделать Discovery за 3 месяца, то, возможно, вы выбрали не тот сегмент или не тот продукт.
Вывод. Discovery дешевле Delivery, поэтому для бизнеса выгодно ввести практику проведения Discovery до Delivery.
Совет. Для Discovery нужен свой бэклог. Если его нет, обязательно заведите, сделайте канбан-доску или дневник гипотез.
Кто должен заниматься гипотезами
По мнению Марти Кагана, автора книги «Вдохновлённые. Всё, что нужно знать продакт-менеджеру», состав команды тестирования гипотез должен быть таким:
Задачи менеджера продукта:
- Изучить целевую аудиторию, стать экспертом и понять потребности клиентов с помощью данных, проблемных интервью, Jobs to be done интервью и др.
- Создать бэклог задач, которые связаны с разработкой и solution discovery. Лучше сначала сделать кликабельный макет и показать его целевой аудитории, чем сразу передавать в разработку.
- Допиливать продукт, проверять ценность с конечной аудиторией. Иногда нужно делать пивот — менять бизнес-модель, продукт или сферу деятельности стартапа.
Вывод. Продакт-менеджер обладает набором стратегических инструментов и определяет видение продукта, стратегию развития и отвечает за бэклог.
Пример проверки гипотезы
Рассмотрим кейс компании Intercom. Это одни из соавторов методологии Jobs to be done, которая помогает объяснять поведение людей. В основе теории — идея, что пользователь покупает не продукт или услугу, а решение своих задач. Он буквально «нанимает» продукт.
Продукт компании Intercom — сервис, который на сайте собирает обратную связь потребителей продукта или услуги.
В определённый момент в Intercom увидели, что часть B2B-клиентов берут скриншоты карты распределения пользователей из кабинета администратора и вставляют их в свои презентации.
Гипотеза. Клиенты используют карту Intercom, когда хотят увеличить объём инвестиций или привлечь партнёров, а также показать масштаб своей деятельности.
Решение. После тестирования решили дорабатывать продукт. Команда сервиса создала функционал, который позволил встраивать карту прямо в сайт клиента. А также добавили возможность поделиться картой в социальных сетях и т.п. Всё это создало дополнительную ценность продукта.
Результат. Intercom получил огромное количество вириального трафика, потому что решение совпадало с ценностью одной из функций продукта, которая даже не была базовой.
Совет. Во время анализа опыта использования сервиса можно обнаружить дополнительную ценность от вашего продукта. Вокруг подобных находок можно формулировать и проверять новые гипотезы.
Алгоритмы и способы проверки гипотез
Давайте коротко рассмотрим несколько инструментов, которые можно использовать на практике и с которыми мы знакомимся в рамках курса Школы продуктового трекинга ФРИИ. Если захотите самостоятельно изучить инструменты более подробно, перейдите по ссылкам в тексте.
HADI-циклы. Это инструмент методологии Agile, предназначенный для проверки гипотез через последовательность действий. Такой подход помогает командам быстро и эффективно проверять свои предположения и корректировать стратегию на основе полученных результатов.
Методика состоит из четырёх этапов:
- Hypothesis (гипотеза) — формулировка гипотезы.
- Action (действие) — проверка гипотезы, например, запуск новой функции в приложении.
- Insight (инсайт) — анализ результатов и формулировка выводов.
- Decision (решение) — решение о продолжении работы над гипотезой или отказе от неё.
Lean Startup Cycle. Это итеративный процесс, который позволяет быстро проверять гипотезы и совершенствовать продукт на основе обратной связи. Цикл позволяет проверять гипотезы, минимизировать риски и оптимизировать ресурсы, что особенно полезно для стартапов и компаний, стремящихся к инновациям.
Цикл проходит в несколько этапов:
- Создание MVP — версия продукта, которая запустит цикл «создать — оценить — научиться» с минимальными затратами.
- Оценка эффективности MVP — отвечает на вопрос, приводят ли усилия по созданию продукта к нужным результатам.
- Анализ — показывает, что не работает и что нужно доработать.
Customer development insight cycle (CDIC). Это методика, которая помогает предпринимателям систематизировать сбор и анализ информации о клиентах.
CDIC включает этапы:
- Формулировку предположений и гипотез.
- Проектирование эксперимента (западающий этап в большинстве команд).
- Тестирование гипотез вместе с клиентами.
- Формирование выводов.
Карточка тестирования Остервальда. Это фреймворк (или канвас), который нужно заполнить. Он очень простой, понятный, но при этом полезный: наглядно показывает, когда гипотеза будет считаться подтверждённой.
В карточке есть четыре компонента:
- Мы верим, что___.
- Чтобы это проверить, мы сделаем ___.
- Мы измерим ____.
- Будем правы, если___ .
Заполнив карточку, можно повысить шансы на успех нового продукта.
SAFe — Scaled agile framework. Это методология для масштабирования agile-методик, которая подходит для крупных корпораций со сложными методиками управления разработкой продукта в многоэтапных проектах. SAFe помогает управлять командами от 50 до нескольких тысяч человек.
Цель методики — создать гибкую систему, чтобы легко управлять разработкой нескольких продуктов и обеспечить взаимодействие между командами.
SAFe помогает:
- Эффективно распределить роли и управлять процессами в больших командах.
- Управлять зависимостями между проектами.
- Обеспечить прозрачность работы на всех уровнях организации, чтобы все участники понимали общую картину и свой вклад в проект.
В ядре SAFe находится всё тот же Lean Startup. Чтобы доказать это, давайте познакомимся с сущностью EPIC (эпик). Каждый EPIC — это крупная, весомая инициатива в разработке, на которую нужно много времени. EPIC строится вокруг гипотезы, в которой описывается, кому и какую ценность компания поставляет. Также описываются результаты, которые компания планирует получить.
Технология проверки:
- Каждый EPIC подразумевает создание MVP.
- Если сделали MVP, то гипотеза может быть опровергнута.
- В таком случае нужно делать пивот (смену бизнес-модели или сути продукта/функции продукта).
- Если не хотим делать пивот, то нужно заканчивать работу и выводить EPIC из разработки.
Получается, когда компания запускает крупную функцию продукта, она делает отдельный EPIC, а это отдельный MVP.
Дневник гипотез. Для проверки гипотез можно вести дневник и фиксировать в нём не только идеи, но и результаты проверки гипотезы:
Краткий вывод
Тестирование гипотез повышает шансы на успех новых продуктов или их функций, а также снижает ключевые риски. Разработка подразумевает не только этап Delivery, но и этап Discovery, который является дефицитной зоной в РФ. А этап изучения потребителей подразумевает собственный бэклог гипотез и задач. Только часть гипотез подтвердится на этом этапе, а значит и не будет необходимости создавать функции, которые никому не нужны — не придётся тратить на это ресурсы.
В продуктовом подходе появляется всё больше инструментов и методик для формирования и проверки гипотез, которые активно применяются в практике продуктового трекинга ФРИИ. Выбор конкретного инструмента зависит от личных предпочтений команды.
Важно не только формировать гипотезы, но и продумывать конкретный дизайн эксперимента и ожидаемые результаты, чтобы можно было делать корректные выводы после любых качественных или количественных экспериментов.
