Прошлогодний снег, или Почему мы перестали строить стартапы вокруг одной фичи?

О том, как AI меняет экономику стартапов, почему минимализм стал опасной привычкой и зачем нам петля повторяемой ценности вместо очередного недоделанного MVP.

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

«Начните с одной функции».

«Сделайте MVP за две недели».

«Не тратьте время на интерфейс».

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

«Не масштабируйте, пока не нашли Product-Market Fit».

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

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

Спросите ChatGPT, как запустить стартап. С большой вероятностью получите знакомый набор рекомендаций из эпохи Lean Startup: найдите проблему, выберите одну ключевую функцию, сделайте MVP, покажите первым пользователям.

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

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

Прошлогодний снег. Только по цене свежего альпийского.

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

Даже Стив Бланк почти уже переобулся

25 сентября 2026 года Стив Бланк опубликовал статью с довольно недвусмысленным названием: AI Killed the MVP — Long Live the IUP.

Это вторая часть серии из четырёх публикаций о том, как искусственный интеллект заставил пересмотреть программу Lean LaunchPad, разработанную Бланком в 2011 году.

И вот что интересно.

Бланк не просто констатирует, что создавать MVP стало быстрее и дешевле. Он обнаруживает гораздо более серьёзную проблему.

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

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

Наличие работающего продукта перестало быть свидетельством того, что основатели хоть что-нибудь поняли о рынке.

Бланк предлагает называть такие AI-собранные продукты Initial Untested Products (IUP). Первоначально непроверенные продукты.

Но самое важное в его статье даже не новый термин.

Бланк напоминает, что исходная задача Customer Development заключалась вовсе не в создании минимального количества функций. MVP должен был помогать проверять гипотезы обо всей бизнес-модели, а не только о продукте.

AI разрушил некоторые прежние предпосылки этого процесса. Поэтому, по мнению Бланка, недостаточно просто обновить инструменты, необходимо пересмотреть сам подход к обучению предпринимателей.

Да, существенная оговорка: Бланк не объявляет ненужными эксперименты, Customer Development или бережливое предпринимательство. Он говорит, что старый MVP больше не работает как прежний индикатор прогресса и полученного знания.

И здесь наши взгляды сближаются, хотя вывод я делаю несколько иной.

Если разработка софта перестала быть главным ограничением, почему мы продолжаем минимизировать именно разработку софта?

Мы экономим на том, что становится дешевым

Классическая логика MVP сформировалась в мире, где разработка была дорогой.

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

Одна лишняя функция могла стоить нескольких недель и десятков тысяч долларов.

Естественно, основатели старались минимизировать объем разработки.

Но сегодня агентная инженерия радикально меняют эту экономику.

Разумеется, сложные интеграции, безопасность, надежность, эксплуатация и технический долг никуда не исчезли. Production-ready продукт по-прежнему требует серьезной работы.

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

И одновременно происходит другая вещь: стоимость копирования ваших функций снижается тоже.

Вы придумали AI-генератор курсов? Отлично. Завтра появятся еще двадцать.

Вы создали умного помощника для продавцов? Прекрасно. Через неделю похожие инструменты смогут собрать десятки других команд.

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

И вот парадокс.

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

Есть даже такие каналы и блоги, они реально запускают такие проекты и даже делают на них свои первые $300-500. Вот только монетизируют они на самом деле не стартапы, а вас, как аудиторию. Реклама, партнерки, запуски образовательных продуктов - вот на чем зарабатывают все эти “знатоки”.

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

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

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

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

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

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

И парадокс, да, это часто требует оверхеда!

False Negative by Design: как убить хорошую идею плохим экспериментом

Представьте, что вы решили создать новый образовательный продукт.

Большая гипотеза: люди хотят не просто получать знания, а непрерывно развиваться, приобретать навыки, применять их на практике, получать обратную связь и что-то там еще (не могу рассказать, т.к. это один из наших продуктов).

Но ментор говорит вам: Слишком сложно. Начните с одной функции.

И вы делаете генератор мини-курсов.

Пользователь вводит тему, получает курс, читает несколько уроков и уходит.

Ретеншн низкий. Платить никто не хочет.

