Похоже, мы быстро движемся к миру, где старые роли в продуктовой и инженерной сферах станут менее актуальными. Не потому, что продакты плохие или разработчики ничего не понимают, а потому что границы между мышлением, проверкой и действием начинают стираться.
Я хочу ввести термин «продуктовый инженер». С сегодняшнего дня я официально называю себя именно так.
Для меня продуктовый инженер — это человек на пересечении бизнеса, продукта и разработки. Он понимает, какую проблему решает, может собрать прототип, проверить гипотезу, пообщаться с пользователями, улучшить MVP, посмотреть на метрики и не сойти с ума от того, что пришлось копаться в коде.
Это не замена команде. Команда всё ещё важна. Но продуктовый инженер может в одиночку довести идею от мысли до работающего сервиса, который можно показать людям. Это, на мой взгляд, станет одним из главных навыков в ближайшие годы.
Продакт, который умеет только писать требования, проиграет тому, кто может сам собрать первый эксперимент. Разработчик, который умеет только закрывать задачи, проиграет тому, кто понимает бизнес, пользователей и зачем нужна та или иная кнопка.
Границы будут размываться. Кажется, через несколько лет у разработчиков будет несколько путей: продуктовый инженер, оркестратор, архитектор. Не лучше или хуже, а разные способы быть полезными.
У меня, конечно, читерский бэкграунд. Я много лет работал в разработке, потом перешёл в продукт, управление и бизнес. Поэтому текущий рынок для меня — это не катастрофа, а странная ночь, в которой я чувствую себя как рыба в воде. Наконец-то можно не выбирать между кодом и продуктом, а объединить это в одну роль.
Но возникает главный вопрос: где взять таких людей? Сейчас на рынке есть сильные ребята, которые сами пришли к этому. Кто-то из разработки, кто-то из продукта, кто-то из основателей. Но массово таких людей никто не готовит. Нас всё ещё учат либо писать код без понимания бизнеса, либо делать продукт без умения что-то собрать руками.
На мой взгляд, это нужно менять. Поэтому я ставлю себе цель не только быть продуктовым инженером, но и воспитывать таких специалистов внутри команды и для рынка. Роль, которая может взять на себя боль, гипотезу, код, пользователей и деньги, будет стоить намного дороже, чем роль, которая умеет только передавать задачи дальше.
· 20.05
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён