Мы понимали, что командами невозможно закрыть весь спектр возникающих задач. Поэтому, создали отдельную большую команду, назвав ее CORE Team. Это важная часть команды разработки, реализующая задачи, которые не вписываются в воронку или исходят от внешнего заказчика (например, отдела маркетинга, продаж и т.д.).
Какие ещё варианты формирования команд рассматривали и почему AARRR победил?
Есть еще варианты, когда команды делятся на платформы. Например, один продакт отвечает за сайт, второй за мобильные приложения. Но такой вариант не особо удобный (на наш взгляд) по следующим причинам:
- Расхождение между платформами будет большим. Пользовательский опыт будет сильно различаться при переходе с телефона на сайт или наоборот
- Расфокусировка по все воронке. Одному продакту в такой схеме придется следить за активацией, монетизацией и вовлечением одновременно
AARRR позволяет заняться определенным шагом воронки и использовать платформы как "инструмент" достижения поставленных задач.
Я бы добавил, что AARRR позволяет тебе, как продуктовому человеку, фокусироваться в первую очередь на клиентском опыте. То есть, это не просто компонент платформы, за который ты отвечаешь, это реальный человек, для которого ты создаешь продукт.
Ну, а дальше уже, чем лучше мы продуктом решаем задачу клиента, тем он счастливее, а значит и фин.результат будет выше.
Прочитал на одном дыхании, как раз сейчас нахожусь в начале пути построения команды в олд компании. Вам успехов)
Очень интересная и компактная статья получилась, ждем еще!
Спасибо, рады стараться!
Новую уже выпустим когда мяса полезного наберем. Пока текущая структура команд актуальна и приносит пользу.
Спасибо, что делитесь опытом!
Расскажите как удавалось вести эксперименты целых четырех продуктовых команд? Были ли конфликты? Как решали?