Привет, ты новый продакт? Добро пожаловать в команду! Меня зовут Ира Ивченкова, я Product Owner A/B-платформы Lamoda. Если ты, как и я, работаешь с внутренним продуктом, и это твой первый проект, располагайся поудобнее. 

Тебя ждут первые шаги и задачи в настоящем продуктовом мире. И я вижу, как ты горишь желанием применить все те крутые фреймворки, которые недавно освоил: ICE, RICE, SWOT и всю ту магию, что делает любого продакта мастером на все руки.

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

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

Ты готов? Пойдем вместе разбираться!

Флоу работы над фичей

Для начала внесем ясность в понятия. Пользовательским мы называем тот продукт, чья целевая аудитория — широкий круг пользователей. А внутренний продукт разрабатывается для применения узким кругом пользователей, которые находятся внутри компании и с помощью продукта решают свои рабочие задачи. 

Разберем типичный флоу работы над новой фичей в пользовательском продукте. Выглядит он примерно так:

1. Поиск точек роста.

2. Исследование рынка.

3. Сбор требований.

4. Приоритизация и оценка эффекта.

5. Проектирование и тестирование решения.

6. Разработка.

7. Мониторинг и обратная связь.

8. Маркетинг.

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

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

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

Поиск точек роста

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

Что бы ты начал делать в первую очередь? 

• Анализировать текущие метрики продукта, чтобы выявить области с потенциалом улучшения.

• Изучать пользовательское поведение и собирать обратную связь.

• Отслеживать рыночные тренды и действия конкурентов для выявления новых возможностей.

Ты думаешь в верном направлении. Но тут есть особенности. Скажи, есть ли какие-то понятные метрики у твоего внутреннего продукта? 

Количество пользователей? Ответ неверный.

Количество пользователей = количество аналитиков в компании

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

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

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

С какими вызовами ты столкнешься:

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

• Продакт внутреннего продукта крайне редко имеет своего аналитика для того, чтобы делать воронки, смотреть в дашборды, искать инсайты в данных и так далее. 

• Не всегда рыночный тренд означает, что он нужен внутреннему продукту. Приоритетнее особенности и потребности бизнеса, чем то, что делают конкуренты. 

Как предлагаю делать я:

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

• Искать не только проблемы пользователей, но и проблемы бизнеса — несмотря на то, что твой продукт внутренний, он может двигать весь бизнес к росту.

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

• Подумать заранее, какую информацию о продукте хотелось бы собирать, и придумать способы сбора внутри продукта. 

Например, в нашей А/В-платформе одно время часто останавливались и перезапускались А/В-тесты, что в свою очередь влияло на time-to-market. Чтобы это исправить, мы сделали простой шаг — при остановке эксперимента запустили модальное окно, где попросили пользователей описать причину остановки, объяснив свою задачу. В результате мы выяснили, что много А/В-тестов перезапускаются из-за багов в событиях — и это наша точка роста.

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

Исследование рынка

Что ты как продакт пользовательского продукта будешь делать, чтобы изучить рынок? 

Полагаю, ответ будет примерно такой:

• Проводить интервью с пользователями, фокус-группы и опросы для сбора качественных данных.

• Анализировать тенденции рынка и отчеты по отрасли.

• Смотреть, что там у конкурентов, какие предложения они делают своим пользователям.

В чем проблема применения во внутреннем продукте:

• Часто с внутренними процессами и продуктами все идет не так гладко, как с внешними. Пользователи — коллеги могут настолько привыкнуть даже к самым неудобным процессам, что не рассматривают варианты, как можно иначе. Проблемы часто приходится выявлять самому.

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

• То, что ты знаешь о продукте конкурентов, о том, как он устроен, не означает, что такой способ подходит под особенности вашего бизнеса.

Как предлагаю делать я:

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

• Договариваться о демо с похожими сервисами, или через нетворкинг находить людей, которые готовы показать устройство своих платформ.  Многие внутренние сервисы имеют свои аналоги на рынке b2b-продуктов и готовы рассказывать о них. Я часто пользуюсь этим способом, для меня он всегда источник вдохновения и новых идей, что можно внедрить.

Сбор требований

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

Что бы ты делал как продакт пользовательского продукта

• Собирал требования с заказчика.

• Формировал документацию.

В чем проблема применения во внутреннем продукте

• Часто заказчик и пользователь — это одно и то же лицо. 

• Заказчиков может быть несколько, и требования каждого уникальны и важны. Между ними нужно уметь ловко лавировать, поэтому бывает почти невозможно расставить приоритеты.

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

• Пользователи часто приходят не с проблемой, а с решением. Так устроен наш мозг — он склонен предложить быстрое решение, а не анализировать проблему, искать ее корень и накладывать на разные кейсы. Поэтому часто решения, которые приносят пользователи — это «заплатки», которые могут решить проблему — быстро, но при более глубоком рассмотрении окажется, что не очень качественно.

Пример. В Lamoda используется сервис TestIT, куда тестировщики заносят критически важные юзер-кейсы и тестируют их при каждом релизе приложений. Когда заводится новый А/B-эксперимент, продакт-менеджер должен получить от тестировщика и добавить на А/B-платформу ссылку на заведенный юзер-кейс. Так мы можем посмотреть, как эксперимент изменит пользовательский путь в приложении. 

Но не всегда продакты делали это. Тогда тестировщики пришли ко мне с задачей — добавить перед запуском эксперимента обязательный чекбокс «юзер-кейсы добавлены в TestIT». 

Погрузившись в детали, я выяснила:

• не все продакт-менеджеры не знают об использовании инструмента, 

• чекбокс нужен только при запуске экспериментов в приложении, исключая десктоп.

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

• Чаще всего в пользовательском продукте меньше возможностей для контакта между продактом и пользователем — ты один, а аудитория может быть миллионная. Если же ты ведешь внутренний продукт, то находишься со своими заказчиками в тесном контакте. Они сидят на соседнем стуле в офисе, участвуют с тобой в одних и тех же созвонах, вы ходите вместе на обед и возможно, подписаны друг на друга в соцсетях. Это важная особенность, которая позволяет действительно глубоко понимать пользовательскую проблематику.

Пример. Я продакт аналитического продукта, хотя не являюсь аналитиком. Это мне абсолютно не мешает при сборе требований. Проблематика — в том, что мы не всегда можем понимать потребности пользователей, потому что их задачи не являются нашей рутиной. Значит, важно задавать правильные вопросы, которые выведут на реальную необходимость в определенной фиче. Мои скилы состоят в том, чтобы правильно интерпретировать то, что говорят пользователи моего продукта. 

Как предлагаю делать я:

• Искать связанности продуктов и бизнес-процессов.

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

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

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

Приоритизация и оценка эффекта

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

Что ты будешь делать на месте продакта пользовательского продукта:

• Оценивать влияние каждой фичи на метрики (а хороший продакт еще и доводит оценку эффекта до денег).

• Использовать фреймворки для оценки фичей (RICE, ICE).

В чем проблема применения во внутреннем продукте:

• RICE/ICE почти не применимы во внутреннем продукте, так как вполне возможна ситуация, что объем аудитории фичи не превысит двоих  человек. При этом фича закроет большой пласт проблем или откроет новые возможности для роста выручки компании.

Например, switchback-тестирование необходимо только команде доставки, и пользоваться ими будут три продакта, и то не в каждом эксперименте. Но наличие такого тестирования позволяет принимать data-driven решения в важной части пользовательского опыта.

• Заказчиками внутреннего продукта могут быть как сами пользователи, так и руководитель, который хочет автоматизировать какой-то процесс. В таком случае часто встает вопрос приоритизации тасок между руководителем одного подразделения и сотрудниками другого (или вообще между руководителями разных подразделений).

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

• Иногда сложно корректно оценить профит всех команд по вкладу в Nord Star Metric. Заказчиками могут быть две разных команды — например, продуктовая аналитика и команда прайсинга. На первый взгляд, у них нет общей метрики (она же Nord Star) — для аналитиков ты снижаешь трудозатраты и автоматизируешь процессы, а для команды прайсинга добавляешь фичу, которая позволяет им проводить А/В-тесты в целом. Такие кейсы во внутренних продуктах сложно решать, так как помимо очевидных факторов вроде «от какой фичи профит сильнее» в силу вступают еще и политические — под ними подразумеваем, что является приоритетом компании, где более активные пользователи, кто заявил о себе громче всех и был услышал сверху, и так далее.

Как предлагаю делать я:

• Лучше всего подошла старая добрая таблица со скором, в которой я прописываю критерии и указываю вес каждого, а потом суммирую. Критерии можно выбрать любые, лишь бы они отражали реальные зоны влияния продукта и не менялись с появлением новой фичи. Ниже приведу таблицу скора для А/В-платформы. Вот и изучай современные методологии :) 

• Не забывай, что у внутреннего продукта тоже должна быть стратегия. Соответствие ей можно использовать как критерий скора, чтобы понимать, какие фичи приближают продукт к достижению целей

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

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

Звучало это примерно так: «Мы на 2 недели быстрее разработаем фичу, которая позволит проводить А/В-эксперименты на N дней быстрее. В месяц у нас A экспериментов, из которых B успешных, это позволит компании заработать +N% GMV». Попробуйте — на языке денег с бизнесом общаться проще.

• Если прошлый пункт не подходит, можно попробовать ориентироваться на снижения затрат сотрудников на определенный бизнес-процесс или на снижение рисков. Чаще всего бизнес знаком с инцидентами и понимает, какие потери возможны.

• Если не получается найти метрики, начни со сбора статистики. Через некоторое время статистика начнет собираться в метрики, а метрики в деревья. Да, это может быть долгий процесс. Скажу по секрету, я сама до сих пор не вывела Nord Star моего продукта, но я уже определенно близка к этому.

Проектирование и обкатка решения на тестовой группе

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

Что ты стал бы делать в роли продакта пользовательского продукта:

• Дал задачу дизайнеру разработать макеты и провел на них количественные исследования на большую аудиторию. Это можно делать через собственные каналы и через специальные сервисы вроде Яндекс Толоки.

• Провел глубинные интервью с пользователями.

В чем проблема применения во внутреннем продукте:

• Если на твой продукт есть выделенный дизайнер, это большая удача! Но часто его нет.

• Возвращаемся к вопросу об аудитории — она так мала, что количественное исследование провести невозможно. Даже если ты проведешь его во внутренних чатах, то скорее всего обнаружишь, что у 5-10 разных людей могут быть абсолютно разные потребности. 

Как предлагаю делать я:

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

• В случае работы над внутренним продуктом лучший инструмент для избежания несоответствия ожиданиям заказчика — демонстрация. Я всегда до начала разработки делаю демо с заказчиками и показываю экраны, проходя с ними флоу работы. Так ты сможешь сократить time-to-market фичи и избежать ситуации, когда пользователь ожидал одно, а получил другое.

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

Мониторинг и обратная связь после релиза

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

Здесь возникают похожие проблемы.

Что обычно делает продакт пользовательского продукта:

• Проводит А/В-тестирование.

• Смотрит на метрики и проводит продуктовый анализ фичи.

• Проводит глубинные интервью с пользователями.

• Устраивает количественные исследования.

• Анализирует запросы в поддержку.

В чем проблема применения во внутреннем продукте:

• Если у тебя есть возможность провести А/В-тестирование твоего внутреннего продукта, за тебя можно только порадоваться (но не от всего сердца :) ). Но чаще всего банально нет такого объема пользователей, чтобы получить статистическую значимость.

• Снова повторю, что у твоих пользователей часто нет выбора — пользоваться сервисом или нет, поэтому смотреть DAU на графиках бессмысленно (из-за этого часто и на другие метрики тоже).

• Для количественных исследований, как я уже говорила, во внутренних продуктах не хватает объема аудитории.

Как предлагаю делать я:

• Создать точку опроса в самом продукте — например, модальное окно с опросом.

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

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

Я решила задачу так: при запуске теста на A/B-платформе добавила обязательный шаг в виде апрува аналитика. И возникли вопросы:

• Есть технические команды, которые используют платформу для проверки, что новая фича ничего не уронила на проде. У них нет аналитика. Кто сможет взять на себя роль апрувера?

• Как мне понять, что с новым решением не стало хуже? Что я не усложнила жизнь своих пользователей и не сломала чей-то бизнес-процесс?

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

Примеры того, как мы собираем обратную связь: 

Маркетинг

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

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

Что обычно делает продакт пользовательского продукта:

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

• Если фича важная, то готовит онбординг для пользователей, в котором поясняет, как ее использовать.

В чем проблема применения во внутреннем продукте:

• Отдельной команды маркетологов у внутреннего продукта нет. Но есть базовые элементы маркетинга (как минимум, обычно продакт или тимлид разработки сообщает в общем чате о том, что катнули новую фичу).

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

• Пользователям часто важно знать, не только как пользоваться фичей, но принцип ее работы под капотом. Например, если продукт аналитический, как у меня, знай — все твои фичи будут рассматривать под микроскопом. Аналитики это требовательная целевая аудитория, которой важно знать всё — от процесса сбора данных до используемых статистических критериев.

Как предлагаю делать я:

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

• Наладить систему работы с аудиторией своего продукта. Продакт имеет более глубокое погружение в контекст пользователей и более плотный контакт с ними, потому что они иногда буквально сидят на соседнем стуле. Мои рекомендации выглядят так:

  1. Собирай комьюнити ваших пользователей в отдельный чат.

  2. Сообщай в нем о релизах новых фичей.

  3. Проводи демо функциональности раз в месяц.

  4. Подводи итоги квартала и делись планами на следующий.

  5. Собирай раз в квартал фидбек о своем продукте.

  6. При необходимости проводи демо раз в пару месяцев на всех желающих в компании.

  У нас в Lamoda Tech это можно сделать на встречах под названием Tech Talk, где коллеги рассказывают о конкретном продукте или изменениях в нем. Еще есть регулярные встречи продуктовой гильдии.

  7. Еще один формат — проводить discuss club, где обсуждать с активными заказчиками интересные статьи и новые подходы.

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

Заключение 

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

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