Я не превращаю продукт конкурента в техническое задание

Когда клиент говорит: «Сделайте как у конкурента», я не воспринимаю это как техническое задание. Это скорее полезный сигнал: человек увидел знакомый способ решить задачу, но ещё не сформулировал, какую именно работу хочет сделать лучше.

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

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

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

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

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

Четыре вопроса вместо копирования

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

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

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

Сравнивать можно, переносить автоматически — нет

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

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

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

Проверьте цену похожести

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

Перед решением я бы проверил:

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

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

Как принять решение спокойно

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

Тогда команда не пытается доказать, что чужой продукт плохой или хороший. Она отвечает на более полезный вопрос: поможет ли нам этот принцип решить конкретную задачу без лишней сложности? Если да — можно брать идею и делать её своей. Если нет — лучше сохранить время для того, что действительно меняет рабочий день клиента.