В девятнадцатом эпизоде подкаста мы поговорили с Егором Петровым, CPO группы компаний M.Video-Эльдорадо, о проверке гипотез, инструментах оценки и работе с ожиданиями стейкхолдеров. Ниже — самое полезное из разговора.
Кто такой Егор Петров
Путь Егора к продуктовой роли начался не в IT, а в МЧС — он 11 лет работал в пожарной охране, где быстро понял, как критична эффективность процессов. Именно там он впервые столкнулся с лин-практиками: «В горящей квартире у тебя нет времени на теорию — нужно действовать быстро и чётко».
Позже он разработал KPI-систему для оценки пожарно-спасательных частей и начал погружаться в бизнес-аналитику. Через консалтинг и маркетинг попал в M.Video-Эльдорадо, где отвечал за интеграцию HR-систем и обучение персонала после слияния компаний. Постепенно пришёл к управлению продуктовыми командами — сначала в HRTech, а с недавнего времени — в финансовом блоке.
Как устроена проверка гипотез в HRTech и финансах
HRTech: поток гипотез и три уровня проверки
В HRTech гипотезы часто поступают не от продуктов, а от бизнес-заказчиков и HR-экспертов — их влияние на команду и продукт велико. Это создает вызов: как выбрать из потока внешних идей те, что действительно принесут ценность?
В команде Егора применяются три основных подхода:
- A/B-тесты. Работают, но с ограничениями. В офлайне (20 тыс. продавцов, 1000+ магазинов) сложно подобрать сопоставимые группы и достичь статистической значимости.
- Экспертная оценка. Применяется, когда A/B невозможен или гипотеза опирается на уникальный контекст компании.
- Количественные и качественные исследования. Интервью, частотки, опросы — всё, чтобы уточнить потребности и ожидания.
Финансовый блок: комитет экспертов и confidence-оценка
Здесь подход другой: 60–70% гипотез поступает от партнёров (например, B2B Center). Далее продуктовые команды валидируют идеи через:
- глубинные интервью,
- количественные опросы,
- прототипирование и маркетинг.
Каждая гипотеза проходит через фильтр: насколько она соответствует целям и метрикам продукта? Итог — формирование бэклога, в котором каждая идея имеет «вес» по уверенности (confidence) в её ценности и потенциальном результате.
Как команда принимает решения: что делаем, что позже, а что — никогда
Ключевой инструмент — система метрик. Продукт описывается в разрезе:
- краткосрочных (на месяц),
- среднесрочных (квартал–полгода),
- и стратегических (1–5 лет) целей.
Гипотеза оценивается по влиянию на эти уровни. Даже если инициатор идеи — важный стейкхолдер, гипотеза не попадёт в разработку, если не проходит по метрикам. Она может быть «на холде», пока не появится подтверждение ценности.
Работа со стейкхолдерами: три уровня влияния
Чтобы снизить влияние «силы должности» и повысить прозрачность, в команде ввели модель с тремя уровнями управления:
- Стратегический уровень (стейкхолдеры) — определяют целевые метрики, рынки, аудитории и P&L.
- Операционный уровень (продукт-менеджер) — трансформирует стратегию в тактику, определяет продуктовую логику, бэклог.
- Тактический уровень (команда) — реализация задач, формирование спринтов.
Стейкхолдеры могут видеть всё, но не влияют напрямую на решение о том, что попадает в спринт. Это защищает команду от микроменеджмента и помогает сфокусироваться на реальной ценности.
Лидерство через системность: как построить управление продуктом на трёх уровнях
CPO «М.Видео-Эльдорадо», делится опытом трансформации командной работы и внедрения трёхуровневого подхода в управлении продуктами. Этот путь начался с выгорания команды и нестабильного бэклога, а привёл к осознанной структуре, в которой каждый понимает, за что отвечает — и, главное, зачем.
Почему понадобилась новая система
Команда регулярно не выполняла коммиты: бэклог был нестабильным, требования — плавающими, и не было возможности проектировать архитектуру с прицелом на будущее. Это вызывало не только организационные сбои, но и эмоциональное выгорание у всех сторон — от разработчиков до стейкхолдеров.
Нужна была структурная рамка, которая обеспечит стабильность, направленность и автономию. Так появилась система из трёх уровней управления: стратегического, операционного и тактического.
«Эта структура не наша выдумка — она активно используется в стратегическом консалтинге и военной теории. За счёт разделения ответственности по уровням появляется вектор движения и фокус у каждого участника».
Как это устроено
- Стратегический уровень — определяет вектор, задаёт персоны (вплоть до фотографии и болей), метрики и цели. Это уровень CPO, бизнеса и ключевых стейкхолдеров.
- Операционный уровень — продуктовые команды и лиды, которые выбирают, как именно идти к цели. Здесь решается, какие гипотезы проверять и какие инструменты использовать.
- Тактический уровень — исполнители, работающие в стабильной среде. Они знают, что делать, и не тратят время на переосмысление глобального направления.
Такой подход разгружает команду: каждый работает в своей предметной области и не «греет океан». А управление превращается в поток с обратной связью — благодаря скрам-ритуалам, ретроспективам и регулярному пересмотру метрик.
Ошибки и уроки: что не сработало
В HR-тех проекте Егор, по его признанию, взял на себя избыточное лидерство — и пытался «спасти» команду через давление. Результат: сопротивление, увольнения и снижение доверия.
«Если продукт не общался с кастомерами хотя бы раз в месяц, я мог дать очень жёсткий фидбэк. Да, потом процессы выстроились, но ценой стали отношения и потерянный социальный капитал».
Тем не менее, спустя время команда вернулась к тем же практикам — уже по собственной инициативе. Они сами стали использовать стори-поинты, работать с Miro, уточнять гипотезы. Рефлексия: чрезмерное давление мешает принятию даже полезных инструментов.
Противоположный подход: как взрастить лидерство в команде
В финтех-проекте стратегия была другой. Вместо давления — наблюдение и выстраивание условий:
- Егор нашёл в команде тех, кто не был доволен, но предлагал решения.
- Обеспечил безопасность: стейкхолдер не мог напрямую требовать фичу, а мог только указать стратегическую метрику.
- Продуктовая команда получала самостоятельность в выборе пути — с защитой от давления сверху.
«Ты не даёшь решения — ты создаёшь условия, где люди сами доходят до нужного. Это и есть настоящая работа CPO, особенно в командах на среднем уровне зрелости».
В результате команда сама построила pipeline от upstream до downstream, интегрировала маркетинг в проверку гипотез, ввела confidence-level оценки, и работала как автономная единица.
Как работать с сопротивлением сверху
Сопротивление — не только в команде, но и среди стейкхолдеров. Здесь сработал кастдев: интервью один на один, выявление боли, языка общения, образа результата и критериев успеха.
«Ты должен говорить на их языке. Если он говорит «итерация», не надо настаивать на «спринте». Это культура, и ты должен в неё встроиться».
Для изменения поведения топов использовалась P&L-логика: показывались метрики, связанные с их идеями, и сравнивались с альтернативами. Инструментами коммуникации стали:
- Бэклог — как отображение приоритетов;
- Система метрик — как способ говорить о влиянии, а не о фичах.
Когда стейкхолдер видит, что его идеи не приносят результата, а альтернатива приносит — он либо перестаёт мешать, либо становится союзником.
Прозрачность, зрелость команд и правильное принятие обязательств
Открытость — не просто хорошая практика, а необходимость, особенно когда вы не попадаете в срок или не достигаете ожидаемого результата. Ключ — не молчать. Как только появляются предпосылки к провалу, важно быть первым, кто сообщает об этом стейкхолдерам. Важно не просто признать проблему, но и предложить объяснение, почему это произошло и что вы будете делать, чтобы этого не повторилось.
Сроки — прозаично, метрики — сложнее
Ошибки в сроках — это, как правило, ошибка в оценке, и здесь всё можно объяснить. А вот ошибки в метриках требуют самокритичного взгляда на методологию. Не стоит манипулировать доверием через «удобные» настройки A/B-тестов. Только честная работа с гипотезами и реальная проверка помогают избежать подмены цели. Особенно сложно с метриками в B2B-продуктах: там и трафик ниже, и собрать статистически значимую выборку тяжело. Здесь важны глубинные интервью, количественные методы и уважение к честным данным.
Открытость и прозрачность — важнейший механизм доверия. Если команда видит, что метрика «плывёт», об этом нужно говорить сразу, а не когда всё уже сгорело.
Социальная сплочённость как опора культуры
Алексей подчёркивает: второй блок разговора — это фактически история о трансформации культуры через работу со стейкхолдерами. Открытость, общий язык и диалог — всё это повышает социальную сплочённость в компании. А высокий уровень доверия снимает бюрократию и позволяет команде сосредоточиться на создании ценности, а не на бесконечных пересчётах P&L до последней копейки.
Пожарные и agile: параллель, которую не ждёшь
Егор проводит мощную аналогию: звено газодымозащитной службы на пожаре работает автономно — по сути, как agile-команда. Им нельзя указывать, как именно тушить. Им дают направление, а дальше — только внутренняя координация. Но команда работает эффективно только при балансе опыта: командир, опытный специалист и замыкающий. Если все — джуны, никто не справится. То же и в IT — перегиб в сторону неопытных специалистов разрушает устойчивость.
Баланс синьоров, мидлов и джунов — это не прихоть, а условие успеха.
Команды с разным уровнем зрелости по-разному воспринимают одни и те же практики. И если команда слишком «зелёная», она может просто не понять, зачем вы внедряете, казалось бы, очевидные инструменты.
Социальная инновация: готовность к новому — тоже навык
Алексей дополняет: синьор — не всегда = гибкость. Бывает, что опытный разработчик говорит «мы так не делаем» — и этим тормозит изменения. Поэтому важен не только баланс опыта, но и готовность к социальной инновации — то есть к новым подходам, новым способам работы, экспериментам. Без этого команда застревает в прошлом.
Команды и гипотезы: если хочешь вовлечённости — делай ставку на участие
Егор делится важным лайфхаком: гипотезы должны приходить не только от продакта или стейкхолдера, но и от самой команды. И даже если гипотеза изначально не их — можно дать команде почувствовать её своей, докрутив идею так, чтобы они сами её сформулировали. Это резко повышает вовлечённость, и гипотеза перестаёт быть задачей сверху, а становится личным вызовом. Когда команда сама дошла до решения, она гораздо сильнее мотивирована довести его до результата.
«Главное — не переусердствовать. Не стоит тащить бэкендера в кастдев, если он пришёл писать код, а не слушать пользователей. Баланс здесь тоже критически важен.»
Точка принятия обязательств: где она и зачем?
Важно понимать, в какой момент команда говорит «да, мы это точно делаем». В их случае точка наступает после бизнес-анализа: есть описание требований, Customer Journey Map и простая модель данных. Команда видит влияние на пользователя и систему — и после этого может брать в работу.
При этом Егор честно признаёт: не все заказчики понимают, где находится эта точка. Это зона ответственности продакта — объяснять, до какого момента идея может быть отменена, а с какого — уже нет. Чем дальше вправо удаётся сместить точку обязательств, тем меньше издержек на отмену, тем выше гибкость и осознанность решений.