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

Lenny Rachitsky поговорил с Cat Wu, которая руководит продуктами Claude Code и Cowork, а мы сделали сокращенный и адаптированный перевод их разговора. 

Оригинал публикации по ссылке.

***

Скорость становится конкурентным преимуществом

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

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

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

Но высокая скорость сама по себе не дает преимущества. Когда код становится дешевле, появляется другой, гораздо более сложный вопрос.

Самое сложное — понять, каким должен быть продукт через месяц

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

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

Отсюда возникает еще одна проблема — поиск правильной степени «веры в AGI» (“AGI-pilled”).

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

Гораздо сложнее построить хороший продукт для сегодняшней модели.

Как выжать из модели максимум возможностей? Как провести пользователя по «золотому пути» — направить его туда, где модель особенно сильна, и компенсировать ее слабые стороны?

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

Продуктовый вкус становится важнее любого бэкграунда

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

Какой должен быть UX для этой фичи? Какой опыт будет самым приятным для пользователя?

Команда Claude получает десятки тысяч пользовательских запросов. Нужно понять, какие из них действительно стоит реализовывать, в каком порядке и каким способом. Именно это в команде Anthropic называют продуктовым вкусом (product taste).

Развитый вкус не зависит от прошлого опыта — он может сформироваться у бывшего инженера, дизайнера или классического продакта. При этом инженерный бэкграунд пока действительно дает одно преимущество: лучшее понимание стоимости реализации. Если задача занимает час, возможно, ее проще сделать, чем обсуждать. Если же она очень дорогая, это становится важной частью продуктового решения.

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

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

Как научиться понимать модель

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

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

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

Третья — системно проверять качество работы моделей. Гораздо большему числу продактов и инженеров стоит научиться это делать. Не обязательно строить сотни тестов (evals): десяти качественных тестов часто достаточно, чтобы фиксировать целевое поведение модели, измерять прогресс и понимать, действительно ли продукт становится лучше.

Роли становятся менее важны, чем способность решать проблему

В команде Claude Code многие продакты раньше были инженерами или продолжают писать код. Дизайнеры тоже нередко имеют инженерный опыт. Немало инженеров в команде способны пройти весь путь самостоятельно — от того, чтобы заметить жалобу пользователя в X (ex-Twitter), до готовой фичи к концу недели — практически без участия продакта. Это эффективный способ шипить.

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

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


***

***

“Just do things” — главный принцип работы

Любимый принцип Кэт Ву — “just do things”. Должностные обязанности во многом условны. 

Роли — это в каком-то смысле выдумка. Если ты понимаешь ограничения, ты можешь разобраться, что можно сделать. А потом просто попробовать сделать это быстро, допускать ошибки — и исправлять их, если что-то пошло не так.

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

AI забирает рутинные задачи — и это хорошо

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

Но важно не останавливаться на первых 90–95% результата. Если автоматизация не работает на 100%, это не настоящая автоматизация. Последние пять-десять процентов требуют больше времени, но именно благодаря им на автоматизацию можно по-настоящему положиться — от решения, которое работает на 95%, не так много пользы.

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