В IT-командах есть один устойчивый миф: если продукт хороший, он сам себя продаст.
Ну хорошо, не совсем сам. Ему помогут Product Manager, разработчики, пара постов в Telegram, лендинг, где написано «инновационное решение для оптимизации бизнес-процессов», и релиз-ноутс на языке, который без подготовки читают только автор задачи, техлид и человек, который слишком долго сидел в Jira.
А потом происходит странное.
Фича есть. Код работает. Продакт не спал три недели. Разработчики сделали сложную штуку, которую реально было непросто сделать. Внутри команды все понимают: «Вот оно. Это важно. Это должно выстрелить».
Но рынок почему-то не падает на колени. Пользователи не понимают, что изменилось. Продажи не понимают, как это объяснять. Маркетинг пытается собрать коммуникацию из того, что есть: технического описания, пары комментариев в задаче и общего ощущения команды, что «это важная штука». Клиент смотрит на всё это и думает: «Очень интересно, но мне-то что с этого?»
И вот где-то в этот момент в комнате появляется Product Marketing Manager.
Не чтобы рассказать разработчикам, как писать код. Не чтобы заменить Product Manager. И не чтобы «добавить маркетингового глянца» поверх инженерной мысли.
PMM нужен, чтобы сложная техническая ценность стала понятной рынку.
Потому что хороший код — это прекрасно. Но если клиент не понял, какую проблему вы ему решили, для рынка этого кода как будто не существует.
Product Manager и Product Marketing Manager — это не один человек, просто в разных худи
Иногда PMM воспринимают как «маркетолога при продукте». Иногда — как продакта, который почему-то пишет тексты. Иногда — как человека, который приходит в конце и говорит: «А давайте назовём это не модуль управления данными, а экосистема эффективности».
На этом этапе продуктовый маркетолог обычно берёт паузу, медленно выдыхает и констатирует: то, что вы делаете с терминами, называется насилием. И точка.
На самом деле всё проще.
Product Manager отвечает за то, что мы строим и почему это важно для продукта.
Product Marketing Manager отвечает за то, как рынок поймёт, купит и начнёт использовать то, что мы построили.
PM смотрит на пользователей, задачи, приоритеты, бэклог, метрики, ограничения и delivery. PMM смотрит на рынок, сегменты, конкурентов, позиционирование, запуск, продажи, коммуникации и то, как всё это выглядит в голове клиента.
Если совсем коротко:
PM помогает сделать правильный продукт.
PMM помогает сделать так, чтобы правильный продукт был понятен нужным людям.
PM и PMM работают с одним продуктом, но с разными слоями. Один отвечает за то, чтобы продукт был правильным внутри. Второй — за то, чтобы снаружи было понятно, зачем он нужен.
Разработчики могут объяснить продукт. Иногда даже слишком хорошо
Разработчики расскажут, как устроена архитектура, почему решение лучше предыдущего, где оптимизировали запрос, какие ограничения учтены и почему фраза «это же на пять минут» должна караться общественными работами в legacy-коде.
Это всё важно.
Но клиент обычно покупает не архитектуру. Он покупает сокращение времени, снижение риска, предсказуемость, контроль и уверенность, что ночью ему не позвонят с фразой «у нас всё легло».
И вот здесь начинается перевод.
Не с технического на «для тупых». А с языка реализации на язык ценности.
Например:
Язык разработки:
«Добавили возможность выполнять проверку прав доступа с учётом RLS и пользовательских ролей».
Язык классического маркетинга:
«Инновационная система безопасности и контроля на базе передовых ролевых моделей!»
Язык PMM:
«Теперь аналитик может быстро понять, почему конкретный пользователь не видит документ, не сбрасывая пароль и не устраивая археологические раскопки в настройках доступа».
Все три варианта могут описывать одну и ту же функцию. Но только последний отвечает на вопрос клиента: «А мне-то что с этого?»
Первый нужен в документации. Второй лучше оставить в 2014 году рядом с «уникальным комплексным решением для цифровой трансформации». Третий — в статье, лендинге, презентации для продаж и разговоре с руководителем, который не хочет знать, что такое RLS, но очень хочет, чтобы кладовщик наконец увидел нужный документ.
На каком этапе PMM и разработка перестают говорить на одном языке
В идеальном мире PMM приходит к разработке и говорит: «Я хочу объяснить клиенту ценность вот так. Проверьте, пожалуйста, не наврала ли я технически».
Разработка отвечает: «Вот здесь точнее сказать не ‘автоматически исправляет’, а ‘помогает выявить’. Вот это ограничение важно упомянуть. Вот тут лучше не обещать всем, потому что работает только при таких условиях».
PMM говорит: «Отлично, спасибо, поправлю».
Все счастливы. Продукт не соврал рынку. Рынок понял продукт. Никто не пострадал.
Но иногда процесс идёт по другому сценарию.
PMM пишет материал: с конфликтом, понятной болью, человеческим языком, метафорой, заголовком, который хочется открыть. Отдаёт на техническую проверку. А обратно получает текст, который стал точнее, спокойнее, стерильнее — и по настроению напоминает внутренний регламент, случайно опубликованный в интернете.
Все технические нюансы соблюдены. Все острые углы сглажены. Живые формулировки заменены на «осуществляется возможность выполнения операций в рамках контролируемого сценария».
Текст больше не врёт. Но и не живёт. Не вздумайте здесь ставить знак равенства.
У меня был похожий опыт с материалом про сложный IT-продукт для 1С-разработчиков и аналитиков. В первой версии была понятная продуктовая идея: в мире перегруженных инструментов пользователю нужна не ещё одна «кабина пилота», а способ быстрее добраться до результата. Были образы, конфликт, история про то, как инструмент снижает когнитивную нагрузку и помогает команде работать быстрее.
После правок материал стал технически аккуратнее, но продуктовый нерв ослаб. Вместо истории о выборе инструмента и его ценности для команды получился общий экспертный текст про практики разработки, диагностику, права доступа и управляемость изменений.
Плохой ли это текст? Нет.
Решает ли он ту же задачу? Уже нет.
Разработчики часто правят текст из лучших побуждений. Они защищают продукт от неточностей, преувеличений и маркетингового дыма. Это ценно. Без этого PMM попадает в красивую, но безжизненную фантазию — как в музей восковых фигур.
Проблема начинается не там, где разработчик говорит: «Так нельзя, продукт работает иначе».
Проблема начинается там, где разработчик говорит: «Давайте уберём конфликт, метафору, заголовок и всё человеческое. Так будет лучше».
Техническая точность обязательна. Но если после согласований текст можно использовать как снотворное для отдела продаж, что-то пошло не так.
Разработка уберегает от неточностей. PMM — от недопонимания
Это самая здоровая формула взаимодействия.
Разработчик должен иметь право сказать:
«Нет, это технически неверно».
«Нет, мы не можем обещать это всем пользователям».
«Нет, здесь есть ограничение».
«Нет, это не автоматизация, а инструмент для ручной проверки».
И PMM должен не обижаться, а благодарить. Рынок может простить сложный продукт. Но он плохо прощает обещания, которые не совпали с реальностью.
Но PMM тоже должен иметь право сказать:
«Да, технически формулировка полнее, но человек на третьем слове перестал читать».
«Да, это точное описание функции, но в нём нет ответа на вопрос ‘зачем мне это’».
«Да, можно назвать это механизмом оперативной диагностики пользовательских ограничений. Но клиент скажет: ‘А по-человечески?’»
«Нет, мы не станем перечислять модули в первом абзаце. Мы начнём с проблемы клиента.»
PMM отвечает не за украшение текста. PMM отвечает за смысл, который должен дойти до рынка без потерь.
Крутой код — это только половина успеха. Вторая половина — PMM. Почему?
Крутой код — это основа. Без него маркетинг быстро превращается в красивую упаковку для пустой коробки.
Но сам по себе код не отвечает на вопросы рынка:
Для кого этот продукт?
Почему ему должны поверить?
Чем он отличается от альтернатив?
Какую боль закрывает?
Почему это важно сейчас?
Как объяснить ценность не разработчику, а руководителю, ИТ-директору или пользователю?
Как запускать фичу, чтобы она не умерла в changelog?
Разработка отвечает на вопрос: «Как это работает?»
Product Manager отвечает на вопрос: «Что и для кого мы строим?»
PMM отвечает на вопрос: «Почему рынок должен выбрать это, понять это и начать этим пользоваться?»
Если последнего вопроса в компании никто не держит в фокусе, его всё равно кто-то будет решать. Просто плохо.
Продакт напишет лендинг между двумя встречами. Разработчик даст техническое описание. Маркетолог возьмёт пять слов из описания и добавит «эффективность». Сейлз придумает собственную версию ценности на звонке. Клиент попытается собрать из этого пазл, устанет и уйдёт к конкуренту, у которого продукт, возможно, слабее, но зато понятно, что он делает и зачем нужен.
Три симптома, что вам уже нужен PMM
PMM нужен не каждой команде с первого дня. Если у вас три клиента, один фаундер и всё держится на личных продажах, отдельный PMM может быть роскошью.
Но если продукт растёт, рынок усложняется, а коммуникации расползаются, симптомы появляются быстро.
1. Вы продаёте функции, а не ценность
На сайте написано: «Гибкий модуль управления сценариями обработки данных».
Клиент думает: «И что?»
Функция сама по себе почти никогда не является ценностью. Ценность появляется, когда понятно, какую боль она снимает, кому помогает и почему это важно.
В метриках это выглядит как низкая конверсия в регистрацию, демо или заявку: трафик идёт, люди что-то читают, но кнопка «Попробовать» простаивает как беговая дорожка в углу комнаты.
Плохая новость: клиент не обязан достраивать ценность в голове.
Хорошая новость: PMM обязан.
2. Релизы выходят, но не запускаются
Команда считает, что запуск состоялся, потому что фича попала в прод.
Пользователи считают иначе: они о ней не знают, не поняли или не увидели причины менять привычный процесс.
Запуск — это не момент, когда код доехал до прода. Это момент, когда нужные люди поняли, зачем им новая возможность, как её использовать и почему она стоит внимания.
В метриках это выглядит как низкая adoption rate новой функции и грустный Product Manager, который видит в аналитике: фичу просили полгода, а пользуются ей три человека, один из них тестировщик.
3. Продажи объясняют продукт каждый по-своему
Один менеджер говорит, что продукт про скорость. Второй — что про контроль. Третий — что про снижение затрат. Четвёртый обещает клиенту функцию, которую разработка потом ищет в бэклоге с выражением лица «откуда это взялось?».
Это не проблема продаж. Это проблема отсутствия единой упаковки ценности.
PMM делает так, чтобы у продаж были не только презентации, но и понятные сообщения: кому продаём, какую боль закрываем, какие аргументы используем, где границы обещаний.
В метриках это проявляется как раздутый цикл сделки, низкая конверсия из демо в оплату и много ручной героики, когда каждый сейлз заново изобретает позиционирование на звонке.
PMM — это не человек, который «делает красиво»
Самое обидное заблуждение про PMM — что это человек про тексты, лендинги и красивые слова.
Тексты действительно есть. Лендинги тоже. Иногда даже красивые слова, хотя их лучше дозировать как острый соус: чуть переборщил — и всё, кроме жжения, уже не чувствуешь.
Но PMM начинается раньше текста.
До статьи, лендинга или релизной рассылки он обязан чётко понимать: кто перед ним; какая боль движет этой аудиторией; как люди решают проблему сегодня и почему их не устраивают альтернативы; что в продукте по-настоящему ценно; какие ограничения нельзя скрывать; какой месседж должны нести продажи; и, наконец, что именно пользователь осознает после самого первого касания.
Как выстроить работу PMM и разработки
Чтобы PMM и разработка не превращали каждый материал в редакционный Mortal Kombat, нужны простые правила.
1. Разработка проверяет факты, а не переписывает голос
Разработчик должен проверять техническую точность, ограничения, корректность терминов, реальность обещаний и отсутствие опасных упрощений.
Но не должен переписывать текст так, чтобы он звучал как заявка на внутренний аудит.
Если хочется заменить живую фразу на канцелярит, стоит спросить себя: «Я исправляю ошибку или просто мне непривычно, что продукт описан человеческим языком?»
2. PMM не спорит с технической реальностью
Если продукт не умеет — не пишем. Если умеет только в определённых условиях — уточняем. Если есть риск неверного ожидания — снимаем риск.
Маркетинг не имеет права продавать то, что потом будет стыдно поддерживать.
3. Все спорят не из-за формулировок, а из-за того, что за ними стоит
Вопрос не в том, нравится ли кому-то метафора. → Вопрос в том, помогает ли она аудитории быстрее понять ценность.
Вопрос не в том, «слишком маркетингово» или «слишком технически». → Вопрос в том, работает ли текст на цель: объяснить, убедить, запустить, продать, обучить, снизить барьер, привести правильного клиента.
4. У текста должен быть один владелец
У текста должен быть один владелец. Иначе получается письмо из Простоквашино: один дописал про стратегию, второй — про ограничения, третий — про важную деталь из бэклога, а читатель теперь пытается понять, у кого лезет шерсть и чей хвост отваливается.
Техническая экспертиза важна. Продакт тоже важен. Но финальная сборка смысла должна быть у того, кто отвечает за коммуникационную задачу.
Если это продуктовая статья — у PMM или редактора, работающего с PMM.
Иначе получится не позиционирование, а протокол согласования.
Что в итоге
Product Marketing Manager нужен IT-продукту не потому, что разработчики плохо объясняют, а продакты плохо думают.
Он нужен потому, что у каждой сильной команды есть то, что остаётся за её фокусом.
Разработка слишком хорошо знает, как всё устроено внутри. Product Manager глубоко погружён в продуктовые решения и компромиссы. Продажи слишком близко к конкретным сделкам. Маркетинг часто работает с каналами, а не с продуктовой сутью.
PMM находится на стыке всего этого и задаёт неприятные, но полезные вопросы:
«Для кого это?»
«Почему это важно?»
«Как это объяснить без экскурсии по архитектуре?»
«Что мы обещаем рынку?»
«Чем мы отличаемся?»
«Что должен понять клиент за первые 30 секунд?»
«А если убрать все термины, ценность останется?»
Крутой код — это фундамент. Product Manager помогает построить правильный дом. А PMM делает так, чтобы к этому дому была дорога, на двери была понятная табличка, а потенциальный клиент не стоял у забора с мыслью: «Наверное, внутри что-то классное, но я так и не понял, зачем мне туда».
Поэтому спор о заголовке — это редко спор о конкретных словах. Чаще это спор о том, увидит ли рынок в продукте ценность или просто ещё одну сложную штуку из мира IT.
Код может быть реализован идеально. Но пока ценность не понята, для клиента её почти нет.
А как у вас в компании?
Кто у вас пишет релизы, упаковывает фичи и воюет за формулировки на сайте: продакты, маркетологи, отдельный PMM или сам фаундер?
И главное: как вы находите баланс между «технически точно до запятой» и «чтобы клиент не уснул на втором предложении»?