Системы в бизнесе Продолжаю над этим работать, за две недели наклепала 12 документов в самых разных форматах - от серьёзного документа на десять страниц до чек-листов, презентаций и карточек исполнения. Темы разные: от чек-листа, как проводить встречи один на один со своими сотрудниками, до проверки Яндекс.Карт и стандартов сервиса. Сначала все процессы были изложены просто на бумаге, документы, а потом я осознала, что в современных реалиях внимание необходимо держать, даже если это всем нужно. Поэтому форматы совершенно разные. Какие выводы? Первое. Эпоха продуктов в инфобизе из серии «вот вам регламенты, инструкции и чек-листы, а я расскажу, как это делать» потихоньку уходит в лету. Потому что с таким помощником, как Клод, всё это делается достаточно быстро, даже если, как мне кажется, человек не такой эксперт, как я, но могу ошибаться. Второе. Для того чтобы описать/создавать системы в бизнесе, сегодня, по сути, вообще никто не нужен, нужен опыт и понимание. Третье. Помимо того чтобы эти бизнес-процессы описать, нужно ещё их внедрить, причем желательно без напряжения, а для этого тем, для кого ты это внедряешь должно быть просто-понятно-удобно, как бы базовая вещь, но почему-то не всегда так. А самое главное - всё это нужно было сделать намного раньше. Я годами это откладывала, все время пытаясь найти, кому бы это поручить. Сегодня все намного проще. Славься ИИ!!!

↓↓↓ Forward Deployed Product Manager Менеджер по продукту, работающий непосредственно с клиентом (FDPM) — работает в компании-поставщике и взаимодействующий с пользователями продукта для обеспечения его успешного функционирования в данной организации. Он принадлежит одной компании, но интегрирован в другую, и отвечает за эффективность работы продукта в среде конкретного клиента. В зависимости от компании, FDPM может обслуживать как одного клиента, так и небольшой портфель клиентов. Суть работы Заключается в непосредственном контакте с командой. Вместо того чтобы полагаться на интервью, заявки в службу поддержки, менеджер видит, как возникает проблема и как люди в настоящее время ее решают. Он сталкивается с проблемой, а не просто слышит о ней рассказы. Дальше: - Прототипирование - Результат FDE vs FDPM 1. FDE отвечает за "как", FDPM за "что" и "почему" 2. принимает решение о том, как следует изменить сам продукт, исходя из результатов этих реализаций. 3. несет ответственность за результаты и обязан передавать полученные знания обратно в разработку продукта. AI PM vs FDPM Менеджер по ИИ продукту: разрабатывает ИИ фичи для рынка. Менеджер по продуктам в области ИИ фокусируется на том, чтобы продукт работал для конкретных клиентов. Затем выполняет две задачи: 1. определяет, что обеспечит успех этому клиенту, часто путем настройки платформы и создания прототипов работающих решений с реальными пользователями. 2. передает полученные знания команде, разрабатывающей основной продукт, чтобы от этого выиграли все остальные клиенты. Большинство FDPM работают вместе с инженером по внедрению решений (FDE), который отвечает за техническую составляющую, в то время как FDPM отвечает за потребности клиента и их обоснование. Спрос На сайте The Bench , посвященном европейским технологическим компаниям, к концу июля 2026 года было зарегистрировано 170 вакансий с пометкой «Внедрение на перспективу» в 98 компаниях. Количество новых вакансий выросло с одной в январе до 62 в июле. Большинство из них – инженерные должности, и The Bench обнаружил множество вакансий под другими названиями, поэтому должности FDPM представляют собой подгруппу. Хотя они и заметны: Scale AI, Salesforce и Adobe входят в число компаний, размещающих объявления о таких вакансиях. 🎞 Интересный ролик — ИИ пишет код. Что же остается инженерам? — самое сложное: понять в чем заключается проблема. Google APM program выпускает по 50 чел/год, а нужно около 12 000.

