Backlog как путь в бездну. Как в зрелом продукте показывать результат и не терять фокус

Ваша команда выкатывает новую фичу за фичой. A/B-тесты показывают +3% к конверсии. Продакт ставит задачам статус "Done", команда получает поздравления от СРО. А через два месяца выясняется: 40% пользователей по-прежнему отваливаются на том же критичном шаге. Проблема не решена. Но в бэклоге она больше не приоритетна - там уже 47 других "важных" задач. СРО требует результат. Кажется что-то не так.

Классический backlog выглядит профессионально: список задач, каждая оценена по RICE, всё отсортировано по приоритету. Все самое важное и значимое делается в первую очередь. Команда работает как швейцарские часы, спринт за спринтом выкатывая фичи.

Но на практике происходит подмена понятий:

Вместо: "Какую проблему пользователей мы решаем?" -> фокус на: "Какую фичу запускаем следующей?"

И это не просто нюанс формулировки. Это корневое искажение, которое превращает продуктовую команду в "фабрику фич". Давайте попробуем понять где именно происходит искажения. Есть несколько ловушек, в которые попадаются продакты:

Ловушка #1: Иллюзия победы

Вариант сценария:

Реальность:

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

Ловушка #2: Быстрая капитуляция

Вариант сценария:

Реальность:

В моей практике огромное количество (60%-70%) "проваленных" A/B-тестов можно было спасти альтернативным решением той же проблемы. Но команды редко возвращаются к "закрытым" задачам, считая что они сделали все необходимое.

Получается, что фокус на backlog задач, на список уже приоритизированных решений смещает фокус продактов с пользовательских проблем (или возможностей) на конкретные решения

А когда команда работает с готовыми решениями:

Результат: Команда превращается в конвейер по выполнению задач. Много движения, мало прогресса.

Но ведь продакты хотят сделать действительно хороший, рабочий продукт. Да и бизнес, по большому счету, ждет что продукт станет лучше привлекать, активировать, удерживать аудиторию, что LTV будет кратно превышать САС. И чтобы не быть тем самым конвейером, который клепает фичи, надо вернуть фокус на проблематику вместо решений. Значит в основе планирования должен стать не список фич, а приоритизированный список пользовательских проблем.

Видите разницу?

Проблема даёт:

В то время как задача даёт:

Давайте перейдем к практической составляющей и разберемся как построить отприоритизированный список проблем.

Этап 1: Сбор пользовательских проблем

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

Какие источники можно использовать, но не ограничивайтесь этим списком, используйте все доступные вам:

Качественные:

Количественные:

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

Важно: Формулируем проблему, а не решение.

Одной из самых часток ошибок является формулировании проблемы в виде отсутствия какого-то конкретного решения. Об этом еще Генри Форд говорил: “Если бы я спросил у покупателей, что им нужно, они ответили бы: более быстрая лошадь”.

Плохо:

Хорошо:

Этап 2: Приоритизация по RICE

Классический RICE применяют к задачам. Мы применяем его к ПРОБЛЕМАМ.

Однако, есть одно отличие - RICE должен быть полностью расчетным. Это критическое отличие, которое меняет всё.

R - Reach (Охват) - Сколько пользователей сталкиваются с проблемой?

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

Как измерять:

Пример расчёта:

Проблема: "Пользователи не понимают, как работает тарификация"

Источники данных:

В данном случае reach можно оценить как 2100 пользователей При MAU = 15 000 → это 14% аудитории

I - Impact (Влияние) - Насколько критична проблема для бизнеса и пользователя?

Зная аудиторию, которая столкнулась с конкретной проблемой, можно достаточно точно оценить упущенную выгоду. Следует понимать какой именно сегмент (по платежеспособности) подвержен данной пользовательской проблеме и какой эффект она имеет. Складывая эти факторы можно рассчитать упущенную выручку на пользователя.

Упущенная выручка на пользователя =

Средний чек × Текущая CR × Потенциальный прирост CR

Пример: "Непонятная тарификация"

Потенциал = ₽1 200 × 10% = $120/мес

