Как поднять frequency регулярных пассажиров без расширения парка — точечная фича, бьющая в главный KPI Whoosh на 2026.
Это не предложение к внедрению и не консалтинговый отчёт. Это упражнение, в котором я разбираю одну продуктовую гипотезу для Whoosh, чтобы показать, как я думаю о продукте.
У меня нет доступа к вашим внутренним данным. Все цифры в документе — публичные оценки или мои допущения, явно помеченные как таковые. С реальными данными выводы могли бы измениться.
Я не знаю, что у вас в бэклоге. Возможно, описанная фича уже разрабатывается, уже отвергнута или решается другим способом. Мне важно показать логику, а не угадать единственно правильный ответ.
На реальной роли я бы сначала запросил данные, погрузился глубже в бэклог и стратегический план, провёл интервью с командой и CustDev — и только потом приоритизировал. Здесь я был лишён этой возможности и сделал лучшее, что мог из публичных источников.
Прежде чем предлагать фичу для роста RPS, полезно разобрать саму метрику на составляющие. Это нужно, чтобы понимать, в какой именно рычаг мы целимся — и какие сознательно не трогаем.
У этой формулы три рычага. По публичным источникам я вижу, что Whoosh в 2026 явно фокусируется на двух из них. Про третий — у меня нет полной картины, поэтому это моя гипотеза о возможной точке роста.
Допускаю, что у Whoosh есть какой-то агрегированный прогноз спроса по локациям и часам — на это косвенно указывает работа операционки по релокации флота между локациями. Это статистика по толпе, и она работает в своей нише.
Чего я не вижу в публичных источниках — это слоя индивидуальных намерений: ситуации, когда сам пользователь подтверждает «я поеду от точки А до точки Б в окно 8:30–9:00».
Главный эффект — рычаг 1B (frequency существующих юзеров). Регулярный пассажир, ездящий 2–3 раза в неделю, превращается в юзера, ездящего 5 раз. Те же люди, больше поездок.
Вторичный эффект — рычаг 3 (доступность). Бронь по пушу возвращает потерянные поездки — те, что сегодня заканчиваются «прошёл, не нашёл, пошёл пешком».
Косвенный эффект — рычаг 2B (релокация). Подтверждённые маршруты становятся новым слоем данных для системы релокации флота, дополняя существующий макро-прогноз спроса.
JTBD-портрет, на который работает фича. Я собрал его из публичных данных Whoosh, исследования T-ID × Whoosh (апрель 2025) и моих допущений о поведении в часы пик. Цифры, не помеченные явно как мои оценки — из публичных источников.
Работает в офисе в 1,5 км от метро Чкаловская. Утром и вечером — самокат от метро до офиса и обратно, поездка занимает 5–6 минут. Whoosh — это его транспорт, не развлечение. В выходные на самокате не катается. Платит Month Pass, окупающийся на 5-й поездке. Цифры ниже — целевое состояние такого пассажира при стабильно работающем маршруте, не средняя текущая активность по базе.
Цепочка действий между «надо ехать» и «поехал» проходит через 5 шагов. На каждом шаге часть пользователей теряется — поездка не случается, и Whoosh теряет потенциальный доход. Цифры рядом с шагами — мои оценочные допущения, которые я бы валидировал данными в первую неделю на роли.
Вывод: регулярный пассажир может ездить 5 раз в неделю — пять рабочих дней. Реально совершается 2–3 поездки. Дельта между потенциалом и реальностью × тысячи пассажиров — это и есть точка роста RPS.
Сразу важная оговорка: у Whoosh уже есть базовое бронирование — 10 минут для всех, 20 минут для подписчиков WhooshPass. «Мой маршрут» не заменяет эту механику и не дублирует её. Фича строится поверх существующей брони, добавляя три слоя, которых сейчас в продукте нет.
Иначе говоря: новое не в самой брони, а в её триггере, моменте и контексте. И в том, что подтверждённые маршруты становятся данными для операционки.
Технически: базовая версия фичи опирается на компоненты, которые в продукте Whoosh, скорее всего, уже есть (история поездок, геолокация, push-уведомления, бронирование). Не нужно строить новые механики с нуля — нужно научиться запускать существующую бронь по триггеру паттерна. На старте достаточно простой эвристики «5+ повторений по схожему паттерну», без сложного ML. По моей оценке — MVP реалистично выкатить за 1–2 спринта.
Большинство фич решают одну проблему — либо UX, либо unit-экономику. «Мой маршрут» работает в обе стороны одновременно: каждое сохранение маршрута даёт ценность пользователю и одновременно генерирует данные для оптимизации флота.
В продукте, насколько я могу судить по публичным признакам, уже есть две части того, что нужно фиче: история поездок (значит, паттерны можно распознавать) и бронирование на 10/20 минут (это есть в публичном FAQ). Это и хорошо, и важно — фича не требует строить с нуля ни одну из ключевых механик.
Допускаю, что у вас уже есть какой-то макро-прогноз спроса по локациям и часам — на это косвенно указывает работа операционки по релокации флота между локациями. Если так — это статистика по толпе, и она работает в своей нише.
Чего я не вижу в публичных источниках — это слоя индивидуальных намерений, в котором сам пользователь подтверждает: «я поеду от точки А до точки Б в окно 8:30–9:00». Если такого слоя пока нет — он мог бы стать сигналом качественно другого порядка по сравнению со статистическим прогнозом, потому что он:
Бронь в Whoosh уже сегодня делает самокат недоступным для других юзеров — это базовая механика. Вопрос не в том, что мы создаём новый источник конфликта, а в том, что мы системно подталкиваем регулярных пассажиров пользоваться этой механикой через пуш. Логичный встречный вопрос: «почему именно они получают подсказку?»
На это есть простой ответ: фича доступна любому юзеру с устойчивым паттерном — не за деньги, не по плану, а по поведению. Юзер с подтверждённым маршрутом потенциально делает в разы больше поездок, чем разовый прохожий, поэтому небольшой приоритет ему оправдан экономикой. Бронь короткая (10/20 минут — стандарт продукта), не блокирует доступ для других надолго.
Хорошая фича начинается с измерительной архитектуры. Я выделяю четыре уровня метрик плюс контр-метрики. Один из уровней — диагностический: его метрики собираются до запуска фичи, чтобы валидировать саму гипотезу.
Я выбрал именно эту гипотезу не потому что «звучит круто», а потому что в своих предыдущих проектах решал что-то структурно похожее. Ниже — две реальные параллели, на каждой из которых стоит логика фичи.
Вывод: я не угадал гипотезу — я выбрал её потому что у меня есть прецеденты, в которых похожая логика дала измеримый результат. Это не гарантия успеха в Whoosh, но это структурный сигнал, что я знаю, как такие фичи запускаются и измеряются.
Этот раздел — не про фичу «Мой маршрут» конкретно. Это про то, как бы я подходил к роли Product Manager в Whoosh в целом. Если фичу-кандидата вы отвергнете — мой подход к работе вы увидите здесь.
Параллельно с задачами по бэклогу — постоянное самообучение и регулярный ресёрч: рынка, конкурентов, новых продуктовых гипотез, метрик. Хочу не только закрывать тикеты, но и приходить с собственными предложениями — обоснованными данными.
Все цифры в документе, не помеченные явно как мои оценочные допущения, взяты из перечисленных ниже публичных источников. Я не ссылаюсь на конкретные строки в тексте, чтобы не загромождать чтение, но при необходимости могу предоставить детальную привязку каждой цифры к источнику.