Продукт

Все вокруг теперь программисты Короче, у Gergely Orosz в The Pragmatic Engineer вышла интересная статья про новый тренд: крупные компании начали создавать собственные аналоги Lovable для сотрудников. И нет, не для разработчиков! А для менеджеров, маркетологов, финансистов и прочих ребят, которые хотят сделать себе какой-нибудь инструмент, но писать код не умеют. Вот вам два примера. 1. Ramp и их Glass Ребята собрали собственную платформу для вайб-кодинга внутренних приложений. Причём первую версию сделали всего два инженера за несколько недель. Теперь любой сотрудник может описать, что ему нужно, подключить корпоративные источники данных и получить работающее приложение. Например, маркетолог собрал себе CRM с более чем 50 полями и фильтрами. И знаете, что самое интересное? В Ramp создание первого инструмента через Glass уже стало частью онбординга новых сотрудников! А 13 октября компания вообще вывела Glass на внешний рынок. 2. Stripe и их Harbor Здесь ещё интереснее. Один инженер за 40 дней создал внутренний инструмент для генерации интерактивных прототипов. И вот результаты с мая 2026 года: • Более 12 000 созданных прототипов. • Более 3 000 сотрудников воспользовались инструментом. • 25% сотрудников Stripe создали хотя бы один прототип. Причём используют его не только дизайнеры. Финансисты собирают интерактивные отчёты вместо презентаций, продавцы калькуляторы ROI, аналитики - дашборды. А самое интересное технически: Harbor интегрирован с другими AI-инструментами Stripe через MCP. То есть прототип можно передать coding-агенту для дальнейшей реализации. Оооокей! А зачем делать свой Lovable, когда уже есть готовые? Orosz выделяет несколько причин: 1. Данные. Корпоративную информацию не хочется отправлять в сторонние сервисы. Своя платформа позволяет контролировать доступ к ней. 2. Интеграции. Можно сразу подключить внутренние API, базы данных и другие системы компании. 3. Стандарты. Генерируемые приложения используют корпоративную дизайн-систему, а не выглядят как результат очередного хакатона. 4. Стоимость внедрения. Иногда собрать собственный инструмент оказывается сопоставимо по усилиям с выбором вендора, согласованием безопасности и последующим внедрением. 5. Компетенции. Инженеры заодно учатся строить собственную AI-инфраструктуру. А теперь моя любимая часть! Кажется, мы наблюдаем довольно интересную трансформацию роли инженерных платформ. Раньше у нас был внутренний заказчик, который приходил к разработчикам и говорил: - Ребята, сделайте мне дашборд, форму или какой-нибудь маленький инструмент! Разработчики брали это в бэклог, приоритизировали, обсуждали, оценивали… А через полгода сообщали, что в этом квартале ресурсов нет. 😁 Теперь этот же сотрудник может собрать себе нужный инструмент самостоятельно. И вот тут возникает интересный вопрос. Если создавать приложения сможет каждый, кто будет отвечать за весь этот зоопарк? Кто управляет доступами? Кто контролирует стоимость исполнения? Что делать, когда автор приложения увольняется? И кто гарантирует, что какой-нибудь вайб-кодер не откроет доступ ко всей корпоративной базе? Кажется, ответ опять - платформенные команды. Только теперь их задача не просто делать удобные инструменты для инженеров, а создавать безопасную среду, в которой приложения могут создавать вообще все сотрудники. И, на мой взгляд, это куда более интересная история, чем очередное ускорение написания кода на 30%. Потому что мы меняем не скорость разработки. Мы меняем то, кому вообще нужна команда разработчиков для создания программного обеспечения.

П.Я.Т.Н.И.Ц.А. становится настоящей! Роберт Дауни-младший снялся в рекламе очков с дополненной реальностью. Это AR-проект Snap, владельца Snapchat. Идея — разместить цифровые инструменты в окружающем пространстве: смотреть на виртуальный экран, видеть подсказки перед глазами, работать с объектами жестами и голосом. Компания привлекла актёра к кампании и дала ему почётную роль Chief Customer Experience Officer. По анонсу, он будет работать с командой над контентом, приложениями и устройствами. Связь с Тони Старком считывается сразу — и сам Дауни её обыгрывает. За этим роликом есть вполне конкретный продукт: на официальном сайте SPECS указан предзаказ от $2 195. Пока — в США, Великобритании и Франции; начало поставок заявлено на осень 2026 года. Мне хочется увидеть, какая ежедневная задача оправдает цену и ношение ещё одного устройства. Какая функция убедила бы вас попробовать такие очки? Видео: SPECS — Lights On | SPECS x Robert Downey Jr. P.S. В прессе фигурировала сумма $100 млн акциями для Роберта.