C - Confidence (Уверенность) - Насколько мы уверены в существовании проблемы и возможности её решить?

Это самый субъективный параметр. Однако, стоит его вывести в объективную плоскость, поэтому создаём четкую шкалу:

Пример оценки:

Проблема: "Непонятная тарификация"

Данные:

Confidence: 60% (количественное подтверждение)

Почему не 100%? Потому что мы не тестировали ещё ни одного решения. Уверены в проблеме, но не уверены, что сможем её решить.

Anti-паттерн: Команда оценивает Confidence как 100%, потому что "ну это же очевидно". А потом делает 5 итераций решения, и ни одно не работает. Confidence - это не только про проблему, но и про уверенность в решаемости.

E - Effort (Усилия) - Сколько ресурсов потребуется на поиск и внедрение решения?

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

Измеряем в person-months:

Важный нюанс: Оцениваем не конкретное решение, а диапазон возможных решений.

Пример:

Проблема: "Пользователи не понимают тарификацию"

Возможные решения (диапазон):

Оценка Effort: 2 PM (средний сценарий)

Если разброс решений очень большой (от 0.5 до 10 PM), это сигнал, что проблема недостаточно конкретна. Разбейте на подпроблемы.

Считаем финальный приоритет

Приоритет = (Reach × Impact × Confidence) / Effort

Пример расчёта топ-3 проблем:

Топ-1 проблема: Непонятная тарификация (приоритет 134 400)

Хотя охват у неё меньше, чем у загрузки каталога, но:

Это и есть объективная приоритизация.

Операционный процесс

Что мы делаем дальше с backlog проблем? А дальше он становится частью операционной работы с задачами и решениями.

Шаг 1: Выбираем топовую проблему

Берём проблему с наивысшим приоритетом по RICE. Не задачу, а проблему.

Важно: Фиксируем целевые метрики:

Шаг 2: Генерим несколько вариантов решений

НЕ останавливайтесь на первой идее! Для одной проблемы придумайте 3-7 вариантов решений из разных категорий:

Проблема: "Пользователи не понимают тарификацию"

Решения:

UX-решения:

Коммуникационные решения:

4. Видео-объяснение (1 мин) на странице тарифов

5. Персонализированные рекомендации "Для вас подойдёт..."

6. Case studies: "Клиенты как вы выбирают..."

Логические решения:

7. Упростить саму тарифную сетку (3 тарифа вместо 7)

8. Тестовый период с автоподбором тарифа

9. AI-ассистент для подбора

Шаг 3: Быстро тестируем гипотезы

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

Как раз на этом шаге проявляется ценность продакта и его компетенций. Именно в этой части можно повысить Confidence решения и выбрать наиболее оптимальное с точки зрения эффекта и затрат решения.

Способы быстрого тестирования:

Для UX-решений:

Для коммуникационных решений:

Для логических решений:

Кейс: Команда хотела делать калькулятор тарифов (оценка: 6 недель разработки). Вместо этого сделали landing page с кнопкой "Рассчитать стоимость" → форма обратной связи. За неделю получили 340 заполнений, подтвердили спрос. Только после этого начали разработку.

Шаг 4: Оцениваем степень покрытия проблемы

Это критичный шаг, который пропускают почти все команды. Возвращаемся к исходной проблеме и смотрим: на сколько % она решена?

Пример:

Проблема: "2 100 пользователей не понимают тарификацию"

Решение 1: Добавили FAQ на страницу тарифов

Результаты через 2 недели:

Вывод: Проблема решена на 15%. Продолжаем искать решение.

Решение 2: Добавили интерактивный калькулятор

Результаты через 2 недели:

Вывод: Проблема решена на 49% (772 пользователей из 1 575)

Итого: За 2 итерации проблема решена на 61% (с 2 100 до 803 пользователей)

Шаг 5: Принимаем решение о дальнейших действиях

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

В нашем примере: Покрытие 61% → Проблема решена не полностью → Делаем еще одну итерацию

У части читателей могут возникнуть возражения или даже негодования в процессе прочтения статьи. Давайте попробую их превентивно отработать.

