Как понять, стоит ли делать продукт: проверка идеи до затрат

Сформулируйте гипотезу так, чтобы её можно было проверить

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

Идея в одном предложении

Используйте простую формулу: для кого → какая проблема → какой измеримый результат.

Пример:

«Для владельцев небольших салонов красоты, которые теряют записи из‑за хаоса в сообщениях, мы даём способ подтверждать визиты автоматически, чтобы снизить долю неявок на 20% за 30 дней».

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

Ключевые допущения (что должно быть правдой)

Любая гипотеза держится на нескольких «если». Выпишите 3–5 самых рискованных:

• проблема действительно регулярная, а не редкий случай;
• люди уже пытаются решать её каким-то способом (даже костылями);
• у них есть право/возможность менять процесс;
• они готовы выделить время/деньги на решение;
• вы можете дать результат быстрее/дешевле/надёжнее, чем альтернативы.

Важно: приоритизируйте допущения по риску. Если самое рискованное окажется ложным, остальное не имеет смысла проверять.

Что означает успех и провал

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

Примеры критериев:

• успех: 10 из 20 целевых респондентов описывают проблему как «критичную» и готовы оставить контакт/записаться в лист ожидания;
• провал: меньше 3 из 20 признают проблему значимой или никто не готов сделать следующий шаг.

Это гипотеза, а не фича‑лист

Оставьте функции в стороне. Формулировка «сделаем приложение с календарём, чат‑ботом и аналитикой» — не гипотеза, а набор предположений.

На старте вам важнее проверить поведение (готовность менять привычки и платить), а не «красоту решения». Функции пригодятся позже — когда станет ясно, за что именно люди готовы «проголосовать» временем и деньгами.

Проверьте, что проблема действительно болезненная

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

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

Описываем текущие замены

Соберите 5–10 примеров того, как люди обходятся без вас, и запишите в формате:

• ситуация → что делают сейчас → сколько это занимает → что раздражает/ломается → чем рискуют

Ищите не слова «неудобно», а конкретику: где именно теряется время, возникают ошибки, срываются сроки.

Признаки, что «болит» по‑настоящему

Боль обычно проявляется через измеримые сигналы:

• частота: проблема возникает регулярно (ежедневно/еженедельно), а не «пару раз в год»;
• стоимость ошибки: ошибки приводят к штрафам, потерянным сделкам, возвратам, переработкам;
• риск: есть риск сорвать обязательства, испортить репутацию, нарушить правила;
• потери времени/денег: люди уже платят деньгами (подрядчикам/сервисам) или часами команды.

Если человек говорит «да, неприятно», но не может назвать последствия — вероятно, это слабая боль.

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

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

Ещё один точный вопрос: «Что вы уже пробовали, чтобы исправить это?» Наличие попыток и затрат — сильный сигнал.

Чек‑лист: реальная проблема или «приятно бы иметь»

Проблема скорее реальная, если:

• люди уже тратят ресурсы на обходные решения;
• могут назвать недавний конкретный случай и последствия;
• есть владелец проблемы (тот, кто отвечает и страдает), а не просто «кому-то неудобно»;
• есть понятный порог ценности: «Если сократим X на 30%, это спасёт Y».

Если же ответы абстрактные, последствия неясны, а решать «когда-нибудь» — это, скорее всего, «приятно бы иметь».

Определите целевую аудиторию и сегменты

Если «нашим продуктом могут пользоваться все», проверка идеи почти всегда превращается в шум: разные люди хотят разного, платят по‑разному и принимают решения по разным правилам.

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

Разделите роли: пользователь, плательщик, влияющий

Для начала разложите аудиторию по ролям — часто это разные люди:

• Пользователь: тот, кто будет работать с продуктом каждый день и испытывать боль.
• Плательщик: тот, кто выделяет бюджет и подписывает счёт.
• Влияющий на выбор: тот, кто может «протолкнуть» или «зарубить» покупку (руководитель, бухгалтерия, ИТ/безопасность, партнёр, супруг(а) и т. п.).

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

Минимальный портрет сегмента

Сегмент — это не «малый бизнес» и не «женщины 25–45». Минимальный портрет должен описывать ситуацию, в которой возникает задача.

Что стоит зафиксировать в 6–8 строк:

