Продукт в IT все реже измеряется количеством функций и все чаще качеством решений, которые стоят за ними. В этой логике роль product manager выходит за рамки управления бэклогом и становится точкой ответственности за устойчивость, безопасность и долгосрочную ценность цифровых решений.
Илья Ковалов — специалист с многолетним опытом в QA, управлении качеством и работе с международными продуктами, говорит о том, как инженерное мышление трансформируется в продуктовый подход и почему именно он сегодня определяет успех сложных IT-систем.
Вы все чаще говорите о себе не только как о QA или лидере, но и как о человеке с продуктовым мышлением. В какой момент вы начали смотреть на проекты именно как на продукты, а не как на набор задач?
— Это произошло тогда, когда я начал замечать повторяющийся сценарий: технически все реализовано корректно, команда отработала профессионально, но продукт не приносит ожидаемого эффекта. Пользователь не возвращается, бизнес не растет, система требует постоянных доработок.
В этот момент ты понимаешь, что проблема не в реализации, а в исходных решениях. В том, какие гипотезы были заложены, какие метрики выбраны, как определен успех. С этого момента я перестал смотреть на задачи изолированно. Меня стало интересовать, зачем функция вообще появляется, какую проблему она решает и что произойдет, если ее не будет. Это и есть продуктовый взгляд.
Многие считают, что продукт — это про идеи, а инженерия про реализацию. Насколько это разделение вообще корректно сегодня?
— Оно устарело. В современных цифровых продуктах реализация — это часть идеи. Если решение невозможно поддерживать, масштабировать или объяснить пользователю, значит, идея была слабой.
Продукт — это не концепт на презентации, а совокупность решений: технических, интерфейсных, бизнесовых. Инженер, который не понимает продукт, реализует требования формально. Продуктовый специалист без технического понимания создает ожидания, которые невозможно выполнить. Поэтому сейчас выигрывают те команды, где эти роли не противопоставляются, а дополняют друг друга.
Как вы определяете, что продукту действительно нужна новая функция, а не просто "кажется, что было бы хорошо"?
— Я всегда задаю себе несколько вопросов. Что изменится для пользователя, если этой функции не будет? Какое поведение мы хотим усилить или изменить? И самое важное, как мы поймем, что решение сработало.
Если на эти вопросы нет четкого ответа, значит, функция не готова к реализации. Очень часто команды делают вещи "на всякий случай", чтобы закрыть гипотетический запрос. В итоге продукт усложняется, а ценность размывается. Продуктовая зрелость как раз и заключается в умении отказываться.
Вы работали с продуктами в медицинской сфере, e-commerce и сервисных платформах. Где цена продуктовой ошибки выше всего?
— В медицинских и инфраструктурных системах. Там ошибка не просто снижает метрику, она может повлиять на реальные процессы и людей, но парадокс в том, что в consumer-продуктах цена ошибки тоже высока, просто она выражается иначе. Пользователь уходит молча. Он не пишет баг-репорт, не объясняет, что пошло не так. Он просто перестает пользоваться продуктом.
Поэтому продуктовая ответственность существует везде. Разница лишь в том, как быстро ты видишь последствия.
Какую роль, на ваш взгляд, должен играть QA в продуктовой команде сегодня?
— QA давно перестал быть финальной точкой проверки. В зрелых командах это роль, которая влияет на формирование продукта еще до начала разработки. QA-инженер видит слабые места логики, потенциальные сценарии отказа, неочевидные пользовательские пути. Если этот опыт использовать на этапе обсуждения требований, продукт становится устойчивее.
Когда QA включен в продуктовую дискуссию, количество дорогих исправлений на поздних этапах резко снижается. Это вопрос не контроля, а участия.
Вы упоминали, что работаете над e-commerce-проектами в США. Как продуктовый подход проявляется там?
— В e-commerce очень хорошо видно, насколько продукт зависит от мелочей. Скорость загрузки, прозрачность логистики, доверие к оплате, простота возврата.
С продуктовой точки зрения здесь важно не просто продать, а выстроить путь пользователя так, чтобы он не испытывал напряжения. Большинство решений, которые мы принимаем, направлены не на увеличение функциональности, а на снижение трения. Иногда убрать шаг — важнее, чем добавить новый.
Как вы относитесь к метрикам? Может ли продукт "утонуть" в аналитике?
— Может, если метрики не связаны с реальностью. Сами по себе цифры ничего не значат. Важно понимать, какие решения за ними стоят. Я сторонник ограниченного набора показателей, которые действительно отражают здоровье продукта. Если команда смотрит на десятки графиков, но не может объяснить, почему пользователь ведет себя именно так, аналитика превращается в иллюзию контроля. Метрики должны помогать принимать решения, а не создавать видимость управления.
Вы много работаете с международными командами. Отличается ли продуктовая культура в США от других рынков?
— Отличается акцентами. В США больше внимания уделяется ответственности за результат. Не за процесс, не за усилия, а именно за эффект. Если решение не сработало, это не трагедия, но от тебя ждут анализа и корректировки. Продукт — это гипотеза, а не догма. Такая культура снижает страх ошибок, но повышает требования к мышлению. Ты должен понимать, почему принимаешь то или иное решение.
Какое продуктовое решение, принятое вами, далось сложнее всего?
— Самые сложные решения — это отказ от того, во что уже вложено много ресурсов. Когда команда привязалась к функции, когда на нее потрачено время и деньги, но становится очевидно, что она не работает. В такие моменты важно уметь отделять усилия от результата. Продукт не обязан "отбивать" каждую идею. Он обязан быть целостным и полезным. Это непросто эмоционально, но необходимо для роста.
Если смотреть на будущее, какой станет роль product manager в IT через несколько лет?
— Она станет более технической и более ответственной. Product manager будет не просто формировать backlog, а управлять сложной системой решений, где участвуют люди, технологии и автоматизированные инструменты, включая AI.
Выиграют те, кто умеет говорить на языке инженеров, понимать бизнес и чувствовать пользователя одновременно. Это сложная комбинация, но именно она формирует продукты, которые остаются на рынке надолго.