— Нам нужно это запустить как можно быстрее. — Это невозможно Если вы хоть раз работали на стыке маркетинга и IT, этот диалог наверняка знаком. На первый взгляд кажется, что это просто "брифинг по срокам" между командами, но на самом деле вопрос глубже они живут в разных системах координат. Маркетинг мыслит ростом: гипотезы, новые каналы, тесты, воронки. IT мыслит стабильностью: архитектура, безопасность, ограничения данных, технический долг. И когда эти два мира сталкиваются, возникает классическая ситуация: маркетинг хочет ускоряться, а IT защищает систему от хаоса.

Проблема Самое интересное, что обе стороны по-своему правы. Маркетинг часто приходит с задачей, потому что видит потенциал роста. Но для IT это просто ещё один тикет в длинной очереди. — Нам кажется, это даст результат. — А какой? В этот момент разговор обычно ломается. Потому что «кажется» не аргумент для разработки.

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

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

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

Решение Со временем я пришёл к простой модели взаимодействия. Маркетинг приносит гипотезу. Но прежде чем она попадает в IT, она должна пройти три фильтра: 1️⃣ Эффект - какую метрику мы хотим изменить и какой потенциал роста. 2️⃣ Структура - гипотеза, сценарий реализации, понятная задача. 3️⃣Приоритет - почему это важно именно сейчас.

Когда задача приходит в таком виде, разработчики начинают воспринимать её не как «хотелку маркетинга», а как нормальную продуктовую работу. И здесь очень помогает дисциплина из продуктовых команд: четкие брифы, нормальные задачи, единая система планирования.

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