🤡 Внедрение ИИ превращается в корпоративный спектакль Опубликованный 23 сентября отчёт Visier описывает новый эффект — *performative AI*, или показное использование искусственного интеллекта. Компания опросила 1 000 работающих полный день американцев и дополнила ответы интервью с сотрудниками из здравоохранения, финансов и HR. 🔵48% хотя бы иногда преувеличивали свой опыт или частоту использования ИИ 🔵45% чувствуют давление применять ИИ, даже когда не уверены, что умеют делать это эффективно 🔵59% не видят у работодателя ясного плана либо не знают, существует ли он 🔵Только 21% полностью согласны, что получают достаточно обучения и поддержки 🔵54% считают, что ИИ уже заметно изменил их роль или карьеру Сотрудники не обязательно пытаются сознательно обмануть компанию. Они подстраиваются под сигнал руководства: современный и эффективный специалист должен пользоваться ИИ. Признаться, что инструмент не подошёл для задачи или потребовал слишком много исправлений, становится рискованнее, чем сообщить об очередном успешном применении. Так внедрение незаметно превращается в соревнование по демонстрации активности. Люди упоминают ИИ на встречах, открывают корпоративные инструменты и добавляют технологию туда, где привычный способ работал быстрее. Дашборд показывает рост использования, но компания всё ещё не знает, стала ли работа лучше. Особенно легко получить такой результат, если руководители ставят цель «увеличить использование ИИ». Человек быстро понимает, какое поведение от него ждут. Чем сильнее частота входов, количество запросов или пройденных курсов влияют на оценку, тем меньше этим данным можно доверять. Полезнее начинать с конкретной проблемы: какую работу нужно ускорить, упростить или сделать качественнее? После эксперимента достаточно проверить, что изменилось с учётом проверки и исправления результата. Важно разрешить и честный ответ: «здесь ИИ не помог». Неудачный сценарий тоже экономит компании время — если его не будут повторять сотни сотрудников. Руководителю при этом нужна не декларация «используйте ИИ активнее», а понятные границы: где инструмент уместен, какие данные нельзя передавать, кто отвечает за итог и в каких задачах человеческая работа остаётся предпочтительной. Тогда сотруднику не приходится изображать уверенность, чтобы не выглядеть отстающим. ✅ Вывод Когда использование ИИ становится самостоятельной целью, сотрудники начинают оптимизировать не работу, а отчёт о внедрении. Зрелая компания спрашивает не «сколько людей открывали инструмент», а «какая задача теперь решается лучше». Всё остальное легко превращается в цифровую имитацию прогресса.

Forward Deployed PM: почему за ними охотятся AI-гиганты Не успели мы привыкнуть к новой роли Product Builder, как на горизонте замаячила новая волна интереса к роли Forward Deployed Product Manager (FDPM). Разбираю, что это такое. 1. Кто такой FDPM и чем он занимается? Обычный PM сидит в офисе своей компании и отвечает за продукт вообще. FDPM десантируется прямо на сторону клиента. Он погружается в реальный операционный хаос заказчика, сидит с его сотрудниками, разбирает их инфраструктуру и отвечает за бизнес-результат конкретного аккаунта. Посадить продуктовика с ценником FDPM внутрь клиента - дорогой шаг, поэтому FDPM отправляют только в два типа аккаунтов: 1. Tier-1 Enterprise (High-LTV): клиенты с чеком $500k – $1M+ ARR, уход которых критичен для бизнеса. 2. Бета-проходцы новых AI-продуктов: когда запускается сложная модель или интеграция, а рынок еще не понимает, как внедрять софт по стандартным инструкциям. Для малого и среднего бизнеса эта модель не применяется, там работают стандартный Self-Serve и отдел CSM. 2. Что по зарплате и вакансиям * Динамика роста: на платформе The Bench число вакансий с формулировкой Forward Deployed выросло с 1 открытой позиции в январе до 170 активных ролей в 98 компаниях к концу июля. * Кто и где нанимает: основной спрос сосредоточен в США (Bay Area, Нью-Йорк, Вашингтон), Великобритании (Лондон) и европейских хабах вроде Берлина и Амстердама. Нанимают Scale AI, Salesforce, Adobe, Accenture, Cresta и Palantir. * Зарплаты: вилка базового оклада для FDPM в США варьируется от $180,000 до $250,000+ (в Scale AI на Public Sector вилка доходит до $345,000). 3. Примеры открытых вакансий Посмотреть на требования и задачи этой роли на рынке можно на листингах: Tribe AI - Forward Deployed Product Manager : транслировать сложнейшие задачи клиентов в готовые продуктовые AI-решения и вести внедрение вместе с продуктовой командой. Sela AI - Forward Deployed Product Manager: отвечать за внедрение AI-агентов под ключ, пересобирая их под то, как реально работают банковские процессы у клиентов. CruxOCM - Forward Deployed Product Manager: работать с техническими лидами заказчика, использовать AI-инструменты для прототипирования и переводить спецификацию конкретного завода в фичи бэклога. Causal Labs - Forward Deployed Product Manager: вести ключевые запускные проекты для требовательных enterprise-клиентов и замыкать кастомные решения на ядро системы. 4. Окей, открываю позицию FDPM. Как нам не скатиться в заказную разработку? Главный риск для FDPM - уйти в бесконечное пиление кастома под одного громкого заказчика. Чтобы защитить ядро платформы, используют правило триангуляции: 1. Быстрый костыль: решаем проблему конкретного клиента локальным кодом или скриптом прямо сейчас. 2. Валидация: ищем, повторяется ли эта проблема у других 3–5 клиентов платформы. 3. Экстракция в Core: если боль системная, фича уходит в бэклог основной платформы. Если она нужна только одному заказчику, то остается локальным костылем на его стороне. Источник: https://www.mindtheproduct.com/what-is-a-forward-deployed-product-manager-anyway/ @productgames

