Портал №1 по управлению цифровыми
и информационными технологиями

Продуктовые метрики для enterprise/b2b или gov продуктов

Как ответить на вопрос: насколько успешен наш продукт? Как оценить насколько мы продвинулись вперед, к нашему пониманию успеха, или наоборот, насколько мы отступили назад? Можем ли мы объективно измерять эту метрику успеха?

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

Практики часто выстраивают наборы метрик в соответствии с AARM:

  • Аcquisition – набор метрик, доказывающий наличие интереса к продукту;
  • Activation – метрики, направленные на измерение того, как происходит процедура приобретения, получение возможности использования продукта;
  • Retention – то, что демонстрирует нам уровень заинтересованности потребителя после того, как он получил опыт использования нашего продукта;
  • Monetization – финансовые метрики вокруг продукта, его потребителей.

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

Что позволяет им с меньшими усилиями получать работающие наборы метрик во всех этих областях?

  1. Неограниченный ресурс пользовательской базы: даже такие гиганты как Amazon, WeChat, Alibaba, Facebook могут сказать “ну вот все жители Индии и Китая поголовно являются нашими пользователями, за исключением отдельных районов, населенных моржами и пингвинами, весь мир охвачен – возможности по органичному росту пользовательской базы исчерпались”.
  2. Перечень возможностей и попыток предложить потребителю продукт весьма широки, стоимость потерь от отказа низка, возможны повторные предложения.
  3. Получение обратной связи о характере использования продукта, удовлетворенности, дополнительных потребностях может быть получена достаточно легко и быстро от некоторой репрезентативной доли пользовательской базы.
  4. Потребитель, чаще всего, является покупателем.
  5. Наличие известных и мощных инструментов для получения и анализа данных от платформодержателей (Google, Amazon, Facebook и др.).

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

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

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

Публичные gov/некоммерческие услуги

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

Из определения “успеха” таких продуктов могут уйти метрики, связанные с пользовательской выручкой, но гарантированно останутся все метрики связанные с измерением путешествия пользователя.

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

Метрики должны учитывать специфику пользовательских взаимоотношений: нет смысла привлекать только что заменившего права водителя приглашением “купить еще записаться снова в 2 клика” – даже если ему понравилось :). Тем не менее, привлечение и удержание пользователя остаются важными: неоцифрованные услуги вне продукта дороже предоставлять пользователю, отличаются и общие риски ошибок и злоупотреблений.

B2B продукты, inhouse разработка

Задача доказательного измерения успешности таких продуктов наименее проста.

С чем приходится считаться:

  1. Покупатель/спонсор обычно отличается когорты непосредственных пользователей, интересы и потребности этих ролей отличаются.
  2. Цикл продажи часто занимает от N месяцев и почти всегда N>=3. Продажи требуют большого количества взаимодействий и коммуникаций массы участников. Повторить предложение после неудачной попытки продажи затруднительно.
  3. Размер пользовательской базы существенно более узок, а получение сведений о характере эксплуатации или удовлетворенности может быть затруднено организационными или техническими ограничениями.
  4. Финансовая успешность b2b продукта может быть достаточно сильно оторвана от его функционально/эксплуатационных характерик в силу дискретности продаж и иных факторов.

Понимая специфику продукта и его позиционирование к рыночной или внутрикорпоративной нише владелец должен дать определение успешности продукта. Заметим, что тезис “продукт решает проблему/удовлетворяет потребность” никто не отменял.

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

