Управление продуктом *

За последние несколько лет AI у меня, как и у многих моих коллег, стал одним из основных рабочих инструментов. И речь не только о том, чтобы иногда задать пару вопросов ChatGPT. AI инструменты сегодня способы приносить пользу продакт менеджеру и команде на каждом этапе жизненного цикла продукта — от появления идеи до его релиза в продакшн.

Недавно я завершила исследование, в рамках которого сравнивались два проекта по разработке продукта в сфере кибербезопасности. Один проект создавался без использования AI, второй — с активным использованием AI-инструментов на протяжении всего жизненного цикла продукта. Результат был следующий: суммарные трудозатраты (а, как следствие, и бюджет проекта) по второму проекту по сравнению с первым снизились на 36%.

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

Где именно AI может быть полезен в работе продакта сегодня?

Этап 1. Проверка гипотез и исследование рынка

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

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

Ким Чан и Рене Моборн подарили нам прекрасную мечту о “голубом” океане. Но не на все вопросы дали ответы... Например, как понять, куда совершать “скачок” в ценности и где открывать новое не охваченное конкуренцией пространство? Попробуем разобраться..

Привет, Хабр. Меня зовут Василий Щитов. Я старший инженер в команде CI-инфраструктуры ВКонтакте. 

Когда в компании десятки проектов и сотни сборок, ручное управление конфигурациями через UI быстро превращается в хаос. Внести однотипное изменение во все пайплайны, отследить историю правок или быстро развернуть окружение на новом инстансе TeamCity становится нетривиальной задачей. Можно превратить этот хаос в упорядоченную структуру, если описать конфигурацию как код с помощью Kotlin DSL. Но далеко не все понимают, как работать с Kotlin DSL для решения своих задач.

Я расскажу об основных подходах и паттернах, которые мы применяем, чтобы облегчить жизнь при работе с TeamCity.

В BI-проектах есть момент, который на бумаге выглядит как финал работы, а на практике часто оказывается только началом более сложной части.

Отчёт готов, данные обновляются, показатели считаются, доступы выданы, на демонстрации заказчик в целом согласен с логикой и просит разве что добавить несколько разрезов или поправить формулировки. С точки зрения проекта всё выглядит неплохо: есть артефакт, есть согласование, есть ощущение, что теперь у бизнеса появился нормальный инструмент для работы с данными.

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

Формально BI появился. Но способ управления почти не изменился.

Я не пишу это как претензию к бизнесу или к конкретным BI-инструментам. Обычно причина не в одном неудачном решении, а в том, что техническая часть проекта и управленческая часть проекта существуют отдельно друг от друга. DataLens, Power BI, Tableau, Metabase или самописный фронт могут быть вообще ни при чём. Отчёт может быть быстрым, аккуратным и полезным для просмотра, но при этом так и не стать частью процесса, в котором принимаются решения.

Кажется, проблема часто появляется раньше, чем аналитик открывает редактор дашборда.

Так уж повелось, что каждый автор и создатель уникального контента считает, что его профиль на крупной цифровой платформе – это его нематериальный актив. Увы, но это не так. Ведь, согласитесь, многие из нас сталкивались с такой ситуацией, что в один «прекрасный» день всё то, что мы годами собирали, формируя базу рецензий и текстов исчезает, как «тени в полдень».

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

Весной 2026 года один из авторов, пользователь книжного сервиса LiveLib столкнулся с гениальной технической рекомендацией, вместо стандартного отката транзакции или ручной правки записей в БД, поддержка выдала – просто заведите себе новый аккаунт. Тем самым платформа фактически расписалась в бессилии собственной архитектуры, сославшись на то, что восстановить бэкапы или связать данные старого профиля с новым технически «невозможно».

Но самое интересное началось позже, когда система автоматической модерации включила режим скрытого подавления.

Давайте с Вами разберёмся, а почему же платформа не блокирует неугодных или критикующих её авторов открыто, а использует пресловутый «режим скрытого подавления»? Всё дело в том, что прямая блокировка подобных авторов влечёт за собой юридический факт – нарушение платформой публичной оферты и статьи 29 Конституции РФ (запрет цензуры).

Привет, Хабр!

На связи команда Дирекции автоматизации девелопмента ПИК — Маргарита Золотых и Ольга Абражевич. В этой статье нам хотелось бы обсудить, какие аналитики будут востребованы в реалиях 2026 года и как найти себя в профессии тем, кто вырос до позиции Senior. С одной стороны, однотипное описание требований и фиксация чужих решений аналитикам становятся неинтересными. С другой стороны, компаниям с приходом доступных ИИ-инструментов и в тренде на оптимизацию бюджетов такой посредник становится нужен все меньше. 

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

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

