Рубрика: выскажи свое мнение как продакт или что бы я хотела знать в начале карьеры 

Привет, Хабр! На связи Настя Швецова, я руковожу продуктовой командой «МосТрансПроекта». В этой роли я работаю больше трех лет, а в цифровой сфере уже больше десяти. За это время прошла путь от маркетинга до управления разработкой и убедилась, что смена фокуса — не обнуление, а наращивание компетенций.

Кстати, наш институт вошел в топ-100 лучших работодателей страны по версии одного из популярных порталов в сфере HR. И сейчас мы снова участвуем в этом рейтинге, чтобы помочь нам войти в список лучших компаний, вы можете поддержать нас тут.

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

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

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

Мой путь в МосТрансПроекте начался с позиции руководителя проекта или PO. С самого начала у меня была команда разработки во главе с тимлидом. И довольно быстро я поняла, что продакт + тимлид — это главная ИТ-скрепа, на которой держится весь процесс.

Одна из самых ценных вещей, которые я усвоила в продуктовой работе, — без нормального взаимодействия с разработкой ничего не взлетит. Чтобы продукт из прототипа стал MVP, а затем доспел до зрелого, ему нужна зрелая и слаженная команда, а не набор компетенций и технологического стека (аналитик, бэкенд, техпис и тд). В конечном счете управлять всем циклом работы этой фабрики по созданию пользовательской ценности должен продакт. И он должен разобраться, как настроить все взаимодействия: и внутри между всеми этими ролями, и снаружи — с бизнесом, пользователями, стейкхолдерами.

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

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

Сейчас в нашей команде несколько функциональных тимлидов, с которыми я взаимодействую. И мне с ними, безусловно, повезло: у нас совпадают ценности, и это превращает работу не просто в обмен задачами, а в полноценное партнерство. Оно не ограничивается требованиями и кодом — им, как и мне, важно, чтобы продукт приносил реальную пользу, менял процессы и улучшал пользовательский опыт. Благодаря такой синергии нам не приходится долго объяснять друг другу приоритеты: мы оба смотрим в сторону результата, а не формального «сделать, потому что попросили».

Это дает гибкость — можно экспериментировать, быстро тестировать гипотезы, менять фокус, когда это необходимо. И самое главное — создает ощущение совместного движения в правильном направлении.

Баланс ответственности между продактом и тимлидом — основа здоровой продуктовой работы. Продакт отвечает за стратегию и целеполагание, пользовательскую ценность, ресурсы, приоритеты и коммуникацию внутри команды и с бизнесом. Тимлид  переносит бизнес-цели на язык кода, декомпозирует задачи и выстраивает реализацию. Казалось бы, очевидно. Но на практике часто начинается перетягивание одеяла. У нас с тимлидами с этим полный порядок: они погружены в цели продукта, понимают, зачем мы делаем каждую фичу, и при этом уважает границы ролей. Доверие и разделение ответственности — это не про борьбу, а про команду.

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

100500 продуктов при горящих сроках. Помогите. 

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

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

Правильный подход — масштабировать позитивный опыт. Вероятность, что предыдущий опыт сработает — не стопроцентная, но очень большая. На момент роста портфеля продуктов у меня уже сложился успешный фрейм работы над продуктом «Узнай про ЖК», сервисом оценки транспортной доступности новостроек. О нем подробно рассказывали здесь. Поэтому, когда встал вопрос о систематизации работы над портфелем, я прыгнула из роли PO в условного CPO и приступила к наведению экосистемы в порядок.

Первым делом мы применили продуктовый подход в каждом продукте, который основывается на принципах:

• желание понимать пользователя и выявлять его потребности,

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

• регулярные ритуалы для выстраивания слаженной работы кросс-функциональной команды без избыточности (только необходимые дейли, синки и стендапы с четкой фасилитацией встречи, транслирование ценности продукта и культуры командной работы),

• внедрение единого подхода к управлению бэклогом (система тегов, принципы группировки и декомпозиции).

Так появилась структура с четким разделением направлений: у каждого продукта есть свой руководитель, а вся система управления базируется на лучших практиках. Мы взяли за основу дизайн-мышление, которое позволяет нам глубже понимать боль пользователя, и принцип Парето — 20% усилий дают 80% результата. Это помогает нам правильно расставлять приоритеты и не разбрасываться на бесполезные фичи. 

Не три, а пять китов, на которых все держится 

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

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

1) Принцип ПДД: Приоритизируй, Декомпозируй, Дедлайны

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

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

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

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

2) Фокус на пользователя

В коммерческих продуктах одной из ключевых зон ответственности продакта является экономика продукта, его бизнесовая модель: деньги — это и цель, и метрика. В работе над некоммерческими или внутренними продуктами метрики меняются, но продуктовый подход остается. Он становится более требовательным к качеству пользовательского понимания и глубине анализа эффектов. Мы оцениваем успех продукта через его влияние на повседневность — то есть социальную и производственную значимость. Решение должно показывать пользователю объективную оценку транспортной доступности без экивоков в сторону застройщика как в случае с «Узнай про ЖК» или повышать скорость доступа к данным при подготовке аналитических материалов для сотрудников МТП. Для нас важно, чтобы продукт действительно менял повседневность людей к лучшему, решал реальные проблемы, добавлял эффективность в решении производственных задач сотрудников организации, приносил общественную пользу.

Пользователь в центре – глубокое понимание целевой аудитории, выявление её потребностей и оценка удовлетворённости. Здесь у нас работают все привычные продуктовые инструменты: CJM, карта гипотез, user stories и тд.

3) Сильная связка продукта и разработки 

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

4) Грамотно сформулированная гипотеза 

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

Гипотеза — это фундамент продукта. На этапе исследования мы тщательно проверяем её, оцениваем риски и убеждаемся, что решаем действительно важную проблему. Если пропустить или формально пройти этот шаг, можно потратить месяцы на фичу, которая никому не нужна. Хорошо сформулированная гипотеза задаёт правильное направление и помогает команде работать целенаправленно, а не вслепую.

6) Важно учитывать контекст стейкхолдеров

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

Это значит держать в голове весь контекст: кто наши стейкхолдеры, какие у них ожидания, на каком языке они общаются с вами (язык презентации в pptx или демо), какие бизнес-задачи стоят перед продуктом, и как всё это соотносится с потребностями пользователей. Если игнорировать этот контекст, команда рискует делать продукт, который либо не соответствует стратегическим приоритетам, либо не решает реальные проблемы клиентов. Без глубокого понимания контекста не получится ни слаженной разработки, ни эффективного взаимодействия с бизнесом, ни успеха продукта в целом. Именно умение балансировать между всеми этими факторами делает продакта настоящим лидером команды.

Итог? 

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

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

Будет тяжело? Безусловно. Главное — не бояться, пробовать, задавать вопросы, слышать людей, быть гибким и учиться. Продакт всегда про людей: свою слаженную команду, пользователей и бизнес. Управлять этим всем — уже почти искусство.