#Продакт менеджмент

Я отработал месяц в Гугл картах и мне прямо нравится и продукт, и команда, и моя роль. И я невольно рефлексирую что же пошло не так в моей первой команде, где я проработал первый год, и в какой-то момент просто сбежал оттуда.

Аналогия, которая пришла в голову — это ландшафт. Есть природный, а есть man-made, то есть создал его человек и его решения.

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

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

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

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

Но!

Если стратегия меняется каждые 3 месяца и людям нужно начинать по-новой, то в какой-то момент начинается усталость от такой среды так знакомая жителям больших городов. Ты просто становишься заложником чужих решений.

И у тебя есть выбор: бороться (и потенциально сломать хребет о корпоративные устои), уйти или быть в этом всём до конца. Я не стороннник сдаваться, но только если у меня есть голос в принятии решений. Когда решения настолько далеко от меня, то я не вижу смысла бороться, так как моя жизнь от этого не зависит и я могу продать своё время туда, где среда способствует достижению результата.

Аминь.


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

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

Для того, чтобы наглядно продемонстрировать как это круто, когда ментальные модели создателя и пользователя совпадают, приведу пример из мира музыки.

Давным-давно я смотрел интервью с Джеймсом Хетфилдом, лидером группы Metallica. Он говорил про то, что в его модели мира голос и гитара — это перкуссионные инструменты. Они не создают мелодию. Они создают ритм, как ударные.

Сегодня я слушал альбом “Hardwired to self destruct” в наушниках и в одной из песен отчётливо услышал, что именно Хетфилд имел ввиду. Гитара, голос и ударные сливались в одно целое.

Это была неудержная а-мелодичная долбёжка в унисон.

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

Так же у меня было с комиксами Sandman Нила Геймана. Я проникся жанром только после просмотра его мастер-класса, где я понял ментальную модель этого жанра искусства, которая помогла мне в полной мере наслаждаться иллюстрированными романами. То же касается любого искусства.

И любого приложения.

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

Figma, git, Google Docs, любая IDE — все они заставили нас работать немного по-другому. И это “по-другому” вывело нас на новый уровень.


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

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

Хорошие дизайнеры, как и хорошие разработчики, на вес золота и “я сказал” с ними не работает. Ты можешь “сказать”, а у них есть другие возможности для карьеры, где у них будет больше свободы.

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

Нужно задавать дизайнеру вопросы, которые заставляют его/её думать в разрезе решения проблемы пользователя. “Как ты видишь намерение пользователя?” “Как ты считаешь этот дизайн поможет ему достичь цели?” “Как этот дизайн взаимодействует с фичей Х?” “Что если пользователь хочет сделать Y?”

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

Если это не помогает, то полезно прибегнуть к принципам дизайна. При помощи принципов можно вывести дискуссию с уровня “чёто тут не то” на уровень “Давай обсудим как это соотносится с принципом Х?” “Применим ли этот принцип?” и “Почему мы отклоняемся от принятых в индустрии принципов?”

Такой подход выводит диалог в другую плоскость, позволяющую обсуждать с виду субъективные вещи в более объективном ключе. Хороший ресурс для изучения принципов - книга Дона Нормана “Дизайн повседневных вещей” и блог его компании Nielsen Norman Group.

Если вы не знакомы с принципами дизайна, стоит начать с этой статьи .


Начинающие продакт менеджеры, а также не-продакты (и не-маркетологи), запускающие продукт на рынок, допускают следующую ошибку — они презентуют продукт как набор фич. Чем больше список, тем “круче” продукт.

Чтобы понять суть проблемы, давайте разберём пример книги как продукта. Допустим, Илья Безделев написал книгу для продакт менеджеров и выложил на свой вебсайт список фич.

  • 14 глав, 300 страниц, 30 тысяч слов!
  • Электронная, аудио и бумажная версия!
  • Матовая супер-обложка!
  • Шрифт с засечками!

Что вы узнали про книгу? Ничего. Продакт менеджер в данном случае перечислил всю работу, которую сделала команда, технические характеристики продукта, но не смог передать какую ценность продукт несёт пользователю и почему стоит его попробовать.

Базовый принцип в маркетинге — коммуникация начинается с ценности для пользователя. Хороший продукт всегда решает какую-то проблему и помогает человеку или бизнесу стать лучше. Особенно, если этот продукт платный.

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

Брендинг идёт ещё дальше и создаёт aspirational image — некий имидж, другая версия тебя, которой ты будешь соответствовать, если купишь продукт.

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

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

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