Про AI-native agency, преждевременный SaaS и маржу на фрагментированном рынке.

Сервисной компании часто выгоднее сначала засунуть AI внутрь деливери, а не сразу делать внешний SaaS.

Производственник, который пришёл в IT. О том, почему до кода надо идти в цех.

Несколько лет назад наблюдал проект на одном производственном предприятии. Небольшое производство, человек 200. До нашего проекта руководство уже наняло специалистов 1С и начало автоматизировать учёт движения сырья и управленческую отчётность по сменам.

Когда мы пришли с проектом по бережливому производству, начали с диагностики. Построили карту потока — и стало понятно, что рановато на предприятии взялись за учёт. 30% операций оказались лишними: просто передача данных между подразделениями.

К концу внедрения 1С дошло: эти 30% операций никуда не делись.

Просто переехали из бумаги в 1С. Только теперь в красивом интерфейсе.

28 мая мы провели в Альпине закрытую мастер-встречу про то, как растить ИИ-компетенции в команде без миллионных бюджетов. На встречу подключились более 150 специалистов из фармы, ритейла, IT, логистики и банков. Я рассказывал про наш путь в AlpinaGPT, коллеги показывали свои кейсы в маркетинге, продажах и разработке, в зале задавали вопросы CTO и L&D-директора крупных российских компаний. После трёх часов разговоров у меня осталось одно главное наблюдение — то, ради чего я и пишу эту статью.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT, Head of AI Alpina Digital и автор тг-канала «Готовим ИИшницу». Главное наблюдение простое: разрыв в ИИ-компетенциях растёт. Одни сотрудники работают с моделями ежедневно, у них уже свой стек, свои шаблоны, своя память между сессиями и встроенные в рабочий процесс агенты. Другие открыли ChatGPT один раз, написали что-то вроде «составь мне отчёт», получили шаблонный текст без контекста, решили, что инструмент бесполезный, и закрыли вкладку. Между этими двумя сотрудниками разрыв растёт каждый месяц быстрее, чем компании успевают его закрывать обучением. 

Разрыв в компетенциях растёт быстрее, чем обучение его закрывает

Главная цифра, которую я показывал на мастер-встрече, — из свежего отчёта DataCamp и YouGov State of Data & AI Literacy 2026 (опрос 517 enterprise-руководителей в США и Великобритании, декабрь 2025 — февраль 2026). 82% компаний уже предоставляют ИИ-обучение для сотрудников, и при этом 59% этих же компаний сообщают, что разрыв в ИИ-компетенциях у них всё равно сохраняется. 23% опрошенных заявили, что программы обучения не адаптированы к конкретным должностным обязанностям, 21% опрошенных говорят, что сотрудникам сложно понять, с чего начать. То есть деньги в обучение пошли, программы запустили, лицензии раздали — а сотрудники в массе своей по-прежнему не владеют ИИ на нужном уровне.  

Когда я отвечал за бизнес-юнит МСБ в Кайтене, мне нужно было посчитать юнит-экономику B2B SaaS с длинным циклом сделки. Задача казалась простой — поделить LTV на CAC и сравнить с порогом. Я неоднократно так делал для B2C для сделок короче месяца.

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

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

Даже если есть приток новых партнеров, выйти на какой-то заметный уровень активных продаж не получается. В итоге партнерский канал растет медленно. Хотя, казалось бы, это база.

У меня есть свой взгляд на эту тему — все-таки 12 лет в роли CMO Битрикс24, где партнерская сеть насчитывает более 10 тысяч компаний, дает определенную пищу для размышлений. Но в этот раз я решила пойти другим путем и спросить самих интеграторов: а что им нужно, чтобы принять решение о работе с вендором?

Почему-то при работе с интеграторами компании чаще всего сосредоточены на том, чтобы рассказать о себе. Но гораздо реже задают простой вопрос: «А чего на самом деле хочет партнер?»

Мы сделали серию интервью с интеграторами и с удовольствием делимся ею с вами. Надеемся, будет полезно.

Первый разговор — с Марией Бар-Бирюковой, директором департамента e-commerce ГК «КОРУС Консалтинг». 

На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Сегодня разбираем, как написать биллинг для продакшн ИИ-агента.