Как статья 2014 года стала кнопкой на всех маркетплейсах На днях Elsevier (это крупнейшей научное издательство в мире, им принадлежат The Lancet, Cell, платформа ScienceDirect и т.д.) опубликовало список самых цитируемых учёных мира за 2025 год, и в топ-1% по ИИ и обработке изображений попали исследователи из Yandex Research - например, Людмила Прохоренкова (автор статьи про CatBoost) и Артём Бабенко. Новость важная, но чтобы она стала менее абстрактной и более "фичевой" - давайте на конкретном примере покажу, как научная цитируемость превращается в конкретную кнопку, которую мы жмём каждую неделю или около того. Год назад я разбирал, как все российские маркетплейсы разом - от Маркета до Озона и т.д. - одновременно внедрили примерно одинаковый поиск по фото. С тех пор он стал весьма востребованной фичей, кстати. Так вот, у него есть конкретная дата рождения: 2014 год, из статьи того самого Артёма Бабенко и его коллег про "нейрокоды". Идея там была довольно-таки хулиганская. Они взяли нейронку, обученную совсем другому - например, отличать питбулей от картошки (это кстати не так просто, если вы понимаете о чём я). Но вместо финального ответа вытащили из неё числа с внутренних слоёв. И оказалось, что эти числа представляют собой отличное описание картинки: если у двух фоток они близки, значит, на них похожие штуки. То есть, нейронку никто специально не учил искать похожие фотки, но она сама это делала. Плюс, бонусом выяснилось, что такое описание можно ужать до короткого вектора почти без потери точности - а значит, хранить и перебирать миллиард товаров можно экономически рентабельно. С тех пор любой поиск по фото примерно так и устроен. Ваша фотка кроссовка превращается в вектор, кроссовки в каталоге - тоже, и ближайшие векторы выдаются вам как результат. Это объясняет, почему фича у всех появилась одновременно и выглядит примерно одинаково. Потому что рецепт один, и он существовал уже давно. И как только обвязка под него достигла сносного уровня - его тут же все запилили. А конкуренция идёт уже не в самой фиче, а в том, насколько чисто размечен каталог и насколько годно сеть дообучили именно на своих товарах (в той статье 2014 года про пользу такого дообучения тоже написано, кстати). Так что, если вдруг маркетплейс по фото вашей кружки найдёт унитаз - не ругайте учёных. Нейронка всё делает правильно, просто кто-то поленился её дообучить. Фичизм

Вы единственный продакт в стартапе. К вам приходят с вопросами — а к кому идти с вопросами вам?

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