Гипотеза не подтвердилась?

Позвольте, какая именно?

Вы проверили востребованность генератора учебных материалов. Но вы даже не поинтересовались, а зачем это пользователю? Или поинтересовались зачем, но не озадачились тем, чтобы помочь ему достичь именно того, что ему на самом деле нужно. 

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

Вы вырезали из продукта почти всё, что могло сформировать его настоящую ценность.

А затем объявили идею нежизнеспособной.

Я называю это False Negative by Design, или ложноотрицательный результат, заложенный в конструкцию эксперимента.

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

И это касается не только количества функций.

Ещё в 2016 году Y Combinator в материале Practical Design: MVP Spec подчёркивал принципиальную разницу между прототипом и продуктом: для пользователя MVP должен выглядеть как законченный продукт с понятным назначением и целостным опытом использования.

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

Сегодня тем более.

Пользователь сравнивает ваш продукт не с вашим бюджетом разработки. Он сравнивает его с привычным цифровым опытом.

Он не знает, что у вас pre-seed, три разработчика и заканчиваются деньги.

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

Он либо получает обещанную ценность, либо закрывает вкладку.

А вы потом можете сколько угодно анализировать причины отсутствия Product-Market Fit.

Value Coverage: иногда нужно построить больше, чтобы проверить меньше

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

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

Не потому, что основатели страдают гигантоманией.

А потому, что ценность может возникать не внутри отдельной функции, а между ними.

Вернёмся к образовательному продукту.

Генерация курса сама по себе может быть полезной. Но настоящая ценность возникает в последовательности:

Твоя текущая цель → Образовательный продукт → Проверка понимания → Обнаружение пробелов → Наставник → Практика → Результат → Новая цель.

Это уже не набор функций. Это воспроизводимый пользовательский процесс.

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

Может быть, за генерацию курса пользователь не готов заплатить ни копейки.

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

Или за доступ к людям, которые помогают освоить профессию.

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

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

Если мы будем создавать и проверять каждый шаг как отдельную итерацию, с запуском цикла маркетинга, с выводами, вcе по HADI, то вы можете разочароваться раньше, чем найдете рабочую джобу (JTBD). И помним, что отдельно взятая джоба может оказаться лишь одним элементом всей ценности и опыта, который получает пользователь в продукте. Но вы по нему будете судить об успешности всего продукта.

Поэтому в нашей венчурной студии мы используем принцип, который называем Value Coverage, или покрытие пространства пользовательской ценности.

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

• Willingness-to-pay — за какой результат пользователь действительно готов платить.

• Retention — что заставляет его возвращаться без постоянного рекламного подталкивания.

• Expansion — как первоначальное использование естественным образом порождает новые сценарии, платежи и рекомендации.

Здесь есть принципиальная разница между расширением функциональности и расширением ценности.

Добавить еще десять возможностей в продукт это не стратегия.

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

И это приводит нас к следующему вопросу.

Почему одна фича больше не защищает бизнес

В последние годы мы наблюдаем ускоряющуюся коммодитизацию софта.

AI-модели становятся доступнее. Типовые интерфейсы воспроизводятся быстрее. Интеграции стандартизируются. Агентные инструменты снижают порог создания функциональности.

Это не означает, что любое ПО теперь легко скопировать. Глубокая отраслевая экспертиза, собственные данные, сложные интеграции и регуляторные барьеры по-прежнему имеют значение.

Но для огромного количества AI-стартапов уникальная функция перестает быть устойчивым конкурентным преимуществом.

Сегодня вы продаёте AI-помощника за 30000 рублей в месяц.

Завтра конкурент предлагает похожего за 3000 рублей. А другой через 3 месяца за 1000 рублей.

Послезавтра крупная платформа включает аналогичную возможность в уже существующую подписку.

И что дальше?

Снижать цену? Увеличивать рекламные расходы? Надеяться на лояльность пользователей?

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

Я бы сформулировал эволюцию конкурентного преимущества так:

Фича даёт вход. Процесс создает привычку. Система накапливает контекст и повышает стоимость переключения. Экосистема открывает новые источники ценности. И все это создает петлю воспроизводимой ценности.

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

