Уроки Y Combinator: почему стартапы выигрывают, начав с малого

Почему успешные стартапы часто начинаются «маленькими»

Y Combinator годами повторяет одну и ту же мысль: на ранней стадии важнее не «выглядеть большим», а быстро доказать, что вы кому-то реально нужны. Поэтому в заявках и интервью YC обычно ценят не громкие обещания и презентации, а ясность: какая боль решается, для кого именно, и почему команда способна сделать решение лучше существующих альтернатив.

Что YC ценит в ранних проектах

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

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

Почему «маленькое начало» — это стратегия

Начинать с малого — значит сознательно выбрать точку входа, где вы можете:

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

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

Что значит «узко» и «почти скучно» на практике

«Узко» — это когда вы можете закончить фразу: «Мы делаем X для Y в ситуации Z». А «почти скучно» — когда решение фокусируется на одной понятной задаче, а не пытается одновременно быть маркетплейсом, соцсетью и платформой.

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

Кому это особенно полезно

Подход start small особенно выигрывает у команд 1–5 человек: ограниченное время и бюджет превращаются в преимущество, если вы режете всё лишнее и доводите до отличного результата один конкретный сценарий. Когда это получилось, расширяться становится проще — уже на основе реальных данных, а не предположений.

Что означает «почти скучно» и почему это работает

«Почти скучно» — это не про отсутствие амбиций. Это про идею, которую легко объяснить за 20 секунд: боль пользователя очевидна, а эффект можно измерить (сэкономили 3 часа в неделю, сократили ошибки на 30%, закрыли задачу без трёх согласований).

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

«Скучно» = понятная рутина, которая стоит денег

Во многих компаниях самые дорогие проблемы — это скучная рутина:

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

У этих задач есть два подарка для стартапа: они происходят регулярно (значит, привычка уже есть) и у них есть метрика (значит, ценность можно доказать).

Чем опасны «большие визионерские» идеи на старте

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

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

Как отличить простоту от банальности

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

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

Как выбрать узкую нишу без долгих исследований

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

Сигналы, что ниша слишком широкая

Если вы ловите себя на мысли «наш продукт для всех, кому нужно…», вы уже ушли в слишком общий рынок. Типичные признаки:

• У вас получается 5–10 разных ICP, и каждый требует свой онбординг, свои фичи и свой маркетинг.
• Есть много сценариев использования, которые не пересекаются (например, «для фрилансеров» и «для корпораций»).
• Вы не можете назвать одного человека, которому прямо завтра напишете с предложением.

Широкая ниша почти всегда приводит к распылению фокуса команды: вы строите «понемногу для всех», но не решаете ничего до конца.

Быстрый тест: одно предложение без «и ещё»

Попробуйте сформулировать проблему так, чтобы не добавлять «и ещё»:

«[конкретный человек] не может [сделать конкретное действие] из‑за [конкретной причины], поэтому теряет [измеримую ценность]».

Если предложение разваливается без уточнений или превращается в список через запятые — ниша пока слишком размыта.

Как выбрать сегмент с высокой частотой боли

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

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

Оценка доступности первых пользователей: где они обитают

Узкая ниша должна быть не только болезненной, но и достижимой. Спросите себя:

• Где эти люди собираются: чаты, сообщества, офлайн‑ивенты, профессиональные рассылки?
• Можно ли составить список из 30–50 потенциальных пользователей за 1–2 дня?
• Есть ли у вас «вход» через знакомых, бывших коллег, клиентов?

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

ICP: один конкретный пользователь вместо «для всех»

ICP (Ideal Customer Profile) — это не «кто-то, кому потенциально понравится». Это один тип человека в одном контексте, у которого боль настолько ясная, что он готов менять привычки и платить (или хотя бы активно пробовать) уже сейчас.

Портрет идеального первого клиента: роль, контекст, триггеры

Соберите портрет так, чтобы вы могли представить конкретный рабочий день этого человека.

