25 февраля 2026 г.
Как выстраивать взаимодействие команд, чтобы продуктовая логика не затерялась между инженерными решениями и ожиданиями бизнеса, рассказывает Иван Чернов, директор по продуктовой стратегии UserGate.
Поиск слабого звена
Если говорить о цепочке «заказчик — разработка — маркетинг», то самый существенный коммуникационный разрыв, как правило, возникает между разработкой и заказчиком. И происходит он чаще всего на этапе обсуждения требований. Каждый участник интерпретирует их через собственную призму восприятия: производитель не всегда понимает нюансы процессов заказчика, а заказчик, в свою очередь, может опускать некоторые детали, причем иногда существенные, считая, что речь идет об очевидных вещах, которые не имеет смысла лишний раз проговаривать. Именно это предположение и становится источником риска. В результате самым опасным местом коммуникационного разрыва оказывается этап формирования требований к продукту. Многое остается недосказанным: что-то вспомнили и вовремя озвучили, а что-то реализовали так, как поняли, — и именно в этот момент ожидания начинают расходиться с реальностью.
Впрочем, расхождения встречаются и в связке «разработка — маркетинг», хотя они обычно действуют на одной стороне и договориться бывает намного проще. Общение инженеров со специалистами по маркетингу накладывает ограничения на понятийную базу и терминологию. В результате иногда допускаются ошибки. Пожалуй, основная — когда отдельные параметры интерпретируются неверно, а потом выносятся на рынок в искаженном виде.
Классический пример — характеристики производительности устройств. Лаборатория предоставляет данные, полученные в идеальных условиях при определенных параметрах, и эти цифры — зачастую очень привлекательные — публикуются в маркетинговых материалах. Однако среда заказчика существенно отличается от лабораторной, и фактические показатели могут оказаться принципиально другими. Так и выходит, что заказчик ориентировался на одни данные, а в реальности получил иные. Подобные ситуации чаще всего возникают именно из-за сбоя, связанного с неверной интерпретацией.
Нужны ли сто лошадей, или Как избежать ловушек
Формально считается, что продуктовый подход — это создание продукта, который соответствует потребностям широкого круга потребителей. Но на практике нередко возникает ситуация, когда компания находит одного якорного заказчика. На первый взгляд может показаться, что продуктовая логика соблюдается: команда собирает требования, проводит интервью, подробно выясняет все нюансы и условия. Однако всё это происходит в рамках одного-единственного клиента.
В результате на выходе получается продукт, который идеально подходит конкретному заказчику, но при этом практически неприменим для рынка в целом. В этом и заключается парадокс: формально всё выслушали, сделали ровно так, как просили, продуктовую логику соблюли, но по факту она полностью нарушена, потому что продукт не масштабируется на широкую аудиторию.
Это одна из самых распространенных ловушек для стартапов и начинающих компаний. Поэтому самый первый и очевидный сигнал того, что ситуация свернула не туда, — это более 80% запросов, исходящих от одного заказчика. Если пропустить этот сигнал, то сбой обнаружится уже позже — когда компания попытается выйти с продуктом к другим заказчикам и обнаружит, что он или не подходит им вовсе, или требует кардинальной переработки. Но даже если удается избежать этой ловушки, риск ошибок остается.
Другая распространенная ловушка связана с тем, как именно производитель и заказчик обсуждают требования. Часто производитель пытается выяснить у заказчика, как тот планирует использовать продукт, вместо того чтобы сосредоточиться на установлении актуальных потребностей. При этом продуктовый подход как раз подсказывает, что о неких гипотетических намерениях спрашивать не стоит. Создавая продукт под воображаемый сценарий будущего, легко прийти к ситуации, когда в результате внешне он будет выглядеть привлекательным, но на практике окажется невостребованным, потому что не соответствует реальному поведению и реальным задачам заказчика или же конечного пользователя.
Поэтому в первую очередь нужно спрашивать у клиента о том, какую задачу он пытается решить, а не о том, что именно нужно сделать в продукте. Типичный пример: заказчик говорит, что десять лет эксплуатирует устройство конкретного производителя и привык действовать определенным образом — зайти в раздел А и нажать кнопку B. И формулирует запрос так: «Сделайте мне раздел А и кнопку B». При этом ему редко задается вопрос о том, какой результат он получает, выполняя эти действия, и какую бизнес-задачу на самом деле решает. В итоге производитель действительно делает соответствующий раздел и добавляет требуемую кнопку, однако это не решает ту глубинную задачу, которая стоит в действительности. Номинально функция реализована, продукт доработан, но бизнес-цели заказчика не достигнуты, потому что этим функционалом уже мало кто пользуется и он не создает достаточной ценности.
Причем дело может быть не только в нежелании увидеть реальную потребность пользователя, но и в неумении сделать это, ведь она далеко не всегда бывает выражена в явной форме. В этой связи часто вспоминают фразу Стива Джобса о том, что пользователь сам не знает, чего он хочет. На российском рынке ее нередко трактуют так, будто производитель должен сам подсказать пользователю, что ему нужно. Но более точный смысл, на мой взгляд, в другом: пользователь действительно не всегда может сформулировать, чего именно он хочет, но он почти всегда понимает, какого результата хочет достичь.
Именно поэтому ключевой принцип правильной продуктовой коммуникации — говорить не о повторении привычных способов достижения цели, а о самой цели. В этом же ключе хорошо звучит известная цитата Генри Форда о том, что если бы он спрашивал своих клиентов, что им нужно, они попросили бы карету со ста лошадьми. Ошибка в коммуникации возникает тогда, когда обсуждают детали условного транспортного средства, а не те цели, ради которых оно будет использоваться.
Не спешите говорить «нет»
Бывает, что ожидания заказчика изначально противоречат техническим ограничениям или продуктовой логике. В зависимости от сути этого противоречия подход производителя будет разным. В первом случае позиция довольно простая: всё, что вписывается в законы физики, в принципе возможно. Если заказчик формулирует запрос, который на первый взгляд кажется технически нереализуемым, не стоит сразу давать отрицательный ответ. Можно взять паузу и провести дополнительные исследования, чтобы понять, какие решения вообще существуют и какими путями можно прийти к нужному результату.
Нередко в процессе выясняется, что заказчик на самом деле имел в виду не конкретное техническое решение, а целевой результат. Или, возвращаясь к цитате Форда, — ему не нужно сто лошадей в повозке, а требуется просто быстрее перемещаться. И тогда задача может быть решена совсем другой технологией. Поэтому не стоит зацикливаться на конкретном способе реализации, на котором настаивает заказчик, — лучше попытаться понять, какого результата он хочет достичь, и предложить альтернативные пути.
Если же запрос противоречит продуктовой логике, ситуация обстоит немного сложнее. Обычно речь идет об эксклюзивной доработке под одного заказчика, которая не нужна рынку в целом и может противоречить текущему продуктовому подходу. Например, рынок давно ушел в сторону сенсорных интерфейсов, а отдельный клиент — зачастую крупный и финансово привлекательный — настаивает на возвращении физической клавиатуры.
В этом случае решение лежит уже в плоскости продуктового управления и экономики. Необходимо оценить, насколько такая доработка оправданна: какую прибыль принесет проект, перекроет ли она затраты на разработку и сопровождение отдельной версии продукта, хватит ли ресурсов на поддержку параллельных решений. Иногда оказывается, что выгоднее сделать функцию для ста небольших заказчиков, чем для одного крупного, а иногда — наоборот.
Универсального рецепта здесь нет. Это всегда прагматичное бизнес-решение, за которое несет ответственность product owner — специально выделенный человек, отвечающий за продукт. Это некий предприниматель внутри компании, который держит в руках всю бизнес-модель продукта и обеспечивает организацию всего процесса.
Как устранить эффект глухого телефона
Как выстраивать коммуникацию так, чтобы требования заказчика не искажались в процессе разработки? Во-первых, на встречи с заказчиком лучше ходить не в одиночку, а минимум вдвоем. Когда информацию воспринимают два человека, вероятность искажения требований из-за субъективной интерпретации одного слушателя заметно снижается.
Во-вторых, обязательна запись встреч и ее последующая расшифровка. С текстом можно работать позже: возвращаться к формулировкам заказчика, уточнять детали, проверять, не были ли упущены нюансы. Этим может заниматься продукт-менеджер, аналитик или технический специалист — но принципиально, чтобы первоисточник всегда был под рукой и требования не переосмысливались по памяти.
Отдельный значимый момент — умение проводить интервью. Этому следует учиться специально: как правильно задавать вопросы, работать с ответами и делать корректные резюме услышанного. Это помогает уходить от разговоров о гипотетическом будущем и фокусироваться на текущей реальности заказчика. И если всё это объединить в системный подход: ходить на встречи вдвоем, фиксировать разговоры, хранить исходный материал и развивать навыки интервьюирования, — риск искажения требований можно существенно снизить.
Работу над ошибками стоит проводить не только в связке «разработка — заказчик», но и в коммуникации между разработкой и маркетингом. Для оптимизации отношений между ними работают форматы кросс-функционального взаимодействия на самых ранних стадиях создания продукта. Например, мы в компании UserGate используем подход, который в маркетинге часто называют shift left marketing. В классической модели разработчики сначала создают продукт, а затем, по завершении работы, передают его в маркетинговый отдел со словами «теперь продвигайте». Мы сознательно ушли от этой схемы. У нас есть выделенная роль — продуктовый маркетолог, который подключается к процессу разработки на самом начальном этапе.
Этот специалист тесно сотрудничает с разработчиками. Он участвует в общих встречах, погружается в специфику продукта, знакомит команду с рыночной информацией. Это могут быть маркетинговые исследования, анализ конкурентов, изучение рыночных запросов, опросы потенциальных потребителей. Задача — заблаговременно интегрировать рыночную экспертизу в процесс разработки. Такой подход повышает рыночную ценность продукта. А когда маркетинг подключается только на финальной стадии, эффективность взаимодействия резко снижается.
Как прийти к эффективной коммуникации
Так как же, учитывая всё вышесказанное, выстроить эффективную обратную связь между рынком, заказчиком и командой разработки так, чтобы она действительно помогала создавать продукт? Для этого есть несколько известных и хорошо зарекомендовавших себя практик.
Первый формат — это демонстрации прототипов и бета-версий заказчикам. Речь может идти как об индивидуальных показах, так и о групповых сессиях, когда на ранних этапах к обсуждению привлекается несколько клиентов. Им показывают прототип, идею реализации, предполагаемый целевой результат, объясняют, как продукт будет выглядеть и работать. Принципиально важно, что такие демонстрации проводит непосредственно команда разработки и для непосредственных заказчиков — без участия маркетинга, поскольку это не публичные презентации готового продукта, а чисто рабочие форматы. Такой подход хорошо помогает еще и потому, что пользователи чувствуют свою вовлеченность в создание продукта и охотно дают обратную связь. И позитивные, и критические отзывы особенно ценны на ранних стадиях, когда важно понять, какой продукт будет действительно востребован рынком.
Второй эффективный формат — стратегические сессии с ключевыми заказчиками. Здесь в обсуждение вовлечены уже не команды разработки, а product owner’ы и управленцы. На таких сессиях обсуждается широкий контекст: как живет заказчик, какие задачи и цели перед ним стоят, какие стратегические горизонты он видит — на пять или даже на десять лет вперед. В процессе совместно генерируются идеи, которые впоследствии могут лечь в основу развития существующих продуктов или стать отправной точкой для запуска новых. Ключевая ценность заключается в прямой коммуникации, без посредников между заказчиком и производителем, которая существенно упрощает поиск релевантных идей и направлений развития.
Третий путь — системная работа с рынком через исследования. Для этого существует отдельное направление стратегической аналитики, которое занимается запуском онлайн-опросов, анкетированием, проведением интервью с действующими и потенциальными пользователями. Не обязательно проводить такие исследования от имени компании. Респонденты могут даже не знать, кто именно стоит за опросом. Это позволяет получить более чистые данные и лучше понять реальную картину рынка. Такая обратная связь носит односторонний характер, но дает ценную информацию для управленческих и продуктовых решений.
И, пожалуй, самое важное — умение слушать и слышать клиента. Сегодня много говорят о клиентоориентированности, и у этого понятия есть разные трактовки. Но в основе всегда лежит одно и то же: понимание, что действительно волнует клиента, какие у него боли, ожидания и цели. В условиях высокой конкуренции на большинстве рынков это становится фактически средством выживания. Всё остальное: скорость получения обратной связи, проверка продуктовых гипотез, корректировка решений, — уже следствие. Поэтому прежде всего научитесь слушать и слышать своего клиента, заложив этот приоритет в фундамент рыночной стратегии компании.
Источник: Иван Чернов, директор по продуктовой стратегии UserGate
