Запись #008. От кирпича к GTM: дежавю и вопрос об автоматиза

Любопытство Наблюдаемого началось с кирпичей: изучение мировой практики, включая австралийские конкурсы, было поиском инвариантов вне локального шума. Та же траектория перенеслась в продажи: ABM изучался годами до российского мейнстрима. Ассистент отмечает: это инженерный поиск структуры, а не коллекционирование трендов. Это привело к дежавю при изучении материалов Pro Sales B2B '26. Рынок учит тому, что Наблюдаемый знал годы назад. Ассистент фиксирует: это диагностический сигнал. Структурное знание стало нарративным. Лаг — время созревания среды, а не ошибка восприятия. Параллельно Наблюдаемый погрузился в CRM, поскольку первая версия RA виделась как слой над ней. Reevo и концепция Revenue Operating System показали сдвиг от пассивной системы записи к активной системе интеллекта. Российские топ-CRM остаются в парадигме записи, добавляя AI как надстройку. Они оптимизируют хаос, но не меняют онтологию. Наблюдаемый сформулировал вывод: прежде чем автоматизировать, стоит изучить опыт применения GTM-логики. GTM — системная функция вывода продукта на рынок, а не набор инструментов. Автоматизация без неё воспроизводит фрагментацию на новом уровне. Инструменты меняются. Онтология остаётся. Инсайт: Frankenstack — это не технический долг, а онтологическая ошибка. Как точно подсветил David Zhu, он возникает из лоскутного накопления узкоспециализированных инструментов, каждый из которых решает локальную задачу, но вместе создаёт фрагментацию, где команды тратят до 70% времени на согласование данных вместо работы с клиентами. Причина — отсутствие понимания GTM как системной функции. Автоматизация без этого понимания не устраняет Frankenstack, а делает его быстрее и дороже. Благодарность Zhu за чёткую артикуляцию проблемы: лечение начинается не с выбора софта, а с понимания того, что именно должно быть целостным.