• Роль: кто он по должности и за что отвечает (например, «руководитель отдела продаж в B2B» или «операционный менеджер в доставке»).
• Контекст: где и как он работает (команда 5–10 человек, всё ведут в таблицах, нет аналитика, решения принимает сам).
• Триггеры: события, после которых проблема становится срочной (сорвали дедлайн, выросло количество обращений, появился новый регламент, «закрыли» привычный инструмент).

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

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

Для первого ICP выберите один главный job-to-be-done: конкретное действие, которое пользователь делает регулярно и которое вы можете улучшить заметно.

Хорошая проверка: если вы уберёте остальные сценарии и оставите один — продукт всё ещё будет ценным? Если да, вы на правильном пути.

Полезные ограничения: география, индустрия, размер

Ограничения — это не «сужение рынка», а ускоритель обучения.

• География: один город/страна, где вы понимаете язык, платежи и реалии.
• Индустрия: одна вертикаль, чтобы не менять терминологию и процессы каждые два разговора.
• Размер компании: например, только команды до 30 человек, где покупатель — тот же пользователь.

Как не перепутать ICP и «всех, кому может быть интересно»

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

Практика: допишите предложение — «Мы решаем проблему X для Y, когда происходит Z». Если в Y больше двух типов ролей или в Z нет конкретного события, вы снова скатываетесь в «для всех».

MVP: минимально, чтобы проверить спрос

MVP в духе YC — это не «урезанная версия мечты», а быстрый способ проверить одно ключевое допущение: пользователь действительно хочет решить эту боль и готов что‑то сделать ради решения (заплатить, оставить заявку, регулярно пользоваться, порекомендовать).

MVP как проверка ключевого допущения

Сформулируйте допущение одной фразой: «Если мы дадим X пользователю Y, он сделает Z». Например: «Если владельцу небольшого интернет‑магазина дать простую страницу с учётом возвратов, он будет заносить туда данные каждую неделю». Затем MVP должен проверять именно это, а не весь «продукт будущего».

Хороший признак: вы можете за 10 минут объяснить, какой факт подтвердит гипотезу и какой факт её опровергнет.

Одна метрика на 2–4 недели

На короткий спринт выберите одну измеримую метрику, которая отражает спрос:

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

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

Что можно делать вручную (консьерж‑подход)

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

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

Критерии «достаточно, чтобы запустить»

MVP готов, если:

• пользователь может получить обещанную ценность за один короткий сценарий;
• вы можете привести 5–10 пользователей к этому сценарию без сложных инструкций;
• есть способ собрать обратную связь и измерить выбранную метрику;
• ошибки не ломают всё: можно быстро поправить и повторить.

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

Как ускорить сборку MVP без потери фокуса

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

В таких ситуациях полезны подходы vibe-coding: когда вы описываете продукт словами, а платформа помогает собрать рабочее веб/серверное/мобильное приложение быстрее, чем классическое программирование с нуля. Например, в TakProsto.AI можно в чате накидать первую версию приложения под ваш один сценарий (лендинг + форма заявки, простая панель, интеграция с базой), затем включить planning mode, чтобы зафиксировать требования и не расползаться по фичам. Дальше — быстро итератировать, используя снапшоты и откаты, и при необходимости экспортировать исходники.

Плюс для российской аудитории: TakProsto.AI работает на серверах в России, использует локализованные/opensource LLM и не отправляет данные за пределы страны — это важно, если ваш ICP чувствителен к требованиям безопасности и хранению данных.

Разговоры с пользователями: как получать полезные ответы

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

Интервью vs продажи: что вы пытаетесь узнать

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

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

10 вопросов, которые вытаскивают реальность

1. «Расскажите про последний раз, когда это произошло. Что именно случилось?»
2. «Как часто это бывает: раз в день/неделю/месяц?»
3. «Что вы делаете сейчас, чтобы решить это?»
4. «Какие инструменты/сервисы используете? Почему именно они?»
5. «Что в текущем решении бесит сильнее всего?»
6. «Сколько времени уходит на это в неделю?»
7. «Кто ещё вовлечён? Кто принимает решение?»
8. «Что будет, если ничего не менять следующие 3 месяца?»
9. «Пробовали ли вы уже покупать/внедрять что-то? Почему не взлетело?»
10. «Если бы проблема исчезла, что стало бы проще/быстрее/дешевле?»

