Delivery-to-User: когда фича считается по-настоящему доставленной
Разбираемся в концепции Delivery — практике доведения ценности до пользователя, которая завершается не релизом, а совершением value-event и его повторением.
Delivery-to-User: когда фича считается по-настоящему доставленной
В продуктовой разработке мы часто путаем два понятия: «релиз» и «доставка». Мы говорим: «Мы доставили фичу», когда на самом деле мы просто выкатили код в продакшн. Это опасное заблуждение, которое приводит к созданию «продуктов-призраков» — фич, которые существуют в коде, но не в жизни пользователей.
Главный вопрос, который нужно себе задавать: «Дошла ли новая ценность до пользователя, и начал ли он ей пользоваться так, как нам нужно?»
Фундаментальный принцип Delivery
Изменение считается доставленным только тогда, когда пользователь совершил
value-event(получил первую реальную пользу) и повторил его в окне успеха.
Релиз — это событие для команды. Delivery — это событие в поведении пользователя. Пока этого не произошло, ваша работа не закончена.
Почему «релиз» ≠ «результат»: лестница, на которой падают пользователи
Между моментом, когда фича технически готова, и моментом, когда пользователь получает от неё пользу, лежит длинная лестница. Задача Delivery — провести пользователя по этой лестнице, не дав ему упасть. Вот типичные ступеньки, на которых мы теряем пользователей:
- Не заметил (нет контакта). Пользователь просто не узнал о новой возможности. Релиз-ноуты, посты в блоге — всё это легко пропустить.
- Не понял «зачем мне это» (нет смысла). Пользователь увидел уведомление, но не понял, как эта фича решает его конкретную проблему прямо сейчас.
- Не доверяет / боится риска (нет уверенности). Новое всегда сопряжено со страхом. «А вдруг я что-то сломаю?», «Это выглядит слишком сложно», «Я потом разберусь».
- Не может пройти путь к первой победе (трение). Пользователь начал, но столкнулся с непонятным интерфейсом, багом или просто нехваткой времени, чтобы разобраться.
- Получил пользу один раз, но не встроил в привычку (нет повтора). «Ага-момент» случился, но не возникло триггера или мотивации, чтобы вернуться и повторить это действие.
Работа Delivery — это системный разбор этой лестницы. Мы должны анализировать, на какой ступеньке отваливаются пользователи, понимать почему, и целенаправленно чинить этот этап.
Анти-самообман: как мы врём себе про Delivery
- «Мы доставили» = «мы зарелизили». Это главный самообман. Антидот: измерять
deliveryпо изменению поведения (value-event+ повтор), а не по тикету в Jira. - «Пользователи не используют — значит, им не нужно». Чаще всего это означает не слабую ценность, а непроходимый путь. Антидот: разбирать по цепочке (увидел → понял → попробовал → добился успеха → повторил) и искать обрыв.
- «Мы всё объяснили в релиз-нотах». Большинство пользователей их не читает. Антидот: доносить смысл в момент потребности, внутри продукта, в контексте сценария.
- «Достаточно баннера/попапа». Показ ≠ действие. Антидот: проектировать не коммуникацию, а
activation path— короткий путь к первой победе.
Настоящая доставка — это не техническая задача, а продуктовая дисциплина. Она требует эмпатии, аналитики и системного подхода. Только когда вы поймёте, что ваша работа заканчивается не в момент мержа ветки, а в момент, когда пользователь получил реальную, повторяемую ценность, вы начнёте строить продукты, которые действительно меняют жизнь людей.