Развивать платформенные продукты не просто. С бизнес-продуктами всё более менее понятно: развивать надо то, что приносит деньги. Тут главный вопрос, как узнать, что именно приносит деньги. Это тоже очень не просто, и на эту тему написано десятки статей и даже учебников.

В этой же статье хочу поговорить о том, какие сложности стоят именно перед платформенными продуктами. Если хотите узнать подробности — эта статья для вас.

Я развиваю платформенный продукт Ролевая модель в Альфа-банке последние 2 года и горжусь им. Мы действительно задаём тренды, находимся в топах практически любого рейтинга, нас копируют. И это здорово. Но сегодня не о рейтингах, а о развитии внутри прекрасного Enterprise.

Главные отличия между платформенными и бизнес продуктами

В процессах управления бизнес продуктов и платформенных продуктов есть несколько важных нюансов, которые нужно учитывать:

Критерий	Бизнес-продукты	Платформенные продукты
Кто заказчик	Внешние клиенты, приносящие деньги	Внешние клиенты + внутренние команды банка
Наша ценность	Выручка, прибыль, конверсия	Надёжность, удобство интеграции, наличие must-have функций
Доступные ресурсы	Аналитики, маркетологи, исследователи	Ограниченный доступ к аналитикам и маркетологам
Приоритет в компании	Главный приоритет — всё, что влияет на деньги	Приоритет по остаточному принципу*
Горизонт планирования	Краткосрочные победы (квартал-год)	Долгосрочный марафон (2-3 года)

Можно сказать, что зарабатывающие продукты — это дамагеры. А платформа — это саппорт.

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

Давайте попробуем разобраться в том, что нужно делать, чтобы ваш продукт ценили и уважали, а не относились к нему как что-то неприоритетное, чем можно пожертвовать.

Главное, что нужно знать про ваш продукт

Ваш продукт — это продукт поддержки

Если провести аналогию с играми, то вы — саппорт. Не пытайтесь строить из себя дамагера. Это крайне важно. Вам всегда необходимо работать в паре, находя партнёров, для которых вы делаете тот или иной функционал. Потому что ваше слово без поддержки продукта, зарабатывающего деньги, почти ничего не значит. Даже если вам кажется, что то, что вы делаете, очевидно нужно делать — это неудобно для пользователя или где-то плохая конверсия, которую вы хотите повысить, найдите заказчика, которому тоже важны эти конверсии и этот функционал. Вы не можете развивать свой продукт только потому что "это повысит конверсию на 25%". Повысит, и что? Кому это кроме вас надо? Саппорт в пати сам по себе бесполезен.

Мультивекторное развитие

Если продукт, зарабатывающий деньги, должен сконцентрироваться на 1-2 задачах и решать их всеми доступными способами в течении плюс-минус года, то для платформенного сервиса нормальна мультивекторность. Когда у вас в течение года условно 10 разных заказчиков, которым вы помогаете. При выполнении пункта 1, срабатывает замечательная поговорка: не имей 100 ₽, а имей 100 друзей. И это именно то, что ожидается от платформенного продукта. Хороший платформенный продукт — тот, у которого много потребителей. Если у вашего платформенного продукта мало потребителей — задумайтесь, зачем вы вообще нужны. Что-то вы делаете не то.

Помощь vs налог на корпорацию

Очень важно поймать баланс между тем, приносите вы пользу другим продуктам или же просто следите за соблюдением необходимых стандартов. Например, мы, как Ролевая модель помогаем разграничивать права и полномочия пользователей в продуктах, и при этом следим за тем, как продукты осуществляют работу с правами.

Часто бывали случаи, что наш сервис использовали неверно. Проверяли не наличие прав у пользователей, а название ролей. Не спрашивайте почему. А заставить продукт в дальнейшем перейти с проверки роли на проверку прав — не так-то просто. Особенно, если продукт приносит деньги — у него бэклог расписан на 2 года вперёд. И если это не влияет на большое кол-во пользователей.

Как искать этот баланс? Надо понимать, что на ваш продукт скорее всего в любом случае будут жаловаться. Ну зачем нужна Ролевая модель продуктам, которые нацелены исключительно на малый бизнес? Для них наш продукт — это налог на корпорацию. С точки зрения бизнеса им вообще не хочется с нами работать. И если обращаться к коллегам с нарративом о том, что они неверно используют ваш продукт, не согласно неким стандартам качества, то хороших отношений выстроить не получится.
А если подойти к коллегам с представителями среднего и крупного бизнеса, у которых миллиардные клиенты жалуются на непонятные продукты в интерфейсе — тут другое дело. Помните про пункт 1 — всегда ищите партнёров. Вы помогаете партнёру добиваться их целей. А то, что параллельно вы развиваете себя — это вторично.

Выстраивание отношений с другими коллегами

Вне зависимости от того, насколько, как вам кажется, хорошо вы делаете свою работу, насколько подробно у вас написаны инструкции и хорошо выстроены отношения с другими коллегами, я рекомендую проводить CSI опрос коллег, с которыми вы сотрудничаете.
Так как конфликты в крупных компаниях неизбежны, нужно иметь инструмент, позволяющий бороться с громкими заявлениями. Иногда они оправданы, а иногда кто-то специально пытается спихнуть вину на ваш продукт. Это нормально.

CSI позволит вам:

Замерить, насколько ваш продукт хорош как сервис в глазах коллег по цеху. Достаточно ли понятны ваши инструкции, достаточно ли быстро отвечаете вы или ваши сотрудники. Список улучшений, которые не нравятся вашим коллегам
В случае эскалаций или "А вот Пётр крайне недаволен Ролевой моделью..", вы можете однозначно сказать "С Петром мы отдельно сейчас разберёмся, но наш CSI 4,8. Скорее всего у нас не просто так разногласия с Петром". У CSI я вижу только один минус. В некоторых компаниях CSI опросы просят заполнить чуть ли не каждая команда, и тогда просьба заполнить очередной опросник превращается в какой-то спам. А вот если таких команд мало, можете брать на вооружение.

Также фиксируйте и собирайте статистику по тому, сколько новых потребителей у вас появилось, сколько доработок вы сделали по запросу коллег и так далее. Помните, топ-менеджмент про любой не приносящий деньги продукт раз в пол года спрашивает "А он точно нам нужен"?

Мой любимый пример незарабатывающего продукта — это онлайн-бухгалтерия для ИП, которая сейчас есть почти в каждом топ банке. Продукт с точки зрения денег — чёрная дыра. Инвестиций требует много, а качественно развивать его практически не получается, потому что все имеющиеся ресурсы обычно заняты тем, что адаптируют продукт под меняющееся законодательство. А продукт-то бесплатный. И раз в полгода в компании всегда задаются вопросом "А точно ли нам это нужно?" Потом вспоминают, что это один из базовых продуктов для привлечения малого бизнеса, и в случае его закрытия потеряется конкурентый паритет с конкурентами, и оставляют.

Стратегия развития, а не выживания

Все предыдущие советы помогут вам выжить и развиваться как платформенному продукту. Но если вы хотите не просто выжить, а влиять на стратегию компании - нужно изменить то, как о вас думают. Пора перестать быть саппортом и стать критической инфраструктурой. Пора поговорить об эволюции.

Позиция саппорта — это ловушка

В долгосрочной перспективе позиция вашего продукта в качестве поддерживающего — это ловушка. Нельзя долго оставаться в этой позиции. Если посмотреть концептуально, то со стороны большинства ЛПР в компании вы:

всегда в позиции просящего
вы не приносите деньги
в условиях кризиса вас режут первыми

Чтобы бороться с этим у вас должно быть сильное позиционирование. Сравните:

Язык продукта поддержки	Язык продукта критической инфраструктуры
Мы помогаем продуктам управлять правами	Без нас невозможно обслуживание корпоративного бизнеса, приносящего ₽X млрд
Сделали 50 интеграций с командами банка	Разблокировали 50 запусков бизнес-продуктов для клиентов среднего и крупного бизнеса
Наш downtime составляет менее 100 минут в квартал	Мы один из самых высононагруженных сервисов банка с нагрузкой в более чем 10 000 rps

Самое главное, что правдой является и то, и то. Выбор за вами, какой язык использовать. Одно дело сокращать кого-то из команды, помогающей продуктам управлять правами, а другое — сокращать кого-то из команды, без которого невозможно обслуживание корпоративного бизнеса.

Метрики, которые меняют ход дела

Чтобы коммуницировать на языке продукта критической инфраструктуры, вы должны уметь защищать этот статус. Сложнее всего спорить с цифрами, а значит они должны быть у вас под рукой.
Эти метр��ки помогут вам правильно спозиционировать ваш продукт:

Revenue dependency — Понимание того, что X% дохода всего банка зависит от вашего продукта — мягко говоря, весомо.
Чтобы рассчитать Revenue dependency:
- Возьмите список всех продуктов, использующих ваши сервисы.
- Запросите у продуктов размер годовой выручки
- Для продуктов, где вы critical (без вас они не работают) — возьмите 100% их выручки
- Для продуктов, где вы важны, но не явлетесь критичными — возьмите 50% выручки
- Получите итоговую сумму, которая зависит от успешной работы вашего продукта

Adoptions metrics. Сколько процентов продуктов используют наши сервисы. Так как вы стремитесь к увеличению потребителей вашего продукта, необходимо рассчитывать, сколько продуктов уже вас используют, сколько в принципе могут, а кто не будет вами пользоваться. По сути это аналог SOM, SAM, TAM, PAM. Только ваш размер рынка — это продукты внутри банка.

Аналогично подходу, по которому рассчитывается Revenue dependency, можно рассчитать следующие показатели:

Ожидаемый доход от подключенных продуктов за год. Нужно понимать, какова ожидаемая прибыль прибыль за год есть у подключенных в течение года продуктов. Для руководства звучит это как "Наш функционал помог в течение прошлого года заработать дополнительно X млн ₽ продуктам А, Б, В".
Cost of failure. Метрика помогает понимать стоимость минуты простоя. Метрика позволяет легче защищать ресурсы на задачи по повышению качества и стабильности. А так же, если вдруг кто-то замахнётся на ваш ресурс QA, то вряд ли согласится принять риск увеличения кол-ва ошибок, зная стоимость ошибки.

Наконец, полезно рассчитать

Cost of avoidance. Сколько команд/человек не пришлось нанимать, потому что существует ваш продукт. В нашем случае, какая выгода от того, что продуктам не пришлось самостоятельно разрабатывать ролевую модель. Посчитайте: если бы каждая из N команд делала свою ролевую модель, сколько бы это стоило? Возьмите среднюю стоимость команды из 5 человек на 6 месяцев (типичное время разработки платформенного MVP). Умножьте на N команд.

Конечно, этот список не исчерпывающий, его можно расширять или детализировать. Но начните хотя бы с этого.

Имея эти метрики под рукой, если кто-то задаст вам вопрос в стиле "А не много ли вы на себя берёте?" — эти метрики однозначно покажут, кто прав.

Как выстраивать стратегию и наполнять бэклог

Как вы понимаете, основной метрикой нашего продукта для позиционирования себя как критически важного инфраструктурного продукта является Revenue dependency. А достигается она в первую очередь через Adoptions, то есть через проникновение в другие продукты. То есть, чем больше продуктов используют вас, тем лучше. И конечно же, чем больше денег приносят продукты вас использующие, тем лучше. Чтобы продукты нас использовали, надо разрабатывать востребованный функционал.

Идеями для востребованного функционала мы обычно вдохновляемся идеями из следующих источников:

анализ конкурентов (не ограничивайтесь вашими прямыми конкурентами)
обратная связь от клиентов
запросы от смежных команд
задачи от ИТ
предложения от бизнес-партнёров
исследования рынка

В непосредственное построение стратегии углубляться мы не будем. Важно вот что.

Помните, что почти все ваши задачи должны иметь бизнес-партнёра. Когда мы ищем партнёров, не стоит позиционировать себя как критическую инфраструктуру. Снова меняем шапочку "крутого, без которого не обойтись" на шапочку саппорта:

Говорим с Руководством о бюджете	Говорим с другими командами
Без нас невозможны 15% выручки банка	Что мы можем сделать, чтобы ваши клиенты были счастливы?

Чувствуете? Два абсолютно разных подхода.

Когда собираете бэклог, не ожидайте, что партнёры сами придут к вам с просьбой сделать то или это. Такое тоже бывает, но реальность обычно работает по-другому. Обычно вы приходите с какой-то идеей для потенциального бизнес-партнёра, он её критикует и спрашивает "а вот это вы можете сделать?". И когда вы говорите да — случается магия. Он предлагает эту идею, а значит, будет в дальнейшем и сам помогать её защищать при необходимости.

Почему ещё это важно. Часто бывает, что несмотря на то, что ваш бэклог уже распланирован на год вперёд, приходят новые заказчики, которым срочно нужно что-то сделать. Далеко не у всех задач есть оценки в деньгах (мы платформенная команда с ограниченным доступом к ресурсу аналитиков, не забывайте), да и у нового потенциального партнёра оценки в деньгах может не быть.

