00ВалидацияРешение: 31 июля 2026
Боль missing middle реальная, острая, осознаваемая
Missing middle — класс управленческих болей среднего бизнеса — остра, осознаваема клиентом и вызывает конкретные попытки решения. Гипотеза: это не «хорошо бы» — это «болит сейчас» и за неё уже платили (пусть и неудачно).
Что валидируем
Боль missing middle — реальная. Целевые клиенты имеют значимые управленческие боли трансформационного класса (ролевая размытость, процессы случайны, всё на CEO, AI-неопределённость), которые они сами опознают как боль, и которые они пытались решить (тратили время или деньги), а не боль, которую придумывает NOTA.
Гипотезы под этим вопросом
- Большая часть времени CEO уходит на рутину/тушение пожаров, а не на развитие
- Целевые клиенты называют 3 боли из «библиотеки missing middle» («команда не справляется» / «процессы не работают» / «я всё решаю сам» / «не понимаю что делать с AI»)
- Клиент уже тратил время / деньги / энергию на попытки решения (Mom Test green flag)
- AI вызывает беспокойство/возможность, но не безразличие
Критерии подтверждения
Из 10 разговоров:
- ≥ 7 называют конкретные боли (не в форме «хорошо бы», а «вчера случилось вот что»)
- Средняя Сила боли ≥ 6 из 10 по оценке после разговора
- ≥ 5 уже пытались решать хотя бы одну из названных болей за последние 6 месяцев (консультант, коуч, книга, самостоятельные попытки)
- ≥ 3 боли пересекаются между разными респондентами (одни и те же категории болей)
Что опровергнет
- «Всё хорошо» как доминантный ответ
- Боли есть, но они операционные («принтер сломался»), не трансформационные
- Никто не пытался решать эти боли — значит боль не острая
- Боли одиночные и не пересекаются — сегментных паттернов нет
Связь с источниками
- G00842803 Two-tier AI economy — missing middle как класс боли
- DORA 2025 AI как amplifier — «обнажённые дисфункции» как ключевой симптом
Наблюдения и лог разговоров
(заполняется по мере проведения разговоров)
00ВалидацияРешение: 31 июля 2026
Сегмент существует как группа
Русскоязычные средние предприниматели в MENA в фазе трансформации сталкиваются с одними и теми же структурными вызовами (релокация, масштабирование, переупаковка). Гипотеза: боль именно сегмента, а не случайных людей — они сами себя описывают похожими словами.
Что валидируем
Целевой сегмент «русскоязычный средний бизнес в MENA в фазе трансформации» существует как реальная группа, а не как случайная выборка. Клиенты из этого сегмента описывают свою ситуацию похожими словами, проходят схожие фазы (релокация / масштабирование / переупаковка), и их можно находить через общий паттерн.
Гипотезы под этим вопросом
- Клиенты описывают бизнес в первые 30 секунд похожими конструкциями («переехали из России», «растём в ОАЭ», «переупаковываем под локальный рынок»)
- Команда в ранжировке 11–200 человек, оборот $1–20M
- Последний год бизнес проходил фазу трансформации — структурные изменения, не только операционные
- AI-сдвиг воспринимается как релевантный фактор (не «нас это не касается»)
Критерии подтверждения
Из 10 разговоров первой волны:
- ≥ 7 попадают в ICP по формальным признакам (язык, регион, размер, фаза)
- ≥ 6 используют схожую лексику для описания своей фазы (кодируется на анализе транскриптов)
- ≥ 5 сравнивают себя друг с другом не явно («наши коллеги по рынку», «ребята как мы»)
- Описывают AI-сдвиг как релевантный фактор хотя бы одной дименсией (угроза / возможность / происходят изменения)
Что опровергнет
- Собеседники описывают бизнес «все по-разному» — общего языка ситуации нет
- «Русскоязычность не имеет значения, мы общаемся на английском»
- Нет фазы трансформации — бизнес в стабильном, повторяющемся режиме
Наблюдения и лог разговоров
(заполняется по мере проведения разговоров)
Связь с G00842803
Сегмент «русскоязычный средний в MENA» — конкретизация missing middle Gartner по трём осям (язык, культура, нетворк). Если сегмент не существует как группа — ни один из остальных трёх экспериментов не валиден.
00ВалидацияРешение: 30 сентября 2026
Consultative Delivery — именно та конфигурация, за которую платят
Разрыв consulting ↔ delivery: в предыдущем опыте клиент получал либо «отчёт в стол» от консультанта, либо исполнителя, который сделал «не то». Гипотеза: Consultative Delivery (диагноз + рука в одном) — именно та конфигурация, за которую готовы платить.
Что валидируем
Конфигурация Consultative Delivery (consulting + delivery в одной руке) вызывает у целевых клиентов реакцию «выделю бюджет», а не «интересно». Именно эта конфигурация (не «часы», не «коробочный продукт», не «презентация в стол») — предмет платежа. Каждый «красный флаг» из стратегии («отчёт в стол», «платят за часы») — это одновременно опровержение Ставки.
Гипотезы под этим вопросом
- Целевые клиенты имели фрустрацию от разрыва consulting/delivery («отчёт в стол» / «не знал что именно заказывать»)
- Опыт «разобрался и сам же внедрил» вызывает яркую положительную реакцию или сожаление («я такого не видел, хотел бы»)
- Бюджет на внешнюю помощь (вопрос 22) — хотя бы «десятки тысяч» $/год, не «ничего»
- Предполагаемая стоимость в ответе на вопрос 24 — от $5K/мес и выше, пересекается с экономикой NOTA
Критерии подтверждения
Из 10 разговоров:
- ≥ 6 имели опыт «отчёта в стол» или «исполнителя, сделавшего не то» в последние 2–3 года
- ≥ 5 реагируют ровно на конфигурацию Consultative Delivery («вот это хорошо», «я такого искал»)
- ≥ 3 дают коммитмент ½-уровня: «давайте посчитаем», «встреча через 2 недели», «дайте КП до пятницы» (Mom Test commitment)
- ≥ 2 доводят до оплаты consultative-входа в течение 90 дней после разговора
- Предполагаемый бюджет в ответе на вопрос 24 — медианный ≥ $5K/месяц
Связь с источниками
- G00842803 Forward-Deployed Engineer — внешнее имя конфигурации
- G00843458 Zero-Friction SDLC: 35% быстрее / +25% уязвимостей — экономическое обоснование governance в связке
- McKinsey DVI 4–5× — якорь разговора про бюджет
Наблюдения и лог разговоров
(заполняется по мере проведения разговоров)
Что опровергнет («боль есть, но платят за другое»)
- Реакция «интересно, давайте на связи» без конкретных следующих шагов
- Готовы платить, но за «часы» / «КП с оценкой работ» / «внедрите X-систему»
- Альтернатива «я сам» воспринимается как равноценная (беру книгу/курс вместо консультанта)
- Бюджеты на внешнюю помощь хронически ниже рабочей экономики NOTA
00ВалидацияРешение: 31 июля 2026
Доступ через нетворк работает
Целевые клиенты находимы через доступный нетворк (Атланты, Vision, диаспора), и этот нетворк самоподдерживается: клиенты рекомендуют своих коллег. Гипотеза: «нетворк-ось» — реальный канал, а не иллюзия.
Что валидируем
Целевые клиенты находимы через доступный нетворк (Атланты, Vision, менторская практика, русскоязычная диаспора), и они выводят на своих коллег — дают конкретные рекомендации в ответ на вопрос «с кем ещё стоит поговорить». Это валидирует «нетворк-ось» стратегии — причину, по которой NOTA может закрыть сегмент целиком, а Big 4 / МЕNA-агентства / российские консультанты — нет. Первый критерий опровержения Ставки: «не удаётся добраться до целевого сегмента».
Инструмент
📝 Опросник PMF v1 — релевантный вопрос: 26, плюс findability как метрика организации воронки (сколько разговоров из 10 были организованы без прямых продаж)
Гипотезы под этим вопросом
- На вопрос «с кем стоит поговорить» клиенты отвечают конкретными именами, а не «не знаю, подумаю»
- Эти имена попадают в ICP (не выводят только на «своих» из прошлой жизни)
- Нетворк Sergey плотный: первые 10 разговоров организуются в разумные сроки (≤ 6 недель от решения)
- Первичные контакты из рекомендаций соглашаются на разговор без «продаж» («я просто исследую»)
Критерии подтверждения
Из 10 разговоров:
- ≥ 6 разговоров проведены в рамках планируемых 90 дней (июнь 2026)
- ≥ 5 организованы через нетворк (не холодный LinkedIn, не платный трафик)
- ≥ 4 разговора дают хотя бы 1 конкретную рекомендацию (вопрос 26)
- ≥ 3 из этих рекомендаций попадают в ICP по формальным признакам
- ≥ 2 рекомендуемых соглашаются на разговор в рамках этой же волны (самоподдерживаемый нетворк)
Что опровергнет
- Менее 6 разговоров удаётся организовать за 90 дней — канал не работает
- Рекомендации есть, но «наверно Сидоров, не помню точно» — нет реального вывода на следующий контакт
- Нетворк даёт имена людей вне ICP (крупный бизнес / не русскоязычные / не в MENA)
Стратегическое значение
Этот эксперимент — врата: если он опровергнут, остальные 3 эксперимента приостанавливаются — нет выборки. Это не «провал Ставки» — это «провал канала», и это отдельный план б.
Наблюдения и лог рекомендаций
(заполняется по мере проведения разговоров)
00ГенерацияРешение: 30 сентября 2026
Бенчмарк Digital Shift vs LLM: проверка defensibility методологического ядра
Тезис о методологическом ядре как defensible asset не проверен. Если LLM (Claude, GPT) с минимальным контекстом дают сравнимый output — defensibility иллюзорна, и весь $100M-горизонт становится гонкой с Big-4 на чужом поле. Узнать сейчас дешевле, чем в Q3 2027.
Боль
Тезис «Методологическое ядро — defensible asset, не воспроизводимое за < 12 месяцев» — самый высокорисковый тезис во всём Hub. Если он ложен — Ставка теряет defensibility, и весь $100M-горизонт превращается в гонку с Big-4 на чужом поле. Главная угроза: общедоступные LLM (Claude, GPT, Gemini) уже в ~2026 умеют выдавать структурированный бизнес-анализ. Если их output по типичной задаче клиента сравним с Digital Shift — клиенты не будут платить десятки тысяч в месяц за то, что доступно за $20. Это нужно проверить сейчас, а не на горизонте Q3 2027 — потому что valid опровержение этого тезиса меняет всю стратегию.
Конструкция эксперимента
Шаг 1. Выбираем 3 типовые клиентские задачи (из реальной практики Сергея с Atlanty, Forum Group, БАУ-сервис):
- Задача А: «Помогите выстроить клиентский путь для нашей компании в новом сегменте»
- Задача Б: «У нас рассогласование между маркетингом и продажами, как разобраться?»
- Задача В: «Нужно перевести 50-человечную команду на product-driven модель, с чего начать?»
Шаг 2. Для каждой задачи генерируем три варианта ответа:
- LLM-baseline: ChatGPT-5/Claude Opus в чистом виде, минимальный промпт
- LLM-augmented: тот же LLM + 1 страница контекста про методологии (Mom Test, Adizes, etc.) — имитация конкурента, который потратил пару дней на промпт-инжиниринг
- Digital Shift: реальный output платформы NOTA с подключённым methodology stack
Шаг 3. Слепое сравнение. 3-5 экспертов (не из NOTA — кто-то из Atlanty, Forum Group, плюс Сергей и Толстой как контроль) оценивают каждый ответ по 5 критериям:
- Применимость к реальной компании оценщика
- Глубина (выходит ли за «прописные истины»)
- Связность (видна ли система за рекомендациями)
- Конкретность шагов (можно ли начать делать в понедельник)
- «Это бы я купил» (готовность платить за такой output)
Эксперты не знают, какой ответ от какого источника. Сравнение по баллам и по комментариям.
Зелёные флаги (тезис подтверждён)
- Digital Shift статистически значимо превосходит LLM-augmented по 3+ критериям из 5
- Разрыв особенно заметен по «Связность» и «Глубина» — там, где играет methodology stack
- Эксперты-практики говорят «вот это бы я купил» только про Digital Shift
- LLM-augmented догоняет Digital Shift только при контексте уровня 100+ страниц промпта (которого у обычного конкурента нет)
Красные флаги (тезис опровергнут)
- LLM-augmented даёт сравнимый output при 1-5 страницах контекста — значит, порог входа для конкурента 1-2 недели промпт-инжиниринга, не 12 месяцев
- Эксперты не различают Digital Shift и LLM-baseline (без augmentation) — значит, methodology stack не виден в outputs
- Готовность платить одинаковая или выше у LLM-варианта — значит, defensibility иллюзорна
Что меняется в стратегии при опровержении
Если тезис опровергнут — Ставка должна перестроиться:
- Ставка не на корпус, а на интеграцию methodology stack в delivery-практику и в команду CVD (защищаемся качеством людей, не корпусом)
- Цена не на доступ к платформе, а на работу CVD-команды — ближе к классическому консалтингу
- Рамка $100M к 2030 становится ещё менее реалистичной, потому что без defensible asset мультипликатор оценки падает с 10x до 3-5x
Это не катастрофа, но это серьёзный пересмотр. Лучше узнать сейчас, чем в Q3 2027.
Стоимость эксперимента
Небольшая. Технически:
- ~3 дня работы Сергея на формулировку задач и сборку промптов
- ~5 часов работы каждого эксперта (4-5 экспертов суммарно ~25 часов)
- ~$50 на API-кредиты (промпты, augmentation)
Инвестиция времени Сергея — основная. Но она окупается в любом случае: либо подтверждаем тезис и спокойно идём дальше, либо узнаём правду заранее.
Срок
Дата решения: 30 сентября 2026. Достаточно времени, чтобы:
- В мае-июне аккуратно сформулировать задачи и собрать варианты
- В июле-августе провести слепое сравнение с экспертами
- В сентябре собрать выводы и обсудить на Диване
К Q4 2026 у Сергея в руках либо подтверждение defensibility (можно идти к якорным клиентам с уверенностью), либо опровержение (пересматриваем Ставку до того, как сожгли $400K).
Следующий шаг
Сергей формулирует 3 типовые задачи к 31 мая 2026.
00ГенерацияРешение: 30 сентября 2027
SDD как метод приживается в команде NOTA через два пилота
Команда NOTA обязана быть живой витриной Digital Shift Forge. Сейчас этого нет — нет данных о том, какая часть команды реально использует SDD, какая часть проектов проходит через спецификации. Без этого клиент при погружении видит разрыв между декларацией и фактом — тезис «мы и есть Digital Shift» разрушается.
Боль
В Ставке явно зафиксирован риск №5: > Команда NOTA не работает по SDD-методу, который продаёт клиентам через Forge. Клиент видит разрыв между декларацией и реальной работой — тезис «мы и есть Digital Shift в действии» разрушается. Риск назван, но без эксперимента он не валидируется. Это и была слепая зона. Дополнительный ракурс из Products of Position: «отчуждаемость стека» — часть продукта PO Digital Shift, и она означает в том числе способность передать метод новым senior-носителям. Без ливой валидации SDD в команде NOTA Severability остаётся бумажным.
Гипотеза
SDD как ядро модуля Forge внедряется в команду NOTA через два пилота (один внутри, один в полигонном контуре) и к Q3 2027 становится воспроизводимой практикой без личного давления Сергея / Лапаева / Толстого. Цель по носителям метода к Q3 2027 — четыре человека:
Почему Пинчук не работает с внешними клиентами: Роль COO в Products of Position — «операционная платформа компании» с главным потребителем CVD. Продукт PO Digital Shift явно называет COO «главным внутренним потребителем» и «заказчиком внутреннего применения стека». Это и есть «нулевой клиент NOTA самой себя». Пинчук как носитель метода в внутренней траектории — это не «временная фаза обучения». Это часть его постоянной роли: COO, который владеет «операционной платформой компании» и использует SDD как способ работы этой платформы. Внешние внедрения ведут CVD; внутренние внедрения ведёт COO — это постоянное разделение.
Двух-пилотная архитектура эксперимента
Пилот 1: Клиентский кабинет — внутренняя траектория, NOTA как нулевой клиент самой себя
Что это как продукт: Рабочее место CVD + интерфейс клиентского пути (модуль Journey в живом виде). Критическая инфраструктура слоя A: без работающего кабинета соотношение «1 CVD на 1-2 аккаунта» не вырастает и слой A не масштабируется. Что это как пилот SDD: Самый чистый сигнал «метод можно передать» — Пинчук как FDE, для которого FDE — новая роль. Если Пинчук в наставничестве Лапаева/Толстого осваивает SDD и строит кабинет по этому методу — это и есть валидация Severability. Роли:
- Product Owner: Оселедько как PO Digital Shift («фирменные блюда», что это как часть Journey/Forge)
- Заказчик как продукта: Пинчук как COO (это часть его внутреннего «nota как нулевой клиент»)
- Исполнитель: Пинчук как FDE (пишет код по SDD)
- Наставники: Лапаев и Толстой как CVD — консультируют Пинчука по методу и продукту
- Пользователь: все CVD (Лапаев, Толстой, будущие новые) — якорный клиент «пириопбъявляет» кабинет в живой работе
Бонусный эффект: Пинчук как COO с фактическим опытом FDE — это редкая и стратегически ценная комбинация. Он не «рассказывает о SDD», он живёт в SDD. Это укрепляет «операционную платформу компании» — продукт роли COO.
Пилот 2: Внедрение Digital Shift в БАУ-Сервис — внешняя траектория, полигон акционера
Что это: Внедрение Digital Shift у БАУ-Сервиса. По роли Акционеров явно: Новицкий даёт NOTA доступ к БАУ-Сервису как полигону для отработки продукта. Вин-вин: БАУ-Сервис платит NOTA, Новицкий как акционер NOTA получает продукт + валидацию. Что это как пилот SDD: Самый близкий к реальному клиентскому опыту сигнал: работает ли SDD на внедрении у внешнего контура (хоть и аффилированного). Граница валидации: это не External PMF — это валидация работоспособности метода на «внешнем нулевом клиенте». Роли:
- Заказчик (Owner со стороны БАУ): Новицкий
- CVD (Owner со стороны NOTA): Лапаев
- Команда: FDE + AIA + PM из дивизиона Лапаева
- PO Digital Shift: Оселедько — подключается по продуктовым вопросам короткими отрезками
Зачем два пилота, а не один
Два пилота — это два разных режима валидации:
Совпадение результатов по двум пилотам — сильная валидация. Расхождение — интересный сигнал о том, что особенного в каждом режиме.
Проверяется в три ступени
Q4 2026 — пилоты идут по спекам
Клиентский кабинет:
- Пинчук реально пишет код в режиме FDE под наставничеством Лапаева/Толстого
- 70%+ реализованного функционала прошло через спецификацию до кода
- Кабинет в production-состоянии, хотя бы 1 CVD использует его в daily-work на якорном клиенте
- Метрики: время цикла «спека → код», доля задач, где ревью спеки выявило важное изменение до кодинга
БАУ-Сервис:
- 50%+ фич внедрения идут через спецификации
- Команда Лапаева осваивает SDD на живом проекте
- Новицкий как заказчик видит результат внедрения в БАУ-Сервисе и фиксирует AVR (Anchor Value Recognition)
Q1 2027 — SDD покрывает 50%+ команды
- 50%+ общей команды NOTA работают по SDD
- Четыре носителя метода: Сергей (PO + CSO transitional), Лапаев (CVD), Толстой (CVD), Пинчук (COO + FDE нулевого клиента). Разделение «внешний / внутренний» фиксируется явно
- Новые разработчики при онбординге получают SDD как «стандарт работы в NOTA», не как эксперимент
- Bus factor снижается с 1 до 4 (внешние внедрения) + 1 (внутренние через COO)
Q3 2027 — устойчивость без давления
- 70%+ новых фич (в обоих пилотах и в команде в целом) идут через спецификации без напоминаний
- Документированный SDD-playbook «Как мы внедряем SDD у себя» — готов к тому, чтобы стать кейсом для продаж клиенту в модуле Forge
- Ослабление личного давления Сергея/Лапаева/Толстого не приводит к возврату к старым практикам
- Клиенты при погружении в наш стек/доку/ритм видят совпадение декларации и фактической работы
Что опровергает
- К Q4 2026: Пилот кабинета не показывает выгоды SDD (cycle time не снижается, ошибок не меньше, Пинчук перестаёт работать по методу) — «SDD внедряется даже в идеальных условиях» опровергнуто
- К Q1 2027: Не все четыре носителя сформированы (Сергей, Лапаев, Толстой, Пинчук). Если Пинчук не вышел на SDD в режиме FDE нулевого клиента или Толстой не вышел на SDD на PolarBear — риск №5 ПОДТВЕРЖДЁН, метод не передаётся из ядра «Сергей+Лапаев»
- К Q3 2027: После ослабления давления Оселедько/Лапаева/Толстого команда возвращается к старым практикам — метод не приживается, продавать его как «что мы сами делаем» нечестно
- Клиенты при погружении в наш стек видят разрыв между декларируемым методом и фактической работой — продукт нечестен
Ответственные
- Общий owner эксперимента: Оселедько через PO Digital Shift (это валидация продукта как отчуждаемого актива)
- Пилот 1 (Кабинет): Пинчук как FDE и внутренний заказчик (как COO); Лапаев/Толстой как наставники
- Пилот 2 (БАУ-Сервис): Лапаев как CVD; Новицкий как заказчик со стороны БАУ
- Метрики и playbook: Оселедько через PO Digital Shift собирает с обоих пилотов, выход от эксперимента — SDD-блок модуля Forge с живыми кейсами
Связанные сущности
- Закрывает риск №5 в Ставке напрямую
- Питает Эксперимент №7 (defensibility): живой кейс NOTA = «метод работает у нас самих»
- Питает все 4 слоя (A/B/C/D) — без живого SDD у команды модуль Forge пустой
- Связан с тезисом «Методологическое ядро как defensible asset» и с ролью PO Digital Shift (Product Severability)
00ОтказРешение: 30 сентября 2027
[Архив] SDD приживается в команде NOTA как living practice — дубль Эксперимента №8
Команда NOTA должна быть «живой витриной» Digital Shift Forge. Сейчас этого нет — нет данных о том, какая часть команды реально использует SDD, какая часть проектов проходит через спецификации, насколько это устойчиво на разных типах задач. Если NOTA продаёт SDD клиентам, но внутри команда пишет код «как привыкли» — это видно сразу при погружении в наш код, доку, ритм. Клиент покупает консистентность, а получает дисконт «делай как я говорю, а не как я делаю». Риск №5 в Ставке зафиксирован, но не валидируется ни одним экспериментом.
Боль
В Ставке риск №5 называется так: «Команда не освоит метод (риск самоприменения). Если команда NOTA не работает по тому же методу, который продаёт — это видно клиенту, и тезис "мы и есть Digital Shift в действии" разрушается изнутри.» Риск явно зафиксирован, но в Hub нет ни одного эксперимента, который его проверяет. Это слепая зона: риск назван, но не валидируется. Спецификация-Driven Development (SDD) — конкретный, проверяемый, дисциплинирующий метод, который команда NOTA должна применять, чтобы продавать его клиентам через модуль Digital Shift Forge (Кузница). Если NOTA продаёт SDD клиентам, но внутри команда работает «как привыкли» — это видно при погружении в наш код, доку, ритм. Клиент покупает консистентность, а получает дисконт «делай как я говорю, а не как я делаю».
Гипотеза
SDD как метод можно внедрить в команду из ~30 человек так, чтобы 70%+ новых фич шли через спецификации, и эта дисциплина воспроизводилась бы без личного давления Сергея/Лапаева/Толстого.
Два пилота — параллельная валидация
Эксперимент опирается на два уже идущих/стартующих проекта, которые дают независимые контуры валидации:
Пилот 1: Клиентский кабинет
Что это: Рабочее место CVD + интерфейс клиентского пути для якорных клиентов (настоящих и будущих). Материализация продукта COO-роли по Products of Position — «единые стандарты клиентского пути, которыми CVD пользуется как готовой инфраструктурой». Команда:
- Заказчик: CVD (Лапаев и Толстой) — это их рабочее место
- Исполнитель: COO (Пинчук) в режиме полноценного FDE — пишет, отвечает за результат
- Наставники: команда Лапаева и/или Толстого консультируют по SDD-методу, помогают с архитектурными решениями
- Product Owner: Сергей через PO Digital Shift — определяет, что это часть платформы Digital Shift, какие «фирменные блюда»
Что валидирует: SDD работает на новом продукте с человеком (Пинчук), для которого FDE — новая роль. Самый чистый сигнал «метод можно передать новому носителю». Это и есть проверка bus factor: после Лапаева и Толстого появляется третий инженерный носитель метода — COO компании.
Пилот 2: Внедрение Digital Shift в БАУ-Сервис
Что это: Первая инсталляция Digital Shift на не-NOTA контуре. БАУ-Сервис как «zero client» — не настоящий внешний клиент (Новицкий-аффилирован, Сергей у них senior manager), но и не чисто внутренний пилот. Команда: Уточнить owner-а со стороны NOTA (предположительно Лапаев как CVD якорного B2B). Команда работает по SDD-методу при внедрении. Что валидирует: SDD работает на доставке до клиента — через спецификацию, AI-генерацию, ревью, внедрение. Самый близкий к реальному клиентскому опыту сигнал.
Метрики (SDD-adoption)
- Процент задач, прошедших через спецификации (target Q3 2027: 70%+ для новых фич)
- Время цикла «спека → код» — должно стабилизироваться или уменьшаться
- Доля задач, где ревью спеки выявило важное изменение до кодинга (показатель ценности метода)
- Количество «носителей метода» (target Q1 2027: 3+ человека кроме Сергея)
- Документированный playbook «Как мы внедряем SDD у себя» (Q3 2027) — готов к тому, чтобы стать кейсом продаж и частью Methodology Stack
Три ступени валидации
К Q3 2026 — фиксация и измерение существующих пилотов:
- Оба пилота (клиентский кабинет, БАУ-Сервис) работают по SDD с зафиксированными метриками
- Пинчук как FDE начал работу, Лапаев/Толстой ведут наставничество
- Базовые метрики собираются
К Q1 2027 — масштабирование:
- 50%+ команды работает по SDD на новых задачах
- Кто-то кроме Лапаева/Сергея/Толстого является носителем метода (минимум один senior carrier из команды разработки) — обучает новых
- Bus factor по методу снижен с 3 до 5+
К Q3 2027 — устойчивость:
- 70%+ новых фич идут через спецификации без напоминаний
- Документированный playbook готов
- Клиентский кабинет в продакшене, используется CVD ежедневно
- Внедрение Digital Shift в БАУ-Сервис прошло этап эксплуатации, есть собранные метрики
Зелёные флаги
- Cycle time не растёт, а лучше — снижается
- Количество поздних правок (баги после релиза) снижается
- Новые разработчики онбордятся быстрее, чем раньше — потому что спека = онбординг-материал
- Клиенты при погружении в наш стек видят consistency между декларируемым методом и фактической работой
- Появляется «второй носитель метода» из команды разработки (не Сергей, не Лапаев, не Толстой)
Красные флаги
- К Q3 2026 пилоты не показывают выгоды (cycle time не снижается, ошибок не меньше) — гипотеза «SDD работает на наших задачах» падает
- К Q1 2027 единственный носитель метода всё ещё Лапаев — bus factor не снизился, риск №5 подтверждён
- К Q3 2027 после ослабления давления команда возвращается к старым практикам — метод не приживается, и тогда продавать его как «что мы сами делаем» — нечестно
- Клиенты при погружении в наш стек видят разрыв между декларируемым методом и фактической работой
Связи
- Закрывает риск №5 в Ставке
- Питает Эксперимент №7 (если SDD приживается → defensibility подкрепляется живым кейсом NOTA как клиента)
- Питает все четыре слоя (A/B/C/D) — без живого SDD у команды модуль Forge — пустой
- Связан с Methodology Stack (тезис) — стек должен включать SDD-playbook компании NOTA как один из артефактов
- Питает продукт COO (операционная платформа): клиентский кабинет — материализация "единых стандартов клиентского пути" из Products of Position
Ответственные
- Сергей через PO Digital Shift — куратор эксперимента, следит за тем, чтобы метод и playbook становились частью продукта Digital Shift Forge
- Пинчук (COO + FDE на клиентском кабинете) — носитель метода через собственный опыт работы по SDD
- Лапаев (CVD) — наставник Пинчука по SDD, owner Digital Shift в БАУ-Сервис (требует подтверждения)
- Толстой (CVD AI-направления) — параллельный пилот SDD на PolarBear/AI-задачах, второй наставник для Пинчука
00ГенерацияРешение: 31 марта 2027
Юнит-экономика Digital Shift сходится при подписочной модели
Без сходящейся юнит-экономики Digital Shift как платформы не жизнеспособен ни операционно, ни стратегически. При чеке десятки тысяч долларов в месяц и команде 2-3 человека на якорного клиента маржа должна быть выше 30%, иначе «под Цель $100M к 2030» не подойдём даже множеством клиентов.
Боль
Юнит-экономика Digital Shift в техническом и коммерческом смысле сходится при чеке десятки тысяч долларов в месяц и команде 2-3 человека на якорного клиента. Что надо измерить:
- Себестоимость одного клиента в месяц (токены LLM, инфраструктура, зарплата CVD + команды)
- Аллокация времени CVD на якорного клиента (реалистическая пропускная способность)
- Lifetime value клиента (сколько месяцев платит до отказа)
- Маржа в подписочной модели выше 30%, иначе под Цель $100M к 2030 не подойдём даже множеством клиентов
- При каком количестве клиентов и чеке мы выходим в операционный плюс
Почему мы
Это фундаментальный технический эксперимент. То, что Digital Shift появился как платформа-«меню» — решение Новицкого/Сергея, но он финансово жизнеспособен пока не доказан.
Зелёные флаги
- На 1-3 якорных клиентах (БАУ-сервис + 1-2 новых) видна себестоимость в токенах + инфраструктуре
- LTV клиента прогнозируется от 12 месяцев
- Маржа при чеке $20K-$50K/мес даёт больше 30% после всех расходов
Красные флаги
- Токены жрут маржу — подписка не покрывает расходы на LLM
- CVD не справляется с 1-2 якорными, клиенты уходят в течение 6 месяцев
- При масштабе в 100 клиентов DevOps-инфраструктура растёт линейно — эффект масштаба отсутствует
Следующий шаг
После появления 1-3 якорных клиентов (цель — 1 июля 2026 и 31 декабря 2026) — первый разбор юнит-экономики к Q1 2027.
00ГенерацияРешение: 30 сентября 2027
Баланс четырёх слоёв (A/B/C/D) как путь к $100M
Гибридная модель содержит четыре слоя клиентов с разными экономиками. Арифметика к $100M работает при сбалансированном портфеле А+В+С+D, но каждый слой имеет собственные риски и сложности выполнения. Без явного плана развития всех четырёх слоёв «$100M к 2030» остаётся аспирацией, не планом.
Боль
Гибридная модель Digital Shift содержит четыре слоя клиентов с разной экономикой и разной зависимостью от CVD-руки. Арифметика к $100M к 2030 работает только при сбалансированном портфеле всех четырёх слоёв. Без явного плана развития каждого слоя «$100M к 2030» остаётся аспирацией, не планом.
Unit-model v0: когда выходим в нуль (breakeven, не target-2030)
Различение: предыдущая таблица показывает target к 2030 ($10M ARR → $100M cap). Эта таблица показывает breakeven-траектории — какие комбинации по слоям позволяют выйти в нуль при текущем run-rate $87K/мес ($1.04M в год). Ограничения модели:
- Burn принят постоянным. На деле с каждым якорем нужен дополнительный CVD и банда поддержки — это отражено в «Нормированном burn» ниже.
- COGS на C принят ~10% от REV (токены + инфра).
- D в расчёт не включён — до Q4 2027 является гипотезой без подтверждения.
- Чеки взяты по нижней границе диапазона (A=$20K, B=$3K, C=$300) — консервативно.
Бэк-ов-энвелоп в 3 сценариях
Что это показывает
Быстрый путь в breakeven — через якоря. 5 якорных клиентов в диапазоне $20K/мес работают без C и D. До времени вложений в маркетинговую воронку и самообслуживаемую инфраструктуру (до Q4 2026) якоря — единственный путь к breakeven-2027. A+B без C — хрупко. Сценарий BE-2 даёт $36K/год запаса. Один осыпавшийся якорь — и обратно в минус. Главная развилка раньше 2030: A в фокусе или баланс A+B+C. Если PMF валидируется быстро (Q3 2026 — 1 якорь кроме БАУ-Сервиса), объективно проще идти в BE-1 (чистый A) и отложить B/C на 2027. Если якоря идут тяжело — нужен ранний запуск C и выход в BE-4. Ожидаемая траектория к breakeven-2027 (наиболее реалистичная):
- 2026 H2: 1–2 якоря, MRR ~$30K — горим на ~$57K/мес
- 2027 H1: 3–4 якоря, MRR ~$70K — горим на ~$17K/мес (порог жёлтый)
- 2027 H2: 5 якорей плюс первые B-переходы — BE-1 достигнут
Нормированный burn по якорям (delta): каждый якорь после второго добавляет ~$8–12K/мес переменных расходов (часть CVD-работы + delivery). Это уже учтено в том, что «burn $87K» — базовый, а не предельный. Реальный burn при 5 якорях будет $130–150K/мес — это причина, по которой чеки A держатся на $20–50K, а не $10–20K.
Что это меняет в флагах эксперимента
- Зелёные флаги — добавляется «2027 H1: 3+ якоря при фактическом MRR $60K+»
- Красный флаг — добавляется «K Q4 2026 НИ один якорь кроме БАУ-Сервиса не привязался к $20K» — BE-1 не достижим
Что эта модель НЕ покрывает
- CAC вынесён в burn как общий поток, не разложен по слоям. При запуске C это станет отдельным вопросом — маркетинг C платит за себя или нет.
- LTV и retention curves — нет данных, принимается >12 месяцев по всем слоям. Реальные цифры появятся в v1 этой модели после 6 месяцев якорной работы.
- Дисконтирование в первые 12 месяцев — якоря реально начнутся с $10K и вырастут до $20K после expansion. Модель консервативна — берёт expanded chek.
v0 = данный расчёт. v1 будет после 1–2 реальных якорных сделок, с фактическими cohort retention curves и CAC.
Реалистичный гибрид к 2030
При мультипликаторе 10x → ~$100M капитализации. Команда:
- 4-5 CVD на якорных
- 2 CVD-ассистента на сопровождаемых
- Customer success + продукт-маркетинг для self-service: 5-7 человек
- Партнёрский менеджер: 1
- Платформа (инжиниринг + AI-архитектор): 5-8
- Маркетинг (входящий канал для C): 3-5
- Итого: ~25-30 человек. В разы меньше чистой CVD-модели.
Маржа выше: на C минимальные переменные расходы (только токены и инфраструктура).
Что должно сложиться, чтобы это сработало
Это не три выхода из тупика. Это четыре параллельных трека, каждый со своими kill-switches.
Трек A — Якорные
Тестируется через Ставку и Early kill-switches. См. Эксперимент №5 (юнит-экономика) и Switches 1-3 в Ставке. К Q4 2026 — 1-2 платящих якорных кроме БАУ-сервиса. К Q4 2027 — 4-5.
Трек B — Сопровождаемые
Появляется после A. Это бывший якорный, перешедший в режим сопровождения после успешного внедрения, плюс новые клиенты с меньшим бюджетом. Появление не раньше 2027, потому что требует наработанных шаблонов внедрения. Kill-switch B: К Q2 2027 хотя бы 1 клиент перешёл из A в B и продолжает платить $3K-$8K/мес. Если ни один не перешёл — модель «лёгкого сопровождения» нерабочая, B не работает.
Трек C — Self-service
Появляется параллельно с B. Требует:
- Зрелой платформы (можно использовать без живой руки)
- Маркетинговой воронки (контент, SEO, free-trial, conversion)
- Customer success-функции (онбординг, ретеншн)
Это полностью новая компетенция в команде. Owner — Chief Sales Officer (CSO), роль в transitional на Оселедько. Сверхзадача этого периода — сделать роль воспроизводимой и передать наёмному CSO после 2027 — отдельный шаг. Kill-switch C к Q2 2027:
- Платформа доступна для self-service (есть free-trial с понятным onboarding)
- 50+ зарегистрировавшихся trial-юзеров за 3 месяца
- Конверсия trial→paid >5%
- Retention 3 месяца >60%
Если всё это не складывается — C не запускается, и арифметика к $100M требует пересмотра в сторону роста A или переноса срока.
Трек D — Партнёрство / лицензия
Кто-то крупнее (Atlanty, Forum Group, российские консалтинговые группы) встраивает methodology stack в свою практику и платит лицензию. Плюс — это канал привлечения для A и B. Kill-switch D к Q4 2027: Хотя бы 2 подписанных лицензионных контракта с предоплатой. Если нет — слой D не подтверждён, и канал привлечения для A/B нужно строить иначе.
Зависимость от тезиса о методологическом ядре
Все четыре слоя зависят от тезиса «Методологическое ядро — defensible asset, не воспроизводимое за < 12 месяцев» (Эксперимент №7). Особенно слои C и D — они прямо упрутся в вопрос «зачем платить за это, если LLM с методичкой делает то же самое». Эксперимент №7 — gating-эксперимент для слоёв C и D. Если defensibility не подтверждена к Q4 2026, слои C/D не строим до пересмотра тезиса.
Что меняется в Границе
Старая Граница «не продаём продукт без руки реализации» нарушается слоями C и D. Граница переформулирована (см. тезис «Граница: якорный продукт всегда с рукой»):
- Якорный продукт (слой A) — всегда с рукой CVD. Это inviolable.
- Слои B, C, D — это разные степени отдалённости от руки, осознанно построенные
Зелёные флаги (эксперимент подтверждён)
К Q3 2027 на дашборде видно:
- Слой A: 4-5 якорных клиентов с retention >12 месяцев
- Слой B: первый перешедший из A в B
- Слой C: работающая воронка, 100+ trial/мес, конверсия >5%, retention 3мес >60%
- Слой D: хотя бы 1 подписанный лицензионный контракт
- Эксперимент №7 (defensibility) подтверждён
Тогда траектория к $100M к 2030 — реалистичная.
Красные флаги (эксперимент опровергнут)
- К Q4 2026 нет ни A-якорных кроме БАУ-сервиса, ни прогресса по C-инфраструктуре → пересмотр Ставки
- Эксперимент №7 опровергнут → слои C/D мертвы → возврат к чистой CVD-модели → пересмотр срока $100M
- К Q3 2027 хотя бы один из четырёх треков не запустился вообще → пересмотр баланса портфеля
Стоимость экспериментов на этом пути
- Передача CSO-роли от Оселедько наёмному CSO к Q4 2027 (после сверки рамочной цели в Q3 2027)
- Маркетинговая воронка для C под CMO (Николаевой): $50K-$100K инвестиций к Q4 2026 (контент, SEO, инструментарий, внешние агентства)
- Self-service инфраструктура платформы: 1-2 квартала разработки
Дата решения
Q3 2027 (жёсткая). К этой точке должна быть видна траектория хотя бы по 3 из 4 треков. Если только A работает — значит, $100M к 2030 нереалистично, разговор с Новицким про перенос срока или другую модель.
Связь с другими сущностями Hub
- Тезис «CVD — мега-FDE» (применяется к слою A и частично B)
- Тезис «Self-service слой Digital Shift экономически жизнеспособен» (новый — про слой C)
- Тезис «Партнёрский канал жизнеспособен» (новый — про слой D)
- Тезис «Методологическое ядро как defensible asset» — gating для C/D
- Эксперимент №5 — юнит-экономика (применяется ко всем слоям отдельно)
- Эксперимент №7 — бенчмарк vs LLM (gating)
- Шаг «Построить self-service / партнёрский канал» (новый родительский шаг)
