Технические навыки для продактов на примерах

Свою продуктовую карьеру в Booking.com я начал программистом и в течение первого года понял, что больше всего мне нравится находиться на границе мира технологий и создания продуктов - так я стал одним из первых «неофициальных» Tech PM в компании (об этой специализации - ниже).

За последние 6 лет я имел удовольствие строить продукты в отделах Core Infrastructure, Business Services, Payments и приставка “Tech” всегда позволяла мне выбирать проекты по запуску чего-то "нового". Сегодня я веду свой департамент как Group Product Manager, и опыт нахождения в технических и бизнес мирах позволил мне сформулировать для себя, зачем и какие тех знания нужны продакту. Чем я с вами и поделюсь.

Очевидная мысль: за последние 5-10 лет все стало онлайн. Вы бронируете самолет и отель в инете, там же покупаете билеты на концерт, заказываете еду, изучаете Python или гитару, иногда даже занимаетесь спортом и обновляете полис на Госуслугах (с трудом). Даже местный кофейный чувак в парке предлагает вам QR-код для сканирования и получения баллов лояльности, а где-то стаи дронов CAFU сажают деревья в пустыне(!).

Перечисленные продукты не висят в вакууме - они основаны на экосистемах реальных IT-сервисов и у них есть команда с продактом, ведущим их в правильном (или неправильном) направлении. В тот момент, когда в почти все в продукте становится блоками IT-логики, их лидер естественным образом вовлекается в область тех-мира: программисты что-то обсуждают про сервисы и API, партнеры предлагают с ними интегрироваться, CEO спрашивает, готовы ли мы к авариям, а на дашборде нет почти ни одной высокоуровневой метрики (типа продаж), зато есть Service Level Indicators (SLIs).

Конечно, совершенно не обязательно отодвигать программистов локтем и лезть в код (помните, продакт отвечает за What/Why, а не How!), но понимать язык сервисов было бы желательно. Хотите попрактиковаться? Тогда не подсматривая на картинки ниже, подумайте пару минут и может нарисуйте на бумаге: из каких больших кусков логики состоит сервис доставки пиццы?

Если у вас в голове родилось что-то похожее на первую картинку, то ваше понимание IT-мира и скрытых возможностей (и опасностей) не очень раскачано.

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

Еще одно относительно новое явление: чтобы запустить продукт, командам редко нужно изобретать все с нуля. По моему опыту, если потратить хотя бы 10 минут в поисковике, то можно найти статью почти обо всем, что вы собираетесь построить. А иногда - и готовое решение, которое предлагают купить и подключить.

Например, представим, что вы планируете обрабатывать изображения для своего локального маркетплейса: продавцы будут загружать фотки (скажем, велосипедов), чуть редактировать, и ваш сервис будет их сохранять, выполнять простое распознавание объектов, а затем отображать покупателям в нужном размером, формате и водяным знаком. Прежде чем бросаться с командой всю эту красоту создавать, при быстром ресерче вы можете найти: 1) API для основных операций с изображениями от Cloudinary 2) почти научные статьи Facebook о методах хранения изображений и даже 3) книгу об обработке изображений High Performance Images. Выбирайте.

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

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

Классический пример - поиск Google. Из “понятных” фичей там только белый экран с кнопочкой поиска, а под капотом… распознавание речи, значения запроса, поисковые алгоритмы, ранжирование и еще в это все интегрированная реклама. А на уровень ниже - собственные базы данных, дата пайплайны, даже собственные дата центры! Вместе это сотни продуктов и… Tech продакт менеджеров.

Конечно, Google все не заканчивается: обмен сообщениями Facebook, обработка изображений в Instagram, поиска проживания в Booking.com, матчинг водителя и пассажира в Uber, платежные API от Stripe, потоковая передача и рекомендации музыки Spotify и практически все веб-сервисы AWS - все это примеры областей на границе продукта и технологий и их ведут те или иные Tech PM-ы.

Кстати, не удивляйтесь, если названия продакт-вакансий в перечисленные компании не всегда имеет префикс «Technical» и загляните в фактическое описание должности. Например, для Amazon PM: «Предыдущий опыт управления техническими продуктами или онлайн-услугами» или Spotify PM: «и технический опыт работы в качестве инженера или другой тех. должности».

Да, такие компании задают очень высокую планку микса продуктовых и технических знаний, но и не все хотят создавать что-то уж совсем инновационное. Но, поскольку всё нынче онлайн-сервис, минимальный набор постепенно становится нужен и в менее топовых конторах.

В итоге, для себя я сформулировал, что для успешного продакт менеджера (или предпринимателя) в любом современном IT-проекте (включая стартапы) есть три уровня скилла:

• База управления продуктом (50%), куда входит умение понимать желания клиентов, преобразовывать их в понятные задачи, строить экономику, задавать метрики, планировать кратко/средне/долгосрочные горизонты, достигать их - короче, общеизвестный фундамент.
  Например, ПМ Вася приоритизирует уведомление о покупке пылесоса в виде отправки SMS-ки, потому что этим “мессенджером” пользуются 40% клиентов (к Васе мы еще вернемся ниже).
• Технические знания о продукте (30%): нужны чтобы легко объединить внешние и внутренние системы вместе, не забыть про нефункциональные требования (архитектура, безопасность, инфраструктура, устойчивость) и, в итоге, превратить идею продукта в реальный работающий сервис, а не трактор.
  Продолжая пример с SMS-ками, ПМ Вася с техническими знаниями может обосновать необходимость гибкой архитектуры сервисов, что, в свою очередь, позволит компании быстро запустить другие мессенджеры для новых рынков (Viber, WhatsApp или Telegram) или даже основать сторонний бизнес мета-мессенджера (сейчас много таких).
  Обратите внимание на разницу: PM не только определяет приоритеты, но теперь, вдобавок, имеет представление о том, как (примерно) это изменение было сделано, и эти знания (в сочетании с видением продукта) порождают в его/ее голове новые бизнес-идеи. Техническим скиллам из этой секции я учу на ламповом живом спец-курсе "Tech для продакта" в школе ProductDo. Мы - не потоковая школа, и если интересно, то советую не тянуть с записью - стартуем уже 9 сентября.
  
• Знание предметной области (20%): добавляется сверху как соус специализированных умений, например, в платежах, трэвеле, маркетплейсах, обработке контента и т.д. Он позволяет продакту чувствовать глубокие вопросы домена, и компании любят таких специалистов: например, любая пейментс контора будет очень рада вашему опыту в FinTech (но без него тоже не откажет). Это не обязательные скиллы, потому что с хорошей базой всегда можно прокачать и детали, а они все равно меняются от проекта к проекту.
  Для нашего примера с SMS-ками, опытный платежник Вася знает, что SMS будут использоваться для двухфакторной аутентификации, и настоит на высокой устойчивости систем отправки сообщений, чтобы не навредить конверсии оплаты.

По моему опыту, продакты, которые развивали в себе все три навыка были наиболее успешными спецами, как в смысле запуска проектов, так и карьерного роста.

Надеюсь, было полезно. Продолжу писать заметки из опыта тут и в канале "ProductDo: практика для продактов". Если есть вопросы - рад ответить.