Команды развития: стартапы внутри устоявшегося бизнеса?
Команды развития — проекты полного цикла продаж от разработки до сделки внутри компании, выделенные под определенный сегмент клиентов. По крайней мере, так это выглядит у нас. Как выстроена структура такой команды и как дружатся между собой процессы операционки и разработки с пользой для клиента и с профитом для бизнеса?
Пролог. Андрей
Одним прекрасным осенним вечером операционный директор UIS Андрей смотрел на капли дождя за окном и размышлял о вечном — о стратегии развития продаж на следующие пару лет. Было очевидно, что традиционная модель продаж унифицированной ценности продукта под всех клиентов скопом себя изжила. Так же как и линейная схема создания этих ценностей “продакты делают — продавцы продают”. Даже с оговорками качественного кастдева на этапе MVP.
Чтобы быть успешнее в продажах и актуальнее в разработке, требовалось адресно обращаться к отдельным сегментам потенциальных клиентов в обоих этих процессах.
Фокус именно на их потребностях и задачах обещал дать выхлоп как в виде большей конверсии лидов в продажи, так и в виде роста LTV и снижения динамики оттока ядра клиентской базы.
Основной вопрос — как развернуть процессы разработки и продаж так, чтобы они могли создавать и предлагать ценностное предложение разным сегментам клиентов. Решений виделось два: а) сегментировать текущую структуру продаж (а с ними и маркетинга) и разработки; б) создать новые рабочие группы из всех необходимых сторон в виде надстройки к устоявшейся структуре.
Трогать уже работающую структуру не стали и выбор пал на вариант Б. Так возникли команды развития. Одним из пионеров стала наша команда по интеграции UIS с Битрикс24 (и я отчасти затрагивала эту тему несколько с другого ракурса в гайде по построению партнерки в B2B).
Структура команды развития
Команда развития строится вокруг ниши или отрасли клиентов, потенциально результативной для бизнеса. И является для этого сегмента, по сути, микроклоном основного сервиса, однако более гибким и клиентоориентированным в силу небольшого размера команды. При этом в ее состав входят все необходимые звенья воронки привлечения, продаж и сопровождения клиентов наряду с разработкой.
Постоянная часть команды
У нас в UIS — в конфигурации масштабного устоявшегося бизнеса — постоянной и автономной частью команды развития является блок лидогенерации и блок аккаунтинга ключевых контрагентов, а также продакт-менеджер со стороны разработки. Это специалисты, которые постоянно сфокусированы на вверенном им сегменте аудитории.
При этом аккаунтинг ключевых контрагентов (в случае нашей команды — партнеров-интеграторов Битрикс24, или, например, VIP-клиентов в команде продаж премиум-сегменту) вынесен в одну из ключевых специфических компетенций команды развития не столько из-за необходимости выделить дополнительные ресурсы на сопровождение клиентов из нужного сегмента, сколько из-за самой цели создания команды развития.
Ребята из лидогенерации и аккаунтинга, тесно общающиеся “в поле” с потребителями сервиса, являются руками и глазами продакт-менеджера. Через них ему транслируются ценности и потребности клиентов определенного сегмента в доработках сервиса. И, в обратную сторону, через них же продакт-менеджер проводит быстрые бета-тесты сделанных доработок, максимально быстро улучшая их до “боевой” версии, массово поставляющейся остальным клиентам.
По факту, без этого у продакт-менеджера просто не хватило бы сил и ресурсов детально погружаться в разные сегменты клиентов и тем более — иметь возможность видеть результаты по привлечению и продажам, напрямую связанные с доработками под эти сегменты.
“Переменная” часть команды
Условно назовем ее так, держа в голове, что специалисты из этой группы точно так же состоят в постоянном штате компании. Их просто неэффективно забирать в отдельную команду развития на постоянной основе — скорее всего, они будут недозагружены.
Сюда, в первую очередь, входит исполнительный блок разработки, которому продакт-менеджер ставит конкретные задачи по доработкам, принесенные из команды развития. При этом, например, у нас в UIS используется фреймворк Scrum, в рамках которого продакт-менеджер планирует работу над новыми релизами двухнедельными спринтами.
Разработчики могут войти в состав рабочей группы команды развития на определенное количество таких спринтов — пока идет процесс доработки под конкретный сегмент клиентов.
Еще одна весомая часть “арендованной” части команды — специалисты из отделов продаж и консалтинга клиентов. Нуждаясь в компетенциях по включению, онбордингу и поддержке клиентов, команда развития при этом не создает особенных требований к этим процессам (кроме знания продукта, но это, вроде как, само собой разумеющийся фактор). Здесь достаточно действовать по стандартным скриптам и бизнес-процессам.
Впрочем, на старте деятельности команды развития лучше выделить в каждом из нужных подразделений ответственных сотрудников, которые будут работать с лидами из определенного сегмента. Понаблюдав за спецификой их онбординга и сопровождения, можно понять, потребуется ли корректировка стандартных скриптов или, скажем, дополнительное тематическое обучение клиентских менеджеров нюансам продукта.
Результаты эксперимента
Сейчас, по прошествии трех лет эксперимента с запуском команд развития внутри сложившегося операционного юнита, можно сказать, что у нас в UIS получилось. В среднем, число лидов из закрепленных за командами сегментов стабильно растет в 2-3 раза ежегодно. Как растет и число команд развития — Андрею нравится :)