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-шник.
Достаточно отважен и хабр храбр?
Успей запрыгнуть в поезд! Но помни – тормозов у этого поезда, похоже, нет.