Держим руку на Pulse: используем продуктовый подход при создании корпоративного портала

Исследование аудитории, планирование, аналитика и стартап-подход. Всё о том, как выглядит разработка корпоративного портала Semrush изнутри.

Привет, меня зовут Маша Ющенко, я Product Owner портала Pulse в Semrush. Уже полтора года я занимаюсь развитием продукта с нуля. Местами это больно, но всегда интересно и волнующе. Обо всём по порядку.

Pulse — корпоративный портал, где собраны список сотрудников с возможностью поиска, новости компании и анонсы мероприятий, календарь, информация о бенефитах (всевозможные компенсации и их условия, приятные бонусы для сотрудников) и корпоративная библиотека.

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

Кроме того, мы интегрировали наш продукт с корпоративным мессенджером Slack, чтобы получать уведомления о статусах заявок и напоминания о днях рождения коллег (накануне праздника канал в Slack создаётся автоматически, куда приглашаются все, кто работает с именинником).

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

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

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

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

Во-вторых, некоторые решения уже существовали в компании, им требовалась только помощь «феи-крестной»: современный код и user-friendly дизайн.

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

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

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

Заказчиками выступили коллеги из HR-департамента. Ещё до появления команды продукта они собрали верхнеуровневые проблемы, с которыми сталкиваются сотрудники, лиды, операционные отделы и HR.

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

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

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

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

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

По итогам опросов и интервью мы выделили задачи, требующие немедленной разработки:

Для публикации новостей есть два канала – почта и Slack. Спустя месяц сложно найти нужную информацию, мало кто помнит, где именно был опубликован тот или иной анонс. В Pulse мы всё собрали вместе и сделали удобный поиск по архиву.

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

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

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

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

Мы провели презентацию Pulse для лидеров мнений во всех локациях: рассказали о продукте и наших дальнейших планах. Так, мы смогли заручиться поддержкой коллег, которые сами начали рассказывать о продукте внутри компании. У нас появились первые пользователи.

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

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

Признаюсь, что решиться на это было одним из самых сложных решений для меня как для Product Owner’а: Pulse казался мне не таким серьёзным и масштабным проектом на фоне крутых основных продуктов компании для клиентов.

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

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

Вот почему мы двигаемся итеративно: при релизе учитываем приоритетные запросы и проблемы, быстро прорабатываем решение, проводим UX-тесты, обсуждаем с командой простую, но надёжную реализацию.

Этот подход похож на HADI-циклы (Hypothesis —> Action —> Data —> Insights). У нас есть гипотеза; затем мы проверяем, есть ли проблема в действительности; разрабатываем решение, если проблема есть; анализируем данные; делаем выводы и продолжаем улучшать решение.

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

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

Для прозрачности мы сформировали видение продукта — что хотим получить через 1-2 года.

Например, к концу 2022 года мы планируем превратить Pulse в центр всех запросов в компании.

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

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

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

В этом разделе всё о метриках: как мы отслеживаем развитие продукта и определяем его успешность.

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

Чтобы следить за важными метриками и понимать, достигает наш продукт успеха или нет, мы создали дерево метрик.

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

В течение этого периода важно, чтобы пользователи возвращались. Мы акцентировали внимание на общую картину: прирост новых пользователей, MAU (Monthly Active Users), Retention и Сhurn Rate.

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

Мы учитываем MAU, так как задачи, которые решает продукт, не возникают перед сотрудниками ежедневно. Это периодические, но важные процессы, которые должны проходить гладко, без долгих поисков. Что и удается нашему продукту. Среднее значение за четвертый квартал 2021 года: 80% сотрудников пользуются продуктом ежемесячно, а 60% — более трёх раз в месяц.

Кроме того, портал предлагает пользователю заполнить NPS-форму, которая появляется на третий день использования и показывается повторно через 90 дней после оценки.

Мы провели первый раунд Product Market Fit (соответствие продукта рынку) опросов, но получили слишком маленькую конверсию в ответ: из 100 человек только 15 заполнили форму. Этих данных недостаточно, чтобы определить, достигли ли мы Product Market Fit в компании, однако подобные опросы — хороший способ получить обратную связь, понять, какие функции чаще всего отмечают, а какие хотят видеть в будущем.

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

Мы внедрили возможность предложить новую опцию и проголосовать за неё в интерфейсе продукта. На этой странице можно увидеть дорожную карту и ссылки на новости о последних релизах.

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

Только вперёд! Для развития продукта именно первый год является решающим: он показывает, стоит ли дальше продолжать работу и вкладывать силы и время в проект.

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

Часто компании не так много времени и ресурсов уделяют внутренним проектам. Мне кажется, это неправильный подход. Я, как Product Owner внутреннего продукта, считаю, что сотрудники — важные пользователи. От их комфорта и эффективности взаимодействия зависит успешность компании в целом.