За все время, что я занимаюсь бизнесом, я понял: нельзя развить или улучшить продукт, если не тестировать гипотезы регулярно. При этом в начале пути это не всегда получается сделать без ошибок, а любая ошибка — риск или убытки для компании.

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

Проводить анализ рынка до запуска даже минимальной версии продукта

Один из моих первых проектов — мобильное приложение для заказа и доставки бутилированной воды. В то время, чтобы купить воду для кулера, нужно было самому приехать к магазину, сдать старые бутылки, закинуть в багажник новые и дотащить их до дома или офиса. А в моем приложении можно было в три клика заказать доставку воды до двери. 

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

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

В итоге приложением никто не пользовался: оказалось, что на тот момент рынок не был готов к такому сервису. Клиенты не понимали, зачем платить за доставку в приложении, если можно по старинке дотащить бутылки самому. А продавцы воды не понимали, зачем покупать мое приложение, если покупатели и так приезжают. Я ошибся, потому что не провел исследование рынка и не объяснил клиентам ценность приложения заранее.

Правило 1: Если у вас есть гениальная гипотеза, сначала поговорите с потенциальными клиентами — возможно, ваш продукт нужно будет доработать или сделать более понятным.

Уточнять запросы клиентов и искать общее понимание проблемы

Одно время пользователи Adesk часто писали в чат поддержки с просьбой добавить функцию выставления счетов для контрагентов. Мы увидели запрос и через некоторое время выкатили полноценную версию функции «Счета». Нас так часто о них спрашивали, что мы были уверены в востребованности нового сервиса.

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

Правило 2: Уточняйте запросы клиентов и что за ними стоит. Выясните, какие именно проблемы возникают у пользователей, а затем уже ищите решения.

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

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

С демоданными можно работать точно так же, как с основными: посмотреть счета, добавить приход или расход и посчитать прибыль

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

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

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

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

Правило 3: Вместо отказа от неудачной на первый взгляд фичи можно доработать гипотезу и попробовать еще раз.

Оценить стоимость разработки и потенциальный заработок до начала тестирования

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

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

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

Вдобавок есть риск, что тарифное разнообразие не станет востребованным и не принесет больше лидов. Мы потратим сотни тысяч рублей на тестирование и внедрение новой идеи, а заработаем на ней в 2-3 раза меньше.

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