Портал №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 вырос из внутрикорпоративного продукта.

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

 

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

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

  • Алексей

    Добрый день! Спасибо за статью.

    А какими метриками можно оценить качество Продукта в ситуации, когда пользователи «обречены» на него ввиду отсутствия так или иначе каких-либо альтернатив? Т

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

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

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


Добавить комментарий

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT