Несколько правил тестирования гипотез Нельзя развить или улучшить продукт, если не тестировать гипотезы регулярно. При этом в начале пути это не всегда получается сделать без ошибок, а любая ошибка — риск или убытки для компании. Совет №1: проводить анализ рынка до запуска даже минимальной версии продукта Рассмотрим на примере мобильного приложения для заказа и доставки бутилированной воды. Ранее, чтобы купить воду для кулера, нужно было самому приехать к магазину, сдать старые бутылки, закинуть в багажник новые и дотащить их до дома или офиса. В приложении же можно в три клика заказать доставку воды до двери. Идея кажется революционной и востребованной, так что не будем тестировать гипотезу и сразу выпустим MVP-версию приложения. MVP — минимально жизнеспособный продукт (Minimum Viable Product). Это первая версия продукта с ограниченным набором функций, которая помогает проверить идею и получить обратную связь. Вы продумали шаги пользователя и добавили в приложение самые востребованные фильтры для выбора воды, но в итоге приложением никто не пользуется. В чем дело? Оказалось, что рынок не готов к такому сервису. Клиенты не понимают, зачем платить за доставку в приложении, если можно по старинке дотащить бутылки самому. А продавцы воды не понимают, зачем покупать наше приложение, если покупатели и так приезжают. Мы ошиблись, потому что не провели исследование рынка и не объяснил клиентам ценность приложения заранее. Правило 1: если у вас есть гениальная гипотеза, сначала поговорите с потенциальными клиентами — возможно, ваш продукт нужно будет доработать или сделать более понятным. Совет №2: уточнять запросы клиентов и искать общее понимание проблемы Одно время пользователи Adesk часто писали в чат поддержки с просьбой добавить функцию выставления счетов для контрагентов. Это увидели и через некоторое время выкатили полноценную версию функции «Счета». О них так часто спрашивали, что разраюотчики были уверены в востребованности нового сервиса. В реальности для большинства клиентов «Счета» оказались неактуальными. Первое время пользователи заходили во вкладку по ошибке: думали, что там хранится информация об их банковских счетах. В итоге функцию убрали за ненадобностью. Правило 2: уточняйте запросы клиентов и что за ними стоит. Выясните, какие именно проблемы возникают у пользователей, а затем уже ищите решения. Совет №3: дорабатывать неудачные гипотезы, а не отправлять их в корзину сразу Если гипотеза не сработала, это не повод от нее отказываться. Например, в Adesk (сервис управленческого учета) есть возможность протестировать работу сервиса на демоданных. Изначально для примера был придуман абстрактный строительный бизнес — в нем много разных операций, контрагентов и можно показать максимум функций. С демоданными можно работать точно так же, как с основными: посмотреть счета, добавить приход или расход и посчитать прибыль Но когда разработчики посчитали конверсию в продажу у тех, кто пользовался демоверсией, и тех, кто сразу загрузил свои реальные данные, все очень удивились: те, кто стартовал с демоданных, реже становились клиентами. Первой мыслью было вообще избавиться от возможности загрузить демоданные. Но сервис решил дать им еще один шанс и предложить пользователям загружать больше вариантов демоданных, чтобы понять принцип работы сервиса. Все-таки специалисту из digital-сферы может быть сложно разобраться в операциях и бизнес-процессах, происходящих на стройке. Теперь при регистрации пользователи выбирают сферу деятельности и сами настраивают дашборд, а потом могут очистить данные и перейти на полноценный рабочий аккаунт. В итоге доработка гипотезы помогла увеличить количество пользователей сервиса и конверсию. Правило 3: вместо отказа от неудачной на первый взгляд фичи можно доработать гипотезу и попробовать еще раз.