Вернёмся к айти. Продавая программный продукт для бизнеса (SaaS), вы можете нарисовать воодушевляющую картинку того, как компания, внедрившая его, станет лидером рынка. Это поможет продать продукт высшему руководству.

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

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

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

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

Вопрос, на который вы должны отвечать — “what’s in it for me?” (что в этом для меня). Но не что в этом для вас, продакт менеджера или маркетолога, а “меня” — целевой аудитории, которая пользуется продуктом, сравнивает его с другими на рынке или ставит печать на банковском переводе. Поставьте себя на место клиента и спросите у самого себя “я-то что с этого буду иметь?”.


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

Мой первый продукт в Амазоне был платформой для аналитики данных и мы назвали его Seldon в честь персонажа трилогии Основание (также известной как “Академия”) Айзека Азимова. Хари Селдон изобрёл психоисторию, науку, которая помогала человечеству предсказывать будущее цивилизаций. А наша система помогала предсказывать будущее поведение пользователей на основе паттернов в данных.

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

У Амазона культура кодовых имён прослеживается в названиях зданий на кампусе. Так, Fiona — это кодовое имя электронной читалки Kindle, Oscar — СУБД Amazon Aurora, а Doppler — голосовой помощник Echo. Мета: один из моих разработчиков написал весь UI первой версии Авроры и мы тогда сидели в здании Оскар, что давало ему отдельный повод для ностальгии и гордости.

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

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

В телеграме у меня есть бот, помогающий публиковать посты. Его зовут Jotaro в честь мальчика-помощника великого самурая 16-го века Миямото Мусаши, автора Книги пяти колец и главного героя романа Musashi, который я сейчас слушаю. У меня всё в самурайской тематике, даже внутренние процессы


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

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

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

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

В какой-то момент начали складываться очертания того, куда я попал, и я начал документ под названием MVSR — Mission, Vision, Strategy, Roadmap. Миссия - это то, зачем мы существуем, высокая идея. Видение - цель на 3-5 лет. Стратегия - как мы достигаем видение и как это увязано со стратегией организации и Google Cloud. Roadmap - конкретные фичи, которые мы планируем сделать в ближайшее время.

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

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

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

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

Эти идеи пришли из трёх источников:

  • Физик Ричард Фейнман практиковал письмо всего, что он знает о предмете, чтобы увидеть границы своих знаний.
  • Мой бывший босс в Амазоне использовал документ MVSR, когда он пришёл в нашу организацию и наводил порядок.
  • Книга «Первые 90 дней» хорошо описывает баланс между техническими знаниями и организационным ориентированием на новом месте.

Итак, когда начинаешь работу в новой для себя сфере/команде/проекте:

  1. Максимально быстро получи общее представление о продукте, процессах, людях и технологиях через общение с людьми, чтение внутренних документов, просмотр видео и т.п.
  2. Начни писать то, что узнал. Это поможет как тебе, так и другим, потому что теперь «племенные» знания (tribal knowledge) становятся задокументированными знаниями и их легко передавать дальше.
  3. Возьми какой-нибудь проект, чтобы окунуться в детали. Погрузись туда с головой. Это поможет понять технические проблемы и ограничения, а также построить отношения с коллегами и пользователями.
  4. Пока у тебя свежий взгляд, подвергай текущие процессы сомнению, но не переусердствуй, так как ты ещё многого не знаешь. Просто задавай вопрос «почему» и изучай ответы. У тебя есть шанс изменить мышление команды к лучшему.
  5. Документируй всё. Повторяюсь, но это важно. Человек, который способен излагать свои мысли и синтезировать информацию письменно, сразу же приносит пользу любой команде. Люди это оценят.
  6. Поставь на паузу другие интеллектуальные задачи. Я на время перестал читать книги не по теме ибо мозг опух так, что я даже не мог нормально разговаривать после рабочего дня. Был перегруз от интенсива. Отдых важен.

Немного деталей о моей работе продакт менеджером в Google Cloud и её технической составляющей. Если вам скажут, что продакту необязательно быть технически подкованным, скажите, что это зависит от индустрии, и перешлите этот пост.

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

