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

Разные Видения Экспериментов: PM vs Аналитик

Контекст проблемы

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

Почему возникают разные видения

PM часто видит:

• Фидбек пользователей (качественные интервью)
• Трудности в использовании продукта (рассказы от support)
• Конкурентный анализ
• Интуиция на основе опыта
• Стратегические цели компании

Аналитик часто видит:

• Поведение в numbers (сколько человек делает X)
• Воронка конверсии (где люди отпадают)
• Корреляции в данных
• Коэффициент значимости эффекта (effect size)
• Статистическую мощь (sample size)

Пример конфликта:

• PM: "Пользователи жалуются на сложный процесс оплаты, давайте его упростим"
• Аналитик: "Но данные показывают, что основной problem находится в процессе регистрации — там теряется 40% новичков. Давайте сначала это потестируем"

Подход к решению

Шаг 1: Остановить "войну" и провести диагностику

Общая встреча с четкой повесткой:

1. PM представляет свою гипотезу:

   • Что именно тестируем?
   • Какая метрика должна улучшиться?
   • Почему это важно?

2. Аналитик представляет свою гипотезу:

   • Что тестируем?
   • Какая метрика?
   • Почему важно?

3. Важный момент: не спорить, а слушать

Шаг 2: Анализ гипотез по единым критериям

Мы судим обе гипотезы по одним и тем же критериям:

Scoring (пример):

• Гипотеза PM: 3.5/5
• Гипотеза аналитика: 4.2/5

Но это не значит, что PM неправ!

Шаг 3: Комбинированный подход вместо выбора

Вариант 1: Последовательно

• Тестируем сначала гипотезу аналитика (15% uplift ожидается)
• Если не сработает → тестируем гипотезу PM
• Если сработает → интегрируем и потом тестируем PM гипотезу

Вариант 2: Параллельно

• Если есть достаточно трафика, можно запустить оба эксперимента одновременно
• Контроль группа, тест А (PM идея), тест Б (аналитик идея)
• Требует больше трафика и статистической мощи

Вариант 3: Модульно

• Если процесс имеет несколько шагов:
  • Шаг 1 (регистрация): тест аналитика
  • Шаг 2 (оплата): тест PM
• Это возможно, если процессы независимы

Вариант 4: Комбинированный эксперимент

• Объединить обе идеи в один тест
• Пример: упростить регистрацию И оплату одновременно
• Риск: если не сработает, не понять что именно помогло

Реальный пример из практики

Ситуация: Финтех приложение, низкая конверсия

PM гипотеза:

• "Нужно добавить социальный proof (отзывы) на экран регистрации"
• Ожидаемый результат: +8% конверсия
• Effort: 2 дня

Аналитик гипотеза:

• "Данные показывают, что 35% юзеров отпадают на шаге с паспортом. Нужно упростить процесс верификации"
• Ожидаемый результат: +25% конверсия
• Effort: 3 дня

Обсуждение:

1. PM спрашивает: "Как ты выбрал именно passport step?"

   • Аналитик показывает воронку
   • PM видит, что действительно там самый большой drop

2. Аналитик спрашивает: "Откуда у тебя идея про социальный proof?"

   • PM показывает конкурентов и фидбек пользователей
   • Аналитик понимает, что это может помочь, но вторична

3. Решение: сначала аналитик, потом PM

   • Неделя 1-2: упрощаем passport verification
   • Результат: +24% конверсия (близко к гипотезе)
   • Неделя 3-4: добавляем социальный proof
   • Результат: дополнительно +6% конверсия

Итог: Последовательное тестирование дало +30% в сумме, и мы поняли, какой фактор более важен.

Правила принятия решения

Правило 1: Данные > Интуиция (но интуиция важна)

Если аналитик показывает, что проблема в точке X (с данными), это имеет больший вес, чем интуиция PM. Но PM интуиция часто верна, просто нужны данные.

Правило 2: Большой impact > маленький effort

Если две гипотезы имеют одинаковый effort, тестируем ту, где больший ожидаемый impact.

Правило 3: Стратегия раньше тактики

Если гипотеза аналитика выравнена со стратегией, а PM гипотеза — нет, приоритет аналитику.

Правило 4: Learnings важны сами по себе

Даже если гипотеза не подтвердится, если мы узнаём что-то важное — это ценно.

Конфликт-менеджмент

Как PM/аналитик не превратить разногласие в конфликт:

1. Фрейм как сотрудничество

   • "Мы оба хотим улучшить продукт"
   • "Давайте вместе разберёмся, что более критично"

2. Уважай экспертизу

   • PM: доверь аналитику по datapoints
   • Аналитик: доверь PM по user research

3. Обоснуй, не угрожай

   • Вместо: "Моя идея лучше"
   • Лучше: "Я вижу потенциал в X потому что..."

4. Договорись о критериях ДО эксперимента

   • Что считается успехом?
   • Сколько трафика нужно?
   • Как долго тестировать?

5. Резервный план

   • "Если первый эксперимент не работает, тестируем второй"
   • "Если оба не работают, переходим на следующую гипотезу"

Мой подход как PM

1. Слушу аналитика очень внимательно

   • Данные не лгут, интуиция может ошибаться

2. Защищаю пользовательский feedback

   • Но только если это не один-два пользователя
   • Если фидбек систематичен → нужны данные

3. Предлагаю гибридные решения

   • Вместо "твоё vs моё" думаю "твоё + моё"

4. Инвестирую в data literacy

   • Учусь читать метрики
   • Задаю уточняющие вопросы аналитику

5. Чем раньше обсуждаю, тем лучше

   • На этапе планирования, не на этапе выполнения

Вывод

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

Правильный процесс:

1. Понять обе гипотезы
2. Оценить их по единым критериям
3. Выбрать последовательность или комбинацию
4. Договориться о успехе ДО теста
5. Узнать из результатов и обновить backlog

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