Конверсия шага загрузки выросла с 40% до 65%, но финальная выдача не двигается. PM требует оставить приоритет фичи в следующем спринте.
Вопрос: Где ты докажешь bottleneck и как переубедишь команду, что проблема не в видимом шаге?
🤔 Подумай перед чтением
Какое решение примешь, если у тебя только один спринт и нельзя трогать два шага одновременно?
Контекст: В предыдущем модуле мы разобрали связь цели, механизма и метрик.
Задача этого модуля: найти реальное ограничение в потоке, а не оптимизировать самый заметный шаг воронки.
Единый цикл модуля
📉 Сигнал: шаг улучшили, итог нет.
🧠 Механизм: bottleneck задает потолок.
⚙️ Анализ: считаем throughput по шагам.
📊 Пример: документы лучше, выдача без роста.
📌 Решение: инвестируем в ограничение системы.
Основная идея
Воронка — не последовательность процентов, а поток. Пользователи входят, проходят шаги, застревают на одних, пролетают через другие. У потока есть узкие места — ограничения, которые определяют пропускную способность всей системы. Всё, что шире самого узкого места, не увеличивает выход.
Типовая ошибка — оптимизировать шаг с наибольшим процентом потерь. Но потери — это не то же самое, что ограничение. Шаг теряет 60% пользователей — и это может быть нормой. А шаг с потерей 15% может быть настоящим bottleneck, потому что именно он задаёт потолок всей воронки.
Как искать ограничение
Поток
Откуда приходят пользователи
→
Шаги
Через что проходят
→
Ограничение
Что задаёт потолок
→
Оптимизация
Расширить узкое место
→
Проверка
Вырос ли выход
Ключевой вопрос — не «где мы теряем больше всего», а «что ограничивает выход». Это разные вопросы. Первый ведёт к работе с самым заметным, второй — с самым важным.
Три правила ограничений
Ограничение одно — в каждый момент есть ровно одно узкое место, которое задаёт потолок потока
Расширение не-ограничения бесполезно — конверсия шага вырастет, но выход не изменится
После расширения ограничение перемещается — оно не исчезает, а переходит на следующий узкий шаг
Пример: загрузка документов в онлайн-банке
Воронка кредитной заявки: 5 шагов от заявки до выдачи. Команда видит, что «загрузка документов» теряет 60% — и оптимизирует этот шаг. Но выход не растёт.
100%
Заявка
75%
Анкета
40%
Документы
35%
Скоринг
18%
Выдача
Видимая проблемаЗагрузка документов — 40% конверсии, самый «дырявый» шаг
Что сделалиУпростили загрузку: камера вместо файлов, автораспознавание. Конверсия шага выросла до 65%
РезультатВыдача кредитов не выросла — 18% осталось. Больше заявок дошло до скоринга, но скоринг отсёк ту же долю
Реальное ограничениеСкоринговая модель отсеивает ~50% заявок. Расширение шага загрузки привело лишнюю аудиторию — к скорингу, где она и отвалилась
Что делатьАнализировать причины отказов скоринга, калибровать модель, или фильтровать аудиторию раньше — до загрузки документов
⏱ Быстрая диагностика
Где ограничение: какой шаг реально ограничивает итоговый выход?
\n
Что будет, если улучшить этот шаг на 10–20%: вырастет ли финальный KPI?
\n
Куда сместится bottleneck после улучшения и что мониторим дальше?
\n
Типовая ошибка интерпретации
«На этом шаге потеря 60% — значит, это главная проблема воронки.»
Большая потеря на шаге — не равно ограничение. Если шаг после него тоже отсеивает, улучшение первого просто перекидывает отсев дальше. Выход воронки определяется самым узким местом, а не самым заметным. Прежде чем оптимизировать шаг, нужно проверить: вырастет ли выход, если этот шаг станет шире.
Типичная ошибка:
Останавливать анализ на первом "красивом" результате и не фиксировать решение через механизм, риски и проверку после внедрения.
Как думает аналитик
Сначала ищем ограничение по финальному выходу, а не по самой заметной потере. Потом сравниваем контрфакты и приоритизируем шаг, который меняет итоговый KPI.
📌 Что сказать на встрече
Факт: Локальная конверсия шага выросла, а итоговый выход почти не изменился.
Интерпретация: Текущий bottleneck находится в другом месте потока.
Риск: Команда потратит спринт на шаг, который не влияет на финальный KPI.
Рекомендация: Перенести приоритет на ограничение системы и оценивать эффект по финальному выходу, а не по шагу.
Что вы начинаете видеть после модуля
Воронку как поток с ограничением, а не как последовательность процентов
Разницу между потерей на шаге и bottleneck системы
Почему рост конверсии на одном шаге может не дать роста на выходе
Где ограничение перемещается после того, как вы расширили текущее
Ситуации, когда улучшение шага ухудшает итоговый результат (сдвиг микса, снижение среднего чека)
Практика
Загрузка документов в онлайн-банке — развёрнутый кейс