Друзья, сегодня у нас не тема, а огонь:
крутейшие продакты рассказывают, по какому принципу у них организованы команды. На английском языке есть две прекрасные заметки на эту тему – от Buffer и Spotify:
https://open.buffer.com/product-team-evolution/https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/– и я давно уже хотела сделать нечто подобное для NFNG. И вот, случилось! Спасибо всем спикерам, кто смог поучаствовать!
----------
Анна Бояркина, Head of Product в RealtimeBoard
В RealtimeBoard есть две группы продуктовых команд — Core Product и Product Growth.
В Core-продукте разделение по опыту пользователя/компонентам — Core features, Integrations, Platform, Mobile, Enterprise. В Product Growth — по Customer journey: Activation, Engagement&Retention, Monetization. Разделение на две части связано с тем, что разная скорость разработки ключевого продукта и экспериментов, для этого нужен разный скиллсет людей. Мы для себя понимаем, что задача ключевого продукта — проверять гипотезу ценности и эту ценность доставлять до пользователя, а задача команды роста — масштабировать это.
Cхема работы между командами такая: Core product исследует потребности и воркфлоу пользователей и занимается глубокой проработкой ценности и UX-фичей, а Product growth уже встраивает их в "каналы доставки" (онбординг, нотификации и тд) и монетизацию.
Для того, чтобы все это не тащилось в разные стороны, есть три важные вещи:
1) OKRs, которые декомпозированы на инициативы, и каждая команда понимает, на что влияет
2) Общая для всех встреча по продуктовым инсайтам, где мы делимся результатами исследований
3) Встреча по продуктовому фидбэку, где мы обсуждаем решения.
----------
Евгений Емельянов, директор по продукту в АвитоОсновной продукт Авито разделен на два ключевых сегмента — частники и бизнес. Далее продуктовые команды делятся по направлениям, которые приносят пользователям конкретную ценность. Например, для частников это: опыт покупателя, опыт продавца, взаимодействие между покупателем и продавцом, безопасность и доверие. И так далее по похожей логике. В каждом направлении одна или несколько продуктовых команд, у каждого направления свои цели и метрики.
Мы не страдаем догматизмом и стараемся адаптировать структуру под действительность, а не наоборот. Нам важно поддерживать стратегию компании соответствующими ударными силами, давать командам достаточно автономии и свободы, минимизировать толкание локтями между командами и всегда быть готовыми к изменениям.
----------
Валерия Коваленко, Head of Product в Qlean
Мы в Qlean организуем продуктовые команды по принципу “Цепочки ценностей” Майкла Портера. Инструмент цепочки ценностей в классическом варианте используется для стратегического анализа компании. Этот подход применяют, когда нужно декомпозировать очень сложный процесс и определить, где “узкое место”. Мы подумали, что это можно адаптировать под нужды нашего бизнеса и продуктовой команды.
Почему мы выбрали такой подход?
1. Все бизнес-процессы укреплены продуктовой экспертизой. Мы видим всю цепочку и на каждое звено ставим часть продукта. Продукт "обволакивает" каждую функцию и думает вместе с ней об эффективности и автоматизации. Это сокращает затраты на коммуникацию, позволяет продакту больше погружаться в проблемы конкретного бизнес-процесса, а бизнес-заказчикам иметь прямой доступ к разработке.
2. Продукт развивается равномерно, нет "перекосов" - в мобильном приложении один функционал, на сайте другой, и все это не синхронизировано. Конечно, если мы не разделяем функционал специально, чтобы вырастить какую-то из метрик.
3. У каждой продуктовой команды есть понятные бизнес-заказчики. Там, где их нет, процесс максимально автоматизирован. Не возникает путаницы и беспощадных гуглдоков, куда тысяча бизнес-заказчиков ставят кучу своих "требований" к продукту.
4. Очень легко считать, за какую часть P&L отвечает команда: каждое звено цепочки ценности представлено в отдельной строке/блоке строк в отчетности. Это помогает лучше ставить цели, планировать эффект работы продукта на бизнес.