Кажется, что главная трудность роли единственного менеджера продуктов в компании — не у кого учиться. На самом деле с источниками знаний проблем нет: профессиональные сообщества, конференции, менторские программы и просто общение с друзьями — все это помогает находить информацию. Не хватает другого — обратной связи конкретно на вашу работу. Статья объяснит, как устроена приоритизация, но никто не скажет, что ваш бэклог на квартал собран вокруг одного клиента, который громче всех доказывает важность фичи именно для него. В большой команде это заметит лид на ревью. В стартапе — только вы сами и возможно остальные недовольные клиенты, но это уже совсем другая история. Ментор может помочь, но и у него есть пределы. А часть особенностей этой роли вообще не про обучение — их полезно знать заранее. Ментор не заменит CTO По техническим вопросам никто не поможет вам так, как собственный технический директор: он знает архитектуру продукта и ограничения команды. Чем лучше вы понимаете друг друга, тем быстрее растете вы оба и ваш продукт. Свой рынок вы будете знать лучше ментора Ментор поможет проверить логику решения, но не скажет, чего хотят ваши клиенты. Здесь главный учитель — пользователи. В стартапе вы к ним ближе всего, и этим стоит пользоваться. Систему придется строить самим На ранних стадиях процессы в стартапах часто еще не выстроены или выстроены на скорую руку, «чтобы просто работало». Выстраивать их будете вы, и ошибок будет много. Где-то рост пойдет медленнее, чем в большой компании, зато опыт в этом деле вы получите колоссальный. Начните с одного процесса — как вы приоритизируете задачи, — и формализуйте его. Дальше действуйте в рамках правил, которые вы согласовали. Договориться о границах с основателем стоит на берегу В стартапе продуктовые решения часто принимает основатель. Обсудите на старте, какие решения приносите вы, а какие готовы брать с его стороны. Иначе вы будете отвечать за результат, которым не управляете. Как создать себе обратную связь: — Найдите одного-двух менеджеров продуктов из других компаний и раз в месяц разбирайте решения друг друга. — Записывайте ключевые решения и ожидаемый результат, чтобы потом было с чем сверяться (о таком журнале принятия решений мы уже рассказывали ранее). — Если оценить ваш уровень пока некому, сверяйтесь с картой компетенций. ИИ тоже может помочь, если просить его найти слабые места и аргументы за/против решения, а не оценить, хорошее ли оно. Так к кому идти с вопросами? Не к одному человеку, а к нескольким: с техническими — к CTO, с вопросами о рынке — к пользователям, с решениями — к коллегам-продактам, а с границами и системой — накапливать опыт, который будете получать на реальных задачах. Лида, который видит все и сразу, в стартапе часто нет. Поэтому такой круг обратной связи вам придется собрать самостоятельно. Но это точно окупится и даст кратный рост в профессии. @productmindset

Когда рост выручки работает против продукта Чтобы быть услышанным стейкхолдерами, нужно уметь связывать фичу с деньгами. И в этой связи важно соблюдать баланс. Разберем, как подружить финансовые и продуктовые метрики без вреда для продукта и выручки. Это вторая часть серии постов о финансовых метриках. Первая — о том, на каком языке менеджеру продукта говорить с бизнесом. Связь продукта и выручки бывает прямой и косвенной ➡️ Пример прямой связи — лента VK

Продукт зарабатывает на рекламе. Чем дальше человек листает, тем больше рекламных постов он видит, тем больше охватов получают рекламодатели и тем выше выручка. Глубина ленты переводится в деньги.

➡️ Пример косвенной связи — чат между водителем и пассажиром в inDrive

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

Главное — не перегнуть Чем сильнее фича влияет на выручку, тем сильнее соблазн давить на этот рычаг. И если в этот момент испортить пользовательский опыт ради финансовых метрик, то успех, скорее всего, будет краткосрочным, а за ним последуют отписки, возвраты, отвалы аудитории.

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

Как связывать метрики и не обмануться ➡️ Лучше всего связывать метрики бизнеса и продукта аналитически: через эксперименты и корреляционные матрицы. При этом помнить, что корреляция еще не означает причинности. ➡️ Если посчитать не получается, можно рассуждать логически: «чем глубже листают, тем больше видят рекламы». Это слабее, но лучше, чем ничего. ➡️ Если в эксперименте прокрасилась выручка, а фундаментальные метрики (ретеншен, ключевые конверсии) нет, скорее всего, что-то не так. Перепроверьте и перезапустите тест. Запуск задержится, зато вы будете уверены, что изменения будут приносить результат и в долгосроке. ➡️ В продуктах с сетевым эффектом обычный A/B-тест может показать прирост, которого нет: тестовая группа просто забирает заказы у контрольной. Здесь помогают switchback-эксперименты (метод тестирования, при котором изменения включают и выключают для всего региона в разные промежутки времени). Это долго и сложно, но работает. ➡️ Если результаты теста кажутся странными, посмотрите на рынок: конкурентов, альтернативы, экономику. Возможно, на поведение пользователей влияют изменившиеся внешние факрторы. Связывая продуктовые и финансовые метрики, важно помнить, что задача продакта — устойчиво улучшать пользовательский опыт. Экологично монетизировать аудиторию получится только поверх этого, а не вместо. В следующем посте разберем, как через влияние на выручку получать ресурсы, когда компания никого не нанимает. По мотивам доклада «Финансовые метрики для продакт-менеджеров: как поженить продукт и деньги» Никиты Лебедева на ProductSense’25 Смотреть видео в Академии ProductSense (бесплатный доступ) → @productsense

