Тут я поверхностно рассказал про концепцию продуктовых инженеров. В целом мне близка такая концепция продуктовых команд. Но у всего есть свои минусы.

– Один из основных минусов, который довольно сильно аффектит концепцию, – это поверхностная экспертиза. Продуктовому инженеру нужно разбираться и в коде, и в аналитике, и в UX, и в бизнесе. Очевидно, что он может уступать узкому специалисту в сложных технических задачах;

– Из пункта выше вытекает еще один минус – выгорание. От продукт-инженера ждут, что он будет писать код, проводить интервью с пользователями, анализировать метрики и принимать продуктовые решения. Перегруз разнопрофильными задачами может сильно выхолащивать;

– Скрытый технический долг. Ну, это база. Стремление быстрее проверить гипотезу приводит к временным решениям. Ну, тут сами понимаете: ничего нет более постоянного, чем что-то временное. Более того, возникает не просто долг, а именно скрытый, о котором сам инженер может не догадываться;

– Особые условия для ротации. Модель требует людей, которые умеют принимать решения в условиях неопределенности. Новым специалистам в такой среде может быть сложно: тут практически сразу требуют перформить и на вкатывание нет времени;

– Неуправляемость. Из-за децентрализации управлять или хотя бы направлять довольно сложно. Это значит, что проблемы, которые могут возникать, могут либо заметаться под ковер в угоду скорости, а если происходит вмешательство извне, то это сильно замедляет темп POD-команды;

– Уход из компании. Уходя, такой специалист может оставить за собой множество черных ящиков: ◦ Заброшенные функции; ◦ Потеря знаний о продукте; ◦ Потеря неформальных связей; ◦ Сложность замены.

Как видите, основной недостаток такой модели – это bus factor. Это не конец света, и риски можно проработать: писать документацию, чаще проводить код-ревью, ротировать задачи и передавать контекст. Но это уже другая история.