# Эмпатия, Double Diamond и Job Crafting: эксперты Стэнфорда о главных навыках Product Manager

Источник: https://www.youtube.com/watch?v=rfx5G-zm9Wk
Канал: Stanford Online
Опубликовано: 21.05.2024

---

В рамках вебинара Stanford Online эксперты и преподаватели Стэнфордского университета обсудили эволюцию роли менеджера продукта (Product Manager, PM) в современной технологической среде. Ведущий Майкл Лепеч, профессор Школы инженерии и Школы устойчивого развития Стэнфордского университета, вместе с коучами программы обучения PM — Куналом Гаргом (CTO стартапа Bracket) и Арьей Тейлор (Product Manager) — разобрали набор компетенций, необходимых для успешного запуска продуктов и карьерного роста.

## 🧠 Топ-3 ключевых навыка менеджера продукта по версии экспертов
[[JUMP:07:00]]

Арья Тейлор, опираясь на четырехлетний опыт работы в управлении продуктами, выделяет три фундаментальные компетенции, которые она считает критически важными для ежедневной деятельности [07:13]:

*   **Эмпатия к пользователю.** По мнению Тейлор, это не просто сочувствие, а способность глубоко анализировать «болевые точки» клиентов, отсеивать лишнее и переводить жалобы в конкретные, исполнимые задачи [07:41]. При этом эмпатия должна распространяться и на коллег: инженеров, дизайнеров и руководство.
*   **Коммуникация и перевод.** Роль PM требует взаимодействия с людьми разного технического уровня и из разных стран [09:01]. Тейлор утверждает, что PM выступает в роли «переводчика» между маркетингом и разработкой [10:35]. Она приводит пример из личной практики: отсутствие одного слова «все» в письме к генеральному директору привело к тому, что сообщение было истолковано неверно, создав ложное ощущение масштабного кризиса [09:27].
*   **Глубокое мышление (Deep Thinking).** Пока инженеры строят, а дизайнеры рисуют, PM обязан синтезировать потоки данных, результаты исследований и стратегические ограничения компании (такие как бюджет или форс-мажоры вроде пандемии) в единое видение и дорожную карту [11:15].

Кунал Гарг, сооснователь YC-стартапа Bracket, дополняет этот список компетенциями, специфичными для ранних стадий бизнеса [12:35]:

*   **Мультизадачность («ношение многих шляп»).** В стартапе PM часто заменяет собой отделы маркетинга, дизайна и анализа данных, заполняя пробелы в команде [13:02].
*   **Организованность.** Гарг полагает, что наличие жестких систем и регламентов с «нулевого дня» позволяет разблокировать работу инженеров и защитить их время от хаоса [13:58].
*   **Решительность при открытом мышлении.** По словам Гарга, PM должен уметь быстро принимать решения о запуске MVP (минимально жизнеспособного продукта), но при этом быть готовым признать свою неправоту, если гипотеза не подтвердилась [15:11].

## 🧪 Научный метод и «Double Diamond» в разработке
[[JUMP:29:27]]

Майкл Лепеч подчеркивает, что в Стэнфордском университете обучение будущих менеджеров продукта строится на научном подходе. Он считает, что работа PM — это постоянное тестирование гипотез: если результат подтвердился — это успех, если нет — это ценное знание, которое предотвращает бессмысленные траты ресурсов [30:07].

Для структурирования этого процесса эксперты рекомендуют использовать фреймворк **Double Diamond** («Двойной алмаз») [30:34]:

1.  **Пространство проблемы.** Первый этап — расширение понимания всех возможных проблем в домене и последующее сужение до одной, самой критичной. Кунал Гарг утверждает, что самой большой ошибкой PM является преждевременный прыжок к решению [30:47].
2.  **Пространство решения.** Только после фиксации проблемы команда начинает генерировать варианты реализации и выбирать оптимальный [31:01].

В качестве примера важности этапа исследования Кунал Гарг привел историю своего стартапа Bracket. Изначально команда строила финтех-продукт для блогеров в TikTok (creator economy) [19:54]. Несмотря на «блестящую» идею, команда быстро осознала, что не понимает клиента и не решает реальную проблему. Благодаря готовности «убить» проект (pivot), они вовремя переключились на сферу обработки данных, где нашли реальный рыночный спрос [20:38].

## 🔄 Переход в PM из других сфер: стратегия «Job Crafting»
[[JUMP:34:41]]

Для тех, кто хочет сменить профессию и стать менеджером продукта, участники вебинара предлагают концепцию **«Job Crafting»** (перепроектирование работы) [36:38].

Арья Тейлор поделилась своим опытом перехода из Data Science. Она начала брать на себя задачи PM неофициально: общалась с пользователями, выстраивала отношения со стейкхолдерами и проектировала видение моделей [24:36]. Когда её руководитель заметил эти наклонности, Арье разрешили вести один проект полностью в роли PM в качестве эксперимента. По её мнению, это лучший способ понять, подходит ли вам эта роль, не меняя компанию [25:17].

Кунал Гарг, будучи бэкенд-инженером в Wealthfront, применял похожую тактику: он просил разрешения присутствовать на интервью с пользователями, которые проводили PM соседних команд [38:28]. Это позволило ему развить «продуктовый взгляд» на код.

Советы для резюме начинающего PM [41:21]:

*   Указывать опыт руководства любыми проектами, даже если в названии должности не было слова «Product».
*   Описывать собственные сайд-проекты (например, создание приложения для разделения счетов в ресторане или запуск e-commerce сайта) [37:50].
*   Использовать волонтерство в некоммерческих организациях для отработки продуктовых навыков [43:29].

## 🏗 Различия: Продукт, Проект и Программа
[[JUMP:44:13]]

Майкл Лепеч вносит ясность в часто путаемые термины. По его определению [48:01]:

*   **Project Manager (Менеджер проекта).** Работает в условиях, когда список задач и их последовательность известны. Пример — строительство здания: нужно залить фундамент, затем возвести стены, затем крышу. Главная задача — управление ресурсами и сроками [48:26].
*   **Program Manager (Менеджер программы).** Координирует группу взаимосвязанных проектов для достижения общих стратегических целей и обмена лучшими практиками [48:52].
*   **Product Manager (Менеджер продукта).** Действует в условиях высокой неопределенности, сравнимой с венчурным бизнесом. PM строит «здание», дизайн которого постоянно меняется в процессе. Это часто требует шагов назад и полной переделки [49:08].

## ⏱ Борьба с выгоранием и «UI Jam»
[[JUMP:50:01]]

В условиях управления командами до 32 человек (как в текущем кейсе Арьи Тейлор [21:34]) риск выгорания крайне высок. Тейлор призывает к «безжалостной приоритизации» (ruthless prioritization) не только задач продукта, но и собственного времени. Она рекомендует использовать **Матрицу Эйзенхауэра** для разделения дел на срочные и важные [54:36].

Кунал Гарг предлагает практический метод поддержания морального духа команды — **UI Jam**. Каждый понедельник утром команда выделяет один час на исправление мелких багов или небольшие улучшения интерфейса, которые обычно откладываются ради крупных задач [52:47]. Это дает команде «быстрый дофамин» от выполненных дел и повышает качество продукта, не отнимая много времени у основной разработки [54:09].

---