Первый принцип хороших процессов Первый принцип хорошего дизайна процессов: Не заставляйте меня думать! У специалистов по юзабилити есть такая шутка: - Идеальная форма состоит из одной кнопки «Сделайте мне хорошо». - Нет, идеальная форма состоит из одной надписи: «Тебе уже хорошо». В этой шутке есть большая доля правды. Любые действия должны быть максимально понятными, простыми и очевидными. Это касается всего: машин, механизмов, портал, вебстраниц, документов — всего, с чем взаимодействует человек. Сотрудник не должен думать ни о чем, кроме того, что составляет сферу его профессионального интереса. Более того, даже в сфере его профессионального интереса количество вариантов того, что сотрудник должен сделать — должно постоянно уменьшаться. Айфон в свое время был революционным смартфоном. Это был первый смартфон без инструкции. До этого смартфоны снабжались толстой книжкой, в которой описывалась как работать со смартфоном. Эппл же разработала настолько простой смартфон, что 99% функций в нем доступны интуитивно. (да, по ряду вещей все равно приходится гуглить, но по сравнению со старыми телефонами — это был скачок вперед!) Дизайнер Дон Норман говорил, что если вы видите слова «смотрите в прилагаемой инструкции», вы знаете, что о вас, как о клиенте, данная компания не позаботилась должным образом. Я дополню: когда сотрудник компании видит безумные инструкции по 100-200 страниц, в которых ничего не понятно — то это значит, компания не позаботилась о сотруднике. То есть, проектировать процесс надо так, чтобы людям там приходилось думать минимально. Тогда процесс будет идти с минимальным количеством ошибок. Исходя из своего опыта могу сказать, что фактически все процессы можно улучшить и упростить за счет несложных доработок и простого изменения дизайна. Да, в какой-то момент потребуется привлекать более сложные инструменты, отслеживать движение глаз, замерять время для нажатия на кнопки и т.д. Но это уже для совсем продвинутых вариантов. #ЧФ #когнитивная_нагрузка

В процессе работы над PersMarket регулярно появляются новые возможности, которые должны быть видны не сразу или не всем. Для таких целей придумали специальный подход - Feature flags (или feature toggles). Я уже упоминал его ранее, когда писал про минимизацию рисков и даунтайма при деплое. Заключается подход в том, чтобы была возможность включать, выключать или менять поведение отдельных функций приложения в реальном времени без повторного деплоя. То есть код и настройки фичи выкатываются очередным релизом, но где-то в базе/конфигах есть переключатель/флаг, по умолчанию выключенный, от состояния которого зависит, работает ли эта функция. И когда приходит момент, флаг просто включают, и пользователи сразу видят новые ништяки. Например, функция оплаты актуальна только после всех согласований с платежным провайдером и обновления юридических документов, хотя код уже должен существовать, чтобы протестировать процессы.

Кстати, имея опыт работы со Stripe, подключал Робокассу. После современных API-управляемых возможностей Stripe Робокасса выглядит, как что-то из нулевых. В Stripe можно построить полноценный тестовый контур, с автотестами, с подписками, платежами, рефандами и т.д. В Робокассе можно сделать только тестовый разовый платеж без истории. То есть узнать его статус позже нельзя, он не хранится. А возвраты и рекуррентные платежи вообще не поддерживают тестирование. Надо будет попробовать других провайдеров еще для сравнения.