Как избежать «похвалы из вежливости»

Не спрашивайте «Вы бы пользовались?». Просите факты: «Что вы делали вчера?», «Сколько раз за неделю?», «Сколько стоит текущее решение?». Хороший тест — попросить следующий шаг: интро к коллеге, доступ к демо-данным, согласие на пилот в конкретную дату.

Фиксируйте доказательства, а не впечатления

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

Первые пользователи и первые сигналы product-market fit

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

Какие сигналы считать ранним product-market fit

На старте важны не абсолютные числа, а повторяемые паттерны поведения:

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

Один сильный пользователь, который реально страдает без вас, иногда ценнее сотни «вроде норм».

Как измерять удержание и ценность простыми словами

Не усложняйте аналитику. Договоритесь о двух вещах:

1. Ключевое действие (что означает «получил ценность»): например, «создал отчёт», «получил ответ», «закрыл задачу».
2. Частота, с которой это должно происходить: ежедневно, еженедельно, раз в месяц.

Дальше всё сводится к вопросам: «Сколько людей повторили ключевое действие через X дней?» и «Сколько сделали это 2–3 раза подряд?».

Что считать «достаточным сигналом», чтобы продолжать

Достаточный сигнал — когда вы видите стабильную группу пользователей, которые:

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

Если этого нет, вероятно, проблема не в «маркетинге», а в ценности или фокусе — и лучше снова сузиться, чем ускоряться вслепую.

Фокус против распыления: что не делать в первые месяцы

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

Что чаще всего «съедает» время и почти не добавляет ценности

Есть типичный набор задач, которые приятно делать (и легко оправдать), но они редко двигают вас к первым регулярным пользователям:

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

Как говорить «нет» запросам и не терять клиента

Отказ — это не «мы не будем», а «мы хотим решить вашу задачу быстрее». Рабочие формулировки:

• «Понимаю запрос. Сейчас мы фокусируемся на X, чтобы гарантированно закрывать основную задачу. Если вам критично Y — расскажите, что вы делаете вместо этого сегодня?»
• «Давайте уточним: без этой функции вы не сможете начать пользоваться или это про удобство позже?»

Если запрос не блокирует использование, фиксируйте его как сигнал, но не как обязательство.

Простой бэклог: Must/Should/Could + критерии удаления задач

Держите бэклог коротким и «жёстким»:

• Must: без этого основной сценарий не работает или не проверяется.
• Should: усиливает сценарий и может заметно поднять конверсию/удержание.
• Could: приятно, но не влияет на решение «пользоваться/платить».

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

Правило: добавляйте только то, что усиливает основной сценарий

Перед тем как взять задачу в работу, спросите:

1. Какой основной сценарий она усиливает?
2. Как мы поймём эффект (конверсия в первый результат, повторное использование, оплата)?
3. Что мы не сделаем ради этого на этой неделе?

Фокус — это не отсутствие идей. Это дисциплина проверять идеи по одной, пока не появится ясный сигнал, что именно даёт ценность.

«Делайте то, что не масштабируется» — без самообмана

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

Что это значит в реальной жизни

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

Например:

• Ручная настройка аккаунта или проекта «под ключ», чтобы человек получил первый эффект за 10–30 минут, а не через неделю.
• Поддержка в чате не по скрипту, а с разбором ситуации пользователя и предложением конкретного решения.
• Персональные разборы (15–30 минут) после первого использования: что было непонятно, где застрял, чего не хватило.

Важно: вы делаете это не ради «сервиса», а ради данных и обучения команды.

Как превращать ручные шаги в автоматизацию

Хорошее правило: автоматизируйте только то, что повторяется и влияет на ценность.

Если вы уже 10 раз подряд объясняете один и тот же шаг — запишите короткую инструкцию в продукте. Если регулярно «чините» одну и ту же ошибку — добавьте проверку и подсказку. Если каждый второй просит одну интеграцию — сделайте её первой.

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

Риск: застрять в ручном режиме

Пора менять подход, если:

