Большинство российских коллег и компаний до сих пор планируют роудмепы и фичи на 6-12 месяцев вперёд. В Anthropic за это время успевают выпустить продукт, переделать его, выбросить половину и выпустить снова. Релизы продуктов и критических фичей выходят — е-ж-е-д-н-е-в-н-о. Кэт Ву, глава продукта Claude Code, проводит сотни собеседований и говорит, что почти все кандидаты имеют устаревший подход и мышление. Не потому что они плохие специалисты, а потому, что просто рефлексируют опыт в профессии, которой больше нет.
Кэт Ву (Cat Woo) — глава продукта Claude Code и Cowork в Anthropic. Много лет работала инженером в Scale AI, потом недолго в венчуре, и теперь в Anthropic. Здесь она работает в паре с Борисом Черни, техлидом и создателем Claude Code. Борис создает видение, Кэт строит дорогу к нему и убирает всё, что мешает команде выпускать фичи за один день.
PM-роль перестала существовать в прежнем виде
Кэт Ву проводит сотни собеседований с кандидатами на роль PM и видит один и тот же устойчивый паттерн. Люди приходят с ментальностью прошлого десятилетия, где горизонт планирования 6-12 месяцев, а главная компетенция — координация многоквартальных роадмапов с кросс-командами, где скорость ограничена скоростью работы команды и стоимостью написания кода. Этот мир исчез.
В Anthropic сроки для продуктовых фич сократились с 6 месяцев до 1, а иногда до 1 недели или 1 дня. В календаре запусков Anthropic события стоят буквально каждый день. При этом сейчас в Anthropic работает около 30–40 PM, разделённых между несколькими командами: исследовательские PM под руководством Дайан, команда платформы разработчиков, команда Claude Code и Cowork, корпоративная команда и команда роста.
Сама Кэт выросла из инженерной роли. Практически все PM в её команде либо были инженерами, либо уже сами активно пишут код. Дизайнеры тоже — все бывшие фронтенд-инженеры.
Что дает супер-скорость
Скорость Anthropic не объясняется доступом к лучшим моделям, хотя это тоже правда.
«Мы двигались довольно быстро уже несколько кварталов. Так что Mythos — не главная причина. Основная причина — это процесс и ожидания, которые мы задаём команде.»
Предельно конкретные цели:
LLM настолько общие, что создают колоссальную неопределённость для команды. Пример из практики Claude Code: «Профессиональные разработчики в enterprise-компаниях должны безопасно свести количество запросов разрешений к нулю» — эта формулировка сразу отсекает большинство неправильных подходов к решению задачи и не оставляет места для бесконечных дискуссий о том, что вообще строить.
Исследовательское превью как стандарт запуска:
Когда фича помечена как «ранний продукт, на который мы собираем обратную связь», команда берёт на себя значительно меньше обязательств. Это позволяет выпустить что-то за неделю-две, получить реальный фидбек и итерировать, вместо того чтобы полгода полировать продукт внутри.
Заранее выстроенный конвейер запуска:
У Claude Code есть «вечнозелёная комната запусков» в Slack. Инженер, считающий фичу готовой и прошедшей внутреннее тестирование, просто постит её туда. Сара, ведущая документацию, Алекс из PMM и команда DevRel подхватывают — и маркетинговый анонс готов уже на следующий день. Никакой отдельной координации, никаких встреч для согласования. PM — это роль, которая должна выстраивать этот процесс.
PRD, принципы и метрики вместо роадмэпов
Работа с документацией в Anthropic заметно отличается от стандартных практик. У ребят нет привычных многостраничных PRD.
Обязательно — еженедельные разборы метрик со всей командой. Цель не в отчётности, а в том, чтобы каждый человек в команде глубоко понимал все части бизнеса, ключевые цели и что на них влияет. Когда все разделяют одну версию реальности, решения можно принимать локально, без PM как единственной точки согласования.
Еще есть список командных принципов (кто ключевые пользователи, почему именно они, на что команда готова идти ради них, от чего готова отказаться). Это позволяет людям принимать решения самостоятельно, не чувствуя, что их действия завязаны на PM или другом стейкхолдере.
PRD всё ещё пишутся, но только для двух категорий задач (неоднозначные фичи, где полезно зафиксировать цели, удачные сценарии использования и текущие провалы на одной странице, и проекты с тяжёлой инфраструктурой, которые объективно занимают много месяцев). Для остального — принципы, метрики и тесная синхронизация.
Культура работы с ошибками
Незадолго до интервью произошло событие, которое многие восприняли как скандал. Исходный код Claude Code оказался публично доступен. Причина оказалась в том, что сотрудник работал с Claude, чтобы написать PR — обновлении процесса выпуска пакетов. PR прошёл через два уровня человеческого ревью, но что-то пошло не так — человеческая ошибка, которую не поймали. Никто не был уволен, все сотрудники продолжают работать в Anthropic. Все провалы рассматриваются как системные проблемы, которые нужно решать инфраструктурно, а не как поводы для наказания конкретных людей.
«Это провал процесса, и самое важное — просто учиться из этого и добавлять больше мер защиты.»
Слияние ролей и что на самом деле ценно
Из всех утюгов мы слышим — ИИ заменит PM, инженеры сами всё построят. Кэт говорит о том, что роли не исчезают, а сливаются. В Anthropic сделали ставку на инженеров с отличным продуктовым вкусом, а не на увеличение числа PM. Многие инженеры в команде Claude Code способны самостоятельно пройти весь путь от фидбека пользователя в Твиттере до выпуска продукта к концу недели без какого-либо участия PM.
Но это не означает, что PM не нужны. Это означает, что ценными становятся люди, способные носить много шляп одновременно, менять их и при этом сохранять низкое эго относительно того, какую конкретно работу они делают ради движения команды вперёд.
Центральный навык, который объединяет все роли, Кэт называет продуктовым вкусом. По мере того как код становится намного дешевле писать, самым ценным становится решение — что писать. Команда Claude Code получает десятки тысяч запросов с просьбами о фичах. Из них нужно выбрать правильные и найти правильный способ их реализовать. Это требует вкуса, который не появляется автоматически ни из одного бэкграунда в разработке — хотя технический опыт даёт одно конкретное преимущество: понимание того, насколько что-то должно быть сложным. Это напрямую влияет на приоритизацию, если задача решается за час, её стоит просто сделать, не обсуждая.
Нужная степень AGI-оптимизма как редкий навык
Одна из самых неожиданных идей в интервью касается того, как правильно калибровать своё видение относительно возможностей текущих моделей.
Легко строить продукт для гипотетической супер-умной модели будущего — там достаточно текстового поля, потому что модель сама разберётся, добавит нужные инструменты, задаст уточняющие вопросы. Сложная работа — выяснить, как максимально раскрыть возможности текущей модели, компенсировать в интерфейсе её слабые места, направить пользователей на «золотой cjm» взаимодействия.
Как развивать этот навык? Кэт называет три способа. Первый — много времени разговаривать с моделью и использовать её. Когда модель делает что-то неожиданное, полезно напрямую попросить её отрефлексировать своё поведение. Пример из практики: иногда Claude вносит изменения во фронтенд, запускает тесты, но не проверяет результат через UI. Вопрос «почему ты это сделал?» даёт конкретный ответ — либо что-то было запутанным в системном промпте, либо верификацию делегировали саб-агенту, который не проверил работу. Это показывает, что именно нужно исправить в харнесе.
Второй способ — найти 2-5 человек, которым вы доверяете как источнику точной обратной связи о модели. Кэт использует коллегу Аманду, которая формирует характер Claude (задача, которая сложнее, чем проверка корректности кода, потому что здесь нет объективного эталона правильности) и вся команду Claude Code в целом — на обедах, когда появляется новая модель, Кэт просто обходит всех и спрашивает «каков вайб модели?» За пятнадцать минут собираются паттерны, которые потом верифицируются данными.
Третий способ — evals. Вам не нужно строить сотни эвалов, чтобы они были полезными. Десять хорошо составленных эвалов важны для того, чтобы команда могла измерить, в чём цель и какой прогресс к ней.
Кейс: как Co-work меняет работу PM на практике
Реальный кейс из жизни Кэт — подготовка доклада для конференции Code with Claude. Тема: переход Claude Code от ассистента к полноценному агенту. Нужно было показать все продукты, выпущенные за этот период, и найти лучшие внутренние демо.
Входные данные: Google Drive подключён, Slack подключён, черновик от Алекса из PMM загружен, список ссылок на релевантные материалы добавлен. Промпт был конкретным: «Сделай мне слайд-дек для конференции. Вот что предложил наш PMM. Вот мой черновик, который мне не нравится. Начни с предложенного аутлайна. Убедись, что не пересекаешься с keynote-докладом на конференции, который важнее.»
Co-work работал около часа. Прошёлся по Твиттеру — посмотрел, что команда запускала публично. Просмотрел вечнозелёную ветку запусков в Slack. Просмотрел канал объявлений Claude Code, где команда постит демо того, как сама использует инструмент. Синтезировал всё это в 20-страничный слайд-дек.
Кэт получила его утром. Главная правка была одна — Claude сделал слайды слишком многословными, а она предпочитает минимум текста. Визуально дек выглядел так, будто его делал дизайнер Anthropic, потому что Co-work имел доступ к стандартному шаблону с цветами, шрифтами и примерами форматов слайдов. Кастомный шаблон можно загрузить напрямую или подключить через Figma MCP.
Кейс Applied AI team (вторая по объёму генерации токенов команда после инженерии) ещё показательнее. Сотрудники, ведущие по 5-10 клиентских встреч в день, накануне вечером просят Co-work собрать дайджест: все встречи на завтра, что этот клиент просил раньше, что было top-of-mind, каковы незакрытые вопросы из прошлых звонков. Если клиент спрашивал о сроках фичи, Co-work ищет актуальный статус в Slack и добавляет в бриф. Человек заходит на звонок с полной картиной без ручной подготовки.
Характер Claude — это конкурентное преимущество
Реакция пользователей на ограничение OpenClaude неожиданно обнажила кое-что важное. Люди расстраивались не просто из-за ограничений. Им нравилась конкретная личность ассистента, с которой они вместе работали каждый день.
«Когда вы вспоминаете всех, с кем работали, есть просто люди, чья энергия вам нравится. Когда люди думают о Claude и Claude Code, это одна из вещей, которую они упоминают чаще всего.»
Три качества, которые команда намеренно культивирует:
— низкое эго — если вы говорите Claude, что он что-то сделал неправильно, он искренне благодарит за указание и предлагает исправить. Никакой защитной реакции, никаких объяснений, почему он был прав.
— позитивность при сложных задачах — когда задача кажется неподъёмной, Claude предлагает конкретные следующие шаги и спрашивает, начать ли за вас.
— честная обратная связь вместо согласия — модель не соглашается со всем, что говорит пользователь.
Аманда, сотрудник который формирует характер Claude, работает в условиях, где нет объективного эталона правильности — в отличие от написания кода, где можно запустить тесты. Нужно иметь сильное собственное чувство того, кем должен быть Claude, уметь это артикулировать и доводить до результата через итерации.
Что жертвуется и как с этим жить
Скорость имеет цену.
Главная жертва — согласованность продукта. Когда код был дорогим, команды тщательно планировали всю архитектуру продуктового набора заранее — как каждый продукт соотносится с другим, один продукт на каждый сценарий использования. Сейчас иногда выходят фичи, перекрывающие друг друга. Команда хочет проверить два разных подхода и дать пользователям решить, какой лучше. Но пользователей это вгоняет в ступор и тревогу.
Вторая жертва — ощущение пользователя, что он не успевает. Традиционный продукт выпускал фичи раз в месяц-квартал. Можно было проверить обновления раз в месяц и ничего не пропустить. Сейчас люди чувствуют необходимость проверять Твиттер каждый день. Именно поэтому появился /powerup — раньше команда принципиально не хотела делать туториал, считая, что хороший продукт должен быть интуитивно понятен без инструкции. Слишком много пользователей хотело знать, какие десять фич из ста абсолютно необходимо освоить.
/powerup — встроенная команда в Claude Code, которая запускает интерактивный онбординг прямо внутри инструмента. Показывает десять ключевых фич из ста доступных — те, без которых вы теряете большую часть возможностей.
Личная стратегия Кэт для сохранения работоспособности в таких условиях — принять, что есть только столько, сколько ты можешь сделать, хорошо спать, жёстко приоритизировать и быть готовой отпускать.
«Есть продукты, которые мы выпускаем не такими отполированными, как мне хотелось бы. Но если продукт не блокирует основной сценарий использования, мы услышим фидбек и исправим в следующем релизе.»
Главный совет для тех, кто хочет остаться в роли продакта
Что надо сделать уже вчера. Найти повторяющиеся ручные задачи и автоматизировать их. У большинства людей есть творческие части работы, которые они любят, и рутинные, которые ненавидят. ИИ способен взять вторые на себя. Освободившееся время — это возможность заняться тем, до чего никогда не доходили руки.
Второй совет менее очевиден. Доводите автоматизацию до конца — или не начинайте вовсе. Если процесс ошибается хотя бы иногда, вы всё равно будете проверять каждый результат вручную и тогда время вы не сэкономили, а просто добавили себе лишний шаг. Последние 5-10% требуют значительно больше усилий, чем первые 90%. Но только когда автоматизация работает без ошибок, вы можете про неё забыть и заняться чем-то другим.
И третий совет. Делайте приложения, которыми пользуетесь каждый день, а не прототипы, которые впечатляют один раз. Только через ежедневное использование ИИ превращается из демонстрационного материала в настоящий рутинный инструмент.
ссылка на оригинал статьи https://habr.com/ru/articles/1037394/