Дисклеймер: этот материал основан на моем опыте в продуктовом маркетинге в сфере ИБ и enterprise IT.

Привет! Я Олег Хныков, а иногда в некотором роде Шерлок Холмс. Уже 12 лет я работаю в ИТ и ИБ: начинал SOC-аналитиком, потом ушел в пресейл, а сегодня руковожу маркетингом продуктов сетевой и инфраструктурной безопасности.

Почему «Шерлок»? Потому что и в SOC, и в маркетинге важна логика, умение видеть систему среди хаоса. Только в SOC мы ищем хакера, а в продуктовом маркетинге — настоящую ценность продукта для клиента. В обоих случаях важно не утонуть в деталях, а на моем текущем месте работы еще и в фичах и release notes.

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

Кому пригодится статья: продуктовым маркетологам в IT/ИБ, продуктовым менеджерам и владельцам продуктов, техническим специалистам, которые поглядывают в бизнесовую часть IT и предпринимателям

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

Ошибки позиционирования (что это вообще такое можно почитать тут) и упаковки стоят владельцам бизнеса больших незаработанных денег. Поэтому всё больше компаний топят за то, чтобы даже в B2B говорить по-человечески. Чтобы представителям бизнеса было понятно, а инженерам — интересно.  Ключ к этому — техническая эмпатия, умение встать на место каждого, кто принимает решение о закупке. «Стать технически эмпатичным» реально. Дальше расскажу как.

Упражнение первое: «Вопросы из зала». Спрашиваем себя и рынок

Немного душной, но важной теории. Любое успешное позиционирование начинается не с продукта, а с аудитории и проблемы. Первый шаг — разобраться, кому нужно техническое решение и какую проблему оно решит.

Задаем себе базовые вопросы:

  1. «Кто наша целевая аудитория? Кто наш клиент?» — без ответов на них маркетинг превращается в стрельбу в пустоту;

  2. «С какими задачами или болями клиент сталкивается?»;

  3. «Как наше решение это изменит?».

 Одновременно изучаем контекст:

  • Чем пользуются потенциальные клиенты в качестве альтернативы (конкуренты или старые методы);

  • Чем наше решение лучше.

Черновик позиционирования можно построить с помощью шаблона:

«Для [целевой клиент], который страдает от [проблема], наш [продукт] – это [категория решения], которое дает [ключевое преимущество]. В отличие от [альтернатива], наше решение [уникальные особенности]».

Заполнив такие поля, команда проверяет себя – учтены ли нужды клиента и понятна ли главная ценность. На этой основе строится краткое ценностное предложение (value proposition) понятным языком.

Мало кому понятное техническое описание

Стало лучше

«Система на базе распределенной архитектуры с инновационным алгоритмом анализа данных»

«Платформа, которая позволяет безопасно и прозрачно отслеживать каждую транзакцию в режиме реального времени».

Согласитесь, вариант справа поинтереснее? Ведь чем формулировка проще и ближе к боли клиента, тем крепче фундамент для дальнейшего маркетинга.

Кроме того, на старте важно еще понять общую картину и собрать вопросы о рынке и тенденциях:

  • Какие вызовы актуальны в отрасли;

  • Есть ли у компаний запрос на оптимизацию, безопасность, скорость.

Если продукт вписывается в тренд (например, автоматизация рутинных операций или импортозамещение технологий), это можно использовать в позиционировании. Но если технология опережает рынок, придется уделить больше сил «обучению» аудитории, т.е. объяснять «что это» и «почему сейчас».

Таким образом, правильные вопросы на старте помогут правильно «прицелиться»: решить, в каком ключе делать маркетинговые материалы и в каких каналах продвигаться. Начав с вопросов, вы избегаете ситуации, когда блестящий по характеристикам продукт «стреляет» в пустоту, потому что никто так и не смог объяснить, кому и зачем он нужен.

Упражнение второе: «Привет, инженер и бизнес-заказчик». Начинаем объяснять

Болезнь многих технических команд — говорить на своем языке, а не на языке аудитории. Инженеры любят детали, аббревиатуры, специфические описания архитектуры решения. Бизнес-заказчик думает о выгодах, рисках и ROI. Нам в IT-маркетинге нужно одинаково хорошо объяснять и тем, и другим. В этом помогает принцип разноуровневого повествования: сначала простая суть и польза — потом технические подробности по запросу.

