Product Manager, Retrosynthesis & Predictive Chemistry

В чем заключается ваша работа?

Моя работа – разрабатывать SaaS-платформы и инструменты для химиков, которые помогают в ежедневной R&D-рутине. Мой главный фокус – ретросинтез: поиск и приоритизация возможных синтетических маршрутов, включая опубликованные и AI-предсказанные варианты. Ну и, на сдачу, участие в разработке других инновационных продуктов, про которые NDA говорить пока не разрешает.

Сразу стоит оговориться: продуктовый менеджер в ИТ это не проектный менеджер с модной подписью в LinkedIn и не «тот самый продакт из маркетинга». Продуктовый менеджер отвечает не только за процессы, но и за то, что именно мы строим, зачем мы это строим, кому это нужно и какую ценность в итоге получает пользователь.

Небольшой оффтоп: пока мы не ушли в пучины ИТ, вспомним про чистую фарму, там похожие по названию роли тоже встречаются, но смысл у них обычно другой. В коммерческих отделах человек, который отвечает за продукт или группу продуктов, чаще называется бренд-менеджером. А в разработке можно встретить роли вокруг product lifecycle management: где-то это функция внутри CMC, где-то – люди из технологического трансфера, где-то – отдельный департамент, а где-то, на худой конец, кто-то слишком активный из R&D. ICH Q12, конечно, рассказывает про lifecycle management с точки зрения CMC и пострегистрационных изменений, но методичку «как назвать должность и куда посадить человека в орг. структуре» туда не положили. Поэтому в реальной жизни названия и зоны ответственности плавают от компании к компании. Productum producto lupus est.

Возвращаясь к ИТ: на практике приходится жонглировать всем сразу: UX-исследованиями, пользовательскими интервью, приоритизацией фичей, разработкой, маркетингом, поддержкой новых и текущих пользователей. Иногда идея новой фичи или продукта приходит именно продакт-менеджеру в бренную голову, и тогда первичный прототип тоже частенько оказывается на его плечах. В хемоинформатике это особенно актуально: иногда быстрее собрать демо самому, чем десятый раз объяснять бэкэнд-инженеру нюансы химии.

Чтобы это не выглядело так, будто я в одиночку отдуваюсь за все грехи мира, отмечу: рядом всегда есть команда смежных продакт-менеджеров, которые занимаются другими, но пересекающимися проектами. Коллеги помогают в самых разных аспектах – от разработки прототипов до общей организации процессов. И это сильно спасает: в продуктах на стыке химии, данных и разработки редкая задача нормально помещается в одну голову.

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

Как вы попали в эту сферу, с чего начинали?

Перед карьерным переходом я провел 12 лет в фармацевтической разработке: синтез активных фармацевтических субстанций (АФС), разработка молекул и технологий, технологический трансфер, CMC. За это время набрался не только химических, но и продуктовых знаний: как идея превращается в молекулу, молекула – в технологию, технология – в документацию, а документация – в шанс выйти на рынок. Думаю, тут уместно сослаться на предыдущий материал, где я подробнее расписывал свой карьерный путь в мире химии. Отдельно просто отмечу, что хемоинформатические навыки пришлось развивать в свободное от работы время.

И как раз после последней заметки, примерно два года назад, я понял, что «в своем познании настолько преисполнился», что дальнейшая карьера в фармразработке для меня стала скорее добором оставшихся 20% знаний – принцип Парето, все дела. И так уж получилось, что, благодаря нетворкингу, подвернулась возможность перейти на темную сторону хемоинформатики. Как выяснилось, там тоже есть свет – просто он чаще идет от монитора.

Что в работе приносит вам радость и удовлетворение?

Раньше меня мотивировала возможность разрабатывать лекарства и потом видеть их на рынке. Сейчас масштаб немного изменился: меня мотивирует возможность помогать химикам по всей Земле ускорять разработку лекарств и других химических соединений. То есть вместо «сделать один препарат самому» появляется шанс сделать инструмент, который поможет многим командам делать свои молекулы быстрее и иногда с меньшим количеством страданий.

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

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

Какому человеку может подойти такая работа?

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

Поэтому выбрать что-то одно не получится. Нужно балансировать между пользователями, разработчиками, маркетингом, продажами, руководством, дорожной картой, техническими ограничениями и ожиданиями менеджмента: «Красивый план, но у нас тут есть пара идей, как насчет того, чтобы добавить AI?».

Таким образом, эта работа точно не для тех, кто ищет тихий угол, где можно «потыкать кнопочки, покурить и свалить». Каждый день вылезают новые задачи, и с ними надо что-то делать. Конечно, многое зависит от организации и ресурсов, но ожидать, что все будет закрываться строго по спринтам и идеально по дорожной карте, не стоит. Дорожная карта – это не железобетонная плита, а скорее верхнеуровневые ожидания, которые приходится пересматривать из квартала в квартал.

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

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

Что нужно знать и уметь?

Все, везде и сразу 

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

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

Дальше важно понимать цикл разработки ИТ-продукта: с чего начать исследование рынка, как сформулировать гипотезы, как валидировать их на интервью с пользователями, когда собирать прототип, как запускать разработку, когда подключать маркетинг и как готовить команду продаж к тому, что они теперь будут продавать не «магический AI», а вполне конкретный продукт с возможностями, ограничениями и ценностью.

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

Ну и, конечно, жёсткие харды. Приходится понимать, чем PostgreSQL отличается от MongoDB, AWS – от Azure и т.д. Понятно, что от менеджера не ждут, что завтра он сядет писать прод-код на JS, но базовые принципы работы знать надо. Иначе разговор с разработкой не клеится.

При этом хотя бы в чем-то одном стоит разбираться достаточно хорошо, чтобы собирать прототипы самостоятельно. Пусть это будет Python, вайб-кодинг или что угодно еще – главное, чтобы идея не умирала на стадии «я отправил задачу и жду три недели».

Ну и куда сейчас без GenAI. Мир уже поменялся, и разработку цифровых продуктов без ИИ представить все сложнее. Он помогает почти на всех этапах: от исследования рынка и анализа интервью до прототипирования, документации, тестов и подготовки релиза. Естественно, без человеческого ревью никуда, но даже сжигание токенов на тысячи £ иногда оказывается экономически выгоднее, чем годами разрабатывать продукт в режиме «давайте еще немного уточним требования».

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

Что можно сделать уже сейчас, чтобы студент или молодой специалист мог стать ближе к этой сфере?

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

Где-то продукты настолько технические, что кажется: маркетинг почти не нужен, «само себя продаст». Но на практике даже очень умный продукт без нормальной стратегии выхода на рынок, документации, обучения команды продаж и понятного позиционирования может остаться красивой демкой для внутренних созвонов.

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

Зайти совсем со стороны и начать разрабатывать продукт, в котором мало что понимаешь, конечно, можно. Но на текущем рынке вряд ли кто-то с радостью даст такую возможность без понятного доменного опыта, технической базы или хотя бы сильного продуктового фундамента. Сейчас всем хочется людей, которые не просто «умеют в продакт», а еще и понимают, почему пользователь страдает, где бизнес зарабатывает деньги и какую нишу можно занять пока конкуренты не поспели.

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

Если в целом интересна тематика разработки ИТ-продуктов, я бы начал с Inspired и Transformed от Кейгана. Книги местами скучные, зато дают базу, после которой многие корпоративные странности приобретают подобие смысла.