Олег Бледнов
✨ Рост продуктов без хаоса
Доброго дня! Спасибо за комментарий и вопрос.
Ранний индикатор — метрика, которая изменяется, хотя не должна. И это при отсутствии внешних причин.
Конкретный пример из кейса №3. Инфраструктура сокращает серверы, маркетинг льёт трафик. Первым «закричит» не P&L, а время отклика сервиса (latency/p95). Оно начнёт расти раньше, чем упадёт конверсия или retention. Маркетинг первое время молчит, так как сервис ещё работает. Но система уже рассинхронизирована.
Ещё можно смотреть на частоту эскалаций между департаментами. Если поддержка начала регулярно подключать разработку к инцидентам, которые гасят разные последствия чьего-то решения — это не про качество кода. Это про то, что цели продукта и разработки не были согласованы до старта.
Наконец, самое очевидное — сроки не укладываются в прогноз систематически, а не разово или частично. Когда оценка расходится с фактом не от случая к случаю, а в каждом втором эпике — это не плохая экспертиза оценки, а разрыв между слоями — продукт не видит реальный объём задач разработки.
Надо понимать, что финансы — самый точный индикатор, но он запаздывающий. Опережающие — операционные метрики и паттерны коммуникации.
В конце могла быть отсылка к компании, предоставляющей качественную защиту или продукт. Но её не будет. Зато я открыт к предложениям о работе. 💼
Такого поворота я ещё не встречал. Но что точно - часто возникает ситуация, когда продукт разрабатывается на умозрительном предположении о потребностях аудитории, и когда реальность не сходится с замыслом, действительно начинают подтасовку в отчётах.
Clubhouse - да. Их главный и единственный продукт - их приложение и платформа для аудио-общения.
Магнит - нет. Это ритейл. Их главный продукт - это продажа товаров в магазинах. IT-отдел в Магните (как и в любом большом бизнесе) есть, но он является вспомогательной, а не продуктовой функцией.
Это компании, которые создают цифровой продукт, а не просто используют готовое программное обеспечение (софт) для своих задач.
Примеры IT-продуктовых компаний: Яндекс, VK, Ozon, Kaspersky. Они создают и продают свои сервисы и программы.
Непродуктовые (там IT - как поддержка): банк, который заказал себе сайт, или сеть магазинов, которая использует 1С. Софт не их главный продукт.
В контексте этого поста - сферы, где технологическая экспертиза (разработка, данные, продукт) является основным активом компании, а не вспомогательной функцией.
Например, IT-продуктовые компании, финтех, EdTech, любые стартапы, где ценность бизнеса создается кодом. Управление в таких условиях требует особого подхода, о котором я и пишу.
Это верно.
Иногда путают клиента и пользователя: менеджер не нашёл понятного отчёта, поэтому попросил инженера построить его по "сырым" данным. Инженер сделал, а позже заказал фичу для расширения API получения этих данных.
Продукт потратил деньги на выполнение запроса пользователя. При том, что правильнее было бы потратиться на закрытие проблемы клиента (менеджера) - создать удобный отчёт. Это принесёт больше ценности.
Финансовый контроль хорошо контролирует работу денег по компании в целом и по бизнес-юнитам в частности.
Чтобы также успешно контролировать работу каждой функции и продукта, нужно сначала формализовать цепочку ценности и процессы.
Это мало кто умеет и делает.
По опыту, гибрид тоже не панацея: из-за 1-2 сотрудников вне офиса устраивать телемост в переговорке. То им не видно доску, то их не слышно.
Возвращаемся к необходимости систематизации: сбор команд по определённым дням в офисе. И чтобы мест точно хватило. Уже сложнее и не каждый сможет правильно организовать.
Но при правильной организации всё возможно. И, как я писал, формат станет не важным.
Мне кажется, что только с опытом. Плюс нужна грамотно выстроенная система работы с эскалациями. Чаще всего компании пытаются подавить их как можно ближе к исполнителям, потому что иначе руководителей дёргают по пустякам. При такой перестройке опережающие индикаторы перестают работать.