Как ставить data-driven продуктовые и бизнес-цели. Фреймворк и алгоритмы

#стратегия #гипотезы #growth #проекты #менеджмент #productmanagement

Вы запускаете новый продукт или проект. Готовитесь к выходу на новый рынок. Формулируете цели на квартал. Придумываете growth-гипотезу. Ситуация непонятная. В какие метрики целиться? Что делать? С какой стороны подойти к задаче?

Всем привет! Меня зовут Ира, люблю системный подход и так сложилось, что периодически я общаюсь про запуск и рост новых продуктов / рынков с ИТ-компаниями, стартапами и продакт-менеджерами. И в ходе общения очень часто всплывают запросы, для решения которых отлично подходит фреймворк DIBB.

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

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

Изначально фреймворк DIBB был создан компанией Spotify для целеполагания и аргументированного обсуждения проектов в рамках системы метрик North Star Metric.

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

Фреймворк — data-driven. В основе лежат данные (Data) и инсайты (Insights) (они же выводы из данных), на основании которых формируется (или уточняется) ваше предположение, в которое вы верите (Belief). Дальше вы «делаете ставку» (Bet) (сколько ресурсов вы готовы поставить) на достижение / проверку.

И в модели есть еще два важных параметра:

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

Мы использовали примерно такой проверочный вопрос:
«Если мы получили 50 платных пользователей, мы считаем, что наша идея подтвердилась / таргет выполнен. А если 30? А если 10?»

Если собрать все воедино, то описание DIBB получается вот таким:

Data

По результатам проведенного анализа мы видим, что ____ (исторические данные, статистика, факты, бенчмарки, наблюдения за рынком, результаты customer development и т.п.).

Insights

Это означает, что _____ (здесь пишем выводы из данных, инсайты).

Belief

Основываясь на данных и инсайтах, мы верим, что, если мы _____ (сделаем вот это), то мы получим _____ (вот такой результат в такие сроки).

Bet

Для проверки нашего предположения мы готовы поставить следующие ресурсы _____ (деньги, время, трудозатраты сотрудников) и провести следующие активности _____ (опциональный, но крайне желательный пункт, помогает определить объем ресурсов и помогает в дальнейшей работе).

Критерием успеха ставки будем считать _____ (описание результата с метрикой) не менее _____. В случае успеха ставки наши следующие шаги будут такими _____. В случае неуспеха ставки мы будем _____.

В зависимости от масштаба проекта глубина проработки и описания будет, само собой, разной.

На каждую ставку стоит определить:

Если реализация ставки длинная (более двух недель):

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

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

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

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

У команды отраслевой конференции, успешной на российском рынке, возникла идея: "А что, если вывести ее на англоязычный рынок". Но было непонятно, стоит ли в это ввязываться. Решили покрутить идею по DIBB перед тем, как запускаться:

Предпосылки / Data и Insights:

Предположение / Belief:

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

Брейншторм ставки

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

Что будем считать подтверждением гипотезы

Что получилось у команды в итоге?

Привожу гипотезу (ставку) в сокращенном варианте.

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

Для этого мы готовы поставить время 6 сотрудников (x% от их рабочего времени на протяжении X недель), и $XX бюджет на платную рекламу, перевод, синхронную трансляцию.

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

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

В случае частичного успеха ставки (только п.1) — проводим исследование причин, в следующий раз экспериментируем с монетизацией и рекламой.

В случае неуспеха - анализируем причины, делаем actionable-выводы.

Фреймворк по сути стал ключевым инструментом по подготовке запуска. Он помог команде:

А как вы ставите цели в своих проектах?