100 глав для успешного бизнеса
- -
- 100%
- +
Видите, дело было не во вкусе или возрасте покупателя, а в контексте и задаче, которую он решал.
А как это в B2B? Да точно так же, только ставки выше!
Какой-нибудь завод покупает не просто "станок с ЧПУ". Он "нанимает" этот станок на работу: "стабильно и точно изготавливать детали по заданным чертежам с минимальным количеством брака и простоев, чтобы вовремя выполнять заказы клиентов, сохранять репутацию надежного поставщика и обеспечивать рентабельность производства".
Чувствуете разницу? В этом описании "работы" есть:
Функциональный аспект: точность, скорость, надежность.
Эмоциональный аспект: уверенность в выполнении заказов, спокойствие за репутацию, отсутствие головной боли из-за простоев.
Социальный аспект: соответствие стандартам качества, репутация в отрасли.
Понимание всей этой работы, а не только технических характеристик, – ключ к созданию действительно ценного продукта и правильному его позиционированию. Мы перестаем продавать "железо" и начинаем продавать "решение проблемы" или "достижение прогресса".
Как "Раскопать" Настоящую Работу Клиента? (Интервью JTBD – Слушаем Про Борьбу)
Окей, звучит логично. Но как понять, на какую именно "работу" клиент хочет нанять наш продукт? Не будешь же пытать каждого клиента: "Эй, какую работу ты тут выполняешь?".
Есть специальный метод – интервью в стиле Jobs to Be Done. Его главная фишка – мы фокусируемся не на абстрактных потребностях или мнении о продукте, а на реальной истории покупки или "переключения" с одного решения на другое. Мы просим человека вспомнить последний раз, когда он столкнулся с проблемой и нашел для нее решение (купил продукт, заказал услугу, внедрил новый процесс).
Наша цель – реконструировать всю цепочку событий и понять силы, которые действовали на клиента:
Толчок: Что заставило его вообще задуматься о поиске нового решения? Какая проблема или неудовлетворенность стала последней каплей? ("Старый поставщик постоянно срывал сроки", "Наше оборудование слишком часто ломалось", "Получили предписание от проверяющих органов").
Притяжение: Что привлекло его в новом решении? Какую "лучшую жизнь" он себе представлял с ним? ("Обещали сократить время обработки на 30%", "У них круглосуточная поддержка", "Эта система интегрируется с нашей 1С").
Тревоги: Какие сомнения и страхи мешали принять решение? Чего он опасался? ("А вдруг будет сложно внедрить?", "А если не окупится?", "Что скажут сотрудники?", "Надежный ли это поставщик?").
Привычки: Что удерживало его в старом решении? К чему он привык, даже если это было неидеально? ("Мы всегда работали с этой программой", "Наши люди уже обучены под старое оборудование", "Неохота затевать весь этот процесс заново").
Чтобы вытащить эти силы, мы задаем открытые вопросы, слушая не только ответы, но и интонации, эмоции:
"Расскажите, когда вы впервые задумались о том, чтобы [купить Х / сменить поставщика Y]?"
"Что происходило в вашем бизнесе / вашей работе в тот момент?"
"Что вы пробовали использовать для решения этой задачи до того, как выбрали [наш продукт / продукт конкурента]?"
"Что именно вас не устраивало в старом подходе? Можете привести конкретный пример?"
"Был ли какой-то момент, когда вы подумали: 'Всё, хватит, нужно что-то менять!'?"
"Как вы искали варианты? На что обращали внимание?"
"Какие решения рассматривали? Что в них нравилось/не нравилось?"
"Были ли у вас какие-то сомнения или опасения перед тем, как выбрать [конечное решение]?"
"Что стало решающим фактором в пользу именно этого варианта?"
"Как проходил процесс покупки/внедрения?"
"Что изменилось в вашей работе/бизнесе после того, как вы начали использовать [новое решение]? Что стало лучше? Может, что-то хуже?"
Такое интервью похоже на детективное расследование. Мы не спрашиваем: "Что вам нужно?", мы спрашиваем: "Что происходило?". Мы ищем не характеристики, а контекст, борьбу и желаемый прогресс.
Представьте, вы общаетесь с начальником службы эксплуатации крупного промышленного предприятия, который недавно перешел с масел "Ромашка Ойл" на ваши супер-пупер индустриальные смазки "МегаПромЛубрикант". Вы можете спросить: "Почему выбрали нас?". Он ответит: "Цена/качество устроили". Банально. А можешь копнуть глубже по JTBD: "Расскажите, что вас подтолкнуло искать замену 'Ромашке'?". И тут может выясниться, что у них из-за некачественной смазки дважды за год вставал критически важный редуктор, был срыв производства, премию сняли… И его настоящая работа была не "купить масло подешевле", а "обеспечить бесперебойную работу ключевого оборудования, чтобы спать спокойно и не получать по шапке от директора". Чувствуете? Это уже совсем другая история и другие критерии выбора!
Формулируем "Заказ на Работу" (Собираем Пазл: Контекст, Мотивация, Результат)
После нескольких таких интервью у вас начнет вырисовываться картина – та самая "Работа", на которую клиенты "нанимают" решения в вашей сфере. Чтобы зафиксировать это понимание и передать его команде (разработчикам, маркетологам, продажникам), полезно сформулировать Job Statement.
Классическая структура выглядит так:
Когда [Контекст/Ситуация], я хочу [Мотивация/Цель], чтобы [Желаемый Результат/Исход].
Давай попробуем на примерах из нашего B2B:
Поставщик ПО для управления складом:
Работа: Когда [я, начальник склада, вижу расхождения между учетной системой и реальными остатками при инвентаризации], я хочу [быстро находить причину ошибок и минимизировать их в будущем], чтобы [сократить потери от недостач/пересортицы, ускорить отгрузку заказов и избежать штрафов от клиентов за некомплект].
Производитель промышленных фильтров для очистки воздуха:
Работа: Когда [ко мне на производство приходит проверка по экологии], я хочу [быть уверенным, что все показатели выбросов в норме и документация в порядке], чтобы [избежать огромных штрафов, остановок производства и репутационного ущерба].
Консалтинговая компания по бережливому производству:
Работа: Когда [я, директор завода, вижу, что себестоимость продукции растет, а производительность падает], я хочу [выявить и устранить скрытые потери в производственных процессах], чтобы [повысить рентабельность, стать конкурентоспособнее и высвободить ресурсы для развития].
К этой основной структуре можно (и нужно!) добавлять:
Ограничения: "…при этом не останавливая основное производство", "…в рамках выделенного бюджета", "…используя имеющийся персонал".
Эмоциональные и социальные аспекты: "…и чувствовать себя спокойно во время аудита", "…чтобы мои сотрудники гордились рабочим местом", "…и соответствовать международным стандартам качества, чтобы выйти на экспорт".
Такая четкая формулировка "Работы" – это как техническое задание от клиента, только написанное на его языке и с фокусом на его реальные цели.
От "Знания Работы" к Продукту (Строим Решение Вокруг Задачи, а не Фичей)
А теперь самое главное: как это знание о "Работе" помогает нам создавать и улучшать продукты?
Приоритезация фичей: Вместо того чтобы пихать в продукт все, что только можно ("А давайте добавим еще 100500 настроек!"), мы задаем вопрос: "Поможет ли эта фича клиенту выполнить его 'Работу' лучше (быстрее, дешевле, надежнее, с меньшими усилиями, с большим спокойствием)?". Если да – делаем. Если нет или "может быть, когда-нибудь пригодится" – откладываем или выбрасываем. Это помогает бороться с раздуванием функционала и фокусироваться на главном.
Проектирование всего опыта: "Работа" клиента часто не ограничивается взаимодействием только с самим продуктом. Она включает в себя поиск информации, покупку, доставку, установку, обучение, поддержку, утилизацию… Понимание полной "Работы" помогает проектировать весь этот опыт так, чтобы он был максимально гладким и помогал клиенту достичь прогресса.
Пример: Производитель сложного оборудования понимает, что "Работа" клиента включает и "быстро обучить персонал работе на новом станке". Значит, нужно не только сделать станок, но и разработать понятные инструкции, видеоуроки, возможно, предложить программу обучения.
Поиск идей для инноваций: JTBD – мощный инструмент для поиска "голубых океанов". Где клиенты все еще "мучаются", используя неидеальные решения? Какие аспекты "Работы" текущие продукты игнорируют? Можем ли мы предложить решение, которое выполняет "Работу" радикально лучше, проще или дешевле? Можем ли мы устранить какие-то шаги, которые сейчас должен делать клиент?
Пример: Компания, поставляющая промышленные газы в баллонах, обнаружила, что для клиентов большая головная боль – это учет пустых баллонов, их хранение и своевременный заказ новых (Работа: "обеспечить непрерывное снабжение нужным газом без лишних хлопот и затрат на хранение"). Они предложили инновационное решение: систему автоматического мониторинга остатков в баллонах с автоматическим заказом и оптимизированной логистикой доставки/забора. Они не улучшили сам газ, они кардинально улучшили выполнение "Работы" вокруг него.
Сегментация по "Работе": Иногда оказывается, что разные группы клиентов "нанимают" один и тот же продукт на разные "Работы". Например, небольшой цех "нанимает" сварочный аппарат для "универсального использования на разных задачах от случая к случаю", а крупный завод – для "высокопроизводительной сварки однотипных деталей на конвейере". Понимание этих разных "Работ" позволяет адаптировать продукт (возможно, создать разные версии) и маркетинг под каждый сегмент.
JTBD и Маркетинг с Продажами (Говорим о Прогрессе, а не о Продукте)
Понимание "Работы" клиента меняет и то, как мы о продукте рассказываем.
Маркетинг: Вместо того чтобы трубить о характеристиках ("Наш насос качает 100 литров в минуту!"), мы говорим о "Работе" и результате ("Надежное водоснабжение вашего цеха без перебоев, чтобы вы могли сосредоточиться на производстве"). Рекламные сообщения, контент на сайте, кейсы – все начинает резонировать с реальной проблемой и желаемым прогрессом клиента. Мы показываем, что понимаем его "боль" и предлагаем "лекарство".
Продажи: Менеджер, вооруженный знанием JTBD, задает правильные вопросы, чтобы понять, какую "Работу" пытается выполнить конкретный потенциальный клиент в его ситуации. Это помогает точнее квалифицировать лида, адаптировать презентацию и аргументацию, снять тревоги и отработать возражения, связанные не с продуктом, а с процессом "переключения". Он продает не дрель, а аккуратные дырки в стене (и отсутствие пыли!).
Вместо заключения
Переход на мышление в стиле Jobs to Be Done – это не просто модный тренд. Это фундаментальный сдвиг от продуктоцентричности к клиентоцентричности. Это способ по-настоящему глубоко понять, зачем мы нужны нашим клиентам, и на основе этого понимания создавать продукты, которые не просто покупают, а которые с радостью "нанимают на работу" снова и снова.
Это требует усилий: нужно проводить интервью, анализировать, менять привычные подходы. Но результат – продукты, которые бьют точно в цель, и маркетинг, который говорит с клиентом на одном языке, – того стоит.
Итак, мы научились определять, какую "Работу" хочет выполнить наш B2B-клиент. Звучит здорово! Но как превратить это знание – эти потребности, желания, критерии успеха – в конкретные технические характеристики, функции и параметры нашего будущего продукта? Как убедиться, что то, что мы разрабатываем, действительно "закроет" ту самую "Работу"?
Об этом – в следующей главе! Мы познакомимся с довольно интересным (хоть и немного суровым на первый взгляд) инструментом под названием Структурирование Функции Качества.
Глава 2: Методология QFD в Разработке Продукта (Quality Function Deployment)
Итак, представьте: мы провели JTBD-интервью, копнули глубоко, и теперь знаем сокровенные желания нашего B2B-клиента. Мы знаем, какой прогресс он ищет, какую "работу" пытается выполнить с помощью нашего (или не нашего) продукта. Например, наш клиент – главный инженер завода – хочет не просто "купить компрессор", а "обеспечить бесперебойную подачу сжатого воздуха нужного качества в цеха, минимизировав затраты на электроэнергию и обслуживание, чтобы производство работало как часы, а он мог спать спокойно". Звучит красиво!
Но тут возникает вопрос на миллион: а как команде разработчиков, конструкторов, инженеров – людям, которые мыслят чертежами, материалами и технологиями – понять, что именно нужно сделать, чтобы клиент получил это самое "бесперебойное снабжение", "минимизацию затрат" и "спокойный сон"? Как перевести туманные маркетинговые "хотелки" и глубокие клиентские инсайты на язык конкретных технических требований?
Ведь сколько раз бывало: маркетологи прибегают с идеей "супер-фичи", инженеры ее пилят полгода, а потом оказывается, что клиенту она не нужна, или нужна совсем другая. Или инженеры увлекаются какой-то сложной технологией, потому что это "круто" с технической точки зрения, а на реальные потребности клиента это влияет слабо, зато цену задирает до небес. Знакомая песня?
Чтобы такого не случалось, умные люди (а именно японцы в 60-70х годах, сначала в Mitsubishi, потом в Toyota) придумали методологию QFD – Quality Function Deployment, что на русский часто переводят как Структурирование Функции Качества. Не пугайтесь громоздкого названия! Если по-простому, то QFD – это как супер-переводчик с языка клиента ("что я хочу получить") на язык инженера ("что мы должны для этого сделать"). Это система, которая помогает гарантировать, что "голос клиента" будет услышан и правильно понят на всех этапах создания продукта – от идеи до конвейера.
QFD – Мост Между "Хочу" Клиента и "Можем" Инженера
Представьте пропасть между отделом маркетинга/продаж (которые общаются с клиентами и понимают их "боли") и отделом разработки/производства (которые создают продукт). Маркетологи говорят о выгодах, эмоциях, "бесшовном опыте". Инженеры – о мегапаскалях, микронах, протоколах передачи данных. Часто они друг друга просто не понимают!
QFD строит прочный мост через эту пропасть. Это структурированный подход, который заставляет разные отделы вместе проанализировать потребности клиента и договориться, какие конкретные технические характеристики продукта являются ключевыми для удовлетворения этих потребностей. Главная цель – не "потерять" клиента и его нужды где-то по дороге от первоначальной идеи до готового изделия. Чтобы в итоге получился не просто набор крутых фич, а продукт, который реально решает ту самую "работу" клиента.
Строим "Дом Качества": Экскурсия по Комнатам
Самый известный инструмент QFD – это матрица, которую называют "Дом Качества". Выглядит она действительно немного похоже на дом со стенами, крышей, подвалом. Давай устроим небольшую экскурсию по этому "дому" и посмотрим, что там внутри. Чтобы было понятнее, будем сразу применять к нашему примеру – разработке нового промышленного компрессора, который должен выполнять ту самую "работу" по "бесперебойному снабжению воздухом с минимизацией затрат и головной боли".
Левая Стена – "ЧТО?" Хотят Клиенты (Голос Клиента + Важность)
Здесь мы записываем все требования, пожелания, нужды, критерии успеха нашего клиента. Откуда берем? Из опросов, анализа жалоб, отзывов, требований стандартов, и, конечно же, из наших JTBD-интервью! Это и есть тот самый "Голос Клиента"
Важно формулировать эти требования языком клиента, но при этом достаточно конкретно.
Пример для компрессора:
"Работает без сбоев" (из JTBD про "бесперебойность")
"Потребляет мало электроэнергии" (из JTBD про "минимизацию затрат")
"Требует редкого и простого обслуживания" (из JTBD про "минимизацию головной боли")
"Легко интегрируется в нашу систему управления"
"Работает в условиях запыленности цеха"
"Имеет понятный интерфейс управления"
"Низкий уровень шума"
"Занимает мало места"
…и так далее. Список может быть длинным!
Рядом с каждым требованием мы ставим оценку важности для клиента (например, по шкале от 1 до 5). Откуда ее взять? Опять же, из опросов или интервью. Какие требования критичны, а какие – "приятный бонус"? Это поможет нам потом сфокусироваться на главном. Например, "Работает без сбоев" – явно 5/5, а "Занимает мало места" – может быть, 3/5.
Потолок – "КАК?" Мы Можем Это Сделать (Голос Инженера / Технические Характеристики)
Здесь в игру вступают инженеры. Они должны перевести каждое "ЧТО" клиента на язык измеримых технических характеристик продукта. Это те параметры, на которые разработчики могут непосредственно влиять.
Ключевое слово – ИЗМЕРИМЫЕ! Не "хорошая надежность", а "Среднее время наработки на отказ " в часах. Не "энергоэффективный", а "Удельный расход электроэнергии (кВт*ч на кубометр воздуха)".
Пример для компрессора:
MTBF (часы)
Удельный расход электроэнергии (кВт*ч/м³)
Межсервисный интервал (моточасы)
Время стандартного ТО (часы)
Поддерживаемые протоколы связи (Modbus, Profinet и т.д.)
Класс защиты корпуса (IP)
Уровень звукового давления (дБ)
Габаритные размеры (ДхШхВ, мм)
КПД двигателя (%)
…и так далее. Инженеры знают, что измерять!
Главная Комната – Матрица Взаимосвязей (Где Магия?)
А вот и сердце "Дома"! Эта большая матрица показывает, как сильно каждая техническая характеристика ("КАК") влияет на удовлетворение каждой потребности клиента ("ЧТО").
Мы заполняем пересечения строк ("ЧТО") и столбцов ("КАК"), используя символы или цифры для обозначения силы связи. Обычно используют:
Сильная связь (например, 9 или ●)
Средняя связь (например, 3 или ○)
Слабая связь (например, 1 или △)
Отсутствие связи (пусто)
Пример для компрессора:
Как MTBF влияет на "Работает без сбоев"? Очень сильно! Ставим 9 (●).
Как Удельный расход энергии влияет на "Потребляет мало электроэнергии"? Тоже очень сильно! Ставим 9 (●).
Как Межсервисный интервал влияет на "Требует редкого обслуживания"? Сильно! Ставим 9 (●).
А как Уровень шума влияет на "Работает без сбоев"? Никак. Оставляем пусто.
Как Класс защиты корпуса (IP) влияет на "Работает в условиях запыленности"? Сильно! Ставим 9 (●).
Как Габаритные размеры влияют на "Потребляет мало энергии"? Скорее всего, никак или очень слабо.
Заполнение этой матрицы требует совместной работы маркетологов и инженеров, обсуждений и иногда даже споров. Но именно здесь происходит "перевод" с языка клиента на язык техники!
Крыша – Матрица Корреляций (Дружат ли Инженеры?)
Эта треугольная матрица наверху показывает, как технические характеристики ("КАК") влияют друг на друга. Помогают они друг другу или мешают?
Мы используем символы для обозначения сильной положительной (++), положительной (+), сильной отрицательной (–), или отрицательной (-) корреляции.
Пример для компрессора:
Увеличение КПД двигателя (+) может положительно повлиять на Удельный расход энергии.
Увеличение Класса защиты корпуса (IP) (–) может отрицательно повлиять на Габаритные размеры (сделать компрессор больше) или на стоимость.
Увеличение MTBF (–) может потребовать использования более дорогих компонентов, что повлияет на цену.
"Крыша" помогает заранее увидеть потенциальные технические компромиссы. Нельзя просто взять и улучшить все параметры до максимума – придется искать баланс.
Правая Веранда – Сравнение с Конкурентами (Глазами Клиента)
Здесь мы сравниваем наш текущий (или планируемый) продукт с продуктами ключевых конкурентов по каждому требованию клиента ("ЧТО"). Оценка дается с точки зрения клиента (например, по 5-балльной шкале).
Откуда брать данные? Опросы клиентов, отзывы, сравнительные тесты (но с фокусом на восприятие клиента).
Пример для компрессора: Как клиенты оценивают наш и компрессоры A и B по критерию "Работает без сбоев"? А по "Потребляет мало энергии"? А по "Простота обслуживания"?
Это помогает увидеть наши сильные и слабые стороны относительно конкурентов именно в том, что важно клиенту.
Подвал – Техническое Сравнение (По Линейке Инженера)
А здесь мы сравниваем наш продукт и продукты конкурентов уже по объективным техническим характеристикам ("КАК").
Данные берем из технических паспортов, собственных измерений, тестов.
Пример для компрессора: Какой реальный MTBF у нас и у конкурентов A и B? Какой удельный расход энергии? Какой класс IP?
Сравнивая "Подвал" и "Правую Веранду", можно найти интересные вещи. Например, наша техническая характеристика может быть объективно лучше, чем у конкурента, но клиенты этого не воспринимают (проблема маркетинга?). Или наоборот: технически мы отстаем, и клиенты это чувствуют.
Фундамент – Целевые Значения и Техническая Важность (Куда Целимся?)
На основе всей информации в "Доме" (важности клиентских требований, силы связей в матрице, сравнения с конкурентами) мы можем рассчитать техническую важность каждой характеристики ("КАК"). То есть, какие параметры важнее всего улучшать, чтобы максимально удовлетворить самые важные потребности клиента и обойти конкурентов.
Здесь же мы устанавливаем конкретные целевые значения для технических характеристик нашего нового продукта. Не просто "улучшить MTBF", а "достичь MTBF не менее 15 000 часов". Не просто "снизить энергопотребление", а "добиться удельного расхода не более 0.1 кВт*ч/м³".
Это и есть конкретное техническое задание для разработчиков, выросшее напрямую из "Голоса Клиента"!
Уф! Экскурсия закончена. "Дом Качества" – это мощный инструмент для анализа и планирования. Он визуализирует сложную информацию и помогает команде принимать обоснованные решения.
За Стенами Первого Дома: Каскад Качества
Важно понимать, что QFD часто не заканчивается на первом "Доме Качества", который фокусируется на продукте в целом. Этот процесс может каскадом спускаться дальше:
Проектирование Компонентов: "КАК" из первого дома (тех. характеристики продукта) становятся "ЧТО" для второго дома. А "КАК" во втором доме – это уже характеристики конкретных узлов и деталей (например, тип подшипника, материал корпуса, алгоритм управления).
Планирование Процессов: Характеристики деталей ("КАК" из второго дома) становятся "ЧТО" для третьего дома. А "КАК" здесь – это уже параметры технологических процессов (например, точность обработки, температура пайки, режим термообработки).
Планирование Производства: Параметры процессов ("КАК" из третьего дома) становятся "ЧТО" для четвертого дома. А "КАК" здесь – это конкретные методы контроля качества, инструкции для рабочих, требования к оборудованию на производственной линии.
Идея в том, чтобы "Голос Клиента", пойманный на самом верху, не потерялся и дошел до самого цеха, влияя на все решения по пути. Конечно, не всегда нужно строить все четыре дома, но сама логика каскадирования очень полезна.
Зачем Весь Этот "Сыр Бор"? Плюсы QFD для Серьезного B2B
Строить "Дом Качества" – задачка не на пять минут, требует усилий и вовлечения команды. Стоит ли оно того, особенно в нашем динамичном мире? Для серьезного B2B, особенно с технически сложными продуктами, – однозначно ДА! Почему?
Фокус на клиенте: QFD не дает забыть, для кого мы делаем продукт. Потребности клиента – во главе угла.
Меньше ошибок и переделок: Проблемы и несоответствия выявляются на ранних стадиях проектирования, а не когда уже поздно и дорого что-то менять.
Ускорение разработки: Как ни странно, хотя QFD требует времени на старте, он часто сокращает общее время вывода продукта на рынок за счет уменьшения итераций и споров на поздних этапах.
Улучшение коммуникации: Заставляет маркетологов, инженеров, производственников говорить на одном языке и понимать друг друга.