Когда ваш ИИ-бот начинает отвечать клиентам в B2B-сегменте, каждый его ответ стоит токенов. Чтобы экономика продукта сходилась, расходы на LLM нужно жестко контролировать и тарифицировать. Кажется, что достаточно просто прикрутить калькулятор, но на деле всё сложнее: один HTTP-запрос может дергать до пяти разных нейросетей, и не все они идут через стандартный граф фреймворка.

В новой статье на Хабре рассказываю: — Почему считать деньги по чатам — это путь к хаосу. — Зачем мы изобрели «микрокредиты» вместо наивных токенов. — Как протащить контекст биллинга через пять LLM-вызовов в одном запросе с помощью магии ContextVar + Mixin.

Разбор для тех, кто делает multi-tenant LLM-сервисы и уперся в ограничения готовых прокси-решений.

В феврале 2024 года американская ContextLogic объявила, что продаёт маркетплейс Wish сингапурскому холдингу Qoo10 за 173 млн долларов. Цифра выглядит обычной для сделок такого рода, пока не вспомнить, что десятью годами раньше Wish был самым скачиваемым шоппинг-приложением планеты, оценивался в 14 млрд долларов и официально отказался от предложений о покупке от Amazon и Alibaba по 10 млрд каждое. Цена сделки оказалась на 99% ниже пиковой оценки — фактически от компании, претендовавшей на роль следующего Walmart, остался только торговый знак, переходящий из рук в руки.

Платёж не прошёл. Отключить пользователя сразу или подождать? Если подождать, то сколько и на каких условиях? Разбираем механику grace-периода изнутри: состояния подписки, поведение доступа для B2C и B2B, цепочку уведомлений и технические подводные камни.

Когда ваша команда в последний раз замечала важный рыночный сдвиг* до того, как он попал в отраслевой доклад на ежегодном форуме или стал темой колонки в Forbes? Если честный ответ требует паузы — значит, в компании нет своей системы раннего обнаружения возможностей (РОВ). Возможно, отдел маркетинга ведёт мониторинг упоминаний бренда и отзывов в СМИ и социальных сетях. Но это не одно и то же.

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

Это не вопрос доступа к информации. Это проявление того, как организация работает с сигналами о будущем, если работает вообще.

В этой статье — пять шагов процесса РОВ, три кейса из российской практики и конкретный план действий на ближайшую неделю. Без теории ради теории.

_{* – Рыночный сдвиг (от англ. Market Shift) — существенное изменение базовых условий на рынке (в поведении покупателей, регулировании, предложении продуктов или технологий), которые формируют новые стандарты, разрушают прежние бизнес-модели и требуют от компаний смены стратегии – для удержания лидерства в конкурентной борьбе, а то и – выживания.}

Привет! Меня зовут Андрей, я инженер в Циане. Примерно год назад мы начали внедрять в работу AI-помощников для разработки, а несколько месяцев назад сфокусировались на Claude Code как самом продвинутом из доступных. Сейчас пилотно используем его в командах инфраструктуры, платформы, продуктовой разработки. Масштаб здесь велик, риски интеграции AI тоже. В статье я расскажу, какие проблемы мы решали в процессе внедрения. И призываю вас поделиться своим опытом в комментариях.

В конце мая вышло исследование «After the Hype: Resilience Seeking in Emerging Technology Ecosystems» (Journal of Product Innovation Management, 2026), которое изучает, что происходит с технологическими экосистемами после того, как угасает их хайп. Авторы разобрали это на примере XR (VR, AR, MR) и показали, как три типа игроков (поставщики технологии, разработчики дополнений и внедряющие компании) пытаются вернуть утраченный интерес и деньги. Уверен, будет интересно ознакомиться как продактам, так и топ-менеджменту: в статье есть и теория, и понятные практические выводы.

Как промт превратил языковую модель в проводника смыслов и источник инсайдов для бизнеса: AI-конструктор офферов

История эволюции инструмента анализа бизнеса: от создания офферов до AI-агента-проводника, который помогает предпринимателю прояснить свой бизнес через диалог.

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

Смотреть на это спокойно я не мог — и не из брезгливости. Я видел, сколько это стоит. Нарисовал флоу KYC один раз — иди рисуй его ещё семь, и каждый раз почти с нуля, потому что переиспользовать нечего. Вот где горело время.

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

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

Дорожная карта должна превращаться не в поток релизов и обновлений, а в систему сценарного планирования, позволяющую перестроить свой план в любой момент.

Для этого продуктовым командам нужно перейти от классических дорожных карт в формате разработки конкретных функций к формату приоритетов и сценариев.

В статье описывается готовый фреймворк построения сценарного RoadMap.