Я сформулировал десять работ для «Дожми Продажи». И почти сразу перестал им доверять

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

У «Дожми Продажи» много сценариев:

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

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

Так и произошло.

Появились десять гипотез:

1. Понять, нужно ли вмешиваться в продажи.
2. Найти реальную причину просадки.
3. Проверить выполнение управленческого фокуса.
4. Синхронизировать понимание стандарта продаж.
5. Найти успешные паттерны.
6. Понять, почему сделки останавливаются.
7. Повысить качество управленческих разборов.
8. Быстро обучать менеджеров на реальных примерах.
9. Понять, какие клиенты и потребности двигают сделки.
10. Перейти от анализа к следующему действию.

Список выглядел разумно.

Даже слишком разумно.

Почему список начал вызывать подозрение

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

У нас есть управленческий фокус - появилась работа «проверить управленческий фокус».

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

Есть рекомендации - появилась работа «перейти от анализа к следующему действию».

Есть калибровка - появилась работа «синхронизировать понимание стандарта».

Получился не список работ клиента, а аккуратно переименованная карта продукта.

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

Это не означает, что все формулировки неверны.

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

В одном списке смешались разные люди

Вторая проблема - участники.

Кто выполняет работу «держать продажи под контролем»?

Собственник или коммерческий директор.

Кто хочет синхронизировать критерии?

Возможно, РОП или руководитель контроля качества.

Кто обучает менеджеров?

РОП, тренер или HR-функция.

Кто ищет клиентов и потребности, двигающие сделки?

Маркетинг, продуктовая команда или основатель.

В B2B легко сказать:

Компания хочет улучшить продажи.

Но компания не является одним человеком.

У разных участников:

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

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

Смешались разные уровни графа

Третья проблема - уровень работы.

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

«Найти причину» может включать:

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

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

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

На практике часть из них может оказаться одной цепочкой.

Красивый язык не заменяет поведение

Самая важная проблема - все десять формулировок были придуманы нами.

Они опирались на опыт, встречи, продукт и здравый смысл. Но это всё ещё гипотезы.

Работа начинает получать подтверждение, когда видно:

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

Фраза может звучать идеально и не существовать как важная работа.

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

Но сколько из них:

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

Без такого поведения мы знаем только, что идея звучит хорошо.

Что осталось после первой критики

Из десяти вариантов я оставил три направления для дальнейшего исследования.

Не как найденные работы, а как более высокие гипотезы.

1. Держать продажи под контролем без постоянного погружения в операционку

Возможный контекст:

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

Возможные решения:

• доверять РОПу;
• смотреть CRM;
• проводить планёрки;
• лично слушать звонки;
• нанять QA;
• использовать аналитику.

2. Вернуть продажи к плану, найдя реальную причину просадки

Возможный контекст:

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

Здесь ценность может быть не в самом анализе, а в том, чтобы не потратить ресурсы на исправление ложной причины.

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

Возможный контекст:

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

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

Почему даже этим трём гипотезам пока нельзя доверять

Они звучат лучше, потому что:

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

Но это всё ещё кабинетные формулировки.

Я пока не знаю:

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

Именно поэтому дальше нельзя просто выбрать самую красивую работу и переписать сайт.

Нужно идти в реальные эпизоды.

Чем гипотеза полезна, если ей нельзя доверять

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

Это не так.

Гипотеза помогает:

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

Проблема начинается, когда гипотеза незаметно превращается в вывод.

Поэтому я хочу использовать простой статус:

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

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

Что это меняет в продуктовой работе

Раньше мы могли увидеть запрос на функцию и сразу обсуждать реализацию.

Теперь между запросом и разработкой появляется дополнительный слой вопросов:

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

Это замедляет первый ответ.

Но может сэкономить месяцы разработки.

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

Главная ценность упражнения с десятью работами оказалась не в списке.

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

Я всё ещё считаю три оставшиеся гипотезы полезными.

Но моя задача теперь не защитить их.

Моя задача - попытаться их опровергнуть на реальных разговорах и поведении.

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

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

Затем напротив каждой поставьте четыре пометки:

1. Кто конкретно выполняет эту работу?
2. Это работа, функция, польза или проблема решения?
3. Из каких слов и действий клиента она появилась?
4. Какое другое решение может быть нанято вместо вашего продукта?

Если формулировка существует только потому, что у продукта есть соответствующий модуль, оставьте её гипотезой.