Как я работаю

Принципы

Продукт должен решать реальную задачу человека или бизнеса и приносить измеримую пользу. Всё остальное — процессы, технологии, дизайн — служит этому.

Я отвечаю за продукт целиком: за экономику, команду, качество и сроки. Поэтому решения принимаю на данных, а не на мнениях, и стараюсь, чтобы у каждого решения был измеримый критерий успеха.

Сложные вещи делаются маленькими шагами. Большая цель разбивается на проверяемые гипотезы, каждая из которых либо подтверждается, либо закрывается за недели, а не за кварталы.

Исследования и CustDev

Любой продукт начинается с разговоров с людьми, которые будут им пользоваться. Я провожу проблемные интервью сам и учу этому команду: открытые вопросы о прошлом опыте, без презентации решения, с фиксацией дословных цитат.

Для одного сегмента обычно хватает 8–12 интервью, чтобы увидеть повторяющиеся паттерны. Дальше — количественная проверка: опросы, анализ поведения в текущих продуктах, данные поддержки и отзывов.

Результат исследования — не отчёт, а список проблем с оценкой частоты и боли, сегментация пользователей и явные «не делаем», которые экономят месяцы разработки.

• Проблемные интервью по сценарию, 8–12 на сегмент
• Количественная проверка: опросы, аналитика, обращения в поддержку
• Карта проблем с оценкой частоты и боли
• Список того, чего мы делать не будем

От потребностей к историям и работам

Потребности я описываю через Jobs to be Done: какую «работу» человек нанимает продукт выполнить, в какой ситуации и какого результата ждёт. Это помогает не зацикливаться на фичах конкурентов и видеть альтернативы, которыми пользуются сейчас.

Для команды разработки работы превращаются в user stories с понятным «кто, что, зачем» и критериями приёмки. Для сложных системных сценариев, например роуминга зарядных сессий между операторами, пишу use cases: участники, предусловия, основной и альтернативные потоки, ошибки.

Так у каждой задачи есть прослеживаемость: от цитаты из интервью до строки в бэклоге и теста.

Карты пути пользователя

CJM я строю не как красивую схему для презентации, а как рабочий инструмент. Для каждого шага: что человек делает, что видит, что чувствует, какие данные и системы участвуют, где он теряется или уходит.

Карта строится на данных интервью и аналитики, а не на предположениях команды. Самые болезненные точки становятся приоритетами бэклога. Для «Я — Атом» так была найдена главная проблема рынка: водитель держал пять приложений разных операторов, и единый вход в зарядную сессию стал основой продукта.

Для B2B и клинических сценариев рисую отдельные карты для каждой роли: администратор, специалист, участник. Один продукт, разные пути.

Discovery

Discovery — это постоянный процесс, а не этап перед разработкой. Каждую неделю команда проверяет несколько гипотез: прототипы, интервью, A/B-тесты, анализ данных. Гипотеза формулируется так, чтобы её можно было опровергнуть, с метрикой и сроком.

Решения проходят четыре проверки: нужно ли это людям, смогут ли они этим пользоваться, можем ли мы это построить и работает ли это как бизнес. Если хоть один ответ «нет», гипотеза закрывается до того, как на неё потрачены деньги.

В Discovery участвуют продакт, дизайнер и ведущий инженер вместе. Инженер на этом этапе нужен, чтобы сразу видеть технические ограничения и возможности, которых не видит продакт.

Delivery

Delivery выстраиваю вокруг коротких циклов и непрерывной поставки. Небольшие инкременты уходят в прод часто, под фича-флагами, с мониторингом и возможностью откатить за минуты. Релиз раз в квартал — это риск, а не праздник.

Обязательный минимум: код-ревью, автоматические тесты на критичных путях, стейджинг с данными, близкими к боевым, и чек-лист готовности к продакшену. В Нейрокоде к этому добавлен мониторинг с алертами, потому что устройства работают у людей 24/7.

Метрики процесса, на которые я смотрю: время от идеи до прода, частота релизов, доля откатов, время восстановления после инцидента. Они честнее, чем выполненные стори-поинты.

Как появляются сильные решения

Посредственный продукт получается, когда команда копирует рынок и закрывает бэклог. Сильный — когда она понимает задачу глубже конкурентов и готова отказаться от очевидных решений.

Я ищу места, где пользователь мирится с неудобством, потому что «так у всех». Plug&Charge в Атоме появился из простого вопроса: почему водитель вообще должен что-то нажимать, чтобы начать зарядку, если автомобиль и станция могут договориться сами. Из этого вопроса вырос патент и ключевая функция продукта.

В Нейрокоде такой точкой стала прозрачность: вместо «чёрного ящика» с оценкой состояния мы показали формулы метрик и сырой сигнал. Это сделало платформу интересной бизнесу и науке, а не только любителям гаджетов.

Для этого нужны три вещи: время команды на исследование без немедленного результата, право на ошибку и привычка проверять смелые идеи дёшево, прежде чем вкладываться по-настоящему.

Дизайн-подход

Дизайн начинается не с экранов, а с языка продукта: как называются сущности, какие состояния у объектов, что пользователь должен понимать без инструкции. Этот словарь фиксируется до макетов и используется и в интерфейсе, и в коде, и в документации.

Дальше — дизайн-система: токены, компоненты, правила отступов и типографики. Один раз хорошо сделанная система экономит недели на каждом новом экране и держит продукт целостным, когда над ним работают несколько команд.

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

Архитектура платформ

