# Lean Startup в промышленности — где методология ломается Четырнадцать лет в промышленном B2B научили меня одному: методологию нужно проверять не на том, насколько красиво она объясняет чужой успех, а на том, где она перестаёт объяснять твою собственную неудачу. Lean Startup — одна из немногих схем, которые я применяю регулярно и в которые не верю целиком. Ниже — что в ней работает в железе и дальнем экспорте, а что ломается о себестоимость итерации, сертификацию и производственный цикл. ## Метод Эрик Райс формулирует ядро метода как цикл build-measure-learn: строишь минимальный эксперимент, измеряешь реакцию рынка, делаешь вывод — продолжать курс или разворачиваться. Ключевая идея, которую упускает большинство пересказов: MVP у Райса — не урезанная версия продукта, а наименьший эксперимент, который даёт максимум подтверждённого знания на единицу усилий. Вопрос не «что мы можем выпустить», а «что нам нужно построить, чтобы проверить самое рискованное допущение» ([theleanstartup.com/principles](https://theleanstartup.com/principles)). Единица прогресса — не написанный код и не выпущенные фичи, а подтверждённая или опровергнутая гипотеза. Стив Блэнк, у которого Райс заимствовал часть аппарата, подошёл к той же проблеме с другой стороны — с продаж, а не с разработки. Его customer development строится на тезисе: стартап гибнет не потому, что не может построить продукт, а потому что не может найти клиентов и повторяемую бизнес-модель. Отсюда четыре шага — customer discovery, customer validation, customer creation, company building — и правило, которое Блэнк повторяет во всех текстах: фактов внутри офиса нет, они снаружи ([steveblank.com](https://steveblank.com/2009/08/31/the-customer-development-manifesto-reasons-for-the-revolution-part-1/)). Процесс у него принципиально не линейный: несколько итераций одного и того же шага — это не брак, а расчётная часть модели. Обе схемы держатся на одном допущении: цикл эксперимента можно сжать почти до предела, а цена ошибки на ранней стадии близка к нулю. Это допущение верно для софта. В промышленном железе оно перестаёт быть верным на первом же шаге. ## Где ломается в промышленности В софте итерация — это деплой. В железе и в контрактном производстве итерация — это новая оснастка, новая партия, иногда новая сертификация. Цена ошибки растёт не линейно, а скачками: макет можно исправить бесплатно, опытный образец — за недели и тысячи, серийная оснастка — за месяцы и на порядок больше денег. Именно поэтому build-measure-learn в его софтверном темпе — недели на цикл — здесь не работает: цикл измеряется кварталами, а не спринтами, и «минимальный» продукт всё равно требует пройти инженерную валидацию, валидацию под клиента и производственную валидацию, каждая из которых стоит отдельного бюджета. У меня это не абстракция, а зафиксированная цифра. По сервисному направлению на рынке Индии ретроспектива MVP показала: затраты 1,25 млн рублей, выручка 171 тыс. рублей, срок 178 дней вместо 150 плановых. Разрыв не в том, что гипотезу проверяли неправильно — гипотезу проверяли по методу. Разрыв в том, что «минимальный» эксперимент в услуге с материальным исполнением не сжимается до недель: в него встроены закупка, логистика, согласование с производственной стороной — то, что в софтверном MVP просто отсутствует как класс затрат. Двадцать восемь лишних дней и превышение бюджета — это не ошибка исполнения, это структурная надбавка, которую Lean Startup в чистом виде не считает вовсе, потому что был придуман для среды, где такой надбавки нет ([[Ретроспектива MVP в Индии]]). Ещё жёстче методология ломается там, где перед первым разговором с рынком нужно закрыть право. На Бразилию ушло шестнадцать месяцев цепочки решений — правовой скрининг, регистрация юрлица, три сценария финансовой модели, формализация продуктового юнита — и даже после этого MVP трижды продлевали, потому что каждая итерация упаковки вскрывала новый вопрос у рынка, а не потому что где-то была ошибка в расчётах. Build-measure-learn предполагает, что можно быстро выйти к клиенту и получить сигнал. На дальнем промышленном рынке сигнал недоступен, пока не закрыт юридический и налоговый периметр — а это заранее известный срок, который никакая скорость экспериментов не сокращает ([[История Бразилии — цена входа на дальний рынок]]). Критика hardware-стартапов формулирует то же самое с инженерной стороны: партнёр венчурного фонда Bolt, работающего только с физическими продуктами, называет это [«эффектом длинной тени»](https://blog.bolt.io/speed-can-kill/) — ошибка в выборе компонента или форм-фактора становится заметной не сразу, а через полгода-год, когда доходит до первой производственной партии, и к этому моменту откатить решение уже нельзя тем же способом, что откатывают деплой. [Разбор структурной медлительности hardware-стартапов](https://www.historyfuturenow.com/articles/the-eighteen-month-trap-why-hardware-startups-are-structurally-slow) идёт дальше и называет это ловушкой: софтверный стартап доходит до первой выручки за недели, стартап, которому нужна собственная производственная инфраструктура, — за 12–18 месяцев, и это не вопрос компетентности команды, а свойство физических объектов — они требуют оснастки, сертификации и капитала до того, как принесут хоть какой-то сигнал от рынка. ## Что оставляю из Lean При этом я не выбрасываю метод целиком — я сужаю область, где он держит нагрузку. Работает часть до первого физического воплощения: проверка гипотезы разговором. Интервью стоит недели, MVP — месяцы и бюджет; если гипотеза не выдерживает десяти разговоров с реальными покупателями, она не выдержит и рынка, и дешевле узнать это до того, как под неё выделены ресурсы на оснастку или производство ([[Гипотезу дешевле убить интервью, чем MVP]]). Работает и определение MVP через факт, а не через список функций. Для меня стадия MVP закрыта не тогда, когда собран набор возможностей продукта, а тогда, когда есть цифра, которую можно сравнить с планом: контракты, выручка, затраты. Индийский кейс закрылся не описанием того, что было сделано, а разрывом 1,25 млн затрат против 171 тыс. выручки — именно этот разрыв стал предметом разбора и основанием для решения по направлению ([[MVP проверяет ценность, а не демонстрирует функции]]). И работает логика пивота, вынесенная из-под иллюзии, что упорство всегда окупается. Когда экономика двух направлений в одной стране конкурировала за общий ресурс, я объединил их в один питч вместо того чтобы тянуть оба до победного; в Бразилии я эту логику применил с опозданием — продлевал MVP месяцами вместо смены модели, и это обошлось дороже, чем стоил бы пивот, принятый на полгода раньше ([[Пивот вовремя дешевле упорства]]). ## Вывод Lean Startup — метод для среды, где цена итерации близка к нулю. В промышленном B2B она никогда не близка к нулю: там, где встроены оснастка, сертификация или иностранное юридическое лицо, «минимальный» эксперимент неизбежно обрастает бюджетом и сроком, которые метод не предусматривает. От Райса я оставляю дисциплину проверяемой гипотезы и MVP как факт, а не демонстрацию; от Блэнка — правило, что фактов внутри офиса нет. От обоих я не оставляю скорость цикла как универсальный ориентир — в железе и в дальнем экспорте её диктует не методология, а физика производства и право. ## Мои кейсы по теме - [[Ретроспектива MVP в Индии]] - [[История Бразилии — цена входа на дальний рынок]] - [[Гипотезу дешевле убить интервью, чем MVP]] - [[MVP проверяет ценность, а не демонстрирует функции]] **Практический разбор по теме:** [[Как проверить продуктовую гипотезу до вложений в проект]] ## Связаться Если у вас похожая задача — обсудим ваш продукт: [[email protected]](mailto:[email protected]), Telegram [@falcolupus](https://t.me/falcolupus) или [MAX](https://max.ru/u/f9LHodD0cOJd5VFHyaG9k7YpP7BW9s55ZYkjWX6P8j51xBYS3XgDfnOxz3U). Работаю удалённо в любом часовом поясе.