Продакт без технического бэкграунда: как не бесить инженеров? 🤣
Когда вы не писали код, легко чувствовать себя «не своим» рядом с тех.командой: кажется, что любой вопрос прозвучит глупо, а любое решение упрется в «это технически невозможно».
Но продакту не обязательно самому быть разработчиком. Важнее — уметь приносить команде контекст, нормально работать с требованиями и уважать инженерную экспертизу 📎
✅ Приходите не только с задачей
Не просто «что надо сделать», а с контекстом: какую проблему решаем, на что хотим повлиять, хотим проверить гипотезу Х.
Вовлекайте инженеров в продукт — они сами иногда будут подкидывать вам идеи.
✅ Проявляйте любопытство к тому, как работает продукт под капотом
Нужно хотя бы по верхам понять, где какие зависимости, ограничения, что может сломаться. Инженеры уважают любознательных продактов.
⭐️Бонус — так вы лучше поймете, почему одна задача делается за день, а другая за квартал.
✅ Качественно прорабатывайте требования
Размытые требования съедают энергию команды и ведут к затратам дополнительных ресурсов на переделывание, доуточнение и т.п.
Кроме того, при меняющихся требованиях разработчики могут засомневаться: а точно ли продакт понимает, что делает?
✅ Обсуждайте сроки, риски и варианты реализации
Это норм.
А вот давать рекомендации, как писать код, или спорить про архитектуру — не очень хорошая идея.
Каждый должен заниматься своим делом: продакт отвечает за проблему, ценность и приоритеты, разработка — за техническое решение.
✅ Ходите на ретро и будьте активным участником
Простой, но недооцененный совет.
Что беспокоит команду? Где не хватает контекста? Какие задачи прилетают слишком поздно?
После такого разговора важно не просто покивать, а забрать action items для себя.
💬 Если коротко
Команда разработки уважает не самого технически подкованного продакта.
Она уважает того, кто приносит смысл, уважает инженерную экспертизу и помогает двигаться к результату.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Если вы переходите из Project Manager в Product Manager, готовитесь к собеседованию в бигтех или хотите увереннее работать с инженерами — тестовая сессия с Романом поможет разложить это на конкретные шаги.
За одну встречу разберете вашу карьерную ситуацию, поймете, какие навыки и аргументы стоит подсветить, где сейчас слабые места и как увереннее заходить в продуктовую роль — на интервью или уже внутри команды.
🔜 Записаться на бесплатную тестовую сессию с Романом
Когда вы не писали код, легко чувствовать себя «не своим» рядом с тех.командой: кажется, что любой вопрос прозвучит глупо, а любое решение упрется в «это технически невозможно».
Но продакту не обязательно самому быть разработчиком. Важнее — уметь приносить команде контекст, нормально работать с требованиями и уважать инженерную экспертизу 📎
Сегодня с нами Роман Степанов — Product Manager в Авито и ментор Solvery.
Роман отвечает за развитие монетизации продавцов, запускал продукты в разных направлениях — внутренние продукты, B2B и B2C, прошел путь из традиционных компаний в Яндекс и Авито, а еще сам совершил переход из Project Manager в Product Manager.
Ниже — его рекомендации о том, как продакту выстраивать работу с инженерами, если он сам никогда не был разработчиком.
✅ Приходите не только с задачей
Не просто «что надо сделать», а с контекстом: какую проблему решаем, на что хотим повлиять, хотим проверить гипотезу Х.
Вовлекайте инженеров в продукт — они сами иногда будут подкидывать вам идеи.
✅ Проявляйте любопытство к тому, как работает продукт под капотом
Нужно хотя бы по верхам понять, где какие зависимости, ограничения, что может сломаться. Инженеры уважают любознательных продактов.
⭐️Бонус — так вы лучше поймете, почему одна задача делается за день, а другая за квартал.
✅ Качественно прорабатывайте требования
Размытые требования съедают энергию команды и ведут к затратам дополнительных ресурсов на переделывание, доуточнение и т.п.
Кроме того, при меняющихся требованиях разработчики могут засомневаться: а точно ли продакт понимает, что делает?
✅ Обсуждайте сроки, риски и варианты реализации
Это норм.
А вот давать рекомендации, как писать код, или спорить про архитектуру — не очень хорошая идея.
Каждый должен заниматься своим делом: продакт отвечает за проблему, ценность и приоритеты, разработка — за техническое решение.
✅ Ходите на ретро и будьте активным участником
Простой, но недооцененный совет.
Что беспокоит команду? Где не хватает контекста? Какие задачи прилетают слишком поздно?
После такого разговора важно не просто покивать, а забрать action items для себя.
💬 Если коротко
Команда разработки уважает не самого технически подкованного продакта.
Она уважает того, кто приносит смысл, уважает инженерную экспертизу и помогает двигаться к результату.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Если вы переходите из Project Manager в Product Manager, готовитесь к собеседованию в бигтех или хотите увереннее работать с инженерами — тестовая сессия с Романом поможет разложить это на конкретные шаги.
За одну встречу разберете вашу карьерную ситуацию, поймете, какие навыки и аргументы стоит подсветить, где сейчас слабые места и как увереннее заходить в продуктовую роль — на интервью или уже внутри команды.
🔜 Записаться на бесплатную тестовую сессию с Романом