Директор по продукту Figma Юки Ямашита в подробном интервью Ленни Рачитскому рассказал о внутренней кухне разработки одного из самых успешных B2B-инструментов современности. В центре дискуссии — эволюция подходов к целеполаганию, продуктовый сторителлинг, управление компактной командой и баланс между интуицией основателей и строгой аналитикой. Материал раскрывает конкретные управленческие механики, которые позволяют Figma сохранять высокую планку качества софта и выстраивать глубокую связь с пользовательским сообществом.
🛠 От Hotmail до Figma: Продуктовый путь Юки Ямашиты 5:20
Карьера Юки Ямашиты началась в корпорации Microsoft, где его первым продуктом стал почтовый сервис Hotmail. В то время индустрия еще формировала стандарты продуктового менеджмента, и Ямашита воспринимал свою роль как междисциплинарную позицию, позволяющую соприкоснуться со всеми аспектами создания софта. Позже, работая над интерфейсом Windows 8, он сфокусировался на сенсорном UI/UX, что предопределило его интерес к дизайну.
Перейдя в команду YouTube (Google) под руководство Шишира Мехротры, Ямашита возглавил разработку мобильного приложения для iOS. Этот опыт сопровождался курьезом: до своего первого рабочего дня менеджер никогда не держал в руках iPhone, из-за чего руководству пришлось отправить его в Apple Store за покупкой тестового устройства прямо в день оформления. После YouTube последовал важный этап в Uber, где Ямашита прошел путь от продуктового лидера до руководителя отдела дизайна подразделения микромобильности (электровелосипеды и самокаты).
Именно в Uber Ямашита впервые столкнулся с Figma как с рабочим инструментом. Внедрение платформы совпало с внутренней культурной трансформацией Uber, направленной на повышение прозрачности и инклюзивности процессов. Продуктового лидера поразило, как Figma размывает жесткие границы между дизайном и продуктовым менеджментом. В итоге Ямашита занял пост Chief Product Officer (CPO) в Figma, на котором находится уже почти четыре года.
По мнению Ямашиты, переход из продуктового менеджмента в дизайн полезен для развития эмпатии, однако управление дизайнерами принципиально отличается от руководства продакт-менеджерами.
Разница подходов заключается в следующем:
- Дизайнерам критически важен рост в контексте их ремесла (
craft). Продуктовые задачи компании (например, оптимизация воронки онбординга) не всегда совпадают с желанием дизайнера изучать сложные микроинтерракции. - Продакт-менеджеры (PM) ориентированы исключительно на бизнес-результат (
impact). Их легко мотивировать, перенаправляя на самые масштабные и сложные проблемы компании.
При этом Ямашита отмечает, что управлять продакт-менеджерами в некотором смысле проще, чем инженерами или дизайнерами, из-за их врожденной нацеленности на измеримый результат.
📖 Сила синтеза и «мимификация»: Основы продуктового сторителлинга 12:42
Одним из главных навыков успешного продуктового лидера Ямашита считает сторителлинг. Навык повествования напрямую влияет на оценки сотрудников в рамках performance review в его команде. Сторителлинг в продуктовой среде состоит из двух ключевых компонентов: навыка синтеза и умения создавать запоминающиеся концепты.
Под силой синтеза понимается способность менеджера прийти на хаотичную встречу топ-менеджмента, зафиксировать полярные мнения лидеров и превратить их в единый, очищенный от шума тезис, который продвинет проект вперед. Ямашита сравнивает эту работу с литературным анализом: на занятиях по литературе в Гарварде при разборе поэзии Уильяма Йейтса требовалось собрать разрозненные наблюдения и выстроить из них монолитный тезис. Хороший PM делает то же самое с массивом фидбека.
Второй важнейший аспект — «мимификация» инсайтов (mimification). Этот феномен Ямашита детально изучил в Uber. Продуктовый аналитик или PM выполняет свою работу на отлично только тогда, когда обнаруженный им инсайт упаковывается в такую емкую форму, что генеральные директора (как Трэвис Каланик или Дара Хосровшахи) начинают цитировать его как мем посреди стратегических совещаний.
Для преодоления «проклятия знания», когда менеджер перегружен контекстом и не может объяснить суть команде, CPO Figma рекомендует технику обнуления:
- Избавиться от внутренних допущений и мысленно перезагрузить контекст.
- Представить пользователя (или стейкхолдера) как человека, который вообще ничего не знает о проекте, но должен понять нюансы за 30 секунд.
- Использовать приземленные бытовые метафоры, как при обучении студентов базовым концептам программирования (например, указателям в Computer Science).
🎯 Владение контекстом «Зачем»: Как масштабировать продуктовые решения 18:58
В Figma зафиксировано жесткое разделение обязанностей: продакт-менеджер не обязан быть автором идей, а проектирование (what) и реализация (how) являются зоной разделенной ответственности всей команды. Однако PM несет единоличную и строгую ответственность за блок «Зачем» (why).
Ямашита противопоставляет две продуктовые культуры, с которыми столкнулся лично:
- Культура Microsoft: Спецификации (спеки) должны быть идеальными. Менеджер пишет гигантские таблицы, где до мелочей расписана логика работы каждой кнопки и сценарии обработки ошибок. В таких условиях у инженеров нет свободы выбора.
- Культура Google/YouTube: Масштаб продукта не позволяет описать все детально. Дизайнеры и разработчики ежедневно принимают сотни локальных продуктовых решений без участия PM.
По словам Ямашиты, единственный способ масштабировать качественный продукт без микроменеджмента — это гарантировать, что каждый член команды глубоко понимает глубинную причину («зачем») и проблему, которую они решают.
Для докопки до сути в инженерной культуре Figma применяется метод «Пяти почему» (Five Whys). Если в системе происходит сбой, команда последовательно разматывает цепочку причин до поиска корневой уязвимости. Ямашита требует от PM применять аналогичный подход к запросам клиентов: когда крупный заказчик просит добавить конкретную кнопку, менеджер обязан докопаться, почему у него возникает эта потребность и какая исходная конфигурация процесса создала эту проблему.
🐦 Феномен Figma: Проксимация к клиентам и канал «Проблемные твиты» 22:15
Связь Figma со своим сообществом закладывалась в период, когда никто не верил, что полноценный графический редактор может работать внутри браузера. Сооснователь компании Дилан Филд действовал по циклу: показывал прототип дизайнерам, собирал фидбек, мгновенно внедрял изменения и возвращался с обновленной версией, превращая первых пользователей в ярых евангелистов бренда. На ранних этапах Филд даже составил социальный граф самых влиятельных дизайнеров в Twitter, сфокусировался на их удержании и впоследствии открыл исходный код этого скрипта.
Эта одержимость обратной связью сохранилась до сих пор. Дилан Филд читает больше отзывов клиентов, чем кто-либо в компании, отслеживая даже публикации с нулевым охватом и отсутствием лайков. Ранее Филд скидывал скриншоты критических твитов в общие Slack-каналы, что приводило к панике: команды бросали текущие задачи ради исправления единичной проблемы.
Для локализации этого процесса Юки Ямашита и глава отдела дизайна создали закрытый Slack-канал под названием #concerning-tweets («Проблемные твиты»). Туда отправляются точечные жалобы из соцсетей, которые анализируются узкой группой лидеров на предмет системных багов без создания хаоса в инженерных командах.
При этом Ямашита подчеркивает необходимость балансировать фидбек от «громкого меньшинства» в Twitter с другими источниками данных:
- Тикеты службы поддержки (где концентрируется технический негатив и сбои).
- Sales-интервью с потенциальными клиентами (отражающие общее восприятие бренда на рынке Enterprise).
🧠 Интуиция против логики: Особенности работы с Диланом Филдом 28:11
Стили работы CPO Юки Ямашиты и CEO Дилана Филда кардинально различаются. По оценке Ямашиты, Филд управляет компанией, опираясь на чистую интуицию и инстинкты, сформированные годами личного общения с пользователями. Роль CPO в данном тандеме заключается в том, чтобы выстраивать логические деревья решений (logic trees) вокруг интуитивных находок генерального директора, объясняя и масштабируя их для остальной команды.
Дилан Филд относится к типу руководителей, которые не могут дать финальный апрув на основе концептуальных макетов или описания стратегии — ему необходимо увидеть и потрогать финальную интерактивную реализацию фичи.
Ямашита приводит пример бытовой одержимости CEO качеством: во время пандемии, проводя встречу «один на один» во время прогулки в парке Долорес, Филд зашел в дом к Ямашите, чтобы воспользоваться уборной. Там он увидел партнера Юки, работающего в Figma. CEO мгновенно забыл о цели визита, углубился в изучение открытого макета и провел длительное время, обсуждая с незнакомым пользователем проблемы отображения шрифтов Google Fonts. По мнению Ямашиты, этот фокус на болях конкретного человека, сохраняющийся спустя 10 лет существования бизнеса, и формирует продуктовую магию Figma.
📉 Уроки неудач: Почему функция Branching и Merging буксовала на старте 33:09
Вопреки внешнему восприятию Figma как компании, которая выпускает исключительно хиты, внутри команды регулярно случаются провальные эксперименты. Самым показательным примером крупной неудавшейся инвестиции стала функция ветвления и слияния макетов (branching and merging) для дизайн-систем.
Инструмент создавался по запросу крупных клиентов для контроля изменений в критически важных компонентах, используемых в тысячах смежных проектов. Однако после релиза фича показала крайне низкие метрики адаптации.
Анализ выявил комплекс причин:
- Технические проблемы с производительностью тяжелых файлов при слиянии веток.
- Слишком высокий порог входа: ментальная модель контроля версий (аналог Git) оказалась чуждой для линейных дизайнеров.
- Отсутствие внутреннего догфудинга: сама команда Figma из-за своих размеров на тот момент не сталкивалась с проблемами такого масштаба и не тестировала сценарий на себе.
Этот кейс заставил команду перестроить процессы. По мере масштабирования Figma создает функционал для типов организаций, на которые сама структура Figma не похожа. Это требует развития кастомных методов внешнего тестирования и отказа от слепой веры в то, что внутренний аудит закроет все пробелы качества.
💻 Культура личной ответственности и догфудинг: Смена меморандумов на презентации 35:20
Флагманский метод контроля качества софта в Figma — тотальный и непрерывный догфудинг. Продуктовые дизайнеры компании проводят внутри редактора в среднем по 6 часов в день. Чтобы погрузить в аналогичный контекст менеджеров по продукту, Ямашита принял непопулярное для Кремниевой долины решение: он развернул внутреннюю культуру от текстовых меморандумов (популярных в Amazon и Uber) в сторону визуальных презентаций. Единственным условием было то, что все слайды должны собираться исключительно внутри Figma. Это заставило PM проводить часы в интерфейсе собственного продукта и лично натыкаться на баги.
Аналогичный подход применили к FigJam: калибровка сотрудников в рамках performance review была переведена на специальный интерактивный шаблон в FigJam, разработанный совместно с HR-департаментом.
Ямашита иллюстрирует важность личной ответственности примером из Uber:
«Каждый сотрудник Uber ездил на работу на Uber. Если инженер, отвечающий за приложение для водителей, видел, как везущий его таксист мучается с интерфейсом или багом, ему становилось физически стыдно. Возникало чувство персональной подотчетности, и инженер шел чинить баг без всяких указаний сверху».
В Figma этот паттерн работает аналогично: дизайнеры компании лично знают лидеров индустрии на Twitter, поэтому выпуск сырого продукта для них означает персональный репутационный ущерб. Ямашита поощряет низовую инициативу разработчиков по исправлению багов в обход жесткого бэклога. По его наблюдениям, фича, которую инженер придумал и продвигает сам, разрабатывается им в два раза быстрее, чем задача, спущенная сверху продакт-менеджером.
🔄 Эволюция OKR: От полной отмены до системы «обязательств» 40:49
Юки Ямашита признается в многолетней «любви-ненависти» к системе OKR (Objectives and Key Results), считая ее проклятием для команд, развивающих основной пользовательский опыт (core experience). При классическом подходе команды попадают в одну из двух ловушек:
- Фиксация на вторичных, легко измеримых метриках (например, удовлетворенность по узкому опросу), которые никак не коррелируют с удержанием (
retention) или общими доходами бизнеса. - Выбор глобальных бизнес-целей (например, рост числа поездок в Uber), на которые продуктовая команда влияет через десятки опосредованных шагов, что делает невозможным чистую атрибуцию результата.
Видя, что сотрудники воспринимают OKR как формальный список дел и заполняют пустые таблицы ради отчетности, Ямашита полностью отменил эту систему в свой первый год работы в Figma. Вместо этого он ввел формат «Философских заголовков» (headlines), требуя от команд четко прописать, что именно они оптимизируют в этом квартале, не заботясь о точности метрик. Оценка выставлялась по принципу школьного табеля успеваемости на основе качественного ретроспективного анализа.
После прихода нового руководителя отдела аналитики (Head of Data из Uber) компания попыталась вернуть OKR, добавив строгости со стороны Data Science. Однако возникла проблема «пост-рационализации»: команды подгоняли метрики OKR под проекты, которые они в любом случае собирались делать.
В качестве текущего эксперимента Figma внедрила концепт «Обязательств» (commitments). Это жесткая связка между контекстом «Зачем» и конкретным проектом («Что»).
Независимо от названия методологии, Ямашита выделяет три столпа качественной цели:
- Понятность (
legibility): Любой человек со стороны должен с ходу понять, что значит метрика. - Применимость к действию (
actionability): Метрика должна вдохновлять команду менять повседневное рабочее поведение. - Аутентичность (
authenticity): Цель должна честно отражать то, чем команда фактически занимается каждый день, а не быть искусственной надстройкой.
👥 Как нанимать топ-PM: Методология команды из 22 человек 48:30
На момент интервью продуктовый департамент Figma состоял всего из 22 менеджеров по продукту — это беспрецедентно малая команда для платформы такого масштаба. При найме Ямашита использует специфические поведенческие фильтры.
Его любимый интерьерный вопрос звучит так: «Расскажите о случае, когда вы были частью крайне спорного, неоднозначного продуктового решения. Что конкретно вы сделали?». При ответе CPO оценивает способность кандидата одинаково беспристрастно и аргументированно представить позиции обеих конфликтующих сторон. Если соискатель скатывается в обвинения коллег или не понимает мотивов оппонентов, это является стоп-сигналом.
Второй фильтр — умение продать скучную проблему. Кандидату предлагается описать сложную техническую задачу из его прошлого. Если после рассказа Ямашита лично чувствует азарт и желание бросить все силы на решение этой рутинной проблемы, кандидат подтверждает навык сторителлинга.
Кроме того, в Figma ценятся:
- Высокоскоростные UX-сессии: Способность PM в ходе обсуждения ментально переключаться между абстрактной стратегией и микродеталями интерфейса, мгновенно просчитывая ветви пользовательских сценариев.
- Перемотка будущего (
fast-forwarding to the future): Концепция Джеффа Холдена из Uber. Менеджер должен уметь в воображении запустить эксперимент, спрогнозировать его негативные исходы и на основе этого умозрительного заключения вовремя отказаться от разработки ненужной фичи.
🤝 Комьюнити-ориентированный рост и партнерство с продажами 51:37
В контексте продуктоцентричного роста (Product-Led Growth, PLG) Figma часто ставят в один ряд со Slack, однако Ямашита предпочитает термин «рост, управляемый сообществом» (community-led growth).
Функция классического отдела продаж (Sales B2B) в Figma перевернута: менеджеры по продажам не пытаются навязать продукт топ-менеджменту компаний «холодными» звонками. Вместо этого они ищут внутри организации дизайнеров, которые уже тайно или локально любят Figma, и снабжают их аналитикой, данными и презентациями, делая из них «супергероев» способных защитить бюджет на покупку софта перед собственным руководством.
Для масштабирования этого эффекта компания развивает программу Friends of Figma — географически распределенную сеть локальных комьюнити, координируемых через Discord-серверы. Пользователи делятся файлами и процессами своих компаний, фактически открывая исходный код корпоративных дизайн-процессов для коллег по цеху.
Ямашита вспоминает, что базовая фича Figma — мультиплеер в реальном времени — изначально вызвала жесткое сопротивление профессионалов. Первой реакцией дизайнеров в Twitter на анонс совместной работы в одном файле была фраза: «Если дизайн станет таким, я ухожу из профессии и меняю карьеру». Наличие подобного сильного эмоционального напряжения и сопротивления Ямашита считает главным индикатором того, что продукт совершает подлинную революцию в устоявшихся рабочих привычках людей. Ленни Рачитский подтверждает этот тезис цитированием плаката из раннего офиса Airbnb: «Любовь движет ростом, а не наоборот».
🔮 Будущее с Adobe и философия Work in Progress 58:38
Обсуждая контуры потенциальной интеграции с корпорацией Adobe (сделка на момент записи подкаста не была закрыта), Юки Ямашита выделил два приоритетных технологических тренда:
- Бесшовный пайплайн: Устранение барьеров при переносе объектов между локальными приложениями Adobe (сложные микроинтерракции в After Effects, растровая графика в Photoshop, вектор в Illustrator) и совместным пространством Figma.
- Мультиплеер как платформа: Перенос браузерных технологий многопользовательской работы Figma на тяжелые креативные вертикали Adobe, такие как видеомонтаж и 3D-моделирование.
При этом CPO подчеркнул, что ключевая ценность Figma — радикальная близость к комьюнити — останется неприкосновенной, в том числе в рамках планируемого взаимодействия со Скоттом Белски.
Главным напутствием Ямашиты продуктовым командам стал призыв принять концепцию «мира в процессе разработки» (Work in Progress world). Он отмечает, что за красивым фасадом успешных корпораций всегда скрывается бесконечный процесс болезненного поиска решений, и никто в индустрии на самом деле не имеет идеальных, застывших во времени ответов на вопросы планирования и целеполагания. Менеджеры должны сохранять гибкость и постоянно перепридумывать инструменты, помня тезис основателей Airbnb: все вещи вокруг нас когда-то были спроектированы точно такими же людьми, и ни одна существующая система не является идеальной по умолчанию.
