Evaluate · Принятие решений · Продуктовая стратегия · Pivot · PTOS

От Scale до Kill: 4 допустимых исхода Evaluate и как принять решение

Подробный разбор четырёх допустимых исходов фазы Evaluate (Scale, Iterate, Rollback, Kill), с чёткими критериями для каждого и пониманием, почему Evaluate должен завершаться именно решением, а не наблюдением.

От Scale до Kill: 4 допустимых исхода Evaluate и как принять решение

Фаза Evaluate — это не просто «посмотреть на метрики». Это кульминация цикла обучения, которая обязана завершиться одним из четырёх конкретных решений. Если вы просто «приняли к сведению» результаты и пошли дальше, значит, вы не провели Evaluate, а просто потратили время.

В PTOS фундаментальный принцип Evaluate звучит так:

Evaluate существует только тогда, когда по его результату заранее принято решение и определены пороги: успех / провал / неясно.

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

1. Scale (Масштабируем)

Это самый желанный исход. Он означает, что ваше изменение работает и готово к расширению.

• Когда принимаем это решение:
  • Пороги успеха, определённые до старта, достигнуты (например, целевая метрика выросла на N%).
  • Guardrail-метрики (побочные эффекты) в норме (например, не выросла нагрузка на саппорт, не упал retention).
  • Эффект устойчив в заданном окне измерения.
• Что делаем дальше:
  • Расширяем rollout на следующий сегмент или на 100% аудитории.
  • Закрепляем операционные процессы (обновляем документацию, обучаем команду).
  • Продолжаем мониторить guardrails, потому что на большом масштабе могут появиться новые, неожиданные эффекты.

2. Iterate (Улучшаем/Итерируем)

Это самый частый исход. Сигнал есть, но он недостаточен для полномасштабного запуска.

• Когда принимаем это решение:
  • Результат попал в «серую зону» (например, метрика выросла, но меньше, чем ожидалось).
  • Сигнал есть, но Activation Path (путь к ценности) где-то ломается.
  • Есть небольшие негативные побочные эффекты, которые можно исправить.
• Что делаем дальше:
  • Не масштабируем! Это ключевое правило. Преждевременное масштабирование «серой зоны» — это масштабирование проблемы.
  • Формулируем новую, более точную гипотезу, направленную на устранение найденной проблемы.
  • Делаем один следующий проверяемый шаг (next bet), а не «пакет улучшений».
  • Составляем stop-doing list: что мы перестаём делать, чтобы не распылять фокус.

3. Rollback (Откатываем)

Это признак зрелой, а не слабой команды. Rollback — это не провал, а управляемое решение, которое защищает пользователей и бизнес.

• Когда принимаем это решение:
  • Нарушены guardrail-метрики (например, выросли ошибки, упал retention в ключевом сегменте).
  • Вред от изменения превышает пользу.
  • Доверие пользователей под угрозой.
• Что делаем дальше:
  • Откатываем изменение (частично или полностью).
  • Проводим разбор причин: что именно пошло не так?
  • Корректируем гипотезу, пороги или дизайн теста для следующей попытки.
  • Останавливаем все коммуникации и обещания, связанные с этим изменением.

4. Kill (Убиваем)

Самое сложное с эмоциональной точки зрения, но часто самое правильное решение.

• Когда принимаем это решение:
  • Пороги провала достигнуты.
  • Поведение пользователей не изменилось, повторяемость отсутствует.
  • Несколько итераций не принесли значимого эффекта.
• Что делаем дальше:
  • Выключаем или полностью удаляем фичу из продукта.
  • Фиксируем, чему научились. Это самый важный шаг. Какие допущения оказались неверными? Что мы узнали о наших пользователях?
  • Возвращаемся в фазу Discover с новым, более глубоким пониманием проблемы.

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