{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Tech для продакта на примере вакансии Spotify

Все больше и больше компаний начинают упоминать в продуктовых вакансиях "experience with tech". При этом, я часто слышу от тех же продактов, что "тех - это не барское дело". Давайте возьмем одну интересную вакансию и разберемся.

Вакансия

Если бы у меня не было любимого продукта в Booking, то на такую вакансию я бы откликнулся сам. Во-первых, Spotify - это инновационный бизнес, меняющий нашу реальность: практически любой человек в наушниках, которого вы видите на улице или в кафе, слушает музыку именно там (ну или в аналогичном сервисе, суть та же).

Во-вторых, тот факт, что целая команда будет заниматься только playlist-ом, уже намекает - все будет "по-взрослому" - с кучей трафика, внутренних клиентов, ультра-оптимизацией customer experience и, как следствие, необходимостью строить платформу, а не просто одноразовую фичу.

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

Что ожидается от продакта

Как вы уже поняли, продукт - это платформа для поддержки сердца любого стримингового музыкального сервиса - Playlist-ов. Хороший (и достаточно технический) продакт в этот момент видит не просто "список песен" на экране айфона, но и алгоритм выбора их "правильного" порядка, простые и интуитивные возможности добавить/удалить песни, авто-генерацию плейлистов на основе истории прослушивания и рекомендаций, хранение этого всего (чтобы ни одна любимая песня не потерялась!). А кто же будет в команде? Следующий блок отвечает:

Этот список стейкхолдеров (дизайнеры, инженеры, дата сайентисты и т.д.), разъясняет, что требуется не просто "технарь", который будет следить за техническими показателями, а именно продакт, который будет совмещать знания технического мира с понимаем желаний кастомеров и главных метрик компании. Что еще раз подчеркивается следующим требованием:

Обратите внимание на "translate tech needs into simple understandable requirements": никому не нужны "умники", говорящие тех терминами - наоборот, чем проще продакты объясняет сложные вещи, тем выше ценится их скилл. Смотрим дальше:

Эта секция еще раз напоминает - тут "не шутят" и рассматривают "одну фичу" в качестве целой платформы. Достаточно технический продакт в этот момент уже представляет себе примерную архитектуру приложения:

  • Сверху - сервисы внутренних клиентов: главное приложение, сервис рекомендаций, сервис внешних интеграций (например, машины), сервис аудиокниг и т.д.
  • Внутреннее API платформы (/add_song, /remove_song, /shuffle, /repeat, /enqueue_after и т.д.
  • Главный "мозг", который заведует состоянием (state) прослушивания - говорит на какой песне слушатель сейчас и что произойдет дальше
  • Очень устойчивое и быстрое хранилище всех плейлистов (1-10 на человека) всех пользователей (365 миллионов monthly users в июле 2021)
  • Ну и конечно, возможность скейла этого всего не только для песен, но и для подкастов, лайфов и прочих стриминговых продуктов, которые Spotify еще будет делать

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

Кстати, как обычно бывает в похожих вакансиях, задание на рисование архитектуры и обсуждение "ньюансов" будет на собеседовании - так наниматели будут прощупывать, видите ли вы глубину и умеете ли декомпозировать задачу на куски. Хотите в этом практиковаться? Приходите на стартующий в ноябре спец-курс "Tech для продактов" нашего практического лицея ProductDo - я могу многим с вами поделиться.

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

Далее, вакансия опять намекает, что все это надо будет преобразовать в последовательную стратегию и уметь ее "защитить" перед коллегами (это мы, кстати, тоже практикуем на курсе):

Наконец, упоминаются более "классические" требования к продакту - умение проводить аналитику и разбираться в A/B тестировании:

Базовые знания а данных и A/B, я надеюсь, есть у большинства. Но data и experiment-driven компания Spotify на Sr.PM вакансии будет брать не всех подряд, так что за продвинутыми Senior-темами типа статистического теста для интерпретации результата, метрик A/B эксперимента, использования SQL и Python-а для быстрого анализа гипотез, практических факапов в реальной практики и многим другим - смотрите расписание наших курсов: нечасто, но мы учим и такому.

Заключение

В этом разборе я хотел показать, что иногда продукты - это не только про UI или склейку известных блоков (сайтик, чат-бот, доставка) в одну картину. Для продуктов инновационных компаний таких блоков попросту нет - так нова и сложна их область. Именно там, на границе бизнеса и теха, и возникают такие интересные продуктовые задачи как Spotify Playlist Platform.

Надеюсь, было полезно! Лонг-риды я пишу редко, а вот практические заметки постоянно появляются в нашей телеге "ProductDo: практика для продактов". До связи!

0
4 комментария
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Vladimir Kalmykov
Автор

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

Ответить
Развернуть ветку
Ari Fierro

Спасибо, очень крутые разборы вакансий делаете! слежу за всеми)

Ответить
Развернуть ветку
Vladimir Kalmykov
Автор

Спасибо! Буду продолжать)

Ответить
Развернуть ветку
1 комментарий
Раскрывать всегда