Еще сценарии: ▪️Если в функции есть критичный баг, ее можно отключить мгновенно без передеплоя ▪️Можно сделать канареечный релиз - включать функцию сначала малой аудитории, потом больше и больше ▪️Можно проводить A/B-тестирование ▪️Можно тестировать функцию прямо из мастер-ветки (особенно в trunk-based разработке), не включая ее на проде Вот и я себе сделал в админке сервиса такой пункт управления, чтобы включать фичи по мере готовности к ним платформы. А оказывается, есть и готовые решения: Split, Flagsmith, LaunchDarkly, GrowthBook, Unleash. А для PHP - Flagception. Конечно, не всё коту масленица, есть и минусы. Во-первых, появляются условия - сценарии для включенной функции и для выключенной, это усложнение. Во-вторых, если необходимость управления фичей отпадает, появляется технический долг - условия и feature flags надо удалять, а до этого обычно руки не доходят. Короче, знайте меру. #process

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

Обновление справочника за 20 октября 2026 Справочник обновился. Во-первых, добавились подробные статьи «Выключатель» и «Слайдер» в виде большого совета на сайте бюро: https://bureau.ru/soviet/20261020/ Во-вторых, появились ещё несколько терминов. В частности, разблокирована буква Э! Для тех, кому не нравились «Заусенцы» и «Пипка», теперь есть «Упячка». В паре мест добавились иллюстрации. Всё новое и дополненное разом показывает, если вписать в поиск заклинание «r02». В-третьих, при переходе по внутренним зелёненьким ссылкам стало сильно лучше понятно, куда тебе указывают, а также после таких переходов заработала браузерная кнопка «Назад». А ещё у справочника появился логотип: https://ilyabirman.ru/reference/

Пилите продукт, а тут выпускают Claude X, который делает то же самое. Это приговор или ещё нет? Это главные мысли из разговора Далтона с Алексом Даниловичем (Magic Patterns, YC W23) — фаундером и CEO AI-инструмента для дизайна, который должен был быть «убит» Claude Design. Видео свежее, они до сих пор живы. • Magic Patterns были очень активными клиентами API Anthropic и не предполагали, что узнают о запуске такого продукта из новостей. Далтон в ответ на это просит не очеловечивать корпорации: они не люди с принципами и не ваши друзья. • Когда ты конкурируешь с продуктом от корпорации, ты должен понимать, что конкурируешь не с ней целиком, а с командой в 5–10 человек, которая этим занимается. И вам нужно быть лучше той команды настолько, чтобы топ-менеджер решил «списать» проект. И вот вы победили. И вся эта команда ещё и перейдёт к вам на работу (это шутка). • После релиза Claude Design у них начался wartime («режим военного времени») — они стали отслеживать любое упоминание Claude Design от их действующих клиентов или даже лидов. И пытались выяснить всё об их рабочих процессах: если кто-то юзал CD, фаундер MP сам выходил на созвоны с этими людьми, чтобы узнать, как улучшить свой продукт. • Чувакам помогло то, что они, по сути, прибыльны. И они даже радовались тому, что появился конкурент. Они и так хотели развиваться, но теперь стало нужно делать это ещё сильнее и лучше. Вопрос был больше в том, как зарядить себя и команду на это, а не думать о выживании. • Всё чаще клиенты переживают о привязке продукта к одной модели (или одному поставщику моделей). И это козырь, который есть у MP, но нет у Claude. Это и про сбои, и про желание попробовать другие модели, и про экономию, и про возможности. Продукт MP, например, может обрабатывать видео, а CD делает это лишь, разбирая его по кадрам. • Им помогает чёткое понимание, кто их клиент (а кто нет), и жёсткое следование правилу Пола Грэма «Найди 10 клиентов, которые тебя реально любят, нежели тысячу, которым ты просто нравишься». Они активно собирают обратную связь, работают в саппорте и так далее. • Главный совет по итогам этой ситуации: выбирай большой рынок — такой, чтобы хватило и сильным конкурентам. И пили крутой продукт — такой, чтобы ты был в нём уверен и даже сам предлагал людям потестить продукт конкурента (фаундер говорит, что они так делали, т.к. он был уверен в качестве MP). • И ещё одно отличие и преимущество стартапа от продуктовой команды типа той, что пилит Claude Design — у вас есть в команде фаундеры, а у них нет. Вы просыпаетесь заряженными и билдите этого «ребёнка», он ваш. А они просто на работу ходят. Из видео на канале Standard Capital (венчурный фонд Далтона и ещё 2 кофаундеров). @y_everyday — рефлексируем об акселератор, создавший 100+ стартапов-единорогов