• Контекст: где и когда возникает проблема (работа/дом, сезонность, срочность, частота).
• Задача: какую работу человек пытается выполнить (не «хочу функцию», а «хочу добиться результата»).
• Ограничения: время, регламенты, требования безопасности, отсутствие полномочий, низкая цифровая зрелость.
• Текущий обходной путь: как решают сегодня (таблицы, мессенджеры, ручной труд, подрядчики).
• Бюджет и способ оплаты: личные деньги/корпоративный бюджет, разовая покупка/подписка, лимиты.

Этого достаточно, чтобы писать понятные вопросы для интервью и собирать сигналы спроса без угадывания.

Как выбрать 1–2 приоритетных сегмента для старта

Не пытайтесь покрыть всё сразу. Выберите один основной и один запасной сегмент по простым критериям:

1. Сила боли: проблема частая, дорогая или рискованная — за неё готовы «платить вниманием» прямо сейчас.
2. Доступ к людям: вы реально можете быстро найти 15–30 представителей сегмента.
3. Платёжеспособность: есть понятный источник денег и понятная логика согласования.
4. Повторяемость: схожие сценарии у многих — продукт можно масштабировать, а не собирать «на заказ».

Если два сегмента одинаково привлекательны, выбирайте тот, где проще добраться до первых разговоров и первых пилотов.

Где искать людей из сегмента

Составьте список мест, где эти люди уже обсуждают свою работу или регулярно собираются:

• Профессиональные сообщества и чаты (по роли: бухгалтеры, HR, руководители отделов продаж и т. д.).
• Форумы и Q&A‑площадки по теме задачи.
• Комментарии к профильным каналам и рассылкам, вебинары, онлайн‑конференции.
• Офлайн: митапы, выставки, коворкинги, отраслевые клубы, учебные центры.
• Маркетплейсы услуг и фриланса (если задача часто отдаётся «на сторону»).

Цель этого шага — не «собрать охват», а обеспечить стабильный поток контактов для интервью и тестов гипотез на ближайшие 2–3 недели.

Проведите интервью: вопросы и ошибки, которые ломают данные

Интервью нужно не для того, чтобы «продать идею», а чтобы понять реальную боль, контекст и то, как люди уже решают задачу. Если после разговора у вас есть только «классная идея, я бы пользовался», — данных нет.

Цель и настрой

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

10–15 вопросов, которые дают факты

1. Расскажите, чем вы занимаетесь и за что отвечаете в этой задаче?
2. Вспомните последний раз, когда возникла проблема. Что стало триггером?
3. Что вы пытались сделать в первую очередь?
4. Какие шаги заняли больше всего времени или нервов?
5. Что пошло не так? Где вы «застряли»?
6. Чем это закончилось (результат, сроки, потери)?
7. Как вы решаете это сейчас? Какие инструменты/исполнители используете?
8. Какие альтернативы рассматривали и почему отказались?
9. Как вы понимаете, что решение «хорошее»? 3–5 критериев выбора.
10. Что для вас неприемлемо (красные флаги)?
11. Кто ещё влияет на выбор/оплату?
12. Сколько раз в месяц/квартал это случается?
13. Сколько времени/денег уходит сейчас (приблизительно)?
14. Были ли попытки автоматизировать/делегировать? Почему не взлетело?
15. Если бы проблема исчезла завтра — что бы изменилось?

Ошибки, которые ломают данные

• Наводящие формулировки: «Вам же было бы удобно, если…?»
• Вопросы про гипотетическое будущее вместо «последнего случая».
• «Похвала вместо фактов»: собеседник поддерживает вас, но не подтверждает боль действиями.
• Рассказывать питч в середине интервью и подталкивать к согласию.

Что фиксировать после каждого интервью

Записывайте дословные цитаты, частоту проблемы, текущие заменители (включая «Excel/чаты/ручной труд»), критерии выбора и признаки готовности платить: упоминание бюджета, уже оплаченные решения, срочность, готовность на пилот/предоплату.

Добавляйте короткий итог: «боль 1–10», «как решают сейчас», «что было бы триггером смены решения».

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

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

Качественные сигналы: когда боль настоящая

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

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

Количественные сигналы: действие вместо слов

Количественные сигналы важны тем, что требуют «микрообязательства».

• Заявки на демо/консультацию (особенно если человек выбирает время в календаре).
• Предзаказы / депозит / счёт на оплату — один из самых сильных сигналов.
• Подписки в лист ожидания с подтверждением почты и ответом на 1–2 уточняющих вопроса.
• Опросы: ценны не проценты «интересно», а доля тех, кто готов оставить контакты, назвать бюджет или согласиться на пилот.

Как отделять «интересно» от «куплю/использую»

