Зачем IT-продукту Product Marketing Manager, если у вас уже есть продакт, разработка и крутой код

В 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 или сам фаундер?

И главное: как вы находите баланс между «технически точно до запятой» и «чтобы клиент не уснул на втором предложении»?