От фич к результату: как формулировать продуктовые цели

Команда выпустила новый экран, отчиталась о релизе — а пользователи продолжают уходить на том же шаге. Значит, пора обсудить не только функции, но и проблему, которую они должны решать.

Запрос «добавить новый экран» описывает возможное решение. Продуктовая цель отвечает, чью проблему нужно решить и что должно измениться. Например, вместо обещания построить новый онбординг можно исследовать, почему пользователи не завершают настройку, и поставить измеримую цель по её завершению. Новый экран может получиться очень красивым. Осталось выяснить, помог ли он кому-нибудь, кроме автора презентации.

Свяжите наблюдаемую проблему, аудиторию, гипотезу, эксперимент и метрику. Укажите исходное значение, способ измерения и период проверки; если данных нет, первый этап — установить базу, а не придумывать точность. Важно заранее определить, что заставит изменить решение: например, отсутствие эффекта или рост обращений в поддержку. Цифры полезны, когда понятно, откуда они взялись. «Давайте вырастем на 30%» само по себе ещё не исследование.

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

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

Представим, что пользователи редко завершают настройку сервиса. Вместо немедленного создания нового экрана команда изучает, где люди останавливаются, формулирует гипотезу и проверяет изменение на измеримом показателе, следя за обращениями в поддержку.

Релиз — начало проверки гипотезы. Дальше нужны данные и разговор с пользователями: именно они покажут, стало ли лучше.