«Интересно» — это реакция на новизну. «Куплю/использую» — это готовность поменять поведение.

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

Мини‑таблица: сигнал → интерпретация → следующий тест

Разберите конкурентов и заменители без самообмана

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

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

Список альтернатив: прямые, косвенные и «вручную»

Соберите таблицу из 10–20 вариантов. Источники: поисковая выдача, маркетплейсы, отзывы, тематические чаты, рекомендации людей из вашей ЦА.

Разделите альтернативы на три группы:

• Прямые: решают ту же задачу тем же способом.
• Косвенные: решают задачу иначе (например, вместо сервиса — агентство).
• Ручные обходные пути: шаблоны, таблички, собственные процессы, «сделаю сам».

Разбор без иллюзий: за что платят, что бесит, где пробел

По каждому варианту ответьте (по возможности с фактами):

1. За что платят сейчас: подписка, разовая покупка, процент, часы специалиста, «налог времени» на ручной труд.
2. Что не нравится: дороговизна, сложность, медленно, нет нужной функции, плохая поддержка, риск ошибок.
3. Где пробел: какие сценарии остаются нерешёнными или решаются слишком дорого/долго.

Важно фиксировать не «нам кажется», а цитаты и конкретику: «плачу 5 000 ₽/мес, потому что экономит 3 часа в неделю», «бросил через 2 дня — слишком сложно настроить».

Матрица позиционирования: чем вы отличаетесь и почему это важно

Сделайте простую матрицу 2×2: по оси X — время до результата (быстро/долго), по оси Y — стоимость владения (низкая/высокая). Разложите альтернативы и отметьте пустую зону, куда хотите попасть.

Рядом сформулируйте отличие в формате: «Для [сегмента] мы [обещание], потому что [механизм], и это измеряется [метрика]».

Главный риск: «мы лучше» без измеримого преимущества

Фразы вроде «удобнее», «качественнее», «современнее» не работают, пока не превращены в измерение: на сколько минут быстрее, на сколько ошибок меньше, на сколько дешевле, какой KPI растёт.

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

Проверьте, как вы будете находить первых клиентов

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

Прикиньте 3–4 канала, которые доступны «сегодня»

Оцените каналы по двум критериям: доступность (можете начать за неделю) и контролируемость (можете повторять результат).

Подходящие варианты для старта:

• Органика: контент, SEO, комьюнити, личные контакты, экспертные выступления.
• Партнёрства: интеграции с сервисами, агентствами, обучающими центрами, реферальные программы.
• Продажи: холодные письма/звонки, поиск в профессиональных сетях (если релевантно), точечный аутрич по списку.
• Маркетплейсы и каталоги: размещение там, где аудитория уже ищет решения (B2B‑каталоги, app/plug‑in marketplaces).

Нарисуйте простую воронку

Используйте базовую цепочку: показ → интерес → контакт → сделка → удержание.

Важно: на раннем этапе можно «склеивать» шаги. Например, вместо полноценного продукта — лендинг + форма заявки; вместо автоматического онбординга — личное сопровождение.

Метрики, которые реально измерить сразу

Ставьте показатели, не требующие сложной аналитики:

• конверсия показ → клик/переход (CTR) для объявлений/постов;
• конверсия переход → контакт (заявка, письмо, созвон);
• доля контакт → сделка/пилот;
• время до результата: сколько дней от первого касания до решения;
• стоимость лида/созвона (хотя бы грубо).

Как понять, что канал слишком дорогой или сложный

Тревожные сигналы: канал требует редких компетенций (например, сложный SEO на конкурентной теме), длинный цикл сделки без ресурсов на «дожим», стоимость контакта выше потенциальной маржи, или результаты не повторяются (один удачный пост и тишина).

Практичное правило: если вы не можете за 1–2 недели получить первые 10–30 целевых контактов выбранным способом, начните с более простого канала или сузьте сегмент.

Черновая юнит‑экономика: стоит ли идея денег вообще

Юнит‑экономика — это быстрый способ понять, может ли продукт зарабатывать на одной «единице» (клиенте, заказе, подписке), не вдаваясь в сложные финансовые модели.

На этапе проверки идеи важна не точность до рубля, а честная логика: откуда берётся прибыль и что её съедает.

Мини‑модель: 4 числа, без которых вы не стартуете

Соберите черновик из четырёх параметров:

• Цена (P): сколько клиент реально готов платить (не «хотелось бы», а «похоже на рынок/интервью/прототип»).
• Валовая маржа (GM): сколько остаётся после прямых затрат на оказание услуги/поставку (себестоимость, комиссии, поддержка на единицу).
• Затраты на привлечение (CAC): сколько стоит получить одного платящего клиента (реклама, продажи, партнёры, ваше время, если оно ограничено).
• Окупаемость: за сколько покупок/месяцев маржа перекроет CAC.

Базовая проверка в одну строку:

Вклад на клиента = (P × GM) − CAC

Если вклад отрицательный — идея не «плохая», но текущая версия не сходится по деньгам: нужно менять цену, маржу, канал продаж или сегмент.

Пороговая математика: сколько продаж нужно, чтобы проект имел смысл

Добавьте постоянные расходы (F): минимум на 2–3 месяца (инструменты, фриланс, операционные расходы). Тогда порог по продажам:

Нужно продаж = F / (P × GM − CAC)

Если получается «нам нужно 3 000 продаж в месяц, а канал даёт 50» — это сигнал не «работать усерднее», а пересобрать гипотезу.

Сценарии без фантазий: оптимистичный/базовый/пессимистичный

Сделайте три набора чисел, меняя только ключевые допущения:

• Оптимистичный: верхняя граница цены и конверсии, нижняя CAC (но всё ещё правдоподобно).
• Базовый: то, что вы готовы защищать фактами.
• Пессимистичный: цена ниже, CAC выше, маржа хуже.

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

Когда достаточно «примерно», а когда нужны точные цифры

«Примерно» достаточно, когда вы выбираете между идеями или проверяете, есть ли путь к прибыли вообще. Точные цифры нужны, когда вы:

• собираетесь нанимать команду или тратить заметный бюджет;
• входите в платный канал (реклама/продажи) и хотите прогноз;
• определились с сегментом и готовы фиксировать цену.

Если на этом этапе математика не сходится — это не провал, а экономия месяцев разработки: вы узнали правду до затрат.

Техническая реализуемость и риски: что может сорвать проект

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

Что именно нужно построить, чтобы обещание стало правдой

Сформулируйте обещание продукта как проверяемый результат: «помогаем X сделать Y за Z времени/денег». Затем разложите его на обязательные элементы.

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

Оценка сложности: данные, интеграции, безопасность, поддержка, сроки

Четыре быстрых вопроса, которые дают честную оценку:

• Данные: они вообще существуют? Насколько они полные, актуальные и «чистые»? Кто отвечает за качество.
• Интеграции: есть ли у нужных сервисов API, стабильны ли они, не придётся ли постоянно чинить соединения.
• Безопасность и доступы: потребуется ли хранить персональные данные, платёжные реквизиты, коммерческую тайну; кто будет администратором доступов.
• Поддержка: какие типовые сбои будут у пользователей и сколько это будет стоить в часах команды.

Сроки лучше оценивать диапазоном и сразу отмечать «узкие места»: доступ к данным, согласования, внедрение у клиента.

Риски: зависимости, право, качество данных

Типовые причины срыва:

• зависимость от сторонних платформ (изменили правила/тарифы/доступы — и продукт перестал работать);
• юридические ограничения (согласия, хранение данных, запреты на определённые способы обработки);
• нестабильное качество данных (продукт формально работает, но пользователи не доверяют результату).

План «как упростить»: вручную, но проверяем ценность

Если реализация выглядит тяжёлой, не начинайте с полной автоматизации. Сделайте версию, где сложные части выполняются вручную, а пользователь получает тот же результат.

Примеры упрощений: отчёт собирает специалист по шаблону; интеграции заменяются выгрузкой файла; проверки качества делаются чек‑листом. Цель — проверить, готовы ли люди платить за итог, а не за технологию.

Спланируйте MVP и эксперименты вместо полной разработки

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

Выберите формат MVP под риск, который проверяете

Не существует «правильного» MVP — есть подходящий под конкретную гипотезу.

• Лендинг + сбор заявок: проверяет интерес и понятность ценностного предложения. Подходит, если вы не уверены в формулировке проблемы/выгоды.
• Прототип (кликабельный/дизайн‑макет): проверяет, понимают ли люди сценарий и готовы ли пройти путь до результата.
• Консьерж‑сервис: вы вручную делаете то, что потом автоматизируете. Проверяет готовность платить и реальную частоту использования без разработки.
• Пилот с одной компанией/группой: подходит для B2B, когда важны интеграции и процесс внедрения.

Как ускорить MVP без тяжёлой разработки (на примере TakProsto.AI)

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

