Как воспринимаешь требования в продукте, которые кажутся бессмысленными?

Мой подход основан на предположении, что у бизнеса или продукт-менеджера есть контекст, который мне не виден. Вместо сопротивления я начинаю с исследования:

1. Задаю уточняющие вопросы, чтобы понять корневую причину. Например: "Это требование связано с конкретным юридическим регулированием?", "Какая пользовательская проблема решается этим изменением?", "Есть ли данные A/B-тестов, которые это подтверждают?"
2. Предлагаю альтернативные, с моей точки зрения, более эффективные решения, если вижу в требовании техническую неоптимальность. Я оформляю это как предложение, а не критику: "Я понял цель — увеличить конверсию на шаге X. Мы можем реализовать это через изменение UI, как в ТЗ, а можем рассмотреть вариант Y, который, по данным из проекта Z, дал +15%. Что думаете?"
3. Если после обсуждения требование остается, но его ценность для меня все еще неочевидна, я реализую его максимально чисто и поддерживаемо. Я документирую в коде или в PR ссылку на тикет/решение, чтобы в будунии было понятно, почему сделано именно так.

Пример из опыта: На одном из проектов было требование добавлять в JSON-ответ API поле с текущим временем в формате HH:MM:SS, хотя временная метка timestamp уже была. После обсуждения выяснилось, что это нужно для устаревшей системы партнера, которая парсила ответ «как есть» и не умела работать с UNIX-временем. Понимание контекста превратило «бессмысленное» требование в необходимое бизнес-ограничение.