Реальный запрос клиента ещё не означает, что продукт выстрелит

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

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

Один просит автоматизировать отчёт. Другой хочет новую интеграцию. Третий объясняет, сколько времени сотрудники тратят на ручную операцию. Четвёртый говорит, что готов пользоваться решением сразу после запуска.

Для digital-агентства это естественный источник продуктовых идей. Мы видели повторяющиеся задачи и могли быстро превращать их в решения.

Но со временем я столкнулся с неприятным фактом:

Реальность запроса ещё не доказывает существование устойчивого спроса.

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

Где ломалась очевидная логика

Привычная цепочка выглядела так:

1. Клиент сталкивается с проблемой.
2. Клиент просит решение.
3. Мы создаём решение.
4. Значит, другие похожие клиенты тоже должны его купить.

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

Из факта, что один клиент попросил решение, не следует, что:

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

Мы могли правильно решить задачу и ошибиться в её масштабе.

Полезно - не значит важно

Одна из самых коварных реакций клиента звучит так:

Да, это полезно.

С ней трудно спорить. Многие функции действительно полезны.

Автоматический отчёт полезнее ручного. Интеграция удобнее копирования. Напоминание лучше забывания. Единая карточка понятнее пяти таблиц.

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

Поэтому вопрос не только в полезности.

Важно понять:

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

Многие наши продукты проигрывали не потому, что были бесполезными. Они проигрывали конкуренцию за внимание.

Клиент может просить функцию, а не продукт

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

Допустим, клиент говорит:

Добавьте выгрузку в таком формате.

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

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

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

Но правильный вопрос находится уровнем выше:

Какого результата он пытался добиться этой выгрузкой и что делал до её появления?

Пока этот слой не раскрыт, мы масштабируем не потребность, а интерфейсную просьбу.

Первая оплата тоже не всегда доказывает рынок

Можно возразить: если клиент заплатил, значит, спрос подтверждён.

Не всегда.

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

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

Продуктовая модель требует другого поведения.

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

Одна заказная разработка подтверждает ценность для конкретного клиента. Она ещё не подтверждает повторяемость.

Как эта ошибка проявляется сейчас

С «Дожми Продажи» мы снова находимся рядом с большим количеством клиентских запросов.

Кто-то хочет сводный отчёт по менеджеру. Кому-то нужна оценка конкретного критерия. Кто-то просит сравнить успешные и неуспешные звонки. Другому важна интеграция с телефонией. Третий хочет рекомендации по следующему шагу.

Каждый такой запрос может быть ценным.

Но теперь я стараюсь не переходить автоматически от фразы клиента к выводу:

Значит, это и есть продукт.

Сначала нужно понять:

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

Это не означает, что нельзя слушать пожелания клиентов.

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

Почему клиент сам может не знать ответ

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

Но человек обычно хорошо знает:

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

При этом он не обязан знать:

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

Когда клиент предлагает функцию, это важный сигнал, но не финальный ответ.

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

Что я хочу проверить на старых продуктах

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

По каждому из них мне интересно восстановить:

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

Возможно, у успешных продуктов запрос был не просто громким, а подкреплённым устойчивым поведением.

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

Возможно, бездействие было слишком дорогим.

А возможно, никакой единой закономерности не найдётся.

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

Практический вопрос

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

Ответьте письменно на четыре вопроса:

1. Что клиент делал до появления решения?
2. Чем он реально жертвовал - деньгами, временем, людьми или вниманием?
3. Кто ещё независимо пытался решить ту же задачу?
4. Что изменилось в поведении клиента после запуска?

Если на эти вопросы нет ответов, возможно, у вас пока подтверждён запрос, но не подтверждён рынок.