Как «слить» бюджет заказчика на проверку гипотезы

Как-то я предложил своему клиенту протестировать новый канал продаж и разместиться на площадке объявлений «Авито». Для этого требовалась работа программиста: выгрузка товаров и настройка. Мы завели на сервис небольшую сумму ($50), программист не довел задачу до конца. Деньги на площадке остались неиспользованными и, по сути, сгорели. Через некоторое время ситуация повторилась. Суммарно потеряли около $100. Эксперимент провалился, даже не начавшись. С точки зрения бюджета проекта это мелочь. С точки зрения отношений это оказалось событием, после которого слово «тест» стало означать для заказчика «слив денег». В этой статье разберу, почему провал приводит к потере доверия со стороны клиента, и как исполнителю вернуть право предлагать новые гипотезы для проверки.

Когда подрядчик завалил эксперимент

Ни один финансовый показатель проекта не дрогнул от таких убытков. Но клиент это видел дважды. У него сформировалось наблюдение: когда маркетолог предлагает попробовать что-то новое, деньги уходят, а результата нет. Одно такое наблюдение – случайность, два подряд – уже правило, которое запоминается. Дальше начинается неприятная механика. Каждый следующий разговор про эксперимент проходит через этот фильтр. Клиент не говорит «нет», он говорит «а давай пока не будем» и «давай сначала выжмем то, что есть». Формально он не запрещает. Фактически вы перестаете пробовать.

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

Ошибки тестирования гипотез

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

  • Я не указал заранее, что считается успехом и что провалом. Тест без критерия успеха невозможно закрыть красиво. Если бы мы договорились «пробуем, вкладываем столько-то, смотрим на количество обращений, если меньше стольких, закрываем», то итог был бы не «деньги пропали», а «гипотеза не подтвердилась, закрыли по плану».
  • Я не проговорил, что часть тестов обязана проваливаться. Это очевидно для меня и совершенно не очевидно для человека, который платит. В его картине мира специалист предлагает то, в чем уверен. Если специалист не сказал заранее, что проверяет неуверенное, любой провал читается как ошибка.
  • Я не отчитался по итогу. Тест просто затих. Не было письма, где сказано, что мы попробовали, вот что помешало, вот вывод. Молчание после неудачи закрепляет ее сильнее, чем сама неудача.

Почему заказчики экономят на тестах

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

Как договариваться с клиентом о тестовом размещении

  • Сумму затрат на эксперимент называть вслух и заранее. Не «попробуем», а «на проверку уходит Х, это потолок, больше без нового разговора не потратим».
  • Обсуждать критерии успеха и закрытия. Два числа. Если достигли первого, масштабировать. Если не достигли второго к дате N, выключаем.
  • Проговорить долю провалов. Формулировка простая: из пяти проверок обычно взлетает одна, и деньги на пять – это цена, чтобы найти одну.
  • Тест не зависит от одного исполнителя. Если для проверки нужен внешний специалист, сначала проверить гипотезу самым дешевым способом без него.
  • Обратная связь по результатам теста в любом случае. Особенно, если результат нулевой. Три абзаца: что делали, что помешало, что из этого следует.
  • Вести общий счет по тестам. Составить одну таблицу за год: сколько проверок, сколько потрачено суммарно, что взлетело и сколько принесло. Один взлетевший тест обычно перекрывает все провальные, и это видно только в таком виде.

Как восстановить доверие заказчика после провала

Если клиент разочаровался, спорить с ним бесполезно. Работает только серия маленьких выигранных проверок. Берете самое дешевое, что можно проверить своими руками без подрядчиков и почти без бюджета. Тестируете и отчитываетесь коротко и с цифрами. Повторяете три-четыре раза. После этого разговор про тест с настоящим бюджетом снова становится возможным.

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

Выводы

Можно возразить, что:

  • «$50 – не сумма, клиент не может всерьез на это опереться». Может, потому что в его голове запоминается не размер потери, а ее характер. Две потери одного типа подряд создают шаблон независимо от суммы.
  • «Тесты и должны проваливаться, это же тесты». Верно, но только если это сказано до эксперимента, а не после. Сказанное после звучит как оправдание.
  • «Виноват программист». Формально – да. Но исполнителя выбирал я, значит, риск подрядчика – это тоже моя зона.

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

Также читайте:

Расскажите коллегам:
Комментарии

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

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

«Тесты и должны проваливаться, это же тесты».

Как говорится - " отрицательный результат - тоже результат"

Важно при каком уровне доверия начинается тестирование гипотезы заказчика. Если уровень доверия, к исполнителю  низкий- даже потеря  50 $ будет воспринимается заказчиком как  проигрыш. И любые аргументы при этом будут мало убедительны. Необходимо в  проектах шаг за шагом наращивать свою компетентность, повышая уровень доверия исполнителя. В том, числе предварительным обсуждением договорённостей, подведением итогов, выводами и новыми  предложениями.

Николай Сибирев пишет:

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

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

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

Николай Сычев пишет:

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

Тонко :)

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии