Большинство статей про Product Owner написаны про один архетип: есть пользователь, есть фича, есть дашборд с DAU. Я Internal PO в банке — управляю бэковым оркестратором заявки на автокредит, и моя реальность устроена иначе.

Когда меня спрашивают, чем занимаюсь, я говорю: управляю продуктом. Дальше идёт стандартный вопрос «О, что за приложение?», и я делаю паузу. Мой продукт — сервис, через который проходит каждая заявка на автокредит: от первого клика в мобильном приложении до момента, когда документы уходят в архив. Он живёт между фронтовыми каналами (мобильное приложение на Android и iOS, веб-версия, фронт-приложение дилерских центров) и почти двумя десятками смежных систем банка. Если он встаёт, процесс автокредитования встаёт целиком. Но его никогда никто не видел: экрана нет, кнопки нет, «нельзя пощупать».

Моя должность — Internal PO. На Habr про эту роль почти ничего не написано. Под катом — про то, что считаешь продуктом, когда твои пользователи сидят внутри компании; про три ловушки, в которые попадаешь в первый год; и про инструменты, которые реально помогают сделать ценность внутреннего продукта видимой для бизнеса.

Контекст: кто такой Internal PO и почему это не то, что вы думаете

Большинство статей про владельца продукта описывают один архетип: есть пользователь с улицы, есть фича, есть дашборд с DAU и retention. PO стоит между бизнесом и командой, переводит хотелки в задачи, расставляет приоритеты в бэклоге. Всё измеримо.

Internal PO — это PO внутреннего продукта. К внутренним продуктам относится всё, чем пользуются сотрудники компании, а не её клиенты: CRM, операционные системы, HR-сервисы, аналитические платформы, ETL-пайплайны, оркестраторы бизнес-процессов. У меня — последнее.

Мой «пользователь» — команды внутри банка, для которых мы делаем интеграции. Мой «клиент» — внутренний заказчик из бизнес-блока розничного кредитования. Мой «продукт» — оркестратор, который ходит в смежные АС и собирает их результаты в единый жизненный цикл заявки на автокредит. Работает круглосуточно, и большую часть времени о нём не вспоминают.

Здесь не онбордят новых пользователей, не запускают A/B-тесты кнопок и не считают NPS по итогам квартала. Зато есть SLA, который нельзя нарушать, потому что за ним стоят реальные сделки с реальными машинами и реальными клиентами банка. Есть полтора десятка команд-смежников, каждая из которых считает свою интеграцию самой важной. Есть легаси-решения, которые придётся поддерживать ещё пять лет. И есть постоянный вопрос на ретро: а что именно я сделала за этот спринт?

У роли почти нет публичного языка. Те, кто в ней работает, заняты работой, а не статьями.

Главная проблема: невидимость

Один эпизод я запомнила надолго. Еженедельная встреча с биг-боссами, все продуктовые команды рассказывают о своей работе и статусах. Мне пишут: «ты не нужна, это для продуктов с клиентами». Мой оркестратор при этом обслуживал заявки всех каналов, представленных на этой встрече.

Невидимость для меня — это не про обиду, а про системную штуку, которая проявляется в трёх местах.

Тебя нет в стратегии

Когда бизнес рисует карту продуктов, внутренних сервисов там нет. Есть мобильное приложение, есть интернет-банк, есть кредит наличными и автокредит — то, что напрямую приносит выручку. Где-то внизу мелким шрифтом — «инфраструктура и интеграции». Никаких OKR или продуктовых стратегий сверху не приходит, потому что внутренний продукт по умолчанию воспринимается как cost center, а не как точка роста. Стратегию ты формируешь сама, без запроса и без внешнего ориентира. На первый взгляд это похоже на свободу, на практике — на работу в вакууме, где непонятно, правильно ли ты вообще двигаешься.

Твой ROI никому не очевиден

Продуктовый PO может сказать: внедрили фичу — конверсия выросла на 3%. Всё понятно, все довольны. Я говорю: разделили сервис на два, теперь команда А получает информацию по своим заявкам отдельно от канала Б. И дальше мне нужно это объяснять, переводить в деньги, доказывать причинно-следственную связь. Внутренний продукт не приносит выручки напрямую, поэтому твоя ценность всегда выглядит как «спасение от потерь», а спасённые потери считать тяжелее, чем рост конверсии. Самое коварное в том, что когда всё работает хорошо, тебя не замечают вообще. А когда что-то падает — замечают сильно. Особенно если в этот момент в дилерском центре сидит клиент и мечтает уехать на новом авто.

Команда теряет ощущение результата

Мы выкатываем подкапотную фичу (например, переводим повторные вызовы смежной системы с синхронных ретраев на асинхронные задания), и если всё прошло хорошо, соседняя команда даже не заметит. Никаких аплодисментов, даже «спасибо» в чате не будет. Со временем это давит, особенно на людей, которые привыкли видеть результат своей работы.

С этим можно жить, но об этой реальности почти не пишут: Internal PO либо привыкает и молчит, либо уходит в роль PO клиентского продукта. Третий вариант — разобраться, как с этим работать.

Ложные решения, которые не работают

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

Ловушка №1. Копировать метрики потребительского продукта

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

Ловушка №2. Делать всё, о чём просят смежники

Когда тебя никто не видит, появляется соблазн доказывать пользу через сговорчивость. Команда мобильного приложения просит срочно добавить поле в API — беру в спринт. Фронт дилерских центров хочет свой формат статусов — беру в спринт. Бизнес-заказчик приносит ещё один сценарий — беру в спринт. Снаружи всё хорошо: меня хвалят, в чатах ставят сердечки, задачи закрываются. Внутри я незаметно превращаюсь из владельца продукта в стол заказов. Внутренние пользователи особенно умеют этим пользоваться: они знают людей в команде, заходят в личку, нажимают на ту самую кнопку «ну ребят, ну очень надо». Через полгода в API пятнадцать костылей под пятнадцать каналов, архитектура трещит, а каждый новый смежник всё равно недоволен — потому что свою боль он считает важнее любой другой. Помогаешь всем, а продукта со своим видением у тебя уже нет.

Ловушка №3. Уходить в технические детали

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

У всех трёх ловушек общая природа: они закрывают симптом «меня не замечают», а настоящая проблема в другом — у тебя нет языка, на котором ценность внутреннего продукта становится очевидной без дополнительных объяснений.

Что реально работает: система, которую я выстроила

Всё, что ниже, — это способы, которые я попробовала и которые сработали.

Измерять боль до и после, а не активность

Я перестала считать, что я делаю, и начала считать, что меняется для других. Внутренний продукт не приносит выручки сам по себе, поэтому единственный способ показать его ценность — через изменения в жизни тех, кто им пользуется. Когда команда приходит с задачей, прежде чем брать её в бэклог, я фиксирую точку А: что работает плохо, какую боль нужно решить. После выкатки фиксирую точку Б. Разница между А и Б и есть ценность.

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

Оговорюсь: бизнес-фичи здесь — исключение. Их ценность считается через классические продуктовые метрики.

Переводить технические результаты на язык последствий

Любой технический результат можно переформулировать через простой вопрос: и что это значит для бизнеса?

Было: «реализовали репроцесс в случае 500ки от смежной системы».

Стало: «в случае недоступности заявка всё равно пройдёт свой путь без привлечения клиента — сокращение потерь».

Было: «реализовали byPass решение создания структуры папок».

Стало: «убрали причину инцидентов в процессе создания заявки за последние полгода — стало меньше эскалаций».

Это честный ответ на вопрос «ну и что?», который любой стейкхолдер задаёт себе мысленно и редко произносит вслух.

Два инструмента работают в связке: измерение боли даёт аргументы, перевод на язык последствий даёт коммуникацию.

Про мотивацию команды: как держать огонь, когда результат невидим

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

Со временем у людей возникает ощущение, которое сложно сформулировать, но легко узнать: «мы работаем, но непонятно зачем». Я с этим борюсь одним способом: создаю обратную связь внутри, не жду снаружи. Каждый раз, когда команда-потребитель говорит что-то хорошее в чате, на встрече или в письме, я фиксирую это и приношу команде. «Ребята, мы выкатили фичу, и теперь поддержка ходит счастливая, что мы их разгрузили». Простая вещь, но она работает.

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

Хорошая дорога незаметна. Никто не думает о качестве асфальта пока едет — думает только когда трясёт. Хороший внутренний продукт устроен так же: его не замечают, пока он работает.

Кто твой клиент, если клиента нет?

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

Очевидный ответ: клиент Internal PO — это команды-потребители, внутренние пользователи.

Но если по-честному, клиент Internal PO — это весь продукт компании целиком. В моём случае — весь процесс автокредитования банка: от первого клика клиента в мобильном приложении до момента, когда машина выезжает с площадки дилера. Мой продукт стоит в середине этой цепочки, и от того, как он работает, зависит, дойдёт ли клиент банка до конца или развалится по пути.

Когда внутренний продукт работает плохо, ничего не падает одномоментно. Просто каждая команда работает как при лёгком кислородном голодании: ни один орган не отказывает, движения вроде те же, но всё немного медленнее и менее точно, и чуть больше времени уходит на обходные пути вместо реальной работы. В нашем случае это значит, что клиент в дилерском центре ждёт решение по заявке на пять минут дольше — а пять минут — это разница между подписанным договором и клиентом, который вышел подышать и не вернулся. Параллельно каждое такое «чуть медленнее» оседает звонком в поддержку и эскалацией в оперативный центр, где живые люди вручную разбирают то, что должно было пройти само. Со стороны это не выглядит как проблема, выглядит как обычная корпоративная жизнь. Пока не посчитаешь.

Внутренний продукт в большом бизнесе работает как кровеносная система: пока кровь свободно идёт ко всем органам, никто о ней не вспоминает, все хвалят руки, ноги и улыбку. Сузишь сосуды — тело не падает в обморок сразу, оно просто живёт чуть хуже: меньше энергии, медленнее реакция, больше усталости к концу дня. Поэтому Internal PO — не менее важная роль, чем PO с живым пользователем.

За всё время в этой роли я почти не встречала русскоязычных статей, написанных Internal PO про свою работу изнутри. Кое-что есть: переводы западных материалов, разборы внутренних платформ и IDP, отдельные тексты продактов с опытом внутренних продуктов в банке. Но это либо про платформы для разработчиков, либо про внутренние продукты, которые сами приносят выручку. Живого голоса того, кто держит в голове полтора десятка смежных систем и каждую неделю заново подбирает слова, чтобы нетехническим стейкхолдерам стало понятно, во что именно ушёл спринт, — этого я не нашла.

Эту статью я написала в том числе чтобы проверить: есть ли такие люди вообще. Если кто-то узнал себя в описании, мне будет интересно встретиться в комментариях.

Internal PO — это либо самая невидимая роль в продукте, либо самая важная инфраструктурная. Какой она получится, зависит от одной вещи: умеешь ли ты делать видимым то, что работает в темноте.