Так и хочется сказать, привет всем моим 8 подписчикам), а если серьезно...

Когда говорят о продуктовых метриках, обычно вспоминают конверсию, удержание, активную аудиторию, количество покупок или средний чек.

А доля сбоев, время запуска приложения, скорость загрузки экрана или процент успешных операций чаще остаются где-то на стороне разработки.

На мой взгляд, это искусственное разделение.

Если пользователь нажал «Купить», но операция зависла, для бизнеса это не техническая проблема. Это потерянная покупка.

Если приложение регулярно падает при загрузке фотографии, проблема не в самом сбое. Пользователь просто перестаёт пользоваться функцией.

Если главный экран открывается несколько секунд, мы можем сколько угодно улучшать дизайн и тексты, но первое впечатление от продукта уже сформировано.

Пользователь не разделяет продукт и технологии

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

Для него всё это один продукт.

Поэтому цепочка часто выглядит так: Техническая проблема → ухудшение пользовательского сценария → изменение поведения пользователя → влияние на бизнес-метрику → влияние на бизнес

Например: медленный запуск → меньше завершённых сессий; ошибки оплаты → ниже конверсия; нестабильная загрузка → ниже удержание функции; частые сбои → меньше доверия к продукту; долгое время ответа → пользователь чаще бросает сценарий.

И в этот момент техническая метрика перестаёт быть только технической.

Важен не процент сбоев, а место, где они происходят

99,9% сессий без сбоев выглядит отлично. Но если оставшиеся 0,1% происходят в момент оплаты, авторизации или восстановления данных, влияние на продукт может быть намного выше, чем кажется по общей цифре.

То же самое со скоростью.

Среднее время ответа API само по себе мало что говорит. Гораздо важнее, насколько быстро пользователь проходит конкретный сценарий и в каком месте начинает уходить.

Поэтому технические показатели полезно связывать с пользовательскими: не «экран загружается 3 секунды», а «при загрузке дольше 3 секунд растёт доля пользователей, которые не продолжают сценарий». не «успешность загрузки 94%», а «6% пользователей не могут завершить ключевое действие».

Это уже язык продукта.

Надёжность и предсказуемость — часть пользовательского опыта

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

Причём зачастую более важный.

Пользователь скорее простит неидеальную анимацию, чем ситуацию, когда деньги списались, а результат операции непонятен.

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

Здесь особенно важна роль разработчика

Разработчик часто первым видит вещи, которые ещё не превратились в продуктовую проблему. Мы видим слишком частые повторные запросы. Знаем, что определённый сценарий плохо переживает нестабильную сеть. Замечаем, что архитектура начинает ограничивать скорость дальнейшей разработки. Видим технический долг, который пока незаметен пользователю, но скоро начнёт влиять на продукт.

И здесь важно не просто сказать: «это нужно отрефакторить». Нужно уметь перевести техническую проблему на язык продукта: что произойдёт с пользователем, сколько сценариев затронуто, какова цена бездействия и что изменится после исправления. ИИ всё сильнее смещает роль разработчика от «написать код» к «принять правильное решение». И последствия этих решений гораздо шире кода: они влияют на сроки, стоимость разработки, пользовательский опыт и бизнес-результат. Поэтому скорость и стабильность приложения для меня — не вспомогательные технические показатели.

Это часть качества продукта.

А значит — такие же продуктовые метрики, как конверсия или удержание.