Customer-driven product teams
Как Hubspot и Drift ведут разработку продукта
Мы уже обсудили как построена работа над продуктом в Netflix, сегодня посмотрим на другую компанию – Drift. У нас эта компания малоизвестна (конкурент Intercom), как впрочем и Hubspot, но и мы будет говорить не о компаниях, а о подходах к разработке.
Основная идея: небольшие инженерные команды, которые общаются напрямую с пользователями и отвечают за конкретную часть продукта от начала до конца.
Как это работает
Теперь немного подробнее:
Три человека в команде, техлид плюс два разработчика. Если продукт большой/сложный, команд может быть много. У Hubspot в какой-то момент было около сотни.
Нет QA и BA, но есть выделенный PM и дизайнер. PM/дизайнер больше как вспомогательный ресурс, для user research и UX/design экспертизы.
Команда принимает все решения по продукту, “ведет” фичу от идеи и обсуждения с пользователем до релиза (деплоя) и поддержки (!). Команда же выбирает инструменты и процессы, которые ей нужны для работы.
Нет публичного роадмапа или списка фич, который приходит “сверху”. Вместо этого команда формирует беклог задач на основе фидбека от пользователей и продуктовых метрик ($$/NPS/etc.), а менеджмент планирует на уровне “цели на квартал-полугодие-год”.
Короткие итерации. Выпустили фичу, собрали фидбек, решили стоит ли развивать дальше или тихонько “похоронить”. “Сырые” фичи точно также идут сразу на прод, но “закрываются” от пользователей через feature flags.
Зачем это бизнесу
Как такой подход выгоден с точки зрения бизнеса (компании):
Faster iterations. Скорость итераций критически важна для любого стартапа, поэтому разрушая барьер между разработчиками и пользователями растет скорость “обучения” команды и скорость релиза новых фич.
Lower management overhead. Для команды из трех человек не нужен отдельный менеджер и не нужны сложные процессы.
Higher NPS. Пользователи, скажем прямо, не разбалованы вниманием разработчиков. Когда ты пишешь в чат на сайте и через 30 минут тебе отвечают “исправили, попробуйте перезагрузить страничку” такое не забывается. По себе знаю.
Higher employee NPS/Retention. Более автономные команды → более счастливые и мотивированные сотрудники → меньше текучка.
Scalable teams. По мере роста продукта ты просто добавляешь (дробишь) команды, каждая из которых отвечает за более узкий “срез” продукта, не усложняя при этом процессы.
Еще почитать
Ссылке по теме:
Выступление David Cancel на Business of Software 2016. Если дослушать до конца, то в секции Q&A можно услышать вопрос автора этой рассылки)
Подкаст Seeking Wisdom, с тем же David Cancel. Особенно ранние выпуски, где они много времени уделяют построению работы над продуктом.
Выпуск рассылки про разработку в Netflix. Если пропустили)
Вместо заключения
Как думаете, может такой подход сработать в украинских реалиях? Если знаете компании, в которых так построена работа над продуктом, дайте знать, интересно.
На сегодня все, спасибо что дочитали до конца.
В следующем выпуске – о важности тестировании гипотез (Wrong by default).