Согласование, принятие решений и работа на лучший результат

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

За последний год я пообщался более чем с 200 клиентами, и их рассказы наглядно объясняют почему. Большинство нашли способы ускорить разработку, но на фоне всего этого «шума» от создания новых продуктов они не всегда могут понять, приводит ли возросший объем работы к реальным результатам. Недавний опрос 550 лидеров в сфере управления продуктами, проведенный Miro, показывает, где именно происходит застои: 74% респондентов отметили, что ИИ увеличил скорость их работы, однако более половины не видят пропорционального улучшения в принятии решений. Рост объемов работы не привел к принятию более качественных решений.

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

Продуктовая дисциплина в ускоренном темпе

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

Поскольку команды получили возможность создавать продукты быстрее, сама суть работы не меняется, но меняются три вещи:

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

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

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

Чтобы поддерживать непрерывность циклов и снизить уровень шума, мы выработали несколько привычек. Каждый участник команды разделяет ответственность за понимание того, «зачем» мы это делаем. Мы используем время, высвобожденное благодаря ИИ, для более глубокого размышления. Мы относимся к процессу с интересом. И мы ждем хороших идей отовсюду. Вот три конкретных проявления этих привычек в компании Miro (на уровне организации) и на платформе Miro (на самом холсте).

Запуск крупного проекта всей командой

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

Ритуал не изменился, но результат может быть другим. Пока ваша команда генерирует идеи, Sidekick создает полную структуру проекта на той же доске: продуктовую концепцию, пользовательские истории, диаграмму последовательностей, мобильный прототип и презентацию для стейкхолдеров. Коллеги добавляют общие знания для полноты контекста — например, дашборд, созданный в Claude, и текущие карты целей OKR, благодаря чему цели компании находятся прямо рядом с идеями. Затем участники дорабатывают черновики. Почему эта история имеет приоритет P0? Разве она не должна быть P1? Прототип и презентация намеренно созданы низкодетализированными. Они существуют для того, чтобы начать разговор.

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

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

Именно к такому сдвигу я стремлюсь благодаря ИИ: меньше рутины, больше мышления. По моему опыту, ключевой фактор успеха здесь глубоко человеческий — лучшие идеи рождаются тогда, когда людям весело. Именно поэтому мы встроили в Miro элементы радости, такие как персонализированные стикеры, чат с курсорами и забавные виджеты вроде колеса фортуны. Эти микромоменты не просто развлекают; они создают микромоменты вовлеченности, которые побуждают всю команду решать сложные задачи.

Превращение прототипа в решение

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

Такая реакция не имеет отношения к вкусу. Дизайнеры привносят контекст, который прототип не может в себя вместить: как работает система, с какими другими инициативами должно сочетаться каждое UX-решение и как сделать так, чтобы продукт не казался франкенштейном. Для продакт-менеджера прототип — это не окончательный ответ. Это способ донести и сформулировать направление, чтобы дизайн мог опереться на него и сделать решение еще лучше и точнее.

Это работает только в том случае, если обсуждение является генерацией идей, а не критикой дизайна. Перенесите прототип, созданный в окне чата или терминале, на доску Miro и позвольте команде разобрать его экран за экраном. Заметки на холсте не воспринимаются как критика. Они выглядят как люди, которые развивают идеи друг друга ради достижения общего результата.

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

Сохранение согласованности действий в процессе разработки агентами

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

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

Синхронизация продолжается от ранней стадии поиска до поставки, при этом руководители продукта по-прежнему задают направление, принимают решения и определяют темп.

Возвращение к ремеслу и сотрудничеству

Чтобы замкнуть круг вопросов, с которых я начал: какая же работа осталась для сегодняшних лидеров продукта?

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

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