Короткий ответ: проверяйте не идею, а шесть неизвестных
Чтобы проверить идею мобильного приложения, не просите людей вынести ей общий вердикт. Для каждой рискованной части задайте отдельный вопрос, выберите честный эксперимент, назовите наблюдаемое событие и заранее решите, что изменится после результата. Интервью может подтвердить контекст проблемы. Прототип показывает, проходит ли человек сценарий. Реальное действие, возврат и оплата отвечают уже на другие вопросы.
Рабочая формула: гипотеза → нужные люди → эксперимент → событие → окно наблюдения и знаменатель метрики → решение. Если последний пункт не записан, данные легко превратить в оправдание любимой идеи.
Шесть неизвестных удобно держать на одной карте. Нельзя компенсировать нулевой доступ к аудитории прекрасным интерфейсом, а сломанную эксплуатацию высокой регистрацией. Слабое звено меняет следующий шаг.
Почему похвала друзей не доказывает спрос
Друг может честно сказать, что экран понятен. Это полезно для ранней проверки текста и навигации. Но если он не сталкивается с проблемой и не выбирает продукт в реальной ситуации, его «я бы пользовался» ничего не говорит о канале, частоте возврата или готовности платить.
У интервью другая задача: выяснить, когда проблема случилась в последний раз, что человек сделал, сколько времени потерял и чем заменяет будущий продукт. Мета-анализ Webb и Sheeran показал общий разрыв между намерением и последующим поведением. Это исследование не про покупки приложений, поэтому из него нельзя брать нормы конверсии. Но оно хорошо защищает простое правило: заявление и действие нельзя складывать в одно доказательство.
| Что произошло | Что это показывает | Чего ещё не знаем | Следующий шаг |
|---|---|---|---|
| Человек похвалил идею | Предложение звучит понятно или приятно | Будет ли он искать решение и действовать | Спросить о последнем реальном эпизоде |
| Прошёл кликабельный прототип | Сценарий можно понять и выполнить | Придёт ли человек сам и вернётся ли | Дать вход через правдоподобный канал |
| Оставил контакт | Сообщение вызвало интерес | Получит ли он обещанную пользу | Довести до первого ценного действия |
| Получил первый результат | Основной путь способен дать ценность | Повторяется ли задача и устроит ли цена | Проверить возврат и обмен ценностью |
| Заплатил | Цена и обещание сработали в этом контексте | Выдержит ли сервис повтор и поддержку | Провести заказ через сбои и исключения |
Что на самом деле означает число 100
Универсально достаточного числа пользователей нет. В справочнике NIST размер выборки зависит от вопроса, желаемой точности, разброса и цены ошибки. Ранние пользователи вдобавок редко приходят случайно: их привёл один канал, пригласил основатель или отобрал партнёр. Поэтому отметка 100 сама по себе не доказывает размер рынка, причинность и тем более соответствие продукта рынку.
Зато это полезный лимит внимания. До начала команда может договориться, какие решения она обязана принять по ходу первой ограниченной серии. Сколько людей увидели приглашение? Кто открыл продукт? Кто дошёл до первого полезного результата? Кто вернулся в естественное для задачи время? Кто заплатил? Сколько ручной работы потребовалось команде?
Не смешивайте знаменатели. Сто установок, сто первых открытий и сто людей, получивших пользу, дают три разные истории. Apple, например, считает удержание по активным устройствам, исключая из этой метрики установки без единого открытия. Ваше определение может быть другим, но оно должно быть подписано рядом с процентом.
До первого приглашения запишите решение
Представьте: в 12:45 в столовой бизнес-центра очередь до двери, а у сотрудников осталось 20 минут перерыва. Команда уже обсуждает меню, бонусы и уведомления. Но главная гипотеза проще: готовы ли люди заранее выбрать блюдо и время выдачи, чтобы не стоять в очереди?
До теста нужно описать не будущий продукт, а правило решения. Подход Strategyzer Test Card предлагает заранее записать, что должно оказаться правдой, как это проверить, что измерять и какой результат будет означать успех конкретного теста. Порог зависит от экономики и риска вашей задачи. Если для него пока нет основания, сначала соберите исходный уровень, а не придумывайте «нормальный процент».
| Поле карточки | Вопрос команды | Пример для столовой |
|---|---|---|
| Гипотеза | Что должно оказаться правдой? | Очередь мешает людям успеть пообедать |
| Сегмент | Для кого и в каком контексте? | Сотрудники здания, которые покупают обед в будни |
| Эксперимент | Как проверить без лишней разработки? | Простая форма заказа и ручное подтверждение кухни |
| Событие | Какое действие считаем? | Заказ оформлен, подтверждён и выдан |
| Окно | Когда результат имеет смысл? | До выбранного времени обеда и в следующий естественный день заказа |
| Решение | Что меняем после сигнала? | Продолжаем, меняем сегмент или останавливаем этот сценарий |
Шесть проверок, через которые проходит идея
Проблема и частота
Начните с последнего реального случая. Не «нужен ли вам предзаказ», а «когда вы в последний раз не успели пообедать, что сделали и чем это закончилось». Ищите повторяющийся контекст, текущую замену и цену проблемы в минутах, деньгах, риске или раздражении.
Если люди понимают вопрос, но не могут вспомнить недавний эпизод, не спешите улучшать интерфейс. Возможно, проблема редкая, сегмент выбран слишком широко или решение не должно быть отдельным приложением.
Доступ к нужным людям
Даже хорошую идею нельзя проверить, если вы не можете регулярно находить людей с нужной проблемой. Ручные приглашения на старте допустимы: Paul Graham советовал молодым продуктам набирать первых пользователей вручную и наблюдать их близко. Но ручной набор не скрывает риск канала, а делает его видимым.
Записывайте источник каждого участника. Если откликаются только знакомые основателя, вы проверили сеть основателя. Если приходят сотрудники одного бизнес-центра, вывод относится к этому центру. Следующее решение может быть не «строить больше», а найти второй независимый путь к похожему сегменту.
Первый полезный результат
Регистрация показывает, что человек вошёл. Она не доказывает ценность. Первым полезным результатом назовите действие, после которого пользователь получил обещанное: увидел подтверждённый заказ, записался на свободное время, отправил документ без ручного дублирования или получил расчёт, ради которого пришёл.
Событие нужно внедрить в аналитику до запуска и проверить в отладке. В Firebase события фиксируют действия, системные события и ошибки. Название события команда выбирает сама, а его смысл должен оставаться понятным владельцу продукта.
Возврат в естественное окно
Ежедневный возврат подходит не каждой задаче. Обед может повториться завтра, запись к врачу через недели, а налоговое действие через месяцы. Сначала назовите естественный следующий момент, затем проверяйте, вернулся ли человек и снова получил пользу.
Если пользователь не вернулся, проверьте три вещи: получил ли он первый результат, должна ли задача уже повториться и не оказался ли привычный способ проще. Уведомление может напомнить о ценности, но не создаёт её вместо продукта.
Деньги или подтверждённая бизнес-ценность
Оплата сильнее обещания «я бы купил», но и она проверяет конкретную цену, предложение и момент. Подпишите знаменатель: все увидевшие предложение, активированные пользователи, начавшие пробный период или дошедшие до оплаты. Эти группы нельзя менять местами после результата.
Для внутреннего продукта вместо оплаты может быть утверждённый бюджет, обязательная операция, снятый риск или измеримая ручная работа. Главное, чтобы ценность проявилась в реальном решении бизнеса, а не только в положительном отзыве сотрудника.
Эксплуатация и исключения
Представьте, что заказ есть, но блюдо закончилось. Клиент нажал оплату дважды. Кухня опоздала, оператор поменял статус вручную, а уведомление не пришло. Спрос может существовать, но продукт пока не выполняет обещание без дорогого ручного спасения.
В 13FOX мы проверяем не только идеальный сценарий. В заказном потоке связываем действие с идентификатором заказа, статусами, отменой, повтором и контрольной сверкой. На первых пользователях записывайте обращения, минуты ручной работы, сбои, незавершённые операции и способ восстановления. Так становится видна реальная стоимость эксплуатации.
Как превратить первые 100 пользователей в рабочие волны
Не делите людей автоматически на четыре равные группы и не откладывайте деньги или эксплуатацию «на потом». Волна заканчивается по заранее записанному правилу: произошло нужное событие, истёк срок или достигнут лимит попыток. Следующая начинается с самого дорогого открытого вопроса. Иногда один человек участвует в интервью, проходит сценарий, возвращается и платит. Для каждой метрики он попадёт в свой знаменатель.
Сохраняйте журнал решений, а не только панель с графиками. У каждой строки есть сегмент, канал, событие, окно, наблюдение, решение и новый тест. Если после волны вы не можете назвать новое решение или следующий проверочный вопрос, вы, вероятно, собираете удобные данные вместо нужных.
Как читать сигнал: продолжить, изменить, остановить или проверить ещё
Один и тот же результат может указывать на разные причины. Люди не открыли приглашение: проблема в сегменте, сообщении или канале. Открыли, но не начали сценарий: обещание не совпало с ожиданием, цена показалась неуместной или доверия не хватило. Начали, но не получили результат: уже виден риск интерфейса, данных или технической надёжности.
| Наблюдение | Что проверить | Возможное решение |
|---|---|---|
| Нужные люди не приходят | Сегмент, канал, сообщение, доверие | Изменить канал или сузить аудиторию до разработки |
| Приходят, но не начинают | Понятность обещания, цена входа, первый экран | Переформулировать предложение и повторить честный тест |
| Начинают, но не получают пользу | Сценарий, данные, ошибки, время до результата | Упростить путь или остановить неработающую реализацию |
| Получают пользу, но не возвращаются | Частоту задачи, качество результата, привычную замену | Сменить окно, сегмент или модель продукта |
| Возвращаются, но не платят | Покупателя, цену, упаковку, бесплатную альтернативу | Проверить другую модель обмена ценностью |
| Платят, но команда спасает каждый заказ | Исключения, поддержку, интеграции, восстановление | Не масштабировать до устойчивого операционного контура |
Решение «проверить ещё» допустимо, если вы можете назвать, какое новое наблюдение снимет неопределённость. Фраза «данных пока мало» без следующего вопроса просто откладывает выбор. Для ограниченного состава продукта пригодится наш разбор о том, как отделить обязательное в MVP от последующих функций.
Когда ждать 100 пользователей не нужно или опасно
Вся аудитория меньше ста
Если внутренним инструментом пользуются восемь диспетчеров, проверьте все роли, смены, пики и исключения. Полнота сценариев важнее красивого числа.
Ошибка может причинить ущерб
Медицинский, финансовый или другой критичный продукт требует юридической, технической, защитной или клинической проверки. Пользовательский тест их не заменяет.
Задача случается редко
Не измеряйте ежедневный возврат для ежегодного или аварийного действия. Нужен естественный следующий шаг и подходящее окно.
Продукт двухсторонний
Сто покупателей не доказывают, что продавцы обеспечат выбор и скорость. Каждую сторону и их встречу проверяют отдельно.
Нет доступа к сегменту
MVP не исправит отсутствие канала. Сначала докажите, что можете найти и пригласить нужных людей без случайной подмены аудитории.
Приложение может быть лишним
Для редкого действия достаточно сайта, формы, бота или ручной услуги. Сравните форматы в материале о том, нужно ли здесь мобильное приложение вообще.
Пройдите тест жизнеспособности идеи
Оцените не качество самой идеи, а силу доказательств по шести вопросам. Ноль означает, что пока есть только мнение команды или данных нет. Один: есть релевантные слова, текущий процесс или единичное действие. Два: нужное поведение наблюдалось в заданном сегменте и контексте.
Сумма показывает покрытие доказательствами на сегодня, а не вероятность успеха. Если безопасность, доступ к аудитории или эксплуатация не проверены, высокий балл за интерфейс не закрывает этот пробел. После теста сохраните результат или сделайте снимок экрана и обсудите три слабые строки с командой до следующей функции.
Без JavaScript: сложите выбранные значения и выпишите три строки с минимальной оценкой. Начните с той, где ошибка дороже или блокирует остальные проверки.
Что сделать завтра
- Сформулируйте одну проблему и один сегмент без списка будущих функций.
- Опишите последний реальный эпизод и привычную замену продукта.
- Назовите первое действие с понятной пользой, окно возврата и знаменатель оплаты.
- Запишите, какой результат означает «продолжить», «изменить», «остановить» или «проверить ещё».
- Выберите самый дешёвый честный эксперимент для слабейшей строки теста.
Когда сигнал уже требует работающей версии, переходите к ограниченному MVP. Когда решение продолжать принято, поможет карта процесса от требований до запуска и поддержки. А масштабирование каналов и возврата стоит обсуждать после доказанного первого цикла; этому посвящён разбор аналитики и системы роста.
На чём основан подход
Эти источники объясняют границы метода; чужие показатели нельзя автоматически переносить на вашу идею. Рядом указана дата публикации или последней проверки.
- NIST, Selecting Sample Sizes: почему размер выборки зависит от вопроса и точности; проверено 10 августа 2026 года.
- Strategyzer Test Card: гипотеза, тест, метрика и порог до результата; опубликовано 5 марта 2015 года.
- GOV.UK, Making prototypes: прототип как быстрый способ проверить сценарий; опубликовано 18 октября 2016 года.
- Webb & Sheeran, Psychological Bulletin: разрыв между изменением намерения и поведения; март 2006 года, без переноса показателей на приложения.
- Firebase Analytics events: события действий и ошибок; обновлено 6 августа 2026 года UTC.
- Apple: удержание приложений: определение удержания и его знаменателя; проверено 10 августа 2026 года.
FAQ
Можно ли проверить идею приложения без разработки?
Да. Интервью и наблюдение проверяют проблему, лендинг и ручной сценарий помогают проверить доступ к аудитории и действие, а кликабельный прототип показывает, может ли человек пройти путь. Код нужен, когда риск нельзя честно проверить более простым способом: например, для сложной интеграции, работы устройства или повторного использования в реальных условиях.
Сколько пользователей нужно для проверки идеи?
Универсального числа нет. Объём зависит от вопроса, сегмента, разброса данных и цены ошибки. Первые 100 удобно использовать как ограниченную серию решений, но это не автоматическая статистическая гарантия и не доказательство соответствия продукта рынку.
Можно ли тестировать прототип на друзьях?
Друзья могут заметить непонятный текст или сломанный переход. Но их похвала не доказывает спрос, если они не относятся к целевому сегменту и не сталкиваются с проблемой в нужном контексте. Для продуктового решения нужны реальные или вероятные пользователи.
Какая метрика важнее всего у первых пользователей?
Универсальной метрики нет. Сначала назовите первый полезный результат, затем выберите естественное окно возврата и отдельно подпишите знаменатель для оплаты. Регистрация, активация, возврат и покупка отвечают на разные вопросы.
Что делать, если пользователи не возвращаются?
Сначала проверьте, получили ли они первую пользу и должна ли их задача вообще повторяться в выбранном окне. Затем разберите качество результата, частоту проблемы и альтернативы. Уведомления не исправят продукт, который не решил исходную задачу.
Когда для проверки уже нужен MVP?
MVP нужен, когда главную гипотезу нельзя честно проверить интервью, прототипом, ручной услугой, лендингом или техническим прототипом. Его состав ограничивают одним рискованным сценарием и событиями, которые заранее связаны с решением продолжить, изменить или остановить работу.
Разберём три главных риска до большой разработки
Пришлите описание идеи, аудитории, ключевой гипотезы и доступного канала первых пользователей. На встрече мы пройдём шесть шкал, отделим слова от поведения и подберём для трёх слабых мест простые тесты без лишней разработки. Результатом станет план первых 100 пользователей: события, окна, знаменатели и правила «продолжить / изменить / остановить». Первая встреча не обязывает заказывать разработку.