Платформа отличается от продукта тем, что на ней должны строиться другие продукты, в том числе чужие. Поэтому архитектуру я закладываю с явными границами доменов, стабильными контрактами API и отдельными контурами для разных клиентов: B2C, B2B, партнёры, клиники.

Принципы, которых держусь: единый источник данных для каждой сущности, события вместо прямых вызовов там, где нужна отказоустойчивость, обратная совместимость API, наблюдаемость с первого дня. Стандарты, где они есть, например OCPI для роуминга зарядных станций, предпочитаю собственным протоколам.

Архитектурные решения фиксируются короткими записями: контекст, варианты, выбор и последствия. Через год это единственный способ понять, почему система устроена именно так.

От бизнес-требований к техническим

Бизнес формулирует цель и ограничения: сколько, когда, с какой экономикой. Моя задача — перевести это в требования, которые инженер может оценить и реализовать, не потеряв смысл.

Путь выглядит так: цель бизнеса, затем сценарии пользователей, затем функциональные требования с критериями приёмки, затем нефункциональные: нагрузка, безопасность, доступность, сроки хранения данных. Для каждого требования понятно, из какой цели оно выросло.

Процессы, в которых участвуют несколько ролей и систем, описываю в BPMN: роли на дорожках, события, шлюзы, точки интеграции. Такая схема одинаково читается и бизнесом, и разработчиками, и из неё напрямую получаются состояния объектов и API.

• Цель и ограничения бизнеса
• Сценарии пользователей и use cases
• Функциональные требования с критериями приёмки
• Нефункциональные требования
• BPMN для межролевых и межсистемных процессов

ИИ в работе директора по продукту

С 2025 года ИИ встроен в каждый этап моей продуктовой работы: от разбора интервью до выкладки на стенд. Это не эксперименты ради моды, а конкретные места, где раньше уходили дни, а теперь часы.

Аналитика. Транскрипты интервью, обращения в поддержку, отзывы в сторах и логи поведения стекаются в одно хранилище, и модель раз в неделю собирает по ним сводку: повторяющиеся проблемы, частота, цитаты, сдвиги по сравнению с прошлой неделей. Продакт больше не читает триста тикетов руками, он читает одну страницу и проверяет выборочно. Метрики продукта запрашиваются на обычном языке: «удержание по когортам за квартал в разрезе каналов» превращается в SQL и график за минуту, а не в задачу аналитику на два дня.

Discovery. На входе в гипотезу модель собирает контекст: что говорили пользователи по этой теме, что делают конкуренты, какие ограничения уже зафиксированы в архитектуре. По итогам интервью черновики JTBD, user stories и критериев приёмки генерируются из транскрипта и правятся человеком, а не пишутся с нуля. Прототип интерфейса для коридорного теста собирается в Figma и в коде за часы. В результате за неделю команда проверяет больше гипотез, а стоимость проверки одной идеи упала в разы.

Время до рынка. Инженерная часть идёт в режиме агентно-ассистированной разработки: Claude Code получает задачу с контекстом репозитория, пишет код, прогоняет тесты и выкатывает на стенд; Codex и модели GPT дают второе мнение и независимое ревью. Типовые задачи — экраны, интеграции, миграции, инфраструктура — уходят на стенд в тот же день. Цикл от описанной задачи до проверяемого результата сократился с дней до часов, а сайт, на котором вы это читаете, собран и выложен в таком режиме за один рабочий день.

Тестирование. Агент пишет автотесты на критичные пути сразу вместе с функцией, прогоняет сценарии в браузере, снимает скриншоты экранов в нужных размерах и темах, разбирает логи инцидентов и предлагает причину. Ручное регрессионное тестирование, которое занимало день перед релизом, превратилось в прогон за минуты и выборочную проверку человеком.

Правила. Человек ставит задачу, задаёт границы, читает результат и отвечает за него. Любое изменение проходит ревью, прод деплоится только через git и пайплайн, агент не имеет доступа к боевым данным и деньгам, а решения по архитектуре, безопасности и приоритетам остаются за людьми. Выводы модели по данным всегда проверяются на исходниках, прежде чем попасть в решение.

Что ещё полезно продакту: быстрые конкурентные обзоры и разбор чужих продуктов по скриншотам, черновики спецификаций, презентаций и писем партнёрам, перевод и локализация, генерация изображений и ИИ-инструменты Figma для визуальных вариантов, подготовка к встречам по протоколам прошлых, суммаризация длинных тредов и документов. Общее правило одно: ИИ делает черновик и рутину, человек принимает решение.

• Сводка по интервью, обращениям и отзывам раз в неделю вместо ручного чтения
• Метрики продукта по запросу на обычном языке
• JTBD, user stories и критерии приёмки — черновик из транскрипта
• Прототип для теста — за часы, в Figma и в коде
• Задача → стенд за часы вместо дней (Claude Code, Codex, GPT)
• Автотесты, браузерные прогоны и разбор инцидентов — силами агента
• Ревью, git-пайплайн, без доступа к боевым данным

Команда и менторство

Я собираю команды под задачу, а не под оргструктуру: продакт, дизайнер и инженеры работают вместе с первого интервью до релиза. Нанимаю людей, которые задают вопросы и способны сказать «это не сработает».

Руководителей продукта и разработки внутри команд я развиваю через регулярные разборы решений: что было известно, какие были варианты, почему выбран этот. Это быстрее любых курсов.

Отдельно занимаюсь менторством продакт-менеджеров и технических руководителей вне своих компаний и читаю лекции в образовательных программах. Если нужна помощь с продуктом, стратегией или командой, напишите.