1. вы тратите всё время на обслуживание старых пользователей и перестали узнавать новое;
2. качество начинает падать из‑за перегруза;
3. ручные действия не приближают продукт к повторяемой модели.

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

Частые ошибки старта и как их избежать

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

Типовые ошибки: где стартапы теряют месяцы

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

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

Сложный стек. Ранний продукт редко требует микросервисов, очередей, кастомных аналитических пайплайнов и «идеальной архитектуры». Сложность увеличивает время изменений и ломает скорость обучения. Правило на старте: выбирайте то, что позволяет переделывать быстро.

Ложные метрики, которые успокаивают, но не помогают

• Регистрации без активации и регулярного использования.
• Лайки/подписки/комментарии как заменитель реальной ценности.
• «Интересно звучит» и «я бы пользовался» без конкретного действия (установил, попробовал, вернулся, заплатил).

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

Красные флаги: проверьте себя за 10 секунд

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

Как вовремя остановиться или сузиться ещё сильнее

Останавливайтесь и сужайтесь, если:

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

Практика: выберите один тип пользователя, один сценарий и один измеримый результат на ближайшие 2–3 недели. Сделайте так, чтобы этот сценарий работал идеально — и только после этого расширяйте. Если нужно — вернитесь к разделу про ICP и перепишите его заново: /blog/icp-one-user.

Когда расширяться, а когда ещё сильнее сужаться

Самая частая ошибка после первых успехов — решить, что «теперь мы для всех». YC обычно советует обратное: пока не появилось стабильное ядро, любое расширение превращает ваш продукт в набор компромиссов.

Когда стоит сужаться

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

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

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

Сигналы готовности к расширению

Расширяться стоит, когда ядро стало повторяемым:

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

Как расширяться правильно

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

Чтобы не потерять качество, расширяйте не обещания, а доказанный результат: сохраняйте главный use case как эталон, не ломайте онбординг под новых пользователей, а добавляйте ветку. И обязательно отслеживайте, не растёт ли доля «не тех» запросов — это ранний признак, что пора снова сужаться.

Короткий чек-лист: как применить уроки YC к вашему проекту

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

Чек-лист на 30 дней: ниша, ICP, боль, метрика

Сформулируйте на бумаге (и не усложняйте):

• Ниша: «Мы делаем X для Y в ситуации Z». (Один Y, одна ситуация.)
• ICP (один конкретный пользователь): должность/роль, размер компании или тип жизни, где он «живёт» (канал, сообщество).
• Одна боль: проблема, которую человек уже пытается решить (табличками, агентством, ручной работой).
• Одна метрика на 30 дней: например, 10 созвонов, 5 оплат, 20 активных пользователей в неделю — выберите одну.
• 30 дней действий: что вы реально сделаете каждый день, чтобы приблизиться к этой метрике.

Шаблон плана спринта: гипотеза → запуск → данные → вывод

1. Гипотеза: «Если мы предложим [оффер] для [ICP], то получим [метрика] за [срок]».
2. Запуск: минимальный способ проверить (не «идеальный продукт»).
3. Сбор данных: заранее решите, какие события считаются успехом/провалом.
4. Вывод:

• подтверждаем и усиливаем;
• или сужаем ICP/сценарий;
• или меняем оффер/цену.

Артефакты, которые стоит подготовить

• Лендинг с одним обещанием и одной кнопкой (заявка/оплата/лист ожидания).
• Оффер: что именно вы делаете, за сколько, и какой результат обещаете.
• Демо: короткое видео/прототип/скриншоты — достаточно, чтобы пользователь понял ценность.
• Сценарий интервью (10–12 вопросов) + форма фиксации ответов.

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

Если вы не можете объяснить продукт одной фразой без «и ещё…», фокус потерян. Формула: «Мы помогаем [ICP] сделать [результат] без [главная боль/трение]».

Если вы делаете MVP на TakProsto.AI, эту фразу удобно превращать в технический план: описываете один результат, один сценарий, одну метрику — и собираете первую версию быстрее, чем при классическом программировании. А дальше уже по-YC: разговоры, итерации, измерения, фокус.