Возражение 1: "Это же очевидно, мы и так думаем про проблемы"

Думать - да. Но проверьте себя:

Быстрый тест:

Как правило ответы следуют такие:

Возражение 2: "У нас уже есть бэклог на год вперёд, как всё переделывать?"

Не нужно переделывать всё сразу. Backlog проблем является основой для backlog задач. Как только вы заведете backlog проблем, вы пересмотрите процесс приоритизирования задач. От задач вам все равно никуда не деться. Ведь с командой разработки вы будете взаимодействовать по прежнему по задачам.

Возражение 3: "Это работает только для зрелых продуктов"

Верно! Backlog проблем - не серебряная пуля для всех ситуаций. На разных стадиях развития продукта нужны разные подходы и backlog проблем не исключение.

Когда НЕ нужен backlog проблем:

Стадия: поиск product-market fit

MVP с минимальной аналитикой

Микрокоманда на все задачи

Когда НУЖЕН бэклог проблем:

Продукт нашёл PMF и продукт в стадии масштабирования

Есть развитая аналитика

Достаточно ресурсов

"Много делаем, мало растём"

Возражение 4: "Это же дольше, чем просто делать задачи"

Да, создание бэклога проблем - инвестиция времени. Но тут важно для себя ответить на вопрос: вам нужно много и быстро или контролируемо и результативно.

Возражение 5: "Как убедить команду и стейкхолдеров перейти работу с проблемами?"

Не начинайте с убеждения. Имейте в виду “Возражение 3”. Возможно, в вашем продукте еще не назрела такая проблема. В первую очередь осознайте потребность. Если же потребность назрела, то начните с эксперимента.

Шаг 1: Выделите одну проблему на основании задач из текущего бэклога

Шаг 2: Придумайте 3 варианта решения (а не только 1)

Шаг 3: Протестируйте все 3

Шаг 4: Измерьте покрытие проблемы, а не успех фичи

Шаг 5: Сделайте ещё 1-2 итерации до полного решения

Шаг 6: Сравните результаты

Цифры убеждают лучше любых презентаций.

Мы уже много обсудили как и что надо делать. Но давайте для полноты картины еще проговорим анти-паттерны.

Анти-паттерн #1: Формулировать проблемы как решения

Неправильно: "Нет функции экспорта в Excel"

Правильно: "12% power-users не могут выгрузить свои данные для дальнейшего анализа (67 обращений в поддержку/месяц, LTV этого сегмента ₽280K)"

Разница: Первое - это решение. Второе - проблема, которую можно решить по-разному (API, экспорт в другие форматы, интеграции).

Анти-паттерн #2: Оценивать Reach "на глаз"

Неправильно: "Проблема затрагивает многих пользователей" (Reach: ~5000)

Правильно: "2,340 пользователей за последние 30 дней бросили регистрацию на шаге верификации email (Google Analytics → Registration Funnel → Step 2 → Exit)"

Инструменты для точного расчёта Reach:

Анти-паттерн #3: Делать бэклог на 100 проблем

Неправильно: Составили список из 100 проблем и оценили все

Правильно:

Почему: Бэклог из 100 проблем = возвращение к хаосу бэклога задач. Фокус теряется.

Правило: Если топ-10 проблем решит большую часть болей, зачем вам 100?

Анти-паттерн #4: Не обновлять приоритеты

Неправильно: Составили бэклог проблем год назад, приоритеты не меняли

Правильно:

Причины для пересмотра:

Анти-паттерн #5: Оценивать одним человеком

Неправильно: PM один составил бэклог проблем и оценил

Правильно: Привлекайте к оценке людей, которые непосредственно работают с пользователями и задачами: исследователей, аналитиков, разработчиков, сотрудников customer support

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

Через 1 месяц:

Красные флаги:

Через 3 месяца:

Красные флаги:

Через 6 месяцев:

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

Переход к backlog проблем создает совсем другую динамику:

Если вы чувствуете, что ваша команда много делает, но продукт растет медленно - почти всегда причина в том, что вы работаете по backlog задач.

Попробуйте перейти к backlog проблем. Меняется всё.