В таких случаях помогает TakProsto.AI — платформа vibe‑coding для российского рынка, где веб‑, серверные и мобильные приложения собираются в формате чата. Это удобно именно для валидации: можно за короткий цикл сделать интерактивный MVP (веб на React, бэкенд на Go с PostgreSQL, мобильное — Flutter), развернуть и протестировать с первыми пользователями. Полезные вещи для экспериментов — planning mode (чтобы зафиксировать план и объём), снапшоты и rollback (чтобы откатывать неудачные итерации), а также экспорт исходников и хостинг с кастомными доменами.

Отдельный плюс для B2B‑пилотов — инфраструктура в России и использование локализованных/opensource LLM‑моделей, что упрощает разговоры про хранение данных и требования безопасности.

Что входит в MVP: только проверка ключевого допущения

Составьте список допущений (например: «боль острая», «нам доверяют данные», «готовы платить X», «канал привлечения работает») и выберите одно главное, которое, если окажется неверным, убивает идею.

В MVP оставьте только то, что помогает проверить это допущение. Всё остальное (личный кабинет, роли, отчёты, «красивости») — позже.

Критерии эксперимента: гипотеза → метод → метрика → порог успеха

Запишите эксперимент в одном абзаце:

Гипотеза: кто и в какой ситуации хочет результат.

Метод: лендинг/прототип/консьерж/пилот.

Метрика: что считаем (конверсия в заявку, число оплаченных пилотов, доля повторных обращений, время до результата).

Порог успеха: конкретное число и срок (например: «10 заявок за 7 дней при бюджете до 15 000 ₽» или «3 компании согласились на платный пилот»).

Сроки и бюджет: ограничьте тест, чтобы не «строить вечно»

Заранее задайте рамки: 1–2 недели на подготовку, 1–3 недели на сбор данных, фиксированный бюджет и список задач, которые нельзя добавлять в ходе теста.

Если порог не достигнут — вы либо меняете гипотезу/сегмент, либо честно говорите «no‑go» и экономите месяцы разработки.

Примите решение: чёткие критерии go/no‑go и план действий

Когда собраны интервью, сигналы спроса и базовые расчёты, важно не «чувствовать», а принять решение по заранее оговорённым правилам. Иначе вы будете бесконечно допроверять идею, тратя время и мотивацию.

Матрица решения: строить / доработать / отказаться

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

• Строить (go): боль высокая, есть измеримые сигналы спроса, понятен канал первых клиентов, риски выписаны и выглядят управляемыми.
• Доработать гипотезу: боль есть, но неясно «для кого именно» или какие условия покупки; сигналы слабые/противоречивые; нужна корректировка сегмента, оффера или цены.
• Отказаться (no‑go): боль не подтверждается, платить не готовы, цикл сделки слишком длинный для ваших ресурсов, или экономика не сходится даже в оптимистичном сценарии.

Пороговые значения: что считать достаточным

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

• Интервью: 12–15 с одним сегментом, пока ответы не начнут повторяться.
• Заявки: 20–30 целевых заявок на понятный оффер (не «интересно», а с конкретной проблемой).
• Предоплаты: 3–5 предоплат/депозитов или подписанных LOI на пилот.
• Пилоты: 2–3 пилота с заранее зафиксированными критериями успеха (что должно улучшиться и как измеряется).

Если ни один сильный сигнал не достигается — это не «почти успех», а повод менять гипотезу.

Преп‑мортем: почему проект провалится

Соберите команду (или хотя бы 1–2 критичных собеседника) и ответьте: «Представим, что через 6 месяцев проект провалился. Почему?» Затем переведите причины в проверки.

Например: «слишком дорого привлекать» → тестируете цену лида; «не внедряют» → проверяете время до первого результата на пилоте.

Следующие шаги после «да»: план на 30–60 дней

На 30 дней: зафиксируйте 1 сегмент, 1 проблему, 1 обещание результата; сделайте MVP, который даёт ценность без лишних функций; запустите 1 канал привлечения; доведите до первых оплат.

На 60 дней: расширьте повторяемость (ещё 10–20 продаж/пилотов), посчитайте экономику на реальных данных, уточните позиционирование и список функций по фактическому спросу.

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

Если вы идёте через быстрые прототипы, заранее продумайте, как будете управлять итерациями (версии, откаты, фиксация требований). Это снижает риск «раскачки» MVP и помогает держать фокус на проверке гипотез, а не на бесконечной дополировке продукта.