Дальше расскажу про фреймворки, на которых строится повествование. Сам долго удивлялся, когда пришел в маркетинг, что в создании текстов, оказывается, тоже есть системный, иногда почти инженерный подход.

  • Фреймворк FAB (Feature – Advantage – Benefit). Классический маркетинговый прием, особенно полезный для технических продуктов. Он заставляет при описании каждой функции (Feature) тут же объяснить, какое преимущество (Advantage) дает эта функция в сравнении с тем, что было до, и какую выгоду (Benefit) из этого получит клиент. Этот фреймворк помогает не забывать превращать каждую характеристику в конкретную ценность. Например:

    «Наш модуль собирает сетевые события в реальном времени (функция), позволяет строить поведенческие профили (преимущество) и предотвращать инциденты до их развития (выгода)».

Этот шаблон особенно эффективен при подготовке презентаций и продажных материалов. Однако важно помнить: если клиент не знает, зачем ему эти функции, FAB не спасёт — сначала нужно прогреть контекст (такой кейс у меня был с продуктом NTA/NDR, если вам интересно про него почитать, напишите об этом в комментариях).

  • Golden Circle (Золотой круг): Why–How–What. Концепция Саймона Синека предлагает строить коммуникацию в последовательности «Почему? Как? Что?».

    • Сначала говорим глобально «зачем»: почему решение вообще важно, какую большую идею оно несет или проблему решает. Это зацепит эмоционально.

    • Затем объясняем, как всё работает (основной принцип, дифференциаторы – без избыточных деталей).

    • Лишь в конце конкретизируем, что за продукт (модель, модуль, технология).

Такой порядок противоположен привычному для инженера (который чаще идет от «что это такое»). Но на практике работает лучше для вовлечения клиента. Например:

Почти хорошо

Хорошо

