Software Engineer + Product Manager = Product Engineer?
TL; DR
В этой статье попробуем разобраться нужно ли инженеру продуктовое мышление (и в каких случаях), какие плюсы (и минусы) это даёт, и возможно ли совместить в одном человеке два разных (часто противоречащих) образа мышления. Ведь разные образы мышления ведут в разным приоритетам, а как следствие и разным действиям.
Intro
Привет! Меня зовут Ил. И я работаю в стартапе. Нас около 20 человек — половина команды (русскоязычная) занимается технологиями, вторая половина (англоязычная) занимается бизнесом. Официальный язык общения — английский. Мы (как продукт, бизнес и команда) быстро растём, итерируемся, меняемся и развиваемся. Поэтому для нас критически важно чтобы было отличное взаимопонимание между бизнесом и технологиями. Обычно в компаниях эту функцию выполняют продуктовые менеджеры или аналитики. И у нас они тоже есть. Даже двое. Но каждый из них работает над продуктовыми задачами только 50% времени, совмещая эту роль с другими ролями. Поэтому суммируя, можно сказать что у нас в команде один Product Manager. А скорость изменений такая, что в полной мере формализовать, описать и декомпозировать задачи у PM-команды времени физически не хватает. Поэтому большинство задач у нас описываются достаточно высокоуровнево с акцентом на «что хотим получить после того как задача будет выполнена». Процесс декомпозиции задачи, поиск возможных путей решения, выбор оптимального способа и более детальная проработка задачи (в том числе с точки зрения требований и продукта) обычно делегируется инженерам.
Погружаемся
Я бóльшую часть времени занимаюсь бэкендом, но как часто бывает в стартапах по факту занимаюсь очень разными задачами. Несколько примеров задач из реальной жизни (которые инженеры обычно не решают):
Сделать research по barcodes (штрих-коды на товарах). Понять какие для них есть международные стандарты, как они различаются в раличных странах, какой у них формат, как их валидировать и прочее;
Создать план тестирования и/или миграции для большой фичи меняющей поведение в критически важном месте системы;
Спроектировать новую архитектуру для критической части системы на основе опыта и ошибок первой версии. Сюда входит в том числе проработка и формализация новых требований, поиск того что нужно изменить в бизнес-процессах, проектирование сценариев работы и т.д.;
Поискать готовые 3rd party решения для той или иной задачи и оценить что в данный момент эффектнее — взять один из них или написать самим.
В какой-то момент я внезапно осознал, что непосредственно инженерными задачами я занимаюсь не более 50–60% времени. А иногда и того меньше. Вторая половина моего времени уходит на другие активности:
звонки, обсуждения, обмен знаниями о продукте;
интервью кандидатов, участие в hiring-процессах;
изучение PRD (по русски — ТЗ), поиск в нём «багов» заложенных ещё на уровне описания идеи и логики, выявление слабых мест, поиск мест которые можно сделать лучше, проще или оптимальнее, оценка времени необходимого на разработку;
эксперименты, проверка гипотез (продуктовых), POC«и (proof-of-concepts);
написание спецификаций, инструкций и других документов для фрилансеров (часть задач мы аутсорсим) и коллег;
координация с другими командами и членами команд;
выявление слабых мест в процессах, и улучшение процессов;
поиск готовых решений для не mission critical задач (чтобы не изобретать велосипед) и анализ как прагматичнее поступить в конкретном случае — запилить своё решение или взять готовое;
smoke-тестирование;
работа с продуктовыми метриками в Amplitude;
генерация кастомных отчётов.
Ещё один важный момент. Когда мы обсуждаем новую фичу (либо для фичи уже есть PRD, и мы делаем техническое ревью) требования почти всегда очень туманные, и бизнес команда смутно понимает чего хочет. Поэтому существенная часть времени уходит на то чтобы:
понять чего хочет бизнес;
понять чего хочет бизнес на самом деле (обычно 20–50% требований меняется в процессе обсуждения, ещё до начала реализации);
уточнить неочевидные детали, краевые случаи;
проанализировать и найти оптимальное техническое решение.
При этом крайне желательно донести до всей команды особенности выбранного в итоге решения, в том числе его ограничения и недостатки. Потому что выбранный вариант решения задачи это почти всегда trade off (причём достаточно жёсткий): между скоростью разработки, качеством, масштабируемостью и расширяемостью.
Все перечисленные факторы приводят к тому что становится критически важно мыслить не только инженерными ценностями (должно работать быстро, стабильно, безопасно), но и продуктовыми (с вероятностью 80% через несколько месяцев мы удалим этот код или полностью его перепишем). Если не подходить в ежедневной работе с подобной точки зрения, удовлетворённость от работы очень сильно снижается.
Ещё одна важная культурная деталь нашей команды — достаточно плоская структура и то, что каждый инженер лично отвечает за свою задачу, от момента её придумывания до user adoption. И написание кода это лишь один из этапов. «Лично отвечает» — не значит что если что-то пойдёт не так, то человека уволят или лишат премии. Нет. Это значит что нужно будет вернуться назад и переделать. И прагматичное, рациональное, продуктовое мышления уменьшает кол-во таких итераций-переделок кардинально.
+/-
У такого режима работы определённо есть как плюсы, так и минусы. Попробуем в них разобраться.
Разберём плюсы. Почему это круто:
Ты намного лучше понимаешь приоритеты, чётко знаешь что важно, а что второстепенно (в мире стартапов «второстепенно» и «не важно» по сути синонимы). Следовательно, понимаешь каким частям кода следует уделять больше внимание, а в каких в данный момент можно на*****кодить
Ты начнёшь понимать мотивы продуктовых решений, почему решили сделать так, а не иначе. Соответственно ты будешь в курсе дальнейших планов на проект/фичу. Это поможет выстроить более адекватную архитектуру
Тебе будут чаще давать более глубокие, сложные, интересные задачи. Ты получишь больше свободы. И больше ответсвенности
Это интересно. Понимать продуктовые метрики и особенности поведения пользователей — это увлекательно. И это затягивает
Когда начнёшь думать не только о коде, но и о продукте, у тебя постепенно начнёт меняться мышление. Ты заметишь, что тебе станет проще коммуницировать с коллегами, которые занимаются продуктовым менеджментом, проектным менеджментом, аналитикой. Тебе будет проще их понимать. А им тебя. Работа станет менее стрессовой и более продуктивной
Качество твоих фич и решений будет увеличиваться. Как следствие, качество всего продукта тоже будет расти. Вместе с продуктом, твоя ценность в команде тоже будет становится всё больше
Тебе откроются новые возможности — это может стать первым шагом к своему стартапу, или крутой карьере в FAANG, или повышению на текущем месте, или удачному exit-у (если у тебя есть опционы)
Почему это не круто:
Частые смены контекста вредят здоровью. Они не только значительно повышают уровень стресса, но и могут пагубно влиять на мозг. Многочисленные исследования подтверждают это — злоупотребление многозадачностью может привести в снижению общего IQ и негативным изменениям в мозге на физическом уровне, таким как уменьшение плотности нейронов (1, 2). А тебе придётся менять контекст очень часто. Твои дни станут более рваными. Ты будешь заниматься несколькими задачами одновременно и минимум 10/20/30 разными задачами в течении дня. Ты скорее всего станешь более нервным и раздражительным. У тебя могут начаться головные боли, даже если раньше ты был им не подвержен
Тебе придётся делать то, что раньше ты скорее всего никогда не делал, потому что это делали за тебя твои коллеги. Например: работать с системами продуктовой аналитики, системами для рекламы, маркетинга, сервисами для мокапов, прототипирования, дизайна. Тебе придётся разбираться с множеством смежных областей и инструментов в этих областаях. Быть проактивным. Пушить других людей, если они не реагируют вовремя (в том числе твоих менеджеров). Назначать встречи/звонки. И это не вместо кодинга, а вместе с кодингом
Ты начнёшь замечать конфликты в своём мышлении, а возможно и в решениях. За хорошее решение принятое тобой как инженером, твой внутренний PM может на тебя косо посмотреть или даже обидеться (привет, биполярочка!)
Определённости и чётких ответов в твоей жизни станет ещё меньше, чем сейчас
Интегрируем
Вот мы и подходим к тому, с чего начали в заголовке статьи.
Термин Product Engineer пока ещё не очень популярен, но я думаю что в скором времени его популярность будет расти. Возможно для этой роли придумают другие названия, но суть не поменяется.
Драйверов развития этой роли несколько:
Новым IT-компаниям становится сложнее найти своё место на рынке, юникорны появляются всё реже. При этом зарплаты инженеров продолжают расти, как и общие затраты на команды. Ведь с насыщением и усложнением индустрии растёт и количество человеко-часов которые нужно инвестировать чтобы построить успешную высокотехнологичную компанию. В таких условиях продуктовые инженеры могут оказаться редкими покемонами, которых хочет к себе в команду любой стартап. Ведь один человек способен закрыть сразу две позиции (а как бонус ещё и меньше overhead«а на коммуникацию)
Сейчас наблюдается бум продакт менеджеров. Появилось много курсов на которых их обучают, некоторые из них дают реально очень качественные знания. В продакт менеджеры переходят из смежных сфер (разработка, дизайн, тестирование, аналитика) и из совсем других сфер. Это говорит о том, что в целом в индустрии есть постоянно растущий спрос на людей способных создавать и развивать продукты.
В таких условиях, с учётом того что продуктовый менеджмент будет усложняться, вполне гармонично может появиться новая роль на стыке между инженерами и менеджерами — продуктовый инженер. Примеров появления новых профессий на стыке двух других уже было очень много:
Сисадмин/программист → DevOps;
Программист/бизнесмен → Product Manager;
Рекламщик/веб-мастер → SEO-шник.
Достаточно отважен и хабр храбр?
Успей запрыгнуть в поезд! Но помни — тормозов у этого поезда, похоже, нет.