Один из моих продуктов - Google Cloud Run for Anthos. Разберём пошагово, что он делает, и заодно посмотрим на требования к знаниям.

  1. Всё начинается с кода, который клиенты запускают на облачной платформе Google Cloud. Мой продукт помогает разработчикам быть более эффективными. Чтобы понимать пользователей, мне нужно разбираться в процессах создания ПО в локальной среде: кодинг, управление зависимостями, сборка, отладка, git.

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

  3. Продукт построен на опен-сорс платформе Kubernetes, которую создали внутри Гугла. Тут начинается самое сложное. Kubernetes даёт много свободы администраторам (они - моя вторая категория пользователей), но чересчур сложный для разработчиков. Задача нашего продукта - дать админам гибкость в настройке, но скрыть всё это от кодеров. Мне приходится разбираться в деталях Kubernetes.

  4. Чтобы упростить жизнь разработчикам и создать иллюзию “бессерверности”, моя команда создала опен-сорс проект Knative. Скажу лишь, что он сложный и пока ещё не достиг версии 1.0, поэтому там много подвижных частей. Он - ядро продукта и его мне нужно понимать достаточно глубоко.

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

    Для сети (network layer) используется гугловский опен-сорс проект Istio, который добавляет к контейнерам в Kubernetes так называемые “sidecars” - дополнительные контейнеры, которые работают рядом с пользовательскими и отвечают за регулировку трафика, мониторинг и соблюдение политики безопасности внутри системы. Нужно разбираться в сетевых протоколах, DNS и информационной безопасности в целом.

  6. Нашим пользователям нужно мониторить свои приложения при помощи метрик, логов и трейсинга, что можно назвать общим словом observability. Этот функционал предоставляется другими продуктами Гугла, а также партнёрами вроде Datadog. Нужно самому уметь всем этим пользоваться, чтобы понимать пользователей.

  7. Интерфейсы продукта: командная строка, графический UI и платформа автоматизации инфраструктуры Terraform. Нужно разбираться в UX дизайне и как он помогает пользователям достигать их целей (UX - это не только то, что можно кликать, а всё, с чем взаимодействует пользователь). Также нужно понимать основы DevOps (infrastructure as code, CI/CD, GitOps).

  8. И напоследок - приложениям пользователей нужно делать запросы к другим продуктам Google Cloud. Эта задача не всегда тривиальная, потому что между приложением и API этих сервисов стоит Kubernetes. Нужно разбираться в платформе Google Cloud и авторизации запросов из Кубернетиса.

Когда я пришёл в Google, я не разбирался в контейнерах и всём, что связано с Kubernetes, Knative и Istio. Мне также не хватало знаний по сетевым протоколам. Чтобы почувствовать себя относительно уверенно, ушло полгода, но мне далеко до комфорта, который я испытываю в области, где у меня есть глубокая экспертиза. Идеальный кандидат на такую работу был бы разработчиком из Гугла, перешедший в продакт менеджмент. Такие есть, но их мало.

Большинство продакт менеджеров в Google Cloud, что я знаю лично — бывшие разработчики, которых тянуло к бизнесу, стратегии и более масштабному мышлению. Если кто-то из вас разработчик, задумывающийся о переходе в продакт менеджмент, вас оторвут с руками на продукты с технической пользовательской базой при наличии сильных продуктовых скиллов. Дерзайте!


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

Разработчики (особенно, самые умные) склонны думать, что другие люди думают так же как они и, конечно же, продукт будет им полезен и они будут за него платить. Поэтому, воодушевлённые, они бросаются в разработку и создают продукт на предположениях (assumptions) и оптимизме. Они запускают продукт, никто им не пользуется и он умирает.

В технологическом секторе часто используют ироничную цитату из фильма “Поле его мечты”, которая говорит “build it and they will come” (построй его и они придут). Эта фраза характеризует оптимизм стартапов, которые до конца не понимают какую проблему они решают и для кого, создают продукт, а пользователи не приходят.

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

Идеи, которые решают твои собственные проблемы — это отличный источник для старта. Но, прежде чем писать код, нужно выдвинуть гипотезу о том, кто твой пользователь и какая у него боль (pain point). Потом найти 8-10 человек, подходящих под профиль идеального пользователя и выяснить, есть ли у них такая проблема и как они её решают.

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

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

Через 10 бесед непременно появятся паттерны. Их нужно синтезировать в обновлённое видение продукта, которое во многом не будет соответствовать изначальным предположениям. Зато ты можешь натолкнуться на другие идеи и другие проблемы, решение которых принесёт пользователям больше пользы.

Такие диалоги могут быть весьма болезненными, потому что у большинства идей нет будущего. С каждым диалогом идея начнёт рассыпаться на кусочки и может так получиться, что ты не найдёшь никакого подтверждения своим гипотезам. Это обидно. Это больно. Это даже может быть ударом по самооценке, если ты сильно прикипел к идее и рвёшься воплотить её в жизнь.

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

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