Но для многих AI-native продуктов именно здесь возникает возможность уйти от ценовой конкуренции. 

А что, если ваша главная фича еще даже не придумана!?

Есть ещё одна проблема с философией найдите одну фичу и стройте вокруг неё стартап.

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

Но история технологий постоянно доказывает обратное.

Возьмём тот же OpenAI.

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

В 2018 году появилась первая GPT. В 2019-м GPT-2. В 2020 году OpenAI представила GPT-3 API, предоставив разработчикам универсальный инструмент для создания множества различных приложений. 

И только в ноябре 2022 года вышел ChatGPT.

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

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

А затем — просто Чат.

Конечно это не просто чат. За ним как раз стояли все эти годы R&D.

И конечно же я не утверждаю, что OpenAI семь лет сознательно строила экосистему ради обнаружения Чата.

Но именно это и делает пример интересным.

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

И здесь возникает вопрос к поклонникам однофичевых MVP.

Что именно OpenAI должна была минимизировать в 2016 году?

Какую одну функцию выбрать?

Какую гипотезу объявить главной?

И что делать, если настоящая точка соприкосновения с массовым рынком появится только после нескольких поколений технологий?

Я не предлагаю стартапам семь лет заниматься исследованиями, прежде чем выпустить продукт. Большинство просто не переживёт такого эксперимента.

Но этот пример демонстрирует важную вещь:

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

Именно поэтому мы считаем Value Coverage не только способом проверить текущую гипотезу, но и способом повысить вероятность обнаружения неожиданных источников ценности.

Посмотрите, куда движутся стартапы, в которые инвестируют миллиарды

В 2025–2026 годах несколько заметных AI-компаний продемонстрировали переход от отдельных возможностей к связанным системам и рабочим процессам.

Glean. Начав с корпоративного поиска знаний, компания развивает платформу организационного контекста и AI-агентов, объединяющую данные, людей и бизнес-процессы. В июне 2025 года Glean привлекла $150 млн при оценке $7,2 млрд. Компания также сообщила о превышении $100 млн ARR. Важнее суммы раунда сама логика: поиск становится точкой входа в инфраструктуру корпоративной работы.

Harvey. Юридический AI быстро понял, что быть просто инструментом поиска и подготовки документов не выгодно. Harvey развивает агентов, которые выполняют последовательности юридических задач внутри рабочих процессов компаний. В марте 2026 года стартап объявил о привлечении $200 млн при оценке $11 млрд. По данным компании, клиенты уже использовали более 25 тысяч собственных агентов.

Sierra. Компания строит платформу AI-агентов для клиентского взаимодействия. Не просто чат-бота, который отвечает на вопросы, а систему, способную участвовать в возвратах, страховых операциях, обслуживании клиентов и других процессах. В мае 2026 года Sierra объявила о раунде на $950 млн с оценкой свыше $15 млрд.

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

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

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

И это не обязательно экосистема с маркетплейсом, социальным графом и сотней модулей.

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

Не минимальная фича, а минимальная петля ценности 

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

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

Мы перестали считать минимальную функциональность целью первого релиза. Вместо этого мы проектируем минимальный целостный продукт, в котором уже замыкается петля воспроизводимой ценности. Пользователь получает результат, этот результат создаёт основания для следующего взаимодействия, а каждое следующее взаимодействие потенциально делает продукт полезнее.

Именно такие системы мы проверяем в рынке.

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

Вместо того чтобы запустить очередной умный медицинский чат а-ля GPT Health и ждать чуда, мы создаём минимальную целостную систему.

Человек загружает медицинские документы и результаты анализов. AI помогает собрать разрозненную информацию в единую картину здоровья, обнаруживает потенциальные риски и противоречия, объясняет назначения врача, помогает подготовиться к консультации и при необходимости получить независимое второе мнение.

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

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

Возникает петля воспроизводимой ценности:

Медицинские данные → Понимание состояния → Выявление рисков и неопределённости → Обоснованное решение с врачом → Действие → Наблюдение результата → Обновление медицинского контекста → Следующее решение.

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

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

Это принципиально другой продукт.

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

