«У конкурента есть — давайте и нам» — этого недостаточно
В обсуждениях проектов я часто слышу такую фразу:
«У конкурента это есть. Давайте и нам сделаем.»
Иногда это действительно может подсказать направление.
Но само по себе это ещё не требование.
Чаще всего это просто наблюдение.
То, что в другом продукте есть определённая кнопка, сценарий или отчёт, не означает, что то же самое можно добавить в нашу систему за те же деньги и в тех же границах.
Мир конкурента
Feature, как он у них выглядит
- Под их сегмент пользователей
- Технический долг, который они уже приняли
- Интеграции, которые у них уже есть
Итог: это вписано в их бизнес-модель
Наша реальность
Риск прямого переноса
- Другие пользовательские привычки
- Риск отвлечь основной сценарий
- Скрытые технические и операционные затраты
Итог: сложность без их контекста
Feature конкурента появился в его собственном контексте
Каждый продукт развивается со своими компромиссами:
- на каких клиентов он ориентирован
- какой процесс он упростил
- какую сложность сознательно оставил за пределами продукта
- какой технический долг он принял
Даже если feature выглядит простым на экране, за ним часто стоят годы накопленных правил, исключений и интеграций.
Просто перенести его к себе со словами «давайте и нам сделаем» — часто означает скопировать не результат, а только внешний вид.
Сначала я задаю несколько вопросов
Когда появляется ссылка на решение конкурента, я сначала смотрю на следующее:
- Какую конкретную проблему этот feature решает у конкурента?
- Есть ли у нас действительно такая же проблема?
- Есть ли у нас такой же пользователь, такая же частота использования и такой же уровень риска?
- Усилит ли это основной сценарий или, наоборот, отвлечёт от него?
- Если мы этого не сделаем, мы действительно потеряем клиента — или просто в списке возможностей будет отсутствовать ещё одна строка?
Если единственный ответ — «у конкурента это есть», этого недостаточно, чтобы начинать работу.
За внешней простотой часто скрывается настоящая цена
Добавить на экран ещё один вариант или статус может выглядеть простой задачей.
Но за этим часто стоят:
- новые бизнес-правила
- совместимость с существующими данными
- влияние на другие сценарии
- дополнительная нагрузка на поддержку и объяснение
- ситуации, в которых то, что выглядит одинаково для всех, на деле требует разных вариантов поведения
Поэтому вопрос не в том:
«Сколько часов займёт это написать?»
Главный вопрос:
«Меняет ли это границы и обещание нашего продукта?»
Над водой — что видно на экране
Несколько UI-элементов, новая кнопка или простой выбор
Под водой — что должна выдержать система
- Новые бизнес-правила и исключения
- Совместимость со старыми данными
- Влияние на пересекающиеся сценарии
- Нагрузка на поддержку, документацию и объяснения
Внешняя простота может скрывать настоящие компромиссы.
Иногда правильный ответ — «не сейчас»
Следить за конкурентами — не значит избегать конкуренции.
Но добавлять в систему всё, что мы у них увидели, — тоже не стратегия.
Для меня более здоровый подход выглядит так:
- сначала понять собственные узкие места и потребности своих пользователей
- рассматривать идею, пришедшую от конкурента, не как пункт чек-листа, а как проблему, которую нужно проверить
- если решение действительно нужно — адаптировать его под наш контекст
- если это просто «было бы неплохо» — отправить в backlog и сохранить фокус основной версии
Потому что когда продукт превращается в копию интерфейса конкурента, мы часто наследуем не его сильные стороны, а его сложность.
Итог
«У конкурента это есть» — может быть наблюдением.
Но хорошее требование звучит иначе:
«У нас есть такая проблема. Это решение её закрывает вот так. Поэтому оно нужно нам сейчас.»
Для меня именно здесь начинается инженерия — не с копирования кнопки из другого продукта, а с правильного решения в контексте собственного продукта.