Зачем нужен этот эксперимент
Проверяем не то, нравится ли людям идея функции, а готовы ли они реально воспользоваться ею, изменить поведение, потратить время или деньги. Запрос клиента на функцию часто является только его предложением решения; настоящая задача может оказаться другой.
Здесь эксперимент должен уменьшать неопределённость до того, как компания вложит много денег в разработку, новый рынок или операционную инфраструктуру.
Когда использовать
Эксперимент нужен перед дорогой разработкой, когда приоритет функции вызывает спор, когда просьба поступает от небольшой группы клиентов или когда непонятно, будет ли функция использоваться регулярно.
Когда эксперимент не нужен
Не стоит проводить такую проверку, если изменение необходимо по закону, безопасности или для устранения критической ошибки. Там решение определяется не спросом.
Как устроена причинно-следственная логика
Как подготовиться
- Переведите просьбу о функции в клиентскую задачу.
- Определите самое дешёвое действие, которое покажет реальный интерес.
- Решите, можно ли временно выполнить результат вручную.
- Заранее определите, какой уровень поведения будет достаточным для следующей инвестиции.
Как провести эксперимент
- Покажите проверку только подходящей группе пользователей.
- Честно сообщайте, если функция ещё не готова; не создавайте ложного ожидания.
- Собирайте причины использования и отказа.
- После первого действия проверяйте повторное использование и ценность результата.
Какие показатели смотреть
Практический пример
Например, пользователи системы учёта клиентов часто просят автоматическое сравнение звонков менеджеров. Команда может потратить три месяца на разработку. Вместо этого она добавляет в интерфейс пункт «Сравнить звонки», а после нажатия предлагает оставить несколько записей. Аналитик вручную готовит сравнение для первых пользователей. Из ста подходящих компаний кнопку нажимают двадцать, данные присылают восемь, повторно просят анализ пять. Это гораздо сильнее списка голосов «за» в опросе.
Как принять решение после проверки
Типичные ошибки
- Принимать количество голосов в опросе за доказательство использования.
- Создавать обманную кнопку без объяснения, что функция ещё проверяется.
- Не проверять повторное использование.
- Разрабатывать запрос одного крупного клиента как универсальную функцию.
- Считать положительный отзыв доказательством спроса.
- Инвестировать в полную разработку до реального обязательства клиента.
- Менять правило успеха уже после получения результата.
- Считать отрицательный результат бесполезным: если он уменьшил неопределённость, эксперимент уже создал ценность.