Главное, чтобы петля ценности замыкалась.

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

А мы — возможность измерить это поведение.

Это не лицензия на бесконечную разработку.

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

1. Нужна ли она для достижения ключевого пользовательского результата?

2. Помогает ли она замкнуть критическую петлю удержания, монетизации или привлечения? Например, за счет лучшего UX.

3. Проверяет ли она принципиальную гипотезу будущей платформы?

Если на все три вопроса ответ отрицательный, то функция нам пока не нужна.

Мы минимизируем не количество функций. Мы минимизируем объём системы, необходимой для воспроизводства и проверки ценности.

Но ведь экосистема стоит дороже? Не обязательно

Здесь мы подходим к вопросу, который особенно интересен тем, кто умеет считать.

Положительная юнит-экономика.

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

В эпоху коммодитизации функций это становится особенно опасно.

Если пользователи легко переходят между похожими продуктами, растёт давление на цену. Если продукт не создаёт причин возвращаться, приходится снова и снова покупать трафик.

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

Экосистемность может изменить эту экономику сразу несколькими способами.

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

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

В-третьих, накопленный персональный или корпоративный контекст позволяет делать продукт полезнее по мере использования.

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

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

Но важно не обманывать себя: экосистемность не гарантирует положительную юнит-экономику.

Она тоже стоит денег. Дополнительные AI-вызовы, инфраструктура, поддержка, сложность интерфейса и сопровождения могут съесть всю дополнительную выручку.

Поэтому мы должны проверять не только retention и willingness-to-pay, но и contribution margin, CAC payback, LTV/CAC, стоимость обслуживания активного пользователя и предельную экономику каждого дополнительного сценария.

Именно здесь проходит граница между экосистемой и дорогой свалкой функций.

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

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

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

В условиях коммодитизации функций устойчивое преимущество всё чаще возникает не из самой функциональности, а из того, как продукт соединяет задачи, контекст и повторяемую ценность в единую систему. 

И всё-таки, смена мышления медленнее чем реальность

Возвращаясь к Стиву Бланку.

В заключительной статье своей серии, Lean LaunchPad — The Next Generation, опубликованной 30 сентября 2026 года, он описывает свою обновленную программу. Заметьте, тоже вас монетизирует, а не свою методику) 

Хотя он и реальный практик, с этим не поспоришь, но уж больно консервативный.

Вместо MVP как универсального доказательства прогресса появляются IUP Snippets для проверки отдельных гипотез, Minimal Tested Canvas для проверки бизнес-модели, Product-Outcome Fit и Design Partners, которые действительно используют продукт и получают результат.

И да, Бланк вновь не призывает строить больше функций. Напротив, он предлагает ещё строже относиться к доказательствам и ещё быстрее проводить эксперименты. Еще быстрее! И еще быстрее!

И в результате ваша команда, с высунутыми языками, после 50 цикла проверки очередной …  IUP Snippets …в фирменном Minimal Tested Canvas от Бланка, просто тихо расходится. А вы, выгоревший насквозь, берете паузу, а потом идете собирать новую команду.

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

Эти подходы на самом деле не противоречат друг другу. Мы просто немного сместили фокус.

Можно проверять отдельные предположения маленькими экспериментами. Можно вообще не писать код, пока нет свидетельств спроса.

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

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

Вместо заключения

Я больше двадцати лет наблюдаю, как меняются технологии, рынки и подходы к созданию инновационного бизнеса. Я провел много лет в большом консалтинге, более пяти лет в Сколково в роли ментора стартапов.

И меня не перестаёт удивлять одна особенность предпринимательской индустрии.

Технологии меняются быстрее, чем методички.

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

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

Мы говорим о Product-Market Fit, но иногда даже не даём пользователю испытать тот продукт, для которого собираемся его искать.

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

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

И если кто-то снова посоветует вам сделать однофичевый MVP, чтобы побыстрее проверить рынок, попросите его объяснить, какую именно гипотезу этот продукт способен проверить?

Возможно, выяснится, что он предлагает вам проверить не рыночный спрос, а статистическую вероятность удачи, ну или просто терпение пользователей. А его хватает на 10-20 секунд от силы.