Как проверить идею приложения до разработки

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

Проверка не доказывает, что идея будет успешной. Она снижает шансы потратить месяцы на то, что никому не нужно.

Что вы на самом деле проверяете

«Это хорошая идея?» — слишком расплывчатый вопрос для проверки. Разбейте его на вопросы, на которые можно ответить:

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

Шаг 1: Запишите самое рискованное предположение

Перед любым исследованием запишите идею одним предложением: «[Кто] борется с [проблемой] и будет использовать [решение], потому что [причина]». Затем перечислите, что должно быть верно, чтобы всё сработало, и обведите пункт, в котором вы меньше всего уверены. Его проверяете первым.

Для приложения для записи клиентов грумеров самое рискованное предположение может быть не «грумерам нужно планирование» — им очевидно нужно, — а «грумеры достаточно недовольны своим текущим инструментом, чтобы перейти на другой».

Шаг 2: Интервью о проблеме

Интервью — самый дешёвый и информативный метод, и его легче всего провести плохо. Цель — узнать о нынешнем поведении человека, а не продавать ему.

С кем говорить

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

О чём спрашивать

Спрашивайте о прошлом, а не о гипотетическом будущем:

• «Расскажите о последнем случае, когда вы столкнулись с [проблемой].»
• «Что вы сделали, чтобы с этим справиться? Какими инструментами пользовались?»
• «Что в этом было особенно раздражающим?»
• «Платили ли вы за что-нибудь, чтобы это исправить? Почему да или почему нет?»
• «Кто ещё участвует, когда это происходит?»

Чего избегать

• «Вы бы стали пользоваться приложением, которое…?» Почти все из вежливости ответят «да».
• Слишком раннее показывание решения. Увидев его, люди реагируют на решение вместо того, чтобы рассказывать о своей проблеме.
• Подсчёт комплиментов. «Отличная идея» — не доказательство. «Можно я попробую, когда будет готово?» — немного. «Вот моя карта» — очень много.

Ведите заметки и после каждого интервью записывайте три вещи, которые узнали. Когда несколько людей описывают одну и ту же боль похожими словами, запишите эти слова — они станут заголовком вашего лендинга.

Шаг 3: Проверьте, что уже существует

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

Если ничего не существует вообще, выясните почему. Иногда это возможность; чаще это значит, что проблема недостаточно болезненна, чтобы за неё платить.

Шаг 4: Тест-пустышка с помощью лендинга

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

Что нужно на странице:

1. Заголовок, который называет проблему словами ваших собеседников.
2. Три–четыре конкретных преимущества — что меняется для пользователя.
3. Один призыв к действию.
4. Честная пометка, что продукт в разработке, чтобы никто не чувствовал себя обманутым.

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

Как читать результаты

Универсально «хорошей» конверсии не существует, поэтому сравнивайте с собой: запустите два заголовка или две аудитории и посмотрите, что работает лучше. Самый полезный результат — не процент, а список людей, которые зарегистрировались. Напишите им и попросите созвониться.

Шаг 5: Создайте лист ожидания — и используйте его

Лист ожидания собирает email заинтересованных людей до запуска. Он полезен по двум причинам: даёт людей для интервью и аудиторию в день запуска.

Его слабость в том, что регистрация почти ничего не стоит. Заставьте список работать сильнее:

• Задайте один вопрос при регистрации, например: «Что вы используете для этого сейчас?»
• Лично отвечайте первым зарегистрировавшимся и попросите 15 минут.
• Отправляйте короткое обновление каждые несколько недель, чтобы список не остывал.

Как создать страницу листа ожидания описывает создание, включая то, где хранятся email.

Шаг 6: Продавайте заранее или берите депозит

Самый сильный ранний сигнал — деньги. Предложите ранний доступ со скидкой, цену для основателей или возвращаемый депозит и посмотрите, кто заплатит. Используйте ссылку на оплату от вашего платёжного провайдера; готовый продукт не нужен.

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

Шаг 7: Тесты «консьерж» и «Волшебник из страны Оз»

Иногда самый быстрый «продукт» — это вы сами.

• Тест «консьерж»: результат вы доставляете вручную. Если приложение должно создавать еженедельные отчёты, сделайте их сами в таблице и отправляйте по email. Вы точно узнаете, что ценят пользователи, прежде чем автоматизировать процесс.
• Тест «Волшебник из страны Оз»: пользователи видят простой интерфейс, но за ним вы выполняете работу вручную. Пользователь ощущает продукт, а вы узнаёте, возвращается ли он.

Оба метода медленно масштабируются, и в этом их смысл. Автоматизировать стоит только то, что доказало свою ценность.

Шаг 8: Создайте небольшой MVP и наблюдайте за поведением

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

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

Сравнение методов проверки

Когда остановиться, поменять курс или продолжать

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

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

Ранняя остановка — хороший результат. Она освобождает время для проверки следующей идеи.

Проверка с Mythex

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

Вопросы