Почему Lean и MVP ломаются в B2B

В 2019 году знакомый CEO enterprise-софтверной компании позвонил с интересной проблемой. Они полгода пытались «запустить MVP» для крупного банка. Внутри команды всё по учебнику: user stories, спринты, ретро, деминг, шесть итераций. На выходе - ноль. Банк согласился посмотреть первую версию, прислал 43-страничный security review, два раза перенёс демо и через полгода мягко сказал «давайте вернёмся к этому в следующем квартале».

«Мы делали Lean по всем правилам, - сказал мне CEO. - А он не работает».

Lean и правда не работал. Но не потому, что команда что-то делала плохо. Потому что Lean Startup написан для другого мира. Для пользовательской экономики, где один человек принимает одно решение, платит одну кредитку и даёт один фидбэк. В B2B-enterprise половина этих допущений отваливается на первой встрече. Дальше начинается марш разочарований.

Откуда взялся Lean и почему он именно такой

Блэнк, Рис, Cooper - всё это родилось в Кремниевой долине на волне B2C-стартапов и SaaS для малого бизнеса. Хрестоматийные кейсы - Dropbox, Airbnb, Zappos. У них общая структура: один решающий человек, короткий цикл принятия решения, низкая цена ошибки, быстрая обратная связь. Пользователь либо кликает, либо не кликает. Если не кликает - меняешь посадочную. Через две недели видно, работает или нет.

Эта механика хороша. Но она работает там, где есть три условия: один покупатель = одно решение; цикл до оплаты не превышает дни-недели; стоимость ошибки низкая (нажали не на ту кнопку - вернулись назад).

В B2B-enterprise все три условия нарушаются. Покупатель - это группа людей с разными функциями и интересами. Цикл от первого разговора до подписи часто растягивается на месяцы. А стоимость ошибки - не «вернуться назад», а подорванное доверие внутри buying committee, которое больше не восстанавливается. Поэтому Lean MVP в enterprise ломается не потому, что Lean плохой. Он просто попадает в среду, где риск распределён между многими людьми.

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

Где именно Lean ломается в B2B

Четыре конкретные точки слома, которые я вижу почти в каждом проекте, где компания пыталась натянуть Lean на enterprise.

1. MVP не проходит security review, а значит не попадает внутрь

Классический Lean MVP - это «ранняя сырая версия, где ещё нет полноценной безопасности, потому что сейчас не об этом». В банке, фарме, госкомпании, крупном ретейле эта версия просто не выходит из ворот. Сначала InfoSec смотрит архитектуру, потом юристы - персональные данные, потом комплаенс - соответствие отраслевым стандартам, потом закупки - контрактную рамку. На всё это уходит 3–6 месяцев. MVP, который должен был протестировать гипотезу за 3 недели, начинает жить по часам enterprise-процессов.

В моей практике BrandMaker это была одна из самых дорогих иллюзий. Мы думали: «покажем банку рабочий прототип с одним ключевым функционалом, и дальше поедем итерациями». Показали. Дальше начался security review на 4 месяца. Итерации умерли, не родившись.

2. «Пользовательская боль» в B2B - это не одна боль, а четыре противоречащие

Lean говорит: находи пользовательскую боль, тестируй решение на ней. В enterprise «пользовательская боль» выглядит так. End-user (реальный пользователь) хочет простоту и скорость. Его руководитель хочет видимость и отчётность. IT хочет безопасность, интеграцию и минимум новых точек отказа. Закупки хотят предсказуемую цену и стандартный контракт. CFO хочет измеримый ROI через 6 месяцев.

Если вы оптимизируете MVP под end-user (как учит Lean), вы проиграете IT. Если оптимизируете под IT - end-user не будет пользоваться. Если под закупки - продукт станет таким же унылым, как конкуренты. «Пользовательская боль» как единый объект исследования в enterprise не существует. Существует конфликтная четырёхмерная матрица, которую надо разруливать, а не «валидировать».

3. Feedback loop медленный до бесполезного

Lean работает на коротком feedback loop: запустил, померил, сделал вывод, изменил. В enterprise этот цикл растягивается так, что к моменту обратной связи уже не помнишь, какую гипотезу проверял. Продукт показали в марте. Пилот согласовали в июне. Запустили в сентябре. Первые реальные данные - в декабре. За это время в компании клиента поменялся CIO, бюджет пересобрали, приоритеты сдвинулись. Ваш сигнал «работает - не работает» приходит в совершенно другом контексте.

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

4. Компромиссный MVP в enterprise выглядит как «вы нам продали недоделанное»

Ещё одна вещь, про которую Lean-евангелисты забывают. В B2C пользователь простит сырой продукт, если за ним стоит понятная история («ранний beta, скидка 50%, помогите нам сделать лучше»). В enterprise это не прощается. Если вы пришли к банку с MVP, в котором не хватает половины функционала, - вам не скажут «ок, дорабатывайте, мы подождём». Вам скажут «спасибо, вернёмся через год, когда у вас будет зрелый продукт». В этой среде «зрелый» означает: полнофункциональный, с сертификатами, с понятной контрактной рамкой, с референсами.

Ещё одна вещь, про которую Lean-евангелисты забывают. В enterprise недоделанное демо часто читается не как «мы быстро учимся», а как «они не понимают цену ошибки». Даже если продукт потом дозреет, первое впечатление может закрыть дверь надолго.