Вышел первый серьезный подкаст со мной Получилось очень живо и плотно по темам. Обсуждали скиллы, безопасность и сложности внедрения в компании Классно, что получилось обсудить много микро-деталей, которые обычно не влезают в тг посты. На чилловый просмотр под пиво/чай/прогулку – самое оно 00:01:47 - Бизнесу часто не нужен отдельный кастомный AI-продукт 00:16:56 - Люди не могут рассказать, как именно делают свою работу, а агенту, как и сотруднику, нужен онбординг 00:24:39 - Полностью автоматические системы регулярно проваливаются 00:36:43 - Доступ в терминал делает агента гибким, но усложняет контроль. Ценность смещается от производства результата к ответственности за него 00:47:08 - Корпоративная инерция и Shadow AI 01:01:40 - Слабые места моделей; Как быстрее всего учиться строить ИИ продукты 01:17:10 - Разрыв между лидерами и остальными. Внедрять ИИ важно не только из-за роста производительности в моменте 📱 Смотреть полную версию Бтв, нарезку выше сделал агент с нуля, но с одним небольшим хаком, угадаете каким?

5 типов личностей по ур. готовности к внедрению ИИ Анализ 5 ключевых аспектов, влияющих на готовность людей к интеграции искусственного интеллекта в рабочую среду. - AI enthusiasts (энтузиасты ИИ) - Мотивированы инновациями, эффективностью, конкурентным преимуществом - Активно хотят внедрять и использовать ИИ - Часто становятся внутренними драйверами (champions) - AI curious (любопытные к ИИ) - Интерес есть, но без слепой веры - Ждут доказательств, ответов на практические вопросы - Готовы пробовать, но в безопасной среде (sandbox) - AI cautious (осторожные) - Думают про риски: безопасность данных, этика, влияние на людей - Хотят контроль и участие человека (human-in-the-loop) - Не против ИИ, но только при строгих ограничениях - AI sceptics (скептики) - Не верят хайпу, требуют доказательств эффективности - Опираться будут на эмпирику (A/B тесты, сравнения) - Часто это рациональные и опытные специалисты - AI opposed (противники) - Сильное сопротивление из-за страхов (потеря работы, контроль, слежка) - Могут полностью отказываться использовать ИИ - Требуют работы с глубинными тревогами --- Интерпретация (для продукта/внедрения): - Это сегментация пользователей по readiness, а не по роли - Основной барьер — психология и доверие, а не технология - Внедрение ИИ = change management + behavioral design