10 лет я развивал агентство заказной разработки, строил команды по 6–10 человек, делали проекты за 5–15 млн рублей по 6–12 месяцев. Часть проектов вел сам как проджект, параллельно поработал продактом мобильного приложения Лукойл. Сейчас развиваю собственный продукт.
В 2026 году я выхожу на рынок найма и хочу пройти весь путь публично — до оффера. На момент написания статьи у меня еще даже нет резюме.
Буду делиться аналитикой, своими действиями и результатами: планирую разобрать 100 вакансий (если столько найду) и сделать 40+ осмысленных откликов.
Постараюсь давать свои выводы по происходящему, чтобы это было полезно тем, кто тоже сейчас в поиске работы.
И да — вокруг много разговоров, что «найм умер», «рынок работодателя» и т.д. Я хочу проверить это на фактах.
Но начну с главного: с вышеописанным кратко опытом я могу пойти и в product, и в project, но не хочу отталкиваться только от предложений. Поэтому этап 1 — чётко определить, какая роль мне подходит и по каким критериям, чтобы не ошибиться и не перегореть.
Что будет в серии
Часть 1 (эта): разбираюсь с критериями выбора и определяюсь с целевой для себя ролью (product vs project).
Часть 2: проверяю на сколько «умер найм»: разберу 100+ вакансий (HH/LinkedIn/Telegram/Хабр.Карьера + чаты/контакты) по требованиям, пойму и покажу картину спроса на рынке глазами соискателя, и отдельным блоком — что уже встречается по AI-навыкам.
Часть 3: составлю резюме и позиционирование, сделаю 40+ осмысленных откликов: покажу воронку: отклик / ответ / скрининг / собеседования и что влияло на конверсию.
Часть 4: буду проходить собеседования и поделюсь выводами — что сейчас реально интересует работодателей, какие бывают вопросы/кейсы, как отличать адекватные варианты от хаоса ролей.
Часть 5: офферы и выводы: куда пошёл, почему, какие компромиссы и что этот эксперимент показал про рынок 2026.
Постараюсь отразить все сложности соискателя в 2026 году и по ходу дела найти к ним решения, чтобы дойти до оффера.
Дальше я разложил свое видение, чем на практике отличается продакт от проджекта и как выбрать правильную роль для себя.
Продакт vs проджект
Если совсем коротко:
Product Manager / продакт / руководитель продукта — отвечает за ценность и результат: что делать и зачем, какие метрики должны вырасти, почему это важно пользователю и бизнесу.
Project Manager / проджект / руководитель проекта — отвечает за доставку результата: как сделать, кто делает, в какие сроки, с какими рисками и зависимостями.
Простой тест:
Если мою работу будут оценивать по росту метрик — я продакт.
Если по выполнению целевых сроков, объемов, ��ачества — это ближе к проджекту.
Сравненим по 10 критериям, на которых могут сломаться ожидания
Критерий | Продакт | Проджект |
Цель | value, метрики, эффект | delivery, сроки/риски/качество |
Горизонт | кварталы/полугодия | спринты/месяцы/релизы |
Главный вопрос | что делать и зачем | как сделать и успеть |
Артефакты | discovery, PRD, roadmap, KPI | план, RAID, статус-репорты |
Решения | приоритеты, scope, «что не надо делать» | ресурсы, сроки, взаимозависимости |
Успех | рост показателей | выполненный результат |
Главный риск | построили не то | построили не вовремя или вообще не построили |
Коммуникации | бизнес, пользователи, аналитика | команда, стейкхолдеры, смежные команды |
Территория в компании | маркетинг | IT |
Как чаще смешивают | продакт = постановщик задач разработчикам | проджект = продакт, но без полномочий |
Несколько показательных примеров, которые я лично видел с обеих сторон:
С позиции проджекта: проект разрабатывается отлично, команда сильная, сроки держим — и вдруг становится понятно, что продуктом никто не собирается пользоваться, идею внутри компании уже морально списали. С точки зрения delivery всё хорошо, с точки зрения смысла — неприятно.
С позиции продакта: у команды роста получилась действительно крутая стратегия — а на реализации всё посыпалось. И тогда продакт почти неизбежно начинает «лезть» в чужую зону ответственности, потому что если не смогли даже реализовать, то как проверять гипотезы?
Классика аутсорс-разработки (но столкнуться может как проджект, так и продакт): один подрядчик разрабатывает сервис, который интегрируется с внутренней системой, которая еще не готова (бывает даже, что ее вообще еще нет).
Границы нужны, токсичность — нет
Когда люди сравнивают продакта и проджекта, часто размышления скатываются в «это я делаю / это я не делаю». Мне нравится другой подход:
Обозначать границы полезно — чтобы понимать ожидания и, например, не оказаться с двумя зонами ответственности и без полномочий. Но…
Помогать шире своей зоны ответственности — это нормально. Иногда именно так и удается проявить себя.
Это не должно превращаться в системный перегруз и путанницу. Но и своего рода «мелочность» в выборе задач, постоянные «это не моя работа», «мы не можем, потому что они не сделали» и тд. во-первых, не позволят вашему проекту или продукту двигаться вперед, а во-вторых, могут скорее сделать вам образ «нытика», чем отвечающего за результат менеджера.
Где пересечения нормальны
По моему опыту не бывает «стерильных» ролей без пересечений зон ответственности, в такой сложной интеллектуальной работе, как наше с вами IT.
В типовой модели продакт владеет:
формулировкой проблем и целей
метриками успеха
приоритетами и roadmap’ом
вопросами «зачем» и «почему»
Проджект в идеале владеет:
планом работ
рисками, взаимозависимостями, сроками
статусами и ожиданиями
процессом delivery
Может, если хочет
продакт может участвовать в «как дела, успеваем?» и выравнивании ожиданий
проджект помогает придерживаться смысла и не городить «фичей ради фичей»
решения про компромиссы по scope/качеству/срокам обычно совместные
5 вопросов работодателю, чтобы и модель понять, и токсичным не выглядеть
Кто владелец roadmap и приоритетов?
Какие 2–3 метрики считаются успехом роли?
Кто принимает решение по scope/срокам/качеству и как решаются компромиссы?
Где чаще бывают проблемы — discovery (смысл) или delivery (реализация)?
Как бы вы сами назвали эту роль — скорее чистый продакт/проджект и ближе к гибриду 2в1?
Последний вопрос по идее должен поставить финальную точку.
Навыки и как я оцениваю себя
Я люблю наглядную визуальную оценку всего чего угодно, чтобы сразу сложилось общее впечатление, а дальше уже можно было бы углубляться в детали.
На оценку специалистов давно уже смотрю через «карту навыков» (и себя теперь ре��ил оценить таким же образом). Я составил карты навыков продакта и проджекта и заполнил по себе в режиме самооценки.
Карта навыков включает все, что нужно уметь, на мой взгляд, для выполнения такой работы на максимальном уровне эффективности и качества. Заполнив такую карту видно где пробелы, что стоит подтянуть под рынок. Собственно, потому я и выбираю между продактом и проджектом, а не системным аналитиком, где у меня будет довольно много пробелов.
Это карта моих навыков продакт-менеджера:
А это карта моих навыков как менеджера проектов:
Если скомпоновать навыки по группам, то картинка становится проще: у продакта и проджекта есть общий «скелет» (без него никуда), а дальше начинаются две разные специализации — одна больше про смысл и ценность, другая — про доставку результата в ограничениях.
Общий фундамент
Это база, которая нужна в обеих ролях. Без этих навыков выбирать между этими ролями не имеет смысла — нужно сперва получить эти навыки:
коммуникации, фасилитация, управление ожиданиями
декомпозиция и структурирование задач
базовая аналитика и понимание метрик
понимание разработки (релизы, итерации, качество)
Уникальные навыки для продакта
Здесь фокус на «что именно строим и почему это должно сработать». Продакт постоянно проверяет гипотезы, режет лишнее и защищает приоритеты — в идеале даже так, чтобы команда делала меньше, но с большим эффектом (ROI).
discovery: интервью, JTBD, problem framing
приоритизация (RICE/ICE/WSJF), гипотезы, эксперименты
продуктовая аналитика: A/B, воронки, retention
юнит-экономика и монетизация (если продукт коммерческий)
Уникально для менеджера проектов
Проджект в первую очередь отвечает за то, чтобы результат случился — несмотря на изменения по ходу. Он держит зависимые куски в голове, заранее видит риски, умеет управлять ожиданиями заинтересованных лиц и командой одновременно.
планирование и зависимости, критический путь
риск-менеджмент, управление изменениями scope
ресурсное планирование, бюджеты/поставщики (если есть)
управление delivery-процессом и качеством
К чему я сейчас склоняюсь
Я могу найти интерес почти в любом проекте и мотивацию, чтобы довести его до результата. Но есть критерий, который на длинной дистанции для меня очень важен: масштаб полезности того, что мы делаем — например, сколько людей/компаний пользуются, сколько процессов/операций/денег проходит через систему. На масштабе особенно видно, какие решения получаются удачные, а какие нет. Так появляется пространство для улучшений и возможность почувствовать свое влияние на продукт.
Еще я понял для себя следующее:
мне нравится быть внутри реализации и доводить до результата (бизнес-аналитиком на потоке я не смогу долго работать, интересные проекты будут проходить мимо)
сейчас мне комфортнее, когда есть понятный отрезок работы и точка завершения (это никак не исключает работу продактом, напимер, есть вехи развития продукта)
я не хотел бы сразу брать на себя многолетнюю стратегию продукта, до того, как мы сработались с компанией и увидели перспективы друг в друге
Пока кажется, что под мои критерии лучше подходит роль менеджера проектов, но мне интересны продуктовые задачии и далеко не все продуктовые вакансии отсекаются этими моими критериями.
Поэтому хочу сперва добавить аналитики с рынка, поразбирать свежие вакансии, пообщаться с давними друзьями из IT. Пойму как эти роли реально выглядят, в том числе и в разных средах — например, как устроен проджект-менеджмент в продуктовой компании и какие есть перспективы. После этого смогу определиться.
Мини-тест для проверки своих предпочтений
Я пока не смог окончательно выбрать роль, но, может быть кому-то удастся это сделать сразу, ответив себе на вопрос:
«Что у меня вызывает азарт?»
Разобраться «что на самом деле нужно пользователю» → продакт;
Собрать людей/план/риски и довести до результата → проджект;
Спорить про приоритеты и говорить «это не делаем» → продакт;
Разруливать зависимости и вытаскивать сроки из болота → проджект;
Радоваться росту метрик после релиза → продакт;
Радоваться, когда релиз вышел без пожара и сюрпризов → проджект;
Спасти всех → проджект;
Приложить как можно меньше усилий и получить признание и много денег → пожелаем удачи.
Как я буду фиксировать прогресс (чтобы не утонуть в приглашениях и офферах)
Чтобы не превращать поиск работы в хаос, я сделал простую канбан-доску — это моя CRM по вакансиям: что в работе, где назначили собес, где результаты, где реально интересно, где оффер и тд.
1 шаг сделан
Критерии выбора сформулированы, надеюсь мой ход мыслей поможет кому-то сузить фокус поиска подходящей позиции в подходящей компании. Потому что это действительно важно — понять для себя, что мне подходит, а что нет. От этого сильно будет зависеть продуктивность, эффективность и внутреннее удовлетворение.
Во второй части я разберу что предлагает рынок: постараюсь найти 100+ свежих вакансий и покажу:
что реально требуют в 2026 году;
где роль чуть шире, а где нужен универсальный боец (что, кстати, тоже не всегда и не для всех плохо);
какие навыки/инструменты всплывают чаще всего;
что по AI — где уже есть осмысленные требования по AI для менеджеров, а где где просто мода требует упоминания и не более того;
и да — там же аккуратно поговорим (я еще не изучал вопрос публичного упоминания конкретных компаний, позиций и зарплат) про деньги, потому что появится репрезентативная выборка вакансий, а потом и реальных офферов.
Источники вакансий, которые я планирую взять: Хабр.Карьера, HH, LinkedIn, Telegram-каналы, плюс контакты и чаты, включая аутстафф-вакансии.
Оглавление
Ссылки на будущие части добавлю по мере выхода.
Часть 1 — Продакт или проджект: как я выбираю роль (эта статья)
Часть 2 — Анализ 40 вакансий: требования 2026, подмена ролей, AI-навыки (ссылка появится)
Часть 3 — Резюме и отклики: версии, 100+ откликов, конверсия (ссылка появится)
Часть 4 — Собеседования: кейсы, вопросы, красные флаги (ссылка появится)
Часть 5 — Офферы и выводы: куда пошёл и почему (ссылка появится)
Если есть вопросы — можешь написать мне
Telegram: @ryazancevnik. Если есть вопросы (любые по теме) или сомнения — можно написать мне, постараюсь помочь чем смогу (не услуги, не реклама, бесплатно). Вместе решать одну и ту же задачу всегда легче.
Вопрос к читателям
На моей практике несколько менеджеров проектов, поработав в моем агентстве, успешно устраивались продактами в крупные компании.
Это потому, что PM’ы прокачивали продуктовое мышление на проектах? Или это получалось из-за личных качеств и достижения некоторой профессиональной зрелости?
Как считаете, почему так получалось и сработало бы сейчас? А если есть такой личный опыт — буду признателен, если поделишься в комментариях!