Три правила адаптации Lean под B2B (или отказ от него)

После десятка проектов, где Lean не работал, у меня сложилось три правила. Не «как сделать Lean лучше», а как перестать его ломать.

Правило 1. Не MVP, а Production-Grade Pilot

В enterprise не запускается «минимально жизнеспособный продукт» - запускается пилот, который сразу проходит security, комплаенс и закупки. Да, это дороже. Да, это дольше. Но это единственный способ получить доступ к реальной обратной связи. Production-Grade Pilot значит: архитектура как на бою, безопасность как на бою, SLA как на бою, но ограниченный скоуп (одна функция, одно подразделение, одна страна).

В BrandMaker мы поняли это в 2015. Перестали говорить «MVP» и начали говорить «одно пилотное внедрение в одном маркетинговом подразделении, на боевых данных, с подписью юристов». Цикл до валидации сократился с 14 месяцев до 5. И - впервые - результаты были сравнимы с реальным использованием.

Правило 2. Feedback loop выносится за пределы клиента

Если у вас один enterprise-клиент и цикл валидации 11 месяцев, у вас нет никакого feedback loop. У вас есть молитва и презентации. Лечится это только через расширенный контур. Вы параллельно работаете с 4–6 потенциальными клиентами на стадии pre-sales (разговор, демо, обсуждение сценариев), и именно из этого потока получаете гипотезы о продукте, позиционировании, ценообразовании и приоритетах. Закрытие сделки - это не источник обратной связи, это её подтверждение.

Я писал про это отдельно в «Почему B2B-воронка не работает как в учебнике». Основной вывод: в enterprise воронка - это не truba, а набор параллельных разведок. И гипотезы проверяются именно на разведке, а не на сделке.

Правило 3. Pivot - это не итерация, это пересборка позиционирования

Lean учит пивотировать продукт. В enterprise пивотируют не продукт, а кому и как его продают. Функционал меняется медленно, а вот ценностное предложение для CFO vs. для IT-директора vs. для end-user - можно переписать за неделю. Если ваш продукт не продаётся, первая гипотеза: не «надо добавить фичу», а «мы говорим не с тем человеком на буду не так». И только если пять переформулировок не дали сдвига - тогда смотрим на продукт.

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

Альтернатива: Discovery-Driven вместо Lean

Если Lean в enterprise ломается, чем заменить? Есть хорошая альтернатива - Discovery-Driven Planning (Макграт и Макмиллан, HBR 1995, переиздано 2017). Главное отличие от Lean: не «быстро запустить и померить», а «явно сформулировать все неявные допущения и проверить их дешевле всего».

Условно, в Lean вы говорите: «давайте запустим MVP и посмотрим». В Discovery-Driven вы говорите: «у нас 14 допущений. Проверим их по порядку - от самого опасного к самому дешёвому. Половина проверяется через интервью, четверть - через прототип, оставшиеся - только на боевом пилоте». Экономия времени и денег - в разы, потому что вы не строите то, что можно было бы сломать логикой на бумаге.

На Pharmznanie мы так работали с новой B2B-моделью в 2023. Вместо «запустим MVP подписки для фарм-компаний» - провели 34 интервью с потенциальными клиентами, сломали три базовых допущения на разговорах (не на коде), и вышли к пилоту с уже сильно переформулированной гипотезой. Сэкономили примерно полгода разработки.

Когда Lean всё-таки работает в B2B

Хочу быть точным: Lean не «вредный». Он просто не универсальный. Есть B2B-ситуации, где он работает нормально.

Первая. Selfserve B2B SaaS с низким средним чеком (10-200 $/мес) и коротким циклом. Там покупатель часто один человек - small-business owner или product manager, - и цикл принятия решения схож с B2C. Lean работает.

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

Третья. Ранняя стадия стартапа, когда ещё нет ни одного enterprise-клиента, и вам надо просто понять, существует ли класс боли. Здесь Lean-discovery-интервью хороши. Но к моменту, когда вы пошли в первую крупную сделку, инструментарий нужно менять.

Границы применимости

Это не значит, что Lean - устаревший или плохой. Это значит, что у каждого инструмента есть своя область работы. Молоток хорош для гвоздя и плох для шурупа. В B2C и selfserve-B2B Lean остаётся сильной методологией. В enterprise-B2B, regulated industries (фарма, банки, госсектор) и в сделках с циклом 6+ месяцев он ломается и требует замены.

Ещё одно замечание. Команды, которые долго работали по Lean в B2C, переходя в B2B, первые полгода пытаются «починить Lean» и только потом принимают, что инструмент не тот. Лучше сразу экономить это время.

Вывод

Lean - инструмент пользовательской экономики, где один человек принимает одно решение и даёт один фидбэк. В enterprise-B2B его допущения ломаются на первой же встрече: пять участников buying committee, полугодовой цикл, security review, сырой демо как причина отказа.

Работающая адаптация выглядит так: Production-Grade Pilot вместо MVP, расширенный feedback loop из 4–6 разведок, пивот позиционирования вместо пивота продукта. В глубине - Discovery-Driven Planning как альтернативная рамка для больших гипотез.

Если ваш продукт или услуга живёт в enterprise-среде и вы чувствуете, что Lean у вас «не едет», - скорее всего не он сломался, а вы пытаетесь забивать шуруп молотком. Менять надо не усилия, а инструмент.