Работа клиента не равна пользе продукта

Первая идея из AJTBD, которая заставила меня пересмотреть собственные формулировки, звучит просто:

Работа клиента не равна продукту, функции или пользе решения.

На уровне определения всё понятно.

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

Мы говорим:

• анализировать звонки;
• находить провалы менеджеров;
• показывать повторяющиеся паттерны;
• строить сводный отчёт;
• рекомендовать следующий шаг.

Все фразы звучат как полезные результаты.

Но какую из них можно назвать работой клиента?

Оказалось, что до ответа нужно разделить несколько разных слоёв.

Работа

Работа - это изменение, которого человек пытается добиться в определённом контексте.

Не действие внутри интерфейса и не технический результат.

Например:

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

Это пока гипотеза, а не доказанная работа. Но в ней есть важные элементы:

• контекст;
• ожидаемый результат;
• более высокая цель.

Решение

Решение - то, что человек нанимает для выполнения работы.

Для одной и той же работы решения могут быть совершенно разными:

• сильный РОП;
• еженедельная планёрка;
• CRM-отчёт;
• личное прослушивание звонков;
• специалист контроля качества;
• консультант;
• речевая аналитика;
• «Дожми Продажи»;
• бездействие до появления серьёзной просадки.

Последний вариант тоже важен.

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

Функция

Функция - конкретная возможность решения.

Например:

• автоматически расшифровывать звонки;
• считать критерий;
• показывать рейтинг менеджеров;
• собирать сводку по ста коммуникациям;
• находить похожие фрагменты;
• формировать карточку разбора.

Функция может быть хорошо сделана и всё равно не быть нужной конкретному человеку.

Она полезна только тогда, когда помогает выполнить работу в нужном контексте.

Польза

Польза описывает, что функция даёт пользователю.

Например:

• не нужно слушать все звонки вручную;
• можно быстрее найти повторяющуюся ошибку;
• руководитель получает одинаково оформленные доказательства;
• спор о качестве разговора можно вернуть к конкретной цитате;
• легче выбрать тему разбора с менеджером.

Польза уже ближе к человеческому результату, но тоже не всегда является работой.

Фраза «быстрее увидеть провал» отвечает на вопрос, что улучшило решение.

Фраза «сохранять управляемость продаж без ежедневного погружения» отвечает на вопрос, зачем руководителю это улучшение.

Проблема решения

Проблема относится не к работе вообще, а к конкретному способу её выполнения.

Допустим, собственник нанимает ручную прослушку звонков.

Проблемы могут быть такими:

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

Эти проблемы не являются работой.

Неправильно формулировать:

Работа клиента - избавиться от ручной прослушки.

Избавиться от ручной прослушки можно, просто перестав контролировать звонки.

Работа находится выше:

Получать достаточную картину происходящего, чтобы принимать управленческие решения.

Почему основателю легко всё перепутать

Мы живём внутри продукта.

Команда обсуждает модули, отчёты, интеграции и сценарии использования. Поэтому язык продукта становится языком мышления.

Если у нас появился модуль поиска успешных паттернов, мы начинаем видеть вокруг работу «найти успешные паттерны».

Если сделали рекомендованный следующий шаг, появляется работа «получить следующий шаг».

Если строим панель управленческого фокуса, кажется, что работа клиента - «проверить управленческий фокус».

Возможно, такие работы действительно существуют на низком уровне.

Но подозрительно, когда список работ почти полностью повторяет меню продукта.

С высокой вероятностью мы описываем собственную архитектуру, а не жизнь клиента.

Пример на другом продукте

Возьмём CRM.

Функции:

• хранить карточки клиентов;
• фиксировать этапы;
• ставить задачи;
• строить отчёты;
• отправлять уведомления.

Польза:

• информация не теряется;
• менеджеры видят следующие действия;
• руководитель получает картину по воронке.

Проблемы текущего решения:

• сотрудники не заполняют поля;
• данные устаревают;
• отчёты не отражают реальные разговоры;
• внедрение занимает много времени.

Возможные работы разных людей:

• собственник хочет сделать продажи менее зависимыми от памяти отдельных менеджеров;
• РОП хочет вовремя видеть сделки без следующего шага;
• менеджер хочет не потерять обязательства перед клиентом;
• новый сотрудник хочет быстро восстановить контекст сделки.

Один продукт. Несколько работ. Разные контексты и критерии успеха.

Что это меняет для «Дожми Продажи»

Раньше мы могли начать описание с продукта:

Платформа анализирует коммуникации, находит потери и показывает следующие шаги.

Это полезно для объяснения возможностей.

Но исследовательский вопрос должен начинаться иначе:

Что происходило в компании до того, как человек начал искать такой анализ?

Например:

• собственник слишком поздно узнал о просадке;
• РОП не смог доказать, что менеджеры выполняют новый стандарт;
• компания меняла скрипт, но не понимала, применяют ли его;
• лучшие менеджеры продавали заметно лучше остальных, но никто не мог объяснить почему;
• консультант дал рекомендации, а команда не смогла проверить их на всей массе коммуникаций.

Только после этого можно смотреть, какое решение нанимали и где появляется наша платформа.

Работа не должна быть слишком широкой

Есть и обратная опасность.

Можно подняться так высоко, что формулировка потеряет практический смысл.

Например:

Развивать успешный бизнес.

Почти любой B2B-продукт можно привязать к этой цели. Она не помогает выбрать сегмент, конкурентов или продуктовый сценарий.

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

Именно поэтому в AJTBD важна структура:

• когда;
• хочу;
• чтобы.

Контекст удерживает формулировку от абстракции.

Результат отделяет работу от решения.

Работа выше показывает, зачем результат имеет значение.

Как я теперь проверяю формулировку

Пока я использую четыре простых вопроса.

1. Может ли человек выполнить эту работу другим типом решения?

Если нет, возможно, я описал функцию продукта.

2. Зачем ему нужен названный результат?

Если ответ раскрывает более важную цель, исходная формулировка может быть низкоуровневой работой.

3. Что он делал до появления нашего продукта?

Если ничего, нужно проверить, существует ли работа в поведении.

4. Какая проблема относится именно к текущему решению?

Это помогает не перепутать неудобство инструмента с целью человека.

Промежуточный вывод

На первой лекции я ожидал получить способ лучше формулировать ценность продукта.

Вместо этого получил более неудобную задачу - перестать начинать с продукта.

Пока я не знаю точную работу «Дожми Продажи».

Но уже вижу, какие ответы нельзя принимать слишком быстро:

• «клиенту нужен отчёт»;
• «клиент хочет AI-анализ»;
• «клиенту важно найти паттерны»;
• «клиенту нужен следующий шаг».

Всё это может оказаться частью решения.

Нужно восстановить ситуацию, результат и работу уровнем выше.

Практическое упражнение

Возьмите одну ключевую формулировку своего продукта и разложите её на пять строк:

1. Работа клиента.
2. Решение, которое он нанимает.
3. Функция решения.
4. Польза функции.
5. Проблема текущего решения.

Если одна и та же фраза попала в несколько строк, значит, границы пока не определены.