Как Figma создает продукт

Всем привет!

Автор статьи поделится интервью с Chief Product Officer в Figma – о полученных на собственном опыте уроках и свежих идеях о создании продукта.

Автор статьи – Lenny Rachitsky.

Figma – одна из самых инновационных, интересных и влиятельных продуктовых команд сегодня. Мы связались с Юкси Ямасита, директором по продуктам Figma, и он очень любезно согласился ответить на вопросы. Юхки возглавляет команды по продуктам и дизайну в Figma. До того, как присоединиться к команде Figma, он проработал в Uber более четырех лет, где руководил редизайном приложений для пользователей и водителей. До этого в Google отвечал за приложение YouTube на iOS.

Содержание:

1. В какой временной перспективе вы используете детализированное планирование, и как это менялось со временем?
2. Используете ли вы OKR (Objectives and Key Results/Цели и Ключевые результаты) в той или иной форме?
3. Как проходят встречи по обзору вашего продукта/дизайна?
4. Для встреч Design Crits - кто приходит на эти встречи, кто их модерирует и как часто вы встречаетесь?
5. Для обзора новых продуктов - тот же вопрос
6. Сколько у вас продакт-менеджеров?
7. Структурируете ли вы свои команды по продуктам, типам пользователей, пути пользователя, результатам или чему-то другому? Как это менялось с течением времени?
8. ‍Хотите тоже научиться создавать крутые продукты?

1. В какой временной перспективе вы используете детализированное планирование, и как это менялось со временем?

Каждый год топ-менеджмент устанавливает приоритеты компании на верхнем уровне, чтобы сформировать ключевые стратегические инвестиции. Затем команды по продуктам должны наметить путь к достижению этих целей.

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

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

Я сотрудничаю с Лоуренсом Луком (Technical Program Manager в Figma) в процессе планирования. Лоуренс создает этот процесс, и вместе мы занимаемся коммуникациями и реализацией.

У нас были веселые отношения с OKR.

Когда я впервые пришел в Figma, я фактически отменил OKR. У нас были ужасные корпоративные встречи по OKR, на которых мы просматривали электронные таблицы с сотнями OKR, которые на самом деле больше походили на задачи, назначенные отдельным участникам. Несмотря на то, что это было удобно для создания определенного уровня подотчетности, было непонятно, зачем на самом деле все это нужно.

Я попросил команды вместо этого определить основные тезисы - по сути заявления, которые они хотели бы сделать к концу определенного периода времени. Например, это может быть что-то вроде «Figma - самый эффективный способ создавать дизайн», и команда предлагает как количественные, так и качественные способы оценки этого утверждения.

Это помогло мне понять, к чему стремится команда с философской точки зрения, вызвало “правильные” дискуссии и позволило командам проявить немного больше креативности для измерения того, воплотила ли они в жизнь свои основные тезисы (например, сочетание различных качественных и количественных показателей). Благодаря этому мы осознали, что некоторые вещи, такие как основная ценность Figma, трудно измерить и они не могут быть сведены к одному показателю. Также это дало командам возможность изучать различные KPIs, а не искусственно повышать показатель, в который на самом деле никто не верил.

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

Наш процесс OKR фактически выполняется на FigJam. У нас есть команды, которые пишут «обязательства» (наши ребрендированные OKR) в этих виджетах, созданных Лоуренсом:

У нас есть сессии Design Crits (встречи для обсуждения дизайна) и обзоры продуктов.
Сессии Design Crits нацелены на продуктивность и не связаны с принятием решений. Дизайнеры делятся файлом (обычно на FigJam), и мы проводим 10 минут молча, оставляя стикеры и комментарии, чтобы обдумать обратную связь о дизайне, прежде чем обсуждать его вживую.

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

Интересно посмотреть на эволюцию формата. Когда я пришел в Figma, люди создавали документы, и это было больше похоже на служебные записки. Я поменял этот формат на презентации, главным образом потому, что хотел усилить культуру сторителлинга (а также для того, чтобы мои менеджеры могли больше использовать Figma!). И в последнее время мы все чаще используем FigJam, потому что это позволяет вести двусторонний разговор и легче оценивать реакции людей. Мой фаворит - виджет "Шкала согласования", который позволяет людям делиться мнением или голосовать за свое отношение к конкретным решениям. Я считаю это гораздо более эффективным, чем позволять самым громким людям в комнате диктовать результат!

Эти встречи являются центральной частью нашей культуры дизайна в Figma. У нас есть пять постоянных слотов каждую неделю, и их состав увеличивается с каждой сессией в течение недели (если в начале недели мы встречаемся только определенными командами, то в пятницу - уже всем отделом дизайна).

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

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

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

~10-15 минут презентации (мы используем Spotlight в FigJam, и участники могут оставлять комментарии во время презентации)
~5 минут ответов на вопросы
~5 минут тишины для комментирования идей

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

Здесь в обсуждении принимают участие все руководители продуктов (включая Дилана Филда, нашего CEO), руководители проектов, а также ключевые лица, принимающие решения. Такие обсуждения происходят не так часто, но, как правило, на критически важных этапах жизненного цикла продукта, и обычно лидируются продакт-менеджером, продукт или работа которого будет обсуждаться.

Двадцать два, и мы сейчас в поиске новых!

Это также забавная дискуссия!
Сейчас мы организуемся вокруг продуктов и платформ. У нас есть два продукта – Figma Design и FigJam – и две команды, ориентированные исключительно на соответствующий продукт. Затем у нас есть «горизонтальные» команды, которые создают функции и решают проблемы для обоих продуктов, например, группа «Enterprise/ предприятие», которая фокусируется на том, чтобы сделать оба этих продукта удобными для крупных компаний, и группа «Infrastructure/ инфраструктура», которая обеспечивает надежность и производительность обоих продуктов.

Это немного изменилось с течением времени, особенно с того момента, когда мы были монопродуктовой компанией. В то время команды были больше организованы вокруг вариантов использования продукта.

Построение структуры команд - это искусство, а не наука, и мы ожидаем, что будем постоянно пересматривать его по мере нашего роста.

Тогда регистрируйтесь на наш комплексный онлайн-курс "Продакт-менеджмент"!