В чем будут отличия или сходства со сказанным выше:

  • Вне зависимости от того, что из себя представляет продукт (даже если это сугубо инфраструктурное решение “сервис корпоративной шины данных” и оно эксплуатируется заказчиком самостоятельно без участия поставщика), он в любом случае проживает свою жизнь по некоторому жизненному циклу: упрощенно от выявления потребности и приобретения до эксплуатации с последующим выводом. Для владельца продукта это означает, что вопросы удовлетворения интереса, приобретения продукта, удержания и подтверждения потребностей (например, выгорание пользователей, выгорание “заказчиков”) остаются релевантными, как и в предыдущих случаях B2C и gov продуктов. Главный вопрос – какие данные, когда, как и от кого мы можем получить!
  • Работа на метрику “TTV: Time-To-Value”: скорость и простота всех шагов, связанных с тем, чтобы дать попробовать продукт в ответ на проявленный интерес, ускорение и упрощение разветывания демо/пробную версии, снижение затрат на запуск продуктивной эксплуатации продукта для заказчика. Внедрение часто является заметной частью TCO, а значит оптимизации внедрения могут стать существенной продуктовой характеристикой (измеряемой!), частью определения его “успеха”.

  • Поскольку в enterprise лицо принимающее решение (спонсор/покупатель) и пользователи – это разные роли, то коммуникации с покупателем, проявление его интереса к продукту, выявление его дополнительных потребностей потребует организации отдельного канала коммуникаций, через который продукт  будет получать важную обратную связь, отличную от технических метрик и пользовательских отзывов. Работа и измерение этого “путешествия покупателя” важна, как и выявление его корелляции с активностью групп пользователей.

  • Различные клиенты в B2B сегменте обладают различной спецификой требований, что означает что одни и те же характеристики вашего продукта могу иметь различное значение для ваших заказчиков, а значит существенно влиять на показатели Retention, даже если первичная продажа прошла успешно. Например, организации в финансовой сфере или в здравоохранении могут иметь особенные требования к защите обрабатываемых данных и быстро разочароваться в продукте, которые не удовлетворяет отдельным характеристикам/потребностям. Понимание этой специфики, а значит и поведения продуктовых метрик, особенно важно для поставщиков SaaS решений.

Экстремальный вариант “для сильных/смелых”: если приложить определенные усилия и желание, то любую inhouse разработку можно дорастить до публичного продукта, изменить ее позиционирование. Примеры подобного существуют: СУБД Tarantool от mail.ru вырос из внутрикорпоративного продукта.

Все пути открыты идущему.

 

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

Комментариев: 2

  • Алексей

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

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

    • Алексей, как мне кажется, это не безвыходная ситуация. В корпоративном кейсе, когда пользователи “обречены”, между командой и этими самыми пользователями часто возможен достаточно плотный контакт, за счет которого можно попробовать выйти на те выгоды которые приносит пользователю продукт или его улучшения (для каждого продукта они свои): увеличение производительности, масштабируемость, экономия времени специалистов на задачах эксплуатации и мониторинга, экономия мощностей, появление новых функций-“enablers”, которые позволяют заказчику/пользователю действовать иначе и экспериментировать и т.п. Вплоть до появления функций, которые перерастают в бизнес-преимущества через фронтовые решения. Если попытаться сделать клиентские выгоды продукта видимыми, а в идеале и измеримыми в натуральных единицах, то это будет практически победа. Я думал бы в эту сторону. С бытовой измеримостью, особенно в начале пути, точно будет трудно, но визуализации полезности продукта, коллективного труда команды – точно нужно добиваться. Это еще и мощнейший мотивирующий фактор для всех.

      Иногда, если заказчиков с разными интересами в компании несколько (от 3-5), то на мой взгляд стоит проводить (ежегодно?) сессии с пользователями для обсуждения видения развития продукта и его текущей позиции, на которую предоставлять и информацию о возможных конкурирующих альтернативах. Это трудоемкое и небезопасное мероприятие, но оно может предотвратить внезапный и острый коммуникационный разрыв между “пользователи привыкли, не жалуются и не уходят” (куда собственно, с подводной лодки то?) и “ваш продукт не нужен: он и не удобен и устарел и дисфункционален; вот лучшие или более дешевые альтернативы. давайте рассмотрим проект перехода на другое решение”. Такая коммуникация важна, т.к. в корпоративном кейсе этот “отток пользователей” точно также существует, просто проявлется он для ненаблюдательного поставщика продукта внезапно, в силу объективных причин.


Добавить комментарий для Андрей ТруфановОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;