Александр Козуб

Не могу не поделиться своим открытием! Хотя для многих это и прозвучит как баян, но я для себя вновь открыл ценность ИИ.

“Надо увеличить ценность нашего продукта!” - фраза, которую произносил, пожалуй, каждый продакт хотя бы раз за свою карьеру. Эта фраза уже так набила оскомину, что уже потеряла всякий смысл.

Пьеса в 15 частях от продуктового лидера, который строил-строил лояльность, да так и не достроил.

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

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

Помню, в далеком 2014 году, когда я примерял на себя роль проджекта, частенько срывался на продакта: «Мы же договорились! У нас дедлайн через неделю, команда уже работает! Зачем ты снова все меняешь?!»

Ваша команда выкатывает новую фичу за фичой. A/B-тесты показывают +3% к конверсии. Продакт ставит задачам статус "Done", команда получает поздравления от СРО. А через два месяца выясняется: 40% пользователей по-прежнему отваливаются на том же критичном шаге. Проблема не решена. Но в бэклоге она больше не приоритетна - там уже 47 других "важных" зад…

Почему команда из 200 разработчиков оценивает задачу в 6 месяцев, когда стартап из 10 человек делает её за месяц? Почему продукты со временем теряют способность к инновациям, даже имея все ресурсы? Ответ не в технологиях. Ответ - в ментальных ограничениях.

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

Замечаю, что в современной продуктовой разработке царствует методологический хаос и даже фреймворкоблудие. Продакты и команды мечутся между удовлетворением «потребностей пользователей», решением «задач» через Jobs to be Done и внедрением «геймификационных механик», не особо вникая, как эти концепции связаны между собой.

Мы постоянно путаем понятия: подменяем цели тактическими задачами, называем операционное управление стратегией, составляем планы на 100 страниц вместо того, чтобы найти тот самый единственный рычаг, ключ к успеху. Ричард Румельт в своей книге «The Crux: How Leaders Become Strategists» (в русском переводе — «Взлом стратегии») расставляет все по мест…