«Это платформа аналитики данных (что), которая использует продвинутые алгоритмы машинного обучения (как), чтобы повысить эффективность маркетинга (зачем

«Чтобы маркетинг тратил бюджет точнее и окупал каждый рубль (почему, ценность), мы применяем ИИ для поиска скрытых паттернов в данных (как). Так появилась платформа X – ваш личный аналитик для принятия решений (что)».

Смысл тот же, но стартуя с «why», мы сразу говорим на языке клиентской цели.

  • Value Proposition Canvas (канва ценностного предложения) помогает соотнести проблемы и задачи клиента с преимуществами продукта. Делим листочек пополам и расписываем:

- какие работы совершает клиент (Jobs to be Done),
- какие у него боли (Pains),
- какие выгоды он ожидает (Gains).

- как продукт эти боли устраняет (Pain Relievers),
- какие выгоды дает (Gain Creators).

Таким образом, технические возможности привязываются к конкретным потребностям. Эта методика покажет команде, если какой-то функционал не закрывает ни одну боль —тогда, возможно, для позиционирования он не важен. Таким образом, канва фокусирует коммуникацию на том, что реально значимо для клиента, отсекая лишнее.

  • Storytelling по схеме «Герой – Препятствие – Решение – Успех». Универсальный сюжет, применимый и в техническом B2B.

    • Герой — ваш клиент (конкретная роль, например, директор по ИТ или главный бухгалтер).

    • У него есть препятствие – проблема или вызов (сложности с масштабированием инфраструктуры, подготовкой отчетности и т.д.).

    • Решение — появляется помощник (технология, продукт), который помогает преодолеть препятствие.

    • В конце — успех, то есть описание, как изменилась жизнь героя к лучшему.

Такой повествовательный каркас можно использовать в кейсах, выступлениях, white papers. Он оживляет подачу: вместо обезличенного «клиент сократил издержки на 20%» мы рассказываем мини-историю, в которой клиенту (герою) сопереживаешь. Это сильнее вовлекает и запоминается.

Один из ярких, на мой взгляд, примеров:

Скрытый текст

Облачный сервис Dropbox в 2007 году предлагал по тем временам сложную концепцию — файлы хранятся где-то в интернете и синхронизируются между устройствами. Вместо технических терминов стартап выпустил двухминутное видео с наглядной историей: герой мучается, перенося файлы на флешках, пока не находит «магическую папку», которая доступна везде. Видео было простым и веселым, а результат мгновенный: 70 тысяч регистраций за одну ночь после премьеры ролика.

Эта история стала хрестоматийной: даже инновационный сложный продукт можно объяснить так, что поймет и студент, и директор, и айтишник — нужно только говорить о решении понятных каждому проблем, а не об абстрактном новшестве.

  • «Пирамида» информации (метод Барбары Минто). Согласно этому принципу, сначала дается главная мысль (вывод), затем – аргументы и детали в порядке убывания важности. В нашем случае лучше начать с краткого резюме пользы, а потом уже раскрыть, как это достигается и из чего состоит. Например,

Просто поток сознания

Пирамида Минто

«Наше решение применяет алгоритмы машинного обучения, автоматизирует рутинные задачи и группирует одинаковые события. Благодаря этому SOC-аналитики работают быстрее, и компания экономит деньги, даже при огромном количестве инцидентов»

«Решение X экономит до 20% бюджета SOC, потому что сокращает время реакции в N раза. Достигнуть этого помогают ML-алгоритмы, автоматизация рутинных действий и агрегация одинаковых событий».

Такой подход гарантирует, что, даже пробежав первые несколько строк, читатель уяснит основное ценностное предложение. Детали же он изучит, если его это зацепило. Для нетерпеливой аудитории (а среди бизнес-людей большинство именно такие, потому что время = деньги «обратная пирамида» подачи критически важна.

  • Аналогии и сравнения как отдельный прием. Исследования подтверждают, что грамотно подобранная аналогия заметно повышает понимание технических описаний. Можно использовать этот микро-фреймворк по схеме:

«X – это как Y, но Z», где X – ваш продукт, Y – что-то знакомое, Z – чем отличается.

Например,

Скрытый текст

«Наша платформа – как личный помощник, только работает 24/7 и не ошибается».

Или в техническом контексте:

Скрытый текст

«Docker – это как контейнеры на корабле: упаковывают приложение с его средой, чтобы перевезти куда угодно без изменений».

Формула простая, но найти удачное Y и правильно описать Z — искусство, требующее знания аудитории. Правильно подобранное сравнение моментально снимает большинство вопросов.

Опишите картину в целом: какую проблему решает продукт и какой результат получит клиент. Например, вместо «система с распределенной архитектурой и машинным обучением» скажите «сервис, который за секунды обнаруживает мошеннические операции и экономит вам миллионы на убытках».

Директор услышит про экономию денег и снижение рисков, инженер — поймет какую задачу выполняет система (и при желании уточнит детали). Простое описание ценности, как заголовок, зацепит всех.

Скрытая, но важная, сторона технической эмпатии

Погружаемся в роль слушателя/ читателя.

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

Аналогии, про которые говорили выше, одинаково хорошо сработают для обеих сторон. Скажем, использование облачного сервера можно сравнить с арендой офиса вместо покупки здания и написать: «Платите за ресурс, когда он нужен, и не тратьтесь на обслуживание инфраструктуры». Инженер оценит корректность сравнения, а бизнесу/владельцу/руководителю станет ясно преимущество модели.

Важно избегать двух крайностей:

  • Жаргон и технические детали без контекста. Фразы вроде «продукт устанавливает защищённое соединение по протоколу TLS 1.3 поверх TCP с использованием TLS_AES_128_GCM_SHA256, обеспечивающей симметричное шифрование на основе AES-128 в режиме GCM и контроль целостности через SHA-256» мгновенно лишают вас части аудитории.

  • Чрезмерное упрощение вплоть до банальностей. Если сказать «это программа, которая экономит вам время и деньги», не пояснив как, то технический специалист лишь усмехнется: слишком уж общее обещание.

Поэтому хорошо бы найти баланс — говорить простыми словами о важном и, если надо, углубиться. Можно не стараться сделать что-то одно универсальное, а подготовить разные уровни материалов: короткое описание с конкретными преимуществами продукта (one page) для C-level, презентацию с архитектурой и спецификациями для IT-специалистов, детальные white paper для технических хардкорщиков. Но единая центральная идея ценности должна прослеживаться у всех.

Проверяем наш посыл на «проклятие знания»

Это когнитивное искажение, когда эксперту трудно представить, что другие не знают очевидных для него вещей. Протестируйте свое описание на «новичках». Хороший признак — когда человек, далёкий от темы, услышав ваш посыл, может своими словами пересказать, что делает продукт и зачем он нужен. Если же без дополнительных вопросов не обошлось, это сигнал: надо еще упростить или прояснить непонятные места.


На этом пока остановлюсь. В следующей статье расскажу, что сложнее позиционировать — абсолютно новый продукт или «переупакованный» старый, и почему в B2B-маркетинге важно не только рациональное обоснование, но и эмоциональная подача.

Комментарии (0)