Почему “самая очевидная фича” не попадает в релиз
Сценарий мне до боли знакомый:
Ты подходишь к станции аренды пауэрбэнков с нулём батареи. Телефон не включается. QR-код не просканировать. И ты стоишь, смотришь на этот спасительный девайс — и не можешь его взять.
«Ну это же надо было додуматься — сделать сервис зарядки, но без способа воспользоваться им, когда ты уже разрядился!»,- думаешь ты. «Ну что за продакты/UX и т.д. Там работают!
Так думают (и говорят вслух) пользователи. И в чём-то они правы.
Вот что слышит фича-делатель:
«ДА ЭТО ЖЕ КРИТИЧЕСКИЙ СЦЕНАРИЙ!» «НАДО ДОБАВИТЬ ЗАРЯДКУ ПРЯМО НА СТАНЦИИ!» «ЭТО ЖЕ САМЫЙ ЛОЯЛЬНЫЙ СЕГМЕНТ — ГОТОВ ПЛАТИТЬ С ХОДУ!»
Но вот гипотеза: возможно, внутри команды про это знали. И даже обсуждали. И даже хотели. Но — не сделали.
Почему такие штуки не попадают в релиз? 1. Это “исключительный сценарий” с точки зрения данныхСколько пользователей действительно оказываются в полной изоляции от сервиса из-за 0% батареи? Не те, кто на 5% — они арендуют. Не те, кто просто забыл пауэрбэнк. А именно те, кто не может даже запустить приложение. 1–3% от общего трафика? Меньше? Для продуктовой команды это может означать: высокая боль, но очень узкий сегмент. 2. Цена реализации выше, чем краткосрочная ценность (если не предусмотрели заранее)Чтобы добавить экстренную зарядку на станции, нужны:
- Железо (разъёмы, защита, питание),
- Софт (отслеживание, логика разблокировки) и т.д., иначе это превращается в "халявную розетку", а не услугу.
А в результате — сложная инженерная задача ради кейса, который не сильно влияет на ключевые KPI квартала: MAU, Retention, выручка.
3. Есть другие, более масштабные приоритетыКогда ты крупный продукт, у тебя десятки “болевых” сценариев. Но в roadmap попадают те, которые:
- Влияют на массовую воронку,
- Повышают конверсию или частоту,
- Укладываются в текущую архитектуру и трек OKR.
Фича для спасения “нулевого заряда телефона” — понятная, но она не даёт рост. Она поддерживает, а не масштабирует.
4. Мы не знаем всего контекстаМы — снаружи. Мы не видим внутренние обсуждения, таблицы с цифрами, приоритизации, технический долг. И очень возможно, что эта боль была замечена, но по совокупности факторов — ушла ниже в стек.
Такие фичи не появляются не потому, что "не подумали", а потому, что приняли решение не делать. Сознательно. На основе данных, ограничений и приоритетов.
В краткосрочной экономике проще гнаться за масштабированием станций, чем за решением сложных сценариев.
Ставки делаются так:
- Сколько людей попадают в сценарий? -Сколько из них можно конвертировать?
- Повлияет ли это и на сколько на ту метрику, за которую в этом квартале хотят растить от продакта?
- Сложно ли это запилить?
- Можно ли объяснить это руководству в одном слайде?
Ну или…. На старте команда просто не предусмотрела сценарий полной разрядки телефона — фокус был на MVP и скорости вывода. Казалось: ну у всех же есть хоть 5% батареи, чтобы отсканировать… Или: QR — это просто! Норм UX!
Архитектура устоялась. Железо законтрактовано. Приложение стабилизировалось.
И теперь: "Да, конечно, можно было бы. Но переписать под это всё — это минус два спринта и плюс конфликт с текущей дорожной картой."Так работает взросление продукта: не потому, что не хотят — а потому, что уже поздно "легко поправить".