Нужно ли продакт менеджерам кодить? На этот вопрос ответ однозначно “это зависит от компании и продукта”. Чтобы разобраться, давайте пройдёмся по требованиям к техническим навыкам продактов в Amazon и Google.

Нетехнический PM отвечает за продукт, в котором технологии — лишь средство реализации идеи, а конечные пользователи — нетехнари. Таким продуктом может быть корзина в интернет-магазине или форма оплаты. Продакту необязательно разбираться как они реализованы, чтобы понимать пользователей и определять куда вести продукт. В Амазоне такие PM есть, в Гугле нет.

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

Технический продакт также может отвечать за продукт, где, вдобавок к тому, что он основан на технологиях, пользователи — технари. Сложно развить эмпатию, придумывать идеи и заглядывать за углы, когда ты не понимаешь как работает и мыслит твоя пользовательская база. Это как работать с бухгалтерами и не разбираться в арифметике. У таких ПМ обычно есть бэкграунд в разработке, хоть сейчас они активно и не кодят. В Google и Facebook все PM проходят техническое интервью, некоторые включают кодинг.

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

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

Скоро расскажу почему нетехническим продактам тоже полезно кодить.


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

Кто же такие продакт менеджеры и чем они занимаются?

Продакт менеджер — это лидерская позиция, которая отвечает на вопросы зачем мы делаем продукт, для кого мы его делаем и что это за продукт. На вопрос “как мы создаём продукт” отвечает команда разработки, но продакт оказывает влияние и там.

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

Он(а) собирает данные из разных источников: прямое общение с пользователями, опросы, репорты аналитиков и анализ данных. У хорошего ПМ развит навык синтеза разрозненной информации в документы и презентации о проблемах, путях их решения и roadmap. Интуиция помогает ПМ быть visionary и заглядывать в будущее.

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

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

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


В интервью на подкасте Traction венчурный капиталист Andy Rachleff вскользь сказал одну очень интересную мысль: “Люди не придумывают идеи для продуктов и стартапов. Идеи приходят сами”.

Идеи приходят из собственного опыта, когда человек решает проблему для себя (scratch your own itch), или из глубокого понимания какого-то рынка и его проблем (earned secrets), или из инсайта, который комбинирует несколько дисциплин в нечто новое.

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

Earned secrets aka “заработанные секреты” — термин, который я подслушал в интервью с Marc Andreessen, создателем первого в мире интернет браузера и основателем Netscape. Заработанные секреты приходят из многих лет опыта работы в индустрии и открывают возможности зайти на сложные рынки, которые требуют глубокого понимания. Многие стартапы в области сложного и специализированного программного обеспечения — из этой серии.

Например, основатель всем знакомого сервиса Zoom работал в WebEx, одном из первых приложений для конференций, и позже Cisco, ведущего производителя оборудования и ПО для компьютерных сетей. За эти годы он заработал знания о том, как эффективно передавать видео и аудио через интернет и какие проблемы существуют с конференциями у корпораций.

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

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

В какой категории твои идеи?


Стив Джобс говорил, что Эппл скорее определяется тем, что компания НЕ делает, чем тем, что она выпускает на рынок. Это простое высказывание отражает основной принцип в создании успешных технологических продуктов.

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

Плохой продакт менеджер берёт идеи, которые к нему приходят, и добавляет их в продукт. Спустя годы добавления фич, мы получаем продукт, который может “всё и для всех”. В худшем случае это означает, что продукт — посредственность, который может всего по чуть-чуть, но ничего не делает хорошо. А если повезёт, продукт действительно обладает хорошим функционалом, но в нём невозможно ничего найти.

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

На смену раздутым продуктам всегда приходят новые, более простые. Продолжая аналогию с текстовыми редакторами, появились Google Docs, Quip, но и они со временем стали превращаться в то, что мы называем bloatware от слов bloat (раздутый) и software (программное обеспечение). Когда компании начинают работать с крупными клиентами, продукты неизбежно раздуваются, пока не начинают тонуть под собственным весом.

А что делать? Сильно просят же… Говорить нет, нет и ещё раз нет, даже когда сильно хочется сказать да. “Да” — это легко и помогает избежать конфликта, но за лёгкие решения всегда приходится расплачиваться. “Нет” — это сложно, но путь к совершенству лежит именно через эти три буквы.

P.S. На картинке знаменитые литографии быка Пикассо, показывающие как из сложного можно сделать простое и наоборот.