«Люди за кодом»: Любовь Смирнова — как управлять продуктом, когда роадмап устаревает раньше, чем ты его допишешь
В рубрике «Люди за кодом» мы уходим от красивых абстракций и показываем, как на самом деле живут и работают люди, стоящие за цифровыми продуктами. Сегодня — Любовь Смирнова, Product Manager в B2B/enterprise‑сегменте (ИБ‑продукты), бывшая инженер телекоммуникационных систем (работала в «Ростелекоме» и Huawei).
Её путь — редкий пример того, как инженерное мышление и привычка к доказательности становятся суперсилой продакта. А ещё — напоминание, что профессия часто находит тебя сама, если ты не боишься брать на себя «чужие» задачи.
Как объяснить роль PM человеку не из ИТ: метафора ресторана
Люба не пытается впечатлить терминами. Её любимая аналогия — ресторан:
- Повара — разработчики (они готовят).
- Дизайнер интерьера — UX‑дизайнер (делает красиво).
- Кассир — продажи.
- Владелец ресторана — менеджер продукта: он решает, что будет в меню, для кого этот ресторан, почему гости должны прийти именно сюда и как сделать так, чтобы бизнес не прогорел.
«Менеджер продукта отвечает за то, чтобы команда делала правильные вещи, а не просто делала вещи правильно. Разница огромная: можно идеально построить дорогу, которая никуда не ведёт»
От альтернативной энергетики к продуктовому мышлению
До того как стать продактом, Люба занималась альтернативной энергетикой: придумывала установки для генерации энергии, исследовала, кто и зачем будет ими пользоваться, оценивала экономическую целесообразность. Тогда она не знала, что это и есть продуктовый подход.
«Я не останавливалась на „о, эта штука классная, делаем!“. Я сразу шла дальше: кто будет пользоваться, какую проблему решит, сколько человек готов платить. Это и были первые продуктовые гипотезы».
Переход в ИТ был естественным: работая инженером и проектировщиком, Люба всё чаще брала на себя задачи вне технической роли — сбор обратной связи, исследование потребностей, управление проектами. Так она и узнала о профессии продакта.
Сейчас наука осталась в виде хобби: Люба мечтает построить энергоэффективный дом и вернуться к миниатюрным ветрогенераторам.
Когда всё горит: как удержать крупный контракт с командой из 4 человек
Один из самых ярких кейсов Любы — работа над крупным контрактом при острой нехватке ресурсов. В команде было 4 человека (1 ведущий и 3 джуна), набора не предвиделось, а цена ошибки — потеря 3–6 месяцев разработки и воронки клиентов (цикл сделки — от 6 месяцев).
Что она сделала:
- Собрала фактуру и пошла защищать инвест. Инвест не одобрили, но удалось договориться о стажировках синьоров из соседних команд — это было посильно бюджету.
- Вела параллельные переговоры с клиентом. Итогом стала разбивка контракта на итерации по полгода — этого хватило, чтобы пересобрать команду, погрузить людей и уложиться в сроки.
«Любая проблема решаема, со всеми можно договориться. Вопрос только в твоей устойчивости, навыке вести переговоры и наличии аргументов».
Интервью vs аналитика: как не пойти по ложному пути
В B2B‑продуктах часто возникает конфликт: исследования (интервью) говорят одно, а аналитика — другое. Люба не выбирает «что вернее», а сводит данные вместе:
- Работает с выборкой живых клиентов, особенно в enterprise: реальные переговоры дают сигнал лучше, чем сотни кликов в дашборде.
- Ищет, откуда «врёт» аналитика. Чаще всего проблема не в данных, а в интерпретации: клик не равен намерению. В B2B особенно важно, что реальный пользователь и ЛПР — часто разные люди.
- Проводит «очную ставку»: кладёт рядом тезисы из интервью и цифры из аналитики, ищет точку расхождения. Обычно это либо проблема сегментации, либо неверная формулировка фичи.
«Аналитика говорит, что происходит, а интервью — почему. Без второго первое легко ведёт в неверную сторону».
Роадмап как гипотеза: как жить в мире, где всё меняется
В условиях стартапа и жёсткой регуляторной среды (ФСТЭК, КИИ, ГИС) роадмап у Любы живёт недолго. Её подход:
- Жёсткий горизонт (4–6 недель): конкретные задачи, понятные команде.
- Средний горизонт (до 6 месяцев): направления, сформулированные через результат для клиента (например, «клиент может пройти аудит по 239‑му приказу без доработок»), а не через фичи.
- Дальний горизонт: ставки и гипотезы, в которые она готова инвестировать, если рынок подтвердит.
Требования она делит на два типа: обязательные к дате (сертификация, соответствие приказу) и желательные (ими можно маневрировать).
«Раньше казалось: если план поехал, значит, плохо спланировала. Теперь понимаю: если роадмап в стартапе не меняется — значит, ты не слышишь рынок. Гибкость плана — это не слабость, это и есть продуктовое мышление в условиях неопределённости».
Инвесторам Люба объясняет это просто: «Мы не меняем цель, мы меняем маршрут».
Как понять, что фича «готова»
В enterprise клиенты редко формулируют требования чётко. Люба использует несколько критериев:
- Фиксация сценария, а не требования. Фича готова, когда она убирает «костыли» (Excel, скриншоты, звонки коллегам), которыми человек пользуется сейчас.
- Тест «объясни за 30 секунд». Если ценность нельзя донести без технических терминов — фича ещё не готова.
- Проверка на «первом пользователе». Смотрят не на слова, а на количество вопросов при первом использовании: много вопросов — фича сырая.
- Критерий «не сломали то, что работало». В enterprise пользователи привыкают к поведению системы, и любое изменение может вызвать негатив.
«„Готова“ — это не про код и не про тесты. Это момент, когда клиент использует фичу без инструкции и не звонит в поддержку».
Неожиданный инсайт: не обязательно копировать конкурентов
Однажды клиент прямо сказал: «Знаем мы все эти приблуды, но они не решают наших реальных задач». Этот момент стал поворотным: Люба поняла, что не нужно пытаться догнать всех по функционалу. Важнее решать проблемы, которые конкуренты у клиентов не заметили.
Одним из таких «гейм‑чейнджеров» стал язык интерфейса. Не локализация, а адаптация формулировок под целевую аудиторию: вместо «session terminated» — «подключение завершено, нарушений не выявлено». Это зашло ИБ‑директорам, которые подписывают акты проверок.
Миф, который Люба хочет развенчать
«PM не нуждается в технических знаниях».
«PM не пишет код, но обязан понимать технические ограничения и возможности достаточно глубоко — иначе не сможет адекватно оценивать сроки, принимать архитектурные развилки и разговаривать с командой на равных. Особенно в сложных B2B‑продуктах вроде PAM/IAM».
Блиц: без купюр, ровно как сказала Люба
- Утро: кофе или что‑то другое?
Утро: у меня на такое кружка специальная есть (надпись: «кофе и свежевыжатый треш»).
- Какой мем лучше всего описывает твой типичный рабочий день?
- Что больше всего раздражает в рабочих чатах?
Слишком много однотипных вопросов. Периодически я цитирую свои сообщения, где были ответы.
- Если бы твоя работа была песней, что бы это было?
1. Фаза хаоса и пивота — Feuer Frei! (Rammstein), «Железо внутри» (Еретик), кофе брейк («Токсичный ансамбль лягухо»).
2. Когда роадмап летит в труху — X Gon’ Give It To Ya (DMX), «Шапочка из фольги» (Заточка), «Ты уволен» (Artalasky).
3. Когда фича наконец зашла клиенту — #1 (Imagine Dragons), «Ты супер» («Токсичный ансамбль лягухо»), «Никто не сможет меня остановить» (25/17).
- Что ты делаешь, чтобы отключиться от работы вечером?
Треню дома либо сажусь за свои собственные проекты (всё от настроения), потом на выбор: читаю книги, крашу фигурки Warhammer, рисую картины.
- Книга/подкаст/курс, который изменил твоё отношение к профессии?
1. Элияху Голдратт «Цель» и «Цель 2» — я как раз в то время работала на заводе.
2. Марти Каган «Inspired» — хорошаааа.
3. Дж. Ханк Рейнвотер «Как пасти котов» — если есть желание погрузиться в то, как общаться с разработкой, довольно неплохая.
Что можно взять себе из подхода Любы
Если вынести из интервью не эмоции, а рабочие инструменты, получится вполне конкретный набор практик, которые пригодятся любому продакту (и не только):
- Не бойся менять роадмап. Дели горизонт планирования на три слоя: жёсткие 4–6 недель, направления на полгода, гипотезы на год. Так ты сохранишь управляемость и не будешь тратить силы на иллюзию контроля.
- Своди аналитику и интервью. Цифры покажут, что делают пользователи, а живые разговоры — зачем они это делают. Если данные спорят, устраивай им «очную ставку»: ищи расхождения в сегментации или формулировках фичи.
- Проверяй готовность фичи по поведению. Фича готова не тогда, когда код протестирован, а когда клиент использует её без инструкции и не звонит в поддержку.
- Говори на языке клиента. Иногда самое сильное улучшение — не новая сложная функция, а простая смена формулировок на экране. Если твой продукт читают люди, которые не живут в терминах разработки, адаптируй язык под них.
- Помни про технические основы. Даже если ты не пишешь код, глубокое понимание технических ограничений — это твой главный рычаг для адекватной оценки сроков и принятия архитектурных решений.
И, пожалуй, самое простое и самое сложное одновременно: не бойся туда, где страшно. «С любым вопросом разобраться можно — главное не бояться и уметь задавать правильные вопросы правильным людям».