И тогда ваш разговор строится очень просто. Вы сообщаете, что у вас есть обязательства перед А, Б, В, Г. Вы закоммитились на реализацию этих задач в определённом объёме и в определённые сроки. Вы абсолютно не против взять задачу вашего визави, но нужно договориться с кем-то из текущих заказчиков, чтобы он согласился подвинуть свою задачу или отказаться от неё. Обычно на этом этапе ваш визави смотрит на фамилии заказчиков и уходит. Или идёт договариваться. Важно, что вы не являетесь частью конфликта — по сути идёт борьба за ваш ресурс. А это хорошо, это показывает вашу востребованность.

Конечно, бывают случаи, когда прилетают задачи, от которых совсем нельзя отказаться. Но это тема для отдельной статьи.

Как рассказывать о том, что ты делаешь

Не менее важной частью развития вашего продукта является демонстрация ваших результатов и рассказы об этом. Особенно хорошо это работает, когда вы работаете совместно с другой командой. Для развития в компании с определённого уровня вам нужны именно совместные победы.

Что-то хоть сколько бы то ни было стоящее вы не сможете сделать одной командой. Да и ТОП менеджмент ищет командных игроков, а не супер-звёзд, считающих, что они способны затмить всех остальных. Ваша работа в команде ценится уже по тому, что она командная.

Часто кажется сложным рассказывать о ваших достижениях из-за:

синдрома самозванца
кажущейся незначительности заслуги
лёгкости задачи
отсутствия практики писать

Реальная причина —отсутствие практики. Всё остальное уйдёт как только напишите первые 10 постов.

Почитайте посты ваших коллег.

Нравятся? А теперь присмотритесь внимательнее, подумав, что именно пришлось команде сделать по факту. Зачастую там маркетинга больше, чем настоящей инженерной работы. И это нормально.
Не нравится? А кому-то из руководства нравится. Они вспомнят, что коллеги писали. Что коллеги могут рассказать о своих результатах. А вы не писали. Не попадались на глаза.

Тренируйтесь писать. Используйте AI как редактора, но не как автора. Ваш личный опыт и инсайты - это то, что делает пост ценным. ChatGPT сделает текст гладким, но безликим.

Выводы

Развитие продукта, не являющегося флагманом внутри компании не тривиальная задача. Добавьте сюда корпоративные джунгли, в которых команды дерутся за ресурсы — и станет понятно, что стратегия развития платформенных продуктов должна сильно отличаться от стратегии развития продуктов зарабатывающих.

Большинство команд застревают на уровне команды поддержки. Для роста в команду, которая ассоциируется с критически важной инфраструктурой, требуется знание нужных бизнес метрик и правильное позиционирование. И не только правильное позиционирование, но и умение разговаривать на двух языках в нужное время, в нужном контексте и с нужными стейкхолдерами.

Я бы разделил уровни зрелости платформенных команд на следующие этапы:

	Выживание	Поиск пути	Критический сервис
Обязательства	Команда справляется со своими обязательствами	Команда выполняет свои обязательства	Команда выполняет свои обязательства и успешно управляет ожиданиями коллег
Бэклог	Расписан на 1-2 квартала вперёд	Расписан на 1 год вперёд	Расписан на год вперёд, есть видение развития на горизонт 2-3 года
Внешние коммуникации	Минимальны	Команда рассказывает о том, что делает	Команда рассказывает о том, что делает красиво
Отношение к команде	Большинство не знает, зачем работать с этой командой	Команду воспринимают как важную, но периодически задаются вопросами Точно ли это так?	Команда — критически важный ресурс, чьё видение на развитие учитывают и уважают

Конечно деление условное, да и горизонт планирования в компании не всегда есть на более, чем 1 год, особенно в текущих условиях турбулентности.

А что вы думаете о развитие платформенных продуктов в Enterprise? Делитесь вашим мнением в комментариях. С какими сложностями сталкиваетесь вы, развивая платформенные продукты?

Спасибо за ваше внимание, если понравилась статья — возможно вам так же понравится мой Телеграм‑канал, в нём найдёте посты про:

В канале я пишу о том, как продактам развивать свои продукты и себя, как на практике использовать AI, работать с данными и выстраивать отношения с коллегами.

Как развивать платформенные продукты. Саппорт vs критическая инфраструктура