Как подготовиться к презентации портфолио на уровне мировых продуктовых компаний (Facebook, Apple, Google)

Первая часть — про то, как выбрать проекты и уверенно рассказать про то, что хочет услышать нанимающая сторона. Вместо тестового задания [1] в ведущих продуктовых компаниях есть продуманный процесс собеседований, который начинается с живой презентации портфолио и рассказа об опыте работы. 9 из 10 кандидатов не проходят дальше первого этапа презентации. Этот этап сложнее, чем кажется на первый взгляд.

Этот текст ориентирован на дизайнеров с опытом больше трёх лет.

• Ограничение по времени: надо успеть рассказать про два-три проекта за 30 минут.Требования к рассказу: от продуктового дизайнера ожидается демонстрация макетов или прототипов, нужно доказать свой продуктовый подход (что дизайн повлиял на метрики и улучшил опыт пользователя — подтвердить цифрами), ярко выраженный личный вклад и примеры кросс-функционального взаимодействия.
• В западных компаниях редко знают даже про «Яндекс», поэтому нужно умело погрузить в контекст (одно-два предложения о сути компании и масштабе).
  
• С непривычки рассказать за 30 минут сложно даже тем, кто такое уже проходил, поэтому презентацию нужно тренировать каждый раз заново
  

• Даже если дизайнеру заранее прислать список вопросов (что нужно показать в презентации), дизайнер почему-то все равно хочет рассказать то, что он хочет. Либо нет ответов, либо считает что лучше знает, что нужно рассказывать, либо просто не читает инструкции.

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

• Не влезают в 30 минут. На реальном собеседовании после 30 минут интервьюер скажет: «окей, спасибо, я готов ответить на твои вопросы, у нас осталось 10 минут и у меня будет другая встреча». И действительно, через 10 минут человек отключится и запишет свое мнение о презентации.

Чтобы влезть в 30 минут, нужно нарезать свои кейсы как можно мельче — вплоть до юзерсторей[2], и сначала натренироваться рассказывать про них.

Выбрать только те проекты, где вы можете ОДНИМ предложением сформулировать проблему пользователя. Это важно! Одно предложение проще понять нанимающей стороне, и вам будет проще объяснить своё решение и мыслительный процесс.

Чтобы показать продуктовое мышление, нужно доказать что проблема не высосана из пальца и именно она была важна для пользователей или бизнеса. Обычно тут можно сказать о размере аудитории (количество людей), которые сталкивались с проблемой, дать портрет пользователя. Важно показать, что вы правильно выбираете над чем работать. К счастью, именно вы выбираете проекты про которые рассказывать на презентации.

Ваш рассказ про дизайн должен строиться на решении проблемы пользователя. В финале нужно показать, как вы проверили что она решена — например, привести результаты А/Б-теста, было/стало, или изменения в поведении пользователей (например, после внедрения новой фичи).

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

Вручную или в Ноушене оценить свои проекты — это гемор, поэтому я сделал простой инструмент и инструкции, где удобно самостоятельно оценивать свои проекты. Я его разработал для тех, кому помогал готовиться к собеседованиям для работы в США и Европе, но принцип универсален.

Работает просто:

• По каждому кейсу нужно честно ответить на закрытые (да-нет) вопросы[3].
• У каждого ответа есть условный вес, комбинации ответов работают по-разному. Алгоритм считает все ответы и рекомендует лучшие пять проектов, из которых надо выбрать два-три.
• По каждому проекту генерируется чек-лист, — что нужно сделать для презентации и на что надо быть готовым ответить.

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

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

Дисклеймер: Всё проверено на собственном опыте (прошел собеседования в гугл/фейсбук) и опыте ребят, которые уже там работают, и которые туда нанимают. И еще — никого не призываю переезжать (каждый решает самостоятельно). Единственная задача поста — поделиться лучшими практиками — они для собеседований в российские компании тоже отлично сработают.

[1] — На западе в развитых продуктовых компаниях мирового уровня редко кто попросит «сделать тестовое», потому что туда обычно набирают экспертов с подтвержденным опытом работы больше трёх-пяти лет. Считается, что опытных людей тестировать на знание азов дизайна — бессмысленно, нужно посмотреть на боевой опыт работы (поэтому презентация). Плюс, много формальных/юридических нюансов, и это занимает слишком много времени с кучей неоднозначных факторов. Навык решения задач проверяется на следующих этапах — упражнениями Whiteboarding и App Critique (ссылки ведут на видео).

[2] — User story. Формат записи задачи: «Я, как [username], хочу [что хочет], чтобы [решить проблему]». Отсюда понятно — кто целевой пользователь, как должен работать дизайн, как поймем про проблема решена. Фича может состоять из пачки юзерсторей, например авторизация в приложении может состоять из входа, восстановления пароля, регистрации, подтверждения почты и т.п., это всё отдельные юзерстори.

[3] Вопросы подобраны так, чтобы сфокусировать дизайнера только на важных для собеседования вопросах. Четыре группы: 1) продуктовое мышление, 2) скиллы (не считая навыка работы в проф. программах), 3) платформы — круто, если дизайнер запускал фичи на разных платформах, и 4) готовность кейса — есть ли что показать на презентации.

Условно — чем больше утвердительных ответов, тем лучше.

• - Проект запущен на пользователей (с твоим участием)?
• Есть ли результат исследования пользователей или анализ данных, на которые ты опираешься в дизайн-решениях?
• Ты тестировал разные гипотезы?
• Можешь сформулировать проблему пользователя/бизнеса в одном предложении?
• Твои дизайны улучшили релевантные продуктовые метрики?
• Были ли измеримые изменения в пользовательском опыте?
• Можешь ли четко сформулировать свой личный вклад в результат?
• Есть ли примеры работы с другими специалистами или подразделениями?
• Ты тестировал продукт перед поставкой на пользователей?
• Ты помогал с маркетингом проекта (лендинг, баннеры, стратегия).

• - Есть ли макеты в презентабельном качестве?
• Есть ли прототип, который можешь показать на презентации?
• Есть ли профессиональная причина гордиться работой? (Награды, радикальные изменения в метриках, качество исполнения и т.п.)

• Мобильные приложения
• Веб-